Claude Code六周深度测评：工程师95%代码失效真相

Vincent Quigley - 2025.09.02

先分享一段亲身经历。十八个月前，每一行代码还都是我自己敲的。到现在，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，从旧的 Pull Request 中获取有用的上下文

如果没有这些上下文，你只能一遍又一遍地解释同样的限制条件。而有了它们，你的工作起始点相当于直接从第二次尝试开始，而不是从零开始。

管理多个 AI“开发者”

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

几个关键策略：

• 永远不要在同一个问题空间上并行处理多个任务，否则自己都容易搞混。
• 用 Linear（或你喜欢的项目管理工具）追踪所有事项。
• 明确标记出哪些代码是人类编辑过的——AI 经常会混淆它自己写的和你改过的部分。

三步代码审查流程

写代码只是工作的一部分，代码审查同样重要。而采用 AI 之后，我的审查流程也自然发生了变化。

首先由 Claude 审查

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

这一步为我和同事节省了不少重复的审查回合。

我审查关键部分

在 Sanity 公司，我们有一条原则：工程师必须对自己提交的代码负责，哪怕代码是 AI 生成的。我需要确保最终提交的代码符合以下要求：

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

团队进行常规审查

• 他们通常并不知道哪些代码是 AI 生成的。
• 质量标准和以前完全一样。

关键在于：我现在对自己“写”的代码反而更加挑剔了，因为其中很多并不是我一个字符一个字符敲出来的。没有了那种情感依恋，审查质量反而更高了。

后台任务袋里的早期实验

我们正在测试一种方式：用 Cursor 通过 Slack 来触发一些简单的后台任务袋里程序。到目前为止：

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

目前的局限性也很明显：

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

但这里面蕴含的潜力很值得想象——比如，你在睡觉的时候，袋里程序正在处理你待办事项列表里的那些小任务。我们 Sanity 团队正在积极探索这个方向，并且在团队之间分享经验，找出真正有效的做法。

真实成本（附上数据）

聊到钱的问题。坦白说，我每个月用 Claude Code 的费用，已经占到了公司付给我月薪的相当一部分比例。

但作为交换，我换来的是：

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

投资回报率是明摆着的。不过如果你想全面投入，这里有一个实际数字：一位全身心使用 AI 的资深工程师，每个月大约需要准备 1000-1500 美元的预算。当然，随着工程师对 AI 使用得越来越熟练，他们的开销效率也会逐步提高——但这需要时间。

实际会出什么问题

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

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

自信问题——AI 会极其自信地写出有问题的代码，并声称它很棒。所以，务必亲自验证，尤其是在以下几个方面：

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

上下文限制问题——大型代码库很容易超出 AI 的上下文窗口大小。需要把问题拆解成更小的部分，并提供集中的上下文。

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

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

坦率讲，这种抽离感其实是一种解放。

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

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

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

如果让我从一个工程师的角度给技术领导者一些建议，当你考虑引入 AI 时，可以关注以下几点：

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

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

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

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

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

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