COC：面向代码生成的认知编排

COC：核心论文

面向代码生成的认知编排

终结氛围式编程：人在回路之上的开发者的五层架构

作者：洪博士（Dr. Jack Hong），新加坡管理大学

版本：1.1 ｜ 2026 年 3 月

许可：CC BY 4.0

摘要

氛围式编程（vibe coding），即用户描述意图、让人工智能生成代码的做法，在 2025 年抓住了软件业的想象力。对于原型与周末项目，它是够用的；对于生产系统，它会在三条可预见的断层上失败：人工智能随上下文填满而遗忘你的指令、依照互联网惯例而非你的惯例、以及选择最短路径以让代码跑通，而这条路径从来不是安全路径。

问题不在模型。模型每月都在改进。问题在于模型四周几乎完全没有机构知识。

本文提出面向代码生成的认知编排（COC），一套五层架构，为人工智能编程助手提供组织上下文、护栏与运行程序，使其能够作为具纪律的工程伙伴工作。COC 把 CARE 框架中确立的「人在回路之上」的哲学直接应用于软件开发：开发者的核心贡献不是写代码，而是定义并维护那套使 AI 生成代码值得信任的机构上下文。

COC 是认知编排（CO）的首个领域应用。CO 是一套领域无关的基础方法论，包含八项首要原则和一套可跨领域适用的五层架构，用于在任何由人类监督之下的 AI 工作场景中，结构化人机协作。COC 把这些原则在软件开发领域具体化。CO 规范与论文另行发布（见 Hong, 2026c）。这些原则本身并不新；新的是把它们系统地组织为一套五层框架。

披露

我构建了 Kailash 生态系统。代码按 Apache 2.0 开源许可发布，意味着源代码公开可获得，任何人在法律上都有权使用、修改、并在其上构建商业产品，永久且不可撤销。

底层的代理式工作流编排技术由两项专利申请覆盖（PCT/SG2024/050503 与 P251088SG）；Apache 2.0 许可包含自动专利授权（第 3 条），为每位使用者授予永久、免版税的专利使用权。

1. 无入职辅导的天才新员工

想一想你聘用一位杰出工程师新人时会发生什么。他们可能以班级第一名毕业。他们可能掌握十七种编程语言，并为被数百万用户使用的开源项目做出过贡献。

上班第一天，他们毫无用武之地。

并不是因为能力欠缺，而是因为上下文缺席。他们不知道支付服务有一个三秒超时，且由于供应商合同不能更改。他们不知道市场团队的 API 会在凌晨两点拉数据，一旦数据结构未提前通知就变更就会崩溃。他们不知道上一个使用某种数据库迁移模式的人在星期五晚上造成了一次长达四小时的故障。

好的组织用入职流程解决这一问题。他们让新人与资深工程师结对。他们提供文档。他们有捕捉内部标准违规的代码评审流程。他们有 CI/CD 管道来执行惯例。他们有把机构知识从资深从业者传递给新人的文化。

接下来看看业界对 AI 辅助开发所做的事情。它招来了软件工程史上最有能力的「新员工」，一个生成代码比任何人类都更快的 AI，却没有进行任何入职辅导。没有内部标准的文档。没有与资深知识的结对。没有惯例合规的代码评审。没有组织模式的强制执行。

结果完全可以预见：代码能跑。基本测试能过。同时它悄悄违反你的架构标准，解开这些违规需要耗费数月。

答案不是放弃 AI 辅助开发，而是把入职流程建起来。

2. 氛围式编程的承诺与现实

「氛围式编程」一词由 Andrej Karpathy 于 2025 年 2 月提出，用以描述一种让用户「完全交给氛围、拥抱指数曲线、忘记代码本身」的编程风格（Karpathy, 2025）。这一说法之所以引发共鸣，是因为它蕴含一个真实洞见：AI 模型在代码生成上已经好到一定程度，瓶颈正从写代码本身转向描述意图。

对于原型与周末项目，这是成立的。对于服务真实用户、处理真实数据的生产系统，它会在三条可预见的断层上塌陷。

断层 1：遗忘。 AI 编程助手运行在上下文窗口之中，即一段固定长度、可保持在工作记忆里的文本。你精心写下的架构指南、数据库惯例、API 命名标准，与正在生成的代码一起竞争这段空间。随着会话变长，AI 开始遗忘。不是戏剧性的遗忘，而是悄然的漂移：它停止沿用你的模式，转而沿用训练数据里的模式。你告诉它所有数据库操作都走你的 ORM，它在前三个文件里照做了，到第五个文件悄悄切成了原生 SQL。没有报错，没有警告，只有漂移。

断层 2：惯例漂移。 每一个成熟的工程组织都有惯例，来自来之不易的经验。也许你用惨痛代价学到数据库迁移必须幂等。也许你的团队发现某一种 API 模式在高负载下会引入竞态。AI 不知道这些。它在公共互联网、Stack Overflow 回答、GitHub 仓库、博客文章上训练。当你的惯例与互联网惯例冲突，AI 跟的是互联网。

断层 3：安全盲区。 AI 模型优化的是抵达可运行方案的最直接路径。安全几乎从来不是最直接的路径。环境变量不如硬编码字符串直接。参数化查询不如字符串拼接直接。正确的认证流程不如开发环境关掉认证、之后忘记打开直接。研究证实，使用 AI 助手的开发者产出的代码在安全漏洞率上与手写代码相当甚至更高，并且更倾向于认为自己的代码是安全的，即便它并不安全（Perry 等, 2023）。

不舒服的真相：这三种失败共享一个共同根因，这个根因不是模型能力，而是上下文缺失。AI 不了解你的组织、你的惯例、你的安全政策、以及上个季度那次出错的部署里你学到了什么。氛围式编程失败，是因为它把 AI 当作已经拥有机构知识的人来对待。它没有。模型的进一步提升也不会给它这些知识，因为这些知识是你的，属于你的组织、你的领域、你的历史，以及你来之不易的教训。

3. 真正的问题：不是模型能力，而是机构失忆

原始模型能力正在成为商品。2024 年，GPT-4 是明确的领先者。到 2026 年，Claude、Gemini 以及众多开源模型已经在大多数编码任务上达到或超越其水平。差距持续收窄。模型会持续变好，价格会持续下降。

如果你的竞争优势取决于选用了哪一款模型，你实际上没有竞争优势。所有人都能使用同一批模型。

真正的问题，也是模型进步无法解决的问题，是机构知识。组织知道的远比它能在任何训练数据中说出来的多。这类隐性知识（事情实际上怎么做、哪些模式奏效、哪些让你栽过跟头、文档里没有说的是什么）恰恰是 AI 缺少的，也恰恰是让工程团队真正有效的东西。

氛围式编程把模型当作整个解决方案。COC 把模型当作一个系统中的一个部件，而系统中的差异化来自机构知识。价值次序因此翻转：

氛围式编程的假设：
  更好的模型 → 更好的代码 → 竞争优势

COC 的现实：
  更好的机构上下文 → 更好的 AI 输出 → 竞争优势
     （对你而言具体）    （用任何模型都成立）（可防御）

你的机构知识（你的框架、惯例、架构决策、复盘教训、领域专长）专属于你的组织。它无法下载，也不会因为竞争对手换了更强的模型而被复制。它是整个团队积累的智慧，而 COC 正是把这份智慧提供给每一次 AI 交互的架构。

4. 五层架构

面向代码生成的认知编排（COC）分为五层。每一层对应一种无结构 AI 代码生成的失败模式。它们共同构成「人在回路之上的开发者」的架构：这种从业者的核心贡献不是写代码，而是定义并维护使 AI 生成代码值得信任的机构上下文。

+--------------------------------------------------+
|          第 5 层：学习                             |
|    观察 → 直觉 → 演化                               |
+--------------------------------------------------+
|          第 4 层：指令                             |
|    含审批门的结构化方法论                            |
+--------------------------------------------------+
|          第 3 层：护栏                             |
|    确定性执行，而非建议                              |
+--------------------------------------------------+
|          第 2 层：上下文                            |
|    你的活的机构手册                                 |
+--------------------------------------------------+
|          第 1 层：意图                             |
|    专职代理，而非通才 AI                             |
+--------------------------------------------------+

这不是一个理论框架。每一层在 Kailash 开源生态中都有具体实现。随后给出的架构描述源自实际的 Kailash COC 模板仓库（https://github.com/terrene-foundation/kailash-coc-claude-py，英文）。

第 1 层：意图（角色）

它解决什么问题：当你用一个通用 AI 处理所有事情，包括数据库设计、API 开发、代理编排、前端工作与安全评审，你得到的是通用产出。AI 调用的是其最广泛的训练数据，而不是对你特定框架与模式的深度领域知识。

原则：不要让一个 AI 什么都做。把任务路由到专职专家代理，每个代理都配置了对特定领域的深度知识。

在 Kailash 生态中，这通过 35 个代理定义来实现，按从 CO 模型映射而来的六个开发阶段组织：分析、计划、执行、评审、学习、交付。每个代理有界定的专长、可用工具、与其工作相匹配的模型层级（以推理为主的代理采用 Opus 级模型追求深度；对速度敏感的代理采用 Sonnet 级模型追求吞吐量），以及精选的领域知识。

关键的专家代理包括：

deep-analyst：在任何代码写下之前做失败点分析、5 Why 根因追溯与复杂度评分。
security-reviewer：在每次提交前强制调用。不是可选，不是「建议」，是强制。
框架专家（dataflow、nexus、kaizen、mcp）：各自承载对特定框架的模式、反模式与惯例的深度知识。

更深的原则映射了高效工程组织的运作方式。你不会让前端开发者去设计数据库表结构，即便技术上他们可以做到。你把数据库工作路由给数据库专家。第 1 层把这种路由显性化、系统化，让 AI 以领域适配的知识处理每一项任务。

第 2 层：上下文（图书馆）

它解决什么问题：AI 的训练数据在训练结束那一刻就已过时。你内部的框架、惯例与架构决策不会出现在任何训练数据中。AI 因此默认依据互联网惯例行事，因为它拿不到你的惯例。

原则：用你的活的机构手册替换 AI 的陈旧训练数据。让组织知识成为主要参考，而不是事后的附加。

在 Kailash 生态中，这通过结构化知识层级以「渐进披露」的方式实现：

CLAUDE.md（主指令）：每次会话加载。确立基础规则，如「框架优先开发」、运行时执行模式、测试政策、安全要求。这是最重要的上下文文档，因为它为每一次交互设定基线。
SKILL.md 索引文件（10-50 行）：快速参考模式指南。足以就某个主题定位 AI，而不占用过多上下文窗口空间。
主题文件（50-250 行）：具体领域知识，包括特定框架、部署模式与测试策略。
完整 SDK 文档（无上限）：仅在复杂实现需要时拉入的深度参考资料。

当前实现包含 34 个技能目录与 400 多个文件，全部遵循这套渐进披露模式。AI 加载当前任务所需的最小上下文，仅在必要时拉取更深参考。

此层由两项原则统领。

第一项是框架优先：绝不从零写代码，永远先查框架。Kailash Core SDK 提供 140+ 个生产就绪节点，即用于文件 I/O、HTTP 操作、数据转换、校验等企业关切的预构建组件。当 AI 知道这些存在（因为上下文告诉了它），它便用经测试的组件组合出方案，而不是从零生成一切。这是「组合优先于创造」的操作表达。

第二项是单一可信源：每一块机构知识只存在于一处，不允许矛盾。当某条惯例变更时，只在一处改动，AI 永远不会遇到相互冲突的指引。

这就是「上下文工程」与「提示工程」的区别所在。提示工程优化单次交互。上下文工程构建跨越每一次交互、每一位开发者、每一次会话都持久存在的组织知识。上下文不是一段巧妙的提示，而是你的工程团队的机构记忆，以机器可读的方式留存。

第 3 层：护栏（监督者）

它解决什么问题：上下文文档告诉 AI 该做什么。但 AI 是概率性的。它大多数时候会遵守指令，而不是所有时候。「大多数时候」对安全关键规则、架构不变量或基础设施安全而言都不够。

原则：确定性执行，而非概率性顺从。不是「AI 应该这么做」，而是「系统不允许 AI 那样做」。

实现分为两层。

第一层：规则（27 个文件）。这是软性执行，AI 读取并纳入自身行为的指令。覆盖代理、测试政策、安全实践、无桩代码政策、编码模式、环境与模型配置、Git 工作流、端到端测试、部署、文档、基础设施、信任平面安全，以及各框架特定惯例。AI 大多数时候会照做。大多数时候对关键规则是不够的。

第二层：钩子（9 个脚本）。这是硬性执行，在每一次工具调用上运行的确定性脚本，独立于模型是否「记得」规则。它们在违规到达代码库之前拦截。

整套体系中最重要的机制是防遗忘钩子：user-prompt-rules-reminder.js。它在每一条用户消息上触发。不是在每一次文件写入，不是在每一次会话启动，而是在每一条消息上。它把关键规则（环境摘要、核心行为规则、框架优先指示）重新注入 AI 的上下文。它能在上下文窗口压缩后存活，因为它在模型记忆之外运行。AI 的上下文窗口可以填满，旧指令可以被驱逐，防遗忘钩子仍会继续执行规则，因为它并不依赖模型记得什么。

这是整套架构中最重要的干预，因为它直接针对最具破坏性的失败模式：遗忘。不论会话多长、任务多复杂，AI 都无法漂过这些边界。

其余钩子提供额外执行：

validate-workflow.js：捕捉错误的代码模式、硬编码 API 密钥（13 种检测模式）、硬编码模型名、生产代码中遗留的桩与 TODO、以及集成测试里的 mock。
validate-bash-command.js：阻断破坏性命令（rm -rf /、fork 炸弹、chmod 777 /），并对风险命令（curl | sh、未经安全评审的 git push）发出警告。
session-start.js：在每次会话开始时建立环境基线。

架构采用纵深防御：关键规则有 5 到 8 道相互独立的执行机制。以「绝不硬编码模型名」为例。这一条规则由 CLAUDE.md（每次会话加载）、rules/env-models.md（软性规则）、user-prompt-rules-reminder.js（每条用户消息）、session-start.js（会话开始）、以及 validate-workflow.js（每次文件写入）共同执行。任何四道失效，第五道仍能拦截。这不是为冗余而冗余，而是承认任一单一执行机制都可能失效，而关键规则理应拥有多重独立防线。

这是 CARE 框架中「信任平面」在开发语境下的应用。在 CARE 里，信任平面是人类定义、AI 无法覆写的边界。第 3 层正是同一概念在开发语境中的体现：由人类定义、以确定性方式执行的规则，AI 在其中拥有生成代码、选择方案、解决问题的完全自主权；但边界本身不可谈判。

第 4 层：指令（运行程序）

它解决什么问题：即便有了合适的专家、合适的上下文、合适的护栏，复杂的开发任务在缺少程序纪律时仍会失败。AI 会先啃最难的一块，而本应先做分析；会在确认方案之前写代码；会在没有证据的情况下声称完成。

原则：给 AI 一套具有阶段审批门、完成依据要求与强制委派规则的结构化方法论。

实现提供由 CO 模型映射的六阶段开发工作流，以及领域专属命令：分析（/analyze）、计划（/todos）、执行（/implement）、评审（/redteam）、学习（/codify）、交付（/release 或 /deploy）。质量门位于阶段之间。AI 不能跳阶段。每一阶段产出下一阶段消费的特定交付物。第四阶段（评审）产出已定稿并验证的产物。第五阶段（学习）把机构知识捕捉到 .claude/ 工件中，而非工作区文件。第六阶段（交付）把产物送上生产。

另有 20 个斜杠命令以精简上下文的方式调用：/sdk、/db、/api、/ai、/test、/validate、/design、/i-audit、/i-harden、/i-polish、/learn、/evolve、/checkpoint、/start、/cc-audit、/journal、/sync、/wrapup、/ws、/deploy。每条命令激活相应的专家代理、加载相关上下文，并为任务建立程序框架。

第 4 层有两点尤需关注。

基于证据的完成：AI 不能仅靠一句「我把功能实现了」。每一项声明都要求文件与行号级的证据：哪个文件、哪一行、哪一项测试验证了行为。这消除了「自信的幻觉」，即 AI 在其实引入了微妙缺陷或漏掉要求时仍报告成功的倾向。

强制委派规则：每次文件变更后做代码评审。每次提交前做安全评审。这些不是建议，而是由工作流强制的程序要求。开发者无需记得去申请安全评审，系统要求它发生。

/i-audit 命令包含一项所谓的「AI 俗套测试」，用以识别那些说明 AI 正在产出泛化博客式内容、而非针对本项目产出的审美痕迹。当产出开始看起来像 AI 写给博客、而非写给这个具体项目，说明有东西已经漂移，这便是一项质量信号。

阶段间的审批门为人类判断创造自然的节点。开发者不会盯着 AI 代码生成的每一次键入，而是审查分析、批准计划、核验测试、验证证据。这就是「人在回路之上」在开发周期中的落地：人类定义程序，AI 在程序中执行，人类在结构化的检查点介入。

第 5 层：学习（绩效评估）

它解决什么问题：大多数 AI 代码生成工作流是无状态的。每次会话都从零开始。AI 从昨天的成功或失败中学不到任何东西。团队的机构知识也不会因 AI 辅助开发而增长，反而会萎缩。

原则：观察何者有效，捕捉成功模式，并随时间演化出新能力。机构知识在每一次会话中复利。

实现遵循「观察、直觉、演化」三段式流水线：

观察（observation-logger.js）：把工具使用、工作流模式、错误与修复记入结构化 JSONL 文件。每次交互都产生关于团队实际模式的数据。

直觉（instinct-processor.js）：分析积累的观察以识别反复出现的模式。它识别：

工作流模式：反复出现的节点序列（在三次或以上出现后触发）
错误-修复对：错误及其五分钟内的修复（在两对或以上触发）
框架选择模式：哪些项目类型选了哪些框架
每一个模式获得一个信心分：频率（40%）+ 成功率（30%）+ 新近度（20%）+ 一致性（10%）

演化（instinct-evolver.js）：当模式到达信心阈值时，系统建议把它们演化为正式工件：

技能（信心阈值 0.7 及以上，五次或以上观察）
命令（信心阈值 0.6 及以上，三次或以上观察）
代理（信心阈值 0.8 及以上，十次或以上观察）

关键约束：演化出的工件是建议，需要人类审查方可部署。系统提议，人类裁定。任何模式，无论信心分多高，都不会在未经人类批准的情况下纳入机构知识。checkpoint-manager.js 为学习状态提供保存、导出、导入、差异比较与恢复操作，使团队能以管理代码的同等严谨来管理其演进中的知识库。

数周数月之后，系统会为组织最常见的模式沉淀出专家代理。新加入的团队成员继承的不只是代码库，还有在其上构建的每个人所提炼的判断。AI 变得更有效，不是因为模型改进（虽然模型也在改进），而是因为围绕模型的机构知识不断加深。

这是在开发语境中最直接体现「人在回路之上」哲学的一层。开发者的主要价值不在任何单次会话里写下的代码，而在其跨所有会话持续创造并修订的机构知识。第 5 层确保这份知识被捕捉、被结构化、并对后续每一次会话可用。

5. 四重集成：CARE、EATP、CO、PACT 与 COC

COC 并非独立框架。它继承自泰睿基金会发布的一套相互咬合的标准：

CARE（哲学）
  └── CO（方法论）
        └── COC（领域应用：代码生成）

EATP（信任协议）←──── 四者共同映射
PACT（组织架构）  ←──── 操作化 CARE 治理

CARE 提供治理哲学：双平面模型（信任平面 + 执行平面）、镜像命题（AI 揭示人独有的价值）、人在回路之上的治理，以及八项 CARE 原则。CO 把这一哲学翻译为领域无关的方法论：八项首要原则、五层架构、三种失败模式、符合性框架。COC 把 CO 在软件开发中具体化：具体的代理、技能、钩子与工作流。EATP 提供四者共同引用的密码学信任基础设施：起源记录、委派记录、约束包络、能力证明、审计锚点。PACT（Hong, 2026f）提供操作化 CARE 治理的组织架构，界定约束型组织如何构建信任委派、能力边界与机构知识管理。

CARE 与 EATP 到 COC 的映射是直接的：

CARE / EATP 概念	COC 对应
信任平面（由人类定义边界）	规则 + CLAUDE.md
执行平面（AI 以机器速度运行）	代理 + 技能
起源记录（初始信任锚点）	`session-start.js`
信任谱系链（可追溯性）	强制评审门
审计锚点（合规证据）	钩子执行（退出码 2 阻断动作）
约束包络（5 个维度）	27 个规则文件 + 9 个钩子脚本
镜像命题（揭示人的价值）	开发者作为 CO 架构师，而非代码写手
人在回路之上	阶段之间的审批门

COC 作为约束型组织

「约束型组织」（Hong, 2026e）描述一种新的组织形态：AI 代理在由人类权威界定的、可经密码学验证的边界内承担运营执行。其五项构成性性质是：

信任与执行的架构性分离
从人类权威到代理行为的可验证信任谱系
以五层架构编码的结构化机构知识
以具名信任姿态表达的分级自主
在每一次交互中加深的复利知识

COC 是这一形态在软件开发领域的具体实例。CLAUDE.md 与规则文件是信任平面。代理与技能是执行平面。钩子强制架构分离。强制评审门提供可验证的信任谱系。COC 五层编码结构化机构知识。阶段化工作流提供分级自主。第 5 层的「观察、捕捉、演化」流水线使知识跨会话复利。

在 COC 中工作的开发者，相当于运行着一个由一人组成的约束型组织：他们定义包络、AI 在其内执行、机构知识复利增长。这是泰睿基金会在组织规模上使用的同一模式：14+ 个专职代理在章程约束（77 条，11 条固化条款）之下管理基金会的知识库。

与 CO 的关系

COC 是 CO 的概念验证。COC 先建立起来，然后 CO 才被正式化；COC 中浮现的模式被归纳为 CO 规范。关系如下：

CO 定义方法论：八项原则、五层架构、三种失败模式、符合性标准
COC 证明该方法论在实际中成立：具体实现、度量的结果、真实部署
面向其他领域的 CO（合规、金融、运营、医疗、教育、研究）可引用 COC 作为「五层架构有效」的证据

COC 的内容在发表时归并进 CO 论文。CO 论文（Hong, 2026c）把 COC 作为参考实现引用，并据此为其经验性论断取得数据支撑。

人在回路之上的开发者

在 CARE 框架中，人在回路之上并不在执行链中，不是每次动作都要审批的瓶颈，而是在执行链之上：界定边界、观察模式，并根据所学精化运行包络。

在 COC 中，开发者占据完全相同的位置。他们不是写每一行代码（那是人在回路中，慢且违背目的）；也不是无结构地接受 AI 的任何产出（那是氛围式编程，快而不可靠）。他们在回路之上：定义意图路由（第 1 层）、维护机构上下文（第 2 层）、执行护栏（第 3 层）、设计运行程序（第 4 层），并培育使每一次会话都比上一次更高效的学习系统（第 5 层）。

更深一层的类比是：CARE 主张在 AI 增强的企业中，人的独特贡献不是做事，而是定义使工作有价值的边界与机构知识。COC 对软件开发给出相同主张。开发者的独特贡献不是单次会话里生成的代码，而是在所有会话里构建并维护的机构上下文，这份上下文把通用 AI 转化为领域专属的工程伙伴。CARE 的镜像命题直接适用：当 AI 承担代码生成时，剩下可见的是开发者的架构判断、领域专长、质量标准与积累的智慧。这正是六项人类能力（伦理判断、关系资本、情境智慧、创造性综合、情感智能、文化导航）在工程语境下的应用。

Lisanne Bainbridge 的《自动化的反讽》（Bainbridge, 1983）指出，一个系统越自动化，操作者对底层过程保持深刻理解就越关键。COC 正是带着这个反讽在设计。每一层都是对人的理解的投资：意图层迫使团队清晰表述领域结构；上下文层迫使他们记录机构知识；护栏层迫使他们识别不可让步的规则；指令层迫使他们把方法论形式化；学习层迫使他们从经验中提炼模式。构建 COC 层的开发者，在自己领域里变得更深，而不是更浅。

6. 竞争格局：趋同即验证

COC 不在真空中运行。到 2026 年年中，每一款严肃的 AI 编程工具都在同一组执行原语上趋同。

Claude Code（Anthropic，2026 年 2 月）提供 COC 所述的全部七项执行原语：代理、技能、规则、钩子、命令、自动记忆与设置，其钩子具有与防遗忘相同的功能。Cursor 的 .cursorrules 文件与 CLAUDE.md 功能相近，为每次交互加载项目专属上下文。GitHub Copilot 的自定义指令通过维持持久指示来应对遗忘。Aider 的惯例体系通过编码项目专属模式来应对惯例漂移。Windsurf 提供 Memories 与 AGENTS.md 以承载持久上下文。

这种独立趋同不是对 COC 的威胁，而是验证。多款由不同团队、不同架构独立构建的商业工具，得出了相同的结论：原始模型能力不够，围绕模型的一切比模型本身更重要。CO 论文称之为「机构知识命题」。Claude Code 称之为「上下文工程」。它们是同一洞见。

趋同部分（时代一：执行原语）

原语	Claude Code	Cursor	COC（CO 层）
代理专职化	`.claude/agents/`	Agent 模式	第 1 层
上下文工程	`CLAUDE.md` + 技能	`.cursorrules`	第 2 层
执行钩子	Pre/Post 钩子	自定义规则	第 3 层
工具权限	allow/ask/deny	文件权限	约束包络（部分）
会话记忆	自动记忆	上下文持久化	第 5 层（部分）
结构化调用	斜杠命令	Composer 模式	第 4 层（部分）

在第 1 至第 3 层，趋同几近完全。机制已是商品，任何支持项目级配置与预动作脚本的团队都能复刻。

仍然独有的部分（时代二：治理方法论）

差异化落在两类：

含质量门的结构化工作流（CO 第 4 层）：没有已上市的工具实现了含强制审批门、基于证据的完成、强制委派与禁止跳阶段的阶段推进。Claude Code 有命令（调用），CO 要求的是编排（带执行的状态机）。这是 CO 符合性中的「必须」级别要求，目前没有执行工具满足。

机构学习流水线（CO 第 5 层）：没有已上市的工具实现了带信心阈值、模式正式化建议与人审后晋升为机构知识的「观察、捕捉、演化」流水线。Claude Code 有自动记忆（非结构化自由文本），CO 要求的是带结构化观察、信心评分与人审批准的学习架构。

治理集成：没有执行工具处理 CARE 信任平面、EATP 信任谱系链或多供应商治理。这些是不同架构层上的不同问题。执行工具回答的是「这个工具是否被允许」（访问控制）。CARE + EATP 回答的是「谁授权了这个动作、在什么约束下、以及能否向审计方证明」（信任治理）。

COC 的发表状态

鉴于这种趋同，COC 不会作为一篇独立论文投稿。执行原语（L1-L3）已是商品，继续把它们当作新颖主张来发表就不诚实。治理方法论（L4-L5）与信任集成（EATP）确实仍然新颖，但归属在 CO 论文中更合适，而非放在面向代码生成的单篇论文里。

COC 仍是 CO 的参考实现。CO 论文（Hong, 2026c）把 COC 的部署经验作为经验证据引用。构建面向其他领域 CO 应用的团队（CO 规范中界定了七个领域应用，包括 COC 本身，以及研究、学习、金融、教育、治理与合规）以 COC 作为「五层架构实际可行」的证据。

任何团队都可以从 COC 中挑出单独的要素应用到既有工具上。CLAUDE.md 模式适用于任何支持项目级配置的 AI 编程助手。钩子化护栏模式适用于任何支持预动作脚本的工具。价值在于系统性的组合、治理集成，以及五层结构所强化的机构纪律。

7. COC 不能解决的问题

诚实要求承认 COC 无法处理的部分。

全新的架构决策。 COC 擅长让 AI 遵循既有模式。它帮不上当团队面对真正新颖、需要创造性工程判断、尚无既有模式的架构挑战。第 2 层可以在决策做出后记录它，但决策本身仍是高度人类的活动。

分布式系统的复杂性。 第 3 层的护栏能捕捉局部违规，如单个文件里的错误模式、危险命令、安全反模式。它们无法捕捉分布式系统中的涌现问题，如只在高负载下出现的竞态、跨服务边界的一致性失败、级联超时效应。这些需要系统级思考，当前的 AI 代码生成工具无论外围架构如何都还无法提供。

团队动力与文化。 COC 构建的是开发者与 AI 之间的技术关系。它不涉及如何处理架构上的分歧，不涉及如何指导以 AI 为主要工具的初级开发者，也不涉及在大量代码由机器生成时如何维持工程文化。这些是组织层面的挑战，需要组织层面的解决方案。

模型本身的局限。 COC 缓解了许多模型局限，如遗忘、惯例漂移、安全盲区，但不能完全消除它们。AI 仍会偶尔产出能通过所有护栏的错误代码。开发者仍需行使判断。架构降低失败的频率与严重度，但不能消除失败。

遗留代码库。 当代码库并非按「框架优先」原则构建，没有可复用的一致框架时，COC 的收益会下降。第 3 层（护栏）与第 4 层（指令）仍有价值，但第 2 层「组合优先于创造」的优势要求有可组合的框架。

8. 从商品模型到机构优势

COC 背后的战略主张值得清楚说出来。

全球每个团队都能用上同一批 AI 模型。模型会持续变好、变便宜。如果你的开发优势取决于用的是哪款模型，那这个优势会随着每一次模型发布而蒸发。

不能被复制的是你的机构知识。你的 COC 各层编码了你组织所独有的东西：

第 1 层（意图） 编码组织结构：哪些专家角色重要、你在哪些领域运作。
第 2 层（上下文） 编码机构知识：你的惯例、框架与来之不易的教训。
第 3 层（护栏） 编码风险偏好：组织视什么为安全、什么不安全。
第 4 层（指令） 编码流程成熟度：组织如何开发与验证软件。
第 5 层（学习） 让以上复利：每一个成功项目让下一个更好。

一个花了六个月构建 COC 层的团队，拥有任何模型升级都无法复制的优势。他们的 AI 产出遵循他们的架构、尊重他们的安全政策、用他们的框架，体现他们的工程文化。一个拥有更强模型但缺乏这一机构上下文的竞争对手，会更快地产出不适配自己组织的代码。

这是开发层面上「做更好的事，而不是更高效地做事」。氛围式编程是更高效地做事：让代码生成得更快。COC 是做更好的事：构建使每次 AI 交互都产出值得保留的代码的机构基础设施。

参考文献

Bainbridge, L. (1983). “Ironies of Automation.” Automatica, 19(6), 775-779.
Hong, J. (2026). “Constraint Theater: Governance Without Wealth Effects.” 投稿 American Economic Review。该系列论文的理论基础。
Hong, J. (2026a). “CARE: Collaborative Autonomous Reflective Enterprise — A Core Thesis.” White Paper Series, Version 2.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/CARE-Core-Thesis.pdf.
Hong, J. (2026b). “Enterprise Agent Trust Protocol (EATP) — A Core Thesis.” White Paper Series, Version 2.2. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/EATP-Core-Thesis.pdf.
Hong, J. (2026c). “Cognitive Orchestration (CO) — A Core Thesis.” White Paper Series, Version 1.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/CO-Core-Thesis.pdf.
Hong, J. (2026d). “Cognitive Orchestration for Codegen (COC): A Core Thesis.” White Paper Series, Version 1.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/COC-Core-Thesis.pdf. （本文。）
Hong, J. (2026e). “The Constrained Organization: An Organizational Model for Enterprise AI Governance.” White Paper Series, Version 1.0. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/Constrained-Organization-Thesis.pdf.
Hong, J. (2026f). “PACT: Principled Architecture for Constrained Trust — A Core Thesis.” White Paper Series, Version 0.8. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/PACT-Core-Thesis.pdf.
Karpathy, A. (2025). “Vibe Coding.” 个人博客文章，2025 年 2 月。
Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). “Do Users Write More Insecure Code with AI Assistants?” ACM CCS 2023.
Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press.

Kailash 栈按 Apache 2.0 开源。完整 COC 实现的 COC 设置仓库在 GitHub 上公开可得（英文）。

关于本文的生成过程

本文的写作过程正是它所描述的过程。

初稿由一组 AI 代理生成：

研究分析代理：探索知识库与源仓库，撰写结构化草稿，并将论断与锚定文档交叉对照。
一个独立的对齐批评代理：对产出进行红队审查，识别出 8 个问题，包括事实错误、夸大陈述与与原始材料的不一致。
一个辩论专家代理：挑战草稿的论证，并标记无法核实的论断。

作者指导每一轮迭代。指令包括：

去掉无法核实的论断
删除对尚不存在的结构的引用
把披露简化为朴素事实
为非技术读者解释技术术语
确保文本读起来像一项标准化提议，而非市场宣传

作者亲自修改了语气、措辞与内容。多轮修订随之而来，每一轮都收窄了代理产出与作者所判断的「诚实且有用」之间的距离。

AI 代理负责起草。作者界定边界、评估产出、捕捉代理遗漏之处，并决定什么留下。这就是实际的「人在回路之上」，不是理论模型，而是产生本文的实际过程。

所使用的工具是 Claude Code（Anthropic），配合用于研究、对齐检查与敌意评审的专职子代理。完整对话历史，包括每一条指令、每一次更正、以及作者拒绝的每一段内容，由作者保留。

版本历史

版本	日期	变更
1.0	2026 年 2 月	初稿：面向代码生成的五层架构、氛围式编程批评、防遗忘模式、机构知识工程、Trinity 集成
1.1	2026 年 3 月	更新 CO 原则数（七 → 八）。将与执行工具的趋同视作验证。与 CO v1.1 的术语对齐

本文为 Hong (2026d)，源自 Hong, J. (2026)《Constraint Theater: Governance Without Wealth Effects》的理论基础。COC 作为参考实现，证明规范质量（q 参数）可以被结构性地提升。另见：Hong (2026a)《CARE: A Core Thesis》为治理哲学；Hong (2026b)《EATP: A Core Thesis》为信任验证；Hong (2026c)《CO: A Core Thesis》为基础方法论；Hong (2026e)《The Constrained Organization》为机构设计；Hong (2026f)《PACT: A Core Thesis》为组织架构。