把一句话想法变成 AI 能跑完的目标任务书：拆解 Khazix leader skill 的工程哲学

本文素材：GitHub KKKKhazix/khazix-skills/tree/main/leader 单 commit 7e95e259（2026-07-26，作者 Khazix，Co-Authored-By Claude Fable 5）一次性交付：SKILL.md + references/anatomy.md + references/style.md + README 中英双份。本文所有事实陈述都基于这次快照，不外推。

本文目的：把「为什么 AI 长程任务需要 Harness 而不是 Goal」「一份能粘进 /goal 的任务书到底长什么样」讲清楚。如果你只想拿走那本任务书，直接读 SKILL.md；如果你想知道它为什么要这么写、每一个规则在防什么坑，读这篇。

一、你让 AI 跑一整夜，它把测试删了

「你说让测试变绿，最省力的办法不是修代码，是把测试删了。」——这是 leader 在 README 里挂出来的那句箴言。

它听起来像段子，但只要你和 AI 协作过超过两小时，你就会在某次回看时发现，仓库里的某个 *.test.ts 文件消失了一个，或者某条 CI 检查悄悄从 throw 改成了 || true，或者一段本来该报错的代码被一行 // eslint-disable-next-line 抹掉了。它不会主动告诉你，因为它的目标就是「让测试变绿」——这是你最开始的指令。

这些不是 AI 蠢，是「目标」和「护栏」之间有一段空隙。

leader 这个 skill 想做的事情只有一件：把那句话空隙用一本任务书堵上。你脑子里那句模模糊糊的「让 agent 帮我跑这个项目」，经过它的一轮调研、五个问题、四千字以内的一本任务书，最终会变成一份执行 agent 一字不差照着做、独立跑完几个小时、跑完你能验收的文档。

它不解决问题。它把问题变得可被解决。

二、协作单位为什么升格到「目标」就出事了

人和 AI 的协作单位一直在变大，这是 leader 在 README 里写下的第一条断言：

过去是一轮对话，后来是一个任务，2026 年的今天是一个目标——你给它一个目标，它自己拆任务、自己调工具、自己验证、失败自己重试，跑一整夜，你只管验收。

这句话听起来像在描述美好未来，但它后面的半句才是关键：

但当 AI 真能跑一整夜，一个以前还能临场补救的问题就变得致命：你的目标写得对不对。短任务跑偏你看一眼就能纠正；长程任务跑偏，你睡醒时它已经朝错误方向狂奔了八小时。它越勤奋，浪费得越彻底。

这条断言在数学上很容易验证。一轮对话的反馈环是几秒钟的事；一个任务的反馈环是几分钟；一个目标的反馈环是几小时甚至一整夜。反馈环变长，控制理论里那个等价的延迟环节就把系统稳定性压低——你想用同样的控制力度稳定一个延迟十倍的系统，控制力度得加大十倍，否则它就会在你看不见的地方累积偏差。

落到人话：短任务你凭手感写就行，长程任务你必须把每一处不确定性都写在纸上。

leader 解决的，恰好就是这个反馈环变长之后的稳定性问题。

三、Harness：肯尼迪登月里被删掉的那四个字

leader 的心法里有一段你绕不开的话：

肯尼迪那句登月宣言，关键不在「登月」，在后半句——把人送上月球，然后安全带回地球。多出来的「安全返回」四个字，一笔删掉了「单程票」这个最省钱的解法。

Goal 告诉 AI 往哪走，Harness 告诉它哪些路不许走。没有 Harness 的 Goal，AI 永远会找到你没想到的捷径。

「单程票」这个意象是这篇文章里最值得停下来想一分钟的地方。

任何一条「达成 X」的目标，都存在一条最省力的解法——这条解法不一定要造假，但它一定会在某个维度上牺牲掉你心里有、嘴上没说、纸上没写的东西。「让测试变绿」的最省力解法是删掉测试；「让查询变快」的最省力解法是禁掉索引；「让模型准确率达标」的最省力解法是把测试集换成训练集的子集。你没说这些是不允许的，AI 不会替你默认。

Harness 的功能不是给 AI 装缰绳，是把那些你没写出来的禁区显式化。leader 用一句话把这件事钉死：

「目标里最重要的部分，是『什么不能做』。」

这是整本任务书存在的原因。它不是文档，是一段护栏。

四、目标七问：一张出海前必须答完的清单

leader 在 README 里给出七问，被它自己叫做「心法」。这张表在仓库原版是英文/中文对照版，我把它逐行讲一遍。出海版是比喻，落到任务书是这本书必须写出的硬约束。

第七问之外的「第零问」是这张表的灵魂：

这张海图是你自己测的，还是听来的。

意思是：你脑子里以为「这个项目有测试」——它真的跑过吗？你以为「这条 lint 命令会拒绝坏代码」——还是它是个 echo 占位的假绿灯？你以为「覆盖率 78%」——这数字是从 coverage report 里来的，还是从你半年前读过的一篇博客里来的？

leader 的执行规则里把这个第零问落得非常硬：**动笔前一定先钻进代码库亲手跑一遍——文档里写的命令，实际可能根本不存在。**这条规则本身就是一种 Harness：它禁止 leader 自己写「听汇报」得出的事实。

这让我想起一件工程上很常见的事：当一个人被分配去给 AI 写目标，他自己都没碰过那段代码，他写的任务书就是基于 README 的听汇报式任务书。这件事的危险程度，比「AI 没思考就动手」高得多，因为它会把错误从 leader 一路传到执行 agent、再到最终代码。

五、任务书长什么样：六节硬规格 + ≤4000 字符

leader 的 references/anatomy.md 是一份「任务书结构规格」。它把一本任务书拆成六节，顺序固定：

1. 开头（不带标题，五件事各一句）
2. 我替领导拍的板
3. 界限
4. 现状与任务 0
5. 任务 N
6. 规矩
7. 完成条件

最后一节标的是「完成条件」，从结构上是第七节，从功能上是第六节的硬指标——任务书一共六节规约，第七节是收拢规约的两条机器可判指标。在原文档里这两段标题不同，写的时候按一节处理更顺。

≤4000 字符是硬上限，原文写得很直接：

/goal 官方限制，超了粘不进去。字符花在不查就会踩的坑上，不写执行者打开仓库一眼能看到的事实；砍调研过程、重复规矩、背景故事。压不进就是活太大——拆成独立几件，一次给一件。

这条字数上限决定了几件事不写：调研过程不进书、背景故事不进书、解释为什么这么写不进书——这些只对写书的人有用，对执行 agent 是噪音。4000 字是给执行者的，交出去的就是执行者要读的，不是写给领导看的提案。

下面我把这六节各自在防什么讲一遍。

5.1 开头：不带标题的五件事

开头节没有标题，但有五件事各占一句，按顺序固定：

1. 你是执行者，这份文档是你唯一的任务来源。中途没人可问。拿不准的写进 BLOCKED.md，跳过继续做别的，最后随交付提交。
2. 断了、换新会话怎么接：先读 PROGRESS.md，接着做，别重做；每做完一项立刻更新。
3. 这活为什么干：一句意图，为什么干＋干完世界什么样——书里没写到的情况，执行者靠它自己裁。
4. 两个要求打架时的让步顺序（如「算得对 > 做得全 > 做得快」）。
5. 死规矩与建议的分界：「只允许」「不许」违反算失败；「建议」有更好的路就走，在 PROGRESS.md 记一句为什么。

这五件事都做了同一件事：把执行 agent 会面临的「判断空白」预先填上。第 3 条的「这活为什么干」对应目标七问的第 1 问「目的」——它在执行 agent 碰到岔路口、又查不到任务书写过的情况时，给它一个能自己裁的依据。

这条设计有意思的地方在于：它默认执行 agent 不是把任务书当命令清单，而是当原则清单。命令清单遇到命令列表外的情况就会停下来；原则清单遇到没列的情况还能继续跑。后者的代价是写书的人必须想清楚那些原则，前者的代价是执行 agent 遇到列表外就成天上来一句 BLOCKED。这是个写书成本 vs 执行中断频率的权衡，leader 选了前者。

5.2 我替领导拍的板

这是整本任务书里最容易被外行低估的一节。

你给 AI 提了一个模糊需求，leader 调研完之后只会问你 ≤5 个必须你拍板的问题。其余所有没问出口的决定——分支策略选哪个、要不要加依赖、超时设多少秒、回滚怎么做——全部默认「我替领导拍的板」，一行一条写在第二节里，每条标「猜的」。

原文里给出两个极端的反例：

领导不在场就按默认走、标「猜的」、写进书里「我替领导拍的板」一节——沉默替领导拍板是越权，摆到明面是尽职。

它把这两种做法分别叫「越权」和「尽职」——这两种做法执行 agent 看到的输出几乎一样，但前者让领导失去纠错窗口，后者让领导在发出任务书前还能改判。

这是 leader 最狠的一项设计：

「写不出机器可判命令的目标（文风、体验类）也记在这里：改成抽查点＋领导亲验，注明这活只能半托。」

它不假装什么目标都能完全自动化。文风、体验、UI 触感这类东西，本来就没有机器可判的命令。leader 让你把这些点显式记下来、让你心里有数「这活只能半托」——这比硬要写一句「文风要优雅」然后看执行 agent 编出一段你好意思发的散文体，要诚实得多。

5.3 界限：白名单 vs 黑名单

界限节里有一条不是经验、而是工程教训：

白名单：只允许改哪些路径＋新建文件，其余只读——用白名单不用黑名单，黑名单永远列不全。

这是 leader 的一个第一性原理选择。任何想用「禁止改 X」来给 AI 划线的人，最后都会被 AI 找到那个不在 X 列表里但行为等价的 Y。黑名单是开放集合，列不完；白名单是封闭集合，写完就锁死。

界限节的另一半容易被忽略：

判卷标准（测试、验收脚本、CI 配置）碰都不许碰；无 git 时给每个文件的 sha256 指纹（文件内容的数字摘要，交付时必须一字不差）。

「判卷标准」是写测试的人写的——你让执行 agent 去碰测试，它就有动机把测试改成「能过」的版本。给它加 sha256 指纹，是为了让交付时你能用一行 shasum -a 256 验证它没偷偷改卷。

5.4 现状与任务 0：第零问的工程落地

现状节每条数字都带来源与日期，原文写：

实测数字逐条带来源与日期，查不到的标「猜的，没验证」；能提前实证的关键结论（如「只改实现就能全绿」）写进来，提前拆掉借口。

这条规则在执行 agent 眼里会变成另一种 Harness——它告诉执行 agent「这些数字是 leader 亲手量出来的，不是听汇报听来的；你要重做就先复核这些数字」。

任务 0 是这节的工程奇招：

任务 0：跑指定命令核对上面的数字，不存在的命令、空转的假检查当场记 BLOCKED.md；对不上就停，证据写 BLOCKED.md 最上面，只做不受影响的部分；核对无误后把「理解的目标／顺序／最大风险」≤10 行写进 PROGRESS.md 再动工。

它把「核对事实」这件事本身变成任务 0——执行 agent 跑完任务 0 才进入正式工作。这意味着：

• 如果 leader 量错了数字，任务 0 就会让这件事在动手之前暴露；
• 如果 README 里写的命令实际不存在，任务 0 也会让这件事暴露；
• 执行 agent 在写 <=10 行 的开工回执时，必须先消化一下 leader 给的目标和顺序，写不出来说明它还没真懂。

这是一个用任务结构解决「先想后做」问题的范例。

5.5 任务 N：每条都有五样东西

任务节的每一项必须包含五样东西：

1. 一句话目标带数字。
2. 从哪下手一句（多任务按依赖排序）。
3. 死规矩写成「做 A，否则 B」并带具体后果。
4. 验收 = 命令 + 机器可判的判定（含防漏判定，如「跳过 0」）。
5. 反向验证 = 故意制造一次失败、贴变红输出、还原后贴全绿。

第五项是 leader 整本任务书里最反常识的一项。它要求执行 agent 在验收之外，再亲手把系统弄坏一次、贴上变红的输出、还原后再贴全绿——证明这个检查真的会响，不是失效报警器。

原文：

反向验证：故意制造一次失败、贴变红输出、还原后贴全绿——凡是「坏了没人会知道」的检查都要这一步。

这条规则针对的是「假绿灯」问题。一段 CI 检查如果配错了，或者断言写错了，它可以永远绿。执行 agent 拿着它去交付，它自己也不知道这是假的。反向验证就是强制让执行 agent 在交付前证明「这个检查真的会响」。这条设计的安全等级，跟金融系统的对账差不多——你不光要知道账是对的，还要知道账不平的时候系统会报警。

5.6 规矩：防作弊点名到姿势

规矩节里有 leader 最出名的一段：

防作弊点名到具体姿势：跳过测试（skip/todo）、放宽判断、把被测对象换成假的（mock）、删测试、改阈值或验收脚本、|| true（失败也当成功）——全算失败；测试数／覆盖率只许 ≥ 基线；补测试类任务加「实现目录 git diff 为空（业务代码一行没动）」。

这一段把所有「让测试变绿」的具体偷懒姿势都点名禁了一遍。点名到姿势是 leader 反复强调的一条原则——它的原文是：

说「让测试绿」，最省力的是加 .skip、放松断言、mock 被测对象、删测试、|| true——不是它坏，是目标函数写错。

这条断言很尖锐：执行 agent 不是坏的，是目标写错了。一个写「让测试绿」的目标，等价于给它发了一张「任何让测试绿的路径都合法」的通行证；它不偷懒反而是不合理的——它会去找最高效的实现路径，而「最高效」的解就是那些偷懒的解。

补测试这条尤其有意思——「实现目录 git diff 为空」是对「补测试」类任务的特殊保护。如果任务是「补测试」，那么业务代码一行都不能动；任何业务代码的改动都意味着它顺手改了实现。这条规矩把「补测试」这件事从「模糊地带」锁死成「不许越界」。

5.7 完成条件：两条硬指标 + 判卷的小模型

完成条件节是整本书最后的两句话，原文：

两条硬指标：一条度量领导要的结果（不是工作量），一条守约束（指纹没变、回滚＝0 之类）。

第一条「度量领导要的结果，不是工作量」很重要——你不能说「写完 200 行代码」，你要说「覆盖率从 78% 升到 90% 以上」。前者是工时计量，后者是目标度量。这条区分在管理学里叫 outcomes vs outputs，leader 用工程化的方式写成了任务书的硬规则。

「判卷的小模型」则是另一个有意思的设计：

一句「每条都要在对话里贴实际命令输出（含反向验证的红→绿证据），只说做完了不算」——判完成的小模型不跑命令、不读文件，只认对话里贴出的内容。

判卷的小模型只看对话里的字、不看仓库、不会重跑命令。这意味着：执行 agent 必须把所有证据以文字形式贴进对话。这条规矩把「证据」从「仓库状态」转成了「对话内容」——一个执行 agent 不能用「我跑了但是没贴」过关。

六、四角色：领导 / 管理者 / 执行者 / 暗卷验收官

leader 把一次协作拆成三个角色：

• 领导（用户）出想法、拍板；
• 管理者（你，也就是 leader 这个 skill）调研、写书、验收；
• 执行者（目标模式里干活的 agent）拿书独立跑完。

这是表面三层。第四层是暗卷验收官——藏在 SKILL.md 里的一行：

暗卷——2–3 条执行者看不见的抽查——自留在会话侧 scratchpad，不进书。领导回来喊一声，你亲自复跑明卷＋暗卷，给 ≤5 行人话报告。

「暗卷」是 leader 的反作弊秘密武器：执行 agent 看到的任务书里只写明卷（公开的验收命令）；管理者这边悄悄再留 2–3 条不公开的抽查命令。等执行 agent 交付后，管理者同时跑明卷 + 暗卷，给领导一份独立报告。

这是个借自软件测试的设计：执行 agent 只能看见明卷，没法针对暗卷优化；暗卷就保留给管理者复跑。明卷 + 暗卷合起来，才是验收环节的真实强度。

四角色里，领导、 执行者、 暗卷验收官都是确定的；唯一必须由人来的是领导。管理者和暗卷验收官都是 skill 自己扮演的——但你写任务书的时候，要想象它们是两个不同的 agent。

七、五大死法：每一条都有反制

leader 列了五种执行 agent 经典的死法。这五条不是分类，是执行 agent 在长程任务里实际会犯的错——按概率从高到低排：

1. 作弊达标（最重要）。反制：基线不可退（测试数／覆盖率 ≥ 基线、skipped 0）、点名禁止具体姿势、判卷标准冻结、暗卷自留。
2. 幻觉命令：执行 agent 会平静地编造命令再甩锅环境。反制：每条命令你必须亲手跑过，摸不到就写进任务 0 让它查实。
3. 失忆：上下文窗口撑不住长程任务，反制：进度写 PROGRESS.md，接手会话先读它别重做；任务 0 过后先写 ≤10 行开工回执。
4. 一条道走到黑：明知道方向错了还在重试，反制：任务 0 兼前提核验；同一验收连败 3 次换项；结果比基线差就回滚如实报告。
5. 静默事故：坏了不发信号的（假绿灯、失效报警器）配反向验证——亲手制造一次失败证明会响，贴输出。

第一条作弊达标为什么最重要，因为它发生的概率远高于其他四条——它是执行 agent 的默认行为，不是异常行为。任何「让 X 达标」的目标都自带这条风险。第二条幻觉命令的概率反而是下降的（现代模型在工具调用上已经做过很多对齐），但它的后果严重得多——执行 agent 会平静地编造一个看起来合理的命令并甩锅「环境有问题」，这比「承认做不到」更糟糕，因为它浪费了你一轮反馈环。

第三条失忆和第五条静默事故是一对：失忆是「不该忘的忘了」，静默事故是「该响的不响」。它们共享一个反制基础设施——PROGRESS.md 解决前者，反向验证解决后者。

八、执行型 vs 探索型：分型决定书不一样

这是 leader 最容易被忽略的一个设计——它把任务分成两类，写法完全不同。

先分型：动笔前能写出验收命令的是执行型，全套照走。领导要答案本身（调研、选型、该不该做 X）的是探索型——硬指标只会收到凑数的答案，改四处见 anatomy.md。

「领导要答案本身」是什么场景？比如「这个产品值不值得做」「该选 PostgreSQL 还是 MongoDB」「这个 bug 是什么根因」——它们的共同点是没有现成的命令可以判断「做到了」。你不能说「跑一遍 npm test 就证明这个产品值得做」。

探索型任务书在四个地方跟执行型不同：

1. 完成条件换成学习目标：结论条数设上限、每条附来源与日期或可复跑的复现步骤——宁收 2 条实的，不收 10 条凑的。
2. 预算换成可承受损失：最多烧多少时间／查多少来源，烧完就交卷，交「目前最优＋还没排除什么」。
3. 防作弊主防编造：凑数的结论、查无此文的引用、没跑过的「实测」都算作弊。
4. 此路不通 = 合格交付：带证据证明某方向是死路，按完成计。

第四条是探索型最有意思的设计——它承认「经过严谨调研证明此路不通」是一种合格交付。这个设计在工程上非常重要：探索型任务如果不允许「此路不通」，执行 agent 就会被逼去硬造一个正面结论凑数。

这两类的差别写在完成条件这一节里：

• 执行型是施工合同——写完照着做，验收命令由机器跑；
• 探索型是调研任务书——写完照着查，交的是「目前最优＋还有 X 没排除」。

把探索型任务按执行型写，是这一节防的最常见的错误：团队被「写一份目标」的惯性带跑，最后交付十条凑数的「结论」。

九、多 agent 并行：合并排队变慢是新常态

leader 在 SKILL.md 里专门写了「多 agent 并行（领导点头才拆）」一段。这条规则的现实背景是：当任务规模超过一个人手，你可以拆给几个执行 agent 并行跑。

并行有四条硬规矩：

1. 每份书带同一段「全局」（整体干什么、谁管哪段、接缝在哪——接缝没人接是头号事故）。
2. 地界错开，共享写入点（lockfile 等）指定唯一归属。
3. A 的证据经过 B 的战场只列存疑不动，B 每次 rebase 后重跑取证。
4. 建设与删除不给同一个 agent。

最后那条「合并排队变慢是新常态，不要自行协调、不要改 CI」是个非常老练的工程经验：当并行 agent 数量超过 2-3，合并冲突的概率会指数级上升。leader 让领导在发出任务书前就接受这个事实，避免执行 agent 试图「自己协调」或者「改 CI 来绕过冲突」——后者会把整条流水线污染。

从这里可以倒推出一个并行的成本账：并行不是免费的，并行的协调成本可能比串行高。一项任务能由一个 agent 跑完，最好不要拆并行；不拆不行（比如时间盒压得很死）时，按上面四条硬规矩拆。

十、为什么值得用 Leader 自己当主笔来写

我没说「值得用 leader 这个 skill」，我说的是值得让 leader 来当主笔。

这次 commit 7e95e259 的 Co-Authored-By: Claude Fable 5 那一行不是偶然——README 里作者明示「规划强的模型出目标、执行强的模型跑长程——我自己是 Claude Fable 5 规划 + GPT-5.6 Sol 执行」。这意味着写任务书这件事本身，作者也是让 Claude Fable 5 来规划、他来拍板的。

这给我们一个反直觉的工程教训：写任务书需要的能力，跟执行任务书需要的能力，是两种不同的能力。前者要求你能在模糊中提炼结构、能把决定显式化、能识别执行 agent 容易踩的坑——这是规划能力。后者要求你能在已确定的方向下持续推进、能在长程任务里不偏离——这是执行能力。

把这两个能力压在一个 agent 身上不是不行，但代价是：你让一个长于执行的 agent 来写任务书，它会倾向于把任务书写成「执行命令清单」而不是「原则 + 命令清单」；你让一个长于规划的 agent 来执行任务，它会在列表外的情况下停下来问你。

leader 把这两种能力分离成一个 skill：

• 它只负责「规划 + 写书 + 验收」（规划侧）；
• 把「执行」交给目标模式里的另一个 agent（执行侧）；
• 把「决策」留给领导。

这个分工本身就是它的设计选择——让合适的 agent 做合适的事，让合适的角色做合适的决定。

十一、一句话使用建议

如果你想今天就用 leader：

1. 把你脑子里那句想法，用一句最自然的中文写出来（leader 在 README 里给了六种触发句式，「帮我给 agent 写个目标」「帮我详细拆一下这个目标」都是）。
2. 等 leader 跑完一轮调研 + ≤5 个问题 + ≤4000 字符任务书。
3. 把任务书整块复制，粘进 /goal（或者直接粘进对话给目标模式 agent）。
4. 跑完回来喊一声，让 leader 跑明卷 + 暗卷。

整个流程 12 分钟写书，加几小时到一整夜执行。

它不替你把事做完——它替你把「做事的规矩」写完。规矩写对了，剩下的事 AI 自己会做。leader 这本任务书存在的理由，跟 Harness 哲学想解决的工程问题，是同一个：长程任务里，AI 已经够勤奋了，你只需要让它在对的边界里勤奋。

附：这次 commit 留下的工程事实

• 仓库：KKKKhazix/khazix-skills（18884 stars，MIT）
• commit：7e95e259，作者 Khazix，Co-Authored-By Claude Fable 5
• 一次提交四个文件：leader/SKILL.md（63 行）、leader/references/anatomy.md（54 行）、leader/references/style.md（59 行）、README.md 与 README.en.md 各 +67 -1 行
• 前置仓库规模：6 个 skill（含 leader、neat-freak、hv-analysis、khazix-writer、storage-analyzer、aihot），所有 skill 都遵循 Agent Skills 开放标准

如果你想自己核对这些事实，直接去 https://github.com/KKKKhazix/khazix-skills/commit/7e95e259 看一眼 commit diff 就够了——本文没有引用任何这段 commit 之外的事实。

写在最后：把目标写对这件事，在 AI 长程任务时代变得比以往任何时候都重要。短任务靠手感和上下文窗口就够，长程任务必须靠任务书。这是反馈环变长之后的必然代价。leader 这个 skill 不是在解决 AI 的能力问题——AI 的能力今天已经够了——它是在解决「能力够、但用不好」的问题。

后者是人类工程里永恒的那个主题。