高手推荐的表达风格，要直接写进 AGENTS.md 吗？

写风格要求前，先明确谁在读输出？

准备改动项目指令时，可以先列出常见读者及其任务：维护者需要定位改动，新成员需要理解背景，决策者需要知道结果与影响。为当前主要读者写一个阅读目标，例如看完说明后能找到修改位置并运行检查，方便判断表达要求是否有帮助。

同一个项目也可能需要几种不同输出。短进展适合快速了解当前状态，操作说明需要讲清步骤，问题分析则要保留判断依据。可以让每种输出对应自己的目标与结构，减少用一条笼统风格要求覆盖所有任务所带来的歧义。

怎样把喜欢的风格变成可检查的要求？

可以把偏好写成具体动作，例如先给当前结论，再说明依据和下一步；涉及一个不熟悉的术语时，补一句它在本任务中的意思。拿一段自己能够判断的材料试用，请读者指出哪里仍需要猜测，再根据这些反馈修改要求。

哪些要求适合留下来作为长期指令？

可以先保留在多次常见任务中都适用的要求，例如项目使用的语言、交付时需要说明的检查结果，以及已有文档的组织方式。只对某次演示或某类读者有效的偏好，则在具体任务中补充，方便后续成员理解它的使用条件。

每新增一条要求，先阅读已有指令，找出重复、含糊或互相冲突的位置，整理成更清楚的描述。再用熟悉任务试一次，确认它确实解决了之前的阅读问题。这里讨论的是整理指令的方法，没有依据摘要推断 AGENTS.md 与 CLAUDE.md 在各工具中的加载范围或优先级。

什么时候应调整或撤掉一种表达偏好？

如果读者经常需要追问缺失背景，或操作说明无法直接执行，就回到具体例子查看是哪条要求造成了歧义。每次只调整相关部分，保留调整前后的输出，让团队能解释为什么改。读者或任务发生变化时，也可以重新检查原有偏好是否仍然合适。

把讨论变成可检查的小任务

可以把同一项三步操作写成两版，保留相同事实与限制，再让未看过操作的人各自说明下一步做什么。记录误解的位置，不只问哪版读起来顺。若简化后漏掉“仅限测试账号”，应算作错误。本文没有招募读者或进行 A/B 实验，这个例子只给出可检查的阅读任务。