一套可落地的企业级 AGENTS.md 项目规则实践
见字如面，与大家分享实践中的经验与思考。
在 Vibe Coding 愈发流行的当下，我逐渐从单一使用 Cursor AI 编辑器，转向组合使用多种 AI 工具，尤其是搭配 CLI 工具进行项目开发。但在不同 AI 编程工具间切换时，我发现代码生成效果存在显著差异。这其中除了模型本身的差别，上下文（Context）提供的质量与一致性也是关键因素。如果你也需要在多个 AI 编程工具间切换，不妨参考这篇文章。
如果需要的是细粒度的项目规则管理，可以直接阅读：
为什么需要 AGENTS.md
在使用阶段，Prompt 往往是零散、即时且一次性的。一旦进入企业级项目或长期维护的工程，以下问题便会日益凸显：
Prompt 散落在对话中，无法复用
不同场景、不同人员与 AI 对话，输出风格不一致
AI 不理解项目结构，生成的代码虽然正确，但常被放置在错误位置或不符合项目风格
随着项目规模扩大，AI 的 "上下文幻觉" 问题愈发明显
AGENTS.md 的本质不是 Prompt 文档，而是「AI 的项目级行为约束」。
它解决的不是“怎么问”，而是：
在这个项目中，AI 应该如何理解代码、遵守规则、参与协作。
当多个 AI 工具协同工作时，也需要一份通用规则以降低切换成本。
当下主流的 AI 编程工具主要分为两类：类 VS Code 编辑器和 CLI 工具。其中 Cursor、Codex、Kiro、Qoder、Trae 等都支持 AGENTS.md 规则，Google Antigravity 支持 GEMINI.md，而 Claude Code 则是 CLAUDE.md。本质上，它们都是通过 Markdown 文件定义 Agent 指令。
与 Project Rules 不同，
AGENTS.md是一个没有元数据或复杂配置的纯 Markdown 文件。对于只需要简单、易读指令，而不想引入结构化规则额外负担的项目来说，它是理想选择。
个人级 VS 企业级的本质差异
许多人（包括早期的我）初次编写 AGENTS.md 时，常不自觉地写成这样：
使用什么语言
遵循什么编码风格
注意可读性、可维护性
这些并没有错，但还远远不够。
个人级 AGENTS.md 侧重于 "期望 AI 如何写代码"。而企业级 AGENTS.md 的核心变化在于三点：
从 “偏好” 变成 “约束”
从 “写代码” 变成 “理解流程”
从 “单人协作” 升级为 “团队共识”
企业级 AGENTS.md 不再局限于个人喜好，而是明确告诉 AI：
哪些事情不能做，哪些边界不能越，哪些决策必须严格遵守既定规则。
如何设计一套可落地的企业级规则？
经过多次迭代与实践验证，我总结了一套 C.A.R.S 模型，用于辅助编写不同项目的规则文件，效果显著。可以直接查看下图：
01 开发命令（Commands）
规则不应是抽象描述，而应是可执行的动作。
为何必须设置开发命令？ 实践表明，若不加以限制，AI 极易乱执行命令。例如：前端使用的是 pnpm，它却使用 npm；后端使用的是 gradle，它却使用 mvn。更有甚者，微信小程序端代码无法使用 npm 或其他工具编译，但 AI 写完代码后仍可能习惯性执行 npm 命令。
通过上述规则约束，AI 乱执行命令的情况已几乎绝迹。
02 架构与目录（Architecture）
此部分主要涵盖技术栈与项目目录，但绝非简单的罗列。最佳实践包括：
技术栈要精确锁定版本和特定选型，例如：Java 21，Spring Boot 3.5.4，Next.js 16 等。切勿只写 “Java” 或 “Spring Boot”，因为不同版本的代码写法与配置存在显著差异。
通过目录结构传递架构思想，建立项目的全景认知。例如，我的后端采用 DDD 分层结构，除了提供带有注释的目录树外，还需要简单描述在这种分层架构下代码的设计逻辑，指导 AI 将代码生成在正确位置。
以上是我后端的代码分层架构，采用 DDD + CQRS 模式。虽然人工编写压力不大，但对 AI 而言，这种设计复杂度较高。必须通过大量文档输入进行约束，AI 才能精准生成符合预期的代码。
03 约束与禁忌（Restrictions）
明确告知 AI “不能做什么” 往往比 “能做什么” 更重要，这是防止错误的最后一道防线。
例如，前文提到的 “小程序端：不要执行 npm/pnpm 命令”。AI 完成代码后常会默认执行命令，与其在 Prompt 中反复强调，不如在文档中明确约束，既高效又可靠。
再比如，前端 JS 计算 number 时常出现精度问题，很多时候因代码量大未及时 Review，从而导致生产事故。
如果在使用过程中，发现 AI 反复犯相同的错误，请务必加上这些约束，这能显著减少因低级错误引发的挫败感。
04 流程规范（Standards）
近期 Spec Coding 颇为流行，我也陆续体验了 Spec Kit、Open Spec 等工具以及 Kiro 的部分 Spec 功能。网络上也有大量相关讨论。但我实际尝试后发现，并不完全适合当前项目。主要原因在于其过于厚重，且难以针对项目实际情况进行定制设计。花费大量时间编写文档，却往往陷入纠结文档设计是否正确的泥潭。尤其在涉及不熟悉的领域时，这种不确定性更令人精疲力竭。
最后，结合 Open Spec 这款轻量级工具的思路，我设计了一套适合个人项目的 AI 协作流程。以下是我的 Specs 分层设计：
感兴趣的话，可以先去了解一下 OpenSpec 的设计思路。个人的设计未必适合所有人，但至少目前它能很好地覆盖我所有的复杂需求，距离成为高效的 “AI 指挥官” 又近了一步。
结语
AGENTS.md 应采用演进式的方式持续更新，所有的 AI 文档亦是如此。你沉淀的文档越规范、越顶层，将来指导 AI 编写代码就越顺手。而过于具体的规则不仅易变，AI 的遵守度也往往不高。
欢迎关注公众号"Eric技术圈"，原创技术文章第一时间推送。