企业官网建设流程全解析

Impeccable Visualize 深度指南：方向 Comp 生成、审批与资产溯源工作流

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

导读

visualize.md 是 Impeccable 设计技能体系在 comp-led（以构图稿为导向）构建路径上的核心参考文档，定义了"方向确定之后、写任何代码之前"的视觉验证环节：生成三个构图选项、向用户展示并等待唯一审批点、把批准后的构图转译为可测量规范、并以嵌入 prompt 的方式为每一张光栅资产建立可追溯的 provenance。读完本文，你将掌握 Impeccable 中build-phase、generate-image、comp-spec、embed-prompt、serve-question这一组命令在构图阶段如何协同，理解"三张构图 + 一个审批点 + 资产溯源"为什么是该工作流不可跳过的纪律，并能把这些规则映射到仓库源码中逐条落实的实现细节。

何时进入 Visualize 阶段：加载条件与豁免

Visualize 阶段只在满足全部前置条件时加载，代码导向（code-led）的契约会刻意跳过本文件，这是设计决定而非流程漂移：

• 触发来源：从 new-work.md 在 comp-led 构建上加载，且此时图像生成可用（harness 原生图像工具，或 API 回退impeccable context报告的generate-image命令）。
• 前置条件：PRODUCT.md与DESIGN.md必须已就位；new-work 已经解决了视觉世界（visual world）的问题，本文件不得重新打开它——DESIGN.md 的调色板、排版方向、材质语言、组件性格、图像立场与动效语法保持固定。
• 已豁免的情形：surface-scope 的结构轮如果已经按 new-work.md 的纪律把三张可视化卡片摆到用户面前，则本轮已"清偿"：被锁定的卡片构图就是已批准的 comp，只需记录批准并直接从"After approval"继续，不再生成任何新图。相反，impeccable build-phase start --comp <approved comp>启动的构建会把 comps 阶段标记为 skipped（见 build_phase.rs），因为该批准发生在 state 建立之前。

进入构图轮前，先做一次 probe：测试构图、叙事、层级、密度、焦点时刻、签名元素使用与图像需求。注意它不是第二次身份（identity）工作坊——视觉世界已在 new-work 阶段敲定。

生成三个构图选项（Three Comp Round）

构图轮必须运行在构建阶段状态内

构图轮运行在构建的 phase 状态内部：impeccable build-phase start --direction <seed key> --kind <...>必须先运行（roll 的输出会给出确切命令），且第一张 comp 生成之前 comps 阶段必须处于 open 状态。在 start 之前渲染的 comp 落在状态之外，从该点恢复的会话没有可跟随的阶段。impeccable generate-image在 start 运行之前会拒绝向.impeccable/mocks/写入；harness 原生图像工具同样受此顺序约束。从源码看，build_phase.rs维护了八个阶段的磁盘状态机：

参见 build_phase.rs 的PHASES常量。

三张图：数量本身就是纪律

渲染三张互不相同的、高保真的 north-star comp，保存到.impeccable/mocks/下以跨会话存续：

• 视口纪律：在 surface 自己的视口下构图——原生应用或移动优先的 surface 用设备尺寸竖图（portrait），桌面端用横图（landscape）；把手机屏幕横排构图，是在任何东西构建之前就先歪曲了构图。
• 不外包：comp 是构建线程自己的工作，绝不委托他人——写 prompt 的线程持有方向的全部上下文，并在构建开始时见过每一张 comp。
• 相对路径：始终用 workspace 相对路径打开图片；沙箱化查看器拒绝绝对路径，而项目根目录下的一切都有相对路径。
• 真实内容：基于真实内容以及与用户已开发的 surface 概念构图。
• 既有世界的锚定：在 established world 上，每一张 comp 都要锚定真实身份——截取代表性现有页面截图，作为参考图传入（harness 图像工具的输入图，或impeccable generate-image --ref）。prompt 以新 surface 的结构开头，参考图承载调色板、字体与组件性格——因为 DESIGN.md 的文字描述会漂移，而像素参考不会。要明确参考图贡献什么、禁止贡献什么：chrome、调色板、字体、组件性格可沿袭；参考页自身的内容不能沿袭；原样搬来的 banner、hero 或卡片是"参考泄漏"而非保真。

在generate_image.rs的实现中，--ref走的是 multipart 的 images/edits 接口，把参考图以image[]字段随 prompt 一起提交，并在 sidecar JSON 中记录refs数组（见 generate_image.rs）；而IMPECCABLE_IMAGE_GEN_FAKE环境变量则让无 API 环境下生成带 "SYNTHETIC COMP" 水印的合成占位图，保证流程在降级环境仍可演练（见 generate_image.rs）。

三张图从哪来

被选中卡片的 decision comp 是三张中的第一张——它已经在这个纪律下以完整保真度渲染过该方向，所以只需再生成两张：改变第一张保持固定的变量（拓扑、序列、密度、层级、焦点构图或交互取景，见下方"方向分叉"），然后把三张一起送到审批点。只有"没有 decision comp 到达"的轮次（降级 roll、identity 模式页面、未经过 decision 轮就锁定的方向）才需要在这里全部渲染三张。

三这个数字的意义：一张构图会招致橡皮图章式批准（rubber-stamping）；三张之间的跨度才暴露出值得构建的构图。

构图质量的四个自检点

comp 是被设计的表面，不是主题的照片。prompt 要以 surface 自身的结构开头：按顺序点名该设计的区域及其比例关系；没有导航的页面就明说没有导航，非常规表面要陈述其非常规骨架。以氛围开头的 prompt 只会得到一幅小景画——模型画的是鱼市，而不是鱼市的网站。每次渲染后自检：如果它能当海报挂起来，或读起来像一张贴了文字的摄影作品，那它就不是 comp，请用更字面的布局脚手架重新生成。

反面的失败同样成立：一个表面里完全没有主题。主题以区域所容纳的内容出现；世界装饰画框，永远不取代画框展示的内容。删除通常搭着 prompt 的排除列表混进来，因此排除项只用于约束虚构主张，而"禁用某种媒介"属于已承诺的图像立场，不属于谨慎。接受渲染前，先指着主题说清楚它在哪里；一张描绘了世界的一切却唯独没有主题的渲染，无论氛围多忠实都是失败，请逐区域点名主题内容重新生成。

把 comp 当作上线的屏幕来评判：访客的任务必须能仅凭图像读出来。不看说明就说出 surface 的模式（Persuade/Operate/Read/Experience）；读不出模式的渲染只是没有表面的艺术指导。以访客的任务作为 prompt 的脊梁重新生成。

承诺是深度，不是覆盖面。世界通过一个主导动作加上支撑它的材质、字体与间距进入；其余区域保持静止，让那个动作可被读出。一个在自己的世界语法里"只是做好本职"的区域，比一个在表演概念的区堿更能把方向推远。这个检查削减的是竞争，不是内容：被安静下来的区域保留信息、停止表演。与点名焦点时刻同尺度的第二个元素意味着构图在喊叫；没有点名焦点时刻时，多个区域同时表演概念同样是喊叫。保留最强的动作、安静其余部分；忙不是大胆，是更吵。

方向分叉规则

• 用户短列了多个概念时，把三张分散到这些概念上；
• 方向已承诺时，在图像可以解决的结构不确定性上做变化：拓扑、序列、密度、层级、焦点构图或交互取景；
• 展示足够超越开场时刻的内容，证明概念能统领整个表面；
• 不要生成调色板 artifact、提出新的氛围问题、引入不同的字体声音或发明新 motif。如果已承诺的世界无法支撑概念，回到概念候选清单，而不是改变世界。

最后记住：每张 comp 都是方向测试，不是截图规格。核心 UI 文案、响应式行为、可访问性、语义与交互状态仍是实现责任。

唯一的审批点（One Approval Point）

展示与提问

三张图一起展示在 decision page 上（impeccable serve-question，每个选项一张 comp 作为其 hero 图），或仅在 harness 能内联渲染图像时展示在 harness 里——纯文本表面不算展示。提问三个问题：

1. 什么应该保留（carry forward）？
2. 什么让这个世界感觉不真实？
3. 选中的概念应该批准、合并、修订还是拒绝？

然后停止并等待。结构化的模拟用户（structured simulated user）同样算"已到场"，收到相同的问题。

serve-question的实现会把选项渲染为带 kicker、thesis、palette、materials、viewport、risk 的卡片，并支持--schema打印载荷形状；用户选择后以ANSWER: <json>形式返回（见 serve_question.rs）。其中comp字段指向该选项的构图稿路径，页面会对尚未生成的 slot 做 shimmer 等待。

不开始代码，直到批准或委托

用户批准方向或明确委托选择之前，不要开始写代码。委托时，依据任务 brief、PRODUCT.md 与 DESIGN.md 选择，并陈述证据。批准细化的是任务概念，不修改 DESIGN.md。

无替代、无跳过

• 结构化问题工具出错时，回退到 decision page；
• 两者都失败后，才可以把选择视为委托；
• 委托的选择按批准完全相同的记录方式记录，并在第一条回复中披露（不是最后一条）；
• finish reviewer 会把"comp 轮构图没有记录的批准"视为 material finding；.impeccable/mocks/decision/下的 decision comp 是方向轮的手笔，不是 comp 轮的输出，本身不代表任何批准。

从源码看，comps 门禁（gate_comps）正是这条纪律的机械执行：它要求.impeccable/mocks/下至少有 3 张图、每张图都有 prompt sidecar、恰好 1 张携带"approved": true，多或少都会失败并给出可操作的提示（见 build_phase.rs）。

批准之后：把选择记录在工具能找到的地方

• 批准 comp 的路径写入 surface brief；
• 其.jsonprompt sidecar 增加"approved": true（通过impeccable generate-image生成的每张 comp 都有 sidecar；原生工具没写就手动创建）；
• sidecar 随 mocks 文件夹一起移动，因此批准能在看不到 brief 的会话与机器间存续；
• impeccable build-phase advance正是读取这个 sidecar 来关闭 comps 阶段（gate_comps返回的approved路径会被写入 state 的comp字段，见 build_phase.rs）。

generate-image写入的 sidecar 结构包含prompt、createdAt、tool: "impeccable generate-image"、model与可选的refs（见 generate_image.rs），这使得 sidecar 本身就携带了生成上下文。

最后：总结构图以及 comp 中不得被字面化的部分，回到 new-work.md，从已批准的概念记录方向契约，然后构建。

批准之后：comp 变成规范（Spec）

北极星，而非重排许可

批准的 comp 是翻译成语义化、响应式、可访问代码的北极星，绝不是重排的许可：保留调色板与情绪但重画拓扑，是第二次艺术指导。不得把核心 UI 文案或控件光栅化；未经询问不得在批准后替换不同的视觉驱动元素。

像素说了算：光栅 vs 语义

comp 展示的内容是测量出来的，不是记忆出来的。new-work.md 第 6 节把构建作为阶段运行（impeccable build-phase）：spec 阶段用impeccable comp-spec把 comp 变成 region boxes 与采样调色板。每个区域的媒介由像素是什么决定，而非"什么好构建"：

源码里is_raster_kind精确对应这三类（见 comp_spec.rs），而PAINTED_NOTE正则会在 region note 描述了绘制材质（diagram、drawing、illustration、photograph、texture、grain 等）却写成代码媒介时，在 spec 门禁处拒绝（见 comp_spec.rs）。

为雕塑面板的饰面写 "CSS"、为撕裂边缘写多顶点clip-path，都是对已批准设计的安静删除——detector 的 organic-clip-path 与 buried-raster 规则，以及 hero 门禁的区域评分会抓住它（对应测试夹具见 organic-clip-path.html 与 buried-raster.html）。丢弃一个图像原生区域是用户在审批点做出的范围决定，绝不是批准后的无声压平。

最后一句定调：生成的图像是材质（material），不是主张（claim）——证据规则约束的是断言、规格、证言和以真实呈现的照片，从不约束渲染保真度。

Plates 与溯源（Provenance）

Plate 的生产时机与方式

每个光栅区域的 plate 在 plates 阶段、任何页面代码之前生产，由随附的资产生产者或当前线程完成：

• impeccable generate-image --plate <id>：一步到位——自己裁剪 comp 区域、把裁剪作为编辑参考、按资产分辨率定尺、把平地上的墨迹扣到 alpha 键、对照裁剪结果打分（PLATE-SCORE）并嵌入 prompt；
• 或 harness 图像工具：以impeccable comp-spec --crop <id>的输出作为输入图、以impeccable comp-spec --plate-prompt <id>的输出作为 prompt，随后补跑embed-prompt；
• 纹理（纸、布、颗粒）优先从 comp 区域裁剪无墨的干净补丁镜像平铺；只有在没有干净补丁时才生成；
• comp 的裁剪是参考，永远不是交付的像素——plates 门禁会拒绝"是 comp 区域重采样"的文件（结构分 ≥0.95 即判定为同一像素的重采样，见 build_phase.rs）。

生成上下文是资产的一部分

用任何工具生成任何图像后，运行.gemini/skills/impeccable/scripts/impeccable embed-prompt <image> --prompt "<prompt>"，传入工具实际收到的精确字符串（impeccable generate-image会自动完成这一步）。--read可以恢复它，--scan <dir>列出仍缺失它的光栅。实现上，prompt 以impeccable:prompt关键字写入 PNG 的tEXt/zTXt块（或 JPEG 的 COM 注释，marker 0xFE），由embed_prompt.rs负责解析与写入（见 embed_prompt.rs）。

嵌入的 prompt + spec 中该区域的记录行 = 该光栅的 provenance，artifact 引用的每个光栅都必须携带它；有来源的、库存的或既有的光栅改为嵌入其来源。修复批次或 reviewer 重建中新建/替换的光栅以同样方式生产；被修复放弃的光栅在同一批次中删除。impeccable context在启动时报告的转换器（IMAGE_TOOLS 行）用于图像格式转换；只有当它报告没有转换器时才 probe，每个会话至多一次，绝不每张图一次。

收尾：返回 new-work 流程

完成 comp 轮与资产溯源后，返回 new-work.md：

1. 方向契约：在 surface brief 中记录 THESIS / OWN-WORLD / STORY / FIRST VIEWPORT / FORM / FINISH 六段契约，作为后续编辑与恢复的锚点；
2. 分阶段构建：spec → plates → hero（72% 通过线，硬性 veto 一项否决）→ sections → motion → responsive（1440 宽 desktop 与 390 宽 mobile 截图对比）；
3. 收尾通过：comp 对比（comp-diff --comp <approved comp> --build .impeccable/review/desktop.png --spec .impeccable/build/spec.json --out-dir .impeccable/review/diff/final）与 finish reviewer 审核，disposition 为 ship / fix / rebuild / recapture 之一。

整条链路的设计意图清晰：构图轮把"方向对不对"变成用户面前一次可验证的视觉选择，comp 门禁把"建得像不像"变成可数值测量的机械检查，provenance 把"资产从哪来"变成文件自身携带的不可分离事实——三者共同把 AI 构建从"凭记忆复原"推进到"被测量、被记录、可追溯"的工程化流程。

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