AGENTS.md 反过度设计：不为理论风险扩复杂度
Dave Kiss 点赞 opencode 的 AGENTS.md 规则：加复杂度前先讲清失败模式与成本，征得用户同意。
来源摘录
This is such a banger rule in @opencode's AGENTS.md "Before adding complexity for a speculative or vanishingly unlikely race or security edge case, explain the concrete failure mode, likelihood, and complexity cost to the user and get their buy-in. Do not silently expand scope for theoretical robustness."
深度解析
是什么：推文引用了 opencode 仓库 AGENTS.md 中的一条规范，并用截图高亮。品格不是产品发布，而是写给编码 Agent 的「工程协作契约」。
核心规则链条：同一文件里的几条规则构成一条完整的克制逻辑：①在拥有该值的边界处只校验一次未知输入，向内传递已定类型，不要重复 typeof === "object" 之类的防御；②不要预先抽取只用一次的 helper，除非它遮蔽了真正复杂的边界；③只在同时说清「具体失败模式、发生概率、复杂度成本」并拿到用户同意后，才为罕见的竞态或安全边界情况加复杂度；④尽量避免 try/catch，避免 any。高亮那条是这套逻辑的收口：复杂度必须有明确买主。
关键洞察：这是把人类资深工程师的隐性判断显性化。Agent 的通病是「宁滥勿缺」式健壮性——为理论上可能的状态加分支、加兜底、加抽象层，最终代码变长、可读性变差、真实缺陷反而被掩盖。规则的价值不在技术，而在流程：它把「是否值得」从 Agent 单方面决策，转成交付给用户的一道确认题，从而抑制静默的范围蔓延（scope creep）。这与代码评审中「拒绝为不可能路径写测试」的资深直觉一致。
边界与风险：规则依赖 Agent 对「几乎不可能」的判断能力，也可能被当作偷懒的挡箭牌拒绝合理防护；对真正高风险领域（支付、权限、并发写入）需要显式的例外清单。此外它是软约束，需配合测试与评审兜底。
可复用点：任何 AGENTS.md / CLAUDE.md 都可直接照搬这条句式——「说明失败模式、概率与成本，然后征求同意」，是把工程品味写进指令文件的高性价比做法。