文档转原型系统Skill：投标文档一键生成Vue3可运行原型

文档转原型系统Skill：把投标文档和需求规格书变成可点击、能走通业务的原型系统

核心结论速览

它是什么：一个名为 doc-to-prototype 的 AI 技能，输入 docx/pdf/xlsx/md 格式的项目早期文档（技术要求和投标文档、需求规格说明书等），输出可运行的 Vue3 Web 原型系统。
它怎么工作：走一条六阶段流水线——文档解析 → 领域识别 → 需求抽取（人工确认①）→ 原型规划（人工确认②）→ 生成 Vue3 原型 → 本地预览交付，中间产物全部写入文件，可审计、可局部重跑。
它强在哪：每一条需求都带章节号与原文摘录溯源，每个业务页面底部有溯源标记，未覆盖的功能必须写进交付说明，不隐瞒。
它适合谁：投标前需要做可点击演示的售前和方案团队、评审前要把文字需求变成界面的需求分析师、以及需要快速对齐认知的项目经理与甲方。
它的底线：原型必须真可操作（CRUD、搜索、分页、状态流转生效并持久化），模拟数据必须有真实感，校验脚本 0 error 且构建成功才允许交付。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

基础信息

项目	内容
中文名	文档转原型系统Skill
英文名	doc-to-prototype
技能ID	2117902381071613953
技能类型	面向研发与售前场景的流程型智能体技能（agent_created: true）
输入	docx / pdf / xlsx / md / txt 项目文档
输出	可直接运行的 Vue3 + Vite + Element Plus + ECharts 原型系统

它解决什么问题

在项目早期，最“贵”的一件事不是写代码，而是把文字需求翻译成所有人能看懂、能点、能走通流程的东西。技术投标文档往往是几十上百页的条目式描述，需求规格说明书常常带着含糊与前后矛盾；等到开发团队真正把界面做出来，往往已经过去几周，评审会上才发现“我们理解的和你理解的不是一回事”。

这个技能要解决的问题就是：让文档直接成为演示系统。你把文档交给它，它按流水线把文档拆成结构化的需求清单和原型规划，再生成一套可以点击、可以增删改查、可以走状态流转的 Web 原型，并附上一份“文档章节 ↔ 模块”的覆盖对照表。这样，评审会讨论的是界面和流程，而不是想象。

“一键安装”AI 技能的思路

“一键安装”的本质，是把一整套复杂的工程流程（解析、抽取、规划、编码、校验、交付）封装成一个可被 AI 助手直接调用的技能包；你不需要自己搭脚手架，也不需要背提示词工程，只需要安装后在对话里上传文档。

一般步骤如下（具体安装入口与命令以官方说明为准）：

准备前提：一个支持 AI 技能（Skill）机制的 AI 助手或开发环境；本机具备 Python 与 Node.js 运行环境，因为后续需要执行解析脚本与 npm install && npm run build。
找到技能：在技能市场或技能管理入口中，用技能ID 2117902381071613953 或英文名 doc-to-prototype 检索。
完成安装：点击安装/添加到工作区，等待技能包（包含 scripts、references、assets 模板目录）加载完成。
验证是否生效：新建一个会话，上传一份 docx 或 pdf 技术文档，然后输入类似“根据这份技术要求做一个原型系统”的请求。若技能生效，你会看到它按“文档解析 → 领域识别 → 需求抽取 → 确认① → 原型规划 → 确认② → 代码生成 → 交付演示”的顺序推进，并在工作目录下生成 .pipeline/ 中间产物目录。
首次运行的小提示：如果解析脚本报依赖缺失，按脚本提示执行 python -m pip install python-docx pymupdf 即可（这是技能内已明确的前置依赖）。

2. 该技能的主要功能和特点

多格式文档解析：内置 docx（scripts/parse_docx.py）、pdf（scripts/parse_pdf.py，页数多时可用 --pages 1-30 分段解析）解析脚本；xlsx 需求清单走 sheetagent 读取，md/txt 直接读取。
解析质量不静默跳过：输出末尾若出现扫描页或内容过少警告，技能被要求按警告指引处理——提示 OCR、多模态识读补充、或记入 openQuestions，而不是悄悄略过。这一点直接决定了原型会不会“莫名少一个模块”。
领域识别驱动专业性：先判定文档所属领域，再完整加载对应领域知识文件。航天业务类（型号、试验、总装、质量、生产、供应链、设备、工艺等）加载 references/domains/aerospace.md，其他或无法判定则加载 generic.md，后续全程参考其模块布局、角色模型、术语表与数据实体模板。遇到真实型号名、单位名、基地名或疑似涉密参数时，按领域文件中的合规要求做脱敏替换。
需求全过程溯源：抽取出的 roles / modules / features / workflows / entities，每一条都带 source（章节号与原文摘录）；文档含糊或矛盾的地方写入 openQuestions，不擅自决定。
两个人工确认关卡：S3 需求抽取后确认①，S4 原型规划后确认②。用户可以增删改模块、调整优先级、确认演示深度，确认后冻结 JSON 再往下走。当用户明确说“全自动/直接生成”时可跳过。
三级演示深度可选：L1 静态导航、L2 交互 CRUD（默认）、L3 角色仿真（含登录与权限差异），按评审需要选择投入。
视觉先规划再写代码：不是直接套模板。要求用“两遍法”先从领域推导色板、排印、布局和设计原则，写入 designTokens，再对照反模板脸清单自查；最终落到 styles.css 的 :root CSS 变量与 config.js，页面只引用变量、不硬编码色值。
开箱即用的原型模板：assets/prototype-template/ 已内置 Vue3 + Vite + Element Plus + ECharts，以及 localStorage 数据引擎和 CrudTable、FormDialog、StatCard、ChartBox、FlowTimeline、TraceFooter 等组件，复用而非重写基础设施。
真实感中文模拟数据：遵循 references/mock-data-guide.md 与领域术语表，明确禁止“测试1/abc/xxx”这类占位垃圾数据。
可断点、可局部重跑：各阶段产物保存在 <workdir>/.pipeline/，任何阶段失败只重跑该阶段；迭代修改时改 JSON 中间产物对应条目，只重新生成受影响页面。
强制质量校验：每批页面生成后运行 python scripts/validate_prototype.py <workdir>/prototype，修复全部 error 才继续下一批；全部完成后必须 npm install && npm run build 验证可构建，validate 0 error 且构建成功才允许交付。

和普通工具相比强在哪？普通 AI 编码助手是“你描述、它写代码”，缺的是流程约束与可审计性；低代码平台是“你拖控件、它存配置”，缺的是文档到需求的自动翻译。这个技能把三件事绑在了一起：文档溯源、结构化中间产物、可运行的成品。

3. 如何使用该技能？

步骤 1：上传文档并明确诉求

在对话中上传技术文档，并用一句话说明目标，例如：

“这是我们的投标技术方案，帮我根据文档做个原型系统，演示深度到 L2 就行。”

技能由“上传项目文档并希望根据技术要求做个原型 / 文档转原型系统 / 快速搭建演示系统 / 做个原型看看效果”这类表达触发。

步骤 2：等待 S1 文档解析

技能会调用解析脚本把文档转为 Markdown，例如：

python scripts/parse_docx.py 技术方案.docx -o tech.md
python scripts/parse_pdf.py 需求规格.pdf -o req.md --pages 1-30

如果输出末尾出现扫描页警告，请配合确认是否需要 OCR 或多模态识读补充，或同意将其记入 openQuestions。

步骤 3：确认领域判定（S2）

技能会告诉你它判定为哪个领域（例如航天业务或其他）。如果判错，直接纠正，它会更换加载的领域知识文件。

步骤 4：人工确认点① —— 需求清单

它会展示模块清单（含优先级）、角色、数据实体和 openQuestions。你需要做的是：

删掉与本次演示无关的模块；
调整优先级（文档功能过多时，高优先级模块优先覆盖）；
补齐角色（例如“评审专家只读”“业务员可编辑”）；
回应 openQuestions，或明确允许先按假设推进。

确认后 requirements.json 冻结。

步骤 5：人工确认点② —— 原型规划与设计令牌

它会展示页面清单、导航结构（可能用 show_widget 画站点地图）和设计令牌摘要（主色、排印、布局原则）。此时可调整页面粒度和演示深度（L1/L2/L3）。确认后 prototype-plan.json 冻结。

步骤 6：生成代码

技能按“设计令牌 → 种子数据 → seed-index 注册 → 路由 → nav 导航 → traceability 对照数据 → 分批生成页面视图”的顺序推进，每批完成后自动跑 validate，最后执行 npm install && npm run build 验证。

步骤 7：本地预览与交付

npm run dev 启动后，通过 present_files 打开 http://127.0.0.1:5173 预览。同时你会拿到一份交付说明，包含：

模块与文档章节的覆盖对照；
未覆盖项与 openQuestions 清单；
演示操作指引（哪些流程能走通、数据存在哪、如何重置）。

输入输出小示例

假设文档中有“设备巡检管理”章节，要求“巡检计划可按周期生成、异常需上报并流转审批”。生成后的原型中，你会看到巡检计划列表页（支持搜索、分页、新增）、巡检记录表单（弹窗式 FormDialog）、异常上报后的状态流转时间线（FlowTimeline），页面底部还有一个溯源标记 <TraceFooter :chapters="['4.1','4.2']"/>，提醒评审者这段界面对应文档哪一节。

步骤 8：迭代修改

评审后要改功能，不要重来。改 .pipeline/ 里对应 JSON 条目 → 只重新生成受影响页面 → validate → 刷新预览即可。需要在线分享时，可走 sites 发布流程（build 产物为纯静态）。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
文档转原型系统Skill（doc-to-prototype）	文档驱动的原型流水线	文档解析、领域识别、需求抽取带溯源、两阶段人工确认、生成可运行 Vue3 原型、需求追溯与未覆盖项标记	需在支持技能的平台安装；本机需 Python 与 Node.js；学习成本主要在两个确认点上	投标演示、需求评审、方案对齐	优势：溯源完整、中间产物可审计、可局部重跑、视觉由领域推导。不足：依赖文档质量，扫描件需 OCR 补充，功能极多的文档需做优先级取舍
通用 AI 编码助手（对话式生成前端）	自然语言写代码	根据描述生成页面与组件代码	门槛低，装好即用	单页面、小工具、快速试错	优势：灵活、上手快。不足：无文档解析与需求溯源，多页系统容易前后不一致，缺少校验关卡，改一处可能牵动全局
低代码/零代码平台	可视化拖拽搭建	表单、流程、报表配置化	门槛最低，但需要人工把文档翻译成配置	内部管理系统、标准业务流程	优势：稳定、可维护、有运行时。不足：文档到配置全靠人读，几十页投标文档的翻译工作量巨大；视觉容易千篇一律
原型设计工具 + 人工绘制	静态高保真原型	画界面、连线、做交互演示	需要设计师时间投入	视觉评审、交互确认	优势：视觉可控、精细。不足：通常不可真操作（无真实 CRUD 与数据持久化），演示时“点不动”，且与后续开发脱节

选择建议：如果你手上是一份几十页的文档，目标是一周内做出能走通业务的演示，且需要向评审方解释“这个功能对应文档第几节”，那么本技能的匹配度最高；如果只是做一个单页小工具或纯视觉稿，通用 AI 助手或原型工具更轻。

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

场景一：售前与投标团队的技术方案演示

角色：售前工程师、方案经理。痛点：投标截止前时间紧，投标文件里写了“支持设备全生命周期管理”“支持质量追溯”等大量条目，但评委看不到系统长什么样，只能看纸。

使用方式：上传投标技术部分，选择 L2 交互 CRUD，确认模块清单时优先保留评分点相关的模块（如设备台账、巡检、异常闭环），生成后在演示现场按流程点一遍。

实际体验：上手难度低，主要工作在确认①和确认②两处，通常一次确认加一到两轮微调即可成形。注意事项：文档里的评分点如果分散在多个章节，建议在确认①时手动把它们拉成高优先级模块，否则容易被“功能过多”的取舍规则排到后面。

场景二：需求评审前把文字变成界面

角色：需求分析师、产品经理。痛点：需求规格说明书里“支持多角色审批”“异常自动升级”这类描述，不同人理解不同，评审会开成辩论会。

使用方式：上传需求规格说明书，深度选 L3 角色仿真，让不同角色看到不同的菜单和权限差异，评审时现场切换角色演示。

实际体验：效果最明显的是“含糊点提前暴露”。技能会把矛盾与含糊写进 openQuestions，比如文中一处说“三级审批”、另一处说“两级审批”，你会在确认①就发现，而不是在开发阶段。注意事项：openQuestions 需要你给出结论，技能不会替你决定。

场景三：甲方与乙方对齐认知

角色：项目经理、甲方业务负责人。痛点：“我要的不是这个感觉”是最贵的一句话。

使用方式：生成后直接本地预览（http://127.0.0.1:5173），让业务方自己点、自己填数据。因为数据存在 localStorage，随便折腾也不会污染任何环境。

实际体验：真实感的中文模拟数据在这里很关键——业务方看到的是“某型号总装工序”“某批次质量异常”这类术语，而不是“测试1”，反馈质量会完全不同。注意事项：原型定位是演示与对齐，不是生产系统，别让它承担真实数据存储的期待。

场景四：开发团队的起步脚手架

角色：前端开发、技术负责人。痛点：从零搭路由、导航、CRUD 组件很费时间，且每个项目都要重复一次。

使用方式：把生成的 prototype/ 目录当作起点，模板已内置 Vue3 + Vite + Element Plus + ECharts、localStorage 数据引擎和一套通用组件，领域特有的重型组件（例如三维仿真场景）再按项目新建到 components/。

实际体验：省下的是“基础设施时间”，页面底部的 TraceFooter 还能当作开发阶段的对照清单。注意事项：原型侧重于快速呈现与业务对齐，生产化时仍需替换数据层、补充鉴权与工程规范。

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

效率价值：把“读文档—整理需求—画页面—写前端—自测”这条链路压缩成一次流水线执行，其中两个确认点是最需要人判断的地方，其余环节交给技能。对于几十页的技术文档，最大的节省不是敲代码的时间，而是需求梳理与返工的时间。

质量价值：结构化的中间产物（requirements.json、prototype-plan.json）让整个过程可审计——每一条需求都能回到文档章节和原文摘录；未覆盖的功能必须写进交付说明，不允许隐瞒；validate 脚本 0 error 与构建成功是硬性交付门槛。

沟通价值：把“形容词级需求”变成“可点击的界面”。评审会上讨论的从“我理解应该是……”变成“这个按钮点了之后应该到哪一步”，争议的解决成本显著下降。

复用与长期价值：模板、领域知识文件与流水线产物都可沉淀。同一领域第二次做原型时，领域术语表、角色模型、组件库都已就绪；改需求时只重跑受影响页面，而不是推倒重来。

门槛降低：不需要会 Vue，也能拿到一个能跑的前端原型；不需要写复杂的提示词，技能本身已经把流程和质量关卡定义好了。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认真的生效了？

在支持 AI 技能机制的平台中，通过技能ID 2117902381071613953 或英文名 doc-to-prototype 检索并安装（具体入口与安装方式以官方说明为准）。验证方法：新建会话上传一份 docx 或 pdf 文档，输入“根据这份文档做个原型”，若能观察到它按“解析 → 领域识别 → 需求抽取 → 确认 → 规划 → 确认 → 代码生成 → 交付”的阶段推进，并在工作目录生成 .pipeline/ 中间产物，说明已生效。首次运行若提示依赖缺失，执行 python -m pip install python-docx pymupdf。

Q2：收费吗？生成的原型版权归谁？

技能详情中未涉及定价与授权条款，具体是否收费、如何计费以及生成产物的使用范围，请以官方说明为准。从技术实现看，生成物是标准的 Vue3 工程目录，属于纯静态可构建产物，可在本地运行与部署。

Q3：适合谁用？不适合谁用？

适合：售前与投标团队、需求分析师与产品经理、需要快速对齐认知的项目经理，以及想省下前端脚手架时间的开发团队。不太适合：需要生产级系统（鉴权、并发、真实数据库、审计合规）的场景；也要求使用者至少愿意在两个确认点上做判断——如果你完全不想看需求清单，直接把原型拿去投标，风险在于未覆盖项你可能没注意到。

Q4：为什么它要做两个“人工确认”，能不能全自动？

确认①冻结需求清单（模块、角色、实体、openQuestions），确认②冻结页面规划与设计令牌。这两个点决定了后面所有代码的方向，越晚改成本越高。如果你明确要求“全自动/直接生成”，技能支持跳过确认直接产出，但建议至少在交付说明里认真看一遍“未覆盖项”清单。

Q5：和低代码平台、通用 AI 编码助手应该怎么选？

看你的起点是“文档”还是“想法”。起点是几十页技术文档、且需要解释每个功能对应文档哪一节——选本技能；起点是明确的小工具想法、只需要几个页面——通用 AI 编码助手更快；起点是标准化的内部管理流程、要长期维护——低代码平台更稳。三者也可以串联：用本技能把文档变成可点击原型完成评审，再用低代码或正式开发承接落地。