Impeccable shape 命令详解：写代码前先完成一轮被确认的 UX 设计简报

在 AI 辅助前端开发中，最常见的失败模式之一是"跳过规划直接写代码"：Agent 拿到一句模糊需求后，立刻开始堆组件、选配色，最后产出一个方向感错误但看起来"挺精致"的界面。Impeccable 的 shape 命令正是为了解决这个问题而设计的——它强制把"发现（Discovery）"和"实现（Build）"拆成两个阶段：shape 只负责搞清楚"要做什么、为谁做、做成什么样算成功"，最终交付一份经过用户确认的设计简报（design brief），并且绝不写任何代码。读完本文，你将掌握 shape 的三阶段工作流（发现访谈、方向决策、简报撰写）的完整规则，理解它在 Impeccable 命令体系中的位置与边界，并能在自己的项目里复现"先确认简报、再动手实现"的工作方式。

shape 在 Impeccable 中的定位

shape 是 Impeccable skill 的 Build 类命令之一。在 SKILL.src.md 的 Commands 表中，它的定义是：

Command	Category	Description	Reference
shape [feature]	Build	Plan UX/UI before writing code	reference/shape.md

命令元数据 command-metadata.json 对它的描述更具体：

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.

注意三个关键词：required（访谈是强制的，不是可选的）、multi-round（分轮进行）、user-confirmed（简报必须经用户确认）。这三个词定义了 shape 与"随手让 AI 写个页面"的本质区别。

从路由规则看，SKILL.src.md 明确写道：

shape owns task discovery, then enters new-work only for visual-world and surface-concept decisions.

也就是说，shape 独占"任务发现"环节；只有当任务涉及视觉世界（visual world）或界面概念（surface concept）层面的决策时，它才会进入 new-work.md 的流程——而且只在 new-work 完成方向选择后就把控制权交还回来，不再往下走。

Phase 1：发现访谈（Discovery Interview）

shape 的第一阶段是发现访谈。shape.md 开篇即立下约束：

Do not write code or choose visual direction yet.

访谈的行为规范（Cadence）有如下要求：

• 优先使用结构化提问工具（structured question tool），不可用时就直接提问并停下来等待回答；
• 每轮问 2～3 个相互关联的问题，然后等待。一轮是默认值；只有当答案暴露出实质性缺口时才加第二轮；
• 禁止倾倒问卷、重复已确认的事实、把显而易见的事实变成选择题。正确姿势是"断言你的最可能解读，然后邀请用户纠正"（Assert the likely reading and invite correction）；
• 稀疏的 prompt 至少需要一轮回答；精确的 prompt 可能只需要一次紧凑的确认。

Round 1：目的、人群与结果

第一轮从以下问题中挑选 2～3 个对结果影响最大的提问：

1. 这个界面（surface）或功能是干什么的？它必须解决什么问题？
2. 具体是谁会接触到它？在什么情境、什么心态下接触？
3. 他们首要需要理解或完成的是什么？成功长什么样？
4. 这里有什么是独特的——相邻产品或通用模板无法声称的？

第四问尤其关键：它直接对应 Impeccable 核心技能文档里的"产品真实性"原则——好的设计必须建立在该产品独有的机制或真相之上，而不是套模板。

Round 2：素材、行为与边界

第二轮只在存在实质性未决问题时才执行，候选问题包括：

• 体验必须承载哪些真实内容、证据、数据和素材？现实的最小、典型、最大范围各是多少？（这是防止 AI 用占位假数据糊弄的关键一问）
• 哪些状态和转换重要：首次运行、空态、加载、错误、成功、权限、溢出、专家用法？
• 预期的保真度、广度和交互程度是什么：探索性原型、可上生产的单屏、完整流程，还是更大的面？
• 什么必须保持不动？即使看起来很精致，什么会让结果"感觉不对"？
• 哪些平台、框架、性能、无障碍、本地化或交付约束是有约束力的？

访谈有一条明确的红线：永远不要索要 CSS 数值或成套的审美风格选项（"Never ask for CSS values or canned aesthetic lanes"）。视觉世界的选择和概念决策属于 new-work.md 的职责，shape 只收集任务层面的事实。

Phase 2：决策设计方向（Resolve the Design Direction）

这一阶段是条件触发的。shape.md 的原文：

For new surfaces, brand expansion, or replacement, follow new-work.md through visual authority, any world workshop, and concept choice. Reuse discovery, then return before its contract, persistence, or implementation. Inside an established world, use its concept process only when composition or interaction remains materially open.

展开来看，这里区分了两种情形：

• 新界面、品牌扩展或视觉世界替换：走完整的 new-work 流程——先判定视觉权威（visual authority，即现有的 DESIGN.md、代码中的既成视觉体系算不算数），如有需要执行世界工作坊（world workshop）和概念选择（concept choice，包括 concept-seed.mjs 掷骰选方向、决策页呈现、re-roll/steer 等机制）。shape 复用其中的发现环节，但在 new-work 写方向契约（direction contract）、持久化或实现之前就把流程交还回来。
• 已建立的视觉世界内部：只有当构图或交互层面仍有实质性开放问题时，才借用其概念流程；否则直接基于既有世界的体系继续规划。

new-work.md 末尾有对应的回还条款：

For shape, return the selected direction to shape.md and stop before persistence or implementation.

这就是 shape 与 new-work 的"半程合作"协议：new-work 负责"选哪个世界"，shape 负责"在这个世界里做什么"，且 shape 的路径永远终止于方向被选出、尚未落盘的时刻。

Phase 3：撰写简报（Write the Brief）

方向确定后，shape 写下"最小可用简报"（the smallest useful brief），包含七个部分：

1. Job and audience（任务与受众）：谁会来、他们的上下文、需求，以及访问者模式（visitor mode，即 Impeccable 的 Persuade / Operate / Read / Experience 四种模式之一，见 SKILL.src.md 的 Modes 一节）；
2. Outcome and proof（结果与证据）：主要任务/动作、成功标准、真实证据，以及产品专属的真相（product-specific truth）；
3. Selected direction（选定方向）：视觉权威、结构与交互论点（thesis）、内容序列、焦点时刻（focal moment），以及它带来的实现后果；
4. Scope and boundaries（范围与边界）：保真度、广度、交互程度、命名目标、保持不动的部分，以及显式的反目标（anti-goals）；
5. States and ranges（状态与范围）：真实的内容/数据范围和重要状态（对应 Round 2 收集的最小/典型/最大数据）；
6. Interaction and layout（交互与布局）：层级、拓扑、响应式、可供性（affordances）、反馈与转场——注意原文强调是意图，而非 CSS（"intent, not CSS"）；
7. Constraints and open decisions（约束与未决项）：平台、交付、无障碍、本地化、可复用组件，以及"构建者不得擅自发明"的选项清单。

篇幅规则同样明确：任务已敲定时用 3～5 条要点即可；完整七段结构只用于模糊的、多屏的、或独立规划类任务；不要复述对话内容。简报的价值在于把散落在对话里的共识固化为一份后续实现者（可能是另一个会话、另一个 Agent）可以直接执行的契约，而不是聊天记录的复读机。

确认即停：shape 的硬边界

流程的最后一节是 Confirm and stop：

Present the brief for explicit confirmation or one correction round, then stop: shape never writes code or a direction contract.

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

两条规则值得展开：

1. shape 永远不写代码，也不写方向契约。方向契约（direction contract）是 new-work 在 surface brief 下的持久化产物（new-work.md 第 5 节 "Record the decision"），由实现路径（comp-led 或 code-led 构建）在开工前落盘；shape 只把选出的方向交还给用户确认，持久化由后续流程承担。这保证了"规划"与"承诺"分离：确认一份简报不等于批准开始构建。
2. 无应答机制时的降级策略：如果既没有人类也没有结构化问答通道（典型的无人值守运行），shape 不得虚构答案，而要明确标注假设、返回简报、然后停止——它仍然不实现。

这套"确认即停"语义在 Impeccable 的行为测试里被直接验证。tests/skill-behavior/scenarios.test.mjs 的 scenario 11 在空工作区执行 /impeccable shape a landing page for the project in this workspace，并断言：Agent 必须先运行 context.mjs 加载项目上下文，且在没有既有视觉世界时必须先解析 init.md（补全 PRODUCT.md 这道构建闸门），之后才允许规划界面——测试名就叫 "shape with no PRODUCT.md resolves the build gate"。tests/skill-behavior/README.md 对同一场景的摘要也印证了这一点：

scenario 11 | empty workspace; prompt is /impeccable shape ... | runs context.mjs; resolves reference/init.md before planning the surface

这说明 shape 的前置条件（PRODUCT.md 缺失时先走 init 捕获产品真相）不是文档建议，而是被行为测试约束的硬性路由。

实操：如何触发与何时使用

在支持 Impeccable 的 harness（Cursor、Codex 等）中，用法是 /impeccable shape <feature>，例如 /impeccable shape a pricing page for the billing flow。触发后的典型时序：

1. Setup 先运行一次 context.mjs（见 SKILL.src.md 的 Setup 一节），加载 PRODUCT.md、DESIGN.md 与匹配的 surface brief；
2. Phase 1 访谈：稀疏需求至少一轮、精确需求一次紧凑确认，每轮 2～3 问后停下等答；
3. 若涉及新界面/品牌扩展/视觉替换，Phase 2 委托 new-work 完成方向选择，然后交还；
4. Phase 3 产出简报：任务明确时 3～5 条要点，模糊/多屏/独立规划时用完整七段；
5. 呈现简报，等待显式确认或一轮纠正，然后停止——代码留给后续的构建命令（如 new-work 的实现路径、live 等）去写。

适用的典型场景：需求一句话但界面不简单（"做个仪表盘"）、涉及多屏或完整流程、需要在动手前对齐状态与数据范围（空态、错误态、溢出）、以及任何"方向错了代价很高"的交付。不适用的场景：对既有界面的小修小补（那属于 polish、clarify 等 Fix/Refine 类命令，且按 init.md 的说明，scoped 命令在 PRODUCT.md 缺失时不应被 shape 或 init 拦截）、纯后端或非 UI 任务（skill 描述明确排除）。

小结

shape 是 Impeccable 里职责最"克制"的构建命令：它用强制的多轮发现访谈收集任务事实，用条件委托把视觉世界的决策交给 new-work，用一份最小可用但结构完整的简报把共识固化下来，最后以"确认即停"守住不写代码、不写契约的边界。从 command-metadata.json 的元数据到 tests/skill-behavior/scenarios.test.mjs 的行为断言，这条"先规划、后实现"的语义在文档、配置与测试三层都得到了印证——这正是它值得在重要界面上优先使用的原因。