如何看待 AI 工具的 "AGENTS.md" 文件

项目中可以指定 AGENTS.md 架构师来制定和维护相关规范，不能人云亦云。

这个 prompt 废话太多了，反而可能影响输出质量、限制模型发挥。这种 prompt 里只需要写你最在意的、最能补充项目相关信息的就够了，规范类内容如果只是很基础、通用的开发规范就没必要往里写。

我一般就写文件结构，哪块内容在哪里。

虽然各家都在吹自家模型能支持多长的上下文，但从实际表现来看，输出质量最高的上下文长度并没有那么长，达到一定程度之后就会明显感觉变弱智。

说白了，你的规范类 prompt 越长，模型在执行任务时可以用于收集信息和输出高质量结果的上下文就越短，越复杂的任务越容易犯病。

mcp 也是同理，加的工具越多、工具 prompt 越长，模型反而越容易犯病、降智，因为上下文从一开始就被吃了一大堆。

AGENTS 时代还是得逐渐积累自己的工作流体系，一直片段化交流到头来只是被 AI 控制着写代码的工具。

网上找的一个 1000 多行 AGENTS.md ，包含技术栈、项目结构、规范、各种示例，结果 Codex 根本不看

我就把 agents.md 当另一种系统提示词用

AGENTS.md 不就是写一下开发环境配置，构建和单测流程，什么功能在哪个文件，改了什么东西要连着什么一起改，commit 之前要做哪些检查之类的吗，和项目是严格相关的。对我来说用 llm 辅助编程就和带一个实习生差不多，该写的东西就是这些。不是很理解为什么会需要一个“通用”的内容，那直接把它做成 system prompt 不就得了

代码能力在一定范围内会越来越不重要，更重要的还是这些思想，程序员不会被 AI 取代，但是会彻底改变程序员的工作方式。如何能让自己的能力在换一个 AI 模型后的影响尽量降低，就像现在一直追逐着最强 AI 模型，自己的写代码能力看似提升了，完全是 AI 模型的泡沫堆起来的，换一个模型或者降智了立马原形毕露。AI 时代还是得让自己慢下来，思考自己可持续化积累的方向。

@artiga033 #8 “只改动必要的部分，优先复用现有成熟代码，避免重复造轮子。” 你感觉这句话有用吗，类似的还有
“不要创建工作汇报或任务总结性质的文档。”、
“对于用户提出的设想和意见，结合项目情况进行全面客观的分析，而不是一味遵循”、
“与用户的所有回复与沟通，文档与代码注释均使用中文，必要时可保留英文专业名词，并在首次出现时附简要中文注释。”...

“代码不再是资产，产生代码的规则才是资产。”

不可控，主要是各家的 context engineering 调教过于黑箱。所以需要看各家解决方案的官方指导更重要点。

理论上给 agent 喂规则会有提升，但要注意 lost in middle 和 context length 本身对模型输出质量的影响。你对于一个黑盒子的商业公司包装后的 agent ，拼了老命调优一个 user prompt ，边际效益太低了，差不多就行了，不要钻牛角尖

@JieyueXing 你举例的这种我感觉大部分工具可能都已经内置了，至少 copilot 和 codex 肯定是有的。再就是专门针对 coding 场景训练的模型不需要说这些它也会这样干的。

而另一些算是用户偏好，和项目无关。比如同一个项目有时候我需要它大胆打破现有框架来 review 我的代码，有时候我又只想让它循规蹈矩生成一堆样板代码。有时候外部依赖都很难用我就是想手写一个，有时候手动实现很难保证正确所以一定要调用外部依赖。这种要求需要的时候顺手提一下就行了，反正都省了写那么多代码了不差多打那两句话。

再比如反过来想如果把问答语言要求这种写进 AGENTS.md 里了，但是团队里如果有洋人或者有人就是喜欢用英文问答怎么办...

我的理解是这些 LLM 说明和 Makefile 之类的差不多，这里应该声明项目独有的注意事项，而不是用户的个人喜好

你看现在 openspec 和 speckit 对文档的定位就知道了，SDD 之后文档既代码，以前是为了多人协作开发追踪变动，审核，规范化代码，现在是追踪审核规范化文档，agents.md/claude.md/xxx.md 应该是所有规范化文档的入口

可惜 claude code 不支持这个

@FlashEcho 之前有人提过，在 claude.md 里写一句“请参考 agents.md”，不知道有没有用

有用，但是大部分时间会被自动忽略。

我很喜欢 linus 的提示词，有时候被骂一下就清醒了

codex 在上下文变长后，特别是快到上限的时候，能明显感觉到变傻了，同样的需求新开一个对话完成的效果要好得多。所以我觉得还是别塞太多的 prompt 比较好。