与 AI 编程工具协作
现在，大部分在 iMBrace 上的构建工作都可以借助 AI 编程工具完成。这没有问题，而且它几乎不 改变“完成”这个词的含义。这一页讲的，就是真正会改变的那部分。
立场
工具辅助，人来决定。 这并不是因为工具能力弱，而是因为责任无法转移。必须有人签字确认 这个构建能用，而签字的不能是写出它的那个工具。
构建对自身的汇报，从不被直接采信。 AI 工具让这一点更加突出：一份令人信服的“测试通过” 总结很容易写出来，却很难和真的测试通过区分开。要亲自运行它、亲眼看着它、到平台上查看结果。 一个你没有亲眼见过的“绿灯”，就不是绿灯。
如实说明状态。 一次构建里的每一部分，都只会是以下三种状态之一：
- 已提议——已经设计，还没有构建；
- 已构建——已经构建，但还没有在平台上运行并核实；
- 已上线——已经在平台上运行，并且结果经过人的核实。
没有人会因为停留在“已构建”而被苛责。真正的失败，是把从未运行过的东西写成“已上线”。
该给工具什么
- 这份指南的
AGENTS.md，或者管辖你手头这项工作的那一页——不要一次给全部内容：一个 把所有东西都读了一遍的工具，留给你这个问题的空间反而更少。 - SDK 自己的地图，在它编写 SDK 代码时，从 engineer.imbrace.co 现抓现用，绝不用旧的副本。
- 组织本身，通过 MCP 连接，用在“这里存在什么”或“发生过什么”这类问题上——见 设置你的编程工具。
准则
- 工作流程、代码步骤、提示词或已提交的文件里都不能出现凭证。 凭证只存放在组织自己的
连接存储中，或者存放在一个绝不提交的本地
.env文件里。 - 代码步骤是纯函数——数字进去，结果出来，没有网络调用，没有密钥——如果做不到，就 明确说明原因。
- 拒绝回答本身也是一种数据，不是错误。 “我没找到”是一个有效、有用的答案。
- 被跳过的检查绝不算通过。 如果一项测试没能运行，就如实说它没有运行。
- 测试数据、日志、提示词或示例中都不能出现个人数据。 都用虚构的。
- 写给一个陌生人看。 用平实的句子，不用只有当事人才懂的简写或黑话。
最重要的几个习惯
- 业务成果优先。 谁会用它、今天卡在哪里、它能带来什么——一个漂亮地回答了没人问过 的问题的方案，就是一个错误的方案。
- 人先画草图。 在工具提出设计方案之前，先让人把用例画出来——形状、各个部分，以及 哪里由人来做决定。这样设计才始终属于这个人。
- 带着证据表达不同意见。 当工具认为这个人错了，它应立即说出来，并给出证据，而不是 默默按要求去做。
- 每一个论断都要有依据。 一条数据表记录、一次运行的 id、一段粘贴出来的输出——没有 依据，就不能下论断。
- 改正记录时要注明日期。 当一条发现或一条决策记录后来被证明是错的，就地注明日期 说清楚，并保留原文可见。
- 由另一个人来评审。 在发布之前，由没有参与构建的人跑一遍 评审清单。
- 流程的繁简要与改动的大小相称。 一次小改动，只需要一条小记录。
让委派保持浅层
如果你的工具把工作交给了它自己的助手，就把交接控制在最上一层，给每个助手一份完整的任务 说明，并亲自核实每一个结果：当某个助手说它修好了什么，就打开文件亲自看一看。
“完成”意味着什么
另一个人能够安装使用的成果、一份他们能照着做的说明、一个他们能运行的测试，以及对每个部分 如实标注的状态。