★ FEATURED ARTICLE 1. 从写代码到聊代码我的工作流被彻底改写第一次用 claude code 是在一个周五的深夜。当时我正对着一个跨平台数据同步模块发愁——三个数据源、两套字段映射规则、还有一堆历史遗留的兼容逻辑光是理清调用链路就花了我一个多小时。抱着试试看的心态我把整个模块的目录结构和一个核心文件丢给了它然后问了一句这个模块的数据流是怎么走的它没有直接回答我而是先反问我你希望我从入口文件开始梳理还是从数据最终落库的位置倒推就这一句话让我意识到它和之前用过的那些代码补全工具完全不是一个物种。补全工具关心的是下一行写什么而 claude code 关心的是你想解决什么问题。这个区别听起来很虚但落到实际工作里它改变的是整个工作流的节奏。以前我写代码是想清楚再写现在变成了边聊边想边想边写。很多时候我还没完全想明白一个模块该怎么拆就先跟它描述需求在对话的过程中思路自己就清晰了。它像一个随时在线的结对伙伴不会替你写全部代码但会在你卡住的时候推你一把。这篇文章不打算写成工具说明书那种东西官方文档比我写得好。我想聊的是一个普通开发者用了几个月之后工作方式到底发生了哪些具体的变化哪些变化是好的哪些地方还需要留个心眼。如果你正在犹豫要不要把它纳入日常工作流或者已经用了但感觉没发挥出全部价值下面的内容应该能给你一些参考。2. 对话式编程的真实体验它到底改变了什么2.1 从搜索-复制-修改到描述-生成-验证以前遇到一个不熟悉的 API 或者库我的标准流程是打开搜索引擎翻三五个结果找到最接近的代码片段复制到编辑器里然后根据实际情况改。这个过程里最耗时的不是写代码而是筛选信息——你要判断哪个答案是对的、哪个版本是过时的、哪个方案在你的场景下不适用。用 claude code 之后这个流程被压缩成了两步描述你的场景然后验证它给的方案。比如我需要给一个批量任务加限流以前得去查各种限流算法的实现现在直接说我有一个批量任务需要控制每秒最多处理 50 条超过的排队等待用 Python 实现它会给出一个基于令牌桶或者漏桶的完整实现还会附带说明为什么选这个方案。但这里有个关键点验证环节绝对不能省。我踩过一次坑让它写一个带重试逻辑的 HTTP 请求封装它给的代码逻辑上没问题但重试的退避策略用的是固定间隔而我的场景里下游服务在过载时需要的是指数退避。这个错误不是它写错了而是我没说清楚。所以现在的习惯是拿到代码先跑一遍再针对边界条件追问几句确认它理解了我的意图。2.2 上下文理解带来的少解释红利claude code 最让我惊喜的能力是上下文保持。在一个会话里我不需要反复解释项目背景。比如我先让它看了项目的目录结构然后说在 utils 下面加一个日期处理的工具函数它能自动推断出项目的命名风格、导入习惯、甚至测试文件的组织方式。这个能力在重构场景下特别有用。我做过一次比较大的重构把一个单体模块拆成三个独立服务。整个过程我就是在对话里一步步描述拆分方案它帮我生成新文件的骨架、迁移旧代码、更新引用路径。最夸张的是它还会主动提醒我你刚才把 A 模块的配置读取逻辑移到了 B 模块但 C 模块里还有一处直接引用了 A 的配置需要一起改。这种跨文件的关联提醒在以前只有靠 IDE 的全局搜索加上自己的记忆力。不过上下文也不是无限的。会话开得太长之后它对早期内容的记忆会变模糊。我的经验是一个会话专注一件事重构就重构写新功能就写新功能不要混在一起。如果确实需要跨会话保持上下文把关键决策和约定写成简短的说明放在项目根目录的文档里下次开新会话时先让它读一遍。2.3 调试场景下的第二双眼睛调试是 claude code 最能体现价值的场景之一。以前遇到一个诡异的 bug我可能要花半小时在日志和断点之间来回切换。现在我会把报错信息、相关代码片段、以及我已经尝试过的排查步骤一起丢给它然后问根据这些信息你觉得最可能的原因是什么它不一定每次都能直接给出正确答案但它能帮你排除掉很多可能性。有一次我遇到一个间歇性的数据不一致问题自己排查了半天没头绪。它看了代码之后说你的写入操作和读取操作之间没有事务保证在高并发下可能出现读到旧数据的情况。这个方向我其实想过但觉得概率太低就跳过了。被它这么一提醒我回去加了日志验证果然是这个问题。注意它给出的排查方向需要你自己验证不要直接当成结论。它的价值在于拓宽你的思路而不是替代你的判断。3. 那些让我回不去的具体场景3.1 陌生代码库的快速上手接手一个别人写的项目以前的做法是先看 README再看目录结构然后从入口文件开始一行行读。这个过程少则半天多则两三天。用 claude code 之后我会直接把整个项目目录丢给它然后问几个问题这个项目的核心业务逻辑在哪个文件里数据从入口到落库经过了哪些处理步骤有哪些地方是明显的技术债或者临时方案它给出的回答不一定百分之百准确但能让我在半小时内建立起一个大致的心智模型。有了这个模型之后再去读具体代码效率完全不一样。就像去一个陌生城市先看地图知道东南西北再走街串巷就不会迷路。3.2 写测试用例的苦力活被接管写单元测试是我以前最不喜欢的工作之一。不是不会写而是写起来太机械——每个分支都要覆盖每个边界都要考虑写完之后还要维护。现在我的做法是把被测函数丢给 claude code说帮我写单元测试覆盖所有分支和边界条件用项目现有的测试框架。它生成的测试用例质量相当高经常能覆盖到我自己没想到的边界情况。比如一个字符串处理函数它会测试空字符串、超长字符串、包含特殊字符的字符串、以及各种编码格式。我只需要检查一遍把不符合项目规范的调整一下就行。但这里有个坑它生成的测试有时候会过度拟合当前实现。也就是说如果当前实现有 bug它生成的测试可能会把这个 bug 当成预期行为。所以我的习惯是先自己确认被测函数的预期行为再让它写测试写完之后人工审查一遍断言逻辑。3.3 文档和注释的自动化生成写文档这件事大家都知道重要但真正写起来又觉得浪费时间。claude code 在这方面的表现让我很满意。我只需要给它一个模块的代码说生成一份面向新人的使用文档它就能输出一份结构清晰、示例完整的文档。更实用的是注释生成。对于复杂的业务逻辑我会在关键函数上方加一行注释说明意图然后让它根据代码逻辑补充详细的参数说明和返回值说明。这样既保证了注释的准确性又省去了逐行写注释的时间。不过要注意它生成的文档需要你审核业务逻辑的准确性。技术细节它不会错但业务规则它可能理解偏差。比如一个订单状态流转的函数它可能把某个状态的转换条件写反了因为它不知道实际的业务约束。4. 踩过的坑与应对策略4.1 过度依赖导致的能力退化焦虑用了几个月之后我发现自己有一个微妙的变化遇到问题第一反应是问它而不是自己思考。这个变化一开始很舒服但时间长了之后我发现自己对某些基础 API 的记忆变模糊了排查问题的直觉也变迟钝了。这不是 claude code 的问题是我自己的使用方式出了问题。后来我给自己定了一个规矩简单问题自己解决复杂问题先自己想五分钟再问它。五分钟想不出来再向它描述问题。这样既保留了独立思考的习惯又能在真正卡住的时候获得帮助。4.2 代码安全与敏感信息的边界这一点必须单独拿出来说。用任何 AI 辅助工具都要注意不要把敏感信息传进去。我的做法是数据库连接串、密钥、token 这类信息在传给工具之前一律替换成占位符涉及核心业务逻辑的代码如果公司有规定不能外传就严格遵守用脱敏后的代码片段来描述问题而不是直接贴完整文件提示养成先脱敏再提问的习惯这应该成为使用任何 AI 工具的基本素养。4.3 生成代码的质量参差不齐claude code 生成的代码质量波动比较大。同一个需求不同的描述方式它给出的实现可能完全不同。有时候它会给出一个非常优雅的方案有时候又会写出很啰嗦的代码。我的应对策略是重要的代码让它给两个方案然后对比选择。比如用两种不同的方式实现这个功能一种偏向性能一种偏向可读性然后根据实际场景选一个。这样比只拿一个方案要靠谱得多。另外它生成的代码有时候会引入不必要的依赖。比如一个简单的日期格式化它可能建议你装一个第三方库而标准库其实就能搞定。所以拿到代码之后先看它引入了哪些依赖评估一下是否必要。4.4 会话管理的经验前面提过会话要专注这里再补充几个细节每个会话开始时先花一分钟说明项目背景和当前任务比直接问问题效果好很多如果会话变得很长响应质量下降果断开新会话把关键结论复制过去重要的决策和代码片段及时保存到本地文件不要只留在会话记录里我现在的习惯是每个工作日结束时把当天会话里产生的关键代码和决策整理到一个笔记文件里。这样既方便回顾也避免了会话丢失导致的信息损失。5. 我的日常使用流程从早到晚的实际操作5.1 早晨规划当天任务每天开始工作之前我会花十分钟跟 claude code 过一遍当天的任务。比如我今天需要完成用户模块的接口重构涉及三个文件这是当前的代码结构你觉得应该按什么顺序改它会给出一个建议的修改顺序通常是从底层依赖开始逐步往上改。这个顺序我自己也能想出来但让它说一遍的好处是在描述的过程中我自己也会重新审视一遍计划有时候会发现遗漏的依赖关系。5.2 上午集中写代码上午是我效率最高的时段通常用来写核心逻辑。这个阶段我会频繁使用 claude code 的代码生成能力但不会完全依赖它。我的做法是自己先写一个骨架把关键的函数签名和数据结构定下来然后让它填充具体实现。这样既保证了对代码结构的掌控又利用了它生成代码的速度。填充完之后我会自己通读一遍把不合理的部分改掉。这个过程比从头写快很多而且经常能从它的实现里学到一些新的写法。5.3 下午调试和测试下午通常用来处理上午留下的问题以及写测试。调试的时候我会把报错信息和相关代码一起丢给它让它给出排查方向。测试的话直接让它生成然后自己审查和调整。这里分享一个技巧让它生成测试的时候同时要求它生成测试数据的构造代码。比如帮我写这个函数的单元测试包括测试数据的构造这样你拿到的是一套可以直接跑的完整测试而不是一堆需要自己补数据的空壳。5.4 傍晚整理和文档下班前半小时我会用 claude code 整理当天的代码变更生成变更说明和文档。比如这是今天修改的文件列表和 diff帮我写一份变更说明面向团队成员。它生成的变更说明通常很清晰我只需要调整一下措辞就行。这样第二天早上团队成员看到变更记录时能快速理解改了什么、为什么改。6. 关于变化的几点个人体会用了这么久最大的变化不是写代码变快了而是思考问题的方式变了。以前遇到一个需求我会直接想怎么实现现在我会先想这个需求的本质是什么有没有更简单的解法。因为跟 claude code 对话的过程本身就是一个不断澄清需求的过程。你描述得越清楚它给的方案越靠谱而描述清楚的过程就是你理清思路的过程。第二个变化是对代码质量的容忍度变低了。以前看到一段能跑的代码就懒得改现在会习惯性地问一句这段代码有没有更好的写法。因为获取改进方案的成本变低了所以更愿意去优化。第三个变化是学习新技术的门槛降低了。以前学一个新框架要花很多时间读文档、跑示例。现在可以直接让 claude code 用这个框架写一个最小可运行的 demo然后基于 demo 去理解核心概念。这种先跑起来再深入的学习方式比从头啃文档效率高很多。当然也有需要警惕的地方。工具越强大越容易让人产生我什么都能做的错觉。但实际上claude code 能帮你写代码不能帮你做技术决策能帮你排查问题不能帮你承担线上故障的责任。它是一把好用的锤子但你要知道什么时候该用锤子什么时候该用螺丝刀。最后分享一个我最近在用的技巧每周花半小时把这一周跟 claude code 的对话记录翻一遍看看哪些问题问得好、哪些问题问得不好。问得好的问题总结成模板存起来问得不好的问题想想下次怎么描述更清楚。这个习惯坚持了一个月之后我跟它协作的效率明显又上了一个台阶。
阅读完成 · 觉得有帮助？
