# 约束金字塔：文件即架构——五层规约全景，为什么"文件"才是 AI 时代的蓝图

> **AI Harness Engineering 系列 · 第一篇** · 王海涛（GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

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

想象一下：一千个人去盖同一栋楼，没有人会让他们"边想边砌"。你得先把蓝图定死——结构、管线、承重墙，一笔一划画清楚，施工队才允许进场。软件工程把这套管理理念原样搬了过来，连术语都直接沿用了建筑行业的：蓝图、分层、分专业。设计一个软件项目，就像盖一栋楼——先画架构图、写 PRD，把框架钉牢，再交给开发、实施和测试，如同庞大的施工队在图纸敲定后进场。无论在建筑还是软件，蓝图从来不是为了好看，它是让一千个乃至更多协作者，"砌出来的墙，最终构成同一栋楼"。

传统软件工程会充分利用人的抽象能力，将系统架构图、信息流程图、数据链路图等各种图嵌入到需求和设计文档中，用尽量具现化的表达方式给接手的工程师一个干活的框架。这里面的每一步几乎都留了沟通的弹性空间，对传统工程师来讲是非常人性化的表现，但是对 AI 编码来说，就会过于灵活，要么频繁的 HITL（Human in The Loop, 人的决策在环），要么放开 AI 想象（幻觉）的闸门，似乎很难找到一个比较好的方式来建立新的"蓝图"。

和传统软件工程工程师，或者以人为本，以 AI 为辅助的方式不同，AI 主导编码的现状，恰恰是反过来的：让 AI"边想边写"，人在后面追着收拾。结果就是——同一个需求，今天生成一份 A 风格，明天生成一份 B 风格，一个月后代码库里塞满了十几套互相打架的"临时方案"。更灾难的是，连正确答案的稳定性都是不确定性的，因为哪套方案能在今天的提示词中"得宠"，就像是天气预测，都是概率。

工程师的执拗，再加上不断尝试各种 AI Agent 工具（内部提示词处理能力参差不齐），我反复踩过这个坑之后，才想明白一件事：**AI 时代的"蓝图"，有一个比图纸更朴素的形态——文件，或者说规约文件体系。**

约束金字塔，是我给"规约文件体系"画的抽象概念图。这一篇，我想讲清楚这套蓝图长什么样，以及它为什么管用。

---

## 一、约束金字塔：五个层次，一套骨架

![01-pyramid.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/cdcf5f31bf5d541f33540b2ccee3d3d6.jpg)

序章里，我用 aITMS 的文件清单给过这座金字塔一个俯瞰——五个层次，一层层向下。这里不再重复那份全景，只讲两个序章没讲透、却是这套体系真正关键的点。

**第一，五层是层次的名称，不是文件清单。** 同一个层次，在不同的项目里会被叫成不同的名字——aITMS 里叫 README，TradeOMS 里叫"宪章"（CONSTITUTION.md），derekcoding-framework 里叫 constitution，它们都是战略层。名字不用深究，层次才是骨架。

```
战略层  ── 要做什么、是什么       ←  README / 宪章 / constitution（命名因项目而异）
   ↕
架构层  ── 边界在哪、为什么       ←  ADR / decisions / 架构文档
   ↕
契约层  ── 怎么做、怎么稳定       ←  Runbook / Skill / Spec / 方法论文档
   ↕
门禁层  ── 怎么保证质量           ←  Pre-submit 脚本 / 门禁脚本 / 检查器
   ↕
实现层  ── 具体产出               ←  代码 / 文章 / 配置
```

**第二，每一层都在翻译上一层。** 战略层定义"是什么"，架构层把"是什么"翻译成"边界在哪"，契约层把边界翻译成"怎么做"，门禁层把"怎么做"变成可自动验证的检查，实现层在被约束的空间里产出。约束往下传导，层层收窄——越往上，文件越少、约束力越强；越往下，文件越多、自由度越大——最终圈出 AI 的行为空间。

---

## 二、三级约束力：不是所有文件都有同样的分量

![02-constraint-levels.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/edfee87f992eaeac2f751141617fc806.jpg)

金字塔给了骨架，但还不够。真正让这套体系可执行的，是另一个维度——**约束力分级**。

不是所有文件都有同等的约束力。我把它们分成三级：

**Level 1 —— 硬约束（不可违背，违者门禁不通过）**
- `schema.sql`：数据库表结构和字段，AI 无权自行修改——任何变更必须通过 HITL（Human in The Loop，人的决策在环）制定原则
- 共享契约（DTO）：API 请求/响应签名，AI 无权自行修改
- 门禁脚本本身：门禁脚本不只用在 CI 上，也不只是系统自动化测试的全覆盖——如果系统规模不大、流程性很强，甚至可以把 UX 走查同样加进门禁
- `pom.xml` / `package.json`：依赖和构建配置，AI 无权自行修改

**Level 2 —— 架构约束（可讨论，但改变需新 ADR）**
- 所有已接受的 ADR
- 战略层文件里的模块边界声明
- 架构设计文档

**Level 3 —— 执行建议（指导性，AI 可优化，但需记录）**
- Runbook（或项目实际在用的脚本、方法）里的步骤
- Skill 定义
- 检查清单

这三级的关键，不在于文件本身，而在于 **AI 必须理解三级差异**：Level 1 碰都不能碰，Level 2 要动得走 ADR 流程，Level 3 可以优化但要留痕。

没有这个分级，AI 会把所有文件都当成"参考建议"，想改就改——那约束体系就名存实亡了。

---

## 三、为什么是"文件"，而不是 prompt 或口头约定

![03-file-vs-prompt.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/52695632d9ebaa571b537fcdc8948dcd.jpg)

开篇那个两难——要么频繁 HITL，要么放开幻觉的闸门——本质上是一个问题：**约束该写在哪里？**

很多人以为答案藏在更长的 prompt 里——把要求写得更详细、更啰嗦，AI 就会听话。但 prompt 有个致命缺陷：**它是一次性的、不可验证的、随对话漂移的。**

- 你这次写在 prompt 里的约束，下次就忘了；
- AI 有没有遵守 prompt，你没法自动检查；
- 同一个 prompt，换个模型、换个上下文，效果就变了——就像开篇说的，哪套方案能"得宠"，是概率。

文件不一样。文件有三个 prompt 给不了的性质：

1. **持久**——写一次，永远在，AI 每次生成都会重新读到它；
2. **可验证**——门禁脚本可以扫描文件，检查 AI 的输出是否违背了约束；
3. **可版本化**——约束的每一次变更，都在 Git 里有据可查。

管理大师德鲁克有句话，用在这里再合适不过：

> **"预测未来最好的方式，是把它创造出来。"**

prompt 是"预测"——你赌 AI 这次会听话；约束体系是"创造"——你把 AI 的行为空间提前圈定好，让它根本没机会跑偏。前者靠运气，后者靠工程。

---

## 四、双向机制：约束往下走，反馈往上传

![04-upper-clear.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/f74018b373b5aa7bec428f5ccf684df9.jpg)

前面讲了文件为什么是约束的载体，接下来这件载体要怎么在体系里流动。好的组织是内部自洽的，如果这套体系只是单向传递信息流，没有反馈，持久运行下去，也会要不断的打补丁，所以，**这套管理体系不只是单向自上而下的命令链，它随时准备着接受逐层反馈和矫正，同时还对已交付工作因规约变化而产生的优化改进负责，目标是做到像一个有责任心的人的感觉。**

先说下行。这套体系运转起来，靠的是一条原则——它来自我的实践，不是物理定律：

> **在我的项目里，如果是 AI 编程为主力交付的，对 AI Agent 的上层约束越清晰，生成的代码的执行效果就越一致。**

我给你一个反例，来自我自己的教训。早期在这套运维系统上，策略文件（README）只写了"这是一个工单系统，后端 Java、前端 Vue"——模块边界、命名规范一概没有。结果 AI 生成代码时，Controller 有的叫 `TicketController`，有的叫 `TicketApi`，有的把业务逻辑塞进 Controller，有的塞进 Service。十几天后，光是把这些"风格"统一回去，就花了我整整两天，而且因为不同风格代表的背后的实现逻辑，在分段去看的时候都是正确的，之所以被发现是因为要做跨系统和跨模块的集成，所以对它的调整，不是一个 bug 修复的过程，而更像是一次重新出发——因为有包袱，甚至比推倒重写还累。

后来我把策略文件（README）写到了 636 行，把模块边界、命名、分层规矩一条条定死。这 636 行不是文档化过度——每一行都是一条 AI 生成时绕不开的原则，写进文件，AI 每次生成都会读到。AI 再生成时，几乎不再出现风格漂移。

**这就是"约束"和"说教"的区别。** 说教是"你要写规范一点"，约束是"你只能在这个边界里写"。前者 AI 听不进去，后者 AI 想不听都不行。

但真正让这套体系开始有活人感的，是反馈和信息上行——**实现层的偏差，要能流回上层，反过来修正约束本身，建立一套自进化体系。**

怎么流动？举三个真实的例子：

- **实现层 → 门禁层**：AI 生成的代码反复违反某条命名规则，这条规则就从"软提醒"升级成"门禁必检"；
- **门禁层 → 契约层**：门禁拦下一个反复出现的错误，说明契约层文件里缺了一步，补进步骤，下次 AI 就不会再错；
- **契约层 → 架构层 → 战略层**：某个约束怎么改都别扭，最后发现是边界划错了——于是新增一条 ADR，甚至修订战略层的宪章。

**约束往下传导，偏差往上传导，两条通道都通畅，约束金字塔规则内的实现就是充满活力的。**

---

## 五、自进化体系在本地知识库里的应用

![05-derekinside.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/b2db176a458096a7dffa31780fa33491.jpg)

我有一个跨项目编码能力共享的本地知识库副脑，叫 **derekinside**。它自己的术语跟约束金字塔并不完全同名，但机制在理念上同构：十几个"知识翼"是战略层，记忆晋升规则是架构层，chunk 切分与实体关系契约是契约层，导入校验与去重是门禁层，数千页沉淀、上万个实体节点（实现层）都是在这些约束底下长出来的。它不是一个静态数据库，而是**约束体系支撑下开始自我进化的系统**——记忆晋升规则会根据使用反馈调整，这就是上行通道在这个副脑里的样子。这里只掀开一角，我会在第九篇把它完整拆开。

---

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

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

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

- [ ] 你的战略层文件（README / 宪章 / constitution）里，有没有**明确写出模块边界和命名规范**？（不是"项目简介"，是"AI 生成前必读的蓝图"）
- [ ] 你的架构决策，有没有**落成文件**（哪怕是 `decisions.md` 一个文件），还是只躺在聊天记录里？
- [ ] 你有没有把约束分**三级**——哪些 AI 绝对不能碰，哪些要审批，哪些可以自己优化？
- [ ] 你有没有**一个可自动验证的检查点**，能让 AI 的输出"过不过关"变成确定答案？
- [ ] 你的约束是写在**文件**里（持久、可验证、可版本化），还是只写在 **prompt** 里（一次性、不可验证、随对话漂移）？

五条里做到两条，你的项目就已经从"追着 AI 收拾"转向"给 AI 划边界"了。再多问一句：当 AI 反复越界时，你有没有让这个偏差**流回约束本身**、把约束改得更准？有这条回路，你的金字塔才是活的。

---

*（《驾驭 AI · AI Harness Engineering》系列第一篇。下一篇：战略层——宪章与蓝图；要做什么、是什么，项目宪章与 AI 的行为底线。）*

---

AI Harness Engineering 系列 · 第一篇 · 王海涛（GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

驾驭 AI · AI Harness Engineering · 约束金字塔

软件工程应用建筑行业蓝图的概念去承载软件设计和界定软件需求的边界，由来已久，而且行之有效，但在AI Agent/ AI Coding的时代，单一的一分业务蓝图，一分PRD，甚至一分宪章来管理整个项目就显得很乏力，AI Agent可能需要一个更复杂而高效的文件体系来完成对能力的集中释放，本文就对如何构建一套有效的适用于AI Agent的文件体系提出了一种解法。

 CTO

人工智能

架构设计

编程语言

**约束金字塔：文件即架构——AI时代五层规约蓝图**

AI编码混乱源于约束缺失。文件体系优于prompt，因其持久、可验证、可版本化。通过战略、架构、契约、门禁、实现五层约束，及三级约束力分级，可有效规范AI行为。双向机制确保约束下行、反馈上行，实现自进化。五条自查清单助你落地。

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

llmsgw

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯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 · 约束金字塔

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐