AI 写代码，但责任在「人」
AI 能高效地写代码，但它产出的代码，不能没人审查就合并。团队协作的核心变化是：AI 负责「写得多、写得快」，人负责「把得严、管得好」。
这一节，建立一套和 AI 协作的代码评审规范，并用在 mcp-hub 的变更上。
一个基本认知：AI 是「高产工人」，不是「权威」
AI 写的代码可以又快又多，但它：
- 可能理解错需求
- 可能引入边界错误
- 可能忽略既有规范
所以评审不是「走流程」，而是必要的质量关卡。
对 mcp-hub 尤其要提醒：AI 帮忙「加一个服务」时，可能顺手改了别的字段、动了不该动的配置。AI 高产，但它的产出必须过审。
一套可落地的评审流程
用「AI 产出 → 人机双审 → 合并」三段式：
1. AI 完成改动 → 提交（进分支）
2. 人审 + AI 辅助审（用审查技能） → 找出问题
3. 修复 → 再审 → 测试通过 → 合并
关键：AI 的活先进分支，评审通过再合并，别让它直接改主干。
对 mcp-hub 团队：给「改服务清单」「改接入规范」这类改动定硬规矩——必须走这个三段式，别直接推到共享主干。
评审的「双审」怎么分工
| 审 | 谁 | 看什么 |
|---|---|---|
| AI 初审 | 审查技能 | 逻辑、边界、异常、可读性、性能 |
| 人终审 | 开发/负责人 | 需求理解、架构合理性、业务正确性 |
AI 审「代码本身」，人审「方向对不对」。两者互补。
对 mcp-hub：AI 初审可以检查「服务清单格式对不对、字段全不全、有没有语法错」，人终审则要确认「这个服务该不该接、凭据是不是安全、owner 是不是对的」。
评审的规范要点
- 分档输出：AI 审查按「必须改 / 建议改 / 可不改」分档，人优先处理「必须改」
- 关键逻辑人工确认：核心算法、安全相关、数据操作，必须人工看懂
- 高风险改动加门禁：涉及数据、生产、安全，要测试 + 双人
对 mcp-hub：涉及凭据、权限、写操作的改动，一律按「高风险」对待，必须双人 + 人工确认，不能只看 AI 初审就放行。
一个可复制的评审 prompt
给 mcp-hub 团队一个「AI 初审」的 prompt，照着用：
帮我审查这次 mcp-hub 的改动（git diff）：
1. 按「必须改 / 建议改 / 可不改」分档列出问题
2. 特别检查：服务清单格式、凭据有没有硬编码、
权限/写操作是否有风险、owner 是否正确
3. 只报真问题，别刷存在感
让 AI 初审标准化，人只看「必须改」优先处理。
落地几个具体做法
- 写一个「代码审查」技能，让 AI 初审标准化
- 规定合并门槛：测试通过 + 无「必须改」未处理 + 关键逻辑人审过
- 保留记录：评审意见、改动过程可回溯
对 mcp-hub：把这个「代码审查」技能也放进团队仓库，和 mcp-hub 一起分发——审 mcp-hub 的改动、也审别的改动，一套规范通用。
一个「审查技能」的样子
把 AI 初审固化成技能，团队共用：
---
description: 团队统一的 AI 代码初审
---
# 代码审查
触发：审查任一改动（git diff）时执行。
要求：
1. 按「必须改 / 建议改 / 可不改」分档输出
2. 每档下写明：文件、位置、问题、理由、建议
3. 重点检查：边界、异常、安全、可读性、性能
4. 只报真问题，不刷存在感，不罗列风格噪音
输出格式：
## 必须改
- [文件:位置] 问题：… 理由：… 建议：…
## 建议改
…
## 可不改
…
有了这个技能，AI 初审不再是「看心情」，而是每次都有统一产出，人直接看「必须改」优先处理。
别踩的坑
- 全信 AI：AI 说没问题就放行 → 危险
- AI 直接改主干：没进分支就改共享分支 → 出乱子
- 只有 AI 审：缺了「人看方向」这一环
对 mcp-hub：这三个坑在团队场景下风险翻倍——mcp-hub 是共享的，一次乱合并可能影响全员能触达的服务。
落地练习：给 mcp-hub 走一次完整评审
这一节，用真实改动走一遍评审流程。
跟着这三步走：
- 让 Claude Code 帮你给 mcp-hub 加一个新服务（或改一条规范），先提交进分支
- 用上面的评审 prompt 让 AI 初审，按「必须改 / 建议改」分档列出
- 你作为人终审：确认「这个改动方向对不对、凭据/权限安全不」，把必须改的修掉再合并
你会怎么判断做对了？——这个改动走了「进分支 → 双审 → 合并」，AI 初审分档清楚、人终审确认了方向和安全，并且有评审记录，就算过关。
卡住了怎么办？ 没有真实改动可审？用上一节的服务清单随手改一处格式错误来练。AI 初审不理想？把「只报真问题」写得更强调。分不清谁是终审？记住：人永远为最终质量负责。
常见坑：把「AI 初审」当成了「评审的全部」
一个常见坑：让 AI 初审了一下，看到「没问题」，就直接合并了。AI 初审只看代码本身（格式、边界、语法），它不判断「这个改动方向对不对、该不该这么接」。
mcp-hub 尤其危险：AI 可能把服务清单格式审得很「干净」，但根本没发现「这个服务权限开太大了」这种方向性问题。AI 初审是「检查工」，人是「方向官」——两者都要，缺了人的终审，等于没审。
小结
- AI 高产，但责任在人——评审是必要的关卡
- 三段式：AI产出 → 人机双审 → 合并
- AI 审代码本身，人审方向
- 分档输出、关键逻辑人工确认、高风险加门禁
- mcp-hub 的改动（尤其涉及凭据/权限）必须走完整评审
下一节，讲多环境与分支策略管理。