@aibyzero/byz 0.0.0 → 0.1.2

package/workflows/cm/skills/cm-frontend-engineer/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: cm-frontend-engineer
+description: 前端工程师 Skill，执行前端开发任务，自动适配项目技术栈（React/Vue/Svelte/Next.js 等），支持 Figma/Stitch 设计稿还原
+---
+
+# cm-frontend-engineer — 前端工程师
+
+执行前端开发任务。自动识别项目技术栈，遵循项目 `.claude/rules/` 中的规范。
+
+## 触发条件
+
+由 `/cm-ai` 自动调用，当 task 涉及前端开发时触发。
+
+**与 cm-ui-engineer 的分工**：feature 存在设计基准（design-baseline/）时，UI 还原由 `cm-ui-engineer` 前置完成——本 skill **直接消费其组件与 design.md 组件契约，不重写其样式**；无基准时按下方 Step 0 现有行为处理。
+
+## 工作流程
+
+### 0. 设计稿检查
+
+开发前先询问是否先实现设计稿：
+
+- **没有设计稿** → **主动询问用户**是否有设计稿地址（Figma/Stitch 链接），等待用户回复后再继续；用户确认没有设计稿则跳过，直接进入开发
+- **有 Figma 链接** → 调用 figma mcp
+- **有 Stitch 项目** → 调用 stitch mcp
+
+**设计稿与业务的关系：**
+
+- 设计稿存在且完整 → 按设计稿还原
+- 设计稿存在但不是明显的缺失 → 自行补全功能
+- 设计稿存在但与业务需求有明显差距或缺失页面 → **主动询问用户**是否需要先还原设计稿再开发功能，等待用户回复后再继续
+- 没有设计稿 → 根据 design.md 和业务需求自行实现
+
+### 1. 识别技术栈
+
+读取项目配置自动判断，不做硬编码假设：
+
+- `package.json` → 框架（React/Vue/Svelte/Next/Nuxt/Astro...）、UI 库、状态管理
+- `tsconfig.json` / `jsconfig.json` → TS/JS、路径别名
+- 样式方案 → Tailwind / CSS Modules / styled-components / UnoCSS 等
+- 构建工具 → Vite / Webpack / Turbopack / esbuild
+
+### 2. 读取上下文
+
+- `.claude/rules/frontend.md`、`.claude/rules/coding-style.md`（如存在）
+- design.md 中当前任务相关的模块设计
+- 扫描 `src/` 了解现有组件结构和命名规律
+- **重点扫描项目已有的 UI 组件库**（`components/ui/`、`components/common/` 等），了解哪些组件已封装可复用
+
+### 3. 开发
+
+**组件封装与复用（重要）：**
+
+- 开发前先检查项目已有的 UI 组件库，能复用的绝不重写
+- 新建通用 UI 组件时放入项目约定的公共组件目录，确保可被其他页面复用
+- 业务组件和 UI 组件分层：UI 组件不含业务逻辑，业务组件组合 UI 组件
+- 如果项目使用了第三方组件库（Ant Design/shadcn/Element/Radix 等），优先用库内组件，不自己造轮子
+
+**Tailwind CSS（如项目使用）：**
+
+- 检查 Tailwind 版本（v3 vs v4），全局样式封装方式不同：
+  - **v3**：`@layer base/components/utilities` + `@apply` 在 `globals.css` 中
+  - **v4**：CSS-first 配置，`@theme` 定义 design token，`@variant` 自定义变体
+- 复用样式通过组件封装而非到处复制 class 字符串
+- 主题色、间距、字体等通过 Tailwind config / CSS 变量统一管理，不硬编码具体值
+
+**组件开发：**
+
+- 遵循项目已有的组件模式（class/函数、选项式/组合式）
+- Props/类型定义跟随项目约定
+- 文件命名跟随项目已有规律
+
+**状态管理：**
+
+- 识别项目使用的方案（Redux/Zustand/Pinia/Vuex/Jotai...）
+- 简单局部状态用框架原生方案
+- 参考 design.md 中的状态流转设计
+
+**API 调用：**
+
+- 基于 design.md 中的接口契约
+- 后端未就绪 → 先写 mock，标注 `// TODO: replace mock when API ready`
+- 错误处理和 loading 状态
+
+**路由：**
+
+- 按 design.md 页面设计配置，遵循项目路由约定（file-based / config-based）
+
+### 4. 验证
+
+```bash
+# 根据项目实际命令执行
+npm run lint
+npm run typecheck
+npm run build
+```
+
+如有开发服务器，启动验证页面渲染正常。
+
+**像素级还原验证（如有设计稿）：**
+
+还原度不靠"看着像"，用 BackstopJS 做量化对比：
+
+1. 设计稿导出为参考图（或导出 HTML+CSS 作为基准页面）
+2. `npx backstop test` 对比还原页面与基准，生成差异报告
+3. 差异集中在特殊效果（渐变边框、复杂阴影）时评估修复成本，其余差异修复后复测
+4. 差异报告结果写入任务汇报，供 N6 QA 的可视化回归复用
+
+> 注意：不要让 MCP 直接"照着感觉"还原——先拿到设计稿源文件/导出物作为基准，再开发，再对比。
+
+## 常见坑
+
+| 问题                                    | 处理                                                     |
+| --------------------------------------- | -------------------------------------------------------- |
+| 路径别名导致 import 报错                | 检查 tsconfig paths 和构建工具配置是否一致               |
+| SSR/SSG 组件使用了 browser API          | 加 `typeof window !== 'undefined'` 或动态导入            |
+| 样式冲突                                | 优先用项目约定的作用域方案，避免全局样式                 |
+| 第三方库类型缺失                        | 检查 `@types/xxx`，必要时声明 `.d.ts`                    |
+| Tailwind v3 和 v4 混用                  | 检查版本，v4 不再用 `tailwind.config.js`，改用 CSS-first |
+| 组件重复造轮子                          | 开发前先搜索项目已有组件，grep 关键词                    |
+| 设计稿颜色/间距与 Tailwind token 不一致 | 扩展 theme 配置而非硬编码 hex 值                         |
+
+## 输出
+
+- 创建/修改的文件列表
+- 验证结果（lint + build）
+- 设计稿还原情况（如有设计稿）
+- 需要其他工种配合的事项

package/workflows/cm/skills/cm-idea/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: cm-idea
+description: 用户说“我有个点子”“帮我梳理产品”或需要先聊清目标时使用。通过逐题访谈整理为可交给 cm-prd 的 PRD；已有明确需求文档时改用 cm-prd，不写代码、不拆开发任务。
+---
+
+# cm-idea — 点子 → PRD（流程上游入口，非 N1–N8 步骤）
+
+先读取 `../../runtime/project-context.md`。Codex 入口为 `$cm-idea`；Claude Code 跨平台入口为 `/cm-idea`，macOS/Linux 另有历史别名 `/cm:idea`。
+
+用户明确要求外部专家，或为本次访谈开启 AUTO 时，先读取
+`../../runtime/external-expert.md` 并执行 `../external-expert/SKILL.md` 的任务路由。
+AUTO 只在复杂方案/材料综合时 CONSULT，需要权威事实时 VERIFY，其余 LOCAL。外部
+结果只作为访谈输入，不能替用户确认产品方向；没有明确请求，也没有本次 AUTO 授权
+时，保持原来的纯对话、不联网流程。
+
+**用法**：`$cm-idea 一句话点子`（如 `$cm-idea 我想做个帮宝妈记录辅食的小程序`）
+
+把模糊想法聊成成熟 PRD 的产品访谈搭档。**本命令只做一件事**：加载 `references/idea-to-prd.md` 并严格按其规则执行——本文件不复制不改写访谈规则，该引用文件是唯一事实源。
+
+## 执行
+
+1. 读取 `references/idea-to-prd.md`，缺失则提示重装最新包后中止
+2. 把 `用户本轮输入` 作为用户点子，进入技能的访谈流程（判定产品类型 → 一次一题 → L1 骨架 → 按用户节奏加深；涉及交易/Web3 自动加载 `references/domains/trading.md` 领域包）
+3. 全程遵守技能自身纪律（一次一题、防诱导选项、狠收敛、纯对话不联网）
+
+## 与 cm 流程的衔接（只提示，不自动执行）
+
+PRD 聊到用户满意收尾时，**追加一段提示**（这是本命令相对裸技能唯一的增量）：
+
+```text
+📄 PRD 已保存: {路径}(成熟度 {L1/L2/L3},「待明确的问题」剩 {N} 条(口径:只数 PRD 第 7 节的条目,正文散落的待补标记不计;路径用绝对路径)——带着未决问题交棒,prd 的产品角色会重新追问;想少被问就先在这里加深)
+下一步(需要你手动执行,本命令不代跑):
+  1. 建 specs 文件夹,把这份 PRD 放进 docs/
+  2. $cm-prd {specs路径}   ← 拆成规格三件套
+  3. 人审摘要卡后 $cm-ai 开始开发
+```
+
+## 边界
+
+- 不写代码、不拆任务、不调 $cm-prd——想法阶段结束就交棒
+- 已有现成需求文档的项目不需要本命令，直接 `$cm-prd`
+- 触发词自然唤起（"我有个点子…"）与本命令等效，习惯哪个用哪个

package/workflows/cm/skills/cm-idea/references/domains/trading.md

@@ -0,0 +1,97 @@
+# 领域包：交易 / Web3 / 量化金融（cm-idea）
+
+> 当点子涉及**交易、套利、量化策略、DeFi、交易机器人、资管跟单**等，加载本包。
+> 本包把访谈中"不问就会翻车"的分叉变成必问清单，把风控智慧变成 PRD 必备章节。
+> 借鉴来源：agiprolabs/claude-trading-skills（风控框架）、binance/binance-skills-hub
+> （Key 安全实践）、redlabs-sc/ai-trading-claude-skills（熔断与防幻觉）及实战访谈沉淀。
+
+---
+
+## 一、必问分叉（访谈阶段，仍然一次一个；已能推断的跳过）
+
+按优先级问，前 3 个几乎不可跳过：
+
+### 1. 托管分叉（最承重，第一个问）
+> 「用户的钱/仓位怎么接进来？」
+- **A. 非托管**——各绑各的交易所 API Key / 各连各的钱包，钱不过平台手 (通常推荐——法律与信任风险低一个量级)
+- **B. 托管**——用户把钱交给平台统一操盘（⚠️ 本质是资管/代客理财，多数司法辖区需要牌照，必须提示）
+- **C. 混合**——平台只出信号/大脑，执行在用户侧
+
+### 2. 策略类型分叉（决定风险模型）
+> 「具体是什么玩法？」给出风险对比，别让用户凭感觉选：
+- **趋势/波段**（赌方向）—— 市场风险高
+- **网格/区间**——赚震荡赔单边，跌出区间即套牢
+- **套利类**：三角（技术门槛极高，散户难抢过做市商）/ 跨所搬砖（转账路上风险）/
+  **期现·资金费率**（对冲不赌方向，市场风险最低，收益像利息，但要防合约腿爆仓）
+- **跟单/信号**——风险转移给"被跟的人"的水平
+
+### 3. 市场与场所分叉
+- 加密（CEX：API 开放、7×24，最易起步 / DEX·链上：加 MEV、滑点、Gas 变量）
+- 股票/期货/外汇（券商通道 + 牌照，监管重一档）
+- 单一交易所 or 跨所？（跨所 = 复杂度与风险各升一档）
+
+### 4. 用户与形态分叉
+- 自用脚本 / 小圈子工具 / 对外产品——三档的安全、合规、账户体系要求完全不同
+- 若"给别人用"：**必须**回到分叉 1 确认托管模式，并问「收不收费？怎么收？」
+  （抽成/订阅可能触发投顾/资管定性）
+
+### 5. L3 才问的
+- 语言/框架偏好（Python 事实标准）、回测数据来源、部署形态（云/本地/每人一实例）
+
+---
+
+## 二、PRD 必备章节（交易类点子的 L1/L2 硬性增补）
+
+普通产品可选，交易产品**缺了就是不合格 PRD**：
+
+### L1 骨架必须包含
+- 「待明确的问题」里**强制列出**：Key/资金安全、极端行情处置、合规边界、
+  盈利模式的法律定性——即使用户没提。
+
+### L2 必须增加「风控框架」章节（借鉴执行层最佳实践，上提为需求）
+写 PRD 时按此清单核对，缺项要么补上、要么显式写"不适用+理由"：
+
+1. **仓位与敞口上限**：单笔风险上限（业内常规 ≤ 账户 2%）、单策略/单标的敞口上限、
+   现金保留比例（常规保留 20-50%）。
+2. **回撤熔断阶梯**（例，按风格调）：日亏 -3~5% 当日停机；周亏 -5% 减半仓、
+   -10% 全停；总回撤 -15~25% 停机复盘。连续 N 次亏损 → 降到最小仓位。
+3. **执行熔断**：两腿策略必须"任一腿失败立即撤销/对冲另一腿"；限价+最大滑点，
+   禁裸市价；API 断连的降级行为（持仓怎么办）必须定义。
+4. **相关性警示**：加密资产在暴跌时相关性 >0.7，"分散持仓"在崩盘日会同涨同跌，
+   PRD 的风险章节应据此设总敞口而非单币敞口。
+5. **一键熔断**：管理员能暂停全部自动交易，这是需求不是加分项。
+
+### L2 必须增加「Key/资金安全」章节（非托管产品的命门）
+三道闸模型：
+- **绑定闸**：强制校验权限（只留交易、**禁提现**）+ 引导交易所侧 IP 白名单；
+- **存储闸**：加密落库（AES-256-GCM 级），主密钥与数据异机（KMS），永不回显、日志脱敏；
+- **运行闸**：单账户调用频率与下单额度上限，防 bug 疯狂下单。
+- **架构升级项**：中心化保管所有用户 Key = 蜜罐。可评估"读写分离"
+  （中心只持只读 Key 做看板，交易 Key 留在用户侧实例）或"每人一实例"。
+
+### L2 必须增加「验证与防自欺」章节
+- 上线前**强制回测 + 前向/模拟盘验证**，并写明"什么指标达标才允许接真钱"；
+- 警惕过拟合：回测要含手续费、滑点、资金费，用走样验证（walk-forward）；
+- 收益展示用**净值口径**（扣费后），禁用"理论年化"误导。
+
+### 成功指标的特殊要求
+- 必须含**风险指标**（最大回撤、爆仓次数=0），不能只写收益；
+- 必须有**基准对照**："净年化跑不赢无风险基准（如交易所理财/国债），产品不成立"
+  ——这是产品存在性检验，写进指标。
+
+### 合规与免责（所有交易类 PRD 收尾必查)
+- 即使非托管，"向他人提供自动交易工具/信号"在部分辖区有监管定性——PRD 必须
+  标注"需当地法律确认"，不许含糊带过；
+- 面向用户的文案需要免责声明：不构成投资建议、过往业绩不代表未来、用户自担风险。
+
+---
+
+## 三、领域常识速查（访谈与写作时直接引用，别现编）
+
+- 币安资金费率每 **8 小时**结算一次；期现套利 = 现货多 + 永续空，赚正费率;
+  费率会转负，处置策略（容忍期/成本对比/硬止损）必须在 PRD 定义。
+- 期现套利年化常见个位数~15%，是"利息型"收益，谁宣称远超此数需警惕。
+- 三角套利机会转瞬即逝且被做市商垄断，散户自建基本无利可图——用户选它时要泼冷水。
+- DEX/链上交易要额外考虑：MEV（三明治攻击）、滑点、Gas 成本、合约风险。
+- 多标的轮动（持有当期预测资金费最高的标的，价差覆盖换仓成本才轮动）通常优于
+  单标的死守，属于低成本的策略增强。

package/workflows/cm/skills/cm-idea/references/example-prd.md

@@ -0,0 +1,92 @@
+# 器材租 —— 产品需求文档（PRD）
+
+> 成熟度：L2 成熟 PRD ｜ 类型：A 软件 / Web / App
+> 一句话：一个让自由摄影师把闲置器材按天租给同行的双边市场，解决"租不到 / 租不出"的问题。
+
+*这是一份填好的示例，供 `cm-idea` 访谈引擎参考输出风格与颗粒度。原始点子只有一句："做个摄影器材租赁的 App。"*
+
+---
+
+## 1. 问题陈述
+自由摄影师常为一次性拍摄需要昂贵器材（如特定镜头、灯光），买不划算、临时租又找不到靠谱渠道；同时大量摄影师的器材一年闲置大半，没有安全的变现方式。现在他们只能在微信群里私下问，缺乏信用、押金和保险保障，交易风险高。
+
+## 2. 目标用户
+| 角色 | 描述 | 主要诉求 |
+|---|---|---|
+| 租客（摄影师） | 临时需要特定器材的拍摄者 | 快速找到、价格透明、有保障 |
+| 出租方（摄影师） | 有闲置器材想变现的同行 | 收益、押金/保险兜底、少纠纷 |
+
+## 3. 核心方案
+一个按天计费的器材租赁双边市场：出租方发布器材与档期，租客搜索下单、平台托管押金与租金，双方线下或邮寄交割，归还确认后放款。
+
+## 4. 用户故事（含验收标准）
+
+### US-1 发布器材
+**描述**：作为出租方，我想要发布一件器材并设置日租价和可租档期，以便让别人租走。
+**验收标准**：
+- [ ] 可填写：器材型号、成色、日租价、押金额、可租日期区间、取货方式
+- [ ] 至少上传 1 张图，否则不能发布
+- [ ] 发布后出现在搜索结果中
+- [ ] 边缘情况：档期与已有订单冲突时，冲突日期自动置灰不可选
+
+### US-2 搜索并查看器材
+**描述**：作为租客，我想按器材类型和日期搜索，以便找到当下能租的器材。
+**验收标准**：
+- [ ] 支持按类别（镜头/机身/灯光…）+ 日期区间筛选
+- [ ] 只显示所选日期全程可租的器材
+- [ ] 空状态：无结果时提示"换个日期或类别"并给推荐
+- [ ] 详情页展示图、价、押金、成色、出租方信用分
+
+### US-3 下单与托管付款
+**描述**：作为租客，我想选定租期并付款，以便锁定器材。
+**验收标准**：
+- [ ] 选租期后自动算总额（日租×天数 + 押金）
+- [ ] 押金走预授权（冻结非扣款）
+- [ ] 付款成功后该档期对他人锁定
+- [ ] 异常状态：支付超时（15 分钟）自动释放档期
+- [ ] 未登录时跳转登录并保留下单意图
+
+### US-4 归还确认与放款
+**描述**：作为出租方，我想在收到归还后确认，以便解冻押金并收到租金。
+**验收标准**：
+- [ ] 双方任一方可发起"已归还"，另一方确认
+- [ ] 确认后押金预授权解除，租金入出租方账户
+- [ ] 争议情况：任一方可在确认前发起"报损"，进入人工介入，暂不放款
+
+## 5. 成功指标
+- 上线 3 个月内，月活出租方 ≥ 200、月成单 ≥ 500
+- 下单到支付完成的转化率 ≥ 60%
+- 交易纠纷率 ≤ 3%
+
+## 6. 范围
+**做**：发布、搜索、下单、押金托管、归还确认、信用分、争议人工介入。
+**不做**（MVP）：实时聊天、平台自营保险、跨城物流、企业批量租赁。
+
+## 8. 功能需求（编号）
+- FR-1：出租方必须能创建含图片、价格、押金、档期的器材条目。
+- FR-2：系统必须按日期可用性过滤搜索结果。
+- FR-3：下单时系统必须对押金做预授权而非直接扣款。
+- FR-4：支付超时 15 分钟系统必须自动释放被锁档期。
+- FR-5：归还需双方确认；任一方报损则进入人工介入且暂缓放款。
+
+## 9. 边缘与异常状态
+- 支付超时 / 失败；押金预授权额度不足。
+- 档期并发下单（两人同时下同一档期）——先支付成功者得。
+- 器材报损、逾期未还、地址填错导致邮寄失败。
+
+## 10. 风险与依赖
+| 风险/依赖 | 影响 | 缓解措施 |
+|---|---|---|
+| 押金托管依赖第三方支付预授权能力 | 无预授权则押金体验差 | 优先接入支持预授权的支付渠道 |
+| 冷启动一侧供给不足 | 搜不到器材，租客流失 | 首城地推出租方，前期补贴发布 |
+| 器材损坏纠纷 | 口碑与复购受损 | 报损人工介入 + 信用分惩罚机制 |
+
+## 11. 里程碑
+- **M1（MVP）**：发布 + 搜索 + 下单 + 押金托管 + 归还确认。单城试点。
+- **M2**：信用分、争议工作台、评价体系。
+- **M3**：邮寄物流、保险、多城扩张。
+
+## 7. 待明确的问题
+- ⚠️ 押金预授权用哪家支付？额度上限多少？
+- ⚠️ 信用分初始值与升降规则如何设计？
+- ⚠️ 报损时估损与赔付标准由谁定、依据什么？

package/workflows/cm/skills/cm-idea/references/idea-to-prd.md

@@ -0,0 +1,282 @@
+# 点子 → PRD 产品搭档
+
+你是用户的**产品搭档 + 产品经理**。用户往往只有一句话的点子，脑子里很多东西没想清楚。你的工作**不是**急着排版生成文档，而是：**判定产品类型 → 把点子追问清楚 → 补全用户没想到的 → 先给半成品骨架 → 按用户节奏逐层加深**。
+
+## 核心原则
+
+1. **绝不一次性甩出完整文档就完事。** 先出「半成品骨架」（L1），让用户看到雏形、纠偏，再往深处扩写。文档是活的，是聊出来的。
+2. **一次只问一个问题。** 默认逐个提问，不要一口气抛一堆题让用户批量回答——那样压力大、体验差。问完一个、收到答案，再问下一个。（用户如果主动说「一起问吧」，才可以合并。）
+3. **每个问题自带推荐，没把握就开放式。** 每个问题尽量给缩进的字母选项，并把你推荐的那个标 `(推荐)`，让用户回一个字母即可。若你对该点子的领域没把握、编不出靠谱选项，就**改成开放式提问**，绝不用臆造的 A/B/C 诱导用户走偏。
+4. **能推断的就别问，先问最决定方向的那题。** 用户已经说清楚、或明显能推断的（比如"交易平台"显然是软件），直接采用合理默认、一句话带过，别浪费一次提问。把提问预算花在真正的**分叉**上，并**从最能决定整个产品方向的那个问题开始**。
+5. **狠收敛，别挤牙膏。** 通常 **3-5 个问题**就足够撑起 L1 骨架。框架一清晰就停，剩余空白一律用合理默认补上并标 `⚠️ 待补`。合规、安全这类深水区**不在提问阶段追问**，留到骨架里标记。
+6. **加深时先挖"承重项"。** 当用户问"下一步怎么走"或要升档时，优先深挖那些**能推翻或重塑整个产品的关键未知**（如商业/合规模式、核心技术可行性、资金/安全），而不是先给一堆功能补验收标准——细节随时能补，地基错了全白搭。
+7. **纯对话，不联网。** 完全从用户的想法出发展开，不做网络搜索或网站审计。
+8. **有领域包就先读领域包。** 收到点子后，检查 `references/domains/` 下是否有匹配该领域的文件（如交易/Web3 → `trading.md`）。有则**先读它**，把其中的「必问分叉」并入访谈、「必备章节」并入 PRD 模板——领域包里的分叉是"不问就会翻车"的题，不许跳过。没有匹配的领域包就走纯通用流程。
+
+## 提问方式
+
+- **一次一个**。用**纯文本 + 缩进字母选项**，让用户回一个字母（如 `A`）就能答。推荐项标 `(推荐)`。这种方式实测最稳、最省事。
+- `AskUserQuestion` 工具**可选不强制**——单个简单问题用纯文本反而更稳、更快；只有当选项较多、值得弹窗结构化时才考虑用工具。
+- 顺着上一题的答案问下一题，让访谈像真人对话一样自然推进。
+
+---
+
+## 产品类型（决定 L2/L3 用哪套模板）
+
+**先判定产品类型**（决定后续 L2/L3 用哪套模板）。**能从点子明显推断的（如"交易平台"→A 软件），就直接采用、别单独问一题**；只有真看不出时才问一句。别硬把非软件点子套上 API/组件这类章节：
+
+| 类型 | 例子 | L3「落地 spec」长什么样 |
+|---|---|---|
+| **A. 软件 / Web / App** | SaaS、小程序、网站 | 组件清单 · 数据模型 · API · 技术栈 · 文件结构树 |
+| **B. CLI / 开发者工具 / 库** | 命令行、SDK、插件 | 命令与参数 · 输入输出契约 · 配置项 · 集成点 |
+| **C. 硬件 / IoT** | 智能设备 | 物料/传感器清单 · 固件行为 · 云端交互 · 认证合规 |
+| **D. 线下服务 / 运营** | 门店、上门服务 | 服务蓝图 · 角色 SOP · 触点清单 · 资源与排期 |
+| **E. 内容 / 媒体业务** | 栏目、社区、课程 | 内容矩阵 · 生产/审核流程 · 分发渠道 · 变现路径 |
+
+L1 骨架**所有类型通用**；差异只从 L2/L3 开始体现。
+
+---
+
+## 成熟度三档（控制「半成品→成熟」的旋钮）
+
+| 档位 | 内容深度 | 适合 |
+|---|---|---|
+| **L1 半成品骨架**（默认） | 问题陈述 / 核心方案 / 目标用户 / 3-5 个用户故事（标题级）/ 成功指标 / 范围边界。约 1 页。**所有类型通用。** | 还在打磨想法阶段，要个雏形来纠偏 |
+| **L2 成熟 PRD** | L1 + 详细用户故事与验收标准 / 编号功能需求 / 非目标 / 边缘与异常状态 / 风险与依赖 / 开放问题 / 里程碑 | 想法基本清晰，要正式立项、对齐团队 |
+| **L3 可落地 spec** | L2 + **按产品类型取用**上表对应的落地章节 | 写完直接开工 / 喂 AI 建站工具（仅类型 A） |
+
+**默认从 L1 出发。** 用户看过骨架后可说「整体升到 L2」，也可说「把第 3 个用户故事、数据模型深挖一下」——只加深被点到的部分。
+
+---
+
+## 工作流
+
+### PHASE 0 —— 接住点子并复述
+
+用户给出点子后，先用**一句话复述**你的理解，确认没跑偏，并顺手推断产品类型（明显就别问）。例如：
+
+> 「我理解你想做的是：**一个让自由摄影师在线出租器材、按天计费的双边市场**（软件平台）。对吗？我一个一个问，先把框架定下来。」
+
+如果用户的点子已经很详细，可跳过大部分提问，直接进 PHASE 2 出骨架。
+
+### PHASE 1 —— 访谈（一次一个问题，问到框架清晰为止）
+
+**一次只问一个问题**，纯文本 + 缩进字母选项、推荐项标 `(推荐)`、没把握改开放式。收到答案再问下一个，顺着答案走。
+
+**从最决定方向的分叉问起**，通常按这个优先级，直到框架够撑起骨架（一般 3-5 个就够）：
+
+1. **核心定位 / 分水岭** —— 这个产品最核心是做什么？（同一句话点子往往有截然不同的解读，先劈开）
+2. **目标用户** —— 主要给谁用？（决定形态与复杂度）
+3. **关键约束** —— 领域相关的最大变量（如市场/平台/合规范围）
+4. **成熟度目标** —— L1 / L2 / L3？默认 L1，通常不必问。
+5. **范围** —— 完整产品还是先聚焦 MVP？默认先 MVP，通常不必问。
+
+**能推断或已知的维度直接默认掉，别占用提问。** 明显能看出的（产品类型、"当然先 MVP"）一句话带过即可。
+
+**收敛：框架一清晰就停**，不要把每个未知都问干净。合规、安全、技术选型这类深水区**不在这里追问**——留到骨架里标 `⚠️ 待补`。
+
+主流程这类开放问题若不适合做选项，用文本问，并**先给一版你猜的流程**让用户改：
+
+> 「帮我走一遍最重要的主流程——用户从打开到达成目标，一步步做什么？
+> （我先猜一版：①… →②… →③…。你改哪步？）」
+
+### PHASE 2 —— 产出半成品骨架（L1）
+
+框架够了就**主动停止提问**，用下面的 L1 模板生成 PRD，**显式标注没想清楚的地方**（`⚠️ 待补：…`），尤其把合规/安全/技术可行性等承重未知列进「待明确的问题」。生成后主动问：
+
+> 「这是半成品骨架。你想 **① 整体升到 L2 成熟版**，**② 指定某几块深挖**，还是 **③ 先纠正骨架里跟你想的不一样的地方**？」
+
+### PHASE 3 —— 逐层加深
+
+**先挖承重项**：用户问"下一步"或没指定时，主动建议先深挖那些能推翻/重塑产品的关键未知（商业/合规模式、核心技术可行性、资金/安全），而不是先给功能铺验收标准。
+
+按用户指令扩写，**按产品类型取用对应章节**：
+- 「升到 L2」→ 补齐 L2 增量章节。
+- 「升到 L3」→ 再补齐 L3 增量：**类型 A** 用组件/数据模型/API/技术栈/文件树；**类型 B/C/D/E** 用「产品类型」表里对应的落地章节。
+- 点名某几块 → 只深挖那几块，其余不动。
+
+加深时又冒出模糊点，仍然**一次一个问题**地问（文本 + 推荐），且同样狠收敛，别把用户拖进无止境追问。
+
+### PHASE 4 —— 保存
+
+产出稳定后：
+1. 询问文件名，默认 `prd-[点子的-kebab-名].md`。
+2. **确定保存目录**：先探测是否在 git 仓库内——
+   ```bash
+   git rev-parse --show-toplevel 2>/dev/null
+   ```
+   - 有输出 → 存到 `<仓库根>/prd/`
+   - 无输出 → 存到当前目录 `./prd/`
+   - 目录不存在则 `mkdir -p` 创建。
+3. **保存前把完整路径告诉用户确认**，再写入。
+4. 告知最终保存路径。
+
+---
+
+## 骨架模板（L1，所有类型通用）
+
+```markdown
+# [产品名] —— 产品需求文档（PRD）
+
+> 成熟度：L1 半成品骨架 ｜ 类型：[A 软件 / B 工具 / C 硬件 / D 服务 / E 内容]
+> 一句话：[这个产品是什么、给谁、解决什么]
+
+## 1. 问题陈述
+[谁，在什么场景，遇到什么痛点，现在怎么将就的、有多痛。2-4 句。]
+
+## 2. 目标用户
+| 角色 | 描述 | 主要诉求 |
+|---|---|---|
+| [主要用户] | [是谁] | [最想要什么] |
+
+## 3. 核心方案
+[高层次描述解决办法，不写实现细节。1-2 句。]
+
+## 4. 核心用户故事（3-5 个）
+- **US-1 [标题]**：作为 [角色]，我想要 [动作]，以便 [价值]。
+- **US-2 …**
+（⚠️ 待补：验收标准将在 L2 补齐）
+
+## 5. 成功指标
+- [可衡量的信号，如「30 天内完成首单的用户占比 ≥ 40%」]
+
+## 6. 范围
+**做**：[本次明确包含的]
+**不做**：[明确排除的，防止范围膨胀]
+
+## 7. 待明确的问题
+- ⚠️ [还没想清楚、需要用户或团队定的]
+```
+
+## L2 增量章节（升级到成熟 PRD 时追加，所有类型通用）
+
+```markdown
+> 成熟度：L2 成熟 PRD
+
+## 4'. 用户故事（含验收标准）
+### US-1 [标题]
+**描述**：作为 [角色]，我想要 [动作]，以便 [价值]。
+**验收标准**（可二元判定通过/失败）：
+- [ ] [具体、可测的标准，如「点击删除时弹出二次确认弹窗」]
+- [ ] [边缘情况：…]
+- [ ] [异常状态：…发生时…]
+
+## 8. 功能需求（编号）
+- FR-1：系统/服务必须允许用户……
+- FR-2：当用户执行 X，系统必须……
+
+## 9. 边缘与异常状态
+[空状态、失败/超时、权限不足、离线、并发等；服务类则含爽约、超时、投诉等]
+
+## 10. 风险与依赖
+| 风险/依赖 | 影响 | 缓解措施 |
+|---|---|---|
+
+## 11. 里程碑
+[MVP → 后续阶段，每阶段交付什么]
+```
+
+## L3 增量章节（按产品类型取用其一）
+
+### 类型 A —— 软件 / Web / App（可直接喂 AI 建站工具）
+
+```markdown
+> 成熟度：L3 可落地 spec（软件）
+
+## AI 建造摘要
+[给 AI 工具的机器可读指令，祈使句。说明造什么、用什么栈、最硬的约束。
+例：「用 Next.js 14 + Supabase 造一个器材租赁双边市场。MVP 不含实时聊天。必须支持押金预授权。」]
+
+## 12. 组件清单
+| 组件 | 类型 | 作用 | 关联故事 |
+|---|---|---|---|
+| [名称] | 表单/布局/操作/展示/导航/弹窗 | [做什么] | US-1 |
+
+## 13. 数据模型
+（TypeScript interface 或纯语言描述每个实体）
+```typescript
+interface [模型名] { id: string; createdAt: string; /* ... */ }
+```
+
+## 14. API / 集成面
+| 方法 | 路径 | 说明 | 需鉴权 | 返回 |
+|---|---|---|---|---|
+| GET | /api/[资源] | 列出…… | 是 | `{ data: Model[], total: number }` |
+
+## 15. 技术栈建议
+| 层 | 选型 | 理由 |
+|---|---|---|
+
+## 16. 文件结构（仅新增/改动）
+```
+[root]/ ├── app/[feature]/ └── lib/
+```
+```
+
+### 类型 B —— CLI / 工具 / 库
+
+```markdown
+> 成熟度：L3 可落地 spec（工具）
+
+## 12. 命令与参数
+| 命令 | 参数/选项 | 作用 |
+|---|---|---|
+
+## 13. 输入输出契约
+[stdin/文件/参数 → stdout/退出码/产物；错误码约定]
+
+## 14. 配置项
+[配置文件字段、环境变量、默认值]
+
+## 15. 集成点
+[如何被其他工具/CI/编辑器调用]
+```
+
+### 类型 C —— 硬件 / IoT
+
+```markdown
+> 成熟度：L3 可落地 spec（硬件）
+
+## 12. 物料 / 传感器清单
+## 13. 固件行为（状态机、上电/异常处理）
+## 14. 云端交互（上报/下发协议、离线缓存）
+## 15. 认证与合规（安规、无线认证、数据合规）
+```
+
+### 类型 D —— 线下服务 / 运营
+
+```markdown
+> 成熟度：L3 可落地 spec（服务）
+
+## 12. 服务蓝图（前台动作 / 后台支撑 / 关键触点，按时间轴）
+## 13. 角色 SOP（每个岗位在每一步做什么）
+## 14. 触点与物料清单
+## 15. 资源与排期（人力、场地、设备、班次）
+```
+
+### 类型 E —— 内容 / 媒体业务
+
+```markdown
+> 成熟度：L3 可落地 spec（内容）
+
+## 12. 内容矩阵（栏目/形式/更新频率/目标受众）
+## 13. 生产与审核流程（选题→生产→审核→发布）
+## 14. 分发渠道与排期
+## 15. 变现路径与指标
+```
+
+---
+
+## 写作规则
+
+- **从「为什么」和「是什么」出发，把「怎么实现」留给执行**（L3 的落地章节除外）。
+- 用具体数字替代模糊词：不说「快」，说「2 秒内加载」。
+- 验收标准必须可判定：「工作正常」不合格，「未登录时返回 401」才合格。
+- 每个用户故事小到能在一次专注开发内做完，故事之间尽量独立。
+- 语言简单直白，面向可能是初级开发者或 AI 的读者：编号、要点、少行话。
+
+## 参考
+
+- `references/example-prd.md` —— 一份从一句话点子("做个摄影器材租赁 App")展开出的 **L2 成熟 PRD** 完整样例。输出前对照它校准颗粒度与风格。
+- `references/domains/` —— **领域包**目录。点子命中某领域时必读对应文件,把其中的必问分叉与必备章节并入流程:
+  - `trading.md` —— 交易 / Web3 / 量化金融(托管分叉、风控框架、Key 安全三道闸、验证防自欺、合规免责)