首次尝试，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，从旧的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取代开发者。而是开发者利用最先进的工具，工作得更快，创造出更好的解决方案。