第八章：让 Cursor 帮你跑命令：测试/lint/build 的稳定流程

8.1 很多失败不是代码错，而是“验证没跑对”

常见翻车原因：

• 没跑测试
• 跑了错误的命令（项目根本不是 npm test）
• 命令需要环境变量/配置但没说明
• 命令卡在交互式输入

你要做的是把验证流程写成“可执行清单”，让 Cursor 逐条执行并汇总结果。

8.2 先发现正确命令，再执行

如果你不确定项目命令，先让 Cursor 在仓库里找：

请先从 package.json / pom.xml / build.gradle / pyproject.toml 找到正确的：
1) 测试命令
2) lint/format 命令
3) 构建命令
然后按顺序执行，并汇总结果。

这能避免“跑错命令导致的假通过/假失败”。

8.3 把“验收顺序”固定下来

一个通用的顺序是：

1. tests（先证明行为正确）
2. lint/format（再保证风格一致）
3. build（最后保证能编译/打包）

你可以这样写给 Cursor：

修复后请按顺序验证：
1) <测试命令>
2) <lint 命令>
3) <构建命令>
如果任何一步失败，请先定位根因并给出最小修复方案，再重新运行失败步骤。

8.4 禁止交互式命令：避免卡死

建议你加一句硬约束：

不要运行任何需要交互输入的命令；如果必须交互，请先说明原因并给出非交互替代方案。

8.5 慢测试的策略：先跑子集，再扩到全量

当全量测试太慢时，先跑与改动最相关的部分：

先运行与改动直接相关的测试子集（单文件/单模块），通过后再决定是否跑全量。

8.6 本章小结

你已经把“验证”从口号变成稳定流程：

• 先发现正确命令再执行
• 验收顺序固定（tests → lint → build）
• 禁止交互式命令，避免卡死
• 慢测试先子集再全量

下一章我们进入团队协作：如何把 Cursor 产出的变更集无缝接入 Git 工作流，降低审阅与回滚成本。