我一直觉得科研项目最难维护的其实不是代码也不是数据而是“上下文”。我做的一个调研项目前后拖了七个多月中间夹杂着文献整理、数据清洗、模型实验和论文初稿最长一次中断了三周。等我重新打开项目时看着自己写的数据处理函数居然要顺着源码一层层回想当初为什么这么设计。更难受的是我让AI助手接着之前的线索帮忙分析数据它完全接不上话——因为之前的会话早就被新对话顶掉了它对我的项目一无所知。后来我在项目根目录下固定放了两个文件AGENTS.md 和 PROJECT.md。AGENTS.md 负责持续给 AI 讲清楚“这是一个什么项目、你在我这里该按什么规矩干活”PROJECT.md 负责记录“项目现在走到哪一步、下一步要干什么”。这两个文件互相配合相当于给 AI 配了一份岗位说明也给我自己配了一块作战进度板。这篇文章就把我摸索出来的这套搭法、工作流和踩过的坑完整地拆开讲一遍。如果你也在用 AI 辅助做长周期的科研项目或者正被“AI 每次都要重新教一遍”的问题折磨这篇内容应该对你有用。1. 为什么说科研项目的上下文比代码更金贵1.1 长线科研项目的“三个月失忆症”代码至少还有个函数名、变量名可以顺着查科研项目里大量决定性的东西都存放在人的脑子里这个参数当初为什么这么设这批数据为什么被标记成异常这个实验方案在什么背景下被推翻的。这些话你在项目中期跟同事聊起来三分钟就能同步完。可一旦放了几周等你再回头连自己也记不清当时的判断依据了。我自己的项目就是一个典型例子。有一轮实验我调整了 prompt 策略把温度参数从 0.2 提到了 0.5跑完一批结果后就开始写下一阶段的代码。两周后我回来分析这批数据看着明显偏随机的结果觉得很奇怪翻了好久聊天记录才想起来“哦那批是故意测生成多样性的”。这类信息如果只存在于聊天记录和脑子里等于不存在。用 AI 辅助科研之后这个问题还会被放大。因为对话式 AI 本身是一种“强记忆、弱延续”的工作方式单次对话里它能记住你前面说的所有细节但你一旦新建会话或者过了几天它就把你的项目忘得一干二净。每次重新开始它都像一个全能但失忆的实习生得从头教一遍项目背景、术语、约定和当前进展。这种重复劳动消耗的不只是时间还有我对“AI 能不能真正接住一个长线项目”的信心。1.2 文件系统才是真正的“项目记忆体”后来我想明白一个道理对 AI 来说真正的长期记忆不应该放在聊天上下文里而应该放在项目自身的文件系统里。文件这个东西有几个天然优点随时可读、随时可改、可搜索、可版本管理。我不需要依赖某个 AI 产品的会话保存机制只要把该传承的信息写进文件AI 每次进入项目时先读这些文件就能快速回到“一个有经验的项目成员”状态。这也正是 AGENTS.md 和 PROJECT.md 各自承担的角色AGENTS.md 更像一张“岗位说明书”告诉 AI 它是谁、在这个项目里该做什么、不该做什么、偏好什么方式输出PROJECT.md 更像一张“作战地图”告诉 AI 项目目前打到了哪一关、敌人长什么样、我们之前踩过哪些坑。前者解决“你会怎么干活”后者解决“我们的现状是怎样的”。两者配合AI 不再是被我反复训话的临时工而是拿着工牌随时能上岗的自己人。有些人可能觉得“这不就是写文档吗我自己写个 Instructions 丢给它不就行了”说实话一开始我也是这么想的但真的把两个文件分开写、持续维护之后才发现里面的门道比想象中多。下面展开讲。2. 把 AGENTS.md 和 PROJECT.md 的分工边界整明白2.1 AGENTS.md给 AI 的岗位说明书AGENTS.md 这个名字来自 GitHub 和多家 AI 工具厂商近期的实践——约定俗成放在项目根目录的一个 Markdown 文件AI 助手进入项目时优先读取它。你可以把它理解成“给 AI 看的 README”只不过 README 是给人类开发者介绍项目用AGENTS.md 是给 AI 助手设定身份和行为准则用。我第一次写 AGENTS.md 时犯了一个错误几乎复制了一份完整的需求文档进去事无巨细地写了项目背景、专业术语、技术栈、甚至包括很具体的算法公式。结果 AI 读完这个文件后在回答里大量复读我写的背景显得又笨又啰嗦。后来我把 AGENTS.md 精简成了四个模块角色定位、项目背景摘要、行为规范、输出偏好。角色定位这一块最重要。我会明确写你在这个项目里不是通用助手而是“科研数据整理与实验文档协作者”你的首要任务是帮助我完成实验记录的清洗、结构化、前后对比而不是替我做研究决策。这样 AI 就不会在自己不擅长的地方强行发挥甚至在统计口径上自作主张。项目背景摘要不需要很长两三句话讲清楚“我们在研究什么话题、当前处在什么阶段、最需要注意什么点”就够。行为规范我写得非常细比如所有关键结论必须标明置信度不要在我没要求的情况下修改原始数据“我觉得”这种主观判断不能出现在结果里如果发现数据矛盾先列出矛盾点再给解释。这些规则看起来琐碎但放在 AGENTS.md 里等于给 AI 提前打了预防针省得每次都要啰嗦。2.2 PROJECT.md给人看的活文档PROJECT.md 则是另一类东西。它更像一个“项目作战日志”主要服务于人也间接服务于 AI。我在里面记录的是项目目前卡在哪个环节、本周完成了什么、哪些决定是临时的、哪些数据文件是最新的、下一步打算怎么走。写 PROJECT.md 不需要追求文学性甚至不需要完整的句子。我用得最多的是清单结构待办列表、完成情况、决策记录。每一条决策后面附带日期和原因。比如“2026-02-18把筛选阈值从 0.8 调整到 0.7因为小样本下 0.8 导致命中率过低。” 这种一句话记录等几周后回看时比翻十页实验记录都管用。有人可能会问这两个文件能不能合并成一个反正都是 Markdown写在一起不是更省事吗我一开始也是合并着写的后来发现不行。原因很简单读者不同。AGENTS.md 的读者是 AI它的语言必须偏向指令式、规则式甚至有点“啰嗦”——因为在长期对话里AI 确实需要被反复提醒边界。而 PROJECT.md 的读者是人类重点是快速扫一眼就知道项目现状如果混入大量“你该怎么做”的规则反而干扰阅读反之AI 在读取 AGENTS.md 时也会被项目状态信息干扰分不清哪些是任务指令、哪些是事实背景。这里我建议用一个直观的对比来把握两者的定位对比维度AGENTS.mdPROJECT.md主要读者AI 助手和人人偶尔被 AI 引用核心问题你在这个项目里怎么干活这个项目现在进展如何更新频率稳定规则想清楚就少改高频每次有进展/决策就更新内容风格指令式、规则式记录式、清单式典型的篇幅半页到一页 A4取决于项目阶段但越精简越好两个文件一个管“方式”一个管“现状”。把这两者解耦之后AI 的能力复用性和人的阅读体验都明显提升后面维护也轻松很多。3. 实操搭建一份可直接改用的模板3.1 从零搭 AGENTS.md把一个 AI 新人调教成项目熟手下面这份模板是我自己在科研项目里整理出来的去掉了具体项目内容你可以直接复制改成自己的版本。注意我不建议写得过长因为 AI 每次读取这个文件都要占上下文预算写得越精简留给实际任务的空间就越多。# AGENTS.md ## 角色定位 你是本项目的研究助理主要负责实验数据整理、文献信息检索、 文档结构化和前后对比分析。你不是决策者不对实验结论负责。 ## 项目背景 用 3-4 句话写明项目目标、当前阶段、关键约束。 ## 行为规范 1. 所有关键数字必须给出统计口径或来源不能凭空生成。 2. 对于不确定的判断必须标注“不确定”并说明原因。 3. 不要修改原始数据文件如需修改复制到新的文件再操作。 4. 遇到矛盾信息时先列出矛盾点再给出你的倾向性判断。 5. 回答问题时默认先根据 PROJECT.md 中的当前进展作答 如果 PROJECT.md 信息过时请明确指出。 ## 输出偏好 1. 实验对比结果用 Markdown 表格输出。 2. 重要结论放在答复最前面解释放在后面。 3. 一次性只给一个可执行的建议不要列五六个选项。 4. 不要输出与当前问题无关的背景介绍。这个模板写完之后我第一次把它交给 AI效果立竿见影。以前我让 AI“帮我看看这组数据”它会从数据格式、统计方法讲到可视化建议讲得天花乱坠但根本没接触我的数据现状。有了 AGENTS.md 后它会先打开 PROJECT.md 看我现在卡在哪再结合当前目录里的数据文件直接干活反馈质量明显不一样。有一点要注意AGENTS.md 里的规则不要写“你永远应该怎样怎样”这种过于绝对的话。AI 的指令遵循能力虽然有进步但在跨场景使用时规则越具体越容易执行。与其写“工作必须严谨”不如写“所有关键结论都要给出小数点后保留两位的来源说明”。越可检验、越具体AI 就越容易遵守。3.2 PROJECT.md 的活文档状态设计PROJECT.md 的搭建更简单但更需要设计“哪种信息值得记、哪种不值得记”。我目前的模板长这样# PROJECT.md ## 项目一句话 用一句话说明项目在做什么例如基于公开文献和实验数据 验证大模型在长文档摘要任务上的鲁棒性。 ## 当前里程碑 - 阶段 2正在进行完成异常值清洗开始第一批消融实验。 - 阶段 1已完成完成数据采集与格式标准化共 12 组。 ## 实验记录 | 日期 | 实验内容 | 关键参数 | 结果/备注 | | --- | --- | --- | --- | | 2026-02-14 | 基线模型摘要质量测试 | 温度0.2top_p0.9 | ROUGE-L 0.38偏保守 | | 2026-02-16 | 增加关键句约束提示 | 温度0.2top_p0.9 | ROUGE-L 0.41效果提升 | ## 决策记录 - 2026-02-16决定将温度固定在 0.2不再调高原因是调高后输出 不稳定给后续人工审校带来较大负担。 ## 下一步 - [ ] 完成消融实验第二组 - [ ] 整理异常值规则补充到代码注释中这个模板看着简单但有几个细节非常关键。第一“下一步”里的每一条待办要尽量写“完成标准”。比如不要只写“完成消融实验第二组”而要写“完成消融实验第二组并输出对比表和一句结论”。有了完成标准AI 才能帮你跟踪进度你自己回看时也知道做到什么程度算完。第二决策记录一定要附日期。没有日期的决策在回看时就是一条没有时间锚点的孤岛信息价值大打折扣。我见过很多人把 PROJECT.md 写成了“大而全的知识库”把相关论文笔记、代码注释、推理过程全部塞进去结果文档变成了一坨只能存档、不常更新的死文件。我的原则是PROJECT.md 只记录“现在和下一步”任何已经归档知识的内容一律挪到其他目录。它是一块进度板不是仓库。4. 长期维护的节奏让文件真正参与每一天的工作流4.1 我的一天AI 开晨会我做归档文件搭好之后真正让它起作用的不是一次性的“喂给 AI 看”而是融入每天的交互节奏。我的标配工作流大概是这样的早上一开始我会让 AI 先读 PROJECT.md 和 AGENTS.md然后问它“根据当前进度和下一步待办你觉得今天最应该推进哪一项先给出你的建议再说理由。”这一步相当于让 AI 做一次晨间同步它能快速把项目现状调取到对话上下文里比我在空白会话里从零描述高效得多。随后我在给它派活的时候也会刻意引用这两个文件。比如“按照 PROJECT.md 里的第二阶段计划帮我写这批数据的新清洗脚本清洗规则参考 AGENTS.md 里写的‘不要修改原始文件’那条。”这样 AI 收到的不是一个孤立请求而是带着项目上下文与既定约束的执行任务。它的产出自然就更贴项目实际。每天收工时我会花两三分钟更新 PROJECT.md把完成的事挪进实验记录表新产生的判断写进决策记录再调整下一步待办。有时候我懒得手打就把今天做的事情口述给 AI让它按照模板整理新版本我只要扫一眼确认没有跑偏就行。这里有个经验让 AI 更新文件前一定要给它明确指令“只改对应小节不要动其他内容”否则它偶尔会顺手重排整个文档结构反而制造混乱。4.2 文档腐化与每周十分钟的维护仪式长期项目最容易遇到的问题不是不写文档而是文档写完之后慢慢腐烂——内容过期没人改AI 引用过时的依赖路径自己回看时被旧信息误导。我自己的项目就发生过一次PROJECT.md 里还写着“依赖 Python 3.9”但我早就迁移到 3.11 环境了。AI 照猫画虎生成了一段用旧语法运行的脚本折腾半天才反应过来是文档没同步。我的解决方法是给文档设一个“每周十分钟维护仪式”。每周五我会专门打开这两个文件做三件事删掉过时的内容、更新本周新增的决策、重新审视 AGENTS.md 里的规则是否有需要调整的地方。这个仪式看起来简单但坚持执行以后两块文件的“可信度”大幅提升AI 和我自己都更愿意依赖它们。另外强烈建议把 AGENTS.md 和 PROJECT.md 纳入版本管理比如 Git。这样每次修改都会留下历史记录能比较不同版本间的差异。如果 AI 在帮你改文档时改坏了内容你也可以快速回滚。实际上我把这两个文件放在 Git 仓库根目录后还发现了一个额外的好处AI 可以通过git diff看到我自己的修改历史反过来推断出我偏好的文档风格后续它生成的更新版本会更贴合我的写法。5. 半年跑下来这套组合拳解决了我的哪些实际问题5.1 一次真实的“换工具”实验这套方法给我最大的惊喜来自一次“换工具”的体验。那阵子我把主力 AI 工具从 A 切换到 B本来担心上下文全部丢失毕竟之前好几轮有价值的对话都在 A 里B 一次都没参与过。结果我直接在 B 的项目会话里让它先读 AGENTS.md 和 PROJECT.md然后继续推进第二阶段任务。它读完文件后问了我两个澄清问题就直接接上了之前的进度产出质量跟 A 在深度对话后的状态几乎没差别。那一刻我才真正意识到这两个文件本质上是“工具无关”的知识资产。以前我把信息押注在聊天记录里等于把项目记忆交给某一个工具平台保管现在我把记忆放回项目本身任何 AI 工具只要能读 Markdown就能快速获得项目知识。这也让我对长期项目使用 AI 这件事放下了焦虑——我再也不用担心平台更新、会话丢失、模型切换这些外部因素的冲击。另一个我没想到的收获是它们降低了“项目交接”的成本。科研项目有时候需要别人接手以前我交接时得准备一个口头汇报加一堆聊天记录截图越讲越乱。现在直接把仓库和两个文件发过去对方扫完 PROJECT.md 的当前里程碑和决策记录基本就能了解项目七成以上的上下文。AGENTS.md 又能告诉对方团队你后续想让 AI 在项目里怎么配合。能少说很多废话。5.2 哪些边界别神化它当然这套双文件组合并不是什么银弹。我在实际使用中也确认了它的边界。第一它替代不了实验设计的思考能力。AGENTS.md 里再怎么规范 AI 的角色它仍然是一个上下文推理工具而不是真正的科研判断者。数据清洗规则、研究假设、实验对照方案这些核心决策必须由我本人做出文件只是把这些决策固化下来以便执行更高效。第二它不适合过碎、过一次性的事务。如果我只是临时问一个问题比如“这个包在 Python 里怎么调用”硬套一套 AGENTS.md 和 PROJECT.md 反而是成本过剩。这套东西的价值区间是长周期、多阶段、需要反复衔接的复杂项目而不是短平快的单次咨询。第三别把 PROJECT.md 写成论文或回忆录。它一旦变得冗长维护成本就会反噬使用意愿最后变成一个月更新一次的“僵尸文档”。我个人的底线是无论项目多复杂PROJECT.md 的核心部分要控制在几眼能扫完的篇幅里。想记录更细的内容那就另开 A 文件夹做扩展记录不要让主文档变成信息沼泽。说到底AGENTS.md 和 PROJECT.md 的搭配方式背后是一种非常朴素的思想把最容易被忽略的项目上下文用文件的形式外置出来让“人”和“AI”都能随时取用。对一个长线科研项目来说三个月后还能不能一眼看懂项目全貌决定了你的 AI 助手是真正替你减负还是每天陪你重复造轮子。我的答案是这套组合拳值得你投入那最初的半小时剩下的就是持续维护的小习惯。
用 AGENTS.md 与 PROJECT.md 为 AI 构建持久项目上下文
我一直觉得科研项目最难维护的其实不是代码也不是数据而是“上下文”。我做的一个调研项目前后拖了七个多月中间夹杂着文献整理、数据清洗、模型实验和论文初稿最长一次中断了三周。等我重新打开项目时看着自己写的数据处理函数居然要顺着源码一层层回想当初为什么这么设计。更难受的是我让AI助手接着之前的线索帮忙分析数据它完全接不上话——因为之前的会话早就被新对话顶掉了它对我的项目一无所知。后来我在项目根目录下固定放了两个文件AGENTS.md 和 PROJECT.md。AGENTS.md 负责持续给 AI 讲清楚“这是一个什么项目、你在我这里该按什么规矩干活”PROJECT.md 负责记录“项目现在走到哪一步、下一步要干什么”。这两个文件互相配合相当于给 AI 配了一份岗位说明也给我自己配了一块作战进度板。这篇文章就把我摸索出来的这套搭法、工作流和踩过的坑完整地拆开讲一遍。如果你也在用 AI 辅助做长周期的科研项目或者正被“AI 每次都要重新教一遍”的问题折磨这篇内容应该对你有用。1. 为什么说科研项目的上下文比代码更金贵1.1 长线科研项目的“三个月失忆症”代码至少还有个函数名、变量名可以顺着查科研项目里大量决定性的东西都存放在人的脑子里这个参数当初为什么这么设这批数据为什么被标记成异常这个实验方案在什么背景下被推翻的。这些话你在项目中期跟同事聊起来三分钟就能同步完。可一旦放了几周等你再回头连自己也记不清当时的判断依据了。我自己的项目就是一个典型例子。有一轮实验我调整了 prompt 策略把温度参数从 0.2 提到了 0.5跑完一批结果后就开始写下一阶段的代码。两周后我回来分析这批数据看着明显偏随机的结果觉得很奇怪翻了好久聊天记录才想起来“哦那批是故意测生成多样性的”。这类信息如果只存在于聊天记录和脑子里等于不存在。用 AI 辅助科研之后这个问题还会被放大。因为对话式 AI 本身是一种“强记忆、弱延续”的工作方式单次对话里它能记住你前面说的所有细节但你一旦新建会话或者过了几天它就把你的项目忘得一干二净。每次重新开始它都像一个全能但失忆的实习生得从头教一遍项目背景、术语、约定和当前进展。这种重复劳动消耗的不只是时间还有我对“AI 能不能真正接住一个长线项目”的信心。1.2 文件系统才是真正的“项目记忆体”后来我想明白一个道理对 AI 来说真正的长期记忆不应该放在聊天上下文里而应该放在项目自身的文件系统里。文件这个东西有几个天然优点随时可读、随时可改、可搜索、可版本管理。我不需要依赖某个 AI 产品的会话保存机制只要把该传承的信息写进文件AI 每次进入项目时先读这些文件就能快速回到“一个有经验的项目成员”状态。这也正是 AGENTS.md 和 PROJECT.md 各自承担的角色AGENTS.md 更像一张“岗位说明书”告诉 AI 它是谁、在这个项目里该做什么、不该做什么、偏好什么方式输出PROJECT.md 更像一张“作战地图”告诉 AI 项目目前打到了哪一关、敌人长什么样、我们之前踩过哪些坑。前者解决“你会怎么干活”后者解决“我们的现状是怎样的”。两者配合AI 不再是被我反复训话的临时工而是拿着工牌随时能上岗的自己人。有些人可能觉得“这不就是写文档吗我自己写个 Instructions 丢给它不就行了”说实话一开始我也是这么想的但真的把两个文件分开写、持续维护之后才发现里面的门道比想象中多。下面展开讲。2. 把 AGENTS.md 和 PROJECT.md 的分工边界整明白2.1 AGENTS.md给 AI 的岗位说明书AGENTS.md 这个名字来自 GitHub 和多家 AI 工具厂商近期的实践——约定俗成放在项目根目录的一个 Markdown 文件AI 助手进入项目时优先读取它。你可以把它理解成“给 AI 看的 README”只不过 README 是给人类开发者介绍项目用AGENTS.md 是给 AI 助手设定身份和行为准则用。我第一次写 AGENTS.md 时犯了一个错误几乎复制了一份完整的需求文档进去事无巨细地写了项目背景、专业术语、技术栈、甚至包括很具体的算法公式。结果 AI 读完这个文件后在回答里大量复读我写的背景显得又笨又啰嗦。后来我把 AGENTS.md 精简成了四个模块角色定位、项目背景摘要、行为规范、输出偏好。角色定位这一块最重要。我会明确写你在这个项目里不是通用助手而是“科研数据整理与实验文档协作者”你的首要任务是帮助我完成实验记录的清洗、结构化、前后对比而不是替我做研究决策。这样 AI 就不会在自己不擅长的地方强行发挥甚至在统计口径上自作主张。项目背景摘要不需要很长两三句话讲清楚“我们在研究什么话题、当前处在什么阶段、最需要注意什么点”就够。行为规范我写得非常细比如所有关键结论必须标明置信度不要在我没要求的情况下修改原始数据“我觉得”这种主观判断不能出现在结果里如果发现数据矛盾先列出矛盾点再给解释。这些规则看起来琐碎但放在 AGENTS.md 里等于给 AI 提前打了预防针省得每次都要啰嗦。2.2 PROJECT.md给人看的活文档PROJECT.md 则是另一类东西。它更像一个“项目作战日志”主要服务于人也间接服务于 AI。我在里面记录的是项目目前卡在哪个环节、本周完成了什么、哪些决定是临时的、哪些数据文件是最新的、下一步打算怎么走。写 PROJECT.md 不需要追求文学性甚至不需要完整的句子。我用得最多的是清单结构待办列表、完成情况、决策记录。每一条决策后面附带日期和原因。比如“2026-02-18把筛选阈值从 0.8 调整到 0.7因为小样本下 0.8 导致命中率过低。” 这种一句话记录等几周后回看时比翻十页实验记录都管用。有人可能会问这两个文件能不能合并成一个反正都是 Markdown写在一起不是更省事吗我一开始也是合并着写的后来发现不行。原因很简单读者不同。AGENTS.md 的读者是 AI它的语言必须偏向指令式、规则式甚至有点“啰嗦”——因为在长期对话里AI 确实需要被反复提醒边界。而 PROJECT.md 的读者是人类重点是快速扫一眼就知道项目现状如果混入大量“你该怎么做”的规则反而干扰阅读反之AI 在读取 AGENTS.md 时也会被项目状态信息干扰分不清哪些是任务指令、哪些是事实背景。这里我建议用一个直观的对比来把握两者的定位对比维度AGENTS.mdPROJECT.md主要读者AI 助手和人人偶尔被 AI 引用核心问题你在这个项目里怎么干活这个项目现在进展如何更新频率稳定规则想清楚就少改高频每次有进展/决策就更新内容风格指令式、规则式记录式、清单式典型的篇幅半页到一页 A4取决于项目阶段但越精简越好两个文件一个管“方式”一个管“现状”。把这两者解耦之后AI 的能力复用性和人的阅读体验都明显提升后面维护也轻松很多。3. 实操搭建一份可直接改用的模板3.1 从零搭 AGENTS.md把一个 AI 新人调教成项目熟手下面这份模板是我自己在科研项目里整理出来的去掉了具体项目内容你可以直接复制改成自己的版本。注意我不建议写得过长因为 AI 每次读取这个文件都要占上下文预算写得越精简留给实际任务的空间就越多。# AGENTS.md ## 角色定位 你是本项目的研究助理主要负责实验数据整理、文献信息检索、 文档结构化和前后对比分析。你不是决策者不对实验结论负责。 ## 项目背景 用 3-4 句话写明项目目标、当前阶段、关键约束。 ## 行为规范 1. 所有关键数字必须给出统计口径或来源不能凭空生成。 2. 对于不确定的判断必须标注“不确定”并说明原因。 3. 不要修改原始数据文件如需修改复制到新的文件再操作。 4. 遇到矛盾信息时先列出矛盾点再给出你的倾向性判断。 5. 回答问题时默认先根据 PROJECT.md 中的当前进展作答 如果 PROJECT.md 信息过时请明确指出。 ## 输出偏好 1. 实验对比结果用 Markdown 表格输出。 2. 重要结论放在答复最前面解释放在后面。 3. 一次性只给一个可执行的建议不要列五六个选项。 4. 不要输出与当前问题无关的背景介绍。这个模板写完之后我第一次把它交给 AI效果立竿见影。以前我让 AI“帮我看看这组数据”它会从数据格式、统计方法讲到可视化建议讲得天花乱坠但根本没接触我的数据现状。有了 AGENTS.md 后它会先打开 PROJECT.md 看我现在卡在哪再结合当前目录里的数据文件直接干活反馈质量明显不一样。有一点要注意AGENTS.md 里的规则不要写“你永远应该怎样怎样”这种过于绝对的话。AI 的指令遵循能力虽然有进步但在跨场景使用时规则越具体越容易执行。与其写“工作必须严谨”不如写“所有关键结论都要给出小数点后保留两位的来源说明”。越可检验、越具体AI 就越容易遵守。3.2 PROJECT.md 的活文档状态设计PROJECT.md 的搭建更简单但更需要设计“哪种信息值得记、哪种不值得记”。我目前的模板长这样# PROJECT.md ## 项目一句话 用一句话说明项目在做什么例如基于公开文献和实验数据 验证大模型在长文档摘要任务上的鲁棒性。 ## 当前里程碑 - 阶段 2正在进行完成异常值清洗开始第一批消融实验。 - 阶段 1已完成完成数据采集与格式标准化共 12 组。 ## 实验记录 | 日期 | 实验内容 | 关键参数 | 结果/备注 | | --- | --- | --- | --- | | 2026-02-14 | 基线模型摘要质量测试 | 温度0.2top_p0.9 | ROUGE-L 0.38偏保守 | | 2026-02-16 | 增加关键句约束提示 | 温度0.2top_p0.9 | ROUGE-L 0.41效果提升 | ## 决策记录 - 2026-02-16决定将温度固定在 0.2不再调高原因是调高后输出 不稳定给后续人工审校带来较大负担。 ## 下一步 - [ ] 完成消融实验第二组 - [ ] 整理异常值规则补充到代码注释中这个模板看着简单但有几个细节非常关键。第一“下一步”里的每一条待办要尽量写“完成标准”。比如不要只写“完成消融实验第二组”而要写“完成消融实验第二组并输出对比表和一句结论”。有了完成标准AI 才能帮你跟踪进度你自己回看时也知道做到什么程度算完。第二决策记录一定要附日期。没有日期的决策在回看时就是一条没有时间锚点的孤岛信息价值大打折扣。我见过很多人把 PROJECT.md 写成了“大而全的知识库”把相关论文笔记、代码注释、推理过程全部塞进去结果文档变成了一坨只能存档、不常更新的死文件。我的原则是PROJECT.md 只记录“现在和下一步”任何已经归档知识的内容一律挪到其他目录。它是一块进度板不是仓库。4. 长期维护的节奏让文件真正参与每一天的工作流4.1 我的一天AI 开晨会我做归档文件搭好之后真正让它起作用的不是一次性的“喂给 AI 看”而是融入每天的交互节奏。我的标配工作流大概是这样的早上一开始我会让 AI 先读 PROJECT.md 和 AGENTS.md然后问它“根据当前进度和下一步待办你觉得今天最应该推进哪一项先给出你的建议再说理由。”这一步相当于让 AI 做一次晨间同步它能快速把项目现状调取到对话上下文里比我在空白会话里从零描述高效得多。随后我在给它派活的时候也会刻意引用这两个文件。比如“按照 PROJECT.md 里的第二阶段计划帮我写这批数据的新清洗脚本清洗规则参考 AGENTS.md 里写的‘不要修改原始文件’那条。”这样 AI 收到的不是一个孤立请求而是带着项目上下文与既定约束的执行任务。它的产出自然就更贴项目实际。每天收工时我会花两三分钟更新 PROJECT.md把完成的事挪进实验记录表新产生的判断写进决策记录再调整下一步待办。有时候我懒得手打就把今天做的事情口述给 AI让它按照模板整理新版本我只要扫一眼确认没有跑偏就行。这里有个经验让 AI 更新文件前一定要给它明确指令“只改对应小节不要动其他内容”否则它偶尔会顺手重排整个文档结构反而制造混乱。4.2 文档腐化与每周十分钟的维护仪式长期项目最容易遇到的问题不是不写文档而是文档写完之后慢慢腐烂——内容过期没人改AI 引用过时的依赖路径自己回看时被旧信息误导。我自己的项目就发生过一次PROJECT.md 里还写着“依赖 Python 3.9”但我早就迁移到 3.11 环境了。AI 照猫画虎生成了一段用旧语法运行的脚本折腾半天才反应过来是文档没同步。我的解决方法是给文档设一个“每周十分钟维护仪式”。每周五我会专门打开这两个文件做三件事删掉过时的内容、更新本周新增的决策、重新审视 AGENTS.md 里的规则是否有需要调整的地方。这个仪式看起来简单但坚持执行以后两块文件的“可信度”大幅提升AI 和我自己都更愿意依赖它们。另外强烈建议把 AGENTS.md 和 PROJECT.md 纳入版本管理比如 Git。这样每次修改都会留下历史记录能比较不同版本间的差异。如果 AI 在帮你改文档时改坏了内容你也可以快速回滚。实际上我把这两个文件放在 Git 仓库根目录后还发现了一个额外的好处AI 可以通过git diff看到我自己的修改历史反过来推断出我偏好的文档风格后续它生成的更新版本会更贴合我的写法。5. 半年跑下来这套组合拳解决了我的哪些实际问题5.1 一次真实的“换工具”实验这套方法给我最大的惊喜来自一次“换工具”的体验。那阵子我把主力 AI 工具从 A 切换到 B本来担心上下文全部丢失毕竟之前好几轮有价值的对话都在 A 里B 一次都没参与过。结果我直接在 B 的项目会话里让它先读 AGENTS.md 和 PROJECT.md然后继续推进第二阶段任务。它读完文件后问了我两个澄清问题就直接接上了之前的进度产出质量跟 A 在深度对话后的状态几乎没差别。那一刻我才真正意识到这两个文件本质上是“工具无关”的知识资产。以前我把信息押注在聊天记录里等于把项目记忆交给某一个工具平台保管现在我把记忆放回项目本身任何 AI 工具只要能读 Markdown就能快速获得项目知识。这也让我对长期项目使用 AI 这件事放下了焦虑——我再也不用担心平台更新、会话丢失、模型切换这些外部因素的冲击。另一个我没想到的收获是它们降低了“项目交接”的成本。科研项目有时候需要别人接手以前我交接时得准备一个口头汇报加一堆聊天记录截图越讲越乱。现在直接把仓库和两个文件发过去对方扫完 PROJECT.md 的当前里程碑和决策记录基本就能了解项目七成以上的上下文。AGENTS.md 又能告诉对方团队你后续想让 AI 在项目里怎么配合。能少说很多废话。5.2 哪些边界别神化它当然这套双文件组合并不是什么银弹。我在实际使用中也确认了它的边界。第一它替代不了实验设计的思考能力。AGENTS.md 里再怎么规范 AI 的角色它仍然是一个上下文推理工具而不是真正的科研判断者。数据清洗规则、研究假设、实验对照方案这些核心决策必须由我本人做出文件只是把这些决策固化下来以便执行更高效。第二它不适合过碎、过一次性的事务。如果我只是临时问一个问题比如“这个包在 Python 里怎么调用”硬套一套 AGENTS.md 和 PROJECT.md 反而是成本过剩。这套东西的价值区间是长周期、多阶段、需要反复衔接的复杂项目而不是短平快的单次咨询。第三别把 PROJECT.md 写成论文或回忆录。它一旦变得冗长维护成本就会反噬使用意愿最后变成一个月更新一次的“僵尸文档”。我个人的底线是无论项目多复杂PROJECT.md 的核心部分要控制在几眼能扫完的篇幅里。想记录更细的内容那就另开 A 文件夹做扩展记录不要让主文档变成信息沼泽。说到底AGENTS.md 和 PROJECT.md 的搭配方式背后是一种非常朴素的思想把最容易被忽略的项目上下文用文件的形式外置出来让“人”和“AI”都能随时取用。对一个长线科研项目来说三个月后还能不能一眼看懂项目全貌决定了你的 AI 助手是真正替你减负还是每天陪你重复造轮子。我的答案是这套组合拳值得你投入那最初的半小时剩下的就是持续维护的小习惯。
