去年Q3，某中型SaaS團隊的代碼事故率突然腰斬。不是換了技術(shù)棧，不是招了架構(gòu)大神，是一個叫Alice的開發(fā)者離職8個月后，她的繼任者找到了一種讓AI"長記性"的辦法。

這事聽起來像那種LinkedIn成功學帖子，但細節(jié)很有意思。當事人沒賣課，沒發(fā)工具，只是把整個過程寫成了field note——那種工程師之間傳閱的、帶著點自嘲的戰(zhàn)地日記。

Alice的遺產(chǎn)，和所有人的噩夢

每個開發(fā)者都認識Alice。不是同一個人，是同一類處境：她有自己的"系統(tǒng)"，她發(fā)誓文檔"基本夠用"，她8個月前離職。然后你接手了。

當事人形容這種感覺像"一只猿站在煤氣灶前"——工具就在那兒，但你和AI一樣，都不知道哪個旋鈕會炸。

團隊試過正經(jīng)辦法。Bob承諾維護Postman集合，堅持了兩次，一次重構(gòu)之后，集合變成"歷史小說"。Karen寫功能文檔，寫得誠懇，但事后補的文檔沒有靈魂：永遠滯后兩個迭代，永遠漏掉那個凌晨2點會炸的邊緣情況，永遠在關(guān)鍵處差那么一點。

沒人撒謊，沒人偷懶。文檔作為"事后想法"（afterthought），注定會死。

所以他們換了個思路：如果要做對，就自己做——而且讓AI一起做。

大多數(shù)人把AI用成了自動售貨機

這是當事人觀察到的核心誤區(qū)。很多開發(fā)者對待大語言模型（LLM，Large Language Model）像投幣機：塞prompt，出代碼，上線。出問題了罵一句"AI沒用"，回去翻Stack Overflow。

但想想你怎么帶新人進一個爛攤子代碼庫？

你不會甩個repo地址說"修#247號工單，沖"。你會先花20分鐘講業(yè)務背景，指出哪個文件是雷區(qū)，提醒上次重構(gòu)埋的坑。你會檢查他的理解，確認你們對"問題"的定義一致，才讓他動手。

最后這一步，所有人都在跳過。對人類新人如此，對AI更是如此。

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

當事人的辦法極簡，三步：

第一步，在倉庫根目錄扔一個READ_BEFORE_CODE.md。

第二步，每次開新任務，給AI喂四樣東西：涉及的文件路徑、目標、上下文、以及明確要求——先別寫代碼，先更新那份文檔。

第三步，讀AI寫的理解，糾偏，確認共識，然后說LFG（Let's F***ing Go）。

就這么簡單。沒有prompt工程證書，沒有RAG架構(gòu)圖，沒有向量數(shù)據(jù)庫。

他貼了一個真實示例。任務：修復建筑類別過濾器返回錯誤結(jié)果。給AI的指令是：

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

「目標：修復建筑類別過濾器返回錯誤結(jié)果」

「在寫任何代碼之前，先更新READ_BEFORE_CODE.md，寫明：1. 你對每個文件角色的理解；2. 它們與這個bug的關(guān)系；3. 你認為需要改什么、為什么；4. 你的假設和盲區(qū)」

「現(xiàn)在，不要寫代碼」

關(guān)鍵在這里：你要AI產(chǎn)出的不是代碼，是一個外化的思維模型。

為什么這比直接生成代碼管用

那份markdown審查是"vibe check"——不是事實核查，是校準共享語境。在真刀真槍之前，確認你們對"我們在修什么"達成一致。

它暴露兩件事：AI的盲區(qū)（它誤解了某個文件的作用），和你自己的盲區(qū)（你沒意識到某個邊緣情況）。

當事人還加了一條常駐規(guī)則：「你做的每件事之后，更新這個文件。這是你的日記，這樣你——或者下一個接手的人——不會重復踩坑?！?/p>

這行字讓AI從"一次性代碼生成器"變成了有記憶的協(xié)作者。3個月后，團隊代碼事故減少47%。

數(shù)字來自內(nèi)部統(tǒng)計，沒第三方審計，但當事人說"我們數(shù)過"。

一個值得玩味的細節(jié)

整個field note最扎心的部分，是當事人對Alice的復雜感情。他說"Alice who left 8 months ago"用了三遍，像某種咒語。他沒罵Alice，反而承認：如果Alice當年有這份READ_BEFORE_CODE.md，他接手時不會那么痛苦。

現(xiàn)在他的AI"實習生"每天更新這份文檔。下一個接他班的人，會面對一個會自我解釋的代碼庫——還是另一個Alice的爛攤子？

這取決于他能不能堅持住第三步：讀，糾偏，確認，再動手。而不是直接說LFG。