上一篇我写，我们用了 8 个月 Trae，最后还是把主力开发转向了 Codex。
今天接着说更具体的一层：转向 Codex 后，我最先做的不是研究更多技巧，而是先把 5 条 AI 规则写死。
因为我越来越确定一件事：
AI 越能干，越不能把猜测权交给它。
Trae 到 Codex 的变化，不只是工具迁移。更深一层，是我对 AI 工作流的期待变了。
以前我会期待它“帮我做完”。
现在我更在意它“能不能在我写死的边界里，按真实工程规则和我一起做完”。
这背后其实是很朴素的第一性原理：一个稳定系统，不能靠每次临场发挥，它要靠确定入口、清晰边界、短反馈、真验收和失败留痕。
我现在给 Codex 写死的 5 条规则，基本都围着这几个东西转。
规则一：先收口，再执行我现在很少直接对 Codex 说“帮我做一下这个”。
这句话太宽了。
宽到 AI 会自己替你补很多东西：它会猜范围，猜目标，猜你能接受的改动幅度，猜哪些文件可以碰，猜做到什么程度算完成。
猜得顺的时候，看起来效率很高。
但只要猜错一次，后面就全是人来兜底。
所以我现在做正式项目，第一步一定是先收口：
这次只做什么。
验收是什么。
哪些地方不能碰。
优先怎么做。
最后输出什么。
这看起来像多写了几句话，其实是在把 AI 的行动空间先圈出来。
先收口，不是为了让 AI 变慢，而是为了让它不要快到跑偏。
这也是我自己底层技能流里最重要的一层：输入先拆，任务先定边界，再进入执行。
很多 AI 协作的问题，不是模型不够强，而是人一开始给了一个太松的口子。
口子一松，后面所有“聪明”都可能变成失控。
规则二：先读现有入口，不准重新发明入口我现在让 Codex 启动项目、联调前后端，或者进入一个陌生仓库，都会先写一条硬规则：
先读现有脚本、文档和配置。
不要自己发明入口。
这条规则是踩过坑之后才变硬的。
AI 很容易找到一条“看起来能跑”的路。
比如换一个更容易启动的 profile，绕过一段真实配置，用 mock 数据让页面先有返回，或者发现一条旧命令能跑，就顺手用了。
表面看，服务起来了。
但这不是我要的联调。
我要的是按项目本来的入口启动，按真实配置启动，按现有约束启动。
能跑只是第一层。
跑对才是关键。
Codex 可以替我按下开关，不能替我重新发明开关。
这也是为什么脚本和文档不是仪式感。
它们是单一真相源。
入口一旦不唯一，AI 就会在多个“可能可以”之间自己选路。可真实项目里，很多时候我们不需要它选路，我们需要它沿着已经确认过的路走。
规则三：不能用假通过替代真验收这是我现在最在意的一条。
AI 做项目时，最危险的不是失败。
失败其实很好处理，报错、看日志、继续查。
真正危险的是“假通过”。
页面打开了，但接的是 mock。
接口返回了，但不是生产同构配置。
测试跑过了，但绕开了真实数据库。
服务启动了，但启动方式不是项目约定的那一套。
这些东西都很容易让人误判。
所以我现在会把禁令写得很死：
联调和验收不能用 local profile、mock 数据、本地临时库来冒充通过。
缺真实配置，就说缺真实配置。
缺真实数据库，就说缺真实数据库。
没有权限，就说没有权限。
真实世界里，失败不是问题，假通过才会把判断带歪。
这条规则背后的第一性原理也很简单：验收必须对应真实目标。
如果目标是验证真实业务链路，那本地模拟只能算自测，不能算验收。
AI 最容易犯的错，是太想把任务完成。
可对项目负责人来说，完成感不重要，可信度才重要。
规则四：每一步都要看得见、测得到、退得回这点其实trae会更方便一些，codex需要通过git来完成。
先读仓库。
再说计划。
小步修改。
看 diff。
跑命令。
看报错。
再修。
最后说风险。
这套流程听起来不炫，但它踏实。
因为真实项目最怕的不是 AI 写不出来，而是它一口气改太多。
它一改多，影响面就变大。
影响面一大，人就要重新花时间兜底。
所以我现在会把规则写得很细：
不要无关重构。
不要顺手优化。
不要跨范围改动。
每次只处理一个问题。
同一个假设最多试两次，第三次必须换假设。
这些规则看起来限制了 AI，其实是在保护人的注意力。
真正可控的 AI 工作流，一定要让每一步都有证据。
证据可以是 diff，可以是日志，可以是测试结果，可以是明确的阻塞说明。
只要每一步看得见，问题就还能收住。
看不见的效率，最后往往会变成人的焦虑。
规则五：失败必须报告，不能偷偷换路我最不想让 AI 做的一件事，就是为了完成任务偷偷换一条更容易成功的路。
比如原来应该按真实配置启动，它发现失败了，就换成 local。
原来应该连真实服务，它发现连不上，就换成 mock。
原来应该跑主链路，它发现卡住了，就跑一个更轻的替代命令。
这不叫解决问题。
这叫把问题藏起来。
所以我现在会明确告诉 Codex：
失败就报告。
说清楚检查过哪些路径。
卡在哪一步。
缺什么条件。
下一步建议怎么处理。
但不要自己换路，不要用容易成功的路径冒充目标路径完成。
成熟的 AI 协作，不是 AI 永远成功，而是 AI 失败时也能留下可信现场。
这条规则对我很重要。
因为只要失败现场可信，人就还能判断。
一旦 AI 自己改路，人看到的就不是现场，而是一个被包装过的结果。
那时你以为自己在验收，其实你在猜。
工具越强，越要把边界写清楚回到 Trae 和 Codex。
我不是因为 Codex 更听话，才把这些规则写死。
恰恰相反，是因为 AI 越能做事，我越需要提前写清楚哪些事不能由它判断。
Trae 适合启动以及小范围代码直接修改，Codex 适合落地。
但不管用哪个工具，有一条线不能丢：
AI 可以替我省下重复劳动，但不能替我决定验收标准。
AI 可以帮我执行复杂流程，但不能替我拥有猜测权。
AI 可以加速，但不能失控。
这也是我现在理解的成熟 AI 工作流：
不是把所有动作都交给一个工具。
而是把任务拆清楚，把入口钉住，把验收写死，把失败暴露出来，然后让 AI 在这个框架里尽量发挥。
工具迁移只是表面，真正的迁移，是从“让 AI 帮我做完”，迁移到“让 AI 按规则和我一起做完”。
这比换哪个工具更重要。
因为工具还会变。
但你怎么保留判断权，怎么定义边界，怎么识别假通过，怎么要求失败留痕，这些东西会一直决定你能不能真的把 AI 用进项目里。
你现在让 AI 做项目时，最怕它在哪一步自作聪明：自己换入口、偷偷用 mock，还是一口气改太多？