最近 AI 很火，各个行业都希望把 AI 整合进来，提升生产效率，但是毕竟是新的东西，没有好的模板可以套，自己一点点摸索又很费时间和资源。作为开发者，我最近也在探索把 AI 整合到生产实践中，试图找到一个可行的提效套路，看了作者这篇文章觉得挺有借鉴意义的，随手翻译了，分享给大家

直到18个月前，我写的每一行代码都亲力亲为。如今，AI负责我80%的初始实现，而我则专注于架构设计、Code Review以及同时协调多个开发线程。

这并非又一篇“AI将改变一切”的陈词滥调。本文旨在探讨将AI整合到生产开发工作流中混乱的现实：什么方法真正有效，什么会浪费你的时间，以及为何将AI视为“一个不会学习的初级开发者”成了我取得成功的心智模型。

一、我的四次编码转变

我的代码问题解决方法在职业生涯中经历了四次转变：

  • 头5年，我埋头阅读书籍和SDK文档。
  • 接着12年，依赖谷歌搜索别人的答案。
  • 之后18个月，使用Cursor进行AI辅助编码。
  • 而最近6周，使用Claude Code进行完全的AI委托编码。

每次转变，都比上一次解决编码问题更快。使用Claude Code，我只用了几个小时就变得高效起来。

二、AI辅助开发的实际体验（对我而言）

以下是我当前工作流的真实面貌，去除了所有炒作成分。我主要把AI当成“共同思考的伙伴”，与它协作产出最终投入生产的代码。

1. 通常需要三次尝试

忘掉一次性生成完美代码的承诺。工程师的职责是为问题寻找最佳解决方案，而不仅仅是编写一堆代码。

首次尝试（垃圾率95%）

  • Claude构建关于系统的上下文
  • 开发者识别出真正的挑战所在
  • 代码通常完全错误

然后，将此次尝试的收获喂回给Claude。

第二次尝试（垃圾率50%）

  • Claude理解了细微差别
  • 开发者已定义了具体方法
  • 仍有一半情况无法使用

第三次尝试（最终可用）

  • Claude实现了一个我们可以迭代和优化的版本
  • 开发者进行 code review 和错误纠正
  • 初稿实现

虽然我们还没有得到可以直接生产可应用的代码，这并非失败，而是过程！我们要知道，期望首次尝试就完美，就如同期望一位初级开发者，在没有上下文的情况下，就能搞定一个复杂功能一样。

2. 上下文问题（及其解决方案）

最大的挑战？AI无法在会话之间保留学习成果（除非您花时间手动赋予它“记忆”）。因此，通常每次对话都需要从头开始。

我的解决方案：

Claude.md 文件
创建一个项目专用的上下文文件，包含：

  • 项目架构
  • 代码风格偏好
  • 陷阱与变通方案
  • 相关文档链接

工具集成
得益于MCP（Model Context Protocol），我现在可以将AI连接到：

  • Linear（用于获取任务单上下文）
  • Notion 或 Canvas（用于获取文档）
  • 非生产数据库（仅只读权限！用于获取数据和数据结构）
  • 实际代码库
  • Github（从旧的PR中获取有用的背景信息）

没有这些上下文，就得反复解释相同的约束条件。有了它，可以直接从第二次尝试开始，而非第一次。

local integrations

3. 管理多个AI“开发者”

我现在并行运行多个Claude实例，这就像管理一个每天早晨都会重置记忆的小型开发团队。

关键策略：

  • 切勿并行处理相同的问题（容易迷失方向，混淆正在解决的不同问题）
  • 在Linear（或您使用的任何项目管理工具）中跟踪一切
  • 明确标记经过人工编辑的代码（AI会混淆它写的代码和您修改的代码）

4. 三步Review流程

编写代码只是工作的一部分，review代码亦然。采用AI也改进了我的代码审查流程。

Claude先行审查

  • 捕捉缺失的测试覆盖
  • 发现明显的Bug
  • 提出改进建议

这为我和同事节省了时间和额外的审查次数。

我的个人 Code Review
在Sanity，我们的原则是工程师对其交付的代码负责，即使是AI生成的代码。我希望确保我交付的是：

  • 可维护的代码
  • 稳健的架构设计
  • 正确的业务逻辑
  • 可集成性良好

团队日常 Code Review

  • 他们很少知道哪些代码是AI生成的
  • 质量门槛保持不变

关键要点：我现在对“我写的代码”更加挑剔，因为其中很多并非我亲手键入。没有情感依恋意味着更好的Code Review。

5. 后台智能体的早期实验

我们正在测试使用Cursor的Slack触发智能体来处理简单任务：

  • 2次成功修复业务逻辑
  • 1次处理CSS布局失败

当前局限性：

  • 无法访问私有NPM包
  • 它会提交未签名的Commit
  • 绕过了正常的跟踪流程

image

但潜力呢？想象一下智能体在您睡觉时处理积压的小任务。我们正在Sanity积极探索这一点，并在团队间分享经验，以摸索出有效的方法。

6. 真实成本（含数字）

我们来谈谈钱，我使用Claude Code的成本占公司支付我月薪的不小比例。

但这项投资带来了：

  • 我的功能交付速度快了2-3倍
  • 我可以管理多个开发线程
  • 我在模板代码和重复性代码上花费时间几乎为 0

投资回报率(ROI)是显而易见的，但需要为全力投入AI开发的资深工程师预算每月1000-1500美元的费用。同样可以合理预期，工程师随着熟练度提高，使用AI的效率会更高，这只是时间问题。

7. 实际会遇到的问题

AI辅助开发并非一帆风顺，以下是我遇到的一些持续挑战：

学习问题
AI不会从错误中学习，需要反复修正相同的误解，解决方案是：配置更好的文档和更明确的指令。

自信问题
AI会自信地编写有问题的代码，并声称其很棒。务必进行验证，尤其是对于：

  • 复杂的状态管理
  • 性能关键部分
  • 安全敏感代码

上下文限制问题
大型代码库会超出AI的上下文窗口限制。将问题分解成更小的块，并提供具体的上下文。

8. 从代码到问题的情感转变

最困难的部分？放下对代码的所有权。现在我不再关心“我写的代码”了，它只是需要Review和优化的输出。

这种超然实际上非常解放！

  • 更快地删除不良解决方案
  • 更客观的代码审查
  • 重构时零 ego（自我）

如果明天出现更好的AI工具，我会立即切换。代码并不珍贵，我们解决的问题才是。

三、这对团队意味着什么（给技术负责人的建议）

如果要从工程师的角度给出建议，如果您是考虑采用AI的技术领导者：

  1. 让团队中的工程师采用和测试不同的AI解决方案： AI辅助编码是一项需要通过实践来学习的技能。
  2. 从重复的任务开始： 这是AI能立即发挥作用的领域。
  3. 为实验预留预算： 第一个月会很混乱。
  4. 调整Coe Review流程： AI生成的代码需要不同的Review。
  5. 用文档记录一切： 优质的上下文是效率倍增器。

适应新AI工作流的工程师会发现工具箱中多了一把利刃：他们正在成为协调者，处理多个AI智能体，同时专注于架构、审查和复杂问题解决。

四、下一步（作为开发者）

挑选一个小的、定义明确的功能。给AI三次尝试来实现它。然后，像指导初级开发者一样对输出的代码进行 Code Review。

就这样，不需要巨大的转型，不需要流程大修。只需一个功能，三次尝试，一次坦诚的Code Review。

未来不在于AI取代开发者，而在于开发者工作得更快，创造更好的解决方案，并利用可用的最佳工具。

参考文献：
First attempt will be 95% garbage: A staff engineer’s 6-week journey with Claude Code