过去一年，我们在宣讲会、客户拜访、行业群里被问得最多的一句话是：
"AI 生成的 ASPICE 文档，评估师认不认？"
作为天天在评估现场的人，我们的诚实回答是：有的认，有的当场挂。区别不在"是不是 AI 写的"，在于产物有没有项目上下文、证据链和不编造。
这篇文章把我们内部使用的评审清单公开出来——AI 产物进场前，我们按这三档分类。
第一档：AI 做得好，评估基本能过
这类产物的共同特征是结构化程度高、有明确模板、判断规则客观：
- 过程描述与裁剪文档：ASPICE 过程模型本身是标准化的，AI 结合项目裁剪说明生成过程描述，质量稳定；
- 追溯矩阵：需求条目间的关联建立与影响分析，AI 做得比人快且不容易漏；
- 评审检查单、会议纪要骨架、整改跟踪表：格式类产物，AI 生成后人工确认即可；
- 文档排版与交叉引用：版本、页码、引用关系，机器天然比人可靠。
这类产物大约占合规文档量的 60–70%，AI 生成 + 工程师确认，评审首过率可以稳定在 90% 以上。
第二档：AI 能起草，必须人工改
这类产物框架可以 AI 给，血肉必须项目填：
- 项目计划与里程碑论证：AI 能生成计划模板，但资源、依赖、风险必须结合真实项目约束填写；AI 写的"通用风险"在评估师眼里一眼假；
- 需求条目的验收准则：AI 能给句式框架，但验收阈值、边界条件来自真实设计决策；
- 问题根因分析：AI 能列出 5Why 结构，根因必须是团队复盘出来的。
评估现场的典型翻车：评估师问"这条验收准则的阈值是怎么定的"，工程师答不上来——因为他没参与写，只是点了"生成"。
第三档：AI 不能碰，必须人来
- 过程能力定级的判断依据：CL2 还是 CL3，是评估师基于证据的专业判断，AI 生成的"自评"只能做参考；
- 组织级过程的适用性裁剪决策：为什么裁掉某个 BP，需要管理层与过程组的真实决策记录；
- 任何"证据"本身：测试记录、评审签到、决策邮件——AI 绝对不能生成证据，只能帮助组织和呈现证据。AI 编造证据是红线，发现即评估事故。
为什么"AI 初稿 + 评估师终审"模式能过评估
我们的做法是把评审前置：DPAI 生成的每一份关键产物，在交付客户前先过我们自有 ASPICE 评估师团队的评审——用评估现场的口径做出厂检验。
这样做解决的是 AI 合规工具最大的信任危机：工具厂商说自己能过评估，但出问题时背锅的是供应商。我们的口径反过来——评估师团队对 AI 产物做终审背书，出了问题我们先改。
给正在选型团队的一句话
判断一个 AI 合规工具靠不靠谱，别问"你的 AI 多先进"，问："生成的工作产物，谁按评估师口径审？出了问题谁负责？" 答不上来这两句的，文档写得再漂亮也别买。
