想让 MiniMax Code 在交付前自己跑一遍测试，关键不在“让它跑”，而在事先把三件事写死：交出去哪些命令、结果必须回传什么、失败后哪些文件不许动。编码 Agent 通常能在终端里执行 shell 命令并读回标准输出和退出码，但这只是“执行”能力，不等于“判断通过”的能力——测试算不算通过、失败后能不能顺手改测试，需要你在任务描述里限定，而不是让它临场发挥。

可执行的判断是：把验证前移成 Agent 交付前的自检环节，适用场景是本地仓库、命令可一键执行、失败可复现的日常改动；操作上先从 CI 配置和项目脚本里挑出测试、构建、静态检查三条命令，写进任务描述作为完成条件，并要求回传退出码、失败用例名和日志片段；验证方式是人工抽验一条最小复现命令，与 Agent 回传结果对照。边界在于：带数据库迁移、外部网络依赖、长时间 e2e 的命令不建议直接交给 Agent 自判，测试文件与测试配置应列为禁止改动项，失败时先报告再询问，不能让它为了提高通过率而改测试或跳过用例。

先把项目里能一键跑的验证命令找出来

不要凭印象挑命令。仓库里已经有作者认可的最小验证集，位置通常在 package.json 的 scripts、Makefile 或 justfile 的目标、pyproject.toml 的 pytest 段、tox.ini，以及 CI 配置（.github/workflows、.gitlab-ci.yml 之类）。CI 里能跑通的命令，通常是副作用最小、依赖最清楚的一批。

# 在仓库根目录执行，先看清楚有哪些入口，不急着跑全量
sed -n '/scripts/,/}/p' package.json
sed -n '/tool.pytest/,/^\[/p' pyproject.toml
grep -n '^[a-zA-Z_-]*:' Makefile | head -20
# 只打印不执行，确认 make 目标会做什么
make -n test

找到候选命令后，先评估两件事：耗时和副作用。静态检查和类型检查通常几秒到几十秒，适合每次交付都跑；单元测试按目录或单文件跑，通常可控；涉及启动数据库、写临时目录、发外部 HTTP 请求、生成构建产物的命令，需要确认 Agent 执行的沙箱里这些依赖是否具备，否则失败原因会混进环境问题，回传日志也没法判断是代码错还是环境错。

• 可以直接交：格式与 lint 检查、类型检查、按目录或单文件的单元测试。
• 谨慎交：需要本地服务或容器的集成测试、会写 lockfile 或产物目录的构建命令，先确认命令是否幂等。
• 不建议交：全量 e2e、带数据迁移的脚本、会推送到远端或发请求到外部环境的命令。

把验证命令写进任务描述里作为交付条件

把自检写成“完成后请顺便跑一下测试”，Agent 往往理解为可选动作；写成“交付条件”，它才会把结果当作必须回传的内容。任务描述里给全命令原文、执行顺序和回传格式，能省掉大量来回追问。

任务：把 src/order/calc.ts 里折扣计算改成按分计算，避免浮点误差。

交付前必须按顺序执行以下命令，并逐条回传结果：
1. npm run lint -- `--quiet`
2. npx tsc `--noEmit`
3. npx jest src/order `--runInBand`

回传格式（每条命令一段）：
- 命令原文
- 退出码
- 失败用例名或报错首行
- 最后 40 行日志

三条命令退出码全部为 0 才算完成；任一非 0，停止修改，
先按失败处理规则报告，等我确认后再动。

执行顺序建议由快到慢：先静态检查，再类型检查，最后跑测试。原因很实际：语法和类型错误会让测试输出被大量噪声淹没，先跑便宜的检查能缩短失败定位路径。回传信息里，退出码是硬指标，失败用例名用于定位，日志片段用于核对有没有被过滤或截断。可以让 Agent 额外说明本次改动涉及哪些文件，方便后面比对禁止改动清单。

约定失败后的处理方式

Agent 为了让命令变绿而改测试、加跳过标记、放宽断言，是最常见也最难事后发现的问题。约定要写在任务描述里，且用“禁止”而不是“尽量”。

• 禁止改动：测试文件与用例数据、fixture、snapshot、测试框架配置（jest.config、pytest.ini、vitest.config 等）、lint 规则文件、CI 配置、tsconfig 中与测试相关的路径配置。
• 禁止使用绕过手段：`--passWithNoTests`、`--forceExit`、test.skip、xit、@pytest.mark.skip、注释掉断言、把断言范围缩小到必然成立。
• 依赖 lock 文件默认不改，除非任务本身就是升级依赖。

如果验证命令失败，按以下顺序处理：
1. 先回传失败的命令原文、退出码、失败用例名和关键日志；
2. 说明你判断的失败原因，指出涉及哪个源文件哪一行；
3. 不要修改测试文件、fixture、snapshot、测试配置、lint 规则、CI 配置；
4. 不要用 skip、forceExit、删断言的方式让命令通过；
5. 报告后停下来等我确认，再决定改实现还是改测试。

这条“先报告再询问”的写法，实际作用是把判断权留在人手里。多数情况下失败确实是实现问题，Agent 改实现就能修好；但当失败暴露出需求本身有歧义时，让它自行“修到通过”，等于让实现去迁就旧测试。

人工复核它回传的日志而不是只看结论

“跑过了”和“跑对了”是两件事。Agent 说“测试已通过”时，需要回到日志里确认四类信息：命令原文是否和你给的一致、退出码是否为 0、汇总行里失败与跳过的数量、有没有被过滤掉的输出。

• 关键行：FAIL / Failed / ERR! / error TS 开头的行；Tests: 后面的 passed、failed、skipped 汇总；Snapshot 是否出现 written 或 updated；警告是否在本次改动后新增。
• 退出码对应：0 表示命令自身判定通过；1 通常表示有测试失败或检查不通过；127 表示命令不存在，多半是路径或依赖没装；被信号终止或超时则是另一个类别，不能当作通过。
• 识别被吞掉的退出码：命令里出现 | tail、|| true、; echo done 时，真实退出码可能已经丢失，需要让 Agent 单独执行原命令或用 set -o pipefail。
• 识别被跳过的用例：pytest 加 -rs 或 -v 能看到 SKIPPED 及原因；jest 用 `--verbose` 后汇总行会显示 skipped 数量；也可以直接搜测试文件里的 skip、only 标记。

如果日志只有一句“全部通过”而没有命令原文和退出码，就当作没有验证。可以让 Agent 重跑并原样粘贴，不需要它重新总结。

在提交前补一次人工抽验

自检结果需要一个独立确认，最省成本的做法是人工跑一条最小命令，覆盖本次改动最核心的分支。选取原则上优先挑两类用例：与改动逻辑直接相关的新增或修改用例，以及最容易被“放松断言”掩盖的那条边界用例。数量不必多，一条到两条即可。

# 单文件单用例，跑得快，结果容易判断
npx jest src/order/calc.test.ts -t 'discount by cent' `--runInBand`

python -m pytest tests/test_order.py::test_discount_rounding -x -q

抽验结果和 Agent 回传不一致时，处理顺序建议是：先以人工结果为准，再回到工作区看 diff 有没有动测试文件或测试配置，然后核对 Agent 执行的命令原文是否和你给的完全一致（参数、路径、过滤条件），最后复跑原命令确认是否可复现。常见的不一致来源是 Agent 用了带过滤的命令、在错误目录执行、或测试进程被缓存影响。确认差异原因之后，再决定是让 Agent 修实现，还是调整验证命令本身。