1. 從一次科研翻車說起為什么我開始給 AI Agent 寫項目文檔去年冬天我在做一個材料計算方向的文獻復現(xiàn)項目。當時手頭同時開著三個 AI Agent 會話一個用 Codex 幫我重構數(shù)據(jù)清洗腳本一個用 Claude Code 幫我梳理實驗流程還有一個在跑文獻摘要的批量提取。三個會話各自跑得挺歡直到某天晚上我發(fā)現(xiàn)——數(shù)據(jù)清洗腳本里用的字段命名和實驗流程文檔里定義的完全對不上。一個叫sample_id一個叫specimen_no還有一個干脆用了material_key。三個 Agent 各自為政誰也沒錯但合在一起就是一團亂麻。那天我花了整整四個小時做人工對齊。四個小時夠我跑完一輪完整的 DFT 計算了。這件事之后我開始認真思考一個問題我們花大量時間研究怎么搭 AI Agent、怎么調 prompt、怎么接模型卻很少花時間研究怎么讓 Agent 理解這個項目到底是什么。Agent 的能力再強如果它不知道你的項目結構、命名規(guī)范、數(shù)據(jù)流向、約束條件它就只能靠猜。而猜在科研場景里是致命的。于是我開始在項目根目錄放一個PROJECT.md。一開始只是隨手記幾行項目說明后來越寫越細逐漸變成了一套完整的項目上下文協(xié)議。現(xiàn)在我的每個科研項目根目錄下都有這個文件Agent 一進來先讀它讀完再干活。效果立竿見影命名沖突沒了重復解釋沒了跨會話的上下文斷裂也基本消失了。這篇文章就是把我這套做法完整拆開講清楚。不管你是剛接觸 AI Agent 的新手還是已經(jīng)在用 Codex、Claude Code 做開發(fā)的老手只要你的項目需要多個 Agent 協(xié)作、或者需要 Agent 在多次會話之間保持一致性這套方法都能直接抄作業(yè)。我會講清楚PROJECT.md到底該寫什么、為什么這么寫、怎么和AGENTS.md配合、以及我在實操中踩過的那些坑。2. 先搞清楚AI Agent、LLM、AI 模型到底差在哪2.1 三層概念的生活化拆解很多人一上來就混淆這幾個詞導致后面配置 Agent 的時候概念對不上。我用一個做菜的類比來講AI 模型比如 DeepSeek、GPT 系列、Claude 系列就像一本菜譜。它知道怎么做菜知識都在里面但它自己不會動。你問它紅燒肉怎么做它能給你寫出完整步驟但它不會去開火。LLMLarge Language Model大語言模型是 AI 模型里專門處理語言的那一類。DeepSeek 屬于 LLMClaude 屬于 LLMGPT 也屬于 LLM。它們擅長理解和生成文本但本質上還是菜譜——你問它答你不問它不動。AI Agent則是那個真正下廚的廚師。它手里拿著菜譜LLM但它還會去冰箱拿食材調用工具、嘗味道執(zhí)行代碼看結果、根據(jù)味道調整多輪迭代、最后端菜上桌輸出成果。Agent 的核心特征是自主性和工具使用能力——它能自己決定下一步做什么而不是等你一步步指令。所以當你聽到Codex 接入 DeepSeek這種說法時意思是用 DeepSeek 這個 LLM 作為 Codex 這個 Agent 的大腦。Codex 負責決策和工具調用DeepSeek 負責語言理解和生成。兩者是協(xié)作關系不是同一個東西。2.2 為什么這個區(qū)分對寫 PROJECT.md 很重要理解了這個分層你就能明白PROJECT.md到底在解決哪一層的問題。LLM 那一層你控制不了太多——模型的能力是固定的你只能通過 prompt 影響它。Agent 那一層你能控制它的工具、它的循環(huán)邏輯、它的終止條件。但項目上下文這一層是你可以完全掌控的而且它同時影響 LLM 的理解和 Agent 的決策。PROJECT.md就是項目上下文層的核心載體。它不改變模型能力也不改變 Agent 架構但它改變了 Agent看到什么。Agent 看到的信息越結構化、越準確它的決策質量就越高。這就像給廚師一張清晰的廚房布局圖——食材在哪、調料在哪、哪些鍋不能用一目了然做菜效率自然高。2.3 常見 Agent 產品的能力邊界目前科研場景里用得比較多的 Agent 產品我按使用頻率排一下Agent 產品核心優(yōu)勢典型科研用途對 PROJECT.md 的依賴度Claude Code長上下文、代碼理解強重構腳本、梳理流程高Codex代碼生成快、工具調用靈活批量數(shù)據(jù)處理、自動化高通用對話 Agent上手快、門檻低文獻摘要、思路整理中自建 Agent完全可控、可定制特定流程自動化極高依賴度越高說明這個 Agent 越需要項目上下文才能發(fā)揮價值。自建 Agent 依賴度最高因為它沒有預設的領域知識全靠你喂。Claude Code 和 Codex 雖然有一些通用能力但在科研這種高度專業(yè)化的場景里沒有PROJECT.md照樣抓瞎。3. PROJECT.md 的整體設計思路它不是 README 的替代品3.1 為什么 README 不夠用很多人第一反應是我不是已經(jīng)有 README 了嗎問題在于README 是寫給人看的PROJECT.md是寫給Agent看的。這兩者的信息需求完全不同。README 通常包含項目簡介、安裝步驟、使用示例、貢獻指南。這些對人有用但對 Agent 來說太粗了。Agent 需要知道的是這個項目的目錄結構長什么樣、每個目錄放什么、命名規(guī)范是什么、哪些文件不能動、數(shù)據(jù)從哪來到哪去、當前處于什么階段。舉個具體例子。README 里可能寫運行python main.py啟動項目。但 Agent 需要知道的是main.py依賴哪些環(huán)境變量、輸出寫到哪個目錄、如果報錯先檢查什么、有沒有已知的坑。這些信息 README 不會寫因為人可以通過試錯解決但 Agent 試錯成本很高——它可能跑偏很遠才回來。3.2 PROJECT.md 的四個核心作用我總結下來PROJECT.md在科研項目里承擔四個作用第一定義邊界。告訴 Agent 哪些能動、哪些不能動?？蒲许椖坷锝?jīng)常有原始數(shù)據(jù)、中間結果、最終成果三層Agent 如果不知道邊界可能把原始數(shù)據(jù)覆蓋了那就出大事了。第二統(tǒng)一語言?？蒲许椖可婕按罅繉I(yè)術語和自定義命名。PROJECT.md里定義好術語表和命名規(guī)范Agent 就不會各說各話。第三傳遞狀態(tài)。項目進行到哪一步了、當前在解決什么問題、下一步計劃是什么。Agent 知道這些才能給出有針對性的建議而不是從頭開始問。第四約束行為。明確告訴 Agent 什么不能做。比如不要修改raw_data/下的任何文件、生成代碼必須帶類型注解、所有輸出必須用 UTF-8 編碼。這些約束能避免大量返工。3.3 和 AGENTS.md 的分工這里要特別說一下AGENTS.md。這兩個文件經(jīng)常被混淆其實分工很明確PROJECT.md描述的是項目本身——這個項目是什么、結構如何、規(guī)范如何。它是相對靜態(tài)的項目不變它就不怎么變。AGENTS.md描述的是Agent 的工作方式——你希望 Agent 怎么干活、用什么風格、遵循什么流程。它是相對動態(tài)的你可以針對不同任務調整。打個比方PROJECT.md是廚房布局圖AGENTS.md是菜譜。布局圖告訴你廚房有什么、東西放哪菜譜告訴你今天做什么菜、按什么步驟做。兩者配合Agent 才能既知道環(huán)境又知道任務。我通常的做法是PROJECT.md放在項目根目錄所有 Agent 共享AGENTS.md可以放在根目錄也可以放在子目錄針對特定任務定制。如果項目簡單一個PROJECT.md就夠了如果項目復雜、任務多樣兩個都上。4. PROJECT.md 的核心內容模塊與寫法4.1 項目概覽讓 Agent 三秒進入狀態(tài)開頭部分要極其精煉讓 Agent 快速建立認知。我通常寫三段第一段一句話說清楚項目做什么。比如本項目復現(xiàn) XX 材料在不同溫度下的熱導率計算使用 VASP 和 LAMMPS 雙引擎交叉驗證。第二段說清楚當前階段。比如當前處于數(shù)據(jù)預處理階段已完成 60% 的原始數(shù)據(jù)清洗下一步進入計算參數(shù)標定。第三段說清楚關鍵約束。比如所有計算必須在集群上運行本地只做數(shù)據(jù)處理和結果分析。這三段加起來不超過 200 字但 Agent 讀完就能知道我在做什么、做到哪了、有什么限制。這比讓它自己翻文件猜要高效得多。注意項目概覽不要寫太長。我見過有人把項目背景寫了 2000 字Agent 讀完前面忘了后面。概覽就是概覽細節(jié)放到后面的模塊里。4.2 目錄結構給 Agent 一張地圖這是PROJECT.md里最實用的部分。我通常用代碼塊畫一棵目錄樹然后在每個關鍵目錄后面加注釋project_root/ ├── raw_data/ # 原始數(shù)據(jù)只讀禁止修改 ├── processed_data/ # 清洗后的數(shù)據(jù)可讀寫 ├── scripts/ # 所有腳本按功能分子目錄 │ ├── preprocessing/ # 數(shù)據(jù)預處理腳本 │ ├── calculation/ # 計算相關腳本 │ └── analysis/ # 結果分析腳本 ├── results/ # 計算結果輸出按日期分子目錄 ├── docs/ # 文檔包括本文件 └── PROJECT.md # 項目上下文文件這棵樹看起來簡單但信息量很大。Agent 一看就知道原始數(shù)據(jù)不能碰、腳本按功能分類、結果按日期組織。沒有這棵樹Agent 可能把腳本扔到根目錄或者把結果寫到raw_data/里那就麻煩了。我還會在樹后面補一段說明解釋幾個容易混淆的目錄。比如processed_data/和results/的區(qū)別前者是清洗后的輸入數(shù)據(jù)后者是計算產生的輸出數(shù)據(jù)不要混用。4.3 命名規(guī)范統(tǒng)一語言的關鍵科研項目里命名混亂是常態(tài)。同一樣東西有人叫sample有人叫specimen有人叫material。Agent 如果不知道統(tǒng)一規(guī)范就會跟著亂。我在PROJECT.md里會明確寫樣本 ID 統(tǒng)一用S加三位數(shù)字如S001、S012溫度參數(shù)統(tǒng)一用T加數(shù)值加單位如T300K、T500K文件命名統(tǒng)一用下劃線分隔全小寫如sample_s001_clean.csv變量命名統(tǒng)一用蛇形命名法如sample_id、temperature_k這些規(guī)范看起來瑣碎但能省掉大量對齊成本。我實測下來有了命名規(guī)范之后Agent 生成的代碼和文檔一致性提升了非常多基本不需要人工修正命名。提示命名規(guī)范要寫具體例子不要只寫規(guī)則。Agent 對例子的理解比對規(guī)則的理解更準確。比如用蛇形命名法不如用sample_id這種格式不要用sampleId或SampleID。4.4 數(shù)據(jù)流向讓 Agent 知道數(shù)據(jù)從哪來到哪去科研項目的數(shù)據(jù)流通常比較復雜原始數(shù)據(jù)經(jīng)過清洗變成中間數(shù)據(jù)中間數(shù)據(jù)經(jīng)過計算變成結果數(shù)據(jù)結果數(shù)據(jù)經(jīng)過分析變成圖表。Agent 如果不知道這個流向可能在中途插一腳把流程打亂。我會用一段文字加一個簡單的列表來描述raw_data/下的原始文件由實驗設備導出只讀scripts/preprocessing/下的腳本讀取原始文件輸出到processed_data/scripts/calculation/下的腳本讀取processed_data/輸出到results/scripts/analysis/下的腳本讀取results/生成圖表到results/figures/這樣 Agent 就知道要改數(shù)據(jù)先改預處理腳本要看結果去results/要加分析寫新腳本放analysis/。每個環(huán)節(jié)的輸入輸出都清清楚楚。4.5 當前狀態(tài)與待辦讓 Agent 接得上手這部分是動態(tài)更新的我通常每周更新一次。內容包括當前正在解決的問題已經(jīng)嘗試過的方案和結果下一步計劃已知的阻塞點比如當前正在標定計算參數(shù)已嘗試ENCUT400和ENCUT500前者結果偏差 3%后者偏差 1.5%下一步嘗試ENCUT600。阻塞點集群隊列排隊時間較長單次計算等待約 2 小時。Agent 讀到這些就能直接接著干而不是從頭問你做到哪了。這在跨會話場景里特別有用——今天用 Codex 跑了一半明天換 Claude Code 繼續(xù)只要PROJECT.md更新了新 Agent 就能無縫接手。5. 實操從零搭建一套 PROJECT.md 工作流5.1 第一步初始化項目結構假設你剛拿到一批實驗數(shù)據(jù)準備開始一個科研項目。先別急著寫代碼先把目錄結構搭好mkdir -p project_root/{raw_data,processed_data,scripts/{preprocessing,calculation,analysis},results,docs} touch project_root/PROJECT.md然后把原始數(shù)據(jù)放進raw_data/確保它是只讀的chmod -R 444 project_root/raw_data/這一步很關鍵。Agent 有時候會好心幫你修改原始數(shù)據(jù)如果你沒設只讀它可能真的改了。設了只讀之后它想改也改不了只能來問你。5.2 第二步寫第一版 PROJECT.md第一版不用寫太細把四個核心模塊填上就行項目概覽、目錄結構、命名規(guī)范、數(shù)據(jù)流向。我通?；?15 分鐘寫第一版后面根據(jù)實際使用情況逐步補充。寫的時候有個技巧假設 Agent 是一個剛入職的實習生。它聰明、能干但對你的項目一無所知。你要告訴它什么才能讓它第一天就能干活按這個標準寫基本不會漏。5.3 第三步配置 Agent 讀取 PROJECT.md不同 Agent 的配置方式不一樣。以 Claude Code 為例你可以在項目根目錄放一個.claude/目錄里面配置上下文文件路徑。Codex 則可以通過項目配置文件指定上下文。通用做法是在 Agent 的啟動配置里把PROJECT.md加入上下文加載列表。這樣每次 Agent 啟動都會先讀這個文件。如果你用的是自建 Agent那更簡單——在系統(tǒng) prompt 里直接引用PROJECT.md的內容或者讓 Agent 啟動時先調用文件讀取工具讀它。注意不要讓 Agent 每次都全文讀取PROJECT.md。如果文件很長可以拆成多個文件按需加載。比如PROJECT.md只放概覽和目錄結構詳細規(guī)范放到docs/naming_conventions.mdAgent 需要時再讀。5.4 第四步和 AGENTS.md 配合使用AGENTS.md我通常寫這幾塊Agent 的角色定位比如你是一個科研數(shù)據(jù)助手專注于數(shù)據(jù)清洗和計算腳本編寫工作流程比如先讀 PROJECT.md再檢查當前狀態(tài)然后提出方案等我確認后再執(zhí)行輸出規(guī)范比如所有代碼必須帶注釋所有輸出必須說明依據(jù)禁止事項比如不要修改 raw_data/不要刪除任何文件不要跳過確認步驟PROJECT.md和AGENTS.md配合起來Agent 就既有環(huán)境認知又有行為約束干活就靠譜多了。5.5 第五步迭代優(yōu)化第一版寫完不是結束而是開始。每次 Agent 犯錯你就想是不是PROJECT.md里沒寫清楚如果是就補上。這樣迭代幾輪PROJECT.md會越來越完善Agent 的錯誤率會越來越低。我自己的PROJECT.md從第一版到現(xiàn)在改了大概 20 多次。每次改動都對應一個實際踩過的坑。比如有一次 Agent 把結果寫到了processed_data/里我就在數(shù)據(jù)流向里加了一句結果數(shù)據(jù)只能寫到 results/禁止寫到 processed_data/。之后再沒犯過。6. 常見問題與排查技巧實錄6.1 Agent 不讀 PROJECT.md 怎么辦這是最常見的問題。原因通常有三個一是配置沒生效二是文件路徑不對三是 Agent 的上下文窗口滿了讀不進去。排查順序先確認配置文件里路徑寫對了再確認文件確實存在且可讀最后檢查 Agent 的上下文使用情況。如果上下文滿了就精簡PROJECT.md或者拆成多個文件按需加載。我遇到過一次配置都對但 Agent 就是不讀。后來發(fā)現(xiàn)是文件編碼問題——PROJECT.md存成了 GBKAgent 按 UTF-8 讀讀出來是亂碼就跳過了。改成 UTF-8 之后正常。6.2 Agent 讀了但理解偏了有時候 Agent 確實讀了但理解和你預期不一樣。這通常是表述問題。比如你寫結果寫到 results/Agent 可能理解成結果可以寫到 results/ 也可以寫到別處。改成結果只能寫到 results/禁止寫到其他目錄就明確了。我的經(jīng)驗是約束性表述要用只能、禁止、必須這類強詞不要用建議、最好、可以這類弱詞。Agent 對強詞的遵循度明顯更高。6.3 多個 Agent 之間上下文不一致這是跨會話協(xié)作的經(jīng)典問題。Agent A 改了PROJECT.mdAgent B 還在用舊版本。解決辦法是把PROJECT.md納入版本控制每次修改都提交Agent 啟動時先拉最新版本。如果做不到版本控制至少要在PROJECT.md里加一個最后更新時間字段Agent 啟動時檢查這個時間如果太舊就提醒你更新。6.4 PROJECT.md 寫多長合適我的經(jīng)驗值是 500 到 1500 字。太短了信息不夠太長了 Agent 讀不完或者讀了后面忘前面。如果確實需要更多信息就拆文件。拆文件的邏輯是按使用頻率拆高頻信息放PROJECT.md低頻信息放docs/下的子文件。Agent 每次必讀PROJECT.md需要時再讀子文件。6.5 常見問題速查表問題現(xiàn)象可能原因排查方法解決方式Agent 不讀文件配置錯誤/路徑錯誤/編碼錯誤檢查配置、路徑、編碼修正配置統(tǒng)一 UTF-8Agent 理解偏差表述模糊檢查是否用了弱詞改用強約束詞跨會話不一致文件未同步檢查更新時間納入版本控制讀不完文件過長檢查字數(shù)拆分文件讀了沒用信息太泛檢查是否具體補充具體例子6.6 幾個我踩過的坑坑一把 PROJECT.md 寫成了日記。一開始我什么都往里寫包括每天的進展、遇到的問題、臨時想法。結果文件越來越長Agent 讀起來效率很低。后來我把日記部分拆出去PROJECT.md只保留結構化信息效果好多了?？佣烁?。有次項目階段變了我忘了更新PROJECT.mdAgent 還在按舊階段干活白跑了一輪。后來我養(yǎng)成了習慣每次項目階段變化第一件事就是更新PROJECT.md?？尤?guī)范寫得太死。有次我寫所有文件必須用 CSV 格式結果后來需要存 JSONAgent 就卡住了。規(guī)范要留余地寫默認用 CSV特殊需求可協(xié)商?？铀暮雎粤?Agent 的反饋。Agent 有時候會問PROJECT.md 里沒寫 XX我該怎么處理這其實是它在提醒你補充。我一開始忽略這些反饋后來發(fā)現(xiàn)這些正是PROJECT.md需要完善的地方。7. 進階讓 PROJECT.md 成為科研協(xié)作的中樞7.1 和版本控制結合把PROJECT.md納入 Git 管理每次修改都有記錄。這樣不僅能追溯變更還能讓多個 Agent 通過 Git 同步上下文。我現(xiàn)在的做法是PROJECT.md和代碼一起提交commit message 里注明更新項目上下文。7.2 和自動化流程結合如果你用 Jenkins 之類的工具做自動化可以在流水線里加一步檢查PROJECT.md是否存在、是否更新。如果項目階段變了但PROJECT.md沒更新就報警提醒。7.3 多項目場景下的管理如果你同時跑多個項目每個項目一個PROJECT.md。Agent 切換項目時先讀對應項目的PROJECT.md。我通常會在 Agent 配置里加一個項目切換命令一鍵加載對應上下文。7.4 團隊協(xié)作場景如果是團隊項目PROJECT.md就是團隊共識的載體。每個人都可以補充但要有審核機制。我建議指定一個人負責維護其他人提修改建議。這樣能保證文件的一致性和準確性。8. 我個人的幾點體會這套方法我用了大半年最大的感受是AI Agent 的能力上限很大程度上取決于你給它的上下文質量。同樣的 Agent喂飽了上下文和餓著肚子干活效果天差地別。PROJECT.md看起來只是個文檔但它實際上是人和 Agent 之間的接口。你把這個接口定義得越清晰Agent 就越能發(fā)揮價值。反過來如果你指望 Agent 自己猜那它猜錯的概率遠大于猜對。還有一個體會是寫 PROJECT.md 的過程其實也是梳理自己項目思路的過程。很多時候我以為自己想清楚了一寫才發(fā)現(xiàn)有漏洞。這個文件逼著我把項目結構、命名規(guī)范、數(shù)據(jù)流向都想明白對項目本身也是好事。最后分享一個小技巧如果你不知道怎么開始寫就先讓 Agent 幫你寫一版。你告訴它項目大概情況讓它生成PROJECT.md初稿然后你在它基礎上改。這樣起步快而且 Agent 寫的版本往往更符合它自己的閱讀習慣。