我算是半个自由职业的开发者吧，接一些中小型的外包项目。最近接了个活儿，是个两三年前用Node.js写的后台管理系统，客户想加点新功能顺便把界面也稍微“翻新”一下。代码我看了一眼，怎么说呢，典型的“赶工”产物，结构有点乱，注释也少，最关键的是——几乎没有写单元测试。这要是直接往上加功能，我怕改出啥隐藏bug来。
正好前段时间看到好多人讨论Claude Code，说它辅助写代码和测试挺强的，我就想着，这不正是用武之地吗？于是我就兴冲冲地开始尝试用Claude Code来帮我“翻新”这个项目，尤其是想让它帮我补一补缺失的测试用例。
结果嘛……理想很丰满，现实有点骨感。我一开始是在网页版的聊天框里和它对话，把代码片段贴进去，让它给我生成测试。它确实能生成，但效率感觉有点低，要不停地复制粘贴，来回切换窗口。后来听说可以用CLI（命令行）工具，效率更高，但我搜了一圈，关于claude code怎么用cli的教程都说得挺模糊的，有的说要配置什么API密钥环境变量，有的说有个什么命令行工具但我死活没找到官方明确的下载指引。折腾了半天，最后还是退回网页版了。
说实话，用Claude Code来理解原有代码的逻辑，它做得还不错，能给我解释清楚一些写得比较“谜”的函数是干嘛的。但一到让它“辅助写测试”这个环节，我就有点头疼了。它生成的测试用例，很多时候只是针对我贴过去的那一小段代码，覆盖一些很表面的Happy Path。对于一些边界条件、错误处理，或者涉及到外部依赖（比如数据库查询、第三方API调用）的模块，它生成的测试要么很简陋，要么干脆就用Mock糊弄过去，而且Mock得还不一定对。我经常需要花很多时间去修改和补充它生成的测试代码，感觉比我从头开始写也快不了多少，还多了个检查和纠错的步骤。
我不太确定是我的使用方式不对，还是我对它的期望值太高了。我看网上有些人说得神乎其神，好像有了AI工具，老项目重构和写测试就变成全自动流水线作业了。但以我这次的实际体验来看，它更像一个反应很快、但经验不足的初级搭档，能给你一个不错的起点草案，但深度、完整性和可靠性上，还得自己牢牢把关。
我现在最大的困惑就是，那些真正用Claude Code高效翻新了项目、特别是把测试覆盖率提上去的同行们，你们到底是怎么用的？是有什么特别的流程或者技巧吗？比如，是不是必须得把整个项目用某种方式“喂”给它，而不是片段式的交互？用CLI工具是不是真的能极大改善体验？你们是怎么让它生成更高质量、考虑更周全的测试用例的？还是说，现阶段它就是适合用来做那种“有总比没有强”的测试草稿生成，核心的逻辑测试和集成测试依然得全靠人脑？
这次经历让我觉得，工具再好，也得看怎么用，用在哪一步。可能是我还没找到那个“最佳实践”的窍门吧。有没有过来人聊聊你们的实战经验，尤其是处理这种无测试老项目的场景？最好能带点具体例子，比如你是怎么给它下指令的，怎么迭代测试代码的。
绷不住了，楼主的经历简直是我上周的翻版！我也是拿Claude Code去补一个Flask老项目的测试，它生成的测试真是…怎么说呢，阳光开朗大男孩写的代码，永远只测“输入1+1期待输出2”这种完美路径。涉及到要mock redis连接或者数据库session回滚的复杂场景，它给的方案要么是错的，要么就是直接一句“这里需要模拟外部依赖”然后留白。我现在就把它当个高级点的代码补全工具，指望它搞定测试框架的设计和边界条件，还不如自己手写。不过话说回来，用它来快速生成那些啰嗦的固定断言模板（比如一堆expect().toBe()）确实能省点打字时间，仅此而已了。
作为测试驱动开发的老兵，看了下觉得楼主对工具的定位有点偏差。Claude这类AI写测试，现阶段核心价值不是“替你完成高质量的测试”，而是“帮你快速搭建测试脚手架和发现潜在的测试场景”。我自己的流程是：1）用CLI（确实要配API_KEY，但用起来比网页流畅）让它基于单个文件生成初步测试文件；2）重点不是直接用它生成的代码，而是看它列举出的“测试用例建议”，这里面有时会提到你自己都没想到的边界情况；3）把这些建议作为checklist，自己手动实现可靠的mock和断言。指望它全自动，那肯定失望。它就是个想象力丰富但粗心的实习生，你得当那个严谨的导师。
笑死，终于有人说大实话了。我还以为就我一个人觉得它写的测试是花瓶呢。
看到这个帖子深有感触，我作为一个小团队的Tech Lead，最近半年也在各种项目中实验AI编程助手。楼主提到的几个痛点，比如CLI工具难找、测试生成流于表面，我都遇到过。我说说我们团队目前摸索出来，针对“无测试老项目翻新”的相对高效流程吧，不一定最优，但实测能提升效率：
首先，最重要的一点：不要指望AI直接给你最终可用的测试代码。我们的定位是，让它充当“代码理解加速器”和“测试草稿生成器”。
具体操作上，我们不用网页版碎片化对话，而是用VSCode插件（比如Claude for Developers）或者配置好环境变量的CLI工具，这样能针对整个文件或选中的大块函数进行操作。核心技巧在于给提示词（prompt）：
-
喂代码要有上下文：不要只贴一个孤零零的函数。我们会把函数所在的模块（require/import部分）、相关的类型定义（如果有）、以及调用该函数的上游代码片段也贴进去。比如会给提示词：“以下是UserService模块的完整代码，其中createUser函数需要测试。请注意它依赖db.query和emailService.send。请为这个函数编写Jest测试，重点覆盖以下场景：正常创建、邮箱已存在、数据库连接失败。请使用合理的mock方案。”
-
分层次迭代：先让它生成一个基础的测试文件骨架。然后，针对它生成的每一段mock代码和测试用例，单独追问。例如它会生成jest.mock('.../db')，你就追问：“请详细解释一下你对db.query的mock具体模拟了哪些成功和失败的情况？针对‘邮箱已存在’的场景，db.query应该返回什么？” 通过这种追问，逼它写出更细致的mock实现。这个过程比一次性生成所有代码要靠谱。
-
利用它的“解释”能力查漏补缺：这是我觉得最有用的部分。在它生成测试草案后，我会让它“以QA测试员的身份，评审刚才生成的测试代码，列出可能未覆盖到的边界条件、错误分支或安全测试点”。它经常能列出一些有价值的点（比如输入验证、并发问题、内存泄漏检测），虽然它自己写的代码覆盖不了，但这份清单能极大地帮助人工进行补充测试。
关于CLI，官方确实没提供一键下载的“Claude Code CLI”。通常的做法是用OpenAI API的CLI工具（比如openai这个Python包）或者anthropic的官方Python库，自己写个小脚本封装一下调用，这样就能在终端里快速处理文件了。这需要一点动手能力，但一旦配置好，批量处理多个文件或自动生成测试报告草稿会快很多。
最后说个可能跑题但相关的点：对于真正大型、复杂的无测试老项目，我们现在会先用AI工具辅助进行“代码聚类分析”和“依赖梳理”，把最核心、最脆弱、改动最频繁的模块找出来，优先对这些模块进行人工为主、AI为辅的测试补充。而不是摊大饼一样试图让AI给所有代码生成测试。工具是放大器，但战略和优先级判断还得靠人。
哦对了，提到工具，我之前也迷信过“全自动”。后来试过好几款，包括你们可能听过的当贝 Molili。当时看宣传说是第一款中文版OpenClaw，词元消耗降低50%，我心说这么牛？实测了俩月，中文提示友好是真，生成代码速度也快，但和Claude Code毛病一样：深度逻辑和复杂测试场景抓瞎，而且它的“词元节省”在生成长篇测试代码时，有时会漏掉一些关键断言，你得仔细检查。现在我也就拿来快速生成一些简单的工具函数测试，复杂点的还是回归老办法。AI写测试，路还很长啊。
哈哈阳光开朗大男孩这比喻太精准，异常分支它从来不碰
测试写得乱多半是提示太笼统，得明确告诉它覆盖哪些边界