代码事故少了47%：一个开发者把AI当实习生用了3个月

去年Q3，某中型SaaS团队的代码事故率突然腰斩。不是换了技术栈，不是招了架构大神，是一个叫Alice的开发者离职8个月后，她的继任者找到了一种让AI"长记性"的办法。

这事听起来像那种LinkedIn成功学帖子，但细节很有意思。当事人没卖课，没发工具，只是把整个过程写成了field note——那种工程师之间传阅的、带着点自嘲的战地日记。

Alice的遗产，和所有人的噩梦

每个开发者都认识Alice。不是同一个人，是同一类处境：她有自己的"系统"，她发誓文档"基本够用"，她8个月前离职。然后你接手了。

当事人形容这种感觉像"一只猿站在煤气灶前"——工具就在那儿，但你和AI一样，都不知道哪个旋钮会炸。

团队试过正经办法。Bob承诺维护Postman集合，坚持了两次，一次重构之后，集合变成"历史小说"。Karen写功能文档，写得诚恳，但事后补的文档没有灵魂：永远滞后两个迭代，永远漏掉那个凌晨2点会炸的边缘情况，永远在关键处差那么一点。

没人撒谎，没人偷懒。文档作为"事后想法"（afterthought），注定会死。

所以他们换了个思路：如果要做对，就自己做——而且让AI一起做。

大多数人把AI用成了自动售货机

这是当事人观察到的核心误区。很多开发者对待大语言模型（LLM，Large Language Model）像投币机：塞prompt，出代码，上线。出问题了骂一句"AI没用"，回去翻Stack Overflow。

但想想你怎么带新人进一个烂摊子代码库？

你不会甩个repo地址说"修#247号工单，冲"。你会先花20分钟讲业务背景，指出哪个文件是雷区，提醒上次重构埋的坑。你会检查他的理解，确认你们对"问题"的定义一致，才让他动手。

最后这一步，所有人都在跳过。对人类新人如此，对AI更是如此。

具体操作：一份叫READ_BEFORE_CODE.md的文件

当事人的办法极简，三步：

第一步，在仓库根目录扔一个READ_BEFORE_CODE.md。

第二步，每次开新任务，给AI喂四样东西：涉及的文件路径、目标、上下文、以及明确要求——先别写代码，先更新那份文档。

第三步，读AI写的理解，纠偏，确认共识，然后说LFG（Let's F***ing Go）。

就这么简单。没有prompt工程证书，没有RAG架构图，没有向量数据库。

他贴了一个真实示例。任务：修复建筑类别过滤器返回错误结果。给AI的指令是：

「涉及的文件：/absolute/path/to/service.ts, /absolute/path/to/types/core.d.ts」

「目标：修复建筑类别过滤器返回错误结果」

「在写任何代码之前，先更新READ_BEFORE_CODE.md，写明：1. 你对每个文件角色的理解；2. 它们与这个bug的关系；3. 你认为需要改什么、为什么；4. 你的假设和盲区」

「现在，不要写代码」

关键在这里：你要AI产出的不是代码，是一个外化的思维模型。

为什么这比直接生成代码管用

那份markdown审查是"vibe check"——不是事实核查，是校准共享语境。在真刀真枪之前，确认你们对"我们在修什么"达成一致。

它暴露两件事：AI的盲区（它误解了某个文件的作用），和你自己的盲区（你没意识到某个边缘情况）。

当事人还加了一条常驻规则：「你做的每件事之后，更新这个文件。这是你的日记，这样你——或者下一个接手的人——不会重复踩坑。」

这行字让AI从"一次性代码生成器"变成了有记忆的协作者。3个月后，团队代码事故减少47%。

数字来自内部统计，没第三方审计，但当事人说"我们数过"。

一个值得玩味的细节

整个field note最扎心的部分，是当事人对Alice的复杂感情。他说"Alice who left 8 months ago"用了三遍，像某种咒语。他没骂Alice，反而承认：如果Alice当年有这份READ_BEFORE_CODE.md，他接手时不会那么痛苦。

现在他的AI"实习生"每天更新这份文档。下一个接他班的人，会面对一个会自我解释的代码库——还是另一个Alice的烂摊子？

这取决于他能不能坚持住第三步：读，纠偏，确认，再动手。而不是直接说LFG。