当 Harness 遇上 CMMI

发布于 2026-06-13

460

我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。

文章来源：

麦哲思科技任甲林

扫码关注公众号

扫码阅读

手机扫码阅读

文章主旨：当AI从一次性工具转变为持续参与生产的角色（即Harness工程），CMMI的过程纪律同样适用于AI，确保其输出可预期、可追溯、可改进，防止规模化管理失控。

关键要点：

AI角色演变：从一次性调用变为长期协作，具备可管理、可规范、可度量的特征。
核心类比：AI行为偏差（幻觉、偏离指令等）在结构上与人高度相似，CMMI约束人的偏差同样可约束AI。
关键过程域映射：需求管理→Skill目标定义；计划监控→Harness执行计划；配置管理→Prompt/Skill版本化；过程资产→标准目录结构；验证确认→输出校验门禁；绩效管理→过程能力基线（一次通过率、人工干预率等）。
必然可行原因：AI已拥有持久状态、工具调用、多轮协作能力，成为有角色职责的加工者；Harness工程本质是过程控制流；CMMI定义的是“可控、可改进的过程”，不限定执行者是人或AI；缺乏过程纪律将导致Prompt漂移、Skill冲突、质量失控。
核心结论：Harness工程解决“AI能不能把事做成”，CMMI解决“AI是否持续、可靠、可控地把正确的事做成”。

内容结构：

一、问题的提出
过去两年AI角色发生根本变化：从一次性工具变为长期参与开发、跨任务协作、会维护上下文的角色，这使CMMI（能力成熟度模型集成）的用武之地显现。

二、核心类比：为什么CMMI适用于AI？
从输入、输出、出错方式、能力差异、改进方式五个维度对比人与AI，表明AI的“行为偏差”结构与人类高度相似，CMMI的过程纪律可同样约束AI的偏差。

三、CMMI关键过程域在Harness工程中的映射

3.1 需求开发与管理（RDM）→ Skill目标定义：每个Skill需有objective.md明确success criteria，输入输出用JSON Schema定义，可自动化校验，追溯至人类需求。
3.2 计划+监控管理→ Harness执行计划：每次AI执行作为可度量工作单元，记录失败率、一致性指标，建立过程性能基线（PPB），对超预算任务触发告警。
3.3 配置管理（CM）→ Prompt/Skill/脚本版本化：用Git管理skills/、harness/、prompts/目录，每个AI输出必须可追溯至模型版本、Skill版本、输入快照，改变时需回归测试。
3.4 过程资产开发+过程管理→ 定义“AI正确做事”的标准：包括如何写Skill、验证、评审、人工介入门禁、持续改进。参考标准目录结构：prompt.md、schema.in/out.json、examples/、test-cases/、metric.md。
3.5 验证与确认（VV）→ AI输出不是终点：自动校验脚本（schema/test/lint）作为门禁，AI输出不能直接合并到主干，需人工签名门禁或交叉验证。
3.6 绩效管理（MPM）→ 过程能力基线：度量指标包括一次通过率、人工干预率、回归错误率、Token效率、平均重试次数，累积为PPB用于预测和量化管理。

四、为什么这是“必然可行”的？

4.1 AI已从工具变为角色：拥有持久状态、工具调用、多轮协作能力，成为有角色职责的加工者，CMMI有30年管理加工者的积累。
4.2 Harness工程已经是过程工程：顺序/分支/重试/人工审批对应CMMI的流程定义、过程监控、风险管理，天然契合。
4.3 CMMI的本质不是“人”而是“可控、可改进的过程”：执行者是人或AI在过程管理意义上等价。
4.4 不引入过程纪律，AI规模化管理必然失控：多个Skill、Prompt模板、大量调用时，没有版本管理、输出校验、性能度量，系统退化，CMMI是防止退化的工程纪律。

5 再次强调
Harness工程解决“AI能不能把事做成”，CMMI解决“AI是否持续、可靠、可控地把正确的事做成”。当AI成为生产成员，CMMI就是它的工程纪律。

文章总结：本文主张将CMMI过程纪律引入AI工程（尤其Harness工程），是确保AI持续可靠工作、防止规模化管理失控的系统化方法。