Agent Skills 工程化实践 03：把共识变成能排队的交付路径

从“我们知道要做什么”到“可以开始做”

对齐完成后，下一步不是马上拆一堆文件任务，而是把共识变成可交付的路径。这个仓库把这件事分成两个相邻动作：to-spec 负责形成 spec，to-tickets 负责把 spec 拆成可以独立验证的 tracer-bullet tickets。

两者都遵守一个约束：不重新 interview，也不偷偷发明已经没有被讨论过的产品决定。上游 conversation 已经确定的内容是输入；如果仍然模糊，应该回到 grill-with-docs。

to-spec 写的是决定，不是文件清单

一份好的 spec 会从用户问题开始，描述 solution、user stories、implementation decisions、testing decisions、out of scope 和 further notes。

Implementation decisions 关注 module、interface、schema、API contract 和 architectural decision，而不是现在的具体文件路径。路径会随着实现变化，决定才是需要跨 session 保留的内容。

Testing decisions 也不等于“补几个单元测试”。它要说清楚什么是 external behavior、应该在哪个 public seam 上观察，以及现有项目里哪些测试可以作为 prior art。这样 implement session 不会一边写代码，一边重新争论测试边界。

Ticket 应该是 tracer bullet

to-tickets 最重要的词是 tracer bullet：一张 ticket 必须贯穿需要的层，形成一条窄但完整、可以 demo 或验证的路径。

不要把工作横向拆成“先做所有 schema，再做所有 API，最后做 UI 和 tests”。这种拆法每一步都可能看起来完成了，却直到最后才知道用户路径是否成立。

更好的拆法是：先交付一个最小但 end-to-end 的行为，再从反馈里扩展下一个行为。每张 ticket 都应该能在一个 fresh context 中被理解，并且有明确的 acceptance criteria。

Blocking edges 让队列变得诚实

多 session 工作最容易失控的地方，是“看起来可以并行”的任务其实依赖了尚未完成的决定。仓库要求每张 ticket 显式写 Blocked by，并按 blockers-first 的顺序创建。

例如：

01  确定导出任务的 domain contract       None
02  从筛选结果生成可下载文件             Blocked by 01
03  在后台展示任务状态                   Blocked by 01
04  处理失败重试与过期                   Blocked by 02, 03

Blocking edge 不是项目管理装饰，它告诉下一个 Agent 哪些 context 已经可靠、哪些路径现在不能开始。所有 blockers 完成的 tickets 才构成当前 frontier。

triage 和 to-tickets 不是一回事

原始 bug report、incoming feature request 和 external PR 需要先经过 triage：确认 category/state，必要时验证问题、补信息或生成 agent-ready brief。

to-tickets 处理的是已经由团队讨论过、已经准备进入实现的 work。它产生的 ticket 默认就是 ready-for-agent，不应该再被当作 incoming issue 重复 triage。区分这两条入口，能避免同一件事在流程里绕圈。

什么时候需要 wayfinder

如果连 destination 都还看不清楚，直接写 spec 只会把 fog of war 转移到文档里。greenfield project 或大到一个 session 装不下的 effort，可以先用 wayfinder 创建一张 decision-ticket map，用 Research、Prototype、Grilling 和 Task tickets 逐项消除不确定性。

wayfinder 的产物仍然是 decisions，不是直接交付 build；map 清晰后，才回到 to-spec → to-tickets → implement。这条边界能防止“规划工具”变成另一种没有终点的 planning theatre。

一份可以执行的检查表

• spec 是否写出了用户问题，而不是只列技术方案？
• ticket 是否能独立 demo，而不是只完成某一层？
• blocking edge 是否真的 gate 了开始条件？
• 当前 frontier 是否足够小，能被一个新 session 接住？
• out of scope 是否明确，避免实现阶段继续扩张？

我的判断是：这套拆分方法真正管理的不是任务数量，而是 context 的形状。每一个新 Agent 都应该能知道自己为什么现在可以开始，以及完成后会为谁解除阻塞。

来源与版本

• 规格化：to-spec
• 垂直切片：to-tickets
• 大型模糊工作：wayfinder
• 参考分支：main · 核验 commit：022fcc3 · 核验日期：2026-08-12