任务只用一句话丢给 Cue 时，跑偏往往出现在前两三步：它自己补了范围、自己选了要动哪些文件、自己决定了产出形式，而这三样恰好是你没写的。可以立刻做的一件事是：把原来那句话原样再跑一次留档，然后用「目标 / 步骤 / 验收」三段改写同一任务跑第二次，只比对能观察到的差异——实际走了几步、有没有碰到范围外的文件、产出能不能直接用、你中途补了几次说明。

适用场景：任务只有一句话、涉及多个文件或多种产出形式、需要限定处理范围。操作动作：先跑一次旧描述留作基线，再按目标、步骤、验收三段改写后重跑。验证方式：对比两次运行的步骤数、是否触碰范围外内容、产出能否直接使用、需要补充说明的次数。风险边界：改写只减少歧义，不保证一次跑完；涉及删除、覆盖、写外部系统的步骤仍需人工确认后再放行。

留一份一句话描述的运行结果

先不要急着改描述。把那句话原样保存下来（对话开头、临时文件或笔记都行），跑一次，只记录可观察的事实：它读过哪些文件、执行了哪些命令、生成或修改了什么、有没有停下来问你。这份记录是后面比对的基线，没有它，改写之后你只会觉得「好像顺一点」，说不清是哪一处起了作用。

建议用下面这种偏流水账的格式记，不求好看，只求能复现。

任务原句：把 config 目录下的配置文件整理一下
实际步骤：
  1. 列出 config 目录内容
  2. 打开了 3 个 yaml，其中 1 个不在 config 下
  3. 重写了键的顺序，删掉了两处注释
  4. 直接覆盖了原文件
产出：被覆盖的 3 个 yaml，没有说明
偏差点：动了范围外的文件；删注释不在预期内；覆盖前没有确认

补上范围和交付形式

最常见的一类跑偏是「做了不在范围内的事」。一句话描述里没有边界，Cue 通常会按最省事的路径扩到相邻文件或整个目录。改写时把四件事写进去：处理对象（哪个目录、哪几个文件、哪几个接口）、时间范围（例如某个版本之后的提交、最近一段日志）、允许动到的部分（只读、可改、可新增、可删除）、交付形式（diff、说明文档、直接改文件、只给结论）。

同一句任务的两种写法可以参考下表，重点看右列多出来的约束。

禁止动作值得单独列一行，因为「不要做 X」通常比「做 Y」更能拦住跑偏。范围之外最容易踩的三项是：删除或覆盖已有文件、改公共接口或配置键名、调用外部服务。

把任务拆成带验收的步骤

让每一步都能被检查，而不是一口气跑到底。可复用的改写模板如下，步骤条数按任务复杂度定，通常三步到五步就够。

目标：一句话说清最终要得到什么
步骤：
  1. …… ；做完的标志：……
  2. …… ；做完的标志：……
  3. …… ；做完的标志：……
验收：整体交付前检查哪几项
不确定时：见「不确定时」那一句

同一任务的两种写法对比，差别在每步能不能被核对。

写法 A（一句话）：
帮我优化一下项目里的日志输出。

写法 B（带验收）：
目标：把 src/ 下模块里的 print 换成统一 logger，原有日志文本内容保持不变。
步骤：
  1. 列出 src/ 下所有使用 print 的文件和行号；
     做完的标志：给出一份文件清单，含行号。
  2. 按清单逐个替换；
     做完的标志：每个文件产出 diff，且能对应到清单里的某一行，无遗漏。
  3. 跑一次现有的检查或启动流程；
     做完的标志：贴出运行结果，失败项单独列出。
验收：diff 覆盖清单全部行；原有日志文本未被改写；未触碰 src/ 之外的文件。

「做完的标志」最好是一个可观察的产物：清单、diff、命令输出、文件列表。只写「完成第一步」这种表述，等于没写。

补一句不确定时怎么办

中途猜测是偏差的主要来源。要写明遇到信息不足时是先问、先跳过还是先按假设继续并标注，三选一，别让它临场决定。可选写法示例：

• 先问：「遇到我没说明的情况（例如同名配置、测试缺失），先停下来问我，不要自行选替代方案。」
• 先跳过：「信息不全的条目记进『待确认』清单后跳过，继续处理其余部分，最后一起给我。」
• 按假设继续并标注：「允许按你的假设往下做，但每条假设必须列在回复末尾的『假设』里，并标出受影响的位置。」

三种策略对应不同代价：先问会多一轮往返，先跳过可能留下半成品，按假设继续则要承担返工。对涉及删除和覆盖的任务，建议统一用先问。

前后两次结果对照

改写是否有效，用两次运行的可观察差异来判断，不要凭印象。建议按下面四个维度逐条记录。

如果四个维度里只有一项变化，也说明改写起了作用；如果两次都跑偏，缺项通常落在「做完的标志」和「允许动到的部分」这两处，优先补它们。一次只加一类信息再跑，否则分不清是哪一项在起作用。