我们在 Neutron 如何构建软件
这是我们用 AI agent 开发软件的规则。在客户项目上，以客户明确提出的要求为准。
规则
代码由 agent 写，不由人写。
我们用 Claude Code 和 Codex 开发。工程师划定范围、给 agent 提供上下文、检查证据，并对结果负责。不要手工改代码：让 agent 去改；反复出现的错误，写进测试或指令。
用 AI agent 开发 →一个 ticket，一个目的。
agent 从 ticket 的目标和验收标准出发，PR 只改为此必须改的地方。PR 大一点没关系，只要它只做一件事，而且证据够别人核查。把新功能、重构和顺手修复混在一起的 PR 就不行。PR 描述要写明为什么改。
交付改动 →agent 的上下文必须准确。
每个 agent 都依据
发布与收尾 →AGENTS.md、CLAUDE.md和文档工作，所以文档写错比没写更糟。哪个 PR 让某条指令不再准确，就在那个 PR 里改掉；计划和工作笔记放在 PR 或 ticket 里，不放进仓库。每次发布后，让文档和代码对齐：该改的改，该补的补，该重组的重组，没人说得清用途的删掉。与其再写一段说明，不如加一个测试或强制检查。全绿必须代表真的能用。
拿出证据，证明每条验收标准都已满足，受影响的现有行为也仍然正常：按验收标准写的测试，加上测试覆盖不到的地方实际跑一遍。证据只对它运行时的那个 commit 有效：代码一改，就要重新收集。写明哪些没有验证。删除、跳过、放宽或禁用检查，都要说明理由，并得到评审人明确同意。
交付改动 →每个改动都有人负责，也有人批准。
负责人能说清改动做了什么、会怎么出问题、怎么撤销。合并前由另一个人批准。AI 评审只提建议，不能批准。
代码评审 →agent 在硬性边界内工作。
只有经过批准的工具才能接触我们的代码。绝不把密钥或真实个人数据写进源代码、prompt 或日志。不管 agent 以什么方式运行，生产环境操作和破坏性操作都要有人明确同意。这些边界靠权限和工具强制执行；只写一条指令，不算边界。
访问、密钥与数据 →
刚开始用 AI agent 写代码？先读用 AI agent 开发。