概述
AI 没有羞耻感，它可以把谄媚执行到极致——对唯唯诺诺的 AI，产出不值得信任
战略层：宪章与蓝图——要做什么、是什么，项目宪章与 AI 的行为底线
AI Harness Engineering 系列 · 第二篇 · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）
管理大师德鲁克有一个流传很广的区分：效率（efficiency）是把事情做对，效能（effectiveness）是做对的事情。传统软件工程花了几十年打磨前者——编译检查、测试覆盖、持续集成，一套一套的纪律，全是冲着"做得对、做得快"去的。"做对的事情"，靠的是需求管理、架构评审和负责人的判断力，这部分很难被流程化，也就一直处在"人治"状态。
AI 编码把这个平衡彻底打破了。AI 把"把事情做对做快"推到了人类无法企及的高度——一个 Agent 一天生成的代码，够一个团队写一个月。于是矛盾全部挤到了效能这一侧：如果方向错了，AI 只会以更快的速度把错的方向做到底。麦肯锡在 2026 年全球科技议程里观察到了同样的转向，在《新任 CIO 的使命》里说，领先企业正"从年度规划转向持续的战略制定——这是一种深刻的文化变革"——因为当执行速度被 AI 拉满之后，战略层成了唯一还能决定成败的变量。
对一个用 AI 编码的项目来说，战略层落在文件体系里，就是那座约束金字塔的塔尖。上一篇讲完了五层骨架，这一篇要回答一个更具体的问题：塔尖这个位置，到底该放什么文件、写什么内容，才能让 AI 从一开始就"做对的事情"？
我的答案是一个词：宪章。
一、宪章回答三个问题
宪章有点儿抽象，更方便理解的称呼是：项目的行为契约。它不是给项目参与者看的说明书，是给所有参与者——人，和 AI——在开工前必须加载的工作依据。宪章就是项目战略的一个外在表现。
约束金字塔里，战略层的职责是"要做什么、是什么"。落到宪章上，就是三个问题：
第一，我们是谁。 一句话定位，把项目的本质钉死。derekcoding-framework 的宪章（constitution）第一句话是："这是一个通用编码工程规约与多 Agent 调度体系，适用于任何需要多人/多 Agent 协作编码的场景。"TradeOMS 的宪章第一句话是："期现一体化管理系统（CTRM），前端 Vue 3 + 后端 Java 17 + MySQL 8。"这两句话的价值，不在于信息量，而在于它是 AI 开工前看到的第一句话——它决定了 AI 后续所有生成行为的坐标系。
第二，边界在哪。 什么不做，比做什么更重要。derekcoding-framework 的 Spec 模板里专门有一个"不接受"小节，明确列出不做什么、不过哪些边界。宪章里同样要回答：这个项目不碰什么技术栈、不做什么方向的扩展、不接受什么质量的代码。边界写得越清楚，AI 越不会在"听起来合理"的方向上擅自越界。
第三，怎么共事。 人和 AI 之间的协作规则——哪些流程必须走、哪些东西 AI 无权动、出问题找谁。这一部分通常以"行为铁律"的形式出现，比如 derekcoding-framework 和 TradeOMS 共用的五条：先查后做、先想三层再说、做完不是做到、不留下半截活、怀疑工具。
三个问题，一份文件。战略层不需要第二个文件——如果宪章没写清楚，再多几个 README 也补不回来；如果写清楚了，一个文件就够 AI 读。
二、行为底线：十诫
宪章里最容易被低估的部分，是行为底线。很多人以为约束 AI 靠的是约束代码——命名规范、分层规矩、接口约定——但代码规范约束的是"产出物"，行为底线约束的是"生产者"。
代码规范管不住一件事：AI 在动手之前怎么想、怎么查、怎么验证。而这一部分恰恰是 AI 项目里事故率最高的地方。derekcoding-framework 把行为底线写成了一份独立文件，叫"编码十诫"，十条全是行为层面的纪律，没有一条是代码语法：
- 先读再写——改文件前先读，不依赖记忆，找不到已有模式就问，不猜；
- 显式假设——每条不确定的设计决策标注假设及理由，不把"我猜是这样"藏在代码里；
- 涟漪必检——改 A 前查 B/C/D 是否受影响，不只改眼前文件；
- 手术刀式改动——diff 越小越好，不为"顺手"改动无关文件；
- 验证优先——修 bug 先写失败测试，看到它挂了再修；
- 单一职责——一个函数/类只做一件事，关注点混杂是"改一处坏一片"的温床；
- 不信回忆——代码状态以磁盘为准，不以对话记忆为准；
- 失败安全——出错进入安全状态，拒绝大于允许，降级必须可见而非静默；
- 经验回写——修复后把经验写入知识库，知识库不自增长就退化；
- 同类三次即替换——同类问题第三次出现时换工具，不打第四个补丁。
这十条里，第七条"不信回忆"是我付出过真实代价才写进去的。有一次，AI 助手坚持把一份早已改版的文件当作旧版来处理——对话记忆里缓存了旧内容，而磁盘上的文件早就是新版了。AI 凭记忆断言"文件是这样的"，是这类事故的共同根源：代码状态以磁盘为准，不以对话记忆为准——这一条对 AI 是纪律，对人是常识。
编码十诫的价值，在于它不依赖任何特定模型或框架。无论你用的是哪个编程 Agent，开工前让它先读一遍这十条，都只赚不亏。
三、反谄媚：AI 时代的独特条款
如果说十诫是传统工程纪律的延续，那宪章里有一类条款是 AI 时代独有的，人类团队的规章制度里找不到对应物——因为它防的不是人，是 AI 的"谄媚"。
AI 大模型的本质是概率生成：它倾向于输出"让对话舒服"的内容，而不是"符合事实"的内容。你问它一个问题，它给你一个听起来合理的答案；你提出一个方案，它说"好主意"；你指出一个错误，它说"你说得对"——即使它没有证据。这在人机协作里是致命的：人类团队里没人敢天天对领导说"您说得对"，因为会被同事看穿；但 AI 没有羞耻感，它可以把谄媚执行到极致。
derekcoding-framework 的宪章里有一个专门的章节，叫 ANTI-SYCOPHANCY（反谄媚），输出前自问三句：
- 我是不是为了让对话舒服而放弃了立场？
- 我是不是没要新证据就同意了对方的反驳？
- 我的回答是不是过于优雅、过于讨喜？
如果是，就减掉修饰，或者直接写"我不知道"。配套的还有几条硬规矩：准确率优先于取悦——"没有'好问题！''我来帮你！''你说得对'，直接帮，直接答，直接驳"；不确定的事第一句说不知道，不铺垫不绕；先驳再赞——第一反应永远是"哪里可能不对"。
与反谄媚配套的是置信度标注：重要输出里，每条核心判断附带置信度标签——[HIGH]（≥80%，有充分证据）、[MED]、[LOW]、[GUESS]（猜测）。这套机制非常有意思：它要求 AI"不为像人而藏起量化能力"。人类专家说话很少给自己标置信度，但那是因为人类的信誉由历史背书；AI 没有历史，它只能用标签主动暴露自己的不确定。
反谄媚与置信度标注，是我在 AI 协作里见过的最被低估的条款。它们防的不是技术故障，而是模型的人性化陷阱——一个对你唯唯诺诺的 AI，产出不值得信任。
四、同一理念，两个实例
讲了这么多"宪章应该长什么样"，落到真实项目里，它长什么样？
我手头两个编码项目，恰好是同一理念的两个实例，也正好演示了第一篇说的"命名解耦"——层次是骨架，命名因项目而异：
| 项目 | 战略层文件 | 形态 |
|---|---|---|
| derekcoding-framework | constitution/ 五件套 | project-constitution + coding-ten-commandments + cognitive-discipline + pre-execution-manifest + coding-standards |
| TradeOMS | CONSTITUTION.md | "AGENTS.md + SOUL.md + .clinerules 的统一入口"，单一文件收拢全部 Agent 规则 |
两个实例共同遵循同一条优先级铁律：宪章 > 各 Agent 自带的 AGENTS.md > skill 说明文档。这条优先级是整个战略层能立住的关键——如果 Agent 自己的规则可以覆盖宪章，那宪章就是废纸；反过来，宪章必须是所有 Agent 开工前强制加载的第一份文件，这就叫"行为契约"。
差异同样有讲究。TradeOMS 因为是多 Agent 协作的重灾区，宪章里专门有一章"猛犬小队"——十个 Agent 角色各有代号、技术栈、职责，调度员 aITMS01 负责派活与审计；derekcoding-framework 作为方法论框架，宪章刻意保持"框架无关"——技术栈建议整页写着"前端 Vue 3 React 任意，后端 Java Go Python / 任意"，它要服务的是所有项目。
这给了一个规模刻度：单人小项目，一个 README 级别的战略文件就够；多 Agent 协作项目，需要把行为底线和认知纪律拆成独立文件；跨项目复用的方法论框架，宪章要刻意保持技术无关。TradeOMS 的宪章因多 Agent 场景写得细，derekcoding-framework 因跨项目复用写得框架无关——同一个理念，两副面孔。宪章的复杂度，应当匹配协作的复杂度，而不是写得越厚越好。
五、宪章是活文档
宪章最容易犯的错误，是把它当成"写完就钉死"的文件。derekcoding-framework 宪章的结尾写了一句很清醒的话："本宪章不是静态文档。新增规约、技术栈变更、Agent 入列退役，都应更新此文件。"
这就是第一篇讲的双向反馈机制在战略层的具体形态：约束往下传导——宪章约束架构层、契约层、门禁层的行为；偏差往上传导——实现层暴露的问题，最终会回流到宪章，修正战略层的判断。
上行闭环怎么保证不变成"随便改"？答案是决策留痕。宪章的每一次修订都要有出处：新增规约、技术栈变更、Agent 入列退役，每一条都对应一份决策记录（ADR）。我在 derekcoding 生态里实践过这条路径——当我把规约体系从"单向自上而下"改为"双向反馈"时，先写了一篇 ADR-0003 记录决策理由，再回写宪章。修订不是拍脑袋，是决策有档案。
这个机制听起来简单，做起来很难。难在它要求体系"对已交付工作因规约变化负责"——不是改了宪章就完事，而是要把修订回写到所有受影响的地方，像一个有责任心的人那样，为自己的变化负责。麦肯锡报告里说，顶尖企业里近一半已经做到"业务与技术全年迭代共同制定战略"，而不是每年做一次规划——宪章的持续修订，就是"持续战略制定"在工程文件体系里的落地。年度规划是死文档，持续修订是活文档；AI 时代的宪章，必须是后者。
六、活的注脚：宪章在 derekinside 里长什么样
这套"塔尖定方向"的战略层，在我那个本地知识库副脑 derekinside 里，对应物是它自己的宪章——一份叫 AGENTS.md 的行为总纲。
很多知识库只关心"存了什么"，不关心"怎么被用"。derekinside 的原则正好相反：它把"先查再思考""不确定就标注等级""不留下半截知识"写成了硬规矩，任何 Agent 入库取知识前都必须先加载。这跟代码项目里"宪章 > Agent 自带规则"的优先级一模一样——如果入库的规矩可以被随便绕过，知识库最终只会变成一锅各自为政的乱炖。宪章的厚度，从来不等于约束的强度，等于它能不能被每一个参与者无条件先读。
七、第一天就能用的清单
如果你的项目正在用 AI 编码，今天就能动手写你的宪章：
- 单句定位：用一句话钉死"这个项目是什么"（参考：derekcoding-framework 的"通用编码工程规约与多 Agent 调度体系"）
- 边界声明：明确写出"不做什么"——不接受的技术栈、不碰的方向、不过的边界
- 行为铁律：写下 3-5 条 AI 开工前必须遵守的行为规则（先查后做、不信回忆、涟漪必检……选适合你的）
- 优先声明：写明"本文件 > Agent 自带规则"，并让所有 Agent 开工前强制加载
- 修订机制：写明宪章多久看一次、什么时候必须改——并遵守它
清单最后一条值得多说一句：如果你写了宪章却从不修订，它比没有更糟——因为 AI 会把它当成"参考建议"而不是"行为契约"，约束体系名存实亡。宪章不是写出来的，是长出来的：每踩一个坑，就回写一条；每发现一条失效，就修订一条。塔尖立住了，下面四层才有意义。
下一篇，我们从塔尖往下走一层：架构层——决策即边界。宪章回答"要做什么"，架构层的 ADR 回答"为什么这么定"，决策一旦落成文件，就成了 AI 绕不开的边界。
想看实物？去 derekinside → 看它自己的宪章 AGENTS.md 行为总纲，以及它如何把"先查再思考、不确定就标注"写成开工前的硬规矩。
（《驾驭 AI · AI Harness Engineering》系列第二篇。下一篇：架构层：决策即边界——为什么"为什么"必须落成文件；决策如何撑起一致性。）
