这一章是把前面所有内容收束起来：给项目写一份真正能让 AI 看懂的使用说明。
如果前面几章解决的是“怎么让 AI 编程助手做事”，这一章解决的就是“怎么让 AI 编程助手长期按你的规则做事”。
学完这一章，你应该能做到：
- 写出简洁、有效的 AGENTS.md；
- 不把 AGENTS.md 写成空话合集；
- 给项目补上命令、规则、边界和验收方式；
- 让后续的 AI 编程工具任务更稳定。
如果还没有打开可用的 AI 编程工具，先按第一章从官网安装并完成第一个练习，再继续这一章。
不同工具读取 AGENTS.md 的方式可能不同。写好文件后，在对话中明确说“请先阅读当前项目的 AGENTS.md”，再让工具复述规则，确认它确实读到了。
本章可直接复制的提示词
你要做的事：让 AI 根据当前项目生成一份最小可用的 AGENTS.md。
【可直接复制给 AI】
请根据当前项目，帮我生成一份最小可用的 AGENTS.md。
要求直接写清楚：
1. 这个项目常用的安装、启动、构建、测试命令；
2. AI 修改文件前应该先确认什么；
3. 哪些文件不要乱改；
4. 不要编造哪些信息；
5. 修改完成后应该怎么验证；
6. 输出用中文，适合编程小白看懂。
先只输出 AGENTS.md 草稿，不要创建文件。
【说明】
- AI 会给你一份项目规则草稿；
- 以后每次让 AI 改代码，都更容易遵守边界；
- 你可以先检查草稿，再决定是否保存成文件。
不满意继续这样问：
这份 AGENTS.md 太长了。
请压缩成 6 个小节：
项目简介、常用命令、修改边界、安全规则、验证方式、写作风格。
11.1 为什么你不能每次都靠嘴提醒 AI 编程工具
前面几章我们一直在重复几句话：
不要修改无关文件
不要新增依赖
不要改价格
不要编造数据
不要动 API Key
改完后跑 build
先看 package.json
先读 README
这些话很重要。
但如果你每次打开项目都要重新说一遍，就很烦。
更麻烦的是，你有时候会忘。
比如你今天让 AI 编程工具改首页，记得提醒：
不要改 Pricing 价格。
明天让 AI 编程工具修接口，忘了提醒：
不要打印 API Key。
后天让 AI 编程工具写 README，又忘了说：
不要编造不存在的启动命令。
这就是 AGENTS.md 的价值。
你可以把它理解成：
README 是写给人看的。
AGENTS.md 是写给 AI coding agent 看的。
README 告诉人：
这个项目是什么
怎么安装
怎么使用
AGENTS.md 告诉 AI 编程工具：
这个项目怎么启动
怎么测试
哪些文件不能乱改
什么叫完成
改完必须检查什么
真正好用的 AI 编程工具项目，不是每次都靠临时提示词，而是项目里提前写好规则。
这一章要讲的就是：
怎么给你的项目写一份不废话、不拖后腿、真的能让 AI 编程工具少犯错的 AGENTS.md。
11.2 AGENTS.md 不要写成“公司制度大全”
很多新手第一次写 AGENTS.md，会写得特别长。
比如：
你是一个资深全栈工程师。
你要认真负责。
你要写高质量代码。
你要保持代码优雅。
你要考虑性能。
你要考虑安全。
你要遵循最佳实践。
你要保持简洁。
你要避免 bug。
这些话看起来正确，但对 AI 编程工具帮助不大。
因为它不知道：
这个项目到底怎么启动？
哪个命令能验收？
哪些文件不能动？
价格数据在哪里？
API Key 怎么处理？
页面改完要看什么？
AGENTS.md 不是励志文。
它应该像项目施工说明：
进入工地前先戴安全帽。
这面墙不能拆。
这个电闸不能碰。
改完要找监理验收。
对 AI 编程工具来说，就是：
先读 package.json
用 pnpm，不要用 npm
改页面不要改 API
Pricing 数据不能改
修改后运行 pnpm build
不确定就先问
错误写法
# AGENTS.md
你是一个优秀工程师。
请写出高质量代码。
请保持项目整洁。
请遵循最佳实践。
请不要犯错。
这类内容太空。
AI 编程工具看了也不知道具体怎么做。
正确写法
# AGENTS.md
## 项目类型
这是一个 Next.js + Tailwind 的 AI 工具落地页项目。
## 常用命令
- 安装依赖：pnpm install
- 本地启动：pnpm dev
- 构建检查：pnpm build
- 代码检查：pnpm lint
## 修改规则
- 页面展示优先修改 app/page.tsx 和 components 目录。
- 不要修改 package.json，除非用户明确要求。
- 不要修改价格、套餐权益、支付链接。
- 不要编造用户数量、客户案例、收入数据。
- 如果需要真实信息，用“待补充”标记。
## 完成标准
每次修改后必须说明：
- 修改了哪些文件
- 为什么要改
- 如何验证
- 是否需要用户人工确认
这才是 AI 编程工具能直接用的规则。
11.3 先给项目写一个最小版 AGENTS.md
新手不要一上来写很复杂。
先写一个最小版。
适合大部分前端项目：
# AGENTS.md
## 项目说明
这是一个前端项目，主要用于产品展示、落地页、文档或工具页面。
## 常用命令
- 安装依赖：根据 lock 文件判断使用 npm、pnpm、yarn 或 bun
- 启动项目：查看 package.json 的 scripts
- 构建项目：优先使用 package.json 中已有 build 命令
## 工作规则
- 修改前先说明计划。
- 不要修改无关文件。
- 不要新增依赖，除非用户确认。
- 不要删除 lock 文件。
- 不要编造用户数量、客户案例、价格、收入数据。
- 涉及 API Key、登录、支付、数据库、生产配置时，先只分析，不要直接修改。
## 完成标准
完成后必须输出：
- 修改文件列表
- 修改内容摘要
- 风险点
- 建议运行的验证命令
这个版本不完美，但比没有强很多。
它解决了最常见的问题：
AI 编程工具不知道边界
AI 编程工具不知道验收方式
AI 编程工具容易改无关文件
AI 编程工具容易编造数据
用 AI 编程工具生成初版 AGENTS.md
你可以直接让 AI 编程工具帮你生成：
请根据当前当前文件夹，帮我生成一份最小版 AGENTS.md。
要求：
1. 先阅读 package.json、README、主要目录
2. 不要修改代码
3. AGENTS.md 不要超过 120 行
4. 只写对 AI 编程工具真有用的规则
5. 包含常用命令、禁止事项、完成标准
6. 不要写空话
7. 不确定的命令写“待确认”
先输出草稿，不要创建文件。
注意最后一句：
先输出草稿，不要创建文件。
你先看一遍，确认没问题，再让它写入文件。
确认后再写入
可以，把这份内容写入项目根目录 AGENTS.md。
要求：
1. 只创建或修改 AGENTS.md
2. 不要修改其他文件
3. 写完后总结内容结构
11.4 案例一：给 AI Chatbot 项目写 AGENTS.md
第一个实战案例：AI Chatbot 项目。
这种项目很容易出事，因为它通常涉及：
模型 API Key
Base URL
模型名
流式响应
用户输入
聊天接口
数据库
登录
环境变量
你不希望 AI 编程工具每次修聊天接口时都忘记：
不要把 API Key 写进代码。
不要把密钥打印到日志。
不要乱换模型名。
不要改变前端依赖的响应结构。
所以 AI Chatbot 项目的 AGENTS.md 要突出安全和接口边界。
AI Chatbot 版 AGENTS.md
# AGENTS.md
## 项目类型
这是一个 AI Chatbot 项目，包含前端聊天界面、服务端聊天接口、模型 provider 配置和环境变量。
## 常用命令
请先查看 package.json 的 scripts 字段，再决定使用以下命令：
- 安装依赖：根据 lock 文件选择 npm / pnpm / yarn / bun
- 本地启动：使用 package.json 中已有 dev 命令
- 构建检查：使用 package.json 中已有 build 命令
- 代码检查：如果存在 lint / test / typecheck 命令，修改后优先运行
## AI 接口规则
- 不要把 API Key 写入代码。
- 不要把 API Key、token、secret 打印到日志。
- 不要编造模型名。
- 不要随意切换 provider。
- 不要修改 Base URL，除非用户明确要求。
- 不要改变 /api/chat 的请求体格式，除非用户明确要求。
- 不要改变前端依赖的响应结构，除非用户明确要求。
## 环境变量规则
- 如果缺少环境变量，先列出变量名和用途。
- 不要编造真实密钥。
- .env.example 只能写占位值。
- 不要修改 .env 或 .env.local 中的真实值。
## 修改规则
- 修接口前，先判断是代码问题、环境变量问题，还是上游模型 API 问题。
- 修复 500 错误时，不要一上来重构接口。
- 修复 401 / 403 时，先检查 Key、Header、权限和环境变量。
- 修复 429 时，先判断是本地限流还是上游限流。
## 完成标准
每次修改后必须说明：
- 修改了哪些文件
- 是否影响模型 provider
- 是否影响 API 返回结构
- 是否涉及环境变量
- 需要运行什么验证命令
这个 AGENTS.md 能避免什么
它能减少这些问题：
AI 编程工具把 Key 写进代码
AI 编程工具在日志里打印 token
AI 编程工具随便换模型名
AI 编程工具改坏前端响应结构
AI 编程工具把上游 429 当成本地 bug
AI 编程工具改 .env 真实值
搭配提示词
以后你修 AI Chatbot，可以这样说：
请先阅读 AGENTS.md，然后排查 /api/chat 返回 500 的问题。
注意：
1. 先分析，不要修改
2. 按 AGENTS.md 的规则检查环境变量和 provider
3. 不要暴露 API Key
4. 不要改变响应结构
这比每次重新写一大堆规则稳很多。
11.5 案例二：给 shadcn 落地页项目写 AGENTS.md
第二个案例：shadcn / Tailwind 落地页项目。
这种项目看起来风险不高，但也很容易被 AI 编程工具改歪。
常见事故：
本来只想改 Hero，它改了 Pricing
本来只想调按钮，它改了全局 Button
本来只想优化文案，它编造客户案例
本来只想移动端适配，它改了桌面端布局
本来只想改页面，它新增了动画库
所以落地页项目的 AGENTS.md 要写清楚：
可以改展示，不可以改真实数据。
可以改样式，不可以乱装依赖。
可以改文案，不可以编造事实。
落地页版 AGENTS.md
# AGENTS.md
## 项目类型
这是一个基于 React / Next.js / Tailwind / shadcn 风格的产品落地页项目。
## 常用命令
- 安装依赖：根据 lock 文件判断包管理器
- 本地启动：查看 package.json 的 dev 命令
- 构建检查：查看 package.json 的 build 命令
- 代码检查：如果存在 lint 命令，页面修改后运行
## 页面修改规则
- 优先修改当前页面和相关展示组件。
- 不要为了小改动重写整个页面。
- 不要新增 UI 库或动画库，除非用户明确要求。
- 不要修改 package.json 和 lock 文件。
- 不要修改 API、登录、支付、数据库相关文件。
## 文案规则
- 不要编造用户数量。
- 不要编造客户名称。
- 不要编造收入、转化率、评价。
- 没有真实来源的信息，用“待补充”标记。
- 改文案时要保留产品真实定位。
## Pricing 规则
- 可以优化 Pricing 展示层级。
- 不要修改真实价格。
- 不要修改套餐权益。
- 不要修改购买链接。
- 不要修改支付逻辑。
- 修改后必须检查价格和权益是否保持不变。
## 移动端规则
- 页面改造必须考虑移动端。
- 不要只检查桌面端。
- CTA 按钮在移动端要容易点击。
- 卡片不能横向溢出。
## 完成标准
每次页面修改后必须输出：
- 修改文件列表
- 改动摘要
- 是否修改真实数据
- 移动端需要检查的点
- 建议运行的验证命令
这个版本适合哪些项目
适合：
AI 工具官网
API 服务落地页
SaaS 首页
课程销售页
开源项目展示页
小工具产品页
个人项目主页
它不适合直接用于：
后台管理系统
复杂电商系统
支付项目
数据库项目
纯后端 API 项目
不同项目要写不同规则。
11.6 案例三：给 vibe coding 生成项目写 AGENTS.md
第三个案例：vibe coding 生成的项目。
这类项目通常有一个特点：
能跑，但不一定好维护。
它可能：
组件很大
文件命名随意
逻辑和 UI 混在一起
依赖比较多
README 很简单
没有测试
没有错误处理
没有空状态
没有加载状态
所以给这种项目写 AGENTS.md，不要只写启动命令。
还要写：
不要继续把所有东西塞进一个组件。
vibe coding 项目版 AGENTS.md
# AGENTS.md
## 项目类型
这是一个 AI app builder / vibe coding 生成的应用项目。项目可以继续迭代，但需要控制改动范围，避免越改越乱。
## 常用命令
- 安装依赖：根据 lock 文件判断包管理器
- 本地启动：查看 package.json 的 dev 命令
- 构建检查：查看 package.json 的 build 命令
- 如果存在 lint / test / typecheck 命令，修改后优先运行
## 修改原则
- 每次只完成一个明确目标。
- 不要一次性大重构。
- 不要把新逻辑继续塞进已经很大的组件。
- 不要新增重复组件。
- 不要硬编码假数据，除非明确标记为 mock。
- 不要编造用户数据、客户案例、收入数据。
- 不要新增依赖，除非用户确认。
## 组件规则
- 如果组件超过 300 行，新增逻辑前先建议拆分。
- 如果多个地方重复出现相同 UI，先说明是否值得抽组件。
- 不要为了小改动抽过多组件。
- UI 组件里不要塞太多业务逻辑。
## 状态规则
涉及用户操作时，优先考虑：
- loading 状态
- error 状态
- empty 状态
- disabled 状态
- 移动端显示
## 完成标准
每次修改后必须输出：
- 修改文件列表
- 是否新增重复代码
- 是否影响组件维护性
- 是否需要补 loading / error / empty 状态
- 建议运行的验证命令
这个规则能解决什么
它可以防止 vibe coding 项目越来越像一团毛线。
尤其适合这些情况：
用 Open Lovable 生成了一个页面
用 Dyad 做了一个本地工具
用 v0 生成了几个组件
用 Bolt 做了一个 demo
用 Lovable 做了一个 SaaS 雏形
第一次能跑只是开始。
后面能不能继续改，取决于你有没有控制结构。
搭配提示词
请先阅读 AGENTS.md，然后帮我给这个 vibe coding 项目增加一个导出按钮。
要求：
1. 只做这个功能
2. 不要重构全项目
3. 如果当前组件太大，先提出拆分建议
4. 不要新增依赖
5. 修改后检查 loading / error / empty 状态
11.7 案例四：给 API 服务项目写 AGENTS.md
第四个案例：API 服务项目。
比如：
OpenAI-compatible API 网关
AI API 中转服务
Hono API
Next.js API Routes
tRPC 服务
Express / Fastify 服务
Cloudflare Worker API
API 项目的 AGENTS.md 要比页面项目更谨慎。
因为 API 改动可能影响：
认证
计费
限流
错误码
模型路由
用户额度
日志
第三方服务
API 服务版 AGENTS.md
# AGENTS.md
## 项目类型
这是一个 API 服务项目，可能包含鉴权、环境变量、第三方 API、错误处理、限流和日志。
## 常用命令
- 安装依赖：根据 lock 文件判断包管理器
- 本地启动：查看 package.json 的 dev / start 命令
- 构建检查：查看 package.json 的 build 命令
- 测试命令：优先使用 package.json 中已有 test 命令
- 类型检查：如果存在 typecheck 命令，API 修改后优先运行
## API 修改规则
- 修改接口前，先确认请求方法、路径、Headers、Body、响应结构。
- 不要随意改变已有接口的返回格式。
- 不要随意改变错误码。
- 不要把上游错误原样暴露给用户。
- 不要在日志中打印 API Key、token、secret。
- 不要绕过鉴权、中间件、限流或权限判断。
- 不要修改计费逻辑，除非用户明确要求。
## 环境变量规则
- 不要编造真实密钥。
- .env.example 只能写占位符。
- 如果缺少环境变量，先输出变量清单。
- 不要修改 .env 或生产环境配置。
## 错误处理规则
- 401：先检查鉴权和 token。
- 403：先检查权限和策略。
- 404：先检查路径和方法。
- 429：先判断本地限流还是上游限流。
- 500：先看服务端日志，不要直接重构。
## 完成标准
每次 API 修改后必须输出：
- 修改文件列表
- 是否改变请求格式
- 是否改变响应格式
- 是否改变错误码
- 是否涉及鉴权、限流、计费
- 建议运行的验证命令
这个版本适合哪些任务
适合：
修 401 / 403
修 404
修 429
优化错误提示
增加参数校验
增加 .env.example
整理 API 文档
不适合让 AI 编程工具直接做：
重写鉴权系统
重写计费系统
重写支付流程
重写数据库 schema
直接改生产环境配置
这些任务可以让 AI 编程工具辅助分析，但不能随便自动修改。
11.8 案例五：给内容站 / SEO 项目写 AGENTS.md
第五个案例：内容站。
比如：
Astro 内容站
Next.js SEO 站
文档站
价格页
教程站
工具页
API 说明页
这类项目看起来不像代码项目那么危险，但也很容易出问题。
常见事故：
改了 slug
改错 canonical
删了 sitemap 页面
写了虚假日期
编造模型价格
编造政策
把 CTA 改错
内部链接乱加
页面标题重复
所以内容站的 AGENTS.md 要写 SEO 和事实规则。
内容站版 AGENTS.md
# AGENTS.md
## 项目类型
这是一个内容站 / SEO 页面项目，主要目标是稳定发布内容、保持页面结构、避免错误事实和 SEO 配置问题。
## 常用命令
- 安装依赖：根据 lock 文件判断包管理器
- 本地启动：查看 package.json 的 dev 命令
- 构建检查：查看 package.json 的 build 命令
- 如果存在 sitemap / link / SEO 检查脚本，内容修改后优先运行
## 内容规则
- 不要编造价格、日期、政策、模型能力、客户案例。
- 不确定的信息写“待确认”。
- 涉及最新价格、政策、模型、产品状态时，需要用户提供来源或明确要求联网核查。
- 不要夸大产品能力。
- 不要写无法验证的“全网最低”“永久免费”“官方唯一”等绝对化表达。
## SEO 规则
- 不要随意修改 slug。
- 不要随意修改 canonical。
- 不要删除 sitemap / robots / llms 相关配置。
- 修改页面标题时，注意不要和现有页面重复。
- 添加内部链接时，必须和页面主题相关。
- 不要把 404 页面加入 sitemap。
## CTA 规则
- 不要随意修改注册链接。
- 不要把主 CTA 改成无关链接。
- 如果页面有固定转化目标，保持 CTA 一致。
## 完成标准
每次内容修改后必须输出：
- 修改页面列表
- 是否修改 slug / canonical / sitemap
- 是否新增事实性描述
- 是否需要来源核查
- 是否修改 CTA
- 建议运行的验证命令
这个版本适合你的项目
这种 AGENTS.md 很适合：
LinkAI guides
AI API Doctor
AI API Radar
aiapiprice
AICostPlanner
RutaAPI landing pages
EInvoiceAtlas
SellerFixHub
EUReadySeller
因为这些项目最怕的不是代码复杂，而是：
事实写错
SEO 路由写错
CTA 写错
sitemap 写错
canonical 写错
价格日期乱写
对内容站来说，AGENTS.md 一定要写清楚事实边界。
11.9 根目录 AGENTS.md 和子目录 AGENTS.md 怎么分
AGENTS.md 可以放在根目录，也可以放在子目录。
你可以这样理解：
根目录 AGENTS.md：全项目通用规则。
子目录 AGENTS.md：某个区域的特殊规则。
比如一个当前文件夹：
AGENTS.md
app/
components/
app/api/
content/
根目录 AGENTS.md 写：
通用命令
通用禁止事项
完成标准
app/api/AGENTS.md 写：
API 错误码
鉴权规则
环境变量规则
不要改响应结构
content/AGENTS.md 写：
不要编造事实
不要乱改 slug
不要乱改 canonical
根目录适合写什么
# AGENTS.md
## 通用规则
- 修改前先说明计划。
- 不要修改无关文件。
- 不要新增依赖，除非用户确认。
- 不要编造数据。
- 修改后总结 diff。
- 优先运行 package.json 中已有验证命令。
API 子目录适合写什么
# app/api/AGENTS.md
## API 规则
- 不要改变已有接口响应结构，除非用户明确要求。
- 不要绕过鉴权和限流。
- 不要打印 token、API Key、secret。
- 401 / 403 / 404 / 429 / 500 要先根据日志判断原因。
- 修改后说明是否影响前端调用。
内容子目录适合写什么
# content/AGENTS.md
## 内容规则
- 不要编造日期、价格、政策、客户案例。
- 不要随意修改 slug。
- 不要随意修改 canonical。
- 添加事实性内容时标记是否需要来源核查。
- 修改后说明是否影响 sitemap 和内部链接。
不要到处放 AGENTS.md
虽然可以分层，但不要滥用。
如果你每个小目录都放一个，AI 编程工具可能会读到太多规则。
更推荐：
根目录一个
API 目录一个
content 目录一个
特殊高风险目录一个
就够了。
AGENTS.md 的目标是减少混乱，不是制造更多规则。
11.10 AGENTS.md 和 Skill 到底怎么分工
前面我们做过很多 Skill：
项目启动体检 Skill
落地页审美 Skill
API 报错诊断 Skill
代码改动审查 Skill
云端任务说明 Skill
这一章又讲 AGENTS.md。
新手很容易混淆：
到底什么写进 AGENTS.md？
什么做成 Skill？
简单说：
AGENTS.md 写项目长期规则。
Skill 写重复任务流程。
AGENTS.md 适合写
项目怎么启动
项目怎么测试
哪些文件不能动
价格数据在哪里
API Key 怎么处理
CTA 链接不能改
内容事实不能编造
完成后必须输出什么
这些规则和项目长期绑定。
Skill 适合写
启动体检流程
页面审美诊断流程
API 报错排查流程
diff 审查流程
PR 描述生成流程
云端任务说明流程
SEO 页面检查流程
这些是可复用工作流，不一定只属于某一个项目。
一个具体例子
比如你做一个 AI API 内容站。
AGENTS.md 写：
这个站的 CTA 是什么
不要改 canonical
不要编造模型价格
构建命令是什么
sitemap 规则是什么
Skill 写：
如何检查一个 AI API 价格页
如何检查 SEO title
如何检查内部链接
如何生成页面验收清单
推荐组合
最稳的组合是：
AGENTS.md 管项目边界
Skill 管具体流程
AI 编程工具执行修改
你做最后验收
不要把所有东西都塞进 AGENTS.md。
也不要每次只靠 Skill，不写项目规则。
11.11 AGENTS.md 太长会拖后腿
AGENTS.md 不是越长越好。
写太长会有几个问题：
AI 编程工具读到太多无关规则
每次任务上下文变重
规则互相冲突
真正重要的禁止事项被淹没
简单任务也变复杂
比如你只是让 AI 编程工具改一个按钮。
但 AGENTS.md 里写了：
数据库规范
部署规范
安全审计规范
文档规范
代码风格规范
PR 规范
品牌规范
几十条测试规则
这会让简单任务变得笨重。
更好的写法：少而准
AGENTS.md 最好遵循：
短
准
可执行
和项目有关
和风险有关
不要写：
保持代码优雅。
要写：
不要修改 package.json，除非用户明确要求。
不要写：
注意安全。
要写：
不要把 API Key、token、secret 写入代码或日志。
不要写：
重视 SEO。
要写：
不要随意修改 slug、canonical、sitemap 配置。
推荐长度
普通项目：
50-120 行
复杂项目：
150 行以内
超过这个长度，就要考虑拆成：
根目录 AGENTS.md
API 子目录 AGENTS.md
content 子目录 AGENTS.md
Skill
而不是全部塞一个文件里。
11.12 本章通用模板
下面这些可以直接复制。
模板一：让 AI 编程工具生成 AGENTS.md 草稿
请根据当前当前文件夹，生成一份最小版 AGENTS.md 草稿。
要求：
1. 先阅读 package.json、README、主要目录
2. 不要修改代码
3. AGENTS.md 不要超过 120 行
4. 只写对 AI 编程工具真有用的规则
5. 包含项目类型、常用命令、禁止事项、完成标准
6. 不要写空话
7. 不确定的命令写“待确认”
8. 先只输出草稿，不要创建文件
模板二：写入 AGENTS.md
可以，把这份内容写入项目根目录 AGENTS.md。
要求：
1. 只创建或修改 AGENTS.md
2. 不要修改其他文件
3. 写完后总结内容结构
4. 告诉我这份 AGENTS.md 主要防止哪些风险
模板三：精简 AGENTS.md
请审查当前 AGENTS.md，帮我精简。
要求：
1. 删除空话
2. 删除重复规则
3. 删除和当前项目无关的规则
4. 保留启动命令、测试命令、禁止事项、完成标准
5. 保留安全和业务高风险规则
6. 精简后不超过 120 行
7. 先输出修改建议，不要直接改文件
模板四：给 AI Chatbot 写 AGENTS.md
请为当前 AI Chatbot 项目生成 AGENTS.md 草稿。
重点包含：
1. 模型 API Key 不得写入代码
2. 不得打印 token / secret
3. 不得随意修改 provider、Base URL、模型名
4. 不得改变 /api/chat 请求体和响应结构
5. 缺环境变量时先输出变量清单
6. 修 500 时先判断环境变量、上游 API 和代码错误
7. 修改后说明是否影响前端聊天流程
先只输出草稿，不要创建文件。
模板五：给落地页项目写 AGENTS.md
请为当前落地页项目生成 AGENTS.md 草稿。
重点包含：
1. 可以改展示，不要改业务逻辑
2. 不要编造用户数量、客户案例、收入数据
3. Pricing 只能改展示，不得改价格和套餐权益
4. 不要新增 UI 库或动画库
5. 页面修改后要检查移动端
6. 修改后说明是否影响 CTA、链接、真实数据
先只输出草稿，不要创建文件。
模板六：给 API 项目写 AGENTS.md
请为当前 API 服务项目生成 AGENTS.md 草稿。
重点包含：
1. 不要改变已有接口响应结构
2. 不要随意改变错误码
3. 不要绕过鉴权、权限、限流
4. 不要打印 API Key、token、secret
5. 缺环境变量时先输出变量清单
6. 401 / 403 / 404 / 429 / 500 要先根据请求和日志判断
7. 修改后说明是否影响前端调用、鉴权、限流、计费
先只输出草稿，不要创建文件。
模板七：给内容站写 AGENTS.md
请为当前内容站 / SEO 项目生成 AGENTS.md 草稿。
重点包含：
1. 不要编造价格、日期、政策、模型能力、客户案例
2. 不要随意修改 slug
3. 不要随意修改 canonical
4. 不要删除 sitemap / robots / llms 相关配置
5. 不要随意修改主 CTA 链接
6. 添加事实性内容时标记是否需要来源核查
7. 修改后说明是否影响 sitemap、canonical、内部链接、CTA
先只输出草稿，不要创建文件。
11.13 本章总结
AGENTS.md 不是装饰品。
它是给 AI 编程工具的项目规矩。
没有 AGENTS.md，你每次都要重复提醒：
不要改这个
不要碰那个
改完要检查
不要编造数据
不要泄露 Key
有了 AGENTS.md，这些规则可以长期留在项目里。
本章你要记住 8 条规则：
第一，README 写给人看，AGENTS.md 写给 AI coding agent 看。
第二，AGENTS.md 不要写空话，要写可执行规则。
第三，普通项目先写最小版，不要一开始写太长。
第四，不同项目要写不同 AGENTS.md：AI Chatbot、落地页、API、内容站规则不一样。
第五，高风险内容必须写清楚：API Key、登录、支付、价格、权限、环境变量、SEO。
第六，根目录写通用规则，特殊目录再写子目录规则。
第七，AGENTS.md 管项目边界，Skill 管重复流程。
第八，AGENTS.md 太长会拖后腿，要少而准。
推荐工作流：
先让 AI 编程工具读项目
生成 AGENTS.md 草稿
人工删掉空话
保留命令、边界、禁止事项、完成标准
写入 AGENTS.md
后续每次任务先让 AI 编程工具遵守它
定期精简和更新
这一章最重要的一句话：
别每次都口头提醒 AI 编程工具，把项目规矩写进 AGENTS.md。
下一章可以继续讲：
重复任务太多时，怎么把启动体检、页面审美、API 排查、diff 审查、SEO 检查这些流程做成 AI 编程工具 Skill，让 AI 编程工具不只是听提示词，而是按固定工作流稳定执行。