# 战略层：宪章与蓝图——要做什么、是什么，项目宪章与 AI 的行为底线

> **AI Harness Engineering 系列 · 第二篇** · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

![00-intro.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/69eef644ac372d3d097394e914beb5dc.jpg)

管理大师德鲁克有一个流传很广的区分：效率（efficiency）是把事情做对，效能（effectiveness）是做对的事情。传统软件工程花了几十年打磨前者——编译检查、测试覆盖、持续集成，一套一套的纪律，全是冲着"做得对、做得快"去的。"做对的事情"，靠的是需求管理、架构评审和负责人的判断力，这部分很难被流程化，也就一直处在"人治"状态。

AI 编码把这个平衡彻底打破了。AI 把"把事情做对做快"推到了人类无法企及的高度——一个 Agent 一天生成的代码，够一个团队写一个月。于是矛盾全部挤到了效能这一侧：如果方向错了，AI 只会以更快的速度把错的方向做到底。麦肯锡在 2026 年全球科技议程里观察到了同样的转向，在《新任 CIO 的使命》里说，领先企业正"从年度规划转向持续的战略制定——这是一种深刻的文化变革"——因为当执行速度被 AI 拉满之后，战略层成了唯一还能决定成败的变量。

对一个用 AI 编码的项目来说，战略层落在文件体系里，就是那座约束金字塔的塔尖。上一篇讲完了五层骨架，这一篇要回答一个更具体的问题：塔尖这个位置，到底该放什么文件、写什么内容，才能让 AI 从一开始就"做对的事情"？

我的答案是一个词：宪章。

---

## 一、宪章回答三个问题

![01-three-questions.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/1604b955487b001bda8dc4150073ac2a.jpg)

宪章有点儿抽象，更方便理解的称呼是：**项目的行为契约**。它不是给项目参与者看的说明书，是给所有参与者——人，和 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 读。

## 二、行为底线：十诫

![02-ten-commandments.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/e6b1415ee0c605dc0a4d10719b1a1d4d.jpg)

宪章里最容易被低估的部分，是行为底线。很多人以为约束 AI 靠的是约束代码——命名规范、分层规矩、接口约定——但代码规范约束的是"产出物"，行为底线约束的是"生产者"。

代码规范管不住一件事：AI 在动手之前怎么想、怎么查、怎么验证。而这一部分恰恰是 AI 项目里事故率最高的地方。derekcoding-framework 把行为底线写成了一份独立文件，叫"编码十诫"，十条全是行为层面的纪律，没有一条是代码语法：

1. **先读再写**——改文件前先读，不依赖记忆，找不到已有模式就问，不猜；
2. **显式假设**——每条不确定的设计决策标注假设及理由，不把"我猜是这样"藏在代码里；
3. **涟漪必检**——改 A 前查 B/C/D 是否受影响，不只改眼前文件；
4. **手术刀式改动**——diff 越小越好，不为"顺手"改动无关文件；
5. **验证优先**——修 bug 先写失败测试，看到它挂了再修；
6. **单一职责**——一个函数/类只做一件事，关注点混杂是"改一处坏一片"的温床；
7. **不信回忆**——代码状态以磁盘为准，不以对话记忆为准；
8. **失败安全**——出错进入安全状态，拒绝大于允许，降级必须可见而非静默；
9. **经验回写**——修复后把经验写入知识库，知识库不自增长就退化；
10. **同类三次即替换**——同类问题第三次出现时换工具，不打第四个补丁。

这十条里，第七条"不信回忆"是我付出过真实代价才写进去的。有一次，AI 助手坚持把一份早已改版的文件当作旧版来处理——对话记忆里缓存了旧内容，而磁盘上的文件早就是新版了。AI 凭记忆断言"文件是这样的"，是这类事故的共同根源：代码状态以磁盘为准，不以对话记忆为准——这一条对 AI 是纪律，对人是常识。

编码十诫的价值，在于它不依赖任何特定模型或框架。无论你用的是哪个编程 Agent，开工前让它先读一遍这十条，都只赚不亏。

## 三、反谄媚：AI 时代的独特条款

![03-anti-sycophancy.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/3c937e73a1a5c0b6e93615b72a63b9dc.jpg)

如果说十诫是传统工程纪律的延续，那宪章里有一类条款是 AI 时代独有的，人类团队的规章制度里找不到对应物——因为它防的不是人，是 AI 的"谄媚"。

AI 大模型的本质是概率生成：它倾向于输出"让对话舒服"的内容，而不是"符合事实"的内容。你问它一个问题，它给你一个听起来合理的答案；你提出一个方案，它说"好主意"；你指出一个错误，它说"你说得对"——即使它没有证据。这在人机协作里是致命的：人类团队里没人敢天天对领导说"您说得对"，因为会被同事看穿；但 AI 没有羞耻感，它可以把谄媚执行到极致。

derekcoding-framework 的宪章里有一个专门的章节，叫 ANTI-SYCOPHANCY（反谄媚），输出前自问三句：

- 我是不是为了让对话舒服而放弃了立场？
- 我是不是没要新证据就同意了对方的反驳？
- 我的回答是不是过于优雅、过于讨喜？

如果是，就减掉修饰，或者直接写"我不知道"。配套的还有几条硬规矩：准确率优先于取悦——"没有'好问题！''我来帮你！''你说得对'，直接帮，直接答，直接驳"；不确定的事第一句说不知道，不铺垫不绕；先驳再赞——第一反应永远是"哪里可能不对"。

与反谄媚配套的是**置信度标注**：重要输出里，每条核心判断附带置信度标签——`[HIGH]`（≥80%，有充分证据）、`[MED]`、`[LOW]`、`[GUESS]`（猜测）。这套机制非常有意思：它要求 AI"不为像人而藏起量化能力"。人类专家说话很少给自己标置信度，但那是因为人类的信誉由历史背书；AI 没有历史，它只能用标签主动暴露自己的不确定。

反谄媚与置信度标注，是我在 AI 协作里见过的最被低估的条款。它们防的不是技术故障，而是模型的人性化陷阱——一个对你唯唯诺诺的 AI，产出不值得信任。

## 四、同一理念，两个实例

![04-two-instances.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/fc69863de0642307b49f0ccc05d02fd6.jpg)

讲了这么多"宪章应该长什么样"，落到真实项目里，它长什么样？

我手头两个编码项目，恰好是同一理念的两个实例，也正好演示了第一篇说的"命名解耦"——层次是骨架，命名因项目而异：

| 项目 | 战略层文件 | 形态 |
|------|-----------|------|
| 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 因跨项目复用写得框架无关——同一个理念，两副面孔。宪章的复杂度，应当匹配协作的复杂度，而不是写得越厚越好。

## 五、宪章是活文档

![05-living-document.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/532486ee730700cc36fd8c5e96999061.jpg)

宪章最容易犯的错误，是把它当成"写完就钉死"的文件。derekcoding-framework 宪章的结尾写了一句很清醒的话："本宪章不是静态文档。新增规约、技术栈变更、Agent 入列退役，都应更新此文件。"

这就是第一篇讲的双向反馈机制在战略层的具体形态：约束往下传导——宪章约束架构层、契约层、门禁层的行为；偏差往上传导——实现层暴露的问题，最终会回流到宪章，修正战略层的判断。

上行闭环怎么保证不变成"随便改"？答案是决策留痕。宪章的每一次修订都要有出处：新增规约、技术栈变更、Agent 入列退役，每一条都对应一份决策记录（ADR）。我在 derekcoding 生态里实践过这条路径——当我把规约体系从"单向自上而下"改为"双向反馈"时，先写了一篇 ADR-0003 记录决策理由，再回写宪章。修订不是拍脑袋，是决策有档案。

这个机制听起来简单，做起来很难。难在它要求体系"对已交付工作因规约变化负责"——不是改了宪章就完事，而是要把修订回写到所有受影响的地方，像一个有责任心的人那样，为自己的变化负责。麦肯锡报告里说，顶尖企业里近一半已经做到"业务与技术全年迭代共同制定战略"，而不是每年做一次规划——宪章的持续修订，就是"持续战略制定"在工程文件体系里的落地。年度规划是死文档，持续修订是活文档；AI 时代的宪章，必须是后者。

## 六、活的注脚：宪章在 derekinside 里长什么样

这套"塔尖定方向"的战略层，在我那个本地知识库副脑 **derekinside** 里，对应物是它自己的宪章——一份叫 AGENTS.md 的行为总纲。
![05-living-document.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/dd1853976625c33e0ae7a5b4ee0d9fb2.jpg)
很多知识库只关心"存了什么"，不关心"怎么被用"。derekinside 的原则正好相反：它把"先查再思考""不确定就标注等级""不留下半截知识"写成了硬规矩，任何 Agent 入库取知识前都必须先加载。这跟代码项目里"宪章 > Agent 自带规则"的优先级一模一样——如果入库的规矩可以被随便绕过，知识库最终只会变成一锅各自为政的乱炖。宪章的厚度，从来不等于约束的强度，等于它能不能被每一个参与者无条件先读。

## 七、第一天就能用的清单

![06-checklist.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/cb336111cc73a9d32b3cf71dde6e0ba1.jpg)

如果你的项目正在用 AI 编码，今天就能动手写你的宪章：

- [ ] **单句定位**：用一句话钉死"这个项目是什么"（参考：derekcoding-framework 的"通用编码工程规约与多 Agent 调度体系"）
- [ ] **边界声明**：明确写出"不做什么"——不接受的技术栈、不碰的方向、不过的边界
- [ ] **行为铁律**：写下 3-5 条 AI 开工前必须遵守的行为规则（先查后做、不信回忆、涟漪必检……选适合你的）
- [ ] **优先声明**：写明"本文件 > Agent 自带规则"，并让所有 Agent 开工前强制加载
- [ ] **修订机制**：写明宪章多久看一次、什么时候必须改——并遵守它

清单最后一条值得多说一句：**如果你写了宪章却从不修订，它比没有更糟**——因为 AI 会把它当成"参考建议"而不是"行为契约"，约束体系名存实亡。宪章不是写出来的，是长出来的：每踩一个坑，就回写一条；每发现一条失效，就修订一条。塔尖立住了，下面四层才有意义。

下一篇，我们从塔尖往下走一层：架构层——决策即边界。宪章回答"要做什么"，架构层的 ADR 回答"为什么这么定"，决策一旦落成文件，就成了 AI 绕不开的边界。

想看实物？去 derekinside → 看它自己的宪章 [AGENTS.md 行为总纲](https://github.com/derekwang85/derekinside/blob/main/AGENTS.md)，以及它如何把"先查再思考、不确定就标注"写成开工前的硬规矩。

---
（《驾驭 AI · AI Harness Engineering》系列第二篇。下一篇：架构层：决策即边界——为什么"为什么"必须落成文件；决策如何撑起一致性。）

AI Harness Engineering 系列 · 第二篇 · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

驾驭 AI · AI Harness Engineering · 战略层设计

AI 没有羞耻感，它可以把谄媚执行到极致——对唯唯诺诺的 AI，产出不值得信任

 CTO

人工智能

架构设计

职业发展

AI编码时代战略层决定成败，项目宪章作为AI行为契约，通过“单句定位、边界声明、行为铁律、反谄媚条款”约束AI做对的事。核心三问、编码十诫、置信度标注构成战略塔尖，宪章动态修订并遵循优先级铁律，确保多Agent协作不偏离方向。

2026上云采购 | AI焕新·智启新局

lexiang

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

驾驭 AI · AI Harness Engineering · 战略层设计-腾讯云开发者社区-腾讯云

驾驭 AI · AI Harness Engineering · 战略层设计

驾驭 AI · AI Harness Engineering · 战略层设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐