目标拆解巧匠

要解决的问题

把一个想法丢给 Agent 让它自己跑完，通常死于两种情况：需求只有一句「让测试绿」，Agent 找到最省力的姿势作弊达标；或者需求写成几十页散文，粘进 /goal 时直接撞上官方 4000 字符上限。目标拆解巧匠补的是中间没人做的那段活——把「想法」变成一份「任务书」，让执行 Agent 一字不差地照做、中途无需回头问人。

它明确不做执行：管理者写书、领导拍板、执行 Agent 干活，三个角色不混。

核心能力与流程

调研：自己能查的一律不问。有仓库就实测——命令真的存在吗、README 的绿灯是不是 echo 占位、文档和实际差多少；摸不到环境就把自测写成任务 0，交执行者查实。

提问：一轮不超过 5 个，只问查不到且会改变任务书的问题，每个给 2–4 个选项加推荐。领导不在场就按默认走，但写进「我替领导拍的板」一节——沉默拍板是越权，摆明面是尽职。

写书：任务书是执行 Agent 的唯一真理，全文不许出现「来找我」。关键规则：

• ≤4000 字符硬上限，字符花在不查就会踩的坑上，不写打开仓库一眼能看到的事实
• 先分型：能写出验收命令的是执行型；领导要答案本身（调研、选型）的是探索型，验收方式完全不同
• 富规格优先：仓库里已有的测试套件、schema、验收脚本直接写路径当规格，不用散文复述
• 法与情报分家：「不许」是法，违反即不合格；「建议」是情报，执行者有更好的路可以走

防作弊是头等大事：书里说「让测试绿」，最省力的姿势是 .skip、放松断言、mock 被测对象、|| true——不是执行者坏，是目标函数写错。对策是基线不可退（覆盖率 ≥ 基线、skipped 为 0）、点名禁止具体姿势、判卷标准冻结，外加管理者自留的「暗卷」抽查，执行者看不见。

还有五种死法要防：幻觉命令（书里每条命令必须亲手跑过）、失忆（进度写 PROGRESS.md、开工先写回执）、一条道走到黑（同一验收连败 3 次换项）、静默事故（坏不发信号的配反向验证，亲手制造一次失败证明会响）。

适用边界

• 这是目标拆解技能，不是执行技能，不代替执行者开工
• 改动技能自身的描述、触发词或工作流，先诊断列计划，等用户明确确认
• 多 Agent 并行要领导点头才拆；每份书带同一段「全局」（谁管哪段、接缝在哪），共享写入点指定唯一归属
• 压不进 4000 字符的活就是太大，拆成独立几件，一次给一件