图 02 · 入口选择

工作以不同形态出现时,我应该怎么做?

六条入口路线的决策树。每种起始情况对应一个明确的首选技能,避免用同一个流程处理所有类型的不确定性。

入口选择决策树 从六种起始情况出发,选择不同的技能作为入口,最终汇聚到 to-spec 和 implement。 当前工作的起始情况是什么? 选择最接近的描述 一个会话内可以 说清楚的新功能 [用户 / 工程] /grill-with-docs 澄清意图 + 建立 共享词汇 外部提交的原始 bug 报告 / 请求 [用户 / 工程] /triage 状态机分拣, 给工单分配角色 难以复现的 bug / 生产回归 [Agent / 工程] {diagnosing-bugs} 先建立反馈循环, 再分析原因 大型工作,架构 决策尚不清晰 [用户 / 工程] /wayfinder 多会话决策映射, 逐决策推进 可运行的设计问题 (比讨论便宜) [Agent / 工程] {prototype} 可扔掉的原型, 回答一个设计问题 内容创意,受众 或证据不明 [用户 / 生产力] /grill-me 澄清受众与 改变目标 虚线:先提取决策 [用户 / 工程] /to-spec → /to-tickets → /implement 所有工程路线的主流程(图 01) [产物 / 生产力] 内容简报 进入图 10 内容流水线 ⚠ 注意:/triage 仅用于外部到来的未塑形工作 /to-tickets 产出的工单已经是 agent-ready,不需要再次 triage 路线选择提示 grill-with-docs = 工程场景,语言持久化到仓库 grill-me = 无状态采访,内容或临时探索 prototype = 可运行比讨论便宜时使用 wayfinder = 多会话决策,终点不清晰 triage = 仅用于外部到来的未塑形工作 grill-me (内容) → 进入图 10,不经过 to-spec

常见错误:用同一个流程处理所有问题

一个生产回归不需要 grill-with-docs——需要的是可复现的失败检查。一个外部提交的模糊 bug 报告不应该直接进入 to-spec——需要先经过 triage 赋予状态角色。

内容路线的分叉点

/grill-me 用于内容创意时,它的输出(内容简报)不进入 /to-spec,而是进入图 10 的内容流水线。这条路线展示的是可迁移的方法(澄清→研究→产出),而不是工程技能的直接复用。

线性阅读顺序:面对中央问题「当前情况是什么」,选择六条路线之一:新功能 → /grill-with-docs;外部工单 → /triage;难 bug → {diagnosing-bugs};大型工作 → /wayfinder;可运行设计问题 → {prototype};内容创意 → /grill-me。工程路线最终汇聚到 /to-spec → /to-tickets → /implement。内容路线进入图 10。