Appearance
Part 6: 团队采用建议 + Q&A (10-15 min)
核心思路：给出可落地的建议，但也坦承这只是一个起点
6.1 先讲一个「里程碑式」的反面案例
2025 年 10 月，一位热情的外行用户给 OCaml 编译器项目提交了一个 13,000 行的 PR [1]。
这个 PR 是用 Claude 全程生成的，目的是实现 DWARF 调试支持。结果呢？被 maintainer 锁定并拒绝了。
text
┌─────────────────────────────────────────────────────────────────────┐
│ OCaml 13K PR 事件时间线 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 提交者: 一位热情的外行用户 │
│ 工具: Claude AI │
│ PR 规模: 13,000+ 行代码 │
│ │
│ 问题 1: 没有事先讨论就提交巨型 PR │
│ └─ 浪费了 volunteer maintainer 的时间 │
│ │
│ 问题 2: AI 生成的代码里有错误的版权声明 │
│ └─ 把代码归属给了 Mark Shinwell（一个真实的人） │
│ │
│ 问题 3: 被问到为什么有这个归属时，提交者说： │
│ 「Beats me. AI decided to do so and I didn't question it」 │
│ （我也不知道，AI 决定这么做的，我没质疑） │
│ │
│ 问题 4: 把大量 .md 文件加进了 .gitignore │
│ └─ 明显没有认真 review 过自己提交的代码 │
│ │
│ 结果: PR 被锁定，maintainer 非常耐心但明确地拒绝了 │
│ │
└─────────────────────────────────────────────────────────────────────┘社区的反应：
「开源项目的维护者完全有能力自己用 LLM 生成代码。你提交一段自己都不理解的 AI 代码，对项目毫无贡献。」
另一个评论更直接：
「提交者声称 AI 对代码有『深入理解』，却无法解释自己提交的基本细节——这暴露的是拒绝思考的态度。」
为什么这件事重要？
这不是个例。类似的事情会越来越多，在各种场景下发生。
想想我自己的 Home Assistant 插件——4000 行代码，我给的预期是半年分 20 个 PR 来提交。为什么？因为但凡有一行代码 Reviewer 有点疑惑，都要解释半天。这是对维护者时间的尊重，也是对自己代码的负责。
LLM 不会带来「平权」。能力不足的话，你甚至没法意识到「这是一件很糟糕的事情」。
不过，Hacker News 上也有一条很灵魂拷问的评论：
「如果一位经理声称他监督了开发员工的工作，而代码质量并不像经理想的那样好，你会说『这位经理因为员工的存在而脑子坏了』吗？」
这个类比值得深思——AI 到底是「员工」还是「工具」？监督 AI 输出和监督员工工作，标准应该一样吗？
作者观点
我没有答案。但我觉得，至少在现阶段，对 AI 输出的审查标准应该比对人类同事更严格，因为 AI 不会为错误负责，你会。
6.2 分阶段采用策略
来自 Pete Hodgson 和 Jellyfish 的建议：
text
┌─────────────────────────────────────────────────────────────────────┐
│ 团队采用 AI 编程的三个阶段 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 阶段 1: 实验 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 理解能力和局限 │ │
│ │ 活动: │ │
│ │ · 小范围试用（1-2 人先跑起来） │ │
│ │ · 记录使用经验（踩了什么坑、学到什么） │ │
│ │ · 尝试不同场景（哪些适合 AI、哪些不适合） │ │
│ │ │ │
│ │ ← 我们团队目前在这里 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段 2: 采用 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 成为日常工具 │ │
│ │ 活动: │ │
│ │ · 团队培训（今天这个分享算是开始） │ │
│ │ · 共享配置（CLAUDE.md、MCP 配置） │ │
│ │ · 建立 Code Review 规范 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段 3: 影响 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 衡量实际效果 │ │
│ │ 活动: │ │
│ │ · 对比使用前后的效率指标 │ │
│ │ · 识别最佳实践，固化成规范 │ │
│ │ · 持续迭代改进 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘作者建议
不要急着进入「采用」阶段。先让几个人把坑踩够，再推广。
6.3 代码审查：一条底线原则
「提交代码的工程师始终对代码质量、安全和功能负责，无论 AI 是否参与。」
这是 Oxide 公司的核心原则 [2]，也是我认为最重要的一条。
对 AI 生成代码的审查，应该多问两个问题：
| 问题 | 为什么重要 |
|---|---|
| 「为什么选择这个方案？」 | 如果答不上来，说明你没理解代码 |
| 「考虑了哪些替代方案？」 | 如果没考虑，说明你只是接受了 AI 的第一个建议 |
回想 OCaml 那个 13K PR 的提交者——他被问到版权归属时说「AI 决定的，我没质疑」。这就是典型的没有 review 自己提交的代码。
6.4 Oxide 公司的五个核心价值
Oxide 是一家做服务器硬件+软件的公司，他们在 RFD 576 中详细讨论了如何在工程团队中使用 LLM [2:1]。我觉得这五条很有参考价值：
| 原则 | 解释 | 我的理解 |
|---|---|---|
| 责任 | 人类判断始终在环内，对所有输出负责 | 不能说「AI 写的，我不知道」 |
| 严谨 | LLM 应该锐化思考而非替代思考 | 用 AI 加速，不是用 AI 偷懒 |
| 同理心 | 考虑内容创作者和消费者 | 想想 Reviewer 的时间，想想维护者的负担 |
| 团队合作 | 保持真诚的沟通 | 如果用了 AI，就说用了；不要假装是自己写的 |
| 紧迫感的平衡 | 不为速度牺牲质量 | 快不是目的，好才是 |
6.5 资源推荐
入门必读：
| 资源 | 说明 |
|---|---|
| Claude Code Best Practices | Anthropic 官方最佳实践 |
| Claude Code Docs | 官方文档，遇到问题先查这里 |
| 如何避免在 AI 时代技能退化 | 中文，Part 5 引用过的那篇 |
进阶阅读：
| 资源 | 说明 |
|---|---|
| Oxide RFD 576 | 企业级 LLM 使用策略，写得非常好 |
| 一个半月高强度 Claude Code 使用后感受 | 喵神的文章，中文，实战经验 |
| Context Engineering Guide | 深入理解 Context Engineering |
工具相关：
| 资源 | 说明 |
|---|---|
| Writing a good CLAUDE.md | 如何写好项目配置文件 |
| AI Agents Roadmap | AI Agent 学习路线图 |
6.6 Q&A：可能会被问到的问题
预留 5-10 分钟的讨论时间。
我预期可能会被问的问题：
| 问题 | 我的简短回答 |
|---|---|
| 「Claude Code 要钱吗？」 | 要，按 token 计费，公司应该会统一采购 |
| 「和 ChatGPT 比哪个好？」 | 写代码的话，Claude 目前更强；但选型要看具体场景 |
| 「会不会泄露公司代码？」 | Anthropic 声称不会用 API 数据训练模型，但敏感代码还是要注意 |
| 「我完全不懂 AI，能用吗？」 | 能，但建议先从简单任务开始，不要一上来就 Vibe Coding |
| 「AI 会取代程序员吗？」 | 短期不会，但会改变工作方式；不用 AI 的程序员可能会被用 AI 的程序员取代 |
| 「英文不好影响大吗？」 | 有影响但不大，Claude 中文支持不错；关键是学会组织 Context |
但说实话，这里很多知识都是「司机的知识」——我只是转述者，很多我自己也没有深刻理解。
「司机的知识」来自查理·芒格的比喻：司机听了很多遍演讲，能把内容背得滚瓜烂熟，但被问到深入问题就露馅了。
所以如果大家有问题，我们可以一起探讨。我能回答的就回答，回答不了的，至少可以记下来，之后一起研究。
6.7 最后一句话
用 AI 加速你已经理解的工作，而不是用它跳过你应该学习的过程。
这是我这几个月踩坑下来最深的体会。希望对大家有帮助。
[!TODO] 素材准备
- [ ] OCaml 13K PR 的截图（GitHub PR 页面）
- [ ] 整理一个团队共享的「入门清单」
- [ ] 准备几个 Q&A 的详细回答备用
参考资料
💬 L4 | AI has a deep understanding of how this code works | Hacker News - 2025 年 10 月 OCaml 编译器 13K 行 AI 生成 PR 事件的社区讨论，展示了 AI 辅助编程的典型反面案例。 ↩︎
📝 L3 | Oxide RFD 576: Using LLMs at Oxide - Oxide 公司关于企业级 LLM 使用的详细策略文档，强调责任、严谨、同理心等核心价值观。 ↩︎ ↩︎