拓冰网站定制 
Cursor 终端工作流让 Agent 跑测试、读失败日志、只改红测相关文件Agent 最容易「看起来勤奋」的方式是改一堆文件、宣称修好了、却换了一条更宽的测试命令或者删掉失败断言装绿。终端工作流的解药很老派——红测即规格你给定精确命令让 Agent 跑、读、改、再跑同一条命令直到退出码为 0且 diff 仍落在相关文件内。本文给出可复制的Cursor 终端闭环提示词配方、范围控制话术、完成定义DoD。适合 pytest / Jest / Go test / 包管理器 filter 测试不绑定单一语言。摘要命令由人给定精确到文件或-k/name filterAgent 不得擅自换全量「蒙混」。先读失败日志再改根因说不清就继续只读。文件白名单 禁止事项写进同一条提示词。同一命令复跑作为唯一绿灯信号。人工看 diff绿了不等于对了。结论终端退出码是裁判红测文本是需求Agent 只是执笔。结论卡环节好人做什么坏人惯性跑精确命令擅自全量或跳过读定位断言/栈不读就猜改相关文件最小 diff重构半个仓验同命令再跑换命令装绿交解释根因「应该好了」背景与边界Cursor Agent 可以经你的批准运行终端命令权限模型以你的客户端设置为准。把测试跑在 Agent 回路里收益是减少「复制粘贴日志」的摩擦风险是 Agent 获得了更强的副作用面——删文件、改 CI、网络请求。因此工作流必须自带闸门。边界不教跳过公司安全策略不建议在生产库跑迁移当「测试」不承诺某模型一次修通。并行 flaky 测试要先隔离再让 Agent 碰。原理红绿循环接到 Agent经典 TDD/调试节奏红 → 绿 →可选重构。接到 Agent 后变成人给出红测命令与范围Agent运行或阅读你粘贴的失败输出Agent提出将改文件列表人可确认Agent最小修改Agent复跑同一命令人审 diff 根因解释。跳过 3 或 6短期更快长期更乱。步骤 1准备一条「诚实」的红测命令好命令的特征可重复同事粘贴也能复现足够窄单文件、单 case、或包 filter退出码可信失败非 0成功为 0输出可读不要默默吞掉断言信息。示例示意# Pythonpytest tests/test_refund.py::test_idempotent_retry-q# JSpnpmexecjest packages/payments/src/refund.test.ts-tidempotent# Gogotest./internal/billing-runTestRefundIdempotent-count1把命令写进提示词原文不要说「你自己找测试」。步骤 2范围控制话术允许 - 修改红测直接指向的生产代码文件 - 修改同模块内为让断言成立所必需的最小辅助函数 - 补充与该红测直接相关的测试断言若我要求 禁止 - 重构无关模块 / 重命名公开 API - 「顺便」升级依赖或改 CI - 删除或 skip 失败测试装绿 - 扩大到全仓格式化 - 修改与本失败无关的快照文件除非失败点就是快照且我授权把「允许/禁止」当成每次任务的必填段而不是年终才写的规范。步骤 3提示词配方四段## 上下文 tests/...失败测试 src/...被测模块 ## 命令唯一验收 请运行{精确命令} 不要改用其他命令作为成功标准。 ## 约束 {允许/禁止} 先列出将修改的文件路径我回复「改」之后再动若你无权等待则列出计划并保持最小集合。 ## 交付 1. 根因一句话 2. diff 涉及文件列表 3. 同一命令的最终退出码与关键输出摘要若你更信任「Agent 直接改」可删掉确认句但DoD 不能删。步骤 4读失败日志的正确姿势要求 Agent或你自己在改之前输出失败断言期望 vs 实际顶层栈里你们仓库内的前 3 个位置是逻辑错误、测试过时、还是环境问题后两者处理策略不同。环境问题缺服务、端口、凭证应停手升级人工而不是让 Agent 改业务代码「绕过」。步骤 5复跑与完成定义Agent 说好了时你核对同一条命令退出码为 0diff 文件集合可解释、与红测相关无密钥、无无关大爆炸格式化相关类型检查/静态检查若存在已对触及包跑过你能用一句话解释根因并同意该修复解释不了根因打开 Ask只读追问「为什么这样改是对的」或git diff自己审。碰巧绿是技术债的一种。进阶把工作流钉进 Rules在.cursor/rules的测试域规则glob 指向**/tests/**写短句修复测试时使用用户给出的命令禁止 skip/delete 失败用例装绿 先报告根因再改diff 限于相关文件。RememberRules 不能替代每次任务里的精确命令。与 CI 的关系本地绿、CI 红时把 CI 日志中的同一命令拉回本地注意版本与环境差。仍用同一套提示词只是把「失败输出」换成 CI 片段。不要让 Agent 在看不懂 CI 容器差异时狂改业务。踩坑清单坑症状处理换命令装绿本地「通过」但 case 没跑到锁死命令字符串删测试文件变少、绿色喜人Code review 拒绝过度 mock测试通过、现实失败要求说明 mock 边界flaky有时好有时坏先稳定测试再修权限过宽Agent 乱跑 rm/curl收紧命令审批日志太长Token 爆炸摘要失败段勿整文件回灌30 分钟练习故意写坏一个断言或生产逻辑制造红测。用本文模板让 Agent 修。故意在禁止项里写「不许改测试」看它是否遵守。记录轮次数、diff 行数、你是否看懂根因。练的不是模型分数是你的闸门肌肉。验收标准工作流模板在两种语言/测试跑通至少拦住一次「想 skip」或「想扩 scope」团队成员能复述 DoD 五条与「Ask 设计评审」衔接大改先评审再进本工作流多包 Monorepo 下的命令策略大仓里最常见的作弊是Agent 跑了根目录全量测试碰巧绿但失败包根本没被编译到。对策命令带 filterpnpm --filter payments test或进入包目录再跑在提示词写「禁止改用根目录全量作为成功标准」。与多根工作区文结合工作区只挂相关包时Agent 更难「无意」跑到别处——但仍要写进文字约束因为工具仍可能发现 git 根。失败日志怎么喂才不爆 Token不要把 5000 行 CI 日志整段丢进聊天。正确喂法保留命令行与退出码截取第一个失败断言块含期望/实际截取仓库内栈帧 1030 行若有Caused by保留最内层。并在提示词写「若需更多日志向我请求行号范围不要自己假设。」这能同时降历史税与幻觉。当你必须允许「改测试」时有时红测本身过时API 已合法变更。此时不要偷偷删测试而要Ask 评审证明生产行为是新的真相人批准「允许修改测试文件集合」Agent 改测试断言并保留覆盖意图同命令复跑PR 描述写明「测试更新原因」。把「改测试」从默许变成显式授权能挡住大量装绿。与安全审批的交界终端工作流会触发网络、容器、云 CLI。公约应规定默认禁止生产凭据需要出网的测试用 mock任何curl | bash、任意下载脚本必须人工。Agent 跑测试的权力不等于运维权力。示例会话可读剧本你tests/test_cart.py::test_coupon 红了。 命令pytest tests/test_cart.py::test_coupon -q 允许改src/cart/coupon.py 禁止改测试、改 CI、全仓格式化。 先跑命令读失败再提出文件列表。 Agent运行后失败在 assert total 80实际 90。 根因怀疑优惠券未应用到折扣价。 计划只改 coupon.py 的 apply()。 你改。 Agent已改同命令退出码 0。根因...把这种剧本贴进团队 onboarding比抽象原则更易迁移。Flaky 测试协议若同命令连续三次结果不一致停止让 Agent 「再试直到绿」开 Ask是时间、顺序、网络还是共享状态先稳测试隔离、种子、假时钟再修业务公约可写flaky 未稳前禁止以 Agent 修复业务逻辑合并。否则你在训练 Agent 与人类一起迷信复跑运气。输出工件PR 描述最小段要求 Agent 在绿了之后生成## 根因 ... ## 验证 命令... 退出码0 ## 范围 仅... ## 风险 ...人复制到 PR。终端工作流的终点不是聊天窗绿色而是可审查的合并请求。并行多个红测怎么排不要让 Agent 同时修五个失败。排序建议先修阻塞编译/收集的错误再按模块逐个红测每绿一个就提交或至少 checkpoint下一个红测新开会话带上「已修复列表」。并行修多红测会让 diff 无法归责也让 DoD 失效——你不知道哪次改动治好了哪个病。记录个人基线花一周记录平均几轮对话修一个红测、平均 diff 行数、有多少次需要你否决扩 scope。基线不是为了考核模型而是为了看你的提示词是否在变好。若轮次下降而回滚上升说明你在用宽松换速度——及时收回禁止项。语言无关的命令表填空生态窄命令示例pytestpytest path::test -qjestjest file -t namevitestvitest run file -t namego testgo test ./pkg -run Name -count1cargocargo test name -- --nocapturePHPUnit./vendor/bin/phpunit --filter Name把你们仓库真实命令写进 WikiAgent 提示词直接引用减少「模型发明命令」。关闭会话前的清理绿了之后丢弃超大日志附件保存根因与命令到 PR新需求新会话不要在已充满失败栈的线程里开新功能。终端工作流与「隐形税」观点是同一枚硬币的两面。把「只改相关文件」写进 PR 模板## 测试 - 命令 - 退出码 ## 文件范围 - 计划内 - 实际 diff ## 声明 - [ ] 未 skip/删除失败用例 - [ ] 未无关格式化没有勾选就不要点合并。模板比口头提醒耐久。何时该停用 Agent 改测试出现以下信号立刻停同命令下失败断言每次漂移需要改生产数据才能复现涉及加密、支付清算、权限矩阵且你看不懂 diffAgent 连续两次试图改 CI 装绿。停用不是失败是工作流里的安全阀。换 Ask 或人工结对仍然保留同一红测命令当裁判。一句话纪律红测命令是唯一裁判相关文件是唯一舞台根因解释是唯一谢幕词。三句都成立才叫完成而不是「看起来绿了」。先红后绿先窄后宽先证据后自信——三条写进提示词置顶即可。小结Cursor 终端工作流是把 TDD 的裁判权夺回人类你掌握命令与范围Agent 掌握打字速度。跑、读、改、再跑——中间全是约束。只改红测相关文件不只是省 Token更是防止仓库在「自动化」名义下缓慢腐烂。草稿未发布 · 作者 梧桐秋海 · 活动九月创作之星、工具实践 Cursor + 终端工作流：让 Agent 跑测试、读失败日志、只改红测相关文件
Cursor 终端工作流让 Agent 跑测试、读失败日志、只改红测相关文件Agent 最容易「看起来勤奋」的方式是改一堆文件、宣称修好了、却换了一条更宽的测试命令或者删掉失败断言装绿。终端工作流的解药很老派——红测即规格你给定精确命令让 Agent 跑、读、改、再跑同一条命令直到退出码为 0且 diff 仍落在相关文件内。本文给出可复制的Cursor 终端闭环提示词配方、范围控制话术、完成定义DoD。适合 pytest / Jest / Go test / 包管理器 filter 测试不绑定单一语言。摘要命令由人给定精确到文件或-k/name filterAgent 不得擅自换全量「蒙混」。先读失败日志再改根因说不清就继续只读。文件白名单 禁止事项写进同一条提示词。同一命令复跑作为唯一绿灯信号。人工看 diff绿了不等于对了。结论终端退出码是裁判红测文本是需求Agent 只是执笔。结论卡环节好人做什么坏人惯性跑精确命令擅自全量或跳过读定位断言/栈不读就猜改相关文件最小 diff重构半个仓验同命令再跑换命令装绿交解释根因「应该好了」背景与边界Cursor Agent 可以经你的批准运行终端命令权限模型以你的客户端设置为准。把测试跑在 Agent 回路里收益是减少「复制粘贴日志」的摩擦风险是 Agent 获得了更强的副作用面——删文件、改 CI、网络请求。因此工作流必须自带闸门。边界不教跳过公司安全策略不建议在生产库跑迁移当「测试」不承诺某模型一次修通。并行 flaky 测试要先隔离再让 Agent 碰。原理红绿循环接到 Agent经典 TDD/调试节奏红 → 绿 →可选重构。接到 Agent 后变成人给出红测命令与范围Agent运行或阅读你粘贴的失败输出Agent提出将改文件列表人可确认Agent最小修改Agent复跑同一命令人审 diff 根因解释。跳过 3 或 6短期更快长期更乱。步骤 1准备一条「诚实」的红测命令好命令的特征可重复同事粘贴也能复现足够窄单文件、单 case、或包 filter退出码可信失败非 0成功为 0输出可读不要默默吞掉断言信息。示例示意# Pythonpytest tests/test_refund.py::test_idempotent_retry-q# JSpnpmexecjest packages/payments/src/refund.test.ts-tidempotent# Gogotest./internal/billing-runTestRefundIdempotent-count1把命令写进提示词原文不要说「你自己找测试」。步骤 2范围控制话术允许 - 修改红测直接指向的生产代码文件 - 修改同模块内为让断言成立所必需的最小辅助函数 - 补充与该红测直接相关的测试断言若我要求 禁止 - 重构无关模块 / 重命名公开 API - 「顺便」升级依赖或改 CI - 删除或 skip 失败测试装绿 - 扩大到全仓格式化 - 修改与本失败无关的快照文件除非失败点就是快照且我授权把「允许/禁止」当成每次任务的必填段而不是年终才写的规范。步骤 3提示词配方四段## 上下文 tests/...失败测试 src/...被测模块 ## 命令唯一验收 请运行{精确命令} 不要改用其他命令作为成功标准。 ## 约束 {允许/禁止} 先列出将修改的文件路径我回复「改」之后再动若你无权等待则列出计划并保持最小集合。 ## 交付 1. 根因一句话 2. diff 涉及文件列表 3. 同一命令的最终退出码与关键输出摘要若你更信任「Agent 直接改」可删掉确认句但DoD 不能删。步骤 4读失败日志的正确姿势要求 Agent或你自己在改之前输出失败断言期望 vs 实际顶层栈里你们仓库内的前 3 个位置是逻辑错误、测试过时、还是环境问题后两者处理策略不同。环境问题缺服务、端口、凭证应停手升级人工而不是让 Agent 改业务代码「绕过」。步骤 5复跑与完成定义Agent 说好了时你核对同一条命令退出码为 0diff 文件集合可解释、与红测相关无密钥、无无关大爆炸格式化相关类型检查/静态检查若存在已对触及包跑过你能用一句话解释根因并同意该修复解释不了根因打开 Ask只读追问「为什么这样改是对的」或git diff自己审。碰巧绿是技术债的一种。进阶把工作流钉进 Rules在.cursor/rules的测试域规则glob 指向**/tests/**写短句修复测试时使用用户给出的命令禁止 skip/delete 失败用例装绿 先报告根因再改diff 限于相关文件。RememberRules 不能替代每次任务里的精确命令。与 CI 的关系本地绿、CI 红时把 CI 日志中的同一命令拉回本地注意版本与环境差。仍用同一套提示词只是把「失败输出」换成 CI 片段。不要让 Agent 在看不懂 CI 容器差异时狂改业务。踩坑清单坑症状处理换命令装绿本地「通过」但 case 没跑到锁死命令字符串删测试文件变少、绿色喜人Code review 拒绝过度 mock测试通过、现实失败要求说明 mock 边界flaky有时好有时坏先稳定测试再修权限过宽Agent 乱跑 rm/curl收紧命令审批日志太长Token 爆炸摘要失败段勿整文件回灌30 分钟练习故意写坏一个断言或生产逻辑制造红测。用本文模板让 Agent 修。故意在禁止项里写「不许改测试」看它是否遵守。记录轮次数、diff 行数、你是否看懂根因。练的不是模型分数是你的闸门肌肉。验收标准工作流模板在两种语言/测试跑通至少拦住一次「想 skip」或「想扩 scope」团队成员能复述 DoD 五条与「Ask 设计评审」衔接大改先评审再进本工作流多包 Monorepo 下的命令策略大仓里最常见的作弊是Agent 跑了根目录全量测试碰巧绿但失败包根本没被编译到。对策命令带 filterpnpm --filter payments test或进入包目录再跑在提示词写「禁止改用根目录全量作为成功标准」。与多根工作区文结合工作区只挂相关包时Agent 更难「无意」跑到别处——但仍要写进文字约束因为工具仍可能发现 git 根。失败日志怎么喂才不爆 Token不要把 5000 行 CI 日志整段丢进聊天。正确喂法保留命令行与退出码截取第一个失败断言块含期望/实际截取仓库内栈帧 1030 行若有Caused by保留最内层。并在提示词写「若需更多日志向我请求行号范围不要自己假设。」这能同时降历史税与幻觉。当你必须允许「改测试」时有时红测本身过时API 已合法变更。此时不要偷偷删测试而要Ask 评审证明生产行为是新的真相人批准「允许修改测试文件集合」Agent 改测试断言并保留覆盖意图同命令复跑PR 描述写明「测试更新原因」。把「改测试」从默许变成显式授权能挡住大量装绿。与安全审批的交界终端工作流会触发网络、容器、云 CLI。公约应规定默认禁止生产凭据需要出网的测试用 mock任何curl | bash、任意下载脚本必须人工。Agent 跑测试的权力不等于运维权力。示例会话可读剧本你tests/test_cart.py::test_coupon 红了。 命令pytest tests/test_cart.py::test_coupon -q 允许改src/cart/coupon.py 禁止改测试、改 CI、全仓格式化。 先跑命令读失败再提出文件列表。 Agent运行后失败在 assert total 80实际 90。 根因怀疑优惠券未应用到折扣价。 计划只改 coupon.py 的 apply()。 你改。 Agent已改同命令退出码 0。根因...把这种剧本贴进团队 onboarding比抽象原则更易迁移。Flaky 测试协议若同命令连续三次结果不一致停止让 Agent 「再试直到绿」开 Ask是时间、顺序、网络还是共享状态先稳测试隔离、种子、假时钟再修业务公约可写flaky 未稳前禁止以 Agent 修复业务逻辑合并。否则你在训练 Agent 与人类一起迷信复跑运气。输出工件PR 描述最小段要求 Agent 在绿了之后生成## 根因 ... ## 验证 命令... 退出码0 ## 范围 仅... ## 风险 ...人复制到 PR。终端工作流的终点不是聊天窗绿色而是可审查的合并请求。并行多个红测怎么排不要让 Agent 同时修五个失败。排序建议先修阻塞编译/收集的错误再按模块逐个红测每绿一个就提交或至少 checkpoint下一个红测新开会话带上「已修复列表」。并行修多红测会让 diff 无法归责也让 DoD 失效——你不知道哪次改动治好了哪个病。记录个人基线花一周记录平均几轮对话修一个红测、平均 diff 行数、有多少次需要你否决扩 scope。基线不是为了考核模型而是为了看你的提示词是否在变好。若轮次下降而回滚上升说明你在用宽松换速度——及时收回禁止项。语言无关的命令表填空生态窄命令示例pytestpytest path::test -qjestjest file -t namevitestvitest run file -t namego testgo test ./pkg -run Name -count1cargocargo test name -- --nocapturePHPUnit./vendor/bin/phpunit --filter Name把你们仓库真实命令写进 WikiAgent 提示词直接引用减少「模型发明命令」。关闭会话前的清理绿了之后丢弃超大日志附件保存根因与命令到 PR新需求新会话不要在已充满失败栈的线程里开新功能。终端工作流与「隐形税」观点是同一枚硬币的两面。把「只改相关文件」写进 PR 模板## 测试 - 命令 - 退出码 ## 文件范围 - 计划内 - 实际 diff ## 声明 - [ ] 未 skip/删除失败用例 - [ ] 未无关格式化没有勾选就不要点合并。模板比口头提醒耐久。何时该停用 Agent 改测试出现以下信号立刻停同命令下失败断言每次漂移需要改生产数据才能复现涉及加密、支付清算、权限矩阵且你看不懂 diffAgent 连续两次试图改 CI 装绿。停用不是失败是工作流里的安全阀。换 Ask 或人工结对仍然保留同一红测命令当裁判。一句话纪律红测命令是唯一裁判相关文件是唯一舞台根因解释是唯一谢幕词。三句都成立才叫完成而不是「看起来绿了」。先红后绿先窄后宽先证据后自信——三条写进提示词置顶即可。小结Cursor 终端工作流是把 TDD 的裁判权夺回人类你掌握命令与范围Agent 掌握打字速度。跑、读、改、再跑——中间全是约束。只改红测相关文件不只是省 Token更是防止仓库在「自动化」名义下缓慢腐烂。草稿未发布 · 作者 梧桐秋海 · 活动九月创作之星、工具实践