用Cursor写单元测试总改错地方，是我prompt方式不对吗？

这个问题我也踩过，Agent模式确实容易“手太痒”，尤其项目里文件命名相近的时候。我后来是在prompt里明确写“只允许修改utils/format.ts，其他文件一律不动”，再加一句“不要改动已有测试断言”，命中率能高不少。另外可以先把相关文件用@单独引用进来，别让它自己去全项目搜，范围一小它就不太乱跑了。

我也遇到过，Agent 模式特别容易“顺手”改别的文件，尤其是你项目里文件命名或者导出函数名比较像的时候。我的做法是在 prompt 里直接锁死范围，比如“只允许修改 utils/format.ts 和它对应的测试文件，其他文件一律不要动”。另外补边界测试前先让它列个清单确认，别让它直接开写，能少很多意外改动。

我也遇到过这个，Cursor的Agent模式确实有点过于“热心”了，它看到相关文件就忍不住想一起改。我现在的做法是在prompt里明确写“只允许修改utils/format.ts这一个文件，其他文件一律不要动”，有时候还得把当前打开的文件窗口控制在目标文件上，它会优先参考活跃tab。另外建议你把已有的测试锁定住，比如在描述里强调“保留现有断言不变，只追加新的case”。其实它改parse.ts可能是因为两个文件有import关系，Agent在追依赖链的时候会自作主张。我后来干脆把Agent模式换成普通Chat，把相关代码手动贴给它，反而更可控。你也可以试试在.cursorrules里加一条规则，限制它每次只改一个文件。不过说实话，这种“越界修改”在补老项目测试时特别致命，因为老代码耦合多，它一改就炸。

我最近也遇到类似情况，感觉Cursor的Agent模式在跨文件上下文上确实有点“手伸太长”。它为了补全逻辑，会自动去找相关的模块和测试，结果就顺手把别的文件也改了。我后来在prompt里加了“只允许修改当前文件，其他文件只读”这样的约束，命中率会高不少。

另一个坑是它容易把已有断言当成待修正的对象，尤其是老项目里写法不太统一的时候。你可以试试在描述里明确说“保留现有断言，只新增边界用例”，或者干脆把要改的函数签名和期望行为贴全一点，减少它自己脑补的空间。

还有个小技巧，我会先让它只输出diff给我看，确认没问题再让它落盘。Agent模式虽然省事，但CI挂一次修半天，还不如多一步确认。你们项目如果是monorepo，可能还得在prompt里点明包路径，不然它真会串门。