Sno Station Skills 是一套为 Claude Code 和 Codex 打造的开源智能体技能集，其中charter和deliver两个技能解决了一个新手最常踩的坑：智能体说"完成了"，但没有人能证明它真的完成了。本文用一次实战流程讲清楚：如何写一张"工作单（charter）"，再让智能体用deliver把它执行到每一步都有真实运行证据为止。

痛点：为什么"它说做完了"不可信

用过 AI 编程智能体的人都见过这种场面：

• 你说"修好这个 bug"，它回一句"已修复，测试通过"，但实际上一行代码没改；
• 它顺手加了三层你从没要求的抽象、一堆"以防万一"的守卫代码；
• 它把"调用过一次接口"当成"消息已送达"。

Sno Station Skills 的解法很朴素：把"完成"从口头承诺变成书面清单。每张工作单里写明交付物、边界、已定决策，以及一组可以回答"通过/失败"的成功检查项（Success checks）——每一条都必须由一次真实运行来回答。智能体自己说"done"，在这里权重为零。

💡 核心理念来自项目首页的一句话："Done" means proven——完成，等于被证明。

工作单长什么样：先认识 charter 模板

charter技能会生成一个 Markdown 文件，这个文件的路径就是任务的身份证。完整布局定义在模板里：

• 工作单模板：references/template.md
• 提问纪律：references/questions.md

模板由四个核心部分组成：

另外两个区块由系统维护，人手不许碰：## Proof（证明表）只由sno deliver-proof写入；## Report在收尾时由执行者填写。工作单还有一个status字段，取值draft → released → delivered（或superseded），代表它的生命周期。

关于成功检查项，模板给了很好的例子（template.md 第 55-57 行）：

• 文件类："生成的报告能打开，第 3 节的总额等于totals.csv独立重算的结果"；
• 消息类："订单后一分钟内，客户收件箱里能看到确认邮件"；
• 代码类："改动前失败的命令，现在输出预期值且退出码为 0"。

注意一个细节：大任务可以"切片（sliced）"——每张工作单可拆成命名的小片，每片有自己连续编号的检查项，一个执行者只负责一张单或一片，方便多个智能体并行。

第一步：写出可用的 charter 工作单（5 步）

charter技能的写作流程定义在 charter/SKILL.md 第 50-71 行，五步走：

1. 先读现场：读请求、相邻笔记和已有工作，问之前先看文件能不能回答。文件里有的事，绝不问第二遍。
2. 起草：按模板写 Owner decisions、Outcome、Scope 和 Success checks。长度跟任务走——小任务几行就够，大任务就切片。
3. 站在执行者角度重读：每条检查项，一个人不问任何人就能分清"通过"还是"失败"吗？拿一个真实例子走一遍，堵住会让结果误判的漏洞。
4. 独立评审一次：用peer-review（如已安装）或第二个智能体，只查"是否符合负责人意图 + 具体缺陷"，修完即止，不无限循环。
5. 汇报并等批准：用大白话告诉负责人这张单交付什么、还差哪个决策，最后附上那一个问题；负责人批准后把status改为released，再把路径交给执行者。

三条保住工作单质量的硬规则，值得新手记住（SKILL.md 第 24-48 行）：

• ✅不发明决策：缺了一个会改变结果的选择，只问一次、一次一问，且沉默不等于同意；
• ✅检查项必须可观察：写明"观察什么、在哪里、怎么观察"，预期值来自需求或独立数据，而不是抄程序的输出；
• ✅不加没用的关卡：每加一个前置条件或检查步骤，先说清它能发现什么故障、失败了会改变什么——什么都不改变，就别加。

⚠️ 特别提醒：默认情况下智能体单独无权发布工作单，它只能记录你的决策。你不在场时，它会把单留成draft等你发布。

第二步：deliver 如何执行一张 released 工作单

deliver技能接手后，规则只有一条：## Success checks就是完成的定义，别的都不算（deliver/SKILL.md 第 13-16 行）。它的六步流程（第 40-77 行）：

证明环节：sno deliver-proof 命令详解

证明工具deliver-proof是一个小脚本（deliver-proof 第 1-10 行 有完整用法），只有三种子命令：

# 用真实命令证明第 n 条检查项（输出和退出码自动存档） sno deliver-proof run <charter> <n> -- <command> # 检查本身就是"看一眼"时用（如打开生成的文档），附上证据文件 sno deliver-proof see <charter> <n> <evidence-file> "<观察到什么>" # 收尾校验：所有检查项都有 pass 记录才退出 0 sno deliver-proof check <charter>

它的行为对新手有几个友好设计：

• 每次run都会把命令输出和退出码存到工作单旁的<名称>.proof/目录（日志名含 UTC 时间戳），并往## Proof表追加一行：| check | result | how | exit | log | at (UTC) |；
• 失败的检查项就记fail，保持失败直到工作改变并再次通过，不允许手工改成 pass；
• 被划掉的检查项（~~3. 旧检查~~ dropped）视为已弃用，不要求证明；
• check子命令逐条核对（第 89-125 行）：没有记录、最新结果不是 pass、或日志文件丢了，都会报NOT proven。

证明必须发生在"请求者看得见的地方"

这是 references/proof.md 的核心要求，值得逐条对照：

• 📄 文档类：打开生成的文件，读出检查项点名的那句话；
• ✉️ 消息类：在接收方读到它，而不是看发送方的"已发送"；
• 📊 数据类：从独立来源重算一遍再比对；
• 🐛 修 bug 类：先展示失败，再展示修复后的通过——不能跳过复现；
• 🚫 禁止用 mock 的返回值、一次成功的退出码、调用次数或程序自己的叙述来顶替证据。

新手最容易翻车的 3 个地方

1. 把"退出码 0"当完成。deliver明确规定：期望值必须来自工作单或独立数据，"程序自己说自己对了"不算证据。
2. 手工编辑 Proof 表。Proof 表只由sno deliver-proof写入；把失败行改成 pass，等于伪造交付。
3. 智能体自我审批发布。默认只有负责人能把单从draft放到released；如果工作单里出现智能体"代为决定"的决策，直接打回重写。

另外，执行长任务时每步都写sno handoff-checkpoint接力文件，意味着任何智能体（哪怕额度快用完的）都能随时优雅交棒，这正是 Sno Station Skills 里handoff、rotate-agent等技能配合工作单的意义——任务属于团队，不属于某一个智能体。

相关文件清单

想动手试一遍，按这个顺序读：

• charter技能说明：skills/T-delegation-and-work-orders/charter/skill/SKILL.md
• 工作单模板与检查项示例：skills/T-delegation-and-work-orders/charter/skill/references/template.md
• deliver技能说明：skills/T-delegation-and-work-orders/deliver/skill/SKILL.md
• 功能证明规范：skills/T-delegation-and-work-orders/deliver/skill/references/proof.md
• 证明命令实现：skills/T-delegation-and-work-orders/deliver/skill/scripts/deliver-proof
• 整个"委派与工作单"技能族索引：skills/README.md

小结：给 AI 智能体下任务的新姿势

整套流程其实只有两句话：

1. charter负责把口头需求变成书面契约——交付什么、边界在哪、你已决定什么、每条成功检查怎么证明，缺一不可，且由你批准发布；
2. deliver负责把契约执行到可验证——每一步真实运行、每条检查都有日志留痕，sno deliver-proof check全绿之前，"完成"两个字没有资格出现在报告里。

当"它说做完了"不再是验收标准，你才真正把任务交给了团队，而不是交给了一个能言善辩的新人。🛠️