|
两个重要追求 用了一段时间的Claude Code，感觉隐约有一些心得和思考，需要记录，以便接下来不偏离使用方向。 任何一个工具的使用，都离不开一个原则：解决实际问题。 我们用Claude Code也不例外，是为了帮我们实现产品。如果要加一些前缀限定，可能是：尽量快地实现我们想要的产品。 所以，两个重要追求： 1. 尽量快地实现#效率； 2. 产品是我们想要的#精准。 哪个追求更重要 我们先来思考一个问题，如果这两个追求，我们只留下一个，要留哪个呢？ 应该留的是第二个。因为，就算它效率再高，做出来的东西不是你想要的，意义也不大。并且如果反复改动，效率也将变得极低。 所以，如何让其精准地实现我们的需求，就成了重中之重。在这个的基础上，我们才需要考虑尽量快。 如何实现对于“精准”的追求 所以前期，基于对”精准“的追求，最需要修炼的是： 1. 确定我们的表达尽量精准； 2. 确定Claude Code听到的尽量精准。 表达能够精准，是有前提的。前提就是，我们自己脑袋里的想法很清晰。 在我们的想法很清晰的前提下，该说到什么地步，cc 才能准确Get到我们的想法呢？ 这个问题在实战中其实没那么重要，因为你最好让它复述下你的想法，确认理解无误了再让它执行即可。 所以，这两点其实可以统筹成一个动作：在确认cc理解你的想法之前，不要让它执行。 你反复修炼这个动作，最终就能够与cc达到某种默契：我大概这么说，它就能听懂了。 但有一种情况，比如你让它给了一个方案，在与它探讨方案细节的时候，即使它表现出听懂了，在具体执行的时候，仍然可能只是基于你与它的最后一轮对话执行。这就导致只是”片面“地执行。所以，最终还要让它复述下完整方案和执行计划才行。 如何实现对于“效率”的追求 1. 让多个cc同时干活 要”精准“，意味着需要反复探讨和确认，也就意味着不那么快。但好在，cc是支持多开的。所以，当你和它探讨完一个需求，让它开始干活的时候，就可以对第二个cc发号施令了，这样就避免了等着它干活的时间。如果你越来越熟练，可能可以接着开第3个、第4个……这样最终，效率的瓶颈就会变成是你，而不是AI了。 但是，让多个cc改同一个项目，不会错乱吗？具体如何做呢？ 是的，不会。我们需要用到最重要的一个工具，就是 git worktree 。这部分内容，大铭老师的这篇《把 Git Worktree 当“实习生”使，我的无冲突并行开发工作流》文章讲得很详细了，我就不重复造轮子了：把 Git Worktree 当“实习生”使，我的无冲突并行开发工作流 2. 让每一个cc都发挥最大价值 如果每个cc都干得很拉胯，多个cc也没法顶一个诸葛亮啊！所以，让每个cc都能成为”诸葛亮“也很关键。并且，让它们学会用工具，且尽量省心，比如自己去操作数据库，自己开浏览器进行测试等等。 具体怎么做呢？ 这方面，我的大部分经验，都来自于小排老师的公众号。小排老师公众号里每一篇关于cc的都值得看，都能让你使用cc的水平提升段位。 如果你实在太懒了，至少这篇《刘小排是如何使用Claude Code的？》也要看：刘小排是如何使用Claude Code的？ 除此之外，就是我上面说的做到对”精准“的追求，这样弄出来的东西才会大差不差。 其他问题 要不要关注消耗了多少token 如果你想爽一下，想看看自己又薅了cc多少美金了，当然可以看； 如果你想以此评估自己的工作量，还是看看你产出了多少功能点吧，毕竟token用得多不代表最终活干出来得多，除非你已经很“精准”； 如果你用的是有限的套餐，比如是20或者100美金的，你可能需要思考的是，如何用更少的token就能搞定任务，与“精准”同样息息相关。 上面忘了说了，有条件还是尽早体验 opus 4 模型，sonnet 4 跟 opus 4 真的不是一个水平！ 多开cc在IDE中经常崩溃 关于在IDE里多开cc导致IDE崩溃，这个问题我没有遇到过，因为我一直是在原生终端使用的cc，一直都很丝滑。目前我的能力水平开4个cc就差不多了，配套开了4个Cursor和4个浏览器。Cursor只用来启动服务和git相关操作，浏览器用来测试。这套组合，运转很丝滑，没有崩溃过。唯一的美中不足是，每天开机后，要开始排页面 给大家看一张页面截图： 另一个显示器(竖向)，则竖着排了4个浏览器，看哪个cc先跑完就测试哪个。 4个我就根本忙不过来了，完全没有等待时间，瓶颈在我身上了。看来，能”多多益善“的前提，是得有韩信将兵的能力啊！哈哈~ | 
