企业官网建设流程全解析

用 Impeccable 的 shape 命令在写任何代码之前确定 UX/UI 设计方向：访谈 → 方向解析 → 确认简报

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

本文是 Impeccable 设计工作流参考文档（shape命令的专属 playbook）的技术解读。在开源仓库中该文档以.opencode/skills/impeccable/reference/shape.md为主镜像，并原样同步到skill/reference/shape.md与plugin/skills/impeccable/reference/shape.md（三份 59 行内容完全一致，diff 验证通过），服务于不同 Agent 运行时。读完本文你将掌握：如何用最少、最准的提问完成一次"发现式访谈"，如何判断是否进入方向解析（以及在哪一步必须回头），以及如何产出一份既足以约束后续实现、又不越界碰代码的"确认版设计简报（design brief）"。

Impeccable 把自己定义为"让 AI 设计能力变得更好的设计语言"。它的核心运转方式是一套按命令（command）切分的参考文档（playbook），其中shape是唯一一个把"先想清楚、后写代码"变成硬性纪律的命令。它在命令表中的定位是：shape [feature]—— Build 类别、Plan UX/UI before writing code。换言之，shape的输出不是界面、不是组件、不是样式文件，而是"这份东西到底该做什么、该怎么工作"的一份被用户确认过的文字契约。

shape 在 Impeccable 命令体系中的坐标

先弄清楚shape站在工作流的哪个位置，才不会在实践时把边界搞混。从技能根文档 SKILL.md 的命令表与路由规则可以梳理出如下分工：

SKILL.md 第 76 行给出了最关键的边界定义："shapeowns task discovery, then enters new-work only for visual-world and surface-concept decisions."（shape 拥有"任务发现"，只有涉及视觉世界与界面概念抉择时才进入 new-work 流程。）而在 new-work.md 的结尾又有一句对偶的回传约定："Forshape, return the selected direction to shape.md and stop before persistence or implementation."（对 shape 而言，把已选方向交还给 shape.md，并在任何持久化与实现之前停下。）

把这两句合起来读，shape 的完整生命周期是：任务发现（shape 负责）→ 若需定视觉世界/概念则临时借用 new-work 的方向解析 → 返回 shape → 输出简报 → 停。任何"写代码""写 DESIGN.md""落盘方向契约"的动作都不属于 shape。命令元数据 command-metadata.json 对 shape 的英文描述也印证了这一性质："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."（写码前规划 UX 与 UI，进行必需的、多轮次的发现式访谈，可用时使用视觉探测，并产出一份用户确认过的、供实现使用的设计简报。）

核心纪律：先产出"被确认的设计简报"，不产出代码

shape 参考文档第一行即点明全文主旨：

Discover what should be made and how it should work, then return a confirmed design brief without code.

翻译成可执行的原则就是三句话：

1. 输入是需求噪音：稀疏的一句"我想做一个落地页"或精确的一段产品描述，都是待加工素材；
2. 加工方式是问：通过有节奏的访谈收敛"做什么、为谁做、做成什么样算成功"；
3. 输出是文字契约：一份简短、无代码、并且已经过用户显式确认（或一轮纠错）的设计简报，作为后续一切实现的锚点。

全流程共三个阶段，外加一个收尾动作：

• Phase 1 — 发现式访谈（Discovery interview）：先别写码、别选视觉方向；
• Phase 2 — 解析设计方向（Resolve the design direction）：仅在需要时借用 new-work 的世界/概念流程；
• Phase 3 — 撰写简报（Write the brief）：输出最小可用简报；
• 确认并停止（Confirm and stop）：呈请确认 → 停止，永不越界写代码。

Phase 1：发现式访谈

阶段一的硬约束写在最前面："Do not write code or choose visual direction yet."（此刻既不能写代码，也不能选视觉方向。）访谈的质量由"节奏（Cadence）"和"两轮问题"共同决定。

访谈节奏（Cadence）

节奏规则是整份文档中最容易被 AI Agent 违背、也最值得照抄的部分：

• 使用结构化提问工具，否则问完就停：能调用 structured question tool 就用它，不能就用自然语言问一轮并等待回复，绝不自问自答、绝不停留在"假设用户会同意"的默认路径上；
• 每轮只问两到三个彼此相关的问题，然后等待：一轮是默认配置；只有当答复暴露出实质性的信息缺口（material gap）时，才追加第二轮；
• 禁止倾倒问卷、复述已定事实、或把明显事实变成菜单选项：正确姿势是"断言你对该需求的合理解读，并邀请用户纠正"（Assert the likely reading and invite correction）。这既省用户时间，也让澄清从"选择题"变成"判断题"；
• 按提示的稀疏度决定提问力度：一句话的稀疏需求至少要走一轮完整提问；已经很精确的提示往往只需要一次紧凑确认（compact confirmation）。

这套节奏与init文档中的要求是同构的——init.md 同样要求"每轮最多三个聚焦问题、必须拿到一个真实回答或批准轮"。可见"小而准的问题、两三轮为上限、问完必等"是 Impeccable 所有交互类命令共享的沟通宪法。

第一轮：目的、人群与结果（Purpose, people, and outcome）

从下列问题中挑选最能改变结果的两到三个去问：

1. 这个界面/功能是做什么的，必须解决什么问题？（What is this surface or feature for, and what problem must it solve?）
2. 谁在什么情境、什么心态下到达它？（Who specifically reaches it, in what situation and state of mind?）
3. 他们最需要理解或完成的一件事是什么？成功长什么样？（What is the primary thing they must understand or do? What would success look like?）
4. 这里有什么是独一无二的，是隔壁产品或通用模板无法声称的？（What is uniquely true here that a neighboring product or generic template could not claim?）

注意第 4 问的价值：它逼出"产品特有真相"（product-specific truth），是后续简报里能区别于模板的关键素材。四选二或三即可，问得越多稀释得越快。

第二轮：材料、行为与边界（Material, behavior, and boundaries）

只有当仍存在实质性未决决策时才进入第二轮，问题方向如下：

1. 体验必须承载哪些真实内容/证据/数据/资产？最小、典型、最大量级分别是多少？
2. 哪些状态与过渡是重要的：首次运行、空态、加载、错误、成功、权限、溢出或专家用法？
3. 预期的保真度、广度与交互度是什么：探索性草稿、可上线的单屏、完整流程，还是更大的表面？
4. 什么必须保持不动？即使外观抛光，什么因素会让结果仍然"不对劲"？
5. 哪些平台、框架、性能、无障碍、本地化或交付约束是绑定性的（binding）？

第二轮的功能就是给简报的"States and ranges"与"Constraints"两节采集弹药。

一道红线：永远不问 CSS 值或套路的审美车道

shape 明确写道："Never ask for CSS values or canned aesthetic lanes. New-work owns visual-world and concept choices."（永远不要问 CSS 取值或现成的审美套路——视觉世界与概念选择归 new-work 所有。）换句话说，访谈里可以问"这个界面最该让用户第一眼相信什么"，但不能问"你想要什么主色 / 圆角多大 / 走玻璃拟态还是新粗野主义"。具体配色、字体、材质这类视觉方向的决策权在 Phase 2/后续 new-work，硬要在发现阶段问出来，只会把用户拖进他本该在方向卡片前做的选择里。

Phase 2：解析设计方向（Resolve the design direction）

shape自身不发明视觉世界，但它必须决定"这次的视觉方向要不要被解析"，以及"借用谁的流程来解析"。参考文档给出的分流逻辑有三条：

1. 新界面、品牌扩张或整体替换：跟随 new-work.md，依次完成视觉权威确认（visual authority）→（如有需要）世界工作坊（world workshop）→ 概念选择（concept choice）。shape 在此只复用其发现结果，一旦走到方向契约（direction contract）、持久化（persistence）或实现（implementation）之前，就必须撤回；
2. 位于已确立的既有世界内：只有当构图或交互仍然实质性开放时，才按该世界的概念流程走一遍；否则视为局部延展，直接跳过概念流程；
3. 无论哪种情况：方向一旦选定，立即回到 shape 自己的流程（写简报），而不是留在 new-work 里继续前进。

为让你理解"借用流程"具体借的是什么，new-work 文档的对应段落可以补一句：它决定"已有什么是真的"（重新设计则替换旧视觉世界、已确立世界则继承、品牌残缺则扩展、无视觉权威则与用户共建新世界），随后在不同规模（延展既有界面 / 在既有世界内新建整面 / 创建或替换整个视觉世界）上选择适量的发明，并用concept-seed.mjs --scope surface/direction --mode <mode>这类脚本做掷骰与挑战者搭配，最后在方向契约（direction contract，固定六个短块：THESIS、OWN-WORLD、STORY、FIRST VIEWPORT、FORM、FINISH，全文不超过 150 词）里落盘。方向契约一旦写入 surface brief，就属于持久化动作——这恰是 shape 必须在此停步、把接力棒交回 shape 简报的界线。

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

简报的原则是**"最小有用"（the smallest useful brief）**。七项内容在原文档中逐条给出：

1. 任务与受众（Job and audience）：谁到达这里、他们的上下文、需求与访客模式（visitor mode）；
2. 结果与证明（Outcome and proof）：首要任务/动作、成功标准、真实证据、产品特有真相；
3. 已选方向（Selected direction）：视觉权威、结构/交互论点、序列（sequence）、焦点时刻（focal moment）、实现后果；
4. 范围与边界（Scope and boundaries）：保真度、广度、交互度、具名目标（named target）、哪些保持不动、显式反目标（anti-goals）；
5. 状态与量级（States and ranges）：真实的内容/数据区间与实质性状态；
6. 交互与布局（Interaction and layout）：层级、拓扑（topology）、响应式、可供性（affordances）、反馈与过渡——只写意图（intent），不写 CSS；
7. 约束与未决决策（Constraints and open decisions）：平台、交付、无障碍、本地化、可复用组件，以及"构建者不得自行发明"的选择。

篇幅规则同样重要：任务已经清晰时，用三到五条要点即可；只有对模糊、多屏或独立规划（standalone planning）才使用完整七节结构。并且"不要复述对话"（Do not restate the conversation）——简报是蒸馏后的契约，不是聊天记录的摘要。

第 6 项的"intent, not CSS"值得再强调一次：简报里可以写"主导航在首屏顶部、主行动按钮是一屏内唯一的高优先级动作、状态切换需要有清晰的过渡反馈"，但不应写"主按钮用 #0A84FF 圆角 12px"。后者属于方向契约与实现层，前者才是 shape 的产物。

确认并停止（Confirm and stop）

收尾动作在文档里只有一句话，却包含四个强制点：

• 把简报呈给用户，等待显式确认或一轮纠错；
• 然后停止；
• shape 永不写代码，也永不写方向契约（shape never writes code or a direction contract）；
• 兜底规则：当不存在人类或结构化回答机制时（no human or structured answer mechanism），如实标注假设、直接返回简报、然后停止——此时"标注假设"（mark assumptions plainly）是保证简报可信度的手段，而不是继续自作主张写实现的借口。

这条兜底规则在实际 Agent 工作流里非常有价值：自动任务没有真人在线时，shape 不能无限等待，也不能把未经确认的假设当作已确认事实继续构建，唯一正确的出口是"假设已注明 + 简报已交付 + 流程已停"。

把 shape 放进一次完整的 Impeccable 运行：前后接力示意

结合仓库里其他参考文档，可以把 shape 放到一条典型链路上看它的前后接力：

1. 语境装载：会话开始时由context.mjs装载 PRODUCT.md、DESIGN.md、匹配的 surface brief（见 SKILL.md 的 Setup 段；无 PRODUCT.md 时，路由会让新界面或替换世界先走init，再走 new-work）；
2. shape <feature>：按本文流程完成发现访谈 →（按需）方向解析 → 产出被确认的简报；
3. new-work 实施：拿到确认简报后进入 new-work.md 的方向契约与构建阶段，craft-floor.md 在动手编辑 UI 前装载，提供质量底线与禁令清单（对比度 ≥4.5:1、正文行长 65–75ch 等机械性检查由其背书）；
4. 收尾：finish-reviewer等 shipped agent 与document命令负责审阅与 DESIGN.md 沉淀——但那是 shape 之后的章节了。

此外，SKILL.md 的模式（Modes）概念是访谈问题的幕后框架：Persuade（说服，落地页/营销/定价）、Operate（操作，应用 UI/仪表盘/设置）、Read（阅读，文档/指南/帮助）、Experience（体验，作品集/画廊）。访谈问"谁到达、要做什么、成功长什么样"，本质上是在替用户确认目标界面所属的模式——选对模式，后续一切（new-work 的概念工作坊、craft-floor 的质量地板）才有了准星。选模式看的是"这个表面对访客意味着什么"，而不是产品类型：工具的落地页仍是 Persuade，时装屋的文档仍是 Read。

从仓库证据看 shape 的分发与一致性

该 playbook 作为 Impeccable 技能的知识层被分发到多个 Agent 运行时，仓库内至少有三处一致的镜像：

• .opencode/skills/impeccable/reference/shape.md（OpenCode 安装渠道主镜像，本次解读对象）；
• skill/reference/shape.md；
• plugin/skills/impeccable/reference/shape.md（OpenAI/插件打包渠道）。

三者均为 59 行、内容逐字一致（仓库内diff验证通过），说明 shape 的玩法定义是跨运行时强一致的；同时其命令名、类别、argument hint（[feature to shape]）与功能描述被登记在 command-metadata.json 中，供/impeccable无参路由菜单呈现（见 routing.md：无参调用时推荐 2–3 个最高价值命令，shape 属于显式/可明确推断的命令，命中即装载本文档）。与 shape 对话节奏最相似的姊妹文档是 init.md（同样的结构化提问、每轮最多三问、问完必等），若要横向学习 Impeccable 的提问法，两篇对照阅读即可。

小结：shape 的成败判据

一个shape运行是否合格，可以用五条检查自问：

1. 是否在写任何代码或选任何视觉方向之前完成了访谈？
2. 每轮是否只问了两三个相关问题、并在每轮后等待了回复？
3. 是否把稀疏需求至少问了一轮、对精确需求只做了紧凑确认？
4. 简报是否"最小有用"——清晰任务只用三到五条要点，且全文零 CSS、零实现细节？
5. 是否获得了显式确认（或一轮纠错）后就地停止，没有越界去写代码或方向契约？

如果五条全绿，你就完成了一次合格的 Impeccable shape 运行：把一团需求噪音，蒸馏成了一份既约束后续实现、又把"视觉世界与概念选择"留给 proper 阶段的一份被确认的设计简报——这正是"先想清楚再动手"在 AI 设计工作流中的工程化落地。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable