人机协作模式
人类与 AI 的角色边界与分工
规则:人类与 AI 在研发流程中承担不同角色,人类负责决策与兜底,AI 负责执行与加速。角色边界必须清晰,不得越权。
[Requirement] 人类是最终决策者和责任人,AI 是辅助执行者,AI 不得在无人类确认的情况下做出不可逆决策。
[Requirement] AI 的所有产出必须经过人类确认后方可进入生产环境。
[Standard] 按”决策权”和”执行权”两个维度划分人机角色。
| 角色 | 决策权 | 执行权 | 说明 |
|---|---|---|---|
| 人类(架构师/工程师) | ✅ 拥有 | ✅ 拥有 | 最终决策者,承担质量责任 |
| AI(编码助手) | ❌ 无 | ✅ 拥有 | 执行编码、测试、文档等任务 |
| AI(评审助手) | ❌ 无 | ✅ 辅助 | 提供评审建议,最终审批权在人类 |
| AI(自动化流水线) | ❌ 无 | ✅ 受限 | 仅执行预设规则,异常时中断并通知人类 |
| 职责 | 说明 | 不可下放给 AI |
|---|---|---|
| 需求决策 | 确定做什么、不做什么 | ✅ |
| 架构选型 | 选择技术方案和框架 | ✅ |
| 风险审批 | 安全、合规、上线审批 | ✅ |
| 最终评审 | 代码合并的最终审批 | ✅ |
| 故障决策 | 故障时的回滚/修复决策 | ✅ |
| 职责 | 说明 | 可自动执行 |
|---|---|---|
| 代码生成 | 按规范生成代码、测试、文档 | ✅(需人类确认) |
| 代码搜索 | 定位相关代码、符号、调用链 | ✅ |
| 静态分析 | lint、类型检查、安全扫描 | ✅ |
| 测试执行 | 运行单元测试、集成测试 | ✅ |
| 文档编写 | 生成注释、README、API 文档 | ✅(需人类确认) |
反模式:
- 让 AI 决定”这个功能要不要做”
- 让 AI 自行审批并合并 PR
- 出了故障让 AI 自己决定回滚还是修复
- 认为”AI 说没问题就没问题”,人类不做最终确认
规则:人机分工遵循”AI 做重复、机械、大规模的事;人类做判断、决策、兜底的事”。
[Standard] 任务分配按”确定性”和”创造性”两个维度划分:高确定性、低创造性的任务给 AI;低确定性、高创造性的任务给人类。
[Default] 推荐的人机分工比例:AI 执行 70% 的编码工作量,人类投入 30% 精力在设计、评审、决策上。
| 任务类型 | 确定性 | 创造性 | 负责方 | 示例 |
|---|---|---|---|---|
| 样板代码生成 | 高 | 低 | AI | CRUD 接口、DTO、序列化 |
| 单元测试编写 | 高 | 中 | AI 主,人类审 | 正常/边界/异常用例 |
| 代码重构 | 中 | 中 | 人机协作 | 提取公共方法、重命名 |
| 算法实现 | 中 | 高 | 人类主,AI 辅 | 核心业务算法 |
| 架构设计 | 低 | 高 | 人类 | 系统拆分、技术选型 |
| 安全审计 | 低 | 高 | 人类主,AI 辅 | 漏洞分析、权限设计 |
| Bug 排查 | 中 | 中 | 人机协作 | 定位根因、修复 |
| 文档编写 | 中 | 中 | AI 主,人类审 | API 文档、注释 |
任务来了 │ ├─ 是否涉及不可逆操作(删库/发布/权限变更)? │ └─ 是 → 人类负责,AI 仅提供建议 │ ├─ 是否有明确规范和模板? │ └─ 是 → AI 执行,人类审核 │ ├─ 是否需要业务判断或权衡? │ └─ 是 → 人类负责,AI 辅助分析 │ └─ 是否为重复性、机械性工作? └─ 是 → AI 执行,人类抽检示例:
任务:实现用户注册接口
人类负责:- 确定接口契约(路径、方法、请求/响应结构)- 确定安全策略(密码哈希算法、邮箱验证机制)- 最终 Code Review
AI 负责:- 生成接口实现代码- 生成单元测试- 生成 API 文档草稿- 运行 lint/测试/安全扫描反模式:
- 让 AI 设计整个系统架构
- 让人类手写所有 CRUD 样板代码
- 人类不审核就直接采用 AI 生成的核心算法
规则:人机协作遵循”人类定义目标 → AI 执行 → 人类审核 → 迭代优化”的闭环,每个闭环必须有人类确认节点。
[Requirement] 每个协作闭环必须包含至少一个人类确认节点(Checkpoint),无确认不得自动推进。
[Standard] 协作流程分为 5 个阶段,每阶段有明确的人机交互点。
┌──────────────┐│ 1. 需求定义 │ 人类:明确需求、验收标准│ (人类主导) │ AI:辅助澄清、补充边界场景└──────┬───────┘ ▼┌──────────────┐│ 2. 方案设计 │ 人类:确定技术方案、架构决策│ (人类主导) │ AI:提供候选方案、分析利弊└──────┬───────┘ ▼┌──────────────┐│ 3. 编码实现 │ AI:生成代码、测试、文档│ (AI 主导) │ 人类:关键节点确认、答疑└──────┬───────┘ ▼┌──────────────┐│ 4. 验证评审 │ AI:执行自动化检查│ (人机协作) │ 人类:Code Review、逻辑确认└──────┬───────┘ ▼┌──────────────┐│ 5. 发布上线 │ 人类:最终审批、发布决策│ (人类主导) │ AI:执行发布脚本、监控└──────────────┘| 模式 | 说明 | 适用场景 |
|---|---|---|
| 问答式 | 人类提问,AI 回答 | 技术咨询、方案讨论 |
| 生成式 | 人类给需求,AI 生成代码 | 编码、测试、文档 |
| 审查式 | AI 生成后,人类审查 | Code Review、质量把关 |
| 迭代式 | 多轮”生成-反馈-修改” | 复杂需求、渐进完善 |
| 代理式 | 人类授权 AI 执行一系列操作 | 重复性任务、明确规则的任务 |
示例:
迭代式协作示例:
人类:实现用户注册接口,要求邮箱唯一。AI:[生成代码 v1]人类:v1 没有处理邮件发送失败的情况,补充一下。AI:[生成代码 v2,增加邮件失败的异常处理]人类:v2 邮件失败时整个注册回滚了,改成记录日志但不回滚。AI:[生成代码 v3,邮件失败仅记录日志]人类:v3 可以,提交 PR。反模式:
- 人类把需求扔给 AI 后完全不管,等 AI 自己做完
- AI 生成后人类只看一眼就 Approve,不认真 Review
- 协作中没有确认节点,AI 一路自动执行到上线
规则:人机协作存在不可逾越的红线,以下事项必须由人类亲自完成,AI 不得代劳。
[Requirement] 红线事项无例外,任何场景下 AI 不得自动执行,必须人类手动操作并确认。
| 编号 | 红线事项 | 原因 | 必须人类操作 |
|---|---|---|---|
| H1 | 生产环境发布审批 | 影响线上稳定性 | ✅ |
| H2 | 数据库结构变更(DDL)审批 | 不可逆、影响数据 | ✅ |
| H3 | 权限/鉴权代码变更审批 | 安全风险 | ✅ |
| H4 | 密钥/凭证的生成与轮换 | 安全风险 | ✅ |
| H5 | 生产数据的导出与删除 | 数据合规 | ✅ |
| H6 | 故障应急决策(回滚/扩容) | 影响面大 | ✅ |
| H7 | 法律合规相关决策 | 法律责任 | ✅ |
| H8 | 第三方依赖引入审批 | 供应链安全 | ✅ |
是否触碰红线? │ ├─ 操作是否不可逆? → 是 → 红线 ├─ 操作是否涉及生产数据? → 是 → 红线 ├─ 操作是否涉及安全权限? → 是 → 红线 ├─ 操作是否影响线上稳定性? → 是 → 红线 └─ 以上都否 → AI 可辅助,人类确认示例:
# 允许:AI 生成 DDL 脚本,人类审批后执行AI: 这是添加 user 表的迁移脚本,请确认后执行。人类: [审查脚本] 确认,执行。
# 禁止:AI 直接在生产库执行 DDLAI: 检测到表结构需要变更,已自动执行 ALTER TABLE。→ ❌ 红线违规反模式:
- 让 AI 自动审批生产发布
- AI 自动执行数据库迁移
- AI 自动轮换生产环境密钥
- AI 自动导出用户数据做”分析”
规则:人机协作的效率优化目标是”让 AI 做更多,让人类做更有价值的事”,通过标准化上下文、模板化 Prompt、自动化校验来提升协作效率。
[Standard] 团队应沉淀”高频任务 Prompt 模板”,减少重复沟通成本。
[Standard] 将重复性的校验步骤自动化(lint/测试/安全扫描),人类只处理自动化发现的问题。
[Suggestion] 定期复盘人机协作中的低效环节,优化 Prompt 和流程。
[Suggestion] 建立团队级 AI 使用最佳实践库,共享高效的协作模式。
| 手段 | 说明 | 预期收益 |
|---|---|---|
| Prompt 模板化 | 高频任务沉淀模板 | 减少 50% 沟通时间 |
| 上下文标准化 | 统一项目上下文注入方式 | 减少 AI 理解偏差 |
| 校验自动化 | lint/测试/安全全自动 | 人类只看异常结果 |
| 代码片段库 | 沉淀常用代码模式 | AI 生成更符合规范 |
| 评审清单化 | Code Review 使用 Checklist | 评审效率提升 30% |
| 指标 | 定义 | 目标值 |
|---|---|---|
| AI 代码采纳率 | AI 生成代码被合入的比例 | ≥ 70% |
| 单次评审耗时 | 人类 Review 一个 PR 的平均时间 | ≤ 30 分钟 |
| 需求到上线周期 | 从需求确认到上线的时间 | 缩短 40% |
| AI 返工率 | AI 生成代码被要求修改的比例 | ≤ 30% |
示例:
优化前:人类:"帮我写个接口"AI:[生成代码,但不符合项目规范]人类:"不对,我们用的是 SQLAlchemy 2.0,参数名要 snake_case"AI:[重新生成]人类:"测试呢?"AI:[补充测试]...(来回 5 轮)
优化后(使用模板 + 标准上下文):人类:[选择"新增接口"模板,填写参数]AI:[一次性生成符合规范的代码 + 测试 + 文档]人类:[Review,1 轮通过]反模式:
- 每次都从零开始写 Prompt,不使用模板
- 人类手动跑 lint、跑测试,不做自动化
- 不沉淀团队的 AI 使用经验,每个人自己摸索