AI写代码了,软件质量还要靠GJB5000B/CMMI吗?——软件过程能力的再思考

当Copilot秒生成代码，当Cursor帮我们重构整个模块，一个声音越来越响亮：“还要GJB 5000B/CMMI这套‘笨重’过程干什么？不是浪费时间吗？”

如果你也有这样的疑问，请花8分钟读完这篇文章。你会发现：AI没有让过程管理变得多余，反而让它变得前所未有的重要。

一、AI没有改变软件的本质——四大难题依然存在

让我们回到一个根本问题：软件开发为什么这么难？

软件工程之父Fred Brooks 曾指出软件的四大本质特征：

• 不可见性：软件是逻辑，不是物理实体

• 复杂性：组合爆炸，微调引发连锁反应

• 一致性：不同角色对需求的理解难以统一

• 灵活性：“易于修改”反而导致失控

这些特征因为AI的加入而消失了吗？恰恰相反。

当你使用AI生成一段代码，你面临的是“更深层的不可见性”——你不仅看不见代码运行时的状态，还看不见AI的“思考过程”。它为什么给出这个算法？有没有隐藏的安全漏洞？你无法像审查人类同事那样追问它的逻辑。

AI还放大了复杂性。现在你的团队不仅是人与人协作，还是人与AI协作。谁来审查AI的输出？AI的建议和人类的设计冲突时听谁的？这些新增的交互节点让过程管理变得更加必要。

更棘手的是AI的“幻觉”。AI会自信地给出错误答案，而且一致性极差——同样的Prompt，两次输出可能完全不同。如果你没有一个规范的过程来验证AI的输出，那就等于在项目里埋下了一颗颗随机爆炸的地雷。

结论很清晰：AI没有消除软件危机，只是把危机换了一张脸。而过程管理，仍然是应对这些固有不确定性的唯一系统化手段。

二、过程能力 vs AI能力——相辅相成，不可替代

我们给“过程能力”下个定义：组织通过其定义的软件过程，持续、可预期地交付高质量结果的能力，包含三个维度——稳定性、可重复性、可改进性。

AI能增强这三个维度吗？当然能。

• 稳定性：AI可以自动执行重复的验证工作，比如每次提交都运行AI生成的测试套件，减少人为疏忽导致的波动。

• 可重复性：AI可以将优秀开发者的“隐式经验”固化为可复用的代码模板、设计模式推荐，让新手也能产出类似质量的结果。

• 可改进性：AI分析历史项目的过程数据，自动发现哪个环节最常导致缺陷，哪里最浪费等待时间，从而驱动精准的过程改进。

但是，AI能替代过程管理本身吗？绝对不能。

为什么？因为过程管理解决的是组织级的问题：

• 谁来定义AI的使用规范？（角色与职责）

• AI生成的知识产权归谁？（法律与合规）

• 如何审计AI做出的关键决策？（追溯性）

• 当AI建议违反军品标准时，如何强制否决？（控制机制）

这些问题没有一个可以通过“更好的AI模型”解决。它们需要的是制度、流程、审查、文化——这属于组织治理与AI管理体系的范畴。GJB 5000B/CMMI可以作为软件工程过程部分的基础框架，还需补充法律、技术和管理规则。

打个比方：AI是顶级的工匠，手艺出神入化；而过程是施工图、质检标准、安全规范。你让一位工匠单独建一栋摩天大楼——他可能盖出精美的狗窝，但绝不敢说能盖出百层高楼。只有工匠+蓝图+质检，才能交付可靠的工程。

三、从“过级思维”到“AI赋能的过程改进”——范式转换

有一个极其重要的认知：不是“为过程而过级”，而是“为业务而过程”。 很多组织过了级，业务依然没起色，就是因为陷入了形式主义。

AI时代，这个范式转换有了新的突破口。

以前，我们为了实现“降低线上缺陷率”这个业务目标，要写很多过程文件、组织很多评审会议，一线人员觉得是额外负担。现在，我们可以问：AI能不能直接帮助实现这个目标？

比如：

• 让AI自动扫描代码中的常见安全漏洞（代替部分人工走查）

• 让AI根据历史缺陷数据，预测本次提交的风险等级，自动触发不同强度的验证流程

• 让AI在需求阶段就检查文档与以前项目的相似缺陷模式

但注意——这些AI应用本身也需要被过程管理。你要定义AI的触发条件、输出物格式、人工复核的规则、失败时的回退机制。这就是“AI赋能的过程改进”：过程为AI铺好轨道，AI为过程提供动力。

GJB 5000B的21个实践域，几乎每一个都可以嵌入AI能力：

关键认知转变：过程不再是“写着累、查着烦”的枷锁，而变成了“让AI为我所用”的操作手册。

四、CMMI / GJB 5000B在AI时代的五大可用价值

有些人说：“CMMI都更新到2.0了，GJB 5000B也老了，AI时代应该有新模型。” 这种观点误解了“模型”与“方法”的区别。GJB 5000B/CMMI的价值不在于具体的术语，而在于它提供了一整套软件工程能力的度量尺度和改进路径。这个价值在AI时代不仅没有消失，反而更加凸显。

1. 可预测性
AI预测需要数据，而数据来自规范的过程度量。如果项目计划是拍脑袋的，需求变更不记录，缺陷不分类——再强大的AI也只能输出“垃圾”。GJB 5000B要求的测量与绩效管理实践域，恰好为AI提供了高质量的训练数据。

2. 组织资产沉淀
训练一个私有化的、懂你业务和写码规范的AI模型，需要大量的历史项目数据（文档、代码、缺陷记录、评审意见）。这些资产不会凭空产生，正是GJB 5000B过程改进日积月累的结果。

3. 减少英雄依赖
AI可以降低对“牛人”的依赖——新人借助AI也能写出不错代码。但前提是你的过程已经定义了“什么样算不错代码”。如果没有过程，每个人的“不错”标准不一样，AI就会陷入混乱。

4. 入场券价值
这不是情感价值，而是现实门槛。军品采购中的GJB 5000B认证要求，不会因为AI的热潮而取消。相反，军方会更关注：你用了AI，如何证明你的软件仍然安全可靠？这时，你有规范的过程管理AI的使用，反而是加分项。

5. 持续进化能力
AI可以大幅加速PDCA循环。以前分析一个过程偏差可能花费一周，现在让AI在分钟级内扫描所有项目数据，输出根因分析和改进建议。过程改进的周期从“年”变成“周”，组织进化速度指数级提升。

五、实战建议：企业如何让GJB 5000B/CMMI与AI“双向奔赴”

如果你所在的组织正在推进GJB 5000B/CMMI，或者已经过了级但感到过程与实际“两张皮”，以下五条建议或许能给你启发。

1. 数据治理先行
没有干净、结构化、版本可控的过程数据，AI就是空中楼阁。先从测量分析实践域入手，把项目的规模、工作量、缺陷、变更等数据规范记录起来。

2. 选择一个实践域做AI试点
不要铺开所有领域，那只会乱成一锅粥。推荐从“验证与确认”或“测量分析”开始。这两个领域的AI工具相对成熟（测试生成、数据分析），见效快，且不直接冲击核心开发流程。

3. 把过程文档变成“可执行的AI工作流”
传统的过程文档是Word/PDF，没人看。试着把一部分活动转成Prompt模板、自动化脚本、规则引擎。例如需求评审过程，可以写一个Prompt：“请根据以下需求文本，对照GJB 438B标准，列出缺失项。” 这样过程就活了起来。

4. 培养“过程+AI”复合人才
EPG（工程过程组）成员需要学习AI的基本能力边界，不要一提AI就觉得“那是算法工程师的事”。开发人员也需要理解：使用AI不意味着可以绕过合规审查。两者需要共同设计新的人机协作过程。

5. 警惕“AI形式主义”
最大的陷阱是为了用AI而用AI。如果一个环节引入AI并没有降低缺陷率、缩短周期或节省成本，那就果断砍掉。始终记得GJB 5000B的范式转换：“为业务而过程”——AI同样只是手段，业务目标才是目的。

六、结语：底座更牢固，加速器才有意义

回顾这篇文章的起点：软件开发很难，这是永恒的。GJB 5000B/CMMI为我们提供了一套对抗不确定性的体系——它不是枷锁，而是让组织从“手工作坊”走向“工程化”的地基。

AI来了，它像一台强力加速器，能让跑在地基上的车飞驰。但如果地基是松散的、没有过程管理的“沙滩”，加速器只会让你陷得更深。

所以，请不要放弃过程改进。而是问自己一个新的问题：“我的GJB 5000B/CMMI体系，准备好迎接AI了吗？”

当你能回答“是”的时候，你就会发现：过程与AI的结合，才是软件组织真正的核心竞争力。

一句话总结：GJB 5000B/CMMI是工程能力的底座，AI是加速器。底座越牢固，加速器越有意义。

作者：王梅_Rose，质量与效能咨询顾问。近20年研发质量管理与项目管理经验。曾在多家企业担任质量总监、质量专家，主导多家企业通过CMMI/GJB 5000B评估，实现体系与敏捷开发的融合从0到1落地，成功率100%。

如果你有任体系及提质增效需求，欢迎扫码添加我的微信👇