detail-flow

DetailFlow

概述

使用此技能将产品或功能创意转化为实用、精致的详情页。优先考虑清晰的产品表达、真实的用户工作流、实现质量、响应式表现，以及能够展现产品而非仅作装饰的视觉素材。规划应能在不同产品类别和前端技术栈之间复用。Agent 负责规划和审核；Starcanvas MCP 是默认且强烈推荐的图像后端。

对于图像详情页工作，应着重关注内容清晰度和整套页面的视觉设计。营销效果研究、转化率衡量和销售效果验证不属于默认工作流。

在同一任务中，优先全程使用 Starcanvas MCP：用于整页生成、补充场景或材质图像、修订、局部编辑、扩展和文字修复。为现有页面添加素材并不是一个需要改用无关后端的新任务。在选择 ImageGen/Imagine 等宿主内置工具之前，请先考虑现有的 Starcanvas 路径以及已知的模型和设置；宿主默认工具可能使用未指定的模型。这是建议，并不禁止使用宿主工具。如果最终使用了其他后端，请在已知时注明实际使用的工具/模型，并将其结果与 Starcanvas 记录区分开来。

比例速查： 9:16 仅为默认选项。已在 Starcanvas 1.8.9 上验证的 PT2.5-stable 选项有 1:1、2:3、3:2、3:4、4:3、4:5、5:4、9:16、16:9、21:9。直接使用用户确认的比例。重复使用此列表，避免在生成或修复过程中反复查询；仅在模型/版本变更、出现特定参数错误或请求未缓存时刷新。请参阅模型设置。更改比例本身并不意味着要改用其他后端，也不意味着要生成 HTML 截图。

执行 Starcanvas 任务时，请阅读统一执行器，并使用随附的编译器/执行器。新任务使用 workflow=detail-flow-direct-v4：已批准的计划 -> 完整最终页面批次 -> 视觉审核。默认无需主页面或预览。

对于新产品，请遵循当前产品与已审核参考资料约定。从全新的产品简介开始；在现有计划中填写页面主题/展示选择和排序后的参考资料角色，解决具体的规划警告，然后编译。此流程不新增用户审批环节。历史 v2/v3 软件包仍可检查和恢复。

如果请求是改进 DetailFlow 本身、从已完成的运行中汲取经验，或添加可复用的自我迭代行为，请先阅读 references/self-iteration.md，再提出或编辑技能文件。技能更新应作为经人工批准的补丁处理，而非自主修改。

安装一次，然后开始制作

安装、设置 MCP、处理缺失依赖或接入新宿主时，请先遵循 由 Agent 执行安装。使用 scripts/setup_detail_flow.py 复用可信的本地连接、在私有环境中修复缺失的 Pillow、验证实际 MCP，并记录准确的运行时路径。猜测的客户端 mcp.json 缺失，并不能证明没有连接。如果宿主支持执行脚本，通过执行器直接使用本地 stdio 即可；不要要求重复注册原生连接器。在 Windows 上，捆绑的 CLI 会复用现有连接；若连接不存在，则启动已验证安装的 Starcanvas 应用一次，并等待其就绪。不要默认要求用户手动打开应用。实时 doctor 检查成功后，直接继续制定制作方案。切勿虚构信任按钮、连接器管理位置或强制新建会话步骤。只有观察到阻断错误，且确认存在适用的解决方法时，才要求用户操作。常规安装无需运行开发者测试套件或安装 Playwright。就绪后，继续正常的已批准制作流程。升级时，根据 ready.json 中的实际安装路径，核实发布版本修订号／内容指纹；仅有新的 ZIP 并不会更新该路径。

安装完成判定（必须遵守）

• 安装阶段不得生成或打开示例审核 HTML，也不得运行 prepare_review.py、浏览器回归或全套开发测试来证明安装成功。只检查依赖、文件和实际连接。用户只要求安装时，完成就绪回执即可；明确要求制作时，再进入正常方案流程。正式制作中的可编辑方案审核仍须保留。

• 实际 doctor 检查通过，并确认 workspace_read=true、required_tools_present=true 后，直接执行器通道即已就绪；继续处理已有制作需求或索取产品素材。

• 星幕主程序启动是建立正常连接的前提，不要求用户寻找“开启 MCP 控制”的开关。通用报错不能证明界面上存在此开关；连接失败时，应核实实际端点和桥接响应。

• 安装成功后，不得默认追加待办事项：要求用户“信任 MCP”、寻找“自定义连接器”按钮、重启软件、新建会话，或清理其他 Agent 的 Skill 副本。

• 是否注册或检查原生客户端连接器，不影响已验证的直接 stdio 执行路线。optional_not_checked 或旧回执中的 native_client_trust=not_verified，都不代表用户还欠缺某项操作。

• 只有出现实际阻断错误，且已核实该宿主确实提供相应操作时，才说明错误和唯一必要的操作；不得猜测按钮名称或页面位置，也不得套用其他客户端的流程。

• 只要能读取 Skill 并运行内置脚本，就在当前会话继续；不得默认将新会话作为安装条件。安装成功不代表方案已获确认，也不代表已获生图授权。

选择所需交付内容

• 仅规划或审核：分析并交付所需的方案／结论；不要开始生成或实施前端。
• 电商图片组：使用下文的 Execution Contract 和 Image Generation Workflow。配置的执行后端为 Starcanvas；其工具映射位于 references/starcanvas-execution.md。
• 前端实施：仅当用户确实要求网页／前端时，才使用 Core Workflow。不同的图像比例、修改请求或一般性确认，本身都不足以选择 HTML 截图制作。只有在另行要求生成图片组时，才适用图片制作的审批阶段。

对于其他 Agent 或计算机，请阅读 references/portability.md，了解能力、依赖和离线验证要求。检查接收方 Agent 的能力，而非其品牌。此 Skill 包含通用本地设置和执行约定；需要时，原生客户端注册应遵循宿主文档说明的设施。安装不会授予生成权限。

各 Agent 必须遵守的行为

• 执行前，检查请求阶段所需的能力：本地脚本／文件、图像检查、可编辑 HTML 交付和 Starcanvas MCP。使用随附的配置和宿主工具；不要在页面任务中构建面向特定客户端的安装程序。
• 首次评审必须向用户提供可编辑的文案／布局、导出控件和可用的 HTML 入口。PNG、截图、纯文本方案或用户无法访问的内部文件路径均不满足交付要求。
• 使用 prepare_review.py 构建，然后通过可用的宿主工具展示／打开，或提供可下载的独立 HTML。选择用户确实能够访问的入口。远程文件系统路径不是用户可访问的链接。
• 如果缺少所需能力，请准确说明哪些能力不可用，保留已完成的工作，并暂停依赖该能力的阶段。不要悄然以静态图像替代，不要谎称已打开页面，也不要继续生成。只有用户明确提出替代方案／放弃要求，才能更改交付内容。
• 打开页面、收到导出文件和获得批准是彼此独立的事件。对于该修订版本，沿用用户已明确给予的实际批准；绝不能根据工具执行成功或用户沉默推断已获批准。

执行约定

对于以图像为主导的电商详情页请求，必须严格遵循既定的 DetailFlow 流程。此约定的优先级高于便利性、临场发挥或工具偏好。

• 默认分工：Agent 规划并撰写最终提示词 -> Starcanvas MCP 执行已批准的图像任务 -> Agent 检查返回的原图并处理必要的修订。将这一后端偏好延续到补充素材和后续编辑中。
• 新的最终页面和明确要求的预览使用 PT2.5-stable（gpt-image-2.5-wd）、1K、用户确认的比例（默认为 9:16）、版本 sunburst、质量 auto，并关闭透明背景。提交前核实实际生效的工作坊行和准确、有序的产品输入。新预览保留已确认的比例，不自动切换渠道；历史上的有限回退说明见 references/unified-executor.md。
• 正常顺序：分析输入和参考资料 -> 制定全页面共享视觉规则及各屏幕蓝图 -> 审核可编辑文案/布局 -> 设计审批 -> 并发提交所有已批准的最终页面 -> 逐张及整体检查最终结果 -> 交付。
• 正常工作流只有一个设计审批关卡，涵盖方案、文案和布局。获批后，提交整套已批准页面。不要增加主图、前两页试做或其他中间生成/审批关卡。沿用现有审批和明确授权。
• 若设计关卡尚未获批，则暂停。明确授权可由 Agent 审核取代这一暂停；豁免仅适用于指定阶段。正常直接制作流程不需要主图豁免。对于明确要求的视觉预览，应在用户要求的范围内审核后，再进行依赖该预览的制作。
• 批次完成后，检查每张最终页面及有序页面集。标记产品变更、文字错误、内容缺失和视觉处理不一致。只有用户明确要求额外生成预览时才检查该预览；不要为了满足内部检查清单而制作预览。
• 必须以用户提供的产品图片、参考资料、已确认事实、已批准蓝图和已批准样稿为权威输入。不要用新编造的概念或通用类别模板替代它们。
• 必须将任务限定在用户要求的电商图片集范围内。获批的 Starcanvas 执行所需的最少画布节点和现有传输工具在范围内。除非用户提出要求，否则不要创建网站、视频、动画、演示文稿、应用、新的工具脚本或无关产物。
• 不得仅为模拟图像生成而编写代码、创建占位交付物，或绕过不可用的图像生成/编辑能力。如果必需能力不可用或失败，应说明限制，并停留在当前阶段或提供最小相关替代方案。
• 捆绑的布局渲染器生成的、明确标注的规划线框属于规划产物，不是图像生成的替代品。绝不能将其呈现为模型结果、最终产品图片、视觉审批或生成授权。
• 可选的生活方式预览可以使用无边框关系草图（见 references/layout-preview.md）：保留重要的人物/产品/空间关系，同时让摄影构图保持灵活。不要自动将预览图发送给生成工具。
• 对于常规电商图片制作，首次确认前必须构建并展示可编辑的 HTML 审核页面。使用 scripts/prepare_review.py PLAN.json NEW_REVIEW_FOLDER：该脚本会构建编辑器，并默认请求启动浏览器。阅读 references/copy-review-editor.md。仅提供静态 PNG/联系表不算完成此阶段。导出的修改是对现有蓝图的草稿审核，会使过时提示词失效，且本身不构成生成授权。
• 必须保持用户要求的交付范围稳定：未经批准，不得增加无关阶段、输出格式、图片数量或辅助交付物。用户提供的产品信息有限时，应根据产品图片、产品类别、参考图片和买家常见顾虑，推断合适的卖点文案、场景创意、视觉元素、标签及辅助内容。明确区分合理的创意推断与已确认事实。不得编造用户或源材料未支持的具体技术参数、认证、奖项、医疗效果、折扣或品牌合作。
• 结果失败后，首先通过现有 Starcanvas 路径修改最小的责任层。不要悄悄将其他工具的输出冒充为 Starcanvas 结果。如果变更影响已批准的蓝图或视觉方向，应保留实际审批范围；不要仅为重申此偏好而新增工具权限关卡。
• 必须保留已批准的输出。试验期间不要覆盖或丢弃已接受的参考资料或页面图片；将修订保存为标识清晰的替代版本或新版本。
• 正常页面生成过程中，不得顺带修改此技能自身的 SKILL.md、references/、scripts/ 或元数据。运行过程中如发现可复用的改进，应生成迭代报告，并等待用户明确批准后再编辑技能文件。
• 仅当轻量级现有工具对于读取图像尺寸、拼接已批准切片、检查文件或保存交付物等确定性操作确有必要时，方可使用。除非用户明确要求自动化，否则不要为这些操作创建新的工具脚本。 如果用户的请求含糊不清，请选择最小范围内、能推进当前 DetailFlow 阶段的操作。扩大范围前先征求同意。

默认情况下，最终页面图片应为相互独立的内容面板：每张图片包含一个完整模块，且采用已确认的比例。在整组图片中协调排版、颜色、光线、侧边距、行高和字间距；不要在相邻图片中放置相同的顶部／底部尖括号、共用边缘装饰或用于衔接的片段。用户主动要求的视觉预览是面向客户的设计检查点，不属于常规流程。最终提示词应明确写出共用视觉规则。在选定的混合参考模式下，只附加匹配且已声明的视觉片段；不要用生成的母版或规划草图替代计划。审核生成的页面时，应互相比较各页面并核对已批准的文案，而不是检查其是否仿照母版。

默认流程不使用生成的母版。无缝长图构建仍处于暂停状态：不进行重叠衔接、边缘锚定或接缝修复轮次。按顺序纵向审核以检查连贯性，但无需像素级匹配边缘。

额外修复范围

修复应在源画布中进行。将 repair_context.source_run 绑定到实际的原始运行或先前修复运行，为每个受影响页面记录简要问题，并使用编译器／执行器在现有节点右侧添加一条新的加载器／生成器／工作坊链，并与源页面对齐。切勿替换原始节点／提示词／图片，默认情况下不要新建画布，也不要在新一轮尝试中复用旧工作坊。在每条新链旁添加可见的文本／注释，标明页面、修复轮次、原因和源节点；生成器应保留完整提示词。这些注释不得连接到生成流程。不要尝试对图片节点执行不受支持的标题写入操作。交付原项目身份标识和 canvas-trace.json，以便用户将每次修复追溯到其来源。缺少源记录时，应停止准备，而不是悄悄创建另一个项目。请参阅同画布修复。

新的付费修复批次需要单独的 repair_authorization 记录，其中应绑定受影响的任务 ID、额外生成次数上限和实际用户凭据。仅有生产审批并不意味着获得额外尝试授权。用完记录的次数后，可继续使用明确授予的既有额度；如果修复已在其范围内，则不要额外设置审批关卡。请参阅统一执行器中的修复授权协议。

可选视觉预览

只有在用户明确要求先查看完整套图之前的预览时，才生成视觉预览。将请求记录为 master_request.evidence；不要根据缺少风格参考、不确定性、安装检查或一般性的页面制作请求推断用户需要预览。遵循统一执行器中现有的预览配置和有界服务故障策略。之前的审批、用户指定的生成次数上限和暂停要求仍然有效。预览成功不代表最终套图审核已完成，预览图片也不得作为最终页面的输入。

核心工作流

对于规划／评审，只使用相关的分析和设计步骤。下文的仓库检查、代码编辑和应用／浏览器渲染适用于前端实现，不适用于纯图片方案。

对于图片转电商详情页的请求，不要立即生成最终图片。首先制作结构化的页面蓝图，并采用适用的设计审批流程，或明确委派／豁免相应阶段。用户要求跳过规划，只豁免规划内容的呈现／确认；仍须制定最精简的可执行简报，且不得新增主阶段。遵循阶段政策约定，不要悄悄移除检查项。

1. 明确产品定位

   确定产品名称、目标受众、核心承诺、具体功能、限制、佐证要点和预期行动号召。如果用户提供了产品图片或参考图片，应先推断可见材质、形态、风格、品类、买家可能关注的问题和差异化特点，再撰写页面内容。如果用户提供了现有页面，应先检查当前结构，再提出修改建议。

2. 规划页面架构

   构建易于浏览的叙事：首屏定位、实际价值、功能板块、示例或使用场景、信任／佐证内容、相关的限制或要求，以及明确的下一步行动。对于一组电商页面，应将内容组织成目的明确的多个屏幕，每屏聚焦一个主要任务，同时让各屏的信息密度有所变化。不是每屏都需要营销风格的标题和副标题；有些屏幕应使用较短的引导文案、说明段落、标签、徽章、提示框、成分／细节说明、对比或场景说明。避免使用适用于任何产品的泛泛营销文案。

   对于以图片为主的电商页面组，应让首屏确立 2-4 个核心主张种子。后续屏幕应展开、佐证、呈现或补充这些主张的背景，而不是引入无关的新卖点。如果后续的卖点屏幕无法追溯到首屏中的某个主张种子，应修改该主张种子或屏幕任务。买家服务模块则可以回答不同的实际问题，而无需引入新的宣传主张。

3. 适配现有项目

   编辑前，先了解仓库结构、框架、路由、组件约定、设计令牌、资源策略和本地样式模式。合适时复用现有组件和工具。

4. 为产品理解而设计

   让产品本身成为首屏的视觉重点。酌情使用截图、生成的视觉素材、产品模型、演示或与领域相关的图片。让运营工具保持信息密集、克制且易于浏览；只有当产品类别适合时，才使用更具表现力的视觉设计。

5. 实现页面

   只编辑合理范围内最少数量的文件。内容、布局和交互状态应足够完整，让页面看起来像真实的产品界面，而非占位内容。遵循现有的前端无障碍、响应式设计和视觉层级指南。

6. 通过实际渲染进行验证

   必要时启动应用。通过截图或浏览器检查桌面端和移动端视口。交付前，修复文本溢出、元素重叠、媒体空白、裁切／构图不当、配色单调、状态缺失和布局偏移等问题。

图片生成工作流

将共用的视觉风格与页面布局分开。经确认的文字规则定义视觉基调；有序蓝图控制整组页面的阅读节奏。根据每页的实际内容，使用现有规划字段确定主题、视角／比例、焦点以及图文关系。不要将某张参考图的页眉／边框／文本框布局套用到所有页面。在现有规划中，以及整批完成后，再检查各页面有意义的构图差异；若有助于比较，也可以有意重复。具体检查项请参阅 视觉规划。无需固定的页面类型、装饰元素、配色方案，也无需增加生成／审批阶段。

以下步骤介绍常规的图像流程。执行契约中明确的阶段委派／豁免规则仅对指定阶段优先适用；不要通过参考清单重新引入已豁免的暂停点。

电商页面图像组请使用此工作流。准备执行时，请阅读 Starcanvas 执行。Agent 提供最终确认的提示词和有序参考图；Starcanvas 按原样执行，并返回文件供 Agent 审核。

关于参考图解读、构图选择、屏幕提示词撰写和视觉审核，请阅读 视觉规划。复用现有蓝图字段。常规的规划与草图审核请使用 布局预览，并使用必需的可编辑 HTML。运行 scripts/prepare_review.py 并打开其生成的 review.html；静态预览仅作补充。这是首个确认材料包，不是额外的关卡。若用户明确要求跳过草图或使用其他审核格式，应予以遵从。

1. 分析输入

   分别描述产品图像和参考风格。列出观察到的产品事实、推断出的卖点，以及不应臆造的未知信息。

   规划前，简要询问用户是否已有参考详情页、风格图、书面风格偏好和已确认的产品信息，并请其一并提供；仅在用户尚未提供时询问。复用之前可访问的输入。无需外部风格参考：如果用户未提供，或将方向交由 Agent 决定，则根据产品提出方向并继续。不要重复提问，也不要要求填写问卷。区分可见事实、创意建议和未知规格。

   当参考图中出现鲜明的角色、模特、吉祥物、手部、道具或场景语言时，如果它有助于实现用户要求的风格，就将其视为参考风格 DNA 的一部分。在抽象层面保留其视觉语言，例如 3D 卡通角色形象、友好的品牌代言人、手持产品展示、低角度生活方式拍摄或微距标注风格。不要照搬参考图中的原品牌、具体人物身份、文字或产品。

2. 首先生成页面蓝图 首先在 visual_master_spec 中定义整页的视觉基调：主背景色及明暗度、辅助色和强调色的作用、光线与材质，以及字体层级。然后在生成前输出逐屏蓝图。保留已确认的页面数量；若未指定，默认生成 8 屏。最终页面采用已确认的比例；仅当未指定比例时，默认使用 9:16。旧字段 visual_master_spec 用于保存共用的文字视觉规则；字段名称并不意味着需要生成一张主视觉图。每屏的蓝图必须包含以下字段：slice_id、buyer_question、module_type、module_label、claim_seed、screen_job、evidence_type、content_density、layout_archetype、copy_module_type、copy_structure_pattern、primary_module、secondary_modules、text_exact、hierarchy_strategy、composition_shift、visual_composition、reference_style_notes 和 risk_unknowns。生成最终页面集前，先在可编辑的 HTML 审阅稿中呈现设计与文案，以供首次确认。使用宿主浏览器／文件打开工具或脚本的默认浏览器启动器打开审阅稿；确认文字编辑与导出控件均清晰可见。始终提供 HTML 文件的绝对路径／链接。如果无法打开，请提供路径并说明审阅稿未能打开；暂停生成，等待用户自行打开并审阅，不要改用 PNG。

编写后续页面前，先确定第 01 屏的 claim_seed 集合。使用 2–4 个简短种子，例如可见的成分／细节、质地承诺、使用场景、信任线索、便利性或情感吸引点。后续每个卖点页面都必须注明其展开的是哪个种子。尺寸表、护理说明和退货政策等买家服务模块可使用 claim_seed: null 并设置独立的买家问题；不要强行把这些事实塞进首屏。除非用户明确要求开辟新章节，否则后续页面不得引入第 01 屏未设定的卖点。

这些字段是规划控制项，不是可见标签。不要将 module_type、detail、parameter_trust、FAQ 或 screen_job 等内部标签写进页面可见文案。应将其转化为自然、面向买家的中文文案。

不要强迫每屏都采用相同的「标题＋副标题」结构。最强的标题／副标题表达应留给首屏或其他真正的章节开篇。后续页面应根据章节任务选择文案模块，例如说明文字、小型指南标题、标签组、图标注释、证据要点、成分／细节标注、场景说明、对比行、信任要点或结尾行动号召。文案结构应推动版式变化与层级安排。

为每屏指定不同的 copy_structure_pattern，至少避免相邻页面重复同一模式。例如：hero_claim_stack、question_answer、single_line_with_labels、annotation_map、three_point_breakdown、scene_caption_cluster、mini_steps、trust_checklist、quiet_closing。不同模式应改变句子节奏、可见文案要素、行数和版式表现，而不只是给相同的标题／正文结构换个名字。

征求确认前，检查文案差异、种子连续性和文案结构多样性。每屏都必须回答不同的买家问题，并承担独特的文案角色，同时仍能追溯到首屏的卖点种子。如果不看图片也无法区分相邻页面，就重写规划。若后续卖点页面看起来像无关的宣传主题，就重写；买家服务模块不受卖点种子连续性要求约束。如果 3 屏或更多页面采用相同的句子节奏，例如「标题＋一句说明＋三个标签」，就重写其 copy_structure_pattern。不要让每屏都用细微改写重复相同的口味、品质、便利性或情感承诺。 根据屏幕用途和可用证据选择信息密度。设置一个主要焦点，并在有助于理解时添加辅助模块；详情页／信息页可包含 2-4 个内容点，而场景页或收尾页可以较为简洁。不要为了满足百分比或内容点数量配额而编造或重复文案。如果证据不足，应在获批前提出调整范围，而不是擅自更改已批准的数量。

对于常规草图评审，请在同一份蓝图中提供 layout.blocks，并引用 text_exact。保留现有的 19 个规划字段；几何信息只是渲染扩展，不是另一份问卷。脚本不会规划、改写文案、审批或生成。完成几何检查后，运行 prepare_review.py，交付实际可编辑的首轮评审页面；不要在运行 render_layout_preview.py 后就停止。首次确认前，解决溢出、文案遗漏和意外重叠问题。将导出的修改采纳为当前文案，并重新编译受影响的提示词。新的清单通过 approved_plan（路径／哈希／实际审批证据）绑定已采纳的修订版本；编译器会按执行参考中的说明检查页面覆盖情况和文案准确性。

3. 通过 Starcanvas 执行已批准的页面图像

   文案决定图像内容：材质文案需要面料／纹理视图；腰带、缝线或标签文案需要对应部位的特写；整体产品视图则适用于识别、整体形态或颜色对比页面。编写提示词前，先明确主体和镜头范围。缺少细节素材时，必须明确限定为概念处理，或请求提供相关素材；不得编造事实性特写，也不得悄悄改用整体产品照片。

   Agent 为每个屏幕编写一条最终提示词，并保留已批准的数量和比例。每个屏幕都必须严格遵循已批准的蓝图：编写提示词期间不得更改 module_type、screen_job、evidence_type、content_density、primary_module、secondary_modules 或 text_exact。在适当情况下，每个屏幕必须包含 2-4 个内容点，并由一个主要模块和已批准结构中的辅助模块组成。不要把每个屏幕都简化成相同的标题和主视觉图。

   通过 Starcanvas MCP 执行已批准的任务。默认并发提交相互独立且已就绪的任务；需要新获批参考资料的任务必须等待。设计获批并通过机器检查后，应批量提交整套已批准的最终页面（ready_stage=production），而不是等待一对试生成图，或逐张提交。遵守服务实际并发限制，并记录采用较小批次的原因。替换并附加准确的参考资料，切勿追加旧阶段的图像。提交前导出一份最新快照，并运行 readback-export，检查该批次的生成器、实际生效的工作坊提示词、输入顺序和设置，然后核实实际生成的新原始文件并交还给 Agent。技术执行成功不等于获得视觉审批。节点准备按完整页面链拆分，每次请求最多 80 项操作；这不会改变整套生成任务的提交方式。 确认设计后，使用已声明的产品／模型输入和任何选定的混合模式视觉片段，一次提交所有已确认的最终画面，并为每页建立独立链路。不要在前两页后暂停，等待内部视觉判断。整组完成后，检查每张原图和按顺序排列的纵向预览：共同的色彩、光线、字体、边距，产品身份，已批准的准确文案，各页角色的差异，以及图像与文案的对应关系。不要以与主图的相似度评分。仅在实际已授权的范围和生成次数内修复受影响的页面。无需再次询问即可使用明确授予的修复权限；超出该范围的额外付费请求或已批准方向／内容的变更，须先征求同意。本地素材收集、检查和打包不增加审批环节，也不代表获准重新生成。仅当用户明确要求时，才可选择先生成小批量试稿。

4. 准备图像交付

   按顺序交付单页图像，确保产品身份、字体、调色板和内容顺序一致。保持产品的颜色、形状、品牌标记和特色组件。始终使用 scripts/compose_ordered_preview.py 创建内部纵向有序审核预览；预览可缩放副本以供检查，但必须保留原图。仅在用户要求时交付合成长图。审核或拼接均不意味着要构成无缝场景。

5. Agent 审核与修订

   Agent 检查最终纵向有序预览、清晰易读的分组视图以及每张原图：主导背景色／亮度、相邻色块的变化、材质／光线风格和字体都必须呈现为统一的页面体系。裁切、视角、文案位置和密度的变化必须遵循共同的书面视觉规则，同时服务于当前文案。直接比较生成的整组页面；审核基准不是主图。还要检查产品、必需文案、可读性、尺寸和无依据的声明。单张图片分别通过审核，并不代表整页方案获得认可。无需匹配实体边缘。

   将修订交由最适合负责的最小层级处理：

   • 重复出现的相同错误：检查之前的修复记录，选择不同策略或暂缓处理；不要不断重试相同的整页提示词。任何局部修复后都要检查整页，并保留实际修复权限。
   • 模型渲染的错字、缺失字形或乱码：保持已批准的 text_exact 不变；修正生成指令，或使用明确授权的文字区域修复。不要为了迁就模型错误而更改已批准的文案。
   • 用户确实要求修改文案：仅在用户实际批准或授权的编辑范围内更新 text_exact，使受影响的提示词失效，并在生成权限范围内仅重新生成受影响的页面。
   • 产品身份、方向、颜色、形状、徽标或组件出现问题：强化产品参考约束，并仅重新生成受影响的画面。
   • 单页层级或杂乱问题：修改该画面的 primary_module、secondary_modules、content_density、copy_structure_pattern 或 hierarchy_strategy。
   • 页面间内容顺序出现问题：修改受影响页面的角色或文案，同时保留已批准且未受影响的页面。
   • 多个画面反复出现相同视觉语法：修改这些画面的 composition_shift；保留已批准的叙事和未受影响的画面。
   • 整组风格偏移：相互比较生成的页面，并检查它们共同的书面视觉规则。修复偏离的提示词／页面。若必须更改已批准的设计方向，则返回受影响的确认环节；不得以与主图的相似度作为验收标准。
   • 整页叙事或主张种子出现问题：返回蓝图。仅当已批准的故事发生重大变化时，才进行完整重新生成。

6. 记录可复用的迭代经验 当用户要求迭代技能本身、出现重复失败模式，或某次运行完成后产生了可复用的经验时，请遵循 references/self-iteration.md。创建简明的 iteration_report，说明观察到的问题、责任层级、建议的长期修复方案，以及需要修改的技能文件。未经用户批准拟议的补丁范围前，不要编辑技能文件。

7. 交付图像集

   生成、修订和最终审核全部完成后，保存已批准的图像集，不要额外要求用户确认保存位置。如果用户已提供保存位置，请使用该位置。否则，请在当前工作区中创建一个名称明确的交付文件夹，例如 outputs/product-detail-page/<product-name>-<timestamp>/。如果没有可用的工作区，请在工作源素材所在目录旁边或当前工作目录中创建交付文件夹。保留原始生成文件。

   为每个已批准的独立页面提供清晰的顺序文件名。仅当属于用户要求的交付包或有助于审核时，才附上用户提供或已批准的风格参考，以及示例／联系信息预览。必须进行内部纵向审核；只有用户要求时，才需提供合并成长图的交付文件。除非用户明确要求提供所有迭代版本，否则不要包含已拒绝或已被替代的版本。

   完成所有视觉检查和最终文件筛选后，运行 交付数量 中的数量汇总。包括初次运行、每次修复运行以及任何用户要求的预览流程。报告最终交付的图像数、累计保存的生成图像数和已确认的生成任务数。仅报告图像和任务数量。不要提供货币消耗、索要账单、估算费用，或补充无法提供费用说明。

   确认交付文件夹中存在每个用户要求的文件。报告交付路径、审核状态和未解决的问题。生成完成后，不要再询问保存路径。使用顺序命名，例如 product_screen_01.png 到指定数量；区分审核预览和原始交付文件。

页面原则

• 让首屏回答：这是什么、适合谁，以及它为何在当下重要？
• 相较于含糊的形容词，优先使用具体的能力描述。
• 通过示例、参数、截图、对比和工作流建立可信度。
• 避免嵌套卡片、装饰性图形、通用渐变，以及隐藏实际产品内容的主视觉区块。
• 标题大小应与其容器相称；不要在紧凑面板中使用主视觉区块级别的大字。
• 对标签页、工具栏、媒体框、网格、计数器和功能卡片等固定格式的 UI，使用稳定的尺寸。
• 将移动端视为完整页面，而不是事后压缩的桌面页面。

内容清单

• 产品名称和类别应立即可见。
• 主要 CTA 应符合用户预期的业务或工作流目标。
• 能力描述应具体到可测试或可识别。
• 按用户的决策流程排列版块，而不是按内部功能清单排列。
• 必要时，技术声明应包含限制、假设或使用情境。
• 页面应包含足够多的具体示例，让新访客能够理解产品。
• 面向消费者的文案和最终图像中，只有在用户提供的证据支持时，才能包含规格、认证、折扣、奖项和测量参数。未知信息应放入内部的 risk_unknowns，或明确标注为规划占位内容，绝不能在 text_exact 或交付图像中编造事实性占位信息。

实施检查清单

• 添加新的抽象前，先检查现有组件、路由和样式。
• 使用能展示产品、输出、工作流或真实主题内容的素材。
• 确认图像、视频、画布或生成的视觉内容能够正确呈现。
• 至少检查一个桌面视口和一个移动视口，确保没有溢出或重叠。
• 如果项目提供构建、lint 或测试工具，且变更范围有需要，请运行这些工具。
• 报告用户可以打开的本地 URL 或文件路径。

参考资料

在选择版块模式、将此技能适配到特定产品类别，或检查页面结构是否完整时，请阅读 references/detail-page-patterns.md。

当用户要求 DetailFlow 自我改进、从已完成的运行中学习，或将观察到的失败转化为可复用的技能规则时，请阅读 references/self-iteration.md。

首次审阅完成检查

在确认设计阶段就绪前，请确认：review.html 已存在；提供了可编辑文案和导出控件；已记录一次打开尝试或由主机打开的操作；用户已获得实际的 HTML 链接。review-receipt.json 会记录文件和来源哈希；它不代表已获批准，发起打开请求也不能证明浏览器已显示页面。如执行参考中所述，新的文案主导型任务清单必须包含 review_delivery。只有用户明确要求采用其他审阅格式或豁免时，才可使用 kind: user_alternative；不得根据模型限制或一般性的继续请求推断存在此例外。仅委派阶段任务，不能以图像取代可编辑产物。