从Cursor到Claude Code：一年半AI编程实战经验

我从前年年中开始用 Cursor，到今年年初慢慢转到了 Claude Code。这一年半时间里，我的开发方式发生了彻底的变化。这篇文章把我积累的经验完整地梳理一遍，包括最重要的 Plan 模式怎么用、怎么让 AI 自己做端到端测试、怎么用日志让它精准定位问题、多会话并行怎么避免冲突等等。都是实战中踩出来的东西，希望对你有用。

一、先讲讲我这一年半的变化

回想我最早用 Cursor 的时候，流程是这样的：我需要把要改动的地方亲自指出来，把问题描述清楚，它才能去修改。改完之后，我还要仔细看一遍它写的代码，不放心。

后来慢慢地，我只需要描述问题，它就能自己找到在哪改。

到了现在用 Claude Code，我完全只做问题的描述------我根本不知道要在哪改，就直接让它自己去找、自己去改。改完之后我基本上不看代码，直接提交。

AI 迭代的速度就是这么快。一年半前和现在，完全是两种工作方式。

这里我要先回应一个很常见的说法："AI 编程不好用"。确实有很多程序员觉得 AI 写出来的东西不是自己想要的，为了达到想要的结果，得不停地跟 AI 聊、让它改，花的精力可能比自己写还多。

但我的实际体验是：我们公司对代码质量要求是很高的，所有代码都要经过同事人工 review。而我现在用 Claude Code 写出来的代码，同事会提一些审查意见，但总的来说，细节都处理得很好，包括代码风格，而且基本上一次运行就过------因为它自己都测试过了。从我这几个月的经验来看，我不看代码、不自己测试、直接提交，基本上没出过差错。

所以问题不在 AI 的能力，而在使用的方法。AI 编程特别是像 Claude Code，写代码的质量是非常高的------前提是你要用对方法。下面就是我总结的方法。

二、最重要的经验：先用 Plan 模式，不要一上来就让它干活

这是我要讲的最重要的一点，用 Claude Code 是这样，用 Codex 这些其他编程工具也是一样。

1. 新手最容易犯的错

新手用 AI 编程，通常一上来就用自动模式或者手工模式，直接让它开干。对于简单的问题------比如一个简单的 bug------这样没问题，你把问题描述清楚交给它，它会自己验证、写单元测试，基本不会出错。

但对于比较大的功能，直接让它上手写，大概率是会出问题的。而且一旦它顺手写完了、出了一堆问题，你再去调、再去改，花的精力可能比自己从头写一遍还多。这就是很多人觉得"AI 效率不高"的根本原因。

2. 为什么会这样？

关键在于背景资料不全。通常包含几个方面：

需求描述得不够细；
接口文档不清晰，或者干脆没提供；
涉及的代码规范、相关系统的说明缺失。

如果你用自动模式，它就直接开始干了。虽然它有时候会问你一些问题，但它问的通常是需要你做决策 的点。而那些缺失的背景资料，它大多数情况下是问不到的------它不知道自己不知道，就会基于自己的猜测去实现。资料给够了，它工作得非常好；资料不全，它实现出来的代码就可能千疮百孔。

3. 一个真实案例：DeepSeek 联网搜索接口

我上次做一个功能，要用 DeepSeek 的 Web Search API（联网搜索接口）来实现搜索。这个接口比较新，我第一次跑代码的时候出了点问题，Claude Code 分析完就给了一个解决方案。

我看了一下，方案看起来挺合理的。但我转念一想：这个 API 是新出来的，Claude 的训练数据里没有这个知识。我又翻了一下它的运行记录，发现它并没有去查 DeepSeek 联网搜索接口的文档------也就是说，这个"看起来合理"的方案，很可能是它基于自己的想象做的假设。

于是我跟它说：

text 复制代码

你到 DeepSeek 的官方网站上搜索一下这个接口，
根据官网最新的 API 文档来设计方案。

它去搜了，结果发现官方文档里接口的定义跟它之前推荐的确实有出入。它重新设计、重新写了代码，一次通过。

从这个细节你就能看出 Claude 在什么情况下能好好工作、什么情况下会出差错：它不会主动承认"这个知识我没有"，你要替它识别出来，并把资料补给它。

4. 我现在的完整工作流

现在我拿到一个开发任务，流程基本是固定的：

先审需求。看需求描述清不清楚，它需要的接口全不全。
收集所有背景资料。需求说明、接口文档、代码规范、辅助文档、可能涉及的网站......凡是这个问题相关的，通通收集到一起，一次性告诉它。
进 Plan 模式让它写计划 。它写计划的时候会自己做比较详细的调研。注意：写计划一定要用最强的模型，实现可以用快一点的模型，但计划阶段别省。
仔细审计划。这一步是关键，下面单独说。
多轮讨论修改。觉得哪里需求写得不明确、哪里实现方式不好，就让它改计划。可能要聊很多轮，别嫌烦------磨刀不误砍柴工。

审计划怎么审？分两个层次：

如果你不太懂实现细节 ，没关系，你就看它写的实现效果：确保它要实现出来的效果跟你想象的一样。它有时候做计划不会特别明确地写出实现效果是什么样的，这时你要让它把效果描述清楚。
如果你是程序员 ，除了效果，还要看架构、性能、实现方式对不对。这里有一个很重要的权衡：再复杂的需求 AI 都能给你实现出来，但实现是有代价的------太复杂的方案性能不好、维护起来也麻烦。你要看它给的方案是不是足够简洁，能不能以比较少的成本达到想要的效果。必要的时候，主动在功能和性能上做妥协。

只要计划做得足够细致，它的实现代码基本上可以保证一次过。现在的 Claude Code 基本不会出现编译错误、运行错误这种低级错误。

5. 再举一个例子：从"完全没思路"到功能上线

光说"审计划"可能还是有点抽象，我再讲一个完整的案例。

我在开发冰石机器人的AI 自主学习功能。想做的事情是：真人客服平时会在会话里发很多回复，我希望 AI 能从真人客服发出的这些消息里学习，总结成问答沉淀下来，让机器人以后的回复能达到真人客服的水平。

这个功能我刚开始是完全没有思路的，甚至不确定能不能做到、做出来效果会是什么样。

我就先开了个 Plan 模式，把需求跟它说了，让它给一些建议，看看能实现成什么样子、有哪些方法。它给出了几种实现方案。我也把我的担忧提出来：比如 AI 总结出来的信息可能不准，比如让 AI 自己去改提示词风险会不会太大。它针对这些担忧给了具体的建议。

它刚开始给的计划不是很细致，我就要求它：把核心算法写清楚，把整个运作流程写清楚，我再来逐条判断流程里有哪些不合适的地方。

这一细化，问题就暴露出来了。它的初版方案里，从真人消息总结出问答之后，要跟知识库里原有的内容比对（判断这条知识是不是已经有了）。它写出来的比对方式是：一条一条比，而且只用"问题"去比。这有两个明显的毛病：

知识库里的条目一多（几千条），一条条比效率就非常低；
很多问题说法不一样但答案是一样的，只拿问题去匹配，根本找不到真正对应的那条。

这些问题我都在计划阶段就跟它讨论修改掉了。就是在这样一轮轮的讨论中，我从"不确定这事能不能干"慢慢理出了思路，确认了可行。细节全部聊清楚之后再让它实现，一次做成。这个自主学习功能现在已经上线了，客户实际用下来反馈还挺有用。

这个案例想说的是：Plan 模式不只是用来"审方案"的，它更是一个和 AI 一起把模糊想法磨成可行方案的过程。

网上那些"一句话让 AI 写个程序"的演示，看看就好。我们实际生产要的是可以直接用的、跟真人程序员写的质量一样甚至更高的代码------这就得靠计划阶段下功夫。

三、测试：别停留在单元测试，让它模拟人工做端到端测试

默认情况下，Claude Code 写完代码就会写单元测试，并确保所有单元测试都跑通，这是最基本的。但单元测试通过，不等于功能达到要求。

一两个月之前，我的工作模式还是：Claude Code 写完代码，我手动再简单测一遍。后来我发现，我大部分的工作时间其实都花在这种手工测试上了。

再后来我发现，Claude Code 不光能写单元测试，它是可以模拟人工做 Web 端到端测试的。方法是给 Chrome 装上 Claude 的浏览器扩展，装好之后它就能控制你的浏览器了。开发完代码，你告诉它访问方式，它自己启动浏览器、自己去点、自己去验证。

而且因为它有源代码，它知道这个功能是干什么的、网页上有什么，所以测试步骤和测试数据它都能自己生成。我们平时做测试比较麻烦的就是构造测试数据再逐个验证，现在这些它都能包了。

登录问题的两个变通办法

有一个点要注意：Claude Code 有安全限制，就算你把网站的用户名密码告诉它，它也不能替你输入密码登录。这确实有点烦，但有两个变通办法：

让它自己构造 Token。它能读源代码、能查数据库。像我们公司的系统，它可以从数据库里查到用户数据，然后在后台构造出一个合法的 Token，用这个 Token 去操作------绕过了输密码这一步。这一点是真的很牛。
人工登录，把会话交给它。我在它控制的那个浏览器里把登录页打开，自己输用户名密码登录好，然后告诉它："我已经登录好了，页面 URL 是 xxx，你接着用这个去测。"

它做端到端测试的速度并不快，但重点是把人解放出来了------它在那测的时候，你可以同时开别的任务去干别的活，不用守着。

四、日志：写全日志，是让 AI 精准定位问题的捷径

这是一个能明显提升排障效率的技巧：日志尽量写得全一点。

碰到问题的时候，最简单的方法就是：把问题描述一下，然后把日志文件整个丢给它。它基于日志分析，能够确切地找到问题所在。

没有日志的话，光靠问题描述它也能分析、也能大致定位，但通过分析代码，有些东西它就需要猜测，给出的方案不一定十分准确，有时候要试几次。而一旦有了日志，定位基本上就是绝对准确的。

还有一个进阶用法：对没把握的问题，先让它加日志。流程是：

让它把相关代码改一下，把日志加上；
运行一遍，复现问题；
把运行日志丢回给它分析，再解决问题。

这样它给出的解决方案会非常准。特别是下面这几类场景，没有日志它很难一次给出准确的实现：

真机上的随机事件------有些事件没法在它的环境里复现；
和其他软件交互------它不知道对方软件确切会返回什么；
调用大模型------我现在的程序里经常需要大模型返回结果，每个大模型确切会返回什么样的内容，不跑一遍谁也不知道。

这类"外部世界的真实反应"，只有日志能带给它。

五、给 AI 一个它自己能跑的"检查"

上面测试和日志这两条经验，其实背后是同一个原理，官方最佳实践里把它总结得很清楚：给 Claude 一个它自己能运行的检查（verification）。

这个检查可以是测试套件、构建命令、一个对比输出的脚本，甚至是浏览器截图和设计图的对比。有了能跑的检查，整个循环就自动闭合了：它干活 → 跑检查 → 读结果 → 迭代到通过。没有检查，它只能靠"看起来做完了"来判断------那你就成了人肉验证环，它的每个错误都要等你来发现。

提示词上的差别大概是这样：

text 复制代码

❌ 实现一个邮箱校验函数

✅ 实现 validateEmail 函数。测试用例：
   user@example.com 返回 true，invalid 返回 false，user@.com 返回 false。
   实现完运行测试，不通过就继续改，直到全部通过。

另外，让它出示证据而不是口头宣布成功：测试输出贴出来、跑了什么命令返回了什么、截图看效果。看证据比你自己复跑一遍快得多。

六、代码 review：让它审 PR，也审它自己

还有一个挺有用的用法：让 Claude Code 帮你 review 代码。你只要把 GitHub 上 PR 的链接给它，它就会自动获取分支里对应的改动，然后给出审查意见。

你也可以让它 review 自己刚写的代码。不过按官方的建议，更好的做法是新开一个会话（或者用子代理）来做 review------新会话的上下文是干净的，不会对"自己刚写的代码"有偏心，审得更客观。

顺带说一句，提交代码的时候让它生成 commit message，质量也很好，直接用就行。

七、记忆：让它把踩过的坑记下来

如果你发现 Claude 反复犯同一个通用性的错误，一定要让它把这个错误写进记忆，下次它就不犯了。

举我自己的例子：我有一个前端项目，Vue 项目，组件库没有做全局导入，每个页面用到哪个组件就要在页面里单独导入。但 Claude Code 每次写 Vue 页面都默认组件是全局导入的，导入代码就不写，连着几次都这样。

后来我就让它把这条写成一条记忆。之后就再也没出过这个问题。

类似的，项目级的规范可以放到项目根目录的 CLAUDE.md 里，每次会话开始它都会自动读取------代码风格、常用命令、架构约定这类"每次都适用"的东西放这里最合适。

八、多会话并行：用 git worktree 让每个会话在自己的分支上干活

用熟了之后你一定会想同时开多个会话干活。这里有个坑：多个 session 同时操作同一份代码，相互之间会冲突。这块我以前做得不好------默认情况下你只是选了同一个目录，不同会话实际上是在同一个分支的同一份文件上改，不打架才怪。

正确的做法是用 git worktree，让每个会话在自己独立的工作目录和分支上干活。Claude Code 现在对这个有官方支持，用起来很简单：

bash 复制代码

claude --worktree feature-auth

加上 --worktree（或 -w）和一个名字启动，它会自动在仓库的 .claude/worktrees/feature-auth/ 下创建一个独立的 worktree，并新建分支 worktree-feature-auth。换个终端、换个名字再跑一次，就是第二个完全隔离的会话。两个会话改各自的文件，互不干扰。

其他几种用法：

在会话中直接跟它说"在 worktree 里干活"，它会自己创建一个进去；
Claude Code 桌面版里，每个新会话默认就自动分配独立的 worktree；
也可以手动管理：git worktree add ../project-feature-a -b feature-a，然后 cd 进去跑 claude。

几个注意事项：

worktree 是一份全新的检出，依赖要重新装 （node_modules 之类）；.env 这种被 gitignore 的配置文件不会自动带过去，可以在项目根目录建一个 .worktreeinclude 文件列出要自动复制的文件；
把 .claude/worktrees/ 加进 .gitignore；
分支合并之后记得清理：git worktree remove <路径>，用 git worktree list 可以看当前有哪些；
文件隔离了，但数据库、端口、服务并没有隔离------两个会话同时对同一个本地数据库跑迁移照样打架，这类共享资源要自己留意；
实践中 2~4 个并行会话是比较合理的上限，再多的话你 review 的速度跟不上它们产出的速度。

九、上下文管理：会话不是越长越好

上下文窗口是 AI 编程最重要的资源。会话里的每条消息、它读过的每个文件、每条命令输出都在占用上下文，塞满之后它的表现会明显下降，开始"忘记"你之前的指令、犯低级错误。

几个实用的做法：

会话太长了，让它总结移交 。你可以让 Claude Code 总结一下当前会话干了什么、进行到哪了，并生成一段提示词，然后拿着这段提示词到新会话里继续干。关键上下文就这样干干净净地带过去了。我之前在《使用Cursor开发大型项目的技巧》里讲过"把上下文从对话转移到文件"，是同一个思路：对话会丢，文件不会。
不相关的任务之间用 /clear 清空上下文。最常见的失败模式就是"一锅烩会话"：干着任务 A，中途问了个不相关的问题，又回来干 A------上下文里全是干扰信息。
纠错两次还不对，就别继续纠了 。这时上下文已经被失败的尝试污染了，继续聊只会越来越乱。正确做法是 /clear，然后把这几轮学到的教训写进一个更好的初始提示词，重新开始------几乎总是更快。
随时可以按 Esc 打断它纠偏；按两次 Esc（或 /rewind）可以回滚到之前的检查点，对话和代码都能回退。

十、写在最后

把这一年半的经验压缩成一句话：AI 编程的上限，不取决于模型有多强，而取决于你给它的信息有多完整、验证的闭环有没有搭起来。

背景资料给全、计划聊透，它的代码质量不输给真人程序员；给它能自己跑的测试和日志，它比人更有耐心地迭代到正确为止。反过来，资料不全、上来就干、人肉验证，那 AI 确实"不好用"------但那不是 AI 的问题。

从"AI 辅助人写代码"到"人辅助 AI 写代码"，这个转变在我身上已经发生了。我现在的角色更像一个提需求、审计划、验收结果的人，而不是一行行敲代码的人。照现在这个迭代速度，相信很快会发生在每个程序员身上。

参考资料：

Claude Code 官方最佳实践：https://code.claude.com/docs/en/best-practices
Git worktree 并行会话官方文档：https://code.claude.com/docs/en/worktrees
我的上一篇：使用Cursor开发大型项目的技巧