关于 detail-flow
detail-flow 是用于规划、生成、审查和迭代产品详情页的技能,尤其面向图片主导的电商页面。它涵盖设计与实现,并在关键阶段要求确认,确保交付内容不超出请求范围。
主要功能
- 01规划产品详情页
- 02制作八屏页面蓝图
- 03在关键阶段设置确认
- 04图像生成与审查流程
- 05响应式实现与渲染检查
- 06范围与宣传声明约束
适用场景
- 01根据产品图规划电商详情页
- 02制作并审查长图销售页面
- 03在现有项目中实现并检查产品页
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ ajbeckliy/ detail-flow --skill detail-flow安装后在 Claude Code 中输入/detail-flow确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdagents/openai.yamlreferences/detail-page-patterns.md详细介绍
DetailFlow
概述
使用此技能将产品或功能创意转化为实用、精致的详情页。优先确保产品信息清晰、用户工作流贴合实际、实现质量高、响应式体验良好,并使用能够展现产品而非仅作装饰的视觉素材。此技能应保持通用,可搭配不同的图像生成工具、前端技术栈或本地流程使用,但其核心任务是规划、生成、审核和迭代产品详情页。
执行规范
对于以图片为主的电商详情页请求,必须严格遵循定义的 DetailFlow 路线。此规范的优先级高于便利性、临场发挥或工具偏好。
- 必须按以下顺序执行:分析输入 -> 生成页面蓝图 -> 等待用户首次批准 -> 确定文案和视觉主稿 -> 在使用 1:3 图片主稿时生成并进行内部检查 -> 生成前 2 张最终切片 -> 创建 2 张切片的拼接预览并进行内部检查 -> 一并提交 1:3 主稿、前 2 张切片、预览和审核结果 -> 等待用户第二次批准 -> 生成剩余切片 -> 进行最终审核 -> 保存并报告输出文件夹。
- 标准工作流必须且只能设置两个常规用户审批关卡:审批 1 确认完整页面蓝图;审批 2 确认包含 1:3 主稿、前 2 张切片及其拼接预览的视觉样稿包。不得在主稿与前 2 张切片之间另设确认环节。只有在严重故障妨碍安全继续,或用户要求更改工作流时,才需要额外确认。
- 必须在两个审批关卡处暂停。不得将沉默、其他阶段的批准,或笼统的“继续”请求视为对尚未审核的蓝图或视觉样稿包的批准。
- 必须在继续之前检查每一份生成的主稿和阶段性输出。若图片没有预定文案、看起来像无关的独立海报、忽略参考风格、更改了产品、包含乱码,或编造了无依据的宣传内容,则不得继续。
- 必须以用户提供的产品图片、参考图片、已确认事实、已批准蓝图和已批准主稿作为权威输入。不得用新编造的概念或通用品类模板取而代之。
- 必须将任务限定在用户要求的电商图片集范围内。除非用户明确要求,否则不得创建网站、视频、动画、演示文稿、应用、工作流节点、Python 脚本、自动化脚本或其他辅助产物。
- 不得仅为模拟图片生成、创建占位交付物,或绕过不可用的图片生成/编辑能力而编写代码。如果所需能力不可用或失败,请说明限制并停留在当前阶段,或提供最小范围的替代方案。
- 必须保持用户要求的交付范围稳定:未经批准,不得添加无关阶段、输出格式、图片数量或辅助交付物。用户提供的产品信息有限时,可根据产品图片、产品类别、参考图片和买家常见顾虑,推断合适的卖点文案、场景创意、视觉元素、标签和辅助内容。必须明确区分合理的创意推断与已确认事实。不得编造用户或源材料未支持的确切技术参数、认证、奖项、医疗功效、折扣或品牌合作信息。
- 生成结果失败后,不得暗中更改制作路线。只能按照修订路由规则修改责任范围最小的部分;若更改会影响已批准的蓝图或主稿,则必须请求确认。
- 必须保留已批准的输出。试验期间不得覆盖或丢弃已接受的主稿或切片;修订稿应另存为清晰标注的替代版本或新版本。
- 仅在确有必要执行读取图片尺寸、拼接已批准切片、检查文件或保存交付物等确定性操作时,才可使用轻量级现有工具。除非用户明确要求自动化,否则不得为这些操作创建新的工具脚本。
如果用户的请求不明确,应选择能推进当前 DetailFlow 阶段的最小范围操作。扩展范围前先询问。
核心工作流程
对于将图片转化为电商详情页的请求,不要立即生成最终图片。先制作结构化的页面蓝图,并请用户确认或修改。只有在用户批准内容计划后才生成图片,除非用户明确要求跳过规划。
-
明确产品定位
确认产品名称、受众、核心承诺、具体能力、限制、佐证信息和预期的行动号召。如果用户提供了产品图片或参考图片,在撰写页面版块前,先推断可见的材质、形态、风格、类别、潜在买家顾虑和差异化优势。如果用户提供了现有页面,先检查当前结构,再提出修改建议。
-
规划页面架构
构建便于浏览的叙事结构:首屏定位、实用价值、能力版块、示例或使用场景、信任背书/佐证信息、相关限制或要求,以及明确的下一步行动。对于电商长页面,将内容拆分成精心规划的多个屏,每屏聚焦一个主要目标,同时调整各屏的信息量。并非每屏都需要广告风格的标题和副标题;有些屏应使用更简洁的引导文案、说明性段落、标签、徽章、提示框、成分/细节说明、对比或场景说明。避免使用适用于任何产品的泛泛营销文案。
对于以图片为主的电商长页面,首屏应确立 2-4 个核心卖点线索。后续各屏应展开、佐证、呈现或补充说明这些线索,而不是引入无关的新卖点。如果后续某屏的文案无法追溯到首屏的某个卖点线索,则应调整首屏卖点线索,或重新明确后续屏的目标。
-
适配现有项目
编辑前先了解代码仓库结构、框架、路由、组件规范、设计令牌、资源策略和本地样式模式。适用时复用现有组件和工具函数。
-
便于理解产品
让产品本身成为首屏传达的信息。适当使用截图、生成的视觉素材、产品模型、演示或与领域相关的图片。让操作型工具的页面内容紧凑、克制且易于浏览;仅在产品类别适合时使用更具表现力的视觉设计。
-
实现页面
以合理的最少文件数完成编辑。确保内容、布局和交互状态足够完整,让页面呈现为真实的产品界面,而非占位页面。遵循现有前端指南,确保无障碍性、响应式布局和清晰的视觉层级。
-
使用真实渲染进行验证
必要时启动应用。通过截图或浏览器检查桌面端和移动端视口。交付前修复文本溢出、元素重叠、媒体空白、裁切/取景不自然、配色单调、状态缺失和布局偏移等问题。
图片生成工作流程
当用户提供产品图片,并要求制作电商详情页、8 屏页面、长图销售页或基于风格参考的产品页面时,使用此工作流程。
-
分析输入
分别描述产品图片和参考风格。列出观察到的产品事实、推断出的卖点,以及不应凭空编造的信息。
编写蓝图前,若用户尚未提供经确认的卖点、规格、功能、受众或禁止使用的宣传内容,应简要给用户一次补充这些信息的机会。不要将其变成强制问卷。如果用户选择不补充信息,则依据产品图片中的证据和合理的品类级推断继续,并明确说明未经确认的卖点由 AI 推断得出,商业使用前应进行审核。 当参考图中包含鲜明的人物、模型、吉祥物、手部、道具或场景语言时,如果它有助于呈现用户要求的风格,就将其视为参考风格 DNA 的一部分。在抽象层面保留其视觉语言,例如 3D 卡通角色形象、亲切的品牌主持人、手持产品展示、低角度生活方式镜头或微距标注风格。不要照搬参考图中的原品牌、具体人物身份、文字或产品。
-
先制作页面蓝图
生成图片前,先输出一份包含 8 个屏幕的页面蓝图。每个屏幕都必须包含以下字段:
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、top_edge_anchor、bottom_edge_anchor、visual_composition、reference_style_notes和risk_unknowns。生成图片前,请用户确认或修改蓝图。先定义第 01 屏的
claim_seed集合,再撰写后续屏幕。使用 2–4 个简短的种子,例如可见的成分/细节、质地承诺、使用时刻、信任提示、便利性或情感钩子。每个后续屏幕都必须指出自己在扩展哪个种子。除非用户明确要求开启新章节,否则不要在后续屏幕引入第 01 屏未设定的卖点。将这些字段视为规划控制项,而非可见标签。不要在可见页面文案中写入
module_type、detail、parameter_trust、FAQ或screen_job等内部标签。应将它们转化为自然、面向买家的中文文案。不要强迫每个屏幕都采用相同的“标题+副标题”结构。将最醒目的标题/副标题设计留给第 01 屏或其他真正的章节开篇。后续屏幕应根据该部分的任务选择文案模块,例如说明文字、小型引导标题、标签组、图标注释、证据要点、成分/细节标注、场景说明、对比行、信任要点或结尾 CTA。文案结构应推动布局变化和层级安排。
为每个屏幕指定独特的
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。不同模式应改变句式节奏、可见文案要素、行数和布局表现,而不只是换个名字来重复相同的标题/正文结构。请求确认前,请检查文案差异化、种子连贯性和文案结构多样性。每个屏幕都必须回答不同的买家问题,并承担独特的文案角色,同时仍可追溯至第 01 屏设定的种子。如果相邻屏幕脱离图片后读起来可以互换,就重写方案。如果后续屏幕像是独立的新主题,而非对既定种子的深入阐释,就重写方案。如果 3 个或更多屏幕采用相同的句式节奏,例如“标题+一句说明+三个标签”,就重写它们的
copy_structure_pattern。不要让每个屏幕都以细微改写的方式重复相同的口味、品质、便利性或情感承诺。除非用户要求采用刻意简约的视觉形式,否则至少 70% 的屏幕应包含 2–4 个内容点,由一个
primary_module和 1–3 个secondary_modules构成。低密度屏幕可以减少文字,但仍须承担明确作用,例如过渡、场景氛围、信任说明、产品身份展示或收尾情感表达。 -
在最终切片生成前锁定长图母版和结构
生成最终屏幕前,先创建或确认长图母版和结构:
- 文本母版:
visual_master_spec、master_reference_prompt和visual_style_dna。用它来锁定调色板、光线、空间、材质、字体、连续性主题、参考风格 DNA、产品身份规则、章节节奏、信息密度和页面结构。 - 图像母版:在工作流支持或适用时,使用 1:3 连续长页面母版参考。用它来锁定长页面的空间连续性:背景世界、地面/桌面透视、光线方向、配料/粒子流动、反复出现的视觉主题、产品比例节奏、章节间过渡,以及整体可见文案层级。测试详情页时,应加入简化的可见中文文案,或清晰预留能体现已批准
text_exact层级的文本模块;除非用户明确要求纯空间参考,否则不要制作完全没有文字的母版。 - 结构蓝图:按顺序排列的屏幕项目,使用
module_type、claim_seed、screen_job、evidence_type、content_density、primary_module、secondary_modules、text_exact、hierarchy_strategy、composition_shift和边缘锚点。将其作为最终提示词的最高优先级来源。
1:3 图像母版不是最终交付物,不是裁剪来源,也不能替代已批准的 9:21 结构。它是连续性和层级参考。不要逐像素复制、裁剪成最终图片,也不要强制每个切片都匹配其确切构图。如果 1:3 母版看起来像彼此独立的海报,而不是一个连续的电商详情页;缺少详情页母版应有的文本层级;或在多个区域重复相同的产品/角色/主要主题英雄构图,请在生成最终 9:21 切片前修改母版。
- 文本母版:
-
生成最终页面分区
将最终画面生成为连续长滚动详情页切片。除非用户明确要求其他平台比例,否则优先使用项目默认的
9:21竖版切片比例。每个切片都必须严格遵循已批准的蓝图:编写提示词时,不要更改module_type、screen_job、evidence_type、content_density、primary_module、secondary_modules或text_exact。适当时,每个切片应包含 2-4 个内容要点,并以一个主要模块搭配已批准结构中的次要模块。不要把每个切片都简化成只有一个海报标题和一张主视觉图。如果存在 1:3 空间母版,每个 9:21 切片提示词都应将其作为共享的空间连续性锚点:沿用其背景世界、光线方向、材质氛围、产品比例节奏、反复出现的主题、配料或道具流动,以及过渡逻辑,同时扩展当前切片自身的结构。明确说明,该切片应让人感觉是同一套长滚动页面系统中某个区域的详细扩展,而不是一张独立海报。
使用分阶段生成检查。生成前 2 个切片后,将它们拼接成小型预览并进行检查。将已批准的 1:3 母版、两个单独切片、2 切片预览和简明审核意见一并作为第二次确认包呈现。只有在用户确认该确认包后,才生成剩余切片。如果早期预览存在内部问题,请在呈现确认包前修改 1:3 母版或受影响切片的提示词;只有在已批准的叙事本身有问题时,才返回修改蓝图。
-
准备拆分交付或长图拼接 如果用户希望获得多张独立图片,请将它们作为同一长滚动页面的连续切片交付。如果用户希望获得一张长图,请按顺序拼接这些切片。确保共享背景、光照、产品标识、反复出现的视觉元素、字体系统、间距节奏和过渡效果保持一致。除非用户明确要求海报风格的输出,否则不要将每个部分都做成独立的社交媒体海报。确保整组图片中的产品标识一致,并避免改变可见的产品颜色、形状、品牌标志或独特部件。
逐张生成独立图片时,不要只依赖“接续上一张切片”这类纯文本说明。缺少前后视觉上下文的切片通常会重置为完整、独立的构图。要实现真正的连续性,请在可用时使用项目的长滚动工作流:创建结构蓝图,构建 9:21 切片提示词,使用明确的边缘锚点按顺序生成切片,拼接预览图,然后修订顶部或底部边缘未能衔接的切片。如果生成工具支持图像参考或扩图,请将上一张切片的底部和下一张切片的规划作为当前切片的视觉上下文。
-
审核结果
生成后,检查结果是否呈现为一张连续的电商详情页。同时检查产品是否出现偏移、文字是否变得乱码、布局层级是否失效,以及是否出现未经支持的参数、认证或声明。在建议再次生成之前,给出具体的修订建议。
连续性审核必须在两个时间点检查拼接预览:前 2 张切片生成后的早期预览,以及整组切片全部生成后的最终预览。如果每张切片都重复完整的海报结构、重新以居中的主视觉场景开篇、以相同尺寸重复相同的主要视觉元素、使用相同的标题/标签模块,或缺少可见的顶部/底部衔接,则判定结果不合格。合格的切片应看起来像同一张长页面中相邻的部分,共享空间逻辑和边缘视觉元素,同时保持信息密度多样。
对生成的 1:3 母版,在继续之前先检查图像。确认其中是否包含预期的文字模块或预留的文字区域、整体是否像一张长详情页而非多个独立场景的堆叠、重复的主要视觉元素是否得到控制而非机械复制,以及规划中的各部分是否可以映射到母版上。如果这些检查未通过,请在创建 9:21 切片之前重新生成 1:3 母版。
将修订限定在最小的责任层级,不要默认重新生成整组图片:
- 文案或措辞问题:修订
text_exact,并仅重新生成受影响的切片或修复其中的文字区域。 - 产品标识、方向、颜色、形状、徽标或部件问题:加强产品参考约束,并仅重新生成受影响的切片。
- 单屏层级或杂乱问题:修订该屏幕的
primary_module、secondary_modules、content_density、copy_structure_pattern或hierarchy_strategy。 - 相邻屏幕的过渡问题:修订受影响的两个边缘锚点,并重新生成范围最小的相邻切片。
- 多个屏幕的视觉语法重复:修订这些屏幕的
composition_shift;保留已批准的叙事和不受影响的屏幕。 - 整页风格或空间连续性问题:修订文字母版或 1:3 母版,然后尽可能只重新生成受更改影响的切片。
- 整页叙事或声明种子问题:返回页面蓝图。只有在已批准的故事发生重大变化时,才重新生成全部内容。
- 文案或措辞问题:修订
-
交付图片组 生成、修改和最终审核完成后,直接保存已批准的图片集,无需另设目标位置确认步骤。如果用户已提供目标位置,请使用该位置。否则,请在当前工作区下创建一个名称清晰的交付文件夹,例如
outputs/product-detail-page/<product-name>-<timestamp>/。如果没有可用的工作区,请在工作源素材旁边或当前工作目录中创建交付文件夹。保留原始生成文件。请交付完整的图片集,而不只是预览图:使用过的已批准 1:3 主图、所有最终单张切片(使用清晰的顺序文件名)、早期的 2 张切片拼接预览、全分辨率最终长图拼接图,以及视情况提供的轻量版拼接预览。除非用户明确要求查看所有迭代版本,否则不要包含已拒绝或已被替代的版本。
请确认交付文件夹中存在所有用户要求的文件。最后,报告交付文件夹路径和简短的完成状态,以便用户打开文件夹查看图片。生成完成后,不要再让用户选择保存路径。使用清晰的名称,例如
product_master_1x3.png、product_screen_01.png至product_screen_08.png、product_first3_preview.png和product_full_long.png。
页面原则
- 首屏要回答:这是什么、适合谁,以及它为何与当下相关?
- 优先使用具体的功能描述,而非含糊的形容词。
- 通过示例、参数、截图、对比和工作流建立可信度。
- 避免嵌套卡片、装饰性图形、通用渐变,以及掩盖实际产品的主视觉区。
- 标题大小应与容器相称;不要在紧凑面板中使用主视觉区级别的大字。
- 为标签页、工具栏、媒体框架、网格、计数器和功能卡片等固定格式 UI 使用稳定的尺寸。
- 将移动端视为完整页面,而不是事后压缩的桌面版。
内容检查清单
- 用户一进入页面就能看到产品名称和类别。
- 主要 CTA 与用户预期的业务目标或工作流目标相符。
- 功能描述具体到可测试或可识别。
- 按用户的决策流程安排版块,而不是按内部功能清单排列。
- 技术声明在需要时应注明限制、假设或使用场景。
- 页面应包含足够多的具体示例,让新访客能够理解产品。
- 对于以图片为主的电商页面,生成的规格、认证、折扣、奖项和实测参数应由用户提供,或明确标记为待替换的占位内容。
实施检查清单
- 添加新的抽象结构前,先检查现有组件、路由和样式。
- 使用能展示产品、产出、工作流或真实主题的素材。
- 确认图片、视频、画布或生成的视觉内容能够正确渲染。
- 至少检查一个桌面视口和一个移动视口,确认没有溢出或重叠。
- 如果项目提供构建、lint 或测试工具,且改动范围适合运行,请执行。
- 报告用户可以打开的本地 URL 或文件路径。
参考资料
选择版块模式、针对特定产品类别调整此技能,或检查页面结构是否完整时,请阅读 references/detail-page-patterns.md。