首次尝试，95% 的代码都是垃圾：一位工程师使用 Claude Code 六周的心得

原文：Vincent Quigley - 2025.09.02

直到 18 个月前，我的每一行代码都还是亲手编写的。而今天，AI 编写了 80% 的初始实现代码，而我则专注于架构设计、代码审查以及同时主导多个开发线程。

这并非又一篇“AI 将改变一切”的空谈文章。本文旨在探讨将 AI 集成到实际生产开发流程中的复杂现实：哪些方法真正有效，哪些纯属浪费时间，以及为什么 把 AI 看作一个“学不会东西的初级开发者” 成了我获取成功的思维模型。

背景故事：在 Sanity 公司，我们每个月都会举办工程研讨会，由一位同事分享他最近在尝试的新东西。上次轮到我时，便展示了如何使用 Claude Code。

编程方式的四次转变

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

最初的5 年，我通过阅读书籍和 SDK 文档来学习。

接下来的12 年，我依赖谷歌搜索来寻找社区提供的答案。

然后是18 个月，我使用 Cursor 进行 AI 辅助编程。

直到最近的6 周，我开始使用 Claude Code，实现完全的 AI 编程委托。

每一次转变都比上一次来得更快。而切换到 Claude Code？我只花了几小时就上手并开始高效产出了。

AI 辅助开发的真实工作流（对我而言）

抛开那些天花乱坠的宣传，我当前的工作流是这样的。我主要是将 AI 作为“辅助思考”的工具，与它协作，共同完成最终要投入生产环境的代码。

通常需要三次尝试

别指望 AI 能一次性生成完美无缺的代码。作为一名工程师，你的职责是为问题找到最佳解决方案，而不仅仅是写一堆代码。

第一次尝试（95% 的代码是垃圾）

• Claude 建立对你系统的初步认知。
• 你在这个过程中识别出真正的挑战所在。
• 生成的代码通常完全是错的。

然后，你带着从这次尝试中学到的东西，再次反馈给它。

第二次尝试（50% 的代码是垃圾）

• Claude 理解了其中的细微差别。
• 你已经定义了具体的实现方法。
• 但仍有一半的代码是无法使用的。

第三次尝试（终于产出可用的代码）

• Claude 实现了一些我们可以作为基础进行迭代和优化的东西。
• 你在这个过程中持续审查并修正方向。
• 这成为了你的起点，而非最终代码。

这不是失败，而是必经的过程！指望第一次尝试就获得完美结果，就像指望一个初级开发者在毫无背景信息的情况下，独立完成一个复杂的功能一样不切实际。

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

最大的挑战是什么？AI 无法在两次会话之间保留学习成果（除非你花时间手动给它灌输“记忆”）。所以，通常每一次对话都是从零开始。

我的解决方案：

Claude.md 文件

为每个项目创建一个特定的上下文文件，包含以下内容：

• 架构决策
• 代码库中的常见模式
• 注意事项和变通方法
• 相关文档的链接

工具集成

得益于 MCP 集成，我现在可以将 AI 连接到：

• Linear（一个项目管理工具），以获取任务的上下文
• Notion 或 Canvas，以获取文档
• 非生产环境的数据库（仅限只读权限！），以获取数据和数据结构
• 你的实际代码库（这是当然的）
• Github，从旧的 PR（Pull Request）中获取有用的背景信息

如果没有这些上下文，你就得一遍又一遍地解释相同的限制。而有了它们，你相当于直接从第二次尝试开始，而不是从零开始。

管理多个 AI “开发者”

我现在会并行运行多个 Claude 实例，这感觉就像在管理一个小型开发团队，只不过团队成员每天早上都会重置他们的记忆。

关键策略：

• 永远不要在同一个问题空间上并行处理（否则很容易迷失方向，混淆正在解决的不同问题）。
• 在 Linear 中跟踪所有事情（或者你使用的任何项目管理工具）。
• 明确标记人类编辑过的代码（AI 会混淆它自己写的和被你修改过的部分）。

三步代码审查流程

写代码只是工作的一部分，代码审查同样重要。采用 AI 也让我的代码审查流程发生了演变。

首先由 Claude 审查

• 捕捉缺失的测试用例。
• 发现明显的 bug。
• 提出改进建议。

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

我审查关键部分

在 Sanity 公司，我们的原则是工程师要对自己提交的代码负责，即使代码是 AI 生成的。我需要确保提交的代码是：

• 一个可维护的代码库。
• 合理的架构决策。
• 正确的业务逻辑。
• 良好的集成点。

团队进行常规审查

• 他们通常不知道哪些代码是 AI 生成的。
• 质量标准保持不变。

关键在于：我现在对自己写的“代码”更加挑剔，因为其中很多都不是我逐字敲出来的。没有了情感上的依恋，审查质量自然更高。

关于后台代理的早期实验

我们正在测试使用 Cursor 通过 Slack 触发的代理来处理一些简单的任务：

• 2 次成功修复了业务逻辑问题。
• 1 次在处理 CSS 布局时失败。

目前的局限性：

• 无法访问私有的 NPM 包。
• 它提交的是未签名的 commit。
• 绕过了常规的追踪流程。

但这其中蕴含的潜力是什么？想象一下，在睡觉的时候，有代理程序在处理你待办事项列表里的小任务。我们 Sanity 公司正在积极探索这一点，并在团队之间分享经验，以找出真正有效的方法。

真实成本（附上数据）

我们来谈谈钱。我使用 Claude Code 的费用，占到了公司付给我月薪的一个不小的比例。

但对于这项投资，我换来了：

• 交付功能的速度快了 2-3 倍。
• 我能同时管理多个开发线程。
• 我不再花时间在样板代码和重复性工作上。

投资回报率（ROI）是显而易见的，但对于一位全身心投入 AI 开发的资深工程师，需要准备每月 1000-1500 美元的预算。当然，随着工程师对 AI 的使用越来越熟练，他们的 AI 开销效率也会提高，但这需要给他们时间。

实际会出什么问题

AI 辅助开发并非一帆风顺。以下是我经常遇到的持续性挑战：

学习问题 AI 不会从错误中学习。你得一遍又一遍地纠正它同样的误解。对应解决方案是：提供更好的文档和更明确的指令。

自信问题 AI 会非常自信地写出有问题的代码，并声称它很棒。务必进行验证，尤其是在以下方面：

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

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

从关注代码到关注问题的情感转变

最难的部分是什么？是放下对代码的“所有权”感。但现在，我不再关心这是否是“我的代码”了；它只是一个需要审查和优化的输出结果。

这种抽离感实际上是一种解放！

• 更快地删除糟糕的解决方案。
• 更客观地进行代码审查。
• 重构时毫无个人情感因素。

如果明天出现一个更好的 AI 工具，我会毫不犹豫地切换过去。代码本身并不宝贵，我们解决的问题才是。

这对你的团队意味着什么（作为技术主管）

如果我从一个工程师的角度给技术领导者一些建议，当你考虑引入 AI 时：

1. 让你的工程师去采用和测试不同的 AI 解决方案：AI 辅助编程是一项需要通过实践来学习的技能。
2. 从最重复性的任务开始：这是 AI 能立竿见影发挥作用的地方。
3. 为实验准备预算：第一个月会比较混乱。
4. 调整你的审查流程：AI 生成的代码需要用不同的方式进行审视。
5. 记录一切：优质的上下文是你提升效率的倍增器。

那些适应了新的 AI 工作流 的工程师会发现，他们的工具箱里多了一把锋利的刀：他们正在成为协调者，能够驾驭多个 AI 代理，同时专注于架构设计、代码审查和解决复杂问题。

你的下一步（作为开发者）

挑选一个小的、定义明确的功能。让 AI 尝试实现它三次。像指导初级开发者一样审查其输出。

就是这样。不需要巨大的变革，也不需要彻底改造流程。只需要一个功能，三次尝试，和一次坦诚的审查。

未来不是 AI 取代开发者。而是开发者利用最先进的工具，工作得更快，创造出更好的解决方案。