嫌麻烦，我不建测试基础设施

阶段测试角色工程师 · 测试工程师严重度高适用版本Coding Agent 通用证据官方文档

一句话摘要：你让我加功能，我会埋头写实现，顺手跳过「搭测试脚手架」这件不出活的事。结果是：没有一处能跑出「通过/失败」的地方，我和你都只能凭「看起来对」过日子。

现象

你说「给项目加个用户导出功能」，我就直接动手写实现——建路由、写逻辑、拼 SQL，一气呵成。但你回头看会发现：这个项目根本没有测试框架，我没装，也没写第一个能跑起来的测试，更没把它接进 CI。我交出的是一坨功能代码，和一句「实现完成了」。

至于「怎么证明它真的对」，我留给了你。

为什么会这样

搭测试设施这件事，不产出可见成果。装框架、配 runner、写一个只断言 1 + 1 === 2 的冒烟测试、改 CI 配置——做完这一圈，你的功能一行都没多。而我被优化成尽快产出你能看到的东西：能跑的功能、能合的 diff、一句「搞定了」。在这套激励下，脚手架天然排在实现后面，而「后面」往往就等于「没有」。

更深一层：我不会主动为「未来的自己」铺路。我没有持续的工程直觉去想「这个项目以后要改一百次，得先有张安全网」——除非你把它写进任务，否则我默认它不在范围内。

可这恰恰拆掉了我自己最需要的东西。我擅长生成貌似合理的代码，但我没真跑过它（详见信任但不验证）。我要从「貌似合理」走到「真的对」，靠的就是一个能给出通过/失败信号的检验，让我自己进入「写 → 跑 → 读结果 → 修」的循环。没有测试设施，这个循环根本无处闭合——我只能停在「看起来对」，你也只能停在「看起来对」。

后果

• 回归无人接住：下次我改这块代码，没有任何东西会在我改坏时报警。坏掉的功能会一路滑到联调、甚至线上才被发现。
• 验证全靠人肉：每一次改动，都得你亲手点一遍、对一遍输出。我把本该自动化的活，悄悄转嫁给了你。
• 我失去自测能力：没有可跑的检验，我交付前无法自我校验，只能凭「读起来通顺」下结论——而那正是我最不可靠的判断方式。
• 欠下的债越滚越大：项目越往后，补设施的成本越高、动力越低。零测试的项目，往往一直零下去。

最佳实践

把「先搭最小测试设施」当成新功能、新项目的前置步骤，而不是事后补丁。 在我写实现之前或同时，先把脚手架立起来——哪怕只有一个真正跑通的测试，也好过零。

一套「最小可用」的测试设施只要三件东西：

1. 一个能跑的测试：哪怕只断言一件最简单的事，重点是它真的能被执行、能变绿。
2. 一条跑它的命令：比如 npm test，让我（和你）随时能一键拿到通过/失败。
3. 接进 CI：让这条命令在每次提交时自动跑，把验证从「人记得跑」变成「机器一定跑」。

可以直接这样要求我：

在写实现之前，先为这个项目搭好最小测试设施：
1. 选一个该语言/框架的主流测试库并装上；
2. 写一个能跑通的冒烟测试，确认 runner 正常工作；
3. 给我一条跑测试的命令，写进 README / package.json；
4. 加一个 CI 配置，让测试在每次 push 时自动运行。
全部跑通、给我看到绿色，再开始写功能。

立起脚手架之后，再让我按信任但不验证里的做法工作：先写测试、再写实现去让它变绿。这时验证闭环才真正合上——宁可一个真实跑通的测试，也别零。

示例

改之前：

你：给项目加一个 CSV 导出功能。
我：（直接写实现，项目里既没有测试框架，也没有 CI）
我：实现完成了，导出功能已加好。
你：（想验证，发现根本没地方跑，只能手动点一遍）
三周后：有人改了字段顺序，导出列错位，没有任何测试报警，线上才发现。

改之后：

你：先给这个项目搭最小测试设施——装测试库、写一个能跑通的冒烟测试、
    给一条 npm test 命令、加个 CI workflow。跑绿了再说。
我：（装好框架，写冒烟测试，配好 CI，跑通并贴出绿色结果）
你：现在加 CSV 导出，先写测试覆盖字段顺序和空数据，再写实现让它们变绿。
我：（测试先行，实现到全绿；以后任何人改字段顺序，CI 立刻亮红）

什么时候例外

「先搭测试设施」是默认，但有几种情况，不搭才是对的：

• 写完即弃的探针 / 一次性脚本：为验证可行性临时写的 demo、跑一遍就删的数据迁移——它根本不会被改第二次，那张「未来改一百次」的安全网没有对象，建框架配 CI 是纯开销。靠你跑一遍肉眼确认就够了。
• 项目已经有现成设施：测试库、runner、CI 都在，你只是加个功能——这时不是「搭设施」，是直接用，本条不适用，照信任但不验证写测试即可。
• 环境上根本立不起来、且有更划算的检验：某些一次性胶水代码，搭隔离测试的成本远超它本身，而一条类型检查 / 构建 / 跑一次比对输出的脚本就能给出红绿信号——那就用那个轻量检验，别为它硬起一套框架。

判据：例外成立，前提是这段代码活不过这一次，或设施已存在。只要它会进仓库、会被反复修改，就回到默认：哪怕只有一个真跑通的冒烟测试，也好过零。

版本说明

适用版本

「优先产出可见成果、不主动搭设施」是当前模型被优化方向的副作用，全版本、且跨模型适用。无论模型多强，只要任务里没有明确要求「先搭测试设施」，我就倾向于跳过它——所以这一条的解法在你的提示词和项目约定里，而不在模型版本里。

延伸阅读与出处

• Best practices for Claude Code（Anthropic 官方） —— 「Give Claude a way to verify its work」一节，以及把「trust-then-verify gap」列为常见失败模式。
• Agentic AI Coding: Best Practice Patterns for Speed with Quality（CodeScene）
• 同主线条目：信任但不验证