【系统架构设计】AI 原生开发流程：人机协同的架构实践
内容提要
本文探讨AI协作开发中的人机分工与审计流程，提出建立可审计状态机：在PR阶段按风险分级设置门禁，高风险变更需指定负责人审批；生产发布采用canary策略和错误预算冻结机制。责任划分上，平台负责硬性约束，批准者承担高风险意图，模型提供方不替代部署方的权限设计。最终将约束、流水线、上下文三要素组合成完整流程。
延伸解读
责任划分的工程边界
文章提出将责任分为平台、批准者和模型提供方三层：平台负责提供硬约束和审计日志，批准者承担高风险意图的审批，模型提供方不替代部署方的权限设计。这种划分避免了“谁点合并谁负责”的简单归责，也防止模型厂商承担超出其控制范围的责任。工程上可辩护的边界在于：控制措施在哪一层缺失，事故复盘就应指出哪一层的责任。
风险分级与门禁设计
PR阶段按副作用不可逆性分为低、中、高三级：低风险如文案注释，CI绿即可；中风险如功能代码，需一人审；高风险如权限放宽、迁移、支付，需指定owner审批甚至双人。特别强调“为过测而删测试或放宽schema”一律升为高风险。这种分级与流水线门禁（101、102）共用同一把尺子，避免人审成为瓶颈。
生产发布与错误预算冻结
生产发布采用canary渐进发布，SLI达标才全量，否则回滚。错误预算耗尽时冻结常规发布，防止AI高频合并持续烧预算。这一机制与SRE实践一致，但AI场景下更需严格执行，否则canary永远在烧预算。开发期人审与运行中HITL需分开建模：一个挡代码进入主干，一个挡工具副作用。
Q&A
AI 原生开发流程中，如何划分人机角色和责任面？
角色分为提议者（Agent 或人）、约束系统、流水线、上下文索引、审查者（人）、值班/SRE。责任面用三句话固定：机器可判定项未绿不得进入人审；人审签字覆盖意图与风险接受，不覆盖保证无缺陷；生产事故归因到批准路径与身份，而不是模型名字。
PR 阶段的风险分级和门禁是怎样的？
风险分级按副作用不可逆性分为低、中、高三级。低风险（如文案、注释）CI 绿即可或轻量审；中风险（功能代码、非破坏 API）需 CI + 一人审；高风险（权限/策略放宽、迁移、多租户边界、密钥、支付）需 CI + 指定 owner 审 + 可要求双人。为过测而删测试或放宽 schema 一律升为高风险。
生产发布时如何控制风险？
生产发布采用 canary 策略，渐进式发布，若 SLI 异常则回滚，SLI 正常则全量发布。同时，错误预算耗尽时冻结常规发布，防止 canary 持续烧预算。
开发期的人审与运行中的 HITL 有什么区别？
开发期的人审对应 PR 阶段的高风险审批，运行中的 HITL 对应 Agent 执行高风险操作时的同步确认或异步审批。两者不能混为一个按钮：一个挡工具副作用，一个挡代码进入主干/生产。
如何将约束、流水线、上下文和流程组合成完整体系？
101 约束作为 CI 硬闸门和运行时最小权限；102 流水线作为状态机中的 CI_Running、Canary、Rollback；103 上下文用于 Agent 开 PR 前检索和人审时核对引用路径；本篇流程提供风险分级、批准、归因和与 Conway 对齐的 owner。装配反模式包括只有 chatbot 没有门禁、只有门禁没有上下文、只有文档没有责任面。
AI 生成代码出错时，责任应该由谁承担？
架构上可辩护的划分是：平台责任（未提供或绕过硬约束导致的事故面）、批准者责任（绿灯后接受的高风险意图）、模型提供方责任（模型层问题按服务条款处理，不替代部署方的权限与门禁设计）。
落地 AI 原生开发流程时，有哪些检查清单？
检查清单包括：PR 是否记录生成者/批准者/策略是否放宽；高风险路径是否强制指定 owner；CI 未绿是否无法进入人审；生产是否有 canary + 错误预算冻结；运行中 HITL 与开发期人审是否分开建模；事故复盘是否能指出缺失的是约束、门禁、上下文还是批准。
