小需求读改测一整轮：Cursor 配 Claude 走完，留下改动清单

一句话结论

小需求用 Cursor 读代码改代码、Claude 审 diff 出用例，一轮读改测通常半天内走完，产出是改动清单加自测记录。

这篇解决什么问题

研发日常里最多的不是大重构，是那种「改一个接口、加两个参数」的小活。它不难，但要读链路、要改对地方、要自己验一遍，注意力来回切换，一件事能耗掉大半天。

适用：边界清楚、改动落在已有代码里、本地能起服务的中小改动。不适用：涉及表结构迁移、跨服务协议变更或者要上灰度的活，这类还是得人自己主导评审。

开始前要准备什么

• Cursor，本地能索引到仓库；个人版有免费额度，团队版按人收费
• Claude，网页版免费额度够几轮对话，贴长 diff 建议用上下文宽的档位
• 一段能跑起来的分支，服务起得来，日志能看
• 需求原文，最好带上用户反馈那句原话，别只给自己一句结论
• 时间预算：一个下午内跑完，读、改、测各占一段

具体怎么做

下面这一轮拿的是个真实的小需求：报表导出接口要支持按时间范围过滤，参数是 startTime 和 endTime。项目名和字段名做了替换，走法可以直接挪到你的活上。

第 1 步 · 只读不改，先摸清链路

AI 一上手就改代码，改的往往是它第一眼看到的那层，不是该改的那层。我在实操中发现，先逼它把调用链和调用方列出来，后面能少返工一大截。

你是我的代码阅读助手。现在有一个需求：给报表导出接口增加按时间范围过滤，参数为 startTime 和 endTime，格式 yyyy-MM-dd HH:mm:ss。
请只读不改，在仓库里回答四件事：
1. 这个需求涉及的调用链，从入口 Controller 到最终查询，按「文件 + 方法」列出来；
2. 每个环节现在做了什么，跟时间过滤有关的部分单独标出；
3. 这个导出方法是否还有别的调用方？有的话全部列出；
4. 你判断最容易出问题的地方在哪，说理由。
不要输出任何代码改动，不要建议重构，等我确认后再动手。

预期产出：一张调用链清单，加上「这个方法还有谁在调」的答案。要是真挖出第二个调用方，后面的改动方案当场就得改。

第 2 步 · 先要方案，别急着要代码

这一步是把「改哪、为什么改」定死。Cursor 手里有仓库上下文，适合干这个；但必须逼它写清楚「不动的地方」，不然它顺手给你重构一片。

基于刚才梳理的链路，给我一份改动方案，先别写代码。
输出格式：编号 | 文件 | 改动点 | 为什么改在这里 | 风险 | 是否必改（必改 / 建议 / 可不动）
要求：
– 每个改动点控制在一行以内；
– 单独列一节「我建议不动的地方」，说明理由；
– 针对入参校验、时区、空值、SQL 拼接方式这四类风险，各给一句结论；
– 如果需求本身有歧义（比如结束时间是否包含当天），列出来问我，不要自己假设。

预期产出：一份带编号的改动清单，每条挂着文件和风险等级。这份东西后面不用重写，归档时直接用。

第 3 步 · 小步改，一次只动一个文件

让它一口气改五个文件，出了问题上哪找都不知道。我的习惯是一次一个文件，改完先看 diff，确认了再往下走。

现在按方案里的第 1 至第 3 条改，一次只改一个文件，改完停下来等我确认。
约束：
– 不改公共工具类，不动数据库索引；
– 时间参数解析沿用项目现有写法，不要引入新依赖；
– 每次改完输出：改了哪个方法、新增删减多少行、会影响哪些调用方；
– 有拿不准的地方先问我，不要自己补默认值。

预期产出：能跑起来的改动，加上每处的说明文字。这些说明攒起来，就是改动清单的正文。

第 4 步 · 把 diff 单独丢给 Claude 审

为什么不接着用 Cursor 审：同一个模型刚写完，容易顺着自己的思路点头。Claude 拿到的是干净 diff 加少量上下文，视角更接近外面来的 reviewer。很多人忽略这点，觉得同一轮对话里追问一句「有没有问题」就够了。

下面是一个 Java 服务的 git diff，需求是给导出接口增加时间范围过滤。
请以 reviewer 视角审这段改动，只基于 diff 和我贴的上下文判断，不要猜测仓库里其它文件的内容。
按严重度分组输出：阻塞 / 应该改 / 建议。
每条写：问题是什么、什么条件下会触发、改法一句话。
重点看四类：边界值（结束时间含不含当天）、空值与默认值、时区与格式、对老调用方的兼容性。
如果确实没问题就直接说没有，不要为了凑数编问题。
diff：
【在这里粘贴 diff】
相关上下文：
【粘贴被改动方法的原实现、参数校验工具类的片段】

预期产出：一份按严重度排序的问题列表。我这一轮被挑出两处边界问题，其中一处是结束时间没含当天，属于真会出事的那种。

第 5 步 · 让 AI 出用例，人跑完记结果

用例交给 AI 出，执行还是自己来，或者让它落成单测你按运行键。这步别偷懒，自测记录的价值全在「实际结果」那一列上。

基于上面的 diff 和 review 结论，产出一张测试用例表。
列：编号 | 类型（正常 / 边界 / 异常）| 输入 | 预期结果 | 覆盖的风险点
要求：
– 至少覆盖这几种：只传开始时间、只传结束时间、两个都不传、开始时间晚于结束时间、格式非法、跨月跨年、结束时间正好是当天 23:59:59；
– 每条用例的预期结果要具体到返回值或者报错文案，不要写「正常返回」；
– 标出哪几条必须手工验证（比如依赖数据库时区的），不要全指望单测。

预期产出：一张用例表，跑完把实际结果补在后面，就是自测记录。被标成手工验证的那几条，也得在上面留痕。

实测记录

最容易错的 3 个地方

1. 第一步就让它改代码。容易动到公共方法。纠正：先锁只读，要调用方清单。
2. 整个仓库丢给 Claude 审。它会引用不存在的文件。纠正：只贴 diff 和片段。
3. 用例不写预期结果。跑完只记「通过」等于没测。纠正：输入和预期都写死。

可复用的东西

五步提示词其实是一套固定骨架：只读摸链路 → 要方案不要代码 → 单文件改 → 外部审 diff → 出用例记结果。换需求时只改方括号和第一句里的需求描述，其余约束别删，尤其是「不要自己假设」和「没问题就直说」这两句。

改动清单的列也可以固定：文件、改动点、理由、风险、是否必改。自测记录就三列，输入、预期、实际。这么攒两三次之后，你会发现自己写提交说明都比以前清楚。

说到底，AI 在这条链路上承担的是「读得快、问得细」，判断和验收还在人这边。你手上那个改了一半的小需求，现在是卡在读代码，还是卡在自测那一步？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接