文档转原型系统Skill doc-to-prototype

名称	doc-to-prototype
描述	从项目早期文档（技术要求、投标文档、需求规格说明书等 docx/pdf/xlsx/md）快速搭建可运行的原型系统。当用户上传项目文档并希望“根据技术要求或投标文档做个原型”、“文档转原型系统”、“快速搭建演示系统”、“做个原型看看效果”时使用本技能。流水线：文档解析 → 领域识别 → 需求结构化（人工确认①）→ 原型规划（人工确认②）→ 生成 Vue3 可运行原型（含真实感中文模拟数据、需求追溯、未覆盖项标记）→ 本地预览交付。 agent_created: true

doc-to-prototype：技术文档 → 可操作原型系统

将技术文档（软件设计说明、投标技术部分、需求规格说明书等）转换为可操作演示的 Web 原型系统。核心价值：中间产物结构化（可审计、可局部重跑）、需求全程溯源、 领域知识驱动的专业文案与模拟数据。

触发场景

• 用户上传 docx/pdf 技术文档并要求生成原型或演示系统
• 投标前需要快速做出可点击、能走通业务流程的功能演示
• 需求评审前把文字需求变成看得见的界面

流水线总览

S1 文档解析 → S2 领域识别 → S3 需求抽取(requirements.json) → [确认①]
→ S4 原型规划(prototype-plan.json) → [确认②] → S5 代码生成 → S6 交付演示

执行原则：

1. 各阶段产物都保存到 <workdir>/.pipeline/，任何阶段失败只重跑该阶段，不整体重来。
2. 两个人工确认点（S3 后、S4 后）默认执行；用户明确要求“全自动/直接生成”时跳过。
3. 开工前完整阅读 references/workflow.md，其中含各阶段的输入、动作、产物与质量关卡。

各阶段要点与资源引用

S1 文档解析

• docx：python scripts/parse_docx.py <file> -o <out>.md
• pdf：python scripts/parse_pdf.py <file> -o <out>.md（页数多可 --pages 1-30 分段）
• xlsx 需求清单：改用 sheetagent 读取；md/txt 直接读取。
• 依赖缺失时按脚本提示执行 python -m pip install python-docx pymupdf。
• 输出末尾若出现扫描页或内容过少警告，必须按警告指引处理（提示 OCR、多模态识读 补充、或记入 openQuestions），不得静默跳过——否则原型会缺失对应功能。

S2 领域识别

判定文档所属领域并完整加载对应领域知识文件，后续全程参考其模块套路、角色模型、 术语表、数据实体模板与页面布局惯例：

• 航天业务（型号、试验、总装、质量、生产、供应链、设备、工艺等）→ references/domains/aerospace.md
• 其他领域或无法判定 → references/domains/generic.md

出现真实型号名、真实单位或基地名、或疑似涉密参数时，按 aerospace.md 的合规要求脱敏替换。

S3 需求抽取

按 references/schemas.md 中 requirements.json 的结构抽取 roles / modules / features / workflows / entities，每条带 source 溯源（章节号 + 原文摘录）；文档含糊或矛盾之处 写入 openQuestions，不擅自拍板。 → 人工确认点①：展示领域判定、模块清单（含优先级）、角色、实体、openQuestions， 用户增删改确认后冻结 requirements.json。

S4 原型规划

按 references/schemas.md 中 prototype-plan.json 的结构规划页面、导航、工作流，遵守其中 “页面类型→组件映射”与规划约束。视觉设计先规划再落码：完整阅读 references/ui-design-guide.md，用“两遍法”在 plan 的 designTokens 中定下从领域推导的 色板、排印、布局、设计原则，再对照反模板脸清单自查。与用户确认演示深度： L1 静态导航 / L2 交互 CRUD（默认） / L3 角色仿真（含登录与权限差异）。 → 人工确认点②：展示页面清单与导航结构（可用 show_widget 画站点地图）+ 设计令牌摘要， 确认后冻结。

S5 代码生成

1. 复制 assets/prototype-template/ 整目录到 <workdir>/prototype/。模板为 Vue3 + Vite + Element Plus + ECharts，已内置 localStorage 数据引擎与 CrudTable / FormDialog / StatCard / ChartBox / FlowTimeline / TraceFooter 组件。 复用内置组件与引擎，不重写基础设施；领域特有的重型组件（如航天仿真的 Three.js 三维场景）按项目新建到 components/。改动点清单见模板内 TEMPLATE-README.md。
2. 先落地设计令牌：把 plan 的 designTokens 写入 styles.css 的 :root CSS 变量 与 config.js，页面只引用变量、不硬编码色值（ui-design-guide.md 第 2 节）。
3. 生成顺序：设计令牌 → 种子数据（遵循 references/mock-data-guide.md）→ seed-index 注册 → 路由 → nav 导航 → traceability 对照数据 → 按模块分批生成页面视图。
4. 每批完成后运行 python scripts/validate_prototype.py <workdir>/prototype， 修复全部 error 再进行下一批；全部完成后 npm install && npm run build 验证可构建。
5. 自我批判（ui-design-guide.md 第 7 节）：关键页面截图回看，问“换个项目名这页 还成立吗”，改掉最通用的一处、删一个多余装饰再交付。

S6 交付演示

1. npm run dev 启动后用 present_files 呈现 http://127.0.0.1:5173 供预览。
2. 生成交付说明：模块↔文档章节覆盖对照、未覆盖项与 openQuestions、演示操作指引 （哪些流程能走通、数据存哪、如何重置）。
3. 用户要在线分享时走 sites 发布流程（build 产物为纯静态）。
4. 迭代修改：改 JSON 中间产物对应条目 → 只重新生成受影响页面 → validate → 刷新预览。

质量红线

• 页面必须真可操作：L2 起 CRUD、搜索、分页、状态流转均真实生效并持久化。
• 演示数据必须有真实感：禁止“测试1/abc/xxx”，遵循 mock-data-guide.md 与领域术语表。
• 视觉必须扎根本项目：遵循 ui-design-guide.md，色板、排印、布局由领域推导并落到设计令牌， 不套用“任何项目都长一样”的默认模板脸；首页以系统最有特征性的内容开场。
• 界面文案用文档原文术语与用户语言，同一动作全流程同名，空态与报错给方向不给情绪。
• 每个业务页面底部放 <TraceFooter :chapters="['3.2']"/> 溯源标记。
• validate 脚本 0 error 且 npm run build 成功后才可交付。
• 文档功能过多时优先覆盖高优先级模块，未覆盖项必须在交付说明中列明，不得隐瞒。