每个改动都要走完整流程吗？
只是改一句按钮文字，却先写了几页计划；或者付款规则还没问清，就已经实现完了。两种情况都浪费工作：一边是流程过重，一边是把猜测做得太完整。
先判断风险与不确定性
先描述预计改哪里、影响谁、有哪些不知道。很小且明确的改动直接做并验证；中大改动先 /grill-with-docs，没有代码库时考虑 /grill-me。
跨会话且决策复杂，才升级 /wayfinder。这些名称是相应技能的调用入口；使用前需确认自己的环境是否提供它们，本站没有代执行按钮。
根据风险与未知选择流程。主链：每一步交出什么
典型顺序是对齐、规格、实施工单、实现、评审、PR。下一步消费上一步的产物；缺了输入就标明缺口，不用一份看起来完整的文档遮住未知。
| 步骤 | 输入 | 可交出的结果 |
|---|
| 对齐 | 模糊请求 | 已确认决策 |
|---|
| 规格 | 已定决策 | 目标、行为、范围外、验收方式 |
|---|
| 实施工单 | 规格 | 可独立验收的纵向能力 |
|---|
| 实现 | 边界清楚的工单 | 通过相关检查的改动 |
|---|
| 评审 | 改动与依据 | 需求、规范两条结论 |
|---|
| PR | 评审与行为证据 | 变化概览、前后证据、合并风险 |
|---|
决策地图不是执行许可
/wayfinder 用地图索引连接决策工单，记录依赖与未决问题。它的工单回答「决定什么」，后续 /to-tickets 的工单回答「实现哪个小闭环」。
地图完成后，再按需要进入规格与实施。规划阶段不默认执行生产改动；目标和范围仍要由人确认，地图膨胀也可能增加维护负担。
工作流各步的输入与产出。同一套建议，也有时间条件
2026 年 1 月侧重 Ralph 与 AFK，春季加入追问与原型，7 月给出下面的新命名链，10 月更强调评审和复盘。7 月这条记录不能代替后来的分流建议。
/wayfinder -> /to-spec -> /to-tickets -> /implement -> /code-review
本站译意：决策规划之后，依次形成规格、工单、实现与代码评审。
— Matt Pocock
10 月 8 日的建议已不再默认从 /wayfinder 开始。读早期材料时，先核对它针对的任务和当时的工作方式，再决定是否沿用。
工作流建议随时间变化。练习：给三种任务选路径
动手练习流程只做到足够
- 任务：分别为改按钮文字、重做付款流程、迁移不清楚的旧系统选第一步。
- 产出：每项写出风险、未知与下一步产物。
- 检查：项目大小相同，是否仍可能走不同流程？
参考思路
文字明确就直接改并验证；付款流程先查现有行为并对齐取舍；旧系统先调查，若跨会话且决策互相依赖，再建地图。判断依据是实际改动与未知。
怎样才算完成？
你能为一个任务选出路径，并指出何时需要升级流程。选定的第一步有明确产物，未确认的决定仍列为未决，不能只交一串技能名称。
继续练习对齐与原型，或带着已定决策进入规格与工单。
速查
03跨会话决策
按需要用地图管理依赖，确认后再实施。
来源
非官方、非商业的学习整理，与 Matt Pocock 无隶属或背书关系。所引作品版权归原作者；MIT 复用内容另附版权与许可声明。