Vibe Coding 人类与 AI 角色边界：把建议、执行与批准拆开

“让 AI 写，人类负责”听起来边界清楚，真正执行时却没有说明谁定义需求、谁能扩范围、谁判断测试是否有效、谁允许改数据库、谁对合并结果负责。于是 Agent 在十分钟内完成编辑、弱化测试并给出“已验证”总结，人类只剩下批准或推倒重来的二选一。Vibe Coding 团队需要的不是一句价值观，而是一张能约束每次任务的责任表。

这与AI 时代的工程团队文化讨论的协作观念不同。本文只处理操作合同：建议、执行、验证、风险接受和发布分别由谁完成，权限在什么条件下失效。NIST AI RMF 强调治理、角色和责任应贯穿 AI 风险管理；落实到编程 Agent，就是不能让“模型参与过”稀释具体个人或团队的责任。

先把一次任务拆成五种动作

同一个人可以承担多个角色，但五种动作不能混成“处理任务”：

1. 定义：确定问题、验收声明、非目标和风险档位；
2. 提议：阅读仓库后给出方案、写集、命令与未知项；
3. 执行：在获准路径修改文件或运行获准工具；
4. 验证：用独立于实现叙述的测试、检查和人工观察检验声明；
5. 批准：接受剩余风险，允许提交、合并、外部写入或发布。

Agent 适合提议、局部执行和重复验证，但不能从“我能生成补丁”推导出“我可以批准需求变化”。人类 task owner 对目标和范围负责，repository owner 对共享约束与合并负责，安全、数据或运维 owner 对各自高风险边界负责。小团队可由一人兼任，仍要在记录中说明他此刻以哪种责任作决定。

任务合同可以写成简表：

脏工作树安全改码提供文件所有权边界，选择性暂存与 Diff 自审说明为什么 Agent 生成的整份 diff 不应自动进入提交。权限表把这些规则放到任务入口，而不是事故发生后才引用。

风险越高，分离越严格

低风险文案或局部样式可以由同一 Agent 编辑并运行确定性检查，人类抽查结果。涉及公共 API、持久化、权限、支付、秘密、不可逆迁移或外部用户时，至少分开实现与批准；关键验证应由另一套工具、另一个 reviewer 或可复现人工步骤完成。不是因为人类天然不会错，而是不同视角让同一个错误更难同时污染实现与证明。

“人工在环”也可能只是橡皮图章。批准请求必须展示确切动作、目标对象、当前 revision、预期副作用、验证证据、失败行为和退出方式。资源、参数或代码代际变化后，旧批准失效。Agent 人工审批门处理运行时授权契约；开发任务同样不能把一句“可以”无限复用于后续 push、部署或数据库写入。

GitHub protected branches 能强制评审和状态检查等机制，但机制名不等于责任完成。一个叫 test 的绿色 check 可能没有覆盖新权限分支，一个批准者也可能只读了 AI 摘要。仓库门禁应绑定Definition of Done中的真实证据，最终批准者明确哪些风险已验证、哪些被接受、哪些仍阻断。

让升级条件写在任务开始时

Agent 发现以下任一情况就暂停：任务目标存在两种合理解释；需要改变验收或删弱测试；目标文件含来源不明修改；工具请求额外凭证；命令产生网络、费用或持久化副作用；恢复需要破坏性 Git 操作；结果无法用当前环境验证。暂停输出一个最小决策问题、已有证据和安全默认动作，不用大段建议迫使人类快速同意。

任务中途换人或换 Agent 时，责任不能靠聊天自动转移。使用Agent 到开发者接管检查点冻结现场，由接收者确认具体 generation、未决项和下一动作。未被接收的责任仍属于原 owner 或回到队列，不能因为 Agent 会话结束就变成“没人负责”。

最后复核责任表与实际轨迹：谁改了范围、谁执行了命令、哪项验证独立、谁接受了剩余风险。若所有列最后都写“AI 完成，人类确认”，说明边界仍是口号。可靠的 Vibe Coding 协作允许 AI 快速行动，但每次越过语义、权限和外部影响边界时，都能找到一个看过当前证据并愿意承担决定的人。