PRD 转可运行 Demo

要解决什么问题

很多团队写完 PRD 之后，落地代码往往变成「目录很全、跑不起来」的脚手架：前后端路由对不上、状态名各写各的、SQL 审查被跳过，Demo 无法证明核心链路。prd-demo-optimized 的目标是把 PRD 转成能跑通的垂直切片，而不是堆文件数量。

技能如何工作

使用前需确认（缺省可推断）：PRD 路径、输出目录（默认 /-demo）、范围 quick / standard / complete。生成代码前以 references/codegen-guide.md 为契约来源（产品字段、状态机、API 路由、前后端文件映射、校验清单）；写后端时读 templates/backend-templates.md，写前端时读 templates/frontend-templates.md。

典型流程：

1. 解析 PRD，抽取产品名、用户、核心功能、意图、Agent/工具、状态、UI 组件、文件约束与错误文案等，并给出简短摘要供确认（除非用户要求直接开写）。
2. 优先后端：Mock LLM 调用保持本地且确定性；CSV/Excel 用 pandas/openpyxl 真实解析；SQL 在 SQLite 沙箱执行，并拒绝非只读语句。
3. 再生成前端：UI 与后端共用同一套状态机与路由契约。
4. 根目录与校验：README、.gitignore；complete 范围可加 docker-compose 与示例数据。交付前检查 Python 导入、FastAPI 可启动/可导入、TS 构建、前后端路由与状态名一致。

standard 范围包含完整后端模块、前端组件、Mock Agent 编排、Schema 查看、指标选择、SQL 审查、图表与报告查看；Demo 不得跳过 SQL 审查——用户必须能查看、编辑并执行生成的 SQL。

适用边界

• 默认 Mock LLM，不依赖外部 API Key。
• 依赖装不齐时仍会生成代码，但会说明校验受限。
• 偏好小文件、清晰结构，而非过度抽象；quick 会减文件数，但仍保留路由契约。