深度四问（Depth, not Bigger）

何时用

用：需求已明确、但你想确保「问到点子上了」——尤其是研究/设计/重构类任务， 容易用「加更多功能/更多文件/更多轮」冒充进展的场景。

不用：

• 机械性改动（改个配置、修个 typo、跑测试）
• 已在 tight loop 里的高频任务（成本不划算）
• 需求本身还没想清楚时（那时该先澄清需求，不是加深）

核心动作

在重写任务之前，先答四问（不是直接开始干）：

1. 领域顶尖专业人士会做、但我没要求的事是什么？
2. 他们会从哪些最原始的素材开始，而不是我已经消化处理过的内容？
3. 他们会用哪些具体方法和工具？
4. 除了你或我，还有什么能证明结果是正确的？

然后基于这四问的答案重写任务，把上述内容写进要求里——而不是重写成一个更大的任务。

第 4 问的 lc 特化（最重要的一条）

「什么能证明结果正确」在 lc 里不应落成模型自觉（「我会仔细检查」＝伪状态）， 而应落成控制层可校验的契约：

# 好的 done_when（机器可判）
Goal.set(
    objective="修复 X 缺陷",
    done_when="pytest tests/test_x.py -q 全绿 且 grep -c 'PROBLEM_MARKER' src/ == 0",
)

判据形态优先级（从严到松）：

1. 命令退出码（pytest / 编译 / 脚本 exit=0）——最优
2. 结构化断言（grep 计数、JSON 字段比对、schema 校验）
3. 台账留痕 + 人工复核（无法自动判时，写明复核人 + 复核时点）
4. 「我检查过了」——不接受，这不是证据

反模式（四问的误用）

输出模板

## 原任务
<用户原始表述>

## 四问
1. 专家会多做：<1-3 条，具体动作，不是「更全面」>
2. 原始素材起点：<具体文件/原始数据/一手来源，而非二手摘要>
3. 方法与工具：<具体方法名/工具名>
4. 正确性证据：<命令 / 断言 / 复核人>

## 重写后的任务
<用四问答案替换原表述——深度版的同一任务，不是更大的任务>

## done_when（机器可判）
<命令或断言>

与其他 skill 的关系

• 与 lc-gov-playbook/three-artifacts.md 互补：四问作用于 spec 的内容深度， 三工件作用于 spec→plan→tasks 的流程结构
• 第 4 问与 docs/peer-borrow/20261029_five_way_review.md §八.2 同源纪律： 「『已落地』的表述必须带消费面证据」——都是「没有外部证据就不算完成」