Appearance
Part 4: 使用边界与团队采用
4.5 使用边界
4.5.1 什么时候该用 / 不该用 AI
text
┌─────────────────────────────────────────────────────────────────────┐
│ AI 使用场景光谱 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 放心用 谨慎用 最好别用 │
│ ◄─────────────────────────────────────────────────────────────► │
│ │
│ · 拼写检查 · 业务逻辑实现 · 安全关键代码│
│ · 格式化 · 不熟悉的领域 · 架构决策 │
│ · 样板代码 · 性能优化 · 加密实现 │
│ · 文档草稿 · 并发代码 · 认证授权 │
│ · 单元测试 · 数据库设计 · 支付处理 │
│ · 代码解释 · API 设计 · 合规代码 │
│ · 重构建议 · 错误处理策略 · 你不打算 │
│ · 命名建议 · 第三方集成 理解的代码 │
│ │
│ 你完全理解 你需要仔细审查 你必须亲自写 │
│ AI 只是加速 AI 是参考意见 或深度审查 │
│ │
└─────────────────────────────────────────────────────────────────────┘引用 软件工程的「纯」与「不纯」：
text
┌─────────────────────────────────────────────────────────────────────┐
│ 纯粹工程 vs 不纯粹工程 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 纯粹工程 不纯粹工程 │
│ (Pure Engineering) (Impure Engineering) │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ · 你非常了解的问题 │ │ · 你只有粗浅理解 │ │
│ │ · 社区不熟知 │ │ · 问题不新颖 │ │
│ │ （值得研究） │ │ 只是对你新 │ │
│ │ · 在专长极限边缘 │ │ · 很少处理透彻 │ │
│ │ · 有无限时间 │ │ 理解的问题 │ │
│ │ │ │ · 紧迫的截止日期 │ │
│ └──────────┬──────────┘ └──────────┬──────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ AI 帮不上忙 │ │ AI 可能比你更聪明 │ │
│ │ （需要深度思考） │ │ （快速出活） │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘作者观点
AI 最擅长的是「不纯粹工程」——那些你知道怎么做、但做起来很繁琐的事情。而「纯粹工程」——需要深度思考和创造性的部分——还是得靠你自己。
4.5.2 技能退化警示
开发者自述：
「我发现自己不再写代码，只是等 Copilot 给我代码。我已经忘了每天都在用的函数和类型。」
三个需要警惕的征兆：
| 征兆 | 表现 | 后果 |
|---|---|---|
| Code Review 变水 | 基础错误开始漏过（线程安全、逻辑问题） | 代码质量下降，技术债累积 |
| 调试能力退化 | 能快速生成代码，但无法定位问题 | 遇到 AI 搞不定的问题时完全不知道从哪下手 |
| 心智模型侵蚀 | 只会「调用」不会「设计」 | 系统越写越乱，最后只能推倒重来 |
X-Y Problem 陷阱：
python
# ❌ 问方案，不问问题
# 问 AI："怎么让这个循环更快？"
for i in range(len(data)): # AI 优化了循环
process(data[i])
# ✅ 理解本质：先问「为什么慢」
# 发现瓶颈是 I/O，不是循环
async def process_all(data):
await asyncio.gather(*[process(d) for d in data])X-Y Problem：你想解决 X，却问 AI 怎么做 Y。AI 会认真帮你优化 Y，但 X 才是真正的问题。
一条判断标准：
专家观点 — Simon Willison [^55]
「我的黄金法则是：我不会提交任何我无法向别人解释的代码。」
预防策略：
- 定期 Unplugged 编程（关闭 AI 辅助）
- 保持学习日志，记录 AI 帮你做的事
- 刻意练习判断力 — 决定何时用 AI、何时手写
延伸阅读
The Paradox of Augmentation [2] — AI 初期提升效率，长期导致技能退化的数学模型
4.5.3 成本意识
text
┌─────────────────────────────────────────────────────────────────────┐
│ 对话累积的成本问题 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 第 1 轮对话：输入成本 500 tokens │
│ 第 2 轮对话：输入成本 2000 tokens（包含第 1 轮历史） │
│ 第 3 轮对话：输入成本 4000 tokens（雪球越滚越大） │
│ ... │
│ 第 10 轮对话：输入成本可能已经是第 1 轮的 20 倍 │
│ │
│ 这就是为什么 Claude Code 有 /clear 命令 │
│ │
└─────────────────────────────────────────────────────────────────────┘Token 效率优化建议：
| 建议 | 说明 |
|---|---|
定期 /clear | 任务完成或对话偏离时，清空重新开始 |
| 精简 CLAUDE.md | 不要塞太多内容，60 行以内最佳 |
| MCP 不要装太多 | 每个 MCP Server 的工具定义都占 Context |
| 具体的 prompt | 一次说清楚，避免来回澄清 |
| 分任务处理 | 大任务拆成小任务，每个任务独立对话 |
4.6 团队采用
4.6.1 OCaml 13K PR 案例
2025 年 11 月，一位热情的开发者给 OCaml 编译器项目提交了一个 13,000 行的 PR [3]。
这个 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 非常耐心但明确地拒绝了 │
│ │
└─────────────────────────────────────────────────────────────────────┘教训：
「提交代码的工程师始终对代码质量、安全和功能负责，无论 AI 是否参与。」
4.6.2 分阶段采用策略
来自 Pete Hodgson 和 Jellyfish 的建议：
text
┌─────────────────────────────────────────────────────────────────────┐
│ 团队采用 AI 编程的三个阶段 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 阶段 1: 实验 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 理解能力和局限 │ │
│ │ 活动: │ │
│ │ · 小范围试用（1-2 人先跑起来） │ │
│ │ · 记录使用经验（踩了什么坑、学到什么） │ │
│ │ · 尝试不同场景（哪些适合 AI、哪些不适合） │ │
│ │ │ │
│ │ ← 我们团队目前在这里 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段 2: 采用 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 成为日常工具 │ │
│ │ 活动: │ │
│ │ · 团队培训（今天这个分享算是开始） │ │
│ │ · 共享配置（CLAUDE.md、MCP 配置） │ │
│ │ · 建立 Code Review 规范 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段 3: 影响 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 目标: 衡量实际效果 │ │
│ │ 活动: │ │
│ │ · 对比使用前后的效率指标 │ │
│ │ · 识别最佳实践，固化成规范 │ │
│ │ · 持续迭代改进 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘4.6.3 Oxide 五原则
企业实践 — Oxide 公司
背景：硬件+软件公司，由前 Sun/Joyent 资深工程师创办（含 DTrace 作者 Bryan Cantrill），只招资深工程师 来源：RFD 576: Using LLMs at Oxide [4]
| 原则 | 解释 | 我的理解 |
|---|---|---|
| 责任 | 人类判断始终在环内，对所有输出负责 | 不能说「AI 写的，我不知道」 |
| 严谨 | LLM 应该锐化思考而非替代思考 | 用 AI 加速，不是用 AI 偷懒 |
| 同理心 | 考虑内容创作者和消费者 | 想想 Reviewer 的时间，想想维护者的负担 |
| 团队合作 | 保持真诚的沟通 | 如果用了 AI，就说用了；不要假装是自己写的 |
| 紧迫感的平衡 | 不为速度牺牲质量 | 快不是目的，好才是 |
4.6.4 代码审查底线
对 AI 生成代码的审查，应该多问两个问题：
| 问题 | 为什么重要 |
|---|---|
| 「为什么选择这个方案？」 | 如果答不上来，说明你没理解代码 |
| 「考虑了哪些替代方案？」 | 如果没考虑，说明你只是接受了 AI 的第一个建议 |
4.7 Q&A 与资源
4.7.1 常见问题
| 问题 | 简短回答 |
|---|---|
| 「Claude Code 要钱吗？」 | 要，按 token 计费，公司应该会统一采购 |
| 「和 ChatGPT 比哪个好？」 | 写代码的话，Claude 目前更强；但选型要看具体场景 |
| 「会不会泄露公司代码？」 | Anthropic 声称不会用 API 数据训练模型，但敏感代码还是要注意 |
| 「我完全不懂 AI，能用吗？」 | 能，但建议先从简单任务开始，不要一上来就 Vibe Coding |
| 「AI 会取代程序员吗？」 | 短期不会，但会改变工作方式；不用 AI 的程序员可能会被用 AI 的程序员取代 |
| 「英文不好影响大吗？」 | 有影响但不大，Claude 中文支持不错；关键是学会组织 Context |
4.7.2 资源推荐
入门必读：
| 资源 | 说明 |
|---|---|
| Claude Code Best Practices | Anthropic 官方最佳实践 |
| Claude Code Docs | 官方文档，遇到问题先查这里 |
| 如何避免在 AI 时代技能退化 | 中文，技能退化警示 |
进阶阅读：
| 资源 | 说明 |
|---|---|
| Oxide RFD 576 | 企业级 LLM 使用策略 |
| 一个半月高强度 Claude Code 使用后感受 | 喵神的文章，实战经验 |
| Context Engineering Guide | 深入理解 Context Engineering |
4.7.3 最后一句话
用 AI 加速你已经理解的工作，而不是用它跳过你应该学习的过程。
这是我这几个月踩坑下来最深的体会。希望对大家有帮助。
参考资料
📝 L3 | 如何避免在 AI 时代技能退化 | 宝玉的分享 - 中文译文，原文详述技能退化的四个征兆和七条实践建议。 ↩︎
🔬 L2 | The Paradox of Augmentation | SSRN - AI 增强悖论的理论模型：AI 初期提升效率，长期导致技能退化的数学模型。 ↩︎
💬 L4 | AI has a deep understanding of how this code works | Hacker News - 2025 年 10 月 OCaml 编译器 13K 行 AI 生成 PR 事件的社区讨论，展示了 AI 辅助编程的典型反面案例。 ↩︎
🔬 L1 | Oxide RFD 576: Using LLMs at Oxide - Oxide 公司关于企业级 LLM 使用的详细策略文档，强调责任、严谨、同理心等核心价值观。 ↩︎