LifeVal 分数低于预期时，最容易犯的错是立刻在「题太难」和「评分口径不对」之间二选一。更有效的做法是先把两件事分开：任务本身是不是多步、需要读状态的，以及自己动手时优化的到底是不是判定会看的那部分。从任务描述里摘出验收条件，再对照每一步的执行日志，通常能把「没读懂约束」「漏步骤」「终态不完整」「操作顺序错」这几类原因区分开。评分口径是否真的有问题，建议放到最后再怀疑。
先按步骤数量给任务打标，再从描述中摘出验收条件，确认判定看最终状态还是过程记录；然后把低分任务按没读懂约束、漏步骤、终态不完整、操作顺序错分组，每次只改一处策略重跑，用并排对比表决定改任务拆解还是改执行顺序。前提是能拿到任务描述和每步日志；如果环境不记录中间过程，只能以终态为据反推，不要直接断定评分有问题。
先分清任务是单步还是多步
单步任务的失败基本是理解问题：模型没弄清对象、位置或数值。多步任务的失败更多来自执行链条：中间状态没读、某一步被跳过、顺序颠倒。两者要改的地方完全不同，所以第一步是给任务打标，而不是先改提示词。
打标方法很简单：数任务描述里独立的状态变更动作，以及需要先读取的当前状态。动作在一到两个、不需要中间判断的记为单步；动作超过三个或需要读一次再决定的记为多步。
| 类型 | 典型任务描述片段 | 失败更像 | 先查什么 |
|---|---|---|---|
| 单步 | 「把冷藏层的牛奶放到最上层搁架」「把周五的会议改到周四上午」 | 理解问题：对象、位置、时间点认错 | 任务描述中的实体名是否与环境中一致 |
| 多步无分支 | 「准备两人份早餐，用完后把餐具放回原位」 | 执行链条：漏掉收尾、顺序错 | 每步是否都落到日志里，最后一步是否执行 |
| 多步带条件 | 「先确认快递是否已签收，若已签收就登记到收纳清单，否则重新预约投递」 | 两种都可能：条件判断错，或分支走完没落到终态 | 读取的那一步取到的值是什么，走了哪个分支 |
打标之后回看低分任务集中在哪里。如果低分几乎都落在带条件的那一栏，问题大概率在「读到状态后没按条件走」，而不是任务整体难度。
确认判定看的是最终状态还是过程记录
很多分数差异来自力气花错地方：自己一直在优化中间动作的规范程度，而验收条件只检查任务结束后的环境状态。要做的是从任务描述原文里把验收条件逐条摘出来，写在纸上或写进对照文件。
摘取的做法是找描述里表示结果的句子，通常是「完成后……应……」这类结构，把它们拆成可检查的条目：检查哪个对象、期望什么状态、在哪一层位置。没有出现在这类句子里的动作，一般不作为判定依据。一条任务的条件摘录示例：
任务描述（节选）：办理完成后，桌面上只保留一份已签名的单据，其余草稿放回文件柜第二层。
摘出的验收条件：
1) 桌面最终文件数量与内容（终态）
2) 文件柜第二层的文件归属（终态）
明确不计入的中间动作：
- 是否先打印草稿、打印了几次
- 打印顺序、临时摆放位置摘完之后拿执行日志逐条对照：日志里花时间最多的动作，有多少能对上上面的条件。如果大部分对不上，先改执行策略，而不是怀疑评分。如果验收条件本身与描述有出入，例如描述要求放回第二层而条件写的是第三层，这属于可记录的口径问题，建议保留原文摘录与截图，先在小样本内确认，再决定是否反馈。
把低分任务按失败类型分组
一堆低分放在一起看不出规律，按失败类型分组后就变成几类可处理的原因。建议固定四个分组维度，不要临时增加：
- 没读懂约束：实体名、数量、位置、时间限制理解错，动作本身合理但对象错。
- 漏步骤：中间某一步完全没执行，终态缺一块。
- 终态不完整：动作都做了，但收尾没落到要求的位置或格式。
- 操作顺序错：依赖关系颠倒，例如先归档再修改。
分组后的记录建议一行一个任务，字段保持稳定，便于后面统计：
任务ID | 步骤类型 | 验收条件条数 | 失败类型 | 失败发生在第几步 | 日志中该步的实际动作 | 是否计入终态填这张表时只写能从日志和页面行为里看到的内容，不要写推测。分完组先看分布：如果「终态不完整」占多数，说明执行链条能走通，问题在收尾；如果「没读懂约束」集中出现，先回去统一实体命名，而不是加更多步骤。
对同一任务只改一处策略再跑一次
一次改提示词、改拆解、加自检，跑完分数变了也不知道是哪一处起作用。建议每次只动一处，其余配置保持原样，并且同一任务重跑时记录改动前的基线。
可单变量尝试的改动点，按代价从低到高：
- 在提示中显式列出从任务描述摘出的验收条件，不改任务拆解。
- 在第一次动手前增加一步「读取并记录当前状态」。
- 把多步任务拆成串行子任务，每步结束检查是否落到终态。
- 只调整执行顺序，其余不变。
- 在最后增加一次终态自检，逐条比对验收条件。
重跑记录表把改动点和观察点固定下来：
| 任务ID | 改动点（仅一处） | 保持不变的部分 | 观察点 | 记录 |
|---|---|---|---|---|
| T-01 | 提示中显式列验收条件 | 拆解方式、步骤数、工具调用 | 约束类错误是否仍在 | 写实际发生的动作 |
| T-01 | 首次动手前读状态 | 提示、拆解方式 | 条件分支是否走对 | 写读到的值与分支 |
| T-01 | 末步加终态自检 | 提示、拆解方式 | 终态缺项是否补齐 | 写缺失的具体条目 |
每次重跑都保留基线那一行的日志，不要覆盖。样本小的时候单次结果波动正常，建议同一改动至少重复几次再看方向，不要把一次通过当成结论。
把两次结果并排对比后决定改哪里
对比的目的不是证明改对了，而是判断下一步该动结构还是动顺序。对比表字段建议与前面的分组表对齐：
| 字段 | 基线 | 单改动后 | 看什么 |
|---|---|---|---|
| 失败类型 | 分组结果 | 分组结果 | 类型是否迁移，还是原地不动 |
| 失败所在步骤 | 第几步 | 第几步 | 是否前移或消失 |
| 终态达标条数 | 达标/总条数 | 达标/总条数 | 终态是否真的变了 |
| 中间动作数 | 步数 | 步数 | 是否只是动作变多而终态没变 |
判读规则可以按这几条走：
- 改动后终态达标条数上升、失败步骤前移或消失，说明问题在执行链条，应改任务拆解，把长任务切成带终态检查的子任务。
- 只调整顺序就通过，失败集中在依赖关系上，应改执行顺序而不是加步骤。
- 只有显式列验收条件才通过，说明问题在约束理解，应把条件摘取固化成固定前置步骤。
- 中间动作明显变多但终态达标条数没变，说明判定只看终态，停止打磨过程记录。
- 几处单改动都没有让终态变化，先复核自己摘的验收条件是否与任务描述一致；确认一致后再考虑判定口径，并保留原文与日志作为依据。
做完这一轮，手上应该有一张按失败类型分布的低分任务表、几条单变量重跑的记录，以及一个明确的下一步：改拆解、改顺序，还是先回头核对约束。这个顺序能让「任务难」和「口径不对」不再靠猜。