1. 科研场景下 AI Agent 的真实困境

1.1 从“能跑”到“跑对”之间隔了什么

我最早把 AI Agent 引入科研工作流，是在处理一批材料计算数据的时候。当时的需求很朴素：让 Agent 帮我读一批结构文件，提取关键参数，按指定格式汇总成表格。第一次跑，结果看起来挺像那么回事，格式整齐，字段齐全。但我随手抽查了三条，就发现其中一条把晶格常数的单位从埃换成了纳米却没标注，另一条把两个相似结构的编号搞混了。如果我没有抽查，这份表格就会直接进入后续分析，错误会被放大到整个结论里。

这件事让我意识到一个核心问题：AI Agent 在科研场景里，最大的风险不是“跑不起来”，而是“跑起来了但跑错了，而且错得很隐蔽”。科研工作和普通的内容生成任务有本质区别，它对可追溯性、可复现性、边界明确性的要求极高。一个写作助手把“大约”写成“大概”，无伤大雅；但一个科研 Agent 把对照组和处理组的标签弄反，整篇论文的结论就废了。

那怎么解决？我试过很多办法。在对话里反复强调“注意单位”“注意编号”，效果不稳定，因为每次新开一个会话，上下文就重置了。把要求写进系统提示词，稍微好一点，但系统提示词一长，Agent 的注意力就会被稀释，而且不同工具对系统提示词的支持程度不一样。后来我逐渐收敛到一个方案：用项目文档 PROJECT.md 作为 Agent 的“科研规范说明书”，把那些不能出错、不能含糊的约束，从对话里搬到文档里，让 Agent 每次执行任务前先读这份文档。

1.2 为什么是 PROJECT.md 而不是别的

你可能会问，为什么偏偏是 PROJECT.md，而不是 README.md、AGENTS.md 或者别的什么文件？这个问题我认真想过，也实际对比过几种方案。

README.md 的定位是“给人看的项目说明”，它通常包含项目背景、安装步骤、使用方法。这些内容对 Agent 也有用，但它的组织方式是为人类阅读优化的，不是为 Agent 执行优化的。人类可以跳读、可以凭经验补全缺失信息，Agent 不行，它需要的是明确的指令、清晰的边界、可枚举的规则。

AGENTS.md 更接近我想要的，它本身就是为 Agent 设计的上下文文件。但在科研场景里，我发现单纯一个 AGENTS.md 还不够。科研项目往往有多个层次的信息：项目级别的总体目标、子任务级别的具体规范、数据级别的格式要求、输出级别的验收标准。这些信息如果全塞进一个文件，会变得臃肿；如果分散到多个文件，又需要一套组织逻辑。

PROJECT.md 在我的实践里扮演的是总纲的角色。它不追求覆盖所有细节，而是明确三件事：这个项目要解决什么问题、Agent 在项目中承担什么角色、以及 Agent 必须遵守哪些硬性约束。具体的任务指令可以放在单独的 AGENTS.md 或任务描述里，但 PROJECT.md 是每次会话开始时 Agent 必须先读的那一份。它就像实验室墙上的安全守则，不涉及具体实验步骤，但每个进实验室的人都要先看一遍。

1.3 这套方案适合什么样的科研工作

不是所有科研任务都值得上这套方案。如果你只是让 Agent 帮你查一篇文献的摘要，或者翻译一段英文，那直接对话就够了，没必要搞项目文档。但如果你面对的是以下场景，PROJECT.md 的价值就会非常明显：

• 多步骤、长周期的任务：比如从原始数据清洗到最终图表生成，中间有十几个环节，每个环节都有格式要求。
• 多人协作或多次复现的任务：你需要保证不同时间、不同人跑出来的结果是一致的。
• 对错误零容忍的任务：比如涉及数值计算、统计分析、实验对照的任务，一个标签错误就可能导致结论反转。
• 需要频繁切换 Agent 工具的任务：今天用这个，明天用那个，你不想每次重新交代一遍规则。

我自己的经验是，当一个科研任务的步骤超过五步，或者需要我反复向 Agent 解释同一件事超过两次，我就会停下来，先写一份 PROJECT.md。这个投入通常在半小时以内，但省下来的沟通成本和纠错成本，往往是十倍以上。

2. PROJECT.md 的核心结构与编写逻辑

2.1 一份合格的科研 PROJECT.md 应该包含什么

我见过不少 PROJECT.md，有的写得像散文，有的写得像代码注释，有的干脆就是把 README 改了个名字。这些都不是我想要的。经过多次迭代，我目前使用的 PROJECT.md 模板包含五个核心模块，每个模块都有明确的编写目的。

项目目标模块回答的是“我们在做什么”。这部分要写得足够具体，具体到 Agent 能判断一个任务是否属于项目范围。比如“分析一批材料的力学性能”就太模糊，“从给定的 200 个结构文件中提取弹性常数，按指定格式汇总，并标记异常值”就清晰得多。Agent 读到前者，可能会去帮你查文献；读到后者，它就知道自己的边界在哪里。

Agent 角色模块回答的是“你是谁，你负责什么”。科研项目里，Agent 可能扮演数据清洗员、代码生成器、结果校验员等不同角色。明确角色不是为了限制 Agent 的能力，而是为了让它知道在什么阶段应该以什么身份行事。我通常会在这一节里写清楚：Agent 在本项目中不负责提出科学假设，不负责解释结果的物理意义，只负责按规范执行数据处理和格式转换。这条边界非常重要，它防止 Agent 越界给出看似合理但未经证实的科学判断。

硬性约束模块是整份文档里最不能含糊的部分。单位、精度、命名规则、文件编码、缺失值处理方式，这些都要一条一条列清楚。我习惯用“必须”“禁止”“一律”这样的词，不用“建议”“尽量”“最好”。Agent 对模糊词的理解是不稳定的，你写“尽量保留两位小数”，它可能在某些情况下保留三位，在某些情况下保留一位。你写“一律保留两位小数，第三位四舍五入”，它的行为就稳定得多。

任务流程模块描述的是标准操作流程。这部分不需要写得像菜谱那么细，但关键节点和检查点要明确。比如“数据读取后先检查行数和列数是否与预期一致”“计算完成后随机抽取 5% 的样本进行人工复核”。这些检查点看起来是给 Agent 的指令，实际上也是给我自己的提醒，让我知道在哪些环节需要介入。

输出规范模块规定的是最终交付物的格式。文件命名、目录结构、表格列名、图表尺寸、颜色方案，这些都要写清楚。科研工作的输出往往要进入论文或报告，格式不统一会带来大量返工。我吃过这个亏，所以现在会把输出规范写得非常细，细到“表格第一列是样本编号，第二列是数值，第三列是单位，列名用英文，首字母大写”。

2.2 为什么这些模块的顺序不能乱

这五个模块的顺序不是随便排的。它遵循的是从抽象到具体、从目标到执行的逻辑。Agent 读文档的方式和人类不一样，它不会跳读，也不会凭经验补全。如果顺序乱了，它可能会在还没理解项目目标的情况下就看到了具体的输出格式要求，然后机械地按格式生成内容，却忽略了内容本身是否符合项目目标。

我做过一个对比实验。同样的内容，一份按“目标-角色-约束-流程-输出”排列，一份按“输出-流程-约束-角色-目标”排列，让 Agent 执行同一个任务。前者的结果明显更符合预期，后者虽然格式正确，但在几个关键判断上出现了偏差。这个实验样本很小，不能说明普遍规律，但至少在我的场景里，顺序是有影响的。

另一个经验是，硬性约束模块要放在任务流程之前。因为流程是“怎么做”，约束是“什么不能做”。先让 Agent 知道红线在哪里，再让它去执行步骤，比反过来更安全。就像教学生做实验，先讲安全规范，再讲操作步骤，顺序反了容易出事。

2.3 一个真实的 PROJECT.md 片段

下面是我在一个数据处理项目中实际使用的 PROJECT.md 片段，隐去了具体项目信息，保留了结构和写法。你可以直接参考这个格式，替换成你自己的内容。

# PROJECT.md ## 项目目标 从给定的结构文件中提取力学参数，按指定格式汇总为 CSV 文件， 并标记出数值异常或缺失的样本。不进行任何物理意义层面的解释。 ## Agent 角色 你是一个数据提取与格式转换助手。你不负责判断数据的科学合理性， 不负责提出假设，不负责解释结果。遇到无法确定的情况，停止操作并 向用户提问，不要自行猜测。 ## 硬性约束 - 长度单位一律使用埃，保留 4 位小数。 - 能量单位一律使用电子伏特，保留 6 位小数。 - 样本编号必须与原始文件名一致，不得修改大小写或添加前缀。 - 缺失值一律填写 NA，不得留空，不得填 0。 - 所有输出文件使用 UTF-8 编码，换行符使用 LF。 ## 任务流程 1. 读取指定目录下所有 .cif 文件。 2. 检查文件数量是否与预期一致，不一致则停止并报告。 3. 逐个提取参数，每处理 10 个文件暂停一次，报告进度。 4. 汇总为 CSV，按样本编号排序。 5. 随机抽取 5% 的样本，与原始文件比对，报告比对结果。 ## 输出规范 - 输出文件命名为 result_YYYYMMDD.csv。 - 第一列为 sample_id，第二列为 lattice_constant，第三列为 energy。 - 列名使用英文，首字母小写，下划线分隔。 - 数值列不得包含单位符号，单位在 PROJECT.md 中统一约定。

这份文档不长，但信息密度很高。Agent 读完它，基本不会在单位、格式、命名这些低级问题上犯错。剩下的精力就可以放在真正的数据处理上。

3. 把 PROJECT.md 接入不同 Agent 工具的实操细节

3.1 不同工具对项目文档的读取方式差异

PROJECT.md 本身是一个纯文本文件，但不同 Agent 工具读取它的方式不一样，这直接影响你的使用体验。我目前主要用两类工具：一类是命令行式的 Agent，一类是编辑器集成的 Agent。它们的读取逻辑有区别，需要分别处理。

命令行式 Agent 通常需要你显式指定上下文文件。比如在启动任务时，把 PROJECT.md 的路径作为参数传进去，或者在任务描述里写明“先读取 PROJECT.md”。这种方式的优点是控制精确，你知道 Agent 读了什么；缺点是每次都要记得传，容易忘。我的做法是在项目根目录放一个固定的启动脚本，把读取 PROJECT.md 作为第一步固定下来，这样就不依赖记忆了。

编辑器集成的 Agent 通常会自动读取项目根目录下的特定文件。不同的工具认的文件名不一样，有的认 AGENTS.md，有的认 PROJECT.md，有的两者都认。你需要查一下你用的工具支持哪些文件名。如果不支持 PROJECT.md，有两个办法：一是把 PROJECT.md 的内容复制到它支持的文件里，二是用符号链接把 PROJECT.md 链接到它认的文件名。我一般用第一种，因为符号链接在某些系统上会有兼容性问题。

还有一个细节是读取时机。有些工具是在会话开始时读一次，之后就不再读了；有些工具是每次任务执行前都读。前者适合内容稳定的项目文档，后者适合需要频繁调整约束的场景。我在项目初期会用后者，因为约束经常要改；等项目稳定了，就换成前者，减少不必要的读取开销。

3.2 上下文窗口有限时怎么取舍

这是很多人会遇到的问题：PROJECT.md 写得太详细，加上任务描述和实际数据，上下文窗口就不够用了。Agent 要么报错，要么开始“遗忘”前面的内容。我试过几种应对策略，各有适用场景。

策略一：分层文档。把 PROJECT.md 拆成核心版和完整版。核心版只保留硬性约束和输出规范，放在项目根目录，每次必读。完整版包含项目背景、详细流程、示例，放在子目录里，只在需要时读取。这样上下文占用小，关键信息又不丢失。

策略二：约束前置。如果只能读一份文档，就把最重要的约束放在文档最前面。Agent 对文档开头的注意力通常比中间和结尾高。我把单位、精度、命名规则这些放在最前面，把项目背景放在最后面。实测下来，这样能减少不少低级错误。

策略三：动态裁剪。对于特别长的项目文档，我会根据当前任务类型，只把相关章节喂给 Agent。比如做数据提取时，只给约束和流程；做结果汇总时，只给输出规范。这需要手动操作，麻烦一点，但上下文利用率最高。

提示：不要为了省上下文而删掉硬性约束。约束是底线，底线不能省。要省就省项目背景和示例，那些是锦上添花的内容。

3.3 让 Agent 主动确认而不是被动执行

这是我踩过坑之后养成的一个习惯：在 PROJECT.md 里加一条规则，要求 Agent 在执行任务前，先用自己的话复述一遍关键约束，并确认理解无误。这条规则看起来多余，但实际效果很好。

有一次我让 Agent 处理一批数据，约束里写了“缺失值填 NA”。Agent 执行到一半，遇到一个缺失值，它填了“N/A”。这两个写法在人类看来差不多，但在后续的自动化处理里，“N/A”和“NA”会被当成两个不同的值，导致统计出错。如果 Agent 在开始前复述了约束，我就能及时发现它把“NA”理解成了“N/A”，避免后面的返工。

复述确认还有一个好处：它能暴露 Agent 对约束的理解偏差。有些偏差不是字面上的，而是语义上的。比如你写“保留两位小数”，Agent 可能理解为“截断到两位”而不是“四舍五入到两位”。复述的时候它说“我会把数值截断到两位小数”，你就能立刻纠正。

我通常会在 PROJECT.md 的末尾加一段：

## 执行前确认 在开始任何任务前，请先复述以下内容： 1. 本项目的核心目标是什么。 2. 你扮演什么角色，不负责什么。 3. 列出三条你认为最重要的硬性约束。 4. 你计划如何执行任务流程。 复述完成后，等待用户确认再开始。

这段确认流程会增加一点交互成本，但比起事后纠错，这点成本完全可以接受。

4. 科研场景下的常见问题与排查实录

4.1 Agent 忽略约束的几种典型情况

即使写了 PROJECT.md，Agent 也不是百分之百遵守约束。我总结了几种最常见的情况，以及对应的排查思路。

情况一：约束太多，Agent 记不住。这是最常见的。一份 PROJECT.md 里列了二十条约束，Agent 执行到后面就忘了前面的。解决办法是分级：把约束分成“必须遵守”和“尽量遵守”两类，必须遵守的用加粗或单独章节标出，数量控制在五条以内。超过五条，Agent 的遵守率就会明显下降。

情况二：约束之间有冲突。比如一条约束说“所有数值保留两位小数”，另一条说“能量值保留六位小数”。Agent 遇到能量值时，不知道该听哪条。解决办法是明确优先级：在文档里写明“特殊约束优先于通用约束”，或者干脆把通用约束改成“除能量值外，所有数值保留两位小数”。

情况三：约束表述有歧义。比如“按样本编号排序”，Agent 可能按字符串排序，也可能按数值排序。如果编号是“1, 2, 10”，字符串排序会得到“1, 10, 2”，数值排序会得到“1, 2, 10”。解决办法是消除歧义：写明“按样本编号的数值大小排序，编号中的数字部分转为整数后比较”。

情况四：Agent 在长任务中“遗忘”约束。任务步骤多、耗时长的时候，Agent 可能会在中间某个环节偏离约束。解决办法是设置检查点：在流程的关键节点要求 Agent 重新确认约束。比如“每处理 50 个样本，重新阅读硬性约束章节，确认当前操作符合要求”。

4.2 数据格式问题的排查清单

数据格式问题是科研 Agent 最容易出错的地方，也是排查起来最耗时的。我整理了一份速查表，遇到格式问题时按顺序排查。

这张表我放在手边，遇到问题就对照着查。大部分格式问题都能在前三行找到原因。

4.3 当 Agent 给出“看起来对但实际错”的结果时

这是最危险的情况。Agent 的输出格式完美、数值合理、逻辑自洽，但就是错的。我遇到过几次，每次都是靠交叉验证发现的。

一次是 Agent 汇总了一批计算结果，数值都在合理范围内，但总数对不上。我让它重新计算，它给出了同样的结果。后来我手动抽查了原始数据，发现它在读取某个文件时跳过了第一行，而第一行恰好是有效数据。这个错误不会导致数值异常，只会导致样本数少一个。如果我没有核对样本总数，这个错误就会一直隐藏下去。

从那以后，我在 PROJECT.md 里加了一条硬性约束：任何汇总操作，必须报告输入样本数和输出样本数，两者不一致时停止并报告。这条约束帮我拦住了好几次类似的问题。

交叉验证的另一个方法是换一种方式算一遍。比如 Agent 用 Python 算了一遍，我让它用另一种方法再算一遍，对比结果。如果两种方法结果一致，可信度就高很多；如果不一致，就说明至少有一种方法有问题。这个方法费时间，但对于关键数据，值得。

注意：不要因为 Agent 连续几次结果正确就放松警惕。错误往往是偶发的，连续正确不代表下一次也正确。关键数据永远要交叉验证。

4.4 多 Agent 协作时的文档同步问题

当一个项目里用了多个 Agent，或者同一个 Agent 在不同任务间切换时，PROJECT.md 的同步就成了问题。我遇到过的情况是：我更新了 PROJECT.md 里的约束，但某个 Agent 还在用旧版本的约束执行任务，导致输出格式不一致。

解决办法是版本化。在 PROJECT.md 的开头加一个版本号和更新日期，每次修改都更新版本号。然后在任务描述里要求 Agent 报告它读取的 PROJECT.md 版本号。如果版本号对不上，就说明有 Agent 用了旧文档。

# PROJECT.md 版本：v1.3 更新日期：2026-01-15 更新内容：修改了能量值的精度要求，从 4 位改为 6 位。

另一个办法是单一来源。所有 Agent 都从同一个路径读取 PROJECT.md，不复制、不转发。这样只要更新了源文件，所有 Agent 下次读取时都会拿到最新版本。复制转发是版本不一致的主要来源，能避免就避免。

5. 从 PROJECT.md 到完整科研 Agent 工作流

5.1 项目文档只是起点

PROJECT.md 解决了“Agent 知道什么”的问题，但没有解决“Agent 怎么执行”的问题。一个完整的科研 Agent 工作流，还需要任务分解、工具调用、结果校验这几个环节。PROJECT.md 是这些环节的共同基础，但它本身不构成工作流。

我的做法是：PROJECT.md 定义静态规则，任务描述定义动态指令，两者配合使用。PROJECT.md 里写的是“所有数值保留两位小数”，任务描述里写的是“请处理 data 目录下的文件，输出到 result.csv”。Agent 先读 PROJECT.md 建立规则意识，再读任务描述执行具体操作。

这种分离的好处是复用性。同一份 PROJECT.md 可以配合不同的任务描述，处理不同的数据。我不需要每次都在任务描述里重复单位、精度、命名规则，只需要写清楚这次要做什么。任务描述可以很短，PROJECT.md 保持稳定。

5.2 任务分解的粒度控制

任务分解的粒度是个经验活。分得太粗，Agent 容易跑偏；分得太细，交互次数太多，效率低。我的经验是按检查点分解：每个子任务结束时，应该有一个可以验证的输出。比如“读取文件”是一个子任务，输出是文件列表和样本数；“提取参数”是一个子任务，输出是原始参数表；“格式转换”是一个子任务，输出是符合规范的 CSV。

每个子任务结束后，我会让 Agent 报告结果，我快速检查一下，确认无误再进入下一个子任务。这样虽然交互次数多了，但错误能在早期被发现，不会累积到最后。科研工作里，早期发现一个错误，比后期返工的成本低得多。

对于特别长的任务，我会在 PROJECT.md 里预设自动检查点。比如“每处理 100 个样本，自动暂停并报告进度和已处理样本的统计摘要”。这样即使我不在旁边，Agent 也会在关键节点停下来，留下检查痕迹。

5.3 结果校验的自动化思路

人工校验费时间，而且容易疲劳。我尝试把一些常规校验自动化，让 Agent 自己完成，我只做最终抽查。

常规校验包括：样本数是否一致、数值范围是否合理、缺失值比例是否正常、格式是否符合规范。这些校验可以写成脚本，也可以写成 Agent 的指令。我倾向于写成 Agent 的指令，因为脚本需要维护，而指令跟着 PROJECT.md 走，改起来方便。

比如在 PROJECT.md 里加一段：

## 自动校验规则 每次生成输出文件后，自动执行以下校验： 1. 输出样本数是否等于输入样本数，不等则报告差异。 2. 数值列的最小值和最大值是否在合理范围内，超出则标记。 3. 缺失值比例是否超过 5%，超过则报告。 4. 文件编码是否为 UTF-8，换行符是否为 LF。 校验结果附在输出文件末尾，或单独生成校验报告。

这段规则让 Agent 在交付结果前先自己检查一遍。我拿到结果后，只需要看校验报告，确认没有异常，就可以进入下一步。这比我自己从头检查快得多。

5.4 长期项目的文档维护节奏

科研项目往往持续几个月甚至几年，PROJECT.md 需要跟着项目演进。我的维护节奏是：项目初期频繁更新，项目中期稳定更新，项目后期冻结更新。

初期，约束和流程都在摸索，可能一周改好几次。这时候我会在文档里标注“草稿”状态，提醒自己和其他协作者，规则可能随时变。中期，主要流程稳定了，只有细节调整，可能一个月改一次。后期，项目进入收尾阶段，文档冻结，不再修改，保证结果的可复现性。

每次更新 PROJECT.md，我都会在版本记录里写清楚改了什么、为什么改。这不是为了形式，而是为了可追溯。半年后回头看，我能知道当时为什么把精度从 4 位改成 6 位，是因为发现了什么数据问题，还是因为合作方提出了新要求。这些信息在写论文的方法部分时很有用。

提示：PROJECT.md 的版本记录不要写得太简略。“修改了精度要求”不如“将能量值精度从 4 位小数改为 6 位小数，原因是合作方提供的参考数据精度为 6 位，4 位会导致对比时出现舍入误差”。后者在半年后看仍然有意义。

6. 我踩过的坑和总结出的经验

6.1 不要试图用 PROJECT.md 解决所有问题

我一开始犯的错误是把 PROJECT.md 写得太长，恨不得把所有可能的情况都覆盖到。结果文档超过三千字，Agent 读起来吃力，遵守率反而下降。后来我明白了，PROJECT.md 的作用是建立规则意识，不是穷举所有情况。遇到文档没覆盖的情况，Agent 应该停下来问，而不是自己猜。所以我在文档里加了一条：“遇到 PROJECT.md 未明确规定的操作，停止执行并向用户提问，不要自行决定。”这条规则比多写一千字的细节更有效。

6.2 约束要可验证，不要写“注意”“小心”这类词

“注意单位统一”这种约束，Agent 没法执行，因为它不知道什么叫“注意”。可验证的约束是“所有长度值以埃为单位，保留 4 位小数，写入 CSV 时不含单位符号”。后者 Agent 可以逐条检查，前者只能靠自觉。科研场景里，靠自觉是靠不住的，要靠规则。

6.3 给 Agent 留出“不确定”的出口

科研数据经常有模糊地带，比如某个文件的格式和预期不符，某个数值处于正常范围的边缘。这时候如果 Agent 强行处理，可能引入错误。我在 PROJECT.md 里明确写了：“遇到不确定的情况，标记为待确认，不要自行处理，在输出中单独列出。”这样我拿到结果时，能清楚知道哪些地方需要人工判断，而不是被 Agent 的“自信”误导。

6.4 定期回顾 PROJECT.md 的实际执行效果

文档写了不等于执行了。我会定期抽查 Agent 的输出，对照 PROJECT.md 的约束，看哪些约束被遵守了，哪些被忽略了。被忽略的约束，要么是写得不清楚，要么是不重要。不清楚的就改清楚，不重要的就删掉。文档不是越长越好，而是越有效越好。

我现在的 PROJECT.md 通常控制在八百到一千字，包含五到八条硬性约束，三到五个流程步骤，以及输出规范。这个规模 Agent 读起来不费力，遵守率也高。超过这个规模，我就会考虑拆分，把不常用的内容移到子文档里。

6.5 一个让我印象深刻的教训

有一次我处理一批实验数据，PROJECT.md 里写了“缺失值填 NA”。Agent 执行时，遇到一个缺失值，它填了“na”。我当时没注意，直接进入了下一步分析。分析脚本里判断缺失值的条件是“== 'NA'”，小写的“na”没被识别，被当成了有效值参与计算。结果那个样本的统计值偏离了正常范围，我花了大半天才定位到问题。

从那以后，我在约束里写缺失值时，会写“填大写 NA，两个字符，不含引号”。同时，在自动校验规则里加一条“检查缺失值字段是否全部为大写 NA”。这个教训让我明白，约束的精确度直接决定结果的可靠性。在科研场景里，一个字符的大小写都可能影响结论。

7. 这套方法还能怎么扩展

7.1 从单项目到多项目的文档体系

当一个实验室或一个团队有多个项目时，PROJECT.md 可以进一步组织成体系。我的做法是：每个项目有自己的 PROJECT.md，同时有一个团队级别的 PROJECT.base.md，包含所有项目共通的约束，比如编码规范、文件命名规范、数据安全规范。每个项目的 PROJECT.md 继承 base 的内容，再补充项目特有的约束。

这样新项目启动时，不需要从零写 PROJECT.md，只需要在 base 的基础上补充差异部分。维护成本降低了，规范的一致性也提高了。

7.2 把 PROJECT.md 和自动化脚本结合

PROJECT.md 里的自动校验规则，可以进一步固化成脚本。Agent 执行完任务后，自动调用校验脚本，生成校验报告。这样校验不依赖 Agent 的“自觉”，而是由代码保证。我目前把样本数校验、格式校验、缺失值校验做成了脚本，Agent 在输出前调用，不通过就报错。这比让 Agent 自己检查更可靠。

7.3 用 PROJECT.md 沉淀科研经验

PROJECT.md 不只是给 Agent 看的，也是给未来的自己看的。每次踩坑后，我会把教训写进 PROJECT.md 的约束里。比如“缺失值填大写 NA”这条，就是踩坑后加的。时间长了，PROJECT.md 就成了这个项目的经验集合。新人接手时，读一遍 PROJECT.md，就能避开大部分坑。这比口头交代或者散落在聊天记录里的经验可靠得多。

我个人的体会是，PROJECT.md 的价值不在于它有多复杂，而在于它把那些容易忘记、容易忽略、容易出错的事情，从人的脑子里搬到了文档里。Agent 读它，人也读它。Agent 按它执行，人也按它检查。这种一致性，是科研工作可复现的基础。