screenshot-feature-extractor（屏幕截图分析器）Skill 是什么？如何下载安装？

屏幕截图分析器（多代理系统）Skill：一张截图，自动产出可执行的开发任务清单

它是什么：一个基于多代理协作的 AI 技能，把产品界面截图自动拆解成「UI 结构 + 交互流程 + 业务逻辑」，最终合成一份带复选框的开发任务清单。
核心差异：不是让一个大模型“看一眼截图说说有啥”，而是让 3 个分析代理并行拆解、1 个合成代理汇总、1 个审阅代理复核，共 5 个专职代理接力完成。
产出物明确：结果落到 docs/plans/YYYY-MM-DD-<产品>-features.md，可直接进需求池、进任务看板。
只谈“做什么”，不谈“怎么做”：输出聚焦特征与交互，不绑定技术栈，前端、后端、外包团队都能直接读懂。
最适合谁：产品经理、独立开发者、创业团队、接单外包方，以及需要做竞品拆解的人。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本身份信息

项目	内容
技能中文名	屏幕截图分析器（多代理系统）Skill
技能英文名	screenshot-feature-extractor
技能ID	12144
技能类型	多代理协作型分析技能
核心产出	结构化功能清单 / 开发任务清单（Markdown 复选清单）

它到底解决什么问题

假设你拿到竞品 App 的十几张截图，或者手上有一份 UI 设计稿，想把它们变成一份能直接开工的需求清单。传统做法是：人眼逐屏看 → 手动记录每个页面有什么控件 → 推测交互跳转 → 归纳业务实体 → 写成 PRD → 再拆成任务。这个流程有三个典型痛点：

耗时：一个中等复杂度的产品，逐屏拆解往往要花掉半天到一天。
容易漏：人眼对布局细节、状态切换、边界情况的记忆是有限的，第二遍看又会发现新东西。
视角单一：一个人写出来的需求文档，往往只覆盖自己熟悉的那一面——做前端的盯着组件，做业务的盯着功能，很难三者兼顾。

屏幕截图分析器（多代理系统）Skill 就是针对这三点设计的：用并行代理解决“慢”，用三个专业视角解决“漏”，用合成 + 审阅两道工序解决“乱”。

一键安装的思路与步骤

安装的核心逻辑是：在支持 AI 技能的客户端或市场中找到该技能 → 完成安装/启用 → 用一张截图验证是否生效。具体步骤如下：

确认前提：你的 AI 开发环境需要支持“技能（Skill）”机制，并且具备多模态读图能力（技能本身需要读取截图文件）与任务代理调度能力。若你的环境不支持代理调度，该技能的多代理流程将无法完整跑通。
定位技能：在技能市场/技能库中按技能 ID 12144 或英文名 screenshot-feature-extractor 搜索定位。具体的市场入口地址与检索方式以官方说明为准。
执行安装：按该环境的标准安装方式启用技能（不同客户端的安装入口和命令并不统一，以官方说明为准；此处不提供未经证实的命令）。
验证生效：准备一张产品截图，按第 3 部分的方式发起一次分析请求。若技能正常工作，你会看到它依次完成“三个并行分析 → 合成 → 审阅”，并最终生成 docs/plans/ 目录下的 Markdown 文件。只有能产出该文件，才算真正安装成功。
建立习惯：把“截图丢进去 → 拿任务清单”当成固定动作纳入日常工作流，安装价值才能体现出来。

该技能的主要功能和特点

五代理协作架构：一个协调器（技能本体）+ 三个并行分析代理（UI 分析器、交互分析器、业务分析器）+ 两个顺序执行代理（合成器、审阅器），职责清晰、互不重叠。
三视角并行拆解：同一张截图会被同时从“界面结构”“交互与状态”“业务与数据”三个维度读一遍，避免单一视角造成的遗漏。
并行提速：三个分析代理在同一条消息内并发调用，而不是排队串行，总耗时显著低于逐个分析。
合成输出统一任务清单：合成器把三份分析结果合并、去重、对齐成一份连贯的清单，而不是三份互不相干的报告拼在一起。
审阅兜底：审阅器会拿最终清单回看原始截图，检查完整性与质量，发现问题直接给出修正，相当于自带一道质检。
复选框任务格式：统一使用 - [ ] 格式，可直接粘贴进任务管理工具或 Markdown 看板。
需求颗粒度可控：要求把特征拆成“小、可执行”的子任务，而不是一句笼统的“做一个首页”。
只描述“做什么”：核心原则是描述要构建的特征与交互，不涉及技术栈与实现细节，因此对技术方案保持中立。
多截图去重与竞品对比：支持一次传入多张截图，跨屏重复特征会自动去重；用于竞争分析时会突出独特功能与能力差距。
落地到文件：结果不只在对话里展示，而是写入 docs/plans/YYYY-MM-DD-<产品>-features.md，天然融入工程仓库。

和普通工具比，它强在哪？普通多模态对话是“一次提问、一次回答”，看完就散；这个技能是“一条流水线”，有分工、有并行、有合并、有复核，并且强制把结果沉淀成仓库里的文件。这就是“聊一聊”和“出交付物”的区别。

如何使用该技能？

整体流程分五个阶段，下面是可直接参考的操作方法。

第一步：收集并准备截图

把要分析的截图整理到一个可访问的目录，记录每张截图的文件路径。
为每张截图附上你能提供的上下文（比如“这是支付流程的第 2 步”“这是后台管理页”）。
如果一次传多张，先判断它们是否来自同一产品——同一产品才适合合并成一份清单，跨产品则应当分开跑。

输入示例：三张截图，路径分别为 shots/home.png、shots/detail.png、shots/pay.png，上下文标注为“某电商 App 的浏览—详情—支付主链路”。

第二步：触发并行分析

向技能发起请求后，它会为每张截图并行启动三个分析代理：

UI 分析器：分析该截图的 UI 组件、布局结构与设计模式；
交互分析器：分析用户交互、导航流程与状态转换；
业务分析器：分析业务功能、数据实体与领域逻辑。

三个代理均以 JSON 格式返回分析结果。注意：三次调用应在同一条消息中并行发出，以最大化效率——这是该技能速度优势的来源，串行调用等于放弃了这个优势。

第三步：合成

并行分析全部完成后，合成器代理登场，把三份结果合成为统一的开发任务清单。此时需要把三份分析结果原样喂给它，并告知产品名称与输出路径。

调用示例（示意）：

UI 分析：[粘贴 UI 分析器结果]

交互分析：[粘贴交互分析器结果]

业务分析：[粘贴业务分析器结果]

产品名称：某电商 App

输出文件：docs/plans/2025-01-15-某电商App-features.md

第四步：审阅

合成完成后，审阅器代理会拿到“原始截图 + 任务清单”进行复核，检查清单的完整性与质量，发现问题即提供修正。建议不要跳过这一步——它是质量的下限保障。

第五步：输出与确认

最终任务清单写入 docs/plans/YYYY-MM-DD-<产品>-features.md；
格式遵循技能自带的输出格式参考文档；
技能会向用户呈现一份摘要，方便快速浏览。

输出示例（片段示意）

- [ ] 首页商品瀑布流
  - [ ] 展示商品图、标题、价格
  - [ ] 支持下拉刷新与上滑加载更多
- [ ] 商品详情页
  - [ ] 展示多图轮播与规格选择
  - [ ] 提供加入购物车与立即购买入口

拿到清单后，你可以直接把它贴进任务工具，或者按“小、可执行”的原则再切一刀。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
屏幕截图分析器（多代理系统）Skill	截图 → 结构化开发任务清单的专用流水线	三视角并行分析、合成、审阅、多截图去重、输出 Markdown 清单	需支持技能与代理调度的 AI 环境，安装入口以官方说明为准	竞品拆解、UI 稿转 PRD、批量分析、竞争分析	优势：有分工有质检，产出物可落地到仓库；不足：依赖支持代理调度的环境，简单单图需求略显重
通用多模态大模型对话	通用看图问答	上传截图后自由提问、自由输出	门槛最低，任何支持读图的对话产品即可	临时看一张图、快速了解某个界面	优势：零学习成本；不足：无固定流程、无审阅、无文件产出，多图时容易前后不一致
人工撰写 PRD / 需求文档	传统产品文档工作流	人工逐屏观察、归纳、撰写	无工具门槛，但人力成本高	需求复杂、需要深度业务判断的项目	优势：业务理解最深、可灵活取舍；不足：耗时长、易漏细节、视角单一、难以批量
传统 OCR / UI 组件识别工具	界面元素识别与还原	识别文字、控件位置、组件类型	工具成熟，通常按量或按账号计费，具体以各产品说明为准	设计稿标注、界面还原、自动化测试定位	优势：元素级精度高、结果结构化；不足：只回答“有什么元素”，不回答“这是什么功能、该怎么拆任务”，缺少交互与业务视角

一句话选型建议：要元素级坐标，选识别类工具；要能开工的任务清单，选这个技能；只是随手看一眼，直接用通用对话就够。

该技能的典型应用场景与实际体验情况

场景一：独立开发者做竞品拆解

角色与痛点：独立开发者想做一个垂直工具，手里有竞品 App 的十几张截图，但逐屏整理功能点太耗时间，往往拆到一半就失去耐心。
使用方式：把同一产品的截图批量传入，标注产品名，让技能跨屏去重后输出一份完整清单，再挑出“竞品有但我没做”的部分作为差异化切入点。
实际体验：三视角并行带来的直接感受是“看得比自己细”——布局细节、状态切换、数据实体都被分别记录，合成后能看出功能之间的依赖关系。上手难度低，关键是截图要清晰、上下文要标清楚。

场景二：产品经理从 UI 设计稿生成 PRD 与任务清单

角色与痛点：设计师交付了一套界面稿，产品经理需要把它翻译成开发能看懂的需求，中间隔着大量重复劳动。
使用方式：把设计稿逐屏导出为图片，作为截图输入，让技能直接产出任务清单初稿，产品经理在此基础上补充优先级、边界与业务规则。
实际体验：初稿的颗粒度比较统一，每条任务都自带复选框，省掉了“从零开始敲”的阶段。注意：技能刻意不涉及技术栈与实现细节，如果你需要技术方案，还得自己补一层。

场景三：团队批量分析多个应用做竞争分析

角色与痛点：团队要做竞品格局分析，需要横向对比四五款产品的功能覆盖度，人工做表极易变成“各写各的”。
使用方式：按产品分别跑一遍，每次只传同一产品的截图，让技能输出各自的任务清单；随后横向对照，重点看它标注出的独特功能与差距。
实际体验：因为流程固定、输出格式统一，横向对比变得很容易。注意事项：不要把所有产品的截图混在一次调用里，否则去重逻辑会把不同产品的功能误判为重复。

场景四：外包接单前的需求评估

角色与痛点：接单方拿到客户给的参考界面截图，需要快速估工期、报价格，但客户往往只有图、没有文档。
使用方式：把参考截图跑一遍，得到功能清单后逐条评估工作量，用清单本身作为与客户对齐范围的依据。
实际体验：最大价值是“把模糊的图变成可数的条目”，报价时更有底气。注意事项：清单是功能层面的描述，工作量仍需结合自身经验判断，不能直接等同于工期。

该技能能为用户带来的价值

效率层面：从“逐屏人工拆解 + 手写文档”变成“传图 → 拿清单”。并行分析让三份视角同时推进，合成与审阅则省掉了人工汇总校对的时间。原本需要数小时的整理工作，可压缩到一次流水线的执行时间内。

质量层面：三个专业视角 + 一道审阅兜底，显著降低了“漏功能、漏状态、漏数据实体”的概率。多截图场景下的跨屏去重，避免了同一功能在清单里出现三遍的尴尬。

门槛层面：不需要会写 PRD 模板，不需要懂设计规范，也不需要懂技术栈——把截图和产品名给到，就能拿到结构化的任务清单。这对非产品背景的独立开发者、刚入行的同学尤其友好。

长期价值：产出直接落到 docs/plans/ 目录，随代码仓库一起沉淀。日积月累，你会得到一个可回溯的产品演进档案：某天做了哪些功能、当时的拆解逻辑是什么样，全都留痕。任务清单使用统一复选框格式，天然可对接任务看板，进一步减少二次搬运成本。

常见问题 FAQ

Q1：这个技能到底怎么安装？安装后怎么确认真的生效了？ 按“在市场里检索技能 ID 12144 或英文名 → 按环境标准方式启用 → 用一张截图验证”的顺序操作。不同客户端的安装入口与命令并不统一，具体以官方说明为准。验证是否生效最直接的判断标准是：跑一次分析后，是否在 docs/plans/ 下生成了对应日期的 Markdown 文件。如果只有对话回复、没有文件产出，说明流程没有跑完整。

Q2：它收费吗？ 收取方式由提供该技能的平台决定，本技能详情中未包含定价信息，请以官方说明为准。

Q3：它适合谁用？不适合谁用？ 适合产品经理、独立开发者、创业团队、接单外包方，以及任何需要做竞品拆解和 UI 稿转需求的人。不太适合两类情况：一是只想随手看看某张图里有什么，用通用多模态对话更快；二是需要元素级坐标与像素级还原，那属于识别类工具的领域。

Q4：一次可以传多少张截图？多张会重复吗？ 技能支持传入多个截图，并会判断它们是否来自同一产品。对于多截图场景，它会跨屏对重复特征进行去重处理。建议：一次只传同一产品的截图；不同产品请分开跑，否则去重逻辑会干扰判断。

Q5：它和直接把截图丢给通用大模型聊天有什么区别？ 区别在“有没有流水线”。通用对话是一次提问一次回答，缺乏分工与复核；本技能是三个专职代理并行拆解、一个合成器汇总、一个审阅器复核，最后强制落地成仓库里的 Markdown 文件。而且它有一条明确的约束：只描述要构建什么（特征与交互），不描述怎么构建（不涉及技术栈），这保证了产出对任何技术团队都是可读的。