企业官网建设流程全解析

Impeccable Visualize 指南：方向构图（Direction Comps）与资产生产的完整管线

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

本文是 Impeccable 技能体系中专用于「构图驱动（comp-led）」构建的参考手册，讲解如何把一个已锁定的视觉方向渲染为三张高保真方向构图（direction comps）、通过唯一批准点获得用户认可，并在批准后把构图转化为可测量、可执行的构建规格与带来源证明（provenance）的光栅资产。读完本文，你将掌握build-phase状态机中 comps 阶段的门禁规则、generate-image/comp-spec/embed-prompt/serve-question等命令的完整用法，以及为什么「构图是契约而非心情板」在 Impeccable 的工程质量体系中是不可妥协的底线。

何时加载本指南：comps 轮次的进入与退出条件

本指南（.cursor/skills/impeccable/reference/visualize.md）不是随时都要加载的通用流程，它服务于一条明确的分支：

• 进入条件：当一次「构图主导（comp-led）」的构建已经具备图像生成能力时加载。图像生成能力包括两种来源：harness 原生的图像工具，或 API 兜底方案——由impeccable context在启动时报告（对应 crates/context/src/generate_image.rs 中基于OPENAI_API_KEY的实现）。
• 跳过条件：代码主导（code-led）的构建契约性地跳过本文件，这是设计使然，而不是流程漂移。此时构图轮的野心转移到方向契约（direction contract）的 FIRST VIEWPORT 块与具名的标志性交互中，由 finish reviewer 在行为层面审计。
• 前置条件：PRODUCT.md与DESIGN.md必须已就绪。new-work.md的流程（.cursor/skills/impeccable/reference/new-work.md）已经解析了视觉世界（visual world），本文件不得重新开启世界讨论。
• 已放电（discharged）的情况：如果 surface 级结构轮已经把三张可视化卡片放到了用户面前（即 new-work 流程中锁定的一张卡片就是已批准的构图），那么本轮已结束：把锁定卡片的 comp 视为已批准构图，记录批准，直接从「批准后」章节继续，不要再生成任何新内容。

这条边界保证了构图轮只服务于「在已定世界内做方向验证」，而不是变成第二次身份（identity）工作坊。每次探测都聚焦于构图、叙事、层级、密度、焦点时刻、标志性元素的使用与图像需求，并保持DESIGN.md中色板、字体方向、材质语言、组件性格、图像立场与动词语法固定不变。

生成三张构图选项（Generate three compositional options）

相位状态（phase state）是硬性前置

构图轮运行在构建的相位状态之内：impeccable build-phase start --direction <seed key> --kind <...>必须先执行（roll 的输出会给出确切命令），并且其comps相位处于打开（open）状态之后才能生成第一张 comp。在 start 之前渲染的 comp 处于状态之外，从该点恢复的会话将没有任何相位可跟随。

这一点在源码层面有强约束：impeccable generate-image会拒绝写入.impeccable/mocks/目录，直到 start 已经运行；harness 原生图像工具也受相同顺序约束。查看 crates/comp-verbs/src/build_phase.rs 可知相位序列为["comps", "spec", "plates", "hero", "sections", "motion", "responsive", "review"]，comps是start后第一个打开的相位；而 comps 门（gate_comps）会实际检查.impeccable/mocks/下是否存在至少三张 comp、每张是否有.jsonprompt sidecar、以及是否有且仅有一张标记了"approved": true。

三张 comp 的产出规则

渲染三张彼此不同的高保真 north-star 构图，覆盖所请求的 surface，并保存到.impeccable/mocks/下以跨会话存活。核心规则包括：

• 按 surface 自身的 viewport 构图：原生应用或移动优先的 surface 使用设备尺寸的竖屏（portrait），桌面场景使用横屏（landscape）。一张被以横屏方式构图的手机屏幕，在任何代码被构建之前就已经错误陈述了构图。
• 构图是构建线程自己的工作，绝不委派：写入 prompt 的线程持有方向的全部上下文，并且在构建开始时已经看过每一张 comp。
• 用工作区相对路径打开每张图像：沙箱化的查看器拒绝绝对路径，而项目根下的每个文件都有相对路径。
• 基于真实内容与已与用户发展的 surface 概念。

在已确立世界上锚定构图

当世界已经建立时，每张 comp 都必须锚定真实身份：截取一个代表性既有页面的截图，作为参考图像传入（harness 图像工具的输入图像，或impeccable generate-image --ref）。prompt 以新 surface 的结构开头，而参考图像承载色板、字体与组件性格——因为仅靠DESIGN.md的文字描述会漂移，像素参考不会。

必须明确命名参考图像贡献了什么、不得贡献什么：

为什么必须是三张

「三」是一个纪律性数字：只有一张 comp 会招致橡皮图章式通过（rubber-stamping）；三张之间的差异才会让「值得构建的构图」浮出水面。

一个常见路径：如果方向轮已经产出了决策 comp（decision comp），它本身就是三张中的第一张——它已经以全保真度渲染了这一方向。此时只需要再生成两张，去变化第一张中「保持固定」的变量，然后三张一起送到批准点。只有一种情况需要在 comps 轮里渲染全部三张：本轮到达时没有任何决策 comp（例如降级 roll、identity 模式页面、或方向被固定但没有经过决策轮）。

四条构图质量纪律

原文档给出了四条相互制衡的纪律，每一条都以「自检 + 重生成」闭环：

1. comp 是设计过的表面，不是主体的照片。prompt 必须以 surface 自身的结构开头：本设计有哪些区域，按顺序命名并给出比例关系；没有导航的页面要明说没有，非常规的 surface 要陈述其非常规骨架。以氛围开头的 prompt 只会得到一张小景画（vignette）——模型画的是鱼市，而不是鱼市的网站。每次渲染后自检：如果它能当作海报挂起来，或读起来像一张上面印了文字的照片，它就不是 comp，必须用更字面的布局脚手架重生成。

2. 反面同样是失败：surface 里没有任何主体。主体以「区域承载的内容」的形式出现；世界只是装饰画框，绝不能取代画框所展示的内容。删除通常搭着 prompt 的排除列表（exclusion list）混进来——排除列表用来约束虚构主张，而对某种媒介的禁令属于已承诺的图像立场（imagery stance），不是谨慎。接受渲染前，要能「指向主体」；一幅描绘了世界的一切却与主体无关的渲染，无论氛围多忠实都是失败的，必须逐区域用主体的内容重生成。

3. 把 comp 当作已上线的屏幕来评判。访客的任务必须仅从图像本身就可读。不看图注就能说出 surface 的模式（Persuade / Operate / Read / Experience）——读不出来的渲染只是没有 surface 的艺术指导。用访客的任务作为 prompt 的主干重生成。

4. 承诺是深度，不是覆盖（Commitment is depth, not coverage）。世界通过一个主导动作（dominant move）加上支撑它的材质、字体与间距进入；其余区域保持静止，让那个动作可被读出。一个安静完成本职工作的区域，比一个表演概念的区域更能推进方向。这条检查削减的是竞争（competition），不是内容：被安静化的区域保留其信息，只是停止表演。当第二个元素以相同尺度与具名焦点时刻竞争时，comp 就是在喊叫；没有具名焦点时刻而多个区域同时表演概念，同样是喊叫。保留最强的动作、安静其余部分后重生成。「Busy is louder, not bolder（忙碌只是更吵，不是更大胆）」是这条纪律的格言。

变化策略与红线

• 用户短列出了多个概念时，把三张分散到这些概念上。
• 方向已承诺时，变化图像能解决的结构不确定性：拓扑（topology）、序列（sequence）、密度（density）、层级（hierarchy）、焦点构图（focal composition）、交互框架（interaction framing）。
• 展示开场时刻之外足够多的内容，以证明概念能统治整个 surface。
• 不得生成色板伪影、不得提出新的氛围问题、不得引入不同的字体声线、不得发明新母题。如果已承诺的世界无法支撑概念，回到概念候选清单，而不是改变世界。

最后，每张 comp 都是方向测试，不是截图规格（screenshot specification）。核心 UI 文本、响应式行为、无障碍、语义与交互状态仍是实现责任，不属于本阶段。

唯一批准点（One approval point）

展示与提问

把三张 comp 一起展示在决策页上（impeccable serve-question，每个选项一张 comp 作为其 hero 图），或仅在 harness 能内联渲染图像时展示在 harness 中；纯文本表面不算展示。然后问三件事：

• 什么应当向前保留（carry forward）？
• 什么对这个世界来说显得虚假？
• 所选概念应当批准、合并、修订还是拒绝？

然后停下来等待。结构化模拟用户同样算「已到场」，要收到相同的问题。

决策页机制在 crates/context/src/serve_question.rs 中实现，支持--schema（打印 payload 结构）、--start（守护进程化、打印页面 URL 与 key）、--wait --key（阻塞等待答案，退出码 3 表示重试）、--update（同一张桌面上交付下一轮）等模式。

委派与降级的边界

在用户批准方向或明确委派选择之前，不得开始写代码。如果用户委派，则依据任务简报、PRODUCT.md与DESIGN.md做选择，并陈述证据。批准是对任务概念的细化，它不修改DESIGN.md。

这个批准点没有替代品，也没有跳过条件：

1. 结构化问题工具出错时，回退到决策页；
2. 只有两者都失败后，才可以把选择视为委派；
3. 被委派的选择要像批准一样被记录，并在第一条回复（而不是最后一条）中披露。

finish reviewer（.cursor/agents/impeccable-finish-reviewer.md）把「comp 轮产出的 comp 没有记录批准」视为实质发现（material finding）；而.impeccable/mocks/decision/下的决策 comp 是方向轮的成果，不是 comp 轮的输出，它们本身不隐含批准。

记录批准：让工具找得到

批准之后必须把选择记录到工具能读取的地方：

• 已批准 comp 的路径写入 surface brief；
• 其.jsonprompt sidecar 增加"approved": true（每个通过impeccable generate-image生成的 comp 都有 sidecar；原生工具没有则创建它）。

sidecar 随 mocks 目录一起旅行，因此批准可以跨越会话与机器存活——即使那些机器从未见过 brief。它正是impeccable build-phase advance读取以关闭 comps 相位的东西。源码印证：build_phase.rs的list_comps会扫描.impeccable/mocks/下所有 png/webp/jpg/jpeg 文件，读取同名.jsonsidecar 并检查approved == true；gate_comps在有 0 张或 2 张以上已批准 comp 时都给出失败原因。

完成记录后：总结构图以及 comp 中不得被字面化（literalized）的部分，返回new-work.md（.cursor/skills/impeccable/reference/new-work.md），从已批准概念记录方向契约，然后开始构建。

批准之后：comp 变成规格（the comp becomes a spec）

北极星不是重构图许可

已批准的 comp 是向语义化、响应式、无障碍代码翻译的北极星，绝不是重新构图的许可：保留色板与情绪的同时重画拓扑，是第二次艺术指导。此外：

• 不得把核心 UI 文本或控件栅格化（rasterize）；
• 批准后未经询问不得替换不同的视觉驱动（visual driver）。

测量，而非记忆

new-work.md第 6 节把构建作为相位运行（impeccable build-phase）。从源码看，这套状态机把「测量」落到了每个门禁上：

• spec 相位：impeccable comp-spec把 comp 转换为带采样色板的区域框（region boxes）。comp-spec的第一步--grid会在 comp 上叠加 10×10 坐标网格（crates/comp-verbs/src/comp_spec.rs中网格列为A-J，行为0-9，区域用类似E0:J4的 span 命名），随后用--regions <file>提交命名好的区域文件，产物是.impeccable/build/spec.json。
• 每个区域的媒介由像素决定，而不是由「好不好构建」决定：

• 为雕塑感面板的饰面写 "CSS"，或为撕裂边缘写多顶点的clip-path，就是对已批准设计的安静删除（quiet deletion）——检测器的 organic-clip-path 与 buried-raster 规则，以及 hero 门的区域分数（region scores）会抓住它。build_phase.rs中 hero 门在发现内联 SVG 插图（svg_illustrations）或有机 clip-path（注入的OrganicScan）时会直接给出失败原因；comp_spec.rs的PAINTED_NOTE正则则会在区域 note 描述绘画材质（diagram、drawing、photograph、texture 等）却标记为代码类型时拒绝该区域。
• 丢弃一个图像原生区域，是用户在批准点做出的范围决策，绝不是批准后的静默扁平化。
• 生成的图像是材料（material）而非声明（claim）：证据规则约束的是断言、规格、证言与被当作真实呈现的照片，从不约束渲染保真度。

hero 门的量化底线

hero 相位是整场运行的成败点，源码给出了硬数字：build_phase.rs中HERO_MIN = 0.72（整体 72% 及格线）、RESPONSIVE_MIN = 0.65、PLATE_MIN = 0.4、PLATE_STRUCTURE_MIN = 0.4。门禁会检查：hero 截图必须在 comp 自身像素尺寸下拍摄；任何区域缺失（missing）、矛盾（contradicted）、图版被裁剪（clipped）、SVG 插图、任何分数的虚构墨迹（invented ink）都是硬否决（hard veto）。文本区域按测量到的 cap height、行数、字重、墨色与位置逐项读数（例如 "cap height 78px in the build, 103px in the comp"），chrome 条按规则高度读数，帧中 comp 平静处出现多余墨迹也会被点名。高于及格线后数字读数降级为建议（advisories），在 responsive 之前的 polish pass 修复。

图版与来源证明（Plates and provenance）

plates 相位：先于任何页面代码

每个栅格区域的图版（plate）在 plates 相位中、任何页面代码之前生产，由 shipped asset producer（.cursor/agents/impeccable-asset-producer.md）或当前线程完成：

• impeccable generate-image --plate <id>：一次端到端生产一个区域，并用comp-spec裁剪的 comp 区域作为参考对图版打分；
• 或 harness 图像工具以impeccable comp-spec --crop <id>的裁剪图为输入、impeccable comp-spec --plate-prompt <id>的 plate prompt 为提示词，随后impeccable embed-prompt。

关键约束（源码build_phase.rs的gate_plates逐一验证）：图版至少是 comp 区域尺寸的 1.5 倍宽；comp 的裁剪永远不是图版（结构相似度 ≥0.95 会直接判为「comp 裁剪重采样」）；墨迹在纯色地面上的图形要用色度键（chroma key）抠出 alpha，让它坐在页面自己的地面上；纹理是 comp 区域的干净补丁镜像平铺，仅在没有干净补丁时才生成。--force只为一个场景存在：用户以「在--reason中引用的原话」降低了 comp 的权威——其他任何理由都被拒绝。

来源证明：生成上下文是资产的一部分

用任何工具生成任何图像之后，都要运行.cursor/skills/impeccable/scripts/impeccable embed-prompt <image> --prompt "<prompt>"，传入工具实际收到的完全一致的字符串（impeccable generate-image会自动完成这一步），让意图活在文件内部：

• --read恢复已嵌入的 prompt；
• --scan <dir>列出仍然缺失 prompt 的栅格。

嵌入的 prompt 加上该区域在 spec 中的行，就是该栅格的来源证明（provenance），artifact 引用的每个栅格都必须携带它。来源化、库存或预先存在的栅格则嵌入其来源（origin）。之后在修复批次或评审者重建中创建或替换的栅格，以同样方式生产；一个修复批次废弃的栅格在同一个批次中删除。

源码层面，crates/context/src/embed_prompt.rs实现了 PNG 的impeccable:prompt关键字（写入tEXt或zTXt块，后者使用 zlib 压缩），并能跨块遍历解析已嵌入的 prompt；crates/context/src/generate_image.rs在调用gpt-image-2后会把 prompt、createdAt、tool、model 与 refs 一并写入<out>.jsonsidecar 并尝试就地嵌入。

图像转换与返回主流程

图像转换使用impeccable context启动时报告的 converter（IMAGE_TOOLS 行）；仅当它报告没有 converter 时才探测（probe），且每会话至多一次、绝不按图像一次。

最后，带着方向契约、分阶段构建与收尾 pass，返回 new-work.md（第 6 节的 phased build 与第 7 节的 finish review）。这条回环正是 Impeccable 的工程哲学：构图轮把「看起来对」的主观判断，压缩成一个可记录、可恢复、可被门禁强制执行的客观状态，而每次构建都以已批准的 comp 为契约、以每张栅格的来源证明为资产账本，一路推进到 finish review 的量化裁决。

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