Lean Testing 是一个智能体编程场景下的测试决策技能，核心目标是防止不必要的测试生成，让测试投入与具体风险相匹配。
用途：在实现功能、修复缺陷或判断是否应添加测试时，帮助确定“最小充分”的检查手段。其立场是：零新增测试是合法选择，而且往往更可取；生成测试很便宜，但执行、诊断、评审和维护成本并不会因此消失；测试产出量并不等于工作进展。
主要能力：
- 负责测试选择与永久测试的准入判断，角色分工、委派、评审时机、重跑与验收仍交给现有工作流。
- 在生成测试前先选择证据：识别变更行为与有意义的失败；现有覆盖足够时就原样复用，不强制产出新断言或新文件。
- 面对行为不确定性时，优先检查可运行产品的真实入口与相关后端，观察结果（包括相关持久化）。使用经授权的环境与数据；live 指实际运行，不一定是生产环境。命令、浏览器交互和诊断探针可以是临时的，有价值的观察记录保留在既有任务记录中。
- 按受保护行为而非文件名或固定的单元/集成/E2E 金字塔来评估。例如用 node:test 驱动真实 CLI 进程可算系统级检查；在关键边界上打桩的浏览器测试可能提供很少的集成证据；聚焦单元测试可能最便宜地验证舍入或受控故障；真实旅程可能暴露 mock 遗漏的接线故障。
- 为永久测试提供理由：新增前需指出一个现有检查未充分暴露的有意义失败，并说明为何重复自动化检测值得执行与维护成本；在既有说明或变更描述中写一句话即可，无需准入表单、评分或额外评审。
使用方式：按情境决策，例如一次性保存/重载不确定性，直接执行真实保存/重载并检查存储结果，保留观察而不自动生成探针；罕见竞态、重试或部分写入故障不便实测时，使用受控的聚焦不变量测试；产品契约有意变更时，按契约更新受影响预期并保留无关断言。失败检查需先厘清预期是否符合约定契约，以及故障属于产品、测试还是环境；无法解释的红色状态不得搁置。不得为臆造的预期而修改正确的产品行为，也不得仅为通过而削弱防护或契约值。
适用场景：智能体实现功能、修复缺陷、决定加不加测试；小型高风险变更可能只需少量聚焦用例，小型变更可能只需现有检查加一次临时实测，规模本身不决定方案。
限制：不强制变异测试；覆盖率、测试数量和测试与产品代码行数比例只是信号，不是生成目标或删除配额；应随工具与模型变化、依据观察到的任务结果重新评估机制，而非假设模型准确率；有用的既有测试无需仪式性重新证明；大规模删除或合并测试套件需另行授权。