去年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。
热门跟贴