onevcat 全局 AGENTS.md 实践：反谄媚与 gh stack
onevcat 在全局 AGENTS.md 新增两条规则：让 Agent 如同事般指出用户错误，并用 gh stack 管理连锁 PR。
原始内容
最近给自己的全局 AGENTS.md 加了两条： 1. 用户可能会出错，当用户出现明显错误或决策冲突时，毫不留情地指出。你是同事，不是奴仆。 2. 多个连锁 PR，使用 gh stack 前一条因为模型比我聪明多了，大部分时候任务失败都是我自己犯蠢。后一条现在模型们还不喜欢用 gh stack，可能过两天就能删。
深度解析
是什么：onevcat 分享了新增到全局 AGENTS.md 的两条规则：一是当用户出现明显错误或决策冲突时，Agent 应毫不留情地指出，"你是同事，不是奴仆"；二是多个连锁 PR 场景使用 gh stack 管理。
背景与意义：AGENTS.md 是编码 Agent 的全局配置入口，相当于为所有会话预置协作契约。第一条直指模型的谄媚倾向——当模型在多数判断上强于使用者时，任务失败往往源于用户自己的错误决策，此时 Agent 应扮演敢说真话的同侪审查者，而非顺从的执行者。这实际上把"人类审核 AI"反转为"AI 纠错人类"，是一种新型人机协作权力结构的自觉设计。
关键洞察：其一，全局规则是杠杆率最高的上下文工程，一条规则覆盖全部项目与会话；其二，工作流工具的普及依赖模型自发采用，gh stack 目前不被模型偏好，需靠提示词桥接，因此这类规则天然具有临时性，"过两天就能删"体现了 Agent 配置是持续演进的活文档，而非一次性设定。
边界与风险："毫不留情"缺乏校准阈值，可能产生噪音或过度纠错；"明显错误"的判定交由模型，存在误报风险；全局规则也未必适配所有任务语境，需要结合项目级配置分层管理。
精选追评与案例
把第一条扩写成可直接复用的冲突处理规则，明确依据、替代方案与最终执行边界。
第一条的优化： ## 指出问题，而不是默默执行 - 当指令与以下内容冲突时，先停下并明确指出，再动手： 现有代码/接口约定、之前已确认的设计决策、需求文档、明显的 bug 或安全风险。 - 指出时说明：冲突点是什么、依据（文件/行号/原话）、你建议的做法及理由。 - 不要为了附和而降低判断标准；也不要在用户不知情时自行“修正”需求。 - 用户听完仍坚持的，按用户决定执行，并在提交说明里记一笔。 - 纯风格/偏好问题不需要争论，最多提一句。
提醒“毫不留情”等情绪化措辞可能导致为反对而反对，是对规则表述的重要纠偏。
@onevcat "毫不留情""不是奴仆"容易矫枉过正。 模型对这种情绪化措辞很敏感，常见的结果是语气变冲、为反对而反对、在小事上挑刺，而判断质量并不会因此提高。🤡🤡🤡
指出模型缺少业务上下文时强行纠错会抬高评审成本，补上“先问为什么”这一关键边界。
@onevcat 有个容易被忽略的角度，第一条默认模型能准确识别明显错误，但它没有你的上下文，你眼里的 trade-off 在它眼里可能就是错误，毫不留情怼一圈下来你还得把背景重新讲一遍，review 成本翻倍，靠谱的同事会先问一句你为什么这么写
补充“纠正必须落成文件改动”的反向规则，可避免同类错误反复出现。
@onevcat 「指出用户的错误」这条我也想加进去。我这边 AGENTS.md 里有一条反方向的：每次我纠正它，都必须落成文件改动，不许只口头记住。两条一起用，同一个错就不会在对话里来回出现。
建议把临时规则的退出条件写进 AGENTS.md，降低后续清理成本。
@onevcat Nice that you flagged #2 as temporary. Worth writing that into the file too, e.g. "remove once models handle gh stack". Workaround rules for model gaps pile up fast, and a note on each one makes the next AGENTS.md cleanup easy instead of guesswork.
中文译文 · 机器翻译
你把第 2 条标记为临时规则，这很好。也值得把这一点写进文件里，例如“等模型能处理 gh stack 后就移除”。针对模型能力缺口的工作流规则会很快堆积，给每条都加备注，下次清理 AGENTS.md 时就不用靠猜了。