本文为方法论示例，成熟度判断需结合真实仓库、流程与运行数据重新验证。
AI 写代码不等于 AI 原生研发。真正的分界线是：一个变更能否从需求、实现、验证到发布形成可重复、可追责、可中止的闭环。
一句话判断
若 Agent 既能修改验收标准，又能产出代码并宣布通过，速度提高了，可信度却没有提高。
最小闭环
建议把流程固定为：需求与约束 → 人工确认并冻结验收 → Coding Agent 生成候选变更 → 独立 Validator 只读验证 → Gate 输出 READY / NOT_READY / BLOCKED → 有限次数修复 → 人工决定发布。
每次运行都绑定基础版本、候选版本、需求摘要、验收哈希和证据目录，避免旧报告被新代码复用。
三个成熟阶段
| 阶段 | 团队能力 | 退出标准 |
|---|---|---|
| 辅助编码 | 人驱动流程，AI 生成局部代码 | 修改可审查、测试可复现 |
| 可审计交付 | 变更有冻结契约与独立验证 | 过期证据会被 CI 拒绝 |
| 自治编排 | 多 Agent 可并行、恢复与取消 | 副作用幂等，失败可安全回滚 |
分阶段建设
第一阶段先统一变更级契约，为需求和验收分配稳定编号，并提供机器可读清单。第二阶段把单元测试、集成测试、桌面端健康检查和语义化 UI 验收汇入同一证据包；截图只能佐证，不能单独判定通过。
第三阶段再引入跨仓、并行验证或长周期恢复的 Agentic Graph，补齐幂等、租约、取消与副作用去重。不要让编排层先于可信的变更契约出现。
退出标准
选择一个真实但低风险的变更试点：冻结输入后生成候选版本，由独立验证器产出完整报告，CI 能拒绝过期或证据不全的结果。做到这一点，团队才从“Agent 辅助编码”跨入“变更级可审计交付”。
下一步：用一个真实变更跑完整闭环，记录每个手工接管点，再决定自动化优先级。