Harness 工程 vs CMMI：AI 到底该不该按"管人"的方式来管？

辩题：AI 的规模化工程管理，应该引入 CMMI 过程纪律吗？

正方：Harness 让 AI 能做事，CMMI 让 AI 持续、可靠地做正确的事——不引入过程纪律，AI 工程必然失控。

反方：AI 不是人，用管人的框架管 AI 是削足适履——过度工程化只会杀死 AI 的灵活性和创造力。

---

第一回合：AI 到底是不是"角色"？

🟢 正方（把 AI 当人管）：

两年前你说 AI 是"一次性工具"，我没意见。发个 Prompt，拿个答案，关窗口走人。

可现在呢？AI 有持久状态——上下文窗口、工作记忆文件、跨会话上下文；AI 能调用工具链——读文件、执行代码、调 API；AI 能多轮协作——和你对话、和其他 AI 配合完成复杂任务。

这叫什么？这叫角色。一个有输入输出、有职责边界、有行为模式的加工者。

你管加工者用什么？CMMI 管了三十年。

🔴 反方（AI 不是人）：

偷换概念。一个能记住上下文的 AI，和一个人坐在工位上，是一回事吗？

人有职业倦怠、有情绪波动、有经验曲线、有团队政治。CMMI 的整个设计前提，就是人是不稳定的——所以需要用流程来约束人的不可靠性。

AI 的问题恰恰相反。AI 的不稳定性来自概率分布，不是心理状态。你今天让 AI 写一千行代码，明天同样 Prompt 再来一遍，偏差可能来自 temperature 参数、模型版本更新、训练数据漂移——这和人的"今天心情不好"是两回事。你用同一套"过程纪律"去管两种完全不同来源的不确定性，这不是对症下药，这是拿着锤子看什么都像钉子。

🟢 正方：

你说了半天"来源不同"，但这重要吗？

我问你：工程师写的代码有没有 Bug？有。AI 写的代码有没有 Bug？也有。工程师的方案需要评审吗？需要。AI 的方案需要评审吗？需要。工程师的产出需要版本管理、需要回归测试、需要性能基线吗？都需要。

偏差的来源不重要，偏差的存在才重要。 结果一样，后果一样，管理手段凭什么不能一样？

---

第二回合：CMMI 的核心过程域，在 AI 工程里真的能用吗？

🟢 正方（能，而且已经有映射了）：

我们一个一个看。

需求开发与管理（RDM）：AI 不需要需求？Skill 的目标描述就是需求文档，输入输出 Schema 就是接口需求，约束条件就是非功能需求。每个 Skill 都应该有 success criteria。

计划与监控（PLAN/MC）：AI 任务就是工作包。Token 消耗就是资源估算，重试和降级策略就是风险管理，执行日志就是过程可追溯实例。

配置管理（CM）：Prompt 版本要不要管？Skill 版本要不要管？知识库版本要不要管？你用 Git 管代码，凭什么不用 Git 管 Prompt？

验证与确认（VV）：AI 输出能不能直接合主干？不能。AI 生成的代码要不要跑测试？要。AI 的方案要不要人审？要。这些就是验证与确认。

绩效管理（MPM）：一次成功率、一致性、回复风格稳定性、成本偏差、安全拦截率——这不是过程性能基线（PPB）是什么？

每一个 CMMI 关键过程域在 AI 工程里都有天然映射，不是硬套，是本就该管。

🔴 反方（能映射≠该照搬）：

"能映射"和"该照搬"之间，差了一个太平洋。

你说 Prompt 版本用 Git 管，我没意见。你说要有 JSON Schema 做输入输出校验，我也没意见。你说每次 AI 调用要记录 Token 消耗，好，都是合理的工程实践。

但你把这些叫做"CMMI 过程域"，就错了。

CMMI 不是一本"好习惯清单"。CMMI 是一个评估模型——它有成熟度等级，有评估方法（SCAMPI），有制度化要求。你真的打算给你的 AI 工程团队做 CMMI 二级评估吗？写《组织过程焦点》文档？建《组织培训》体系？

如果不是，你就不是在做 CMMI，你只是借了几个 CMMI 名词来包装正常的工程实践。这叫贴牌，不叫应用。

🟢 正方：

你说到点子上了。我确实不认为一个三人的 AI 工程团队需要去做正式的 SCAMPI A 类评估。

但你注意我的原话：“CMMI 的思想适用于 AI”。不是"CMMI 的认证适用于 AI"。

CMMI 的核心遗产不是那个评估表格，而是三十年来沉淀的过程管理哲学：定义过程的目的是让输出可控；度量的目的是建立基线、驱动改进；配置管理的目的是保证可追溯；验证确认的目的是把"中间产物"和"最终交付"分开。

这些思想，你今天做任何一家 AI-Native 公司的工程管理，都用得上。你管它叫不叫 CMMI 都可以，但它就是 CMMI。

---

第三回合：引入 CMMI，AI 的灵活性和创造力会死吗？

🔴 反方（会，绝对会）：

你扪心自问：你今天用 AI，最爽的是什么？是它能说人话、能随机应变、能抓住你模糊描述里的真实意图。

你现在要在上面加一层 JSON Schema 契约、success criteria 门禁、回归测试套件、过程性能基线。我就问你：你的 Skill 定义文件会不会比 Skill 的 Prompt 本身还长？你花在"管理 AI"上的时间和精力会不会超过"用 AI"本身？

CMMI 式管理最大的副作用就是过程重于结果。当工程师每天要填"输出一致性度量表"、“Token 偏差分析报告”、“AI 安全拦截率周报”，他们还有精力打磨那个真正让用户叫好的 Skill 吗？

别忘了，CMMI 就是被敏捷运动掀翻的。 为什么？因为它太重、太慢、太官僚。你现在想把一个被敏捷干掉的框架用在 AI 上？AI 工程迭代速度比传统软件快十倍，你让一个慢十倍的管理框架去管一个快十倍的工程——不出三个月，团队跑光。

🟢 正方（不会，想想敏捷和 CMMI 的关系）：

你这个"CMMI 被敏捷干掉"的叙事是互联网爽文，不是事实。

CMMI 2.0 专门加了敏捷场景的实践指导。CMMI 从没说"你必须瀑布"，它说的是"你必须有过程，并且过程在持续改进"。敏捷团队的站会、冲刺评审、回顾——这些本身就是过程，完全可以在 CMMI 框架下评估和改进。

你担心"过程重于结果"？那恰恰是不成熟的过程才会有的问题。CMMI 高成熟度（四级、五级）的核心恰恰是量化管理和持续优化——如果一个过程指标变成了负担，五级组织的做法是"改掉它"，不是"忍着"。

至于你说的"JSON Schema 比 Prompt 还长"——如果一个 Skill 足够简单，它的管理开销自然低。如果一个 Skill 影响核心业务、每天被调用上千次，增加校验成本理所应当。这不是官僚主义，这是风险分级管理。

🔴 反方：

漂亮话谁不会说？那我问你一个实际的：

你现在有一个做模具零件报价的 AI Skill。它今天输出了一个报价 8500 元，Schema 校验通过，一致性评分 95%，Token 消耗在预算内——所有 CMMI 指标全绿。

但这张报价单错了一个关键参数：材料单价用的是三周前的行情。Skill 的知识库没更新。CMMI 的哪个过程域能发现这个问题？

🟢 正方：

问得好，而且你恰恰证明了我的观点。

你说的这个问题，本质是"知识库的版本管理被遗漏了"。在 CMMI 的配置管理（CM）过程域里，所有影响输出质量的配置项都应该纳入版本控制——包括知识库。

你的 Skill 输出的可追溯性链条断了：你能追溯到 Model version，能追溯到 Skill version，但你追溯不到 Knowledge-base version。所以你不知道这个 8500 元是"基于 5 月 3 日材料价"还是"基于 5 月 26 日材料价"。

这不是 CMMI 失效了，是你根本没把知识库当配置项管理。 而 CMMI 的 CM 过程域第一课就是：识别所有配置项。

---

第四回合：规模化——不引入过程纪律，真的会失控吗？

🟢 正方（会，而且是必然）：

我直接给你画三个场景：

场景一：10 个 Skill、50 个 Prompt 模板。团队成员改了 Prompt，没通知任何人。两周后才发现产出的代码风格全变了。谁能追到是谁、什么时候、改了什么？没有版本管理的 Prompt 就是定时炸弹。

场景二：每天 500 次 AI 调用。成功率从 92% 掉到 78%，没人发现。直到客户投诉"最近的报价都不准"。没有过程性能基线的 AI 系统就是温水煮青蛙。

场景三：三个 AI Agent 协作完成一个任务。Agent A 的输出给 Agent B，B 又传给 C。某一环出了问题，最终结果不对。三个 Agent 都说"我不是我的错"。没有可追溯性的 Agent 协作就是罗生门。

这三个场景都不是虚构的未来——今天任何一家认真用 AI 做产品的团队都在经历。

🔴 反方（你说的对，但解药不是 CMMI）：

场景一：用 Git 管 Prompt，加 code review，不就解决了？需要 CMMI 什么？

场景二：加个监控面板，成功率掉到阈值发告警，不就解决了？需要 CMMI 什么？

场景三：Agent 之间传递结构化数据、带校验，输出打日志，不就解决了？需要 CMMI 什么？

你举的三个问题，都是好的工程实践能解决的。把好的工程实践总结成一个框架，CMMI 是其中之一，但它不是唯一的，甚至不是最适合 AI 工程的。

Harness 工程自身，就是最适合 AI 的过程框架。 它的设计从第一天就针对 AI 工作流：Skill 编排、工具链整合、模型切换、输出校验。你非要在上面再套一层三十年前为瀑布式国防项目设计的框架，这叫过度抽象。

🟢 正方：

“加个监控面板”、“打日志”、“加 code review”——你刚才说的每一个字，都是 CMMI 定义的过程资产和过程监控。

你反对的是"CMMI 认证"这个名字，你认同的是 CMMI 的全部工程内核。

Harness 工程解决的是"AI 能不能把事做成"——编排执行流、调用工具、生成输出。这是能力层。

CMMI 解决的是"AI 是否持续、可靠、可控地把正确的事做成"——版本管理、输出校验、性能基线、持续改进。这是纪律层。

能力层和纪律层不是替代关系，是互补关系。没有纪律的能力是不可靠的，没有能力的纪律是空洞的。两者缺一，AI 规模化工程管理都是半条腿走路。

---

第五回合：AI 在进化，管理 AI 的方式也需要进化吗？

🔴 反方（需要，但不是向 CMMI 的方向进化）：

你说 CMMI 是"30 年的沉淀"。我说，这恰恰是问题。

30 年前的软件工程，一个版本周期是 6 个月，需求文档写了三个月，测试两个月，发布一个月。在这样的节奏下，CMMI 的过程审计、文档要求、成熟度评估是合理的。

今天的 AI 工程呢？模型两周更新一次，Skill 三天迭代一轮，Prompt 一天调 N 次。你用 CMMI 的节奏去管，光写过程文档的时间就够 Skill 迭代三轮了。

AI 工程需要的是轻量化、实时化、自动化的管理框架，不是文档驱动、审计导向的 CMMI。

🟢 正方（CMMI 也在进化，看看 2.0 版）：

你说的是 CMMI 1.3 的刻板印象。

CMMI 2.0 明确引入了敏捷实践指南，强调"过程是最小必要"（just enough process），强调性能导向而非文档导向。一个高成熟度的 CMMI 实践者，绝对不会要求你"每次改 Prompt 写三页变更申请"。

他们会要求的是：“你的 Prompt 改了之后，能不能一键跑回归测试？如果不能，先把这个能力建设起来。”

这不是增加负担，这是帮你跑得更快而不跌倒。

🔴 反方：

理论是一回事，实践是另一回事。

CMMI 在传统软件工程里推了三十年，真正做得好的是谁？波音、洛克希德马丁、NASA——国防和航天。这些行业本身就容忍重流程，因为出错代价是几十亿和几百条人命。

你的 AI Skill 报价错了 500 块，代价是什么？客户不高兴，改一版 Prompt，两分钟的事。

错误代价完全不在一个量级上，你却要引入同一套管理框架。这不是严谨，这是管理通货膨胀。

🟢 正方：

错误代价不在一个量级上——这个判断本身，就是你在没有过程性能基线的情况下做的主观判断。

让我反过来问你：你确定你的 AI Skill 从来没有犯过比"多报 500 块"更严重的错误吗？你确定你的 Agent 从来没有在非结构化输出中泄露过不该泄露的信息？你确定你的多 Agent 协作链从来没有因为一个环节的轻微偏差导致下游的级联错误？

你不知道。因为你没有度量，所以你"觉得"没问题。

这就是为什么 CMMI 说：先度量，再判断。不要凭感觉管理 AI。

---

总结陈词

🔴 反方总结：

各位，我们不是在反对工程纪律。

版本管理、输出校验、性能监控——这些我们全部赞成。但这些是好的工程实践，不是 CMMI 的专属领地。

把 AI 当人管，最大的风险不是"管不了"，而是管过头。AI 的价值恰恰在于它能做人类做不了的事——瞬间理解模糊意图、跨越领域关联、在混乱信息中找出模式。你用一个为约束人类组织行为而设计的框架去管理 AI，最终管住的不是 AI 的错误，而是 AI 的创造力。

让 Harness 管执行，让工程师管质量，让数据管改进。不需要第三层 CMMI 抽象。

🟢 正方总结：

AI 不再是工具，它是生产成员。

是生产成员，就需要管理。管理的本质是什么？让输出可预期、可追溯、可改进。 而 CMMI 三十年来做的唯一一件事，就是这个。

你说"好的工程实践就够了"——我同意，CMMI 就是一套系统化组织"好工程实践"的方法。你的 Git + Schema + 监控面板 + 回归测试，组合起来就是一个 CMMI 过程域的实现。

Harness 让 AI 能做事。CMMI 让 AI 可靠地做正确的事。两者不是敌人，是搭档。

当我们有 10 个 Skill、100 个模板、每天 1000 次调用时，"感觉没问题"就不再是合格的管理标准。到那一天，你会发现——你已经在不知不觉中，实践了 CMMI 的每一个核心思想。

---

本文核心命题回顾：

• Harness 工程 = AI 的能力层（能做什么）
• CMMI 过程纪律 = AI 的纪律层（如何可靠、可控、持续地把事做对）
• 核心论断：能力层和纪律层不是替代关系，是互补关系。当 AI 从一次性工具变成持续参与生产过程的角色，它就天然具备了"可被管理"的特征——而 CMMI 是三十年来最成熟的过程管理框架，不分"执行者是人还是 AI"。

---