日常工作知识库

Appearance

高保真 PRD2Prototype 技能方案与自动化验证流程 ​

归类：工具 / 技能 / 工作流 适用对象：产品经理、项目负责人、设计协同、前端工程 状态：✅ 已形成技能、工作流、原型壳与自动化验证闭环

一、目标是什么 ​

高保真 PRD2Prototype 的目标，不是把需求文档转换成几张静态页面，而是生成一个：

  • 可运行
  • 可演示
  • 可迭代
  • 可自动验证
  • 可跨版本查看

的产品原型工程。

这类原型工程更适合用于：

  • PRD 评审
  • 版本方案演示
  • UI 与交互对齐
  • 下一轮产品设计迭代

二、方案框架 ​

这套方案由 5 层组成：

  1. 输入层：PRD / SDD / Speckit / API 契约 / 截图 / 在线地址
  2. 锚定层：选择真实前端仓库作为高保真标准
  3. 盘点层：先自动盘点页面并做页面分型
  4. 原型层：把结果落到统一 prototype shell
  5. 闭环层：通过 Cybervisor 或 workflow 做持续修正
  6. 验证层：每次更新后自动 build，必要时自动 dev
mermaid
flowchart LR
  A["PRD / SDD / Speckit"] --> B["Anchor Repo"]
  B --> C["Prototype Shell"]
  C --> D["Mock Contracts"]
  D --> E["Build / Review / Fix"]
  E --> F["Auto Validation"]
  F --> G["PM Demo & Next Iteration"]

三、当前工作区里的角色分工 ​

在 SPM 工作区里，推荐的职责分工是：

  • spm-management：真实管理端锚点
  • spm_mobile：移动端锚点
  • spm-workbencn_pc：PC 工作台锚点
  • spm-proto：统一 prototype 承载工程
  • spm-cybervisor：高保真 prd2prototype 技能与 pipeline 中枢

四、什么时候用 workflow，什么时候用 skill ​

1. 直接看现成原型 ​

如果只是想打开已经生成好的原型工程，不需要先跑 workflow。

在工作区根目录直接执行：

bash
cd /Users/jinqicheng/Desktop/58work/working/202604/spm-ops
./start-prototype.sh

2. 根据新需求继续生成或更新原型 ​

如果要让 AI 基于新的 PRD / SDD / Speckit 更新原型工程，就应该使用：

  • spm-proto 内部 workflow
  • 或通用 skill prd2prototype-cybervisor

推荐顺序：

  1. 团队内部在当前工作区直接走 workflow
  2. 需要跨 IDE / 跨终端复用时，安装 skill

五、如何安装 skill ​

进入技能仓库执行：

bash
cd /Users/jinqicheng/Desktop/58work/working/202604/spm-ops/spm-cybervisor
python3 skills/prd2prototype-cybervisor/scripts/install_skill.py --force

安装后，这个 skill 可以在支持本地技能目录的 AI 终端或 IDE 中复用。

六、如何使用 skill / workflow ​

workflow 方式 ​

入口：

  • spm-proto/.agent/workflows/prd-to-prototype.md
  • spm-proto/.agent/workflows/high-fidelity-prd-to-prototype.md

适合：

  • 当前就在 SPM 工作区里协作
  • 想复用已有原型壳和版本注册机制

skill 方式 ​

入口：

  • spm-cybervisor/skills/prd2prototype-cybervisor/SKILL.md

适合：

  • 需要跨终端复用
  • 希望把原型生成能力从单个仓库的 workflow 中抽出来

七、自动化验证现在怎么执行 ​

这是这次方案里非常关键的一点：

更新原型后，不能只停在“代码已经生成”，而必须自动做运行验证。

当前约束已经升级为：

  • 默认自动执行 npm run build
  • 如果显式配置为 post_update_validation: "dev"，则自动执行 npm run dev
  • 验证失败不能直接结束，必须继续修正或明确记录 blocker

默认模式 ​

json
{
  "post_update_validation": "build"
}

含义：

  • 每次更新原型后，自动构建校验
  • 最适合 CI / 稳定批处理 / 非交互场景

自动启动模式 ​

json
{
  "post_update_validation": "dev"
}

含义：

  • 每次更新原型后，自动拉起开发服务器
  • 适合产品或设计同学立即查看页面效果

八、页面盘点与分型为什么应该属于 skill ​

当锚点仓库是 spm-management 这种中大型前端工程时，技能不应该直接跳到“逐页生成”。

更合理的默认步骤是：

  1. 先盘点页面总量
  2. 自动按页面类型分组
  3. 标记复杂度
  4. 区分哪些适合批量高保真迁移，哪些需要人工 review

这一步已经适合做成 skill 内建能力，而不是人工临时分析。它的作用不是替代原型生成，而是给后续的批量迁移建立可靠清单。

九、skill 与 dev server 的最佳边界 ​

最佳设计不是把“能不能自动启动 dev server”当成 skill 是否成功的唯一标准。

更通用的设计应该是：

  • skill 本体负责：理解需求、盘点页面、生成原型、执行自动验证、输出 artifacts
  • dev server 负责：作为可配置的后处理动作，服务于本地演示场景

因此推荐默认值仍然是：

json
{
  "post_update_validation": "build"
}

只有在明确需要“更新后立即演示”的场景下，再切换到：

json
{
  "post_update_validation": "dev"
}

十、Cybervisor 流程现在建议怎么走 ​

当前更推荐的长任务流程是：

mermaid
flowchart TD
  A["Discover Context"] --> B["Review Context"]
  B --> C["Build Prototype"]
  C --> D["Validate Workspace"]
  D -->|失败| C
  D -->|通过| E["Review Fidelity"]
  E -->|未达标| C
  E -->|达标| F["Browser Calibration"]
  F --> G["Verify Demo"]

这里新增的 Validate Workspace 很关键，因为它把：

  • 代码生成
  • 工程是否能 build
  • 工程是否能 dev

这几件事分开了，避免出现“页面看起来写完了，但工程根本跑不起来”的假完成状态。

十一、当前 prototype shell 有哪些产品能力 ​

当前的 prototype shell 已经支持：

  • 顶部右侧“版本 + 页面”双切换
  • 同版本页面抽屉总览
  • 多版本 prototype 注册
  • 根目录一键启动脚本

这意味着后续生成新版本时，不只是多一个页面，而是会自动加入统一的版本导航体系。

十二、推荐的使用顺序 ​

如果明天要继续推进，推荐这样操作：

  1. 用 ./start-prototype.sh 启动当前 prototype
  2. 明确下一轮要锚定的真实页面或模块
  3. 安装或确认 prd2prototype-cybervisor skill 可用
  4. 准备 PRD / SDD / Speckit / API 契约
  5. 运行高保真 workflow 或 Cybervisor pipeline
  6. 看自动 build 或 auto-start 结果
  7. 根据 fidelity report 决定是否继续修正

十三、结论 ​

高保真 PRD2Prototype 真正有价值的地方，不在“生成页面”本身，而在于它已经开始具备工程化能力：

  • 有真实锚点
  • 有统一 shell
  • 有版本导航
  • 有自动化验证
  • 有闭环修正

这样生成出来的原型，才更接近“产品版本 Demo 工程”，而不是一次性的静态展示页。