Impeccable `shape` 流程：在写代码前用结构化访谈收敛出经确认的设计简报

导读

shape 是 impeccable 技能系统中负责设计前期任务发现的 Build 类命令，它的全部职责可以用一句话概括：弄清"要做什么、它应当如何运作"，然后交回一份不含任何代码、并已获得用户确认的设计简报（design brief）。本指南基于命令参考文档 .agents/skills/impeccable/reference/shape.md 展开，并结合技能源定义 skill/SKILL.src.md 与配套参考，逐条讲解三阶段流程、两轮访谈的提问纪律、简报的七段式结构与"确认即停止"的收尾边界。读完你不仅能复现该命令的完整行为，还能理解它为什么刻意把"想清楚"与"动手做"切成两个阶段，以及它与 new-work、init、routing 等姊妹参考之间的协作分工。

一、shape 在命令体系中的位置与产出边界

命令定义与触发方式

在 impeccable 的命令表中，shape [feature] 属于 Build（构建）类别，官方描述为 "Plan UX/UI before writing code"（在写代码之前规划 UX/UI），对应参考页即本文所述的 shape.md。命令元数据中对其功能解释得更为完整：

Plan UX and UI before code. Runs a required multi-round discovery interview, uses visual probes when available, and produces a user-confirmed design brief for implementation.

（来源：plugin/skills/impeccable/scripts/command-metadata.json，参数形如 shape [feature to shape]。）

而技能路由规则 skill/SKILL.src.md 明确了一条边界：shape 拥有任务发现（task discovery）的所有权——它只负责把"要做什么、如何运作"问清楚，只有在触及"视觉世界（visual world）"和"表面概念（surface concept）"决策时，才把流程移交给 new-work。

三条硬边界

参考文档对 shape 的产出范围设定了不容逾越的三条边界：

1. Phase 1 不允许写代码或选定视觉方向（"Do not write code or choose visual direction yet"）；
2. 它从不写"方向契约（direction contract）"——那是 skill/reference/new-work.md 在概念落定后，于实施前写入 surface brief 的开发专用契约，shape 要在这一步之前就把接力棒交出去；
3. 它的产物是一份简报，而不是界面——后续的代码实现、视觉方案由体系内其他阶段接手，shape 本身到此为止。

也就是说，shape 是一个面向"规划型"与"未定型"需求的前置闸门：与其让模型在信息缺失时猜测式开工，不如先用最少轮次的问题把方向钉死。

二、三阶段总览

阶段	目的	关键动作	结束判据
Phase 1 Discovery interview	收集"该做什么"的事实	1~2 轮各 2~3 个相关问题，问完即等	获得足以写简报的回答
Phase 2 Resolve the design direction	明确视觉与结构方向归属	新表面/换肤走 new-work；成熟世界内视情况小范围决策	方向确定但尚未进入契约/持久化/实现
Phase 3 Write the brief	产出最小有用简报	按七段结构或 3~5 条要点落笔	简报成形、可提交确认
Confirm and stop	拿到确认	请求明确确认或一轮纠正	得到认可即停止，不写代码

原文定位语："Discover what should be made and how it should work, then return a confirmed design brief without code."

三、Phase 1：发现式访谈（Discovery interview）

1. 节奏纪律（Cadence）——问得少、问得准、问完就停

这一小节是全文档对 AI 行为约束最集中的地方，四条纪律缺一不可：

• 用结构化问题工具，否则发问并停下等待。在支持交互式选择的 harness 里优先使用 structured question tool（该机制在 skill/reference/init.md、skill/reference/new-work.md、skill/reference/visualize.md 中被反复强调）；环境不支持时，就以普通文本提问并等待回答，而不是自问自答。
• 每轮只问两三个彼此相关的问题，然后等待。默认只进行一轮；只有当回答暴露出"实质性缺口（material gap）"时，才允许追加第二轮。
• 绝不倾倒问卷、绝不复述已确定的事实、绝不把显而易见的事实变成选项菜单。正确姿势是：先给出你对现状最可能的解读（"assert the likely reading"），再邀请用户纠正。
• 按输入的成色决定轮次：一条语焉不详的稀疏提示（sparse prompt）至少要有一轮回答；而一条已经非常精确的提示，往往只需要一次紧凑的确认即可。

这套纪律背后的动机很实际：过多无差别问题会消耗用户的耐心，而过早自作主张又会让产物偏离真实需求。把"询问"收敛为"每轮两三个高杠杆问题"，是保证效率与准确率平衡的关键。

2. 第一轮：目的、人群与结果（Round 1: purpose, people, and outcome）

第一轮只从下列问题里挑选最能改变结果的两三个来问（"Choose the two or three questions that most change the result"）：

• 这个页面或功能是用来做什么的？它必须解决什么问题？
• 谁会专门触达它？他们处在什么场景、什么心绪之下？
• 他们首要必须理解或完成的事情是什么？成功长什么样？
• 在这里有什么是独一无二、不可替代的——是邻近产品或通用模板无法声称的？

其中第四问尤其关键：它直接对抗"通用模板味"——如果答案为空，说明这个设计还没有找到只属于该产品的立足点。这正是技能中 "product-specific truth"（产品专属事实）在访谈阶段的体现。

3. 第二轮：素材、行为与边界（Round 2: material, behavior, and boundaries）

第二轮仅在仍存在实质性未决决策时运行，候选问题包括：

• 这个体验必须承载哪些真实内容、证据、数据与资产？现实的最小 / 典型 / 最大量级各是多少？
• 哪些状态与转换是重要的：首次运行、空态、加载、出错、成功、权限、溢出，还是专家用法？
• 期望的保真度 / 广度 / 交互性落在哪档：探索稿、生产级单屏、完整流程，还是更大范围的表面？
• 有哪些**必须保持不动（remain untouched）**的东西？什么样的结果即使看起来精致，也会让人感觉"不对"？
• 哪些平台、框架、性能、无障碍、本地化或交付约束是有约束力的（binding）？

这组问题专门用来把访谈从"界面长什么样"拉回"真实数据与真实场景"。尤其"什么会让结果显得不对"与"什么必须保持不动"，能提前拦截掉那些"看起来精致但违背产品本性"的方案。

4. 绝对禁区

原文用一句话锁死了提问内容的下限：

Never ask for CSS values or canned aesthetic lanes. New-work owns visual-world and concept choices.

即：绝不询问具体的 CSS 取值，绝不要求用户在现成美学风格（canned aesthetic lanes）里做选择。视觉世界与概念选择的所有权属于 new-work。shape 只关心需求、内容、行为与边界这类"作业事实"，颜色值、字号、风格走向这类问题在此阶段被明确禁止——它们是后续 new-work 方向工作坊与概念选择阶段的议题。

四、Phase 2：方向决策的归属（Resolve the design direction）

shape 并不自己完成视觉方向决策，而是按情况分流：

• 新表面（new surface）、品牌扩展（brand expansion）或整体替换（replacement）：转交 skill/reference/new-work.md，走其流程直至完成"视觉权威（visual authority）→ 世界工作坊（world workshop）→ 概念选择（concept choice）"，但复用自己的发现成果，并在进入该流程的契约（contract）、持久化（persistence）与实现（implementation）之前返回 shape。
• 既有成熟世界（established world）内部：只有当构成（composition）或交互（interaction）仍存在实质性开放时，才调用其概念流程；否则直接沿用世界设定即可。

new-work 参考中对这条边界的写法同样值得引用："For shape, return the selected direction to shape.md and stop before persistence or implementation." 也就是说，两个流程是互相咬合的：shape 起步、在方向分叉处把"视觉世界"决策暂托给 new-work、再回到 shape 收尾——方向可以定，但契约、持久化、实现必须留给后面阶段。

顺带一提，new-work 中按 visitor mode（访客模式）设计了不同侧重的提问变体——Persuade 问"谁必须行动、相信什么、用什么真实证据赢得相信"，Operate 问"任务、信息、重要状态、使用频次、约束"，Read 问"读者的疑问、素材、结构、寻路"，Experience 问"什么在引领、探索如何展开、哪个交互/转换重要"。当 shape 需要在既有世界内做小范围概念澄清时，可参考这套按 mode 分化的问题集来提炼自己的第一轮问题。

五、Phase 3：写出"最小有用"的简报

简报的七段式结构

一旦访谈信息就绪，就进入写作阶段。参考文档给出了简报的完整骨架：

#	段落	内容
1	Job and audience（任务与受众）	谁到达这里、其上下文、需求与访客模式（visitor mode）
2	Outcome and proof（结果与证据）	首要任务/动作、成功的定义、真实证据、产品专属真理
3	Selected direction（已选方向）	视觉权威、结构/交互论点、时序、焦点时刻、实现后果
4	Scope and boundaries（范围与边界）	保真度、广度、交互性、具名目标、不可触碰项、明确的反对目标（anti-goals）
5	States and ranges（状态与量级）	现实的内容/数据量级与关键状态
6	Interaction and layout（交互与布局）	层级、拓扑、响应性、可供性（affordances）、反馈与转场——只写意图（intent），不写 CSS
7	Constraints and open decisions（约束与待决项）	平台、交付、无障碍、本地化、可复用组件，以及"构建者不得自行发明"的选项

注意第 6 段的关键措辞："intent, not CSS"——与访谈阶段"不问 CSS 取值"的禁令一脉相承：简报描述设计意图与行为关系，具体的像素与样式交由实现阶段裁决。

篇幅选择：两种模板

原文强调"Write the smallest useful brief"（写最小有用的简报），并给出了两个弹性档位：

• 任务已经定案（task is settled）时：用三到五条要点即可，不必套完整结构；
• 仅当需求模糊（ambiguous）、多屏（multi-screen）或独立规划（standalone planning）时：才使用上述完整七段结构。

最后还有一条写作纪律：不要复述对话过程（Do not restate the conversation）。简报应当是去对话痕迹、可直接交付给实现方的决策文档，而不是访谈记录。

下游落点参照

理解简报中这些字段最终会流向何处，可以参考仓库自带的落地页示例 demos/landing-demo/PRODUCT.md、demos/landing-demo/DESIGN.md 与 demos/landing-demo/DESIGN.json 的文档分层：PRODUCT.md 沉淀持久的产品真理，DESIGN.md 记录耐用的视觉决策，surface brief 则承载只属于某条路由/产物的短期策略。shape 的简报处于这条流水线的最前端——它把"访谈得到的理解"固化成文档化的方向，供下游 new-work 落定方向契约、实现者落地代码、documenter 反向记录系统。

六、确认与停止（Confirm and stop）

收尾三动作

访谈与成稿之后，shape 必须以如下方式收束：

1. 呈交简报，请求明确确认（explicit confirmation），或允许一轮纠正（one correction round）；
2. 然后停止。重申边界："shape never writes code or a direction contract"——它既不是实现命令，也不是方向契约的写入者；
3. 只有当用户明确认可后，任务才算完成。

无人值守时的降级路径

参考文档特别覆盖了一种现实场景：

When no human or structured answer mechanism exists, mark assumptions plainly, return the brief, and stop.

即当既没有真人回答、也没有结构化回答机制可用时：把所做假设清清楚楚地标注出来，照常返回简报，然后停止。这避免了 AI 在无人监督时"自问自答式"虚构事实。与之相呼应的是 skill/reference/init.md 中的更细规则——"是否存在可回答者"是一个机械测试而非主观判断：问题工具或决策页的存在能证明回答机制存在，而"系统提示声称用户不在线"这种说法不能替代实际探测；应先以真实的第一轮问题探测一次，探测报错或超时后才能从显式简报推断，且所有推断事实都要在文档中标注、在首次回复中披露。shape 的降级分支与此纪律同源：宁可明示假设，也不要把猜测伪装成事实。

七、shape 与技能主干的协作：模式、路由与文档分层

shape 虽是独立参考页，它的行为只有放进技能主干才能被正确理解。综合 skill/SKILL.src.md 可得以下协作图景：

• 命令触发：显式说出 shape（或描述"先规划、别急着写码"的意图）→ 加载 shape.md → 按本文三阶段执行；无参数请求则由 skill/reference/routing.md 呈现上下文感知菜单，绝不自动执行命令。
• 访客模式是简报的语言：技能定义里，"模式（mode）命名了这个表面上访客成功的样子"——Persuade（说服，如落地页/定价页）、Operate（操作，如 App UI/仪表盘）、Read（阅读，如文档/文章）、Experience（体验，如作品集/画廊）。shape 简报第 1 段的 "visitor mode" 正是取自这套分类；而选择模式取决于所请求的表面本身，而非产品大类（工具类产品的落地页仍是 Persuade，时尚品牌的技术文档仍是 Read）。
• 概念决策分层：路由规则明确指出 shape 进入 new-work 仅限"视觉世界与表面概念决策"；世界一旦建立，局部新增走既有世界继承，不重新发明身份（见 skill/reference/new-work.md 中 "A section, component, feature, or state inside an established surface inherits that surface"）。
• 与实现命令的分工：shape（规划）→ 概念落定 → 后续 Build/Refine 类命令（如 craft、polish、bolder 等）负责产出与打磨。shape 永远只站在"想法被确认"这一侧，把"怎么实现"留给链条下游。

八、在仓库中的部署形态与规范来源

值得说明的是，shape.md 并非孤本。由于 impeccable 技能会以 SKILL 包形式部署到多个 agent harness，同名的参考文件在仓库中呈镜像分布，均已确认存在：.claude、.cursor、.gemini、.github、.grok、.hermes、.kiro、.opencode、.pi、.qoder、.rovodev、.trae、.trae-cn、.vibe 各自的 skills/impeccable/reference/shape.md，外加插件发行形态 plugin/skills/impeccable/reference/shape.md 与技能源码形态 skill/reference/shape.md（其容器 skill/SKILL.src.md 即命令表与路由规则的规范出处）。这意味着在不同 AI 编程工具中唤起 impeccable 时，shape 的行为约定是逐字一致的——任何一处修订都会同步到所有 harness。

结语：为什么"先 shape 再动手"值得坚持

把一次设计任务的起点硬性拆成"访谈两轮 → 定向分流 → 最小简报 → 确认即停"，本质上是把不确定性关进一个低成本的小盒子里：在投入任何代码、视觉方向甚至概念渲染之前，先用最少的问题交换，换取一份不写代码、却把该知道的都写清楚了的方向文档。对使用者而言，shape 提供了参与设计的明确入口——你只需要回答两三个问题、审阅一份简报；对执行方而言，它保证了后续的 new-work、实现与审查都站在同一份被确认过的事实之上。边界越是清晰，接力越不会掉棒：shape 定"做什么"，new-work 定"长什么样"，实现阶段解决"怎么写"，最终由 finish review 验证"做没做到"——这正是 impeccable 把设计当工程来管的核心姿势。