---
name: task-difficulty-verification
description: 按需求难度分配验证成本——简单改动只做最省的确认、不跑测试；复杂改动必须做回归测试，避免改完反复返工。在本项目（Unity Vision）里做代码、场景或资源改动时适用。
---

# 按难度分配验证成本

目标：简单任务不要为了「保险」浪费 token 去测试；复杂任务必须验证，避免改错没发现、来回返工。

## 先判定难度，并用一句话说明

动手前判定，并用一句话告诉用户这次算简单还是复杂（例如「这算简单任务，改完直接给你」）。判错了用户能当场纠正。

**简单任务**（符合任一）：

- 单文件小改、文案 / 命名 / 日志 / 注释
- 只读查询、看状态、回答问题
- 加一个对象、调一个参数、改个颜色或层级
- 删除无用代码，且无人引用
- 影响面单一，且用户已明确说明期望结果

**复杂任务**（符合任一）：

- 跨文件 / 跨模块，或改动落在公共 API、被多处调用的代码上
- 核心逻辑、算法、状态机、存档或数据格式、构建配置、包依赖、渲染管线、材质 / Shader
- 改动会引入其他代码要使用的新类型、新接口、新字段
- 改错了不容易被发现，或者可能破坏原本能跑的东西
- 用户明确要求验证或回归

拿不准时按复杂处理。

## 简单任务：不做测试

- 直接改完交付，最多做一次最便宜的确认：读一次返回值、看一眼 transform、curl 一次接口。
- 不跑测试套件，不做回归，不为了确认把整个项目重读一遍。
- 不要用「更保险」当理由补验证步骤。

## 复杂任务：必须回归

按下面顺序做，够用即停：

1. 先让编译错误清零：读 `mcpforunity://editor/state` 等到 `compilation.is_compiling == false`，再 `read_console(types=["error"], count="10")`。
2. 跑覆盖本次改动的测试（`run_tests`，EditMode / PlayMode 按改动性质选），只跑相关范围，不重跑全量。
3. 回头验证本次改动会碰到、但原本正常的行为：调用方、相邻功能点、序列化数据、场景里已存在的对象。
4. 结果讲清楚：跑了什么、过没过、哪部分没测以及原因。

## 避免重复修改

- 验证通过就停手，不要顺手再改别的地方。
- 验证不过：定位根因改一次，重跑同一条验证；不要一边猜一边连续打补丁。
- 同一处连续两次修不好，停下来把现象和判断交给用户决定。

用户明确要求跑测试、或明确说不用测时，以用户的要求为准。