AI Coding Team 管理笔记
不审查代码，审查系统。不信任代码，信任验证。
背景
我写代码几乎 95% 以上是让 AI 写的。Python 后端我可以仔细 review，发现问题让 AI 改。但对于不熟悉的领域——比如 APP 开发、C++、Rust——我没法逐行审查。随着 AI 越来越强，多个 Agent 并行开发，代码量远超我能看的范围。
核心问题：注意力有限，如何保证交付质量？
答案是：从”审查代码”转变为”验证行为”。
马斯克：守住底线
马斯克管理 SpaceX 的方式——他不懂每个零件的制造细节，但他知道物理极限。
他的方法是第一性原理 + Failure Mode Analysis。不管方案多漂亮，他只问一个问题：
最坏情况是什么？
他常说的话：
- “给我解释最坏情况”（worst case explanation）
- “这个方案的物理极限在哪？”
- “如果这个东西失败，最可能因为什么？”
映射到软件——你不需要 review AI 写的 Rust 代码，但你能判断方案在系统层面是否合理：
- 并发瓶颈在哪？锁的粒度对不对？
- 分布式场景下会丢数据吗？
- 依赖的第三方服务挂了，降级策略是什么？
具体执行：让 AI 做 failure mode 分析，你 review 分析结果，不做取舍决策（速度 vs 质量 vs 成本）。
黄仁勋：守住质量
黄仁勋最核心的一个数字：NVIDIA 验证工程师的数量是设计工程师的好几倍。
他的哲学：写代码（设计）是便宜的，验证是贵的。不要试图理解每个细节，但要保证验证系统覆盖每个细节。
对应到 AI 团队管理——先建验证基础设施，再让 AI 干活：
- 单元测试框架（AI 写，CI 自动跑）
- 集成测试（核心流程端到端验证）
- 模糊测试（对 API 自动喂随机输入）
- 性能基准（每次改动前后对比）
- 安全扫描（dependency audit + SAST）
- lint / 类型检查（任何语言都有成熟工具）
- 金丝雀部署（灰度发布，线上自动验证）
每个任务的标准流程：
- 需求明确（你定义）
- AI 写实现
- AI 写测试
- 另一个 AI 做 code review
- 自动跑验证 pipeline
- 全绿 → 合并，红灯 → 打回
你只看两样东西：验证覆盖率 + 最终通过/失败报告。
核心理念：一个人检查所有人的代码不可扩展，但一套检查系统可以无限扩展。
雷军：守住价值
雷军跟黄仁勋完全不同的思路。黄仁勋建验证体系，雷军会说你搞得太工程师思维了。
雷军的哲学就七个字：专注、极致、口碑、快。
他的做法是基本可用就发布，让用户告诉你哪里不对。MIUI 早期版本 bug 多到离谱，但每周发一版更新，用户疯狂反馈，团队跟着改。
- “把砍掉的功能再做精简，还是太多了”
- “不要闭门造车，把东西扔出去”
- “口碑来自细节，细节来自亲身体验”
具体执行：
- 不追求完美，追求够快。”能跑、核心功能对，就发布”
- 每周花一小时，把自己当小白用户，走一遍核心流程
- 砍功能：先做一个功能做到极致，上线拿到反馈，再决定下一步
自动化测试验证不了的东西——体验、交互、需求真伪——只有真人能告诉你。
最好的 review 是用户的投诉。
三位一体
三个人分别守住不同的维度：
| 马斯克 | 黄仁勋 | 雷军 | |
|---|---|---|---|
| 守住 | 底线 | 质量 | 价值 |
| 防止 | 出大事才知道 | bug 率失控 | 做一堆没用的 |
| 核心动作 | 问最坏情况 | 建验证体系 | 问用户反馈 |
| 关键问题 | 会炸吗 | 测到了吗 | 有人用吗 |
缺任何一个维度都不行：没有马斯克，系统出大事才知道；没有黄仁勋，bug 率控制不住；没有雷军，做了一堆没用的东西。
架构设计怎么做
不是自己写文档，是跟 AI 讨论、拍板、让 AI 写。
你脑子里有想法/方向
↓
跟 AI 讨论（可能多轮）
"我觉得应该用事件驱动，你觉得呢？"
"并发场景下消息顺序怎么保证？"
AI 回复 → 你追问 → AI 补充 → 你再质疑
↓
你拍板："就这个方案，XX部分用A方案，YY部分用B方案"
↓
AI 写架构文档、接口定义、技术方案
↓
你 review 文档（确认 AI 有没有理解对你的决策）
↓
确认无误，文档就是开发契约
时间分配：
- 60% 跟 AI 讨论、质疑、头脑风暴
- 20% 拍板决策（选 A 不选 B，这个优先级高那个先不做）
- 20% review AI 写的文档和接口定义
你的核心竞争力不是”写文档写得漂亮”，是讨论过程中暴露出来的判断力和决策力。就像 CEO 不会自己写 PPT——CEO 提供观点和判断，秘书（AI）负责整理成文档。
AI 审 AI 的具体模式
Agent A 写代码（sonnet 级别）
Agent B 写测试（sonnet 级别）
Agent C review 代码（opus 级别，不同 prompt）
Agent D review 测试覆盖度（opus 级别）
自动 CI pipeline 跑一遍
全绿 → 合并，红灯 → 信息回到 Agent A 重做
你只需要看最终的通过/失败报告 + review AI 输出的 review 结论摘要。
日常工作分配
25% 跟 AI 讨论架构和方案 ← 核心：讨论、质疑、拍板
15% review AI 写的文档/接口定义 ← 确认 AI 理解对了你的决策
15% 跟 AI 对话质疑执行方案 ← 第一性原理问问题
15% Review 验证结果和报告 ← 测试覆盖率、CI 状态、运行指标
10% 端到端手动验证 ← 把自己当用户走一遍
10% 看关键代码，保持直觉 ← 极少数情况
10% 业务决策、外部协调 ← 跟真人相关的事
常见问题速查
| 情况 | 该怎么做 |
|---|---|
| 不熟悉 AI 用的语言 | 只看测试结果和 CI 报告，不看代码 |
| 多个 AI 并行开发 | 先建好验证体系，再让他们开工 |
| 不确定 AI 写的对不对 | 问 AI “失败模式是什么” |
| 不知道功能该不该做 | 先做最小版本给用户，用反馈决定 |
| 代码量太大看不过来 | 专注看架构图和数据流，不看实现 |
| AI 写的代码有性能问题 | 看 profiling 结果，不看代码本身 |
| 担心安全漏洞 | 配好 SAST 扫描和 dependency audit |
| 不知道质量如何 | 看测试覆盖率和线上监控指标 |
写在最后
你的角色不是不懂技术的 PM，是懂物理定律的系统架构师。
PM 只管”要做什么”，你管”怎么做才不会炸”。你不是在管理一群程序员，你是在建设一个质量保障体系，然后让 AI 在这个体系里自由发挥。