在技术开发公司的日常流程中，代码审查、测试计划编制、测试执行是把控交付质量的核心环节，而这几个环节，恰好精准对应了CMMI（能力成熟度模型集成）中PR（同行评审）与VV（验证与确认）这两个实践领域。
面对日益普及的AI技术，我们该如何将AI融入这些传统的CMMI实践领域？本文将从需求落地、标准制定、流程模板化到AI提示词的应用，为你梳理一套高效落地的实战思路。
一、核心环节对应的CMMI实践领域
先把最核心的对应关系讲清楚，避免落地时出现归属混淆，这也是CMMI 审计中的核心要点：
- 代码审查：核心归属同行评审实践域。无论是开发团队的Code Review，还是正式的技术审查，本质都是通过同行专家的视角，提前识别代码中的技术缺陷、逻辑漏洞、规范问题，匹配PR的核心实践要求。次要关联TS（技术解决方案）、VV（验证与确认）。
- 测试计划编制、测试过程执行：核心归属验证与确认实践域。VV的核心目标，就是通过验证确保 “你把产品做对了”（符合需求规格），通过确认确保 “你做了对的产品”（满足用户真实使用场景），而测试全流程正是实现这一目标的核心载体。如果测试计划需要开展同行评审，则关联PR实践域。
二、从客户需求出发，搭建可落地的检查清单体系
在我多年的工作经验里，PR和VV能不能不流于形式，核心就在于有没有一系列好用、贴合业务的检查清单。CMMI的实践要求是通用的，但每个项目的客户需求、业务场景是个性化的。
关于检查清单的搭建，我总结了一套从主观需求到客观标准的闭环方法，可落地性极强：
- 第一步：锚定客户主观需求，锁定核心检查项。先从客户的原始需求出发，哪怕需求是模糊的、主观的描述，也要先把核心诉求拆解出来，转化为检查清单的核心事项。比如客户要求“系统迁移不能影响现有业务的稳定性”，就可以先拆解出“脚本回滚机制”、“业务中断时长限制”等核心检查点，确保清单从一开始就贴合项目的核心目标。
- 第二步：参考行业标准与同行经验，做精简后补充。行业内的通用开发规范、编码标准、测试准则，都是很好的补充来源，但核心原则是只留和项目需求相关的内容，绝不照搬全抄。可参考的内容很多，但如果全部塞进清单，只会让执行人员抓不住重点。
- 第三步：转化为可落地的客观技术要求，固化标准。随着需求的细化、开发过程的推进，客户模糊的主观诉求会逐渐变成明确的、可量化的客观技术要求。这时候我们要做的，就是把这些技术要求写入检查清单，把主观期望，变成“要做到什么标准”的客观规则。比如把 “代码要规范”，细化成“命名规则、SQL权限控制、脚本首尾格式要求”等可直接检查的条目，让清单既有技术可执行性。
- 第四步：沉淀为组织级模板，持续迭代优化。最终成型的检查清单，就是PR和VV两个实践域的管理标准。在此基础上，我们可以基于公司原有的开发流程与项目实际情况，细化出标准化的模板：比如同行评审记录模板、测试计划模板、测试用例模板，放到公司的线上管理平台中。项目组发起评审、编制测试计划时，直接调用模板即可快速启动，既保证了CMMI要求的落地一致性，又不会给项目组增加额外的流程负担。
这里还要额外强调测试环节的一个核心要点：如果和客户合作较深，一定要搭建和客户生产环境一致的模拟测试环境。这是VV实践域高级要求，也是确保测试结果真实有效、最终交付能满足客户真实场景的核心前提。
三、把检查清单转化为AI提效利器
很多人会问，PR和VV的环节里，AI能做什么？会不会替代人？我的答案很明确：核心代码编写、核心需求把控必须由人主导，AI做标准化、重复性的辅助工作。
为什么核心工作必须人来做？因为AI对主观、模糊、需要反复确认的客户需求，理解准确率永远达不到 100%。尤其是客户需求边界不清晰、业务逻辑复杂的场景，只有人能精准把握需求的核心诉求、业务的隐性规则，代码的编写、方案的设计，必须由人来主导落地。
而AI的核心价值，在于把人从重复、标准化的审查工作中解放出来。尤其是当我们已经有了明确、客观、可量化的检查清单时，AI就能发挥出极强的执行能力。
给大家举一个我实操过的例子：我们给客户做系统迁移升级，在一段时间后，交付的升级包有非常明确的标准化要求，包括脚本的编写规范、首尾格式、SQL调用规则、权限控制、命名与路经规范、等，所有要求都已经沉淀到了检查清单里。我们就把这些检查规则，完整写入了AI提示词中，打造了一个专属的“迁移升级包审查助手”。
提示词的设计逻辑非常清晰，完全贴合PR的审查流程：
- 开头先完整写入检查清单的所有核心规则、技术标准；
- 明确审查流程：先逐文件检查，检查基本的语法问题，再逐段、逐行核对，检查结果标注清楚文件名、问题行号；
- 明确输出要求：针对每个问题给出具体的修改建议，最后对整个升级包给出整体合规性结论与质量评分。
用这套方法，原本需要开发人员花几个小时逐行核对的脚本文件，AI几分钟就能完成全量检查，而且不会出现人为的疏漏，既大幅提升了评审效率，又完美满足了CMMI对PR 过程可追溯、可记录的要求。
四、让CMMI要求融入流程
有了检查清单、有了AI辅助工具，最后一步就是把这些内容固化到公司的开发流程中，避免出现 “想起来就做，忙起来就忘” 的情况。
我的建议是，不要为了CMMI重构公司的研发流程，而是在原有流程的基础上，细化PR和VV的环节要求。比如：
- 代码提交前，必须先通过AI的标准化代码审查，再发起人工同行评审；
- 测试计划编制完成后，必须先通过测试检查清单，再进入测试执行环节，确保测试范围完整覆盖客户需求；
- 所有评审记录、测试结果数据、AI审查报告，全部同步到公司的项目管理平台，形成完整的过程证据链，既满足CMMI的审计要求，又方便后续的复盘与优化。
五、用数据支撑CMMI成熟度提升
CMMI的核心不是一次性过级，而是组织能力的持续提升，这就离不开全流程的数据收集与分析，这也是CMMI高成熟度等级的核心要求。
针对PR和VV两个环节，我们可以重点收集这些核心数据：
- PR环节：评审发现的代码缺陷数量、缺陷类型分布、代码稳定性、评审效率、过程合规性问题等；
- VV环节：测试用例通过率、需求覆盖率、缺陷分布、测试环境有效性等。
这些数据不仅是CMMI认证的核心证据，更是组织过程改进的核心依据。通过数据分析，我们可以找到研发流程中的薄弱环节、高频缺陷的根因，反过来优化我们的检查清单、工具模板、AI提示词与流程，逐步提升团队的开发能力。
评论