乐于分享
好东西不私藏

AGENTS.md 不是技术文档,是你交给 AI 员工的岗位说明书.

AGENTS.md 不是技术文档,是你交给 AI 员工的岗位说明书.

哈喽,大家好,我是老杨。

今天这个选题,我想从一个很小的文件讲起。

如果你用过 Codex 或 Claude Code,很容易有一个错觉:只要我把需求说清楚,AI 就会自己把事情做好。

但我自己用下来,发现真正影响结果的,往往不是你当下那一句提示词,而是 AI 开工前有没有读懂这个项目的规矩。

比如我现在这个公众号项目,不是简单写一篇文章就完事。它要先读我的写作规则,再去 Obsidian 里找资料,写完要生成预览页,还要做封面图,最后上传到公众号草稿箱,而且只能进草稿箱,不能直接发布。

这些规则如果每次都靠我在聊天框里重新说一遍,迟早会漏。

所以 AGENTS.md 这个文件,不是技术文档,它更像一份写给 AI 员工的岗位说明书。

先说清楚:它到底解决什么问题。

很多人第一次接触 AGENTS.md,会把它理解成程序员才看的说明文件。

但你换个角度就明白了。

你请一个新人来帮你做事,会不会只跟他说一句:帮我把公众号做好?

肯定不行。

你要告诉他账号定位、文章风格、资料放哪里、哪些话不能写、做完要检查什么、哪些按钮不能点。

AI 也是一样。

你不告诉它项目规矩,它就只能靠猜。猜对了,你觉得它聪明;猜错了,你又觉得它不靠谱。

很多 AI 翻车,不是能力不够,而是岗位没交代清楚。

我之前看过一个很典型的情况:帮朋友做 AI 客服,本来只是想让它回答常见问题,结果它会在价格上乱编数字。后来复盘发现,不是 AI 故意胡说,而是项目里根本没有放清楚价格表,也没有写价格类问题必须按固定资料回答。

这类规则如果只藏在你脑子里,AI 就不会知道。

写进项目说明以后,情况就完全不一样了。

AGENTS.md 应该写什么。

不要一上来写很长。

越长越像公司制度,AI 反而抓不到重点。第一版只写五块就够。

第一,项目是干什么的。

一句话说清楚。比如:这是老杨 AI 公众号工作区,用来生产公众号文章、预览页、封面图和草稿箱内容。

第二,关键资料在哪里。

例如写作规则在哪个目录,Obsidian 知识库在哪,草稿保存到哪里,封面图放到哪里。

第三,做事顺序是什么。

不要只写目标,要写顺序。先读资料,再写正文,再排版,再检查,再生成预览。

第四,哪些事情不能做。

这部分很重要。比如不能删除旧资料,不能覆盖用户改过的终稿,不能把草稿直接发布,不能暴露账号信息和后台路径。

第五,什么叫做完成。

不要让 AI 自己宣布完成。你要写清楚:正文已保存,预览页已生成,封面图已生成,检查脚本已通过,草稿箱上传成功或明确说明失败原因。

这五块写完,AI 就不是每次临时被你叫来干活的人,而是知道这个岗位该怎么交接的人。

我建议你先写一个很短的版本(或者你直接让AI写):

项目定位:

这个项目用来做什么,服务谁,最终产出什么。

关键目录:

资料库在哪里,草稿放哪里,输出物放哪里。

工作规则:

开工前先读哪些文件,做事按什么顺序走,遇到冲突听谁的。

禁止事项:

哪些文件不能动,哪些动作不能自动做,哪些信息不能写进正文。

完成标准:

做完以后必须给出什么结果,必须跑什么检查,失败时要说明什么。

你会发现,这东西并不难。

难的是你以前没有把自己的做事方法写出来。

为什么我说它是岗位说明书。

因为 AGENTS.md 真正改变的不是某一次回答,而是 AI 每次进入项目时的默认行为。

没有它,你每次都要重新培训一遍。

有了它,AI 至少知道:这个项目不是空白页,这里有规矩,有历史,有边界,也有完成标准。

这对一个人干活的人特别有价值。

你可能没有团队,没有助理,也没有专门的项目经理。但你可以先把自己脑子里的做事方法写成一页说明,让 AI 每次进来都先读。

这一步看起来很小,其实很像从随口安排任务,变成开始管理一个岗位。

我现在对 AI 工具的判断也越来越简单:能不能真正帮你做事,不只看模型强不强,还要看你有没有把任务变成岗位,把经验变成规则,把结果变成可检查的标准。

所以你今天不用想太复杂。

打开你正在做的一个项目,新建一个 AGENTS.md,先写五句话也行。

写清楚它是干什么的,资料在哪里,怎么做,不能做什么,做到什么算完成。

我认为,普通人真正开始用好 AI 的标志,不是会写很长的提示词,而是开始愿意把自己的做事方法整理出来。

因为只有你说得清自己的岗位,AI 才有机会像员工一样接住你的活。

相关学习资料