罗斯蒙德想法产品化

概述

想法产品化 —— 想法 → PRD → 原型 → 墨刀

运行环境

脚本为纯标准库 Python，最低 3.6，不需要 pip 安装任何东西。

但各机器的解释器命令名不一致：Linux / macOS 多为 python3，Windows 上可能只有 python 或 py，而部分老系统上的裸 python 是 Python 2。因此执行任何脚本前，先解析一次可用解释器：

# POSIX：Linux / macOS / Git Bash
PY="$(command -v python3 || command -v python)"
"$PY" --version        # 必须 >= 3.6；若显示 2.x，换下一个候选

# Windows PowerShell
$PY = (Get-Command python3 -ErrorAction SilentlyContinue).Source
if (-not $PY) { $PY = (Get-Command python -ErrorAction SilentlyContinue).Source }
& $PY --version

想一次看清本机情况，用任意一个可用的 Python 跑自检脚本——它会列出全部候选、标出哪些版本过低，并给出本机对应的安装命令：

"$PY" scripts/env_check.py

下文所有命令示例中的 $PY，即指这里解析出的解释器；不要照抄成裸 python。

概述

接收任何形态的模糊输入，产出完整版 PRD + 可点击原型 + 需求覆盖矩阵 + 墨刀导入包。

四条核心原则：

1. 输入先分诊，再解析 —— 一句话、草图、截图、设计稿、文档、参考 URL 是六种不同信号，走不同解析链路，但归一到同一个「统一需求模型」。下游推导只认这个中间层，不认输入形态。
2. PRD 在原型之前 —— 原型是 PRD 的下游产物，不是反过来。先有需求条目（R1…Rn）、目标与非目标，再有页面。这样覆盖矩阵的左列永远有来源，不管 PRD 是读来的还是生成的。
3. 澄清按信息量分场景 —— 信息量低时少问多假设、给梗概让你推翻；信息量高时主动抛问题并捕获设计风格。不机械套用一种问法。所有假设与推测必须可见。
4. 确认后才打包 —— HTML 未经你确认，绝不产出墨刀包。

何时使用 / 何时不用

用本技能：

• 有一句话想法、草图、截图、设计稿、参考 URL，想得到 PRD 和可点击原型
• 有 PRD 文档，想验证页面结构是否漏了东西
• 需求评审前需要一份逐条可追溯的覆盖矩阵
• 原型要导入墨刀继续标注或做交互动效

不用本技能：

• 只审查已有 PRD 的质量、不出原型 → 用「需求文档质量审查」
• 需要高保真视觉稿或品牌级视觉设计 → 本技能中保真封顶
• 需求已完全明确、只要一个静态页面 → 直接写即可，不必走完整流程

输入形态与解析链路

分诊规则见 references/input-triage.md。混合输入（如"照着这个截图做，但要加批量导入"）按主导形态分诊，其余作为补充约束。

资源索引

工作流

阶段1 · 输入分诊

1. 加载 references/input-triage.md，判断主导输入形态。
2. 形态不确定时直接问一句（"这主要是想表达想法，还是要还原这张图？"），不做猜测。
3. 输出分诊结论：主导形态 + 补充约束 + 需要读取的解析参考。

阶段2 · 解析归一

按分诊结论加载对应解析参考，产出统一需求模型——无论输入是什么，都必须填满这七项：

每一项都必须标注来源：原文（输入里明确有）或 推测（模型补全）。推测项比例过高时，必须在阶段3 显式告知用户"这份输入信息量不足，以下内容为我补全，请重点复核"。

阶段3 · 澄清闸口（按信息量分场景）

先判断输入信息量，再选澄清方式——两种都要会，不要只认一种。

场景 A · 信息量低（一句话、草图、模糊诉求）

走「少问多假设」：

• 阻断项（影响页面结构、主流程、字段集合、角色划分）→ 汇总为一次性提问，不超过 8 个。
• 可默认项（排序、分页条数、文案措辞、次要交互）→ 声明假设继续推进，不提问。
• 信息量极低时，不要试图补齐 20 个问题——改为输出一份「我理解成这样」的方案梗概让用户确认或推翻，比问 20 个问题高效得多。

场景 B · 信息量高（PRD、设计稿、参考 URL、竞品截图）

走「主动抛出 + 捕获设计风格」：

1. 主动抛出结构化澄清稿：2–4 个你理解的核心用户场景 + 候选功能清单（按页面归组，标 P0/P1）+ 5–8 个针对性问题（如"列表默认排序字段？""是否需要批量导入？""权限分几类？"）。
2. 捕获设计 / 风格要求——必须明确询问：品牌主色、辅助色、字体、信息密度（B 端密 / C 端疏）、风格关键词。
   • 若用户已给：记录为本次设计约束，阶段5 落成设计令牌。
   • 若用户未给：声明"本次采用默认『无 AI 味道』基线（主色 #1677FF，见 references/design-system.md）"，不擅自套用套路化视觉。
3. 等待用户确认澄清稿后再进阶段4 / 阶段5。

已有完整 PRD 时，跳过本阶段直接进阶段4。

阶段4 · 生成完整版 PRD

加载 references/prd-template.md，产出 12 章完整版 PRD。要点：

• Non-goals 必写，且要具体到"不做什么"，防止范围蔓延
• 成功指标必须可观测、可归因、有基线与目标值
• Open Questions 收录阶段2 的所有推测项与阶段3 的假设，标注责任人与期望澄清时间
• 优先级建议可以给，但必须标注为"建议，待确认"

可验收性（硬性，缺一不可）：

• 第 4 章产出验收标准索引表，每条 AC 有唯一编号、场景类型（正常/边界/异常）、关联需求 R-x
• 每条 AC 的期望结果可测量——禁止"响应迅速""界面友好""提示合理"，必须给出数值、状态或具体文案
• 第 5 章每条 R-x 必须填验收标准列（AC 编号）与前置依赖列（R 编号或第 10 章 D-x）
• 第 6 章产出边界场景清单（B-x）与权限场景清单（P-x），每条场景关联 R-x 与 AC
• 一条没有验收标准的需求等于没定义完，不得进入开发排期；宁可把它移出本期范围，也不留无 AC 的需求

自检：第 5 章 R 数 = 有 AC 覆盖的 R 数，且依赖链无环。

PRD 写完后必跑静态自检（有 ERROR 必须修完再给用户确认）：

"$PY" scripts/check_prd.py <输出目录>/PRD.md

检查每条 R-x 是否有 AC、依赖是否成环、AC 是否含不可测量表述、第 6 章场景清单是否齐备。有 ERROR 说明 PRD 还没写完，不要进下一步。

章节标题必须写成 ## 4. 用户故事与验收标准 这种「数字 + 点」格式——脚本按这个格式切章，写成「第 4 章」会导致检查被静默跳过。

PRD 自检通过后等待用户确认，再进入原型生成。

阶段5 · 原型生成与走查

5.1 原型规划（先规划，后写代码）

加载 references/page-derivation-rules.md，用 PRD 里的实体/角色/状态机走文档链路 R-x 规则；若输入含图像，同时走视觉链路 V-x 规则，两条链路结果合并去重，产出五张表：

页面必须能追溯到 R-x 或 V-x 规则——清单里出现一条没有来源规则的页面，说明是凭空发挥，删掉或回阶段4 补需求。

是否需要停下来等你确认规划：PRD 已在阶段4 确认过，规划是它的机械推导，默认不停。仅在以下情形停下确认：

• 目标形态有歧义（PC / 移动端 / 兼顾未定）
• 页面数 ≥8，或出现 PRD 未定义的功能模块
• 覆盖矩阵预判会出现 ≥3 条「未覆盖」

5.2 文件结构决策

mobile 骨架已内置：430px 手机壳、底部 Tab、底部弹层、离线提示条、角色切换器。

完整流程拿不准时，先看 examples/README.md——那是一次真实跑通的产物，不是假数据。

"$PY" scripts/scaffold.py <项目名> --mode single|multi|mobile --out <输出目录> [--with-prd]

5.3 编码规范

加载 references/design-system.md 与 references/interaction-patterns.md 写代码。约束：

1. HTML：标准 HTML5 语义标签（header/nav/main/section），不 div 堆砌。
2. JS：仅原生 JS，无框架、无构建步骤；交互含显隐、Tab、弹窗、表单校验。
3. CSS：4px 间距基准；PC 内容区 ≤960px 居中；移动端 430px 居中（.mobile-frame）；单文件内联、多文件独立 .css。
4. 配色：主色默认 #1677FF；用户给了品牌色则以其为准。
5. 图片：SVG 占位或 CSS 绘制，禁外链。
6. 零外链（硬性）：禁任何 CDN / 外链字体 / 外链图片 / 外链脚本——既保证离线双击可开，也满足墨刀导入。

5.4 每页必覆盖

• [ ] 顶部导航（Logo + 主导航 + 用户区）
• [ ] 面包屑（≥2 级页面）
• [ ] 主要内容区
• [ ] 空状态（列表为空）
• [ ] 加载状态（异步处）
• [ ] 表单错误提示（如有表单）
• [ ] 角色切换器（角色 ≥2 时）
• [ ] 真实字段名与业务语义一致的示例数据，禁用 lorem ipsum

5.5 四层走查

加载 references/walkthrough-checklist.md 走查四层：第零层 PRD 需求质量（每条 R 是否有 AC、AC 是否可测量、依赖是否成环、场景清单是否齐备）、需求覆盖、一致性、代码质量。P0/P1 立即修复并重验；P2/P3 记入文档。

5.6 交付前必跑静态自检

不替代人工走查，只抓会静默失效的问题：

"$PY" scripts/check_proto.py <输出目录>

递归检查外链、ID 重复、data-page/data-open/data-submit/data-state 悬挂引用、缺 <title>（含 pages/ 子目录）。有 ERROR 必须修完再交付。

5.7 交付

present_files 打开原型，输出 说明.md（功能解释 / 设计思路 / 需求覆盖矩阵 / 假设清单与走查结论），并明确提示"确认 HTML 无误后我再产出墨刀导入包"。

说明.md 结构见 scripts/scaffold.py 的 DOC_TEMPLATE，四段必须有（顺序与骨架一致，不要自创）：

1. 一、功能解释 —— 页面清单 + 跳转关系 + 共用组件 + 交互路径 + 覆盖的需求点
2. 二、设计思路 —— 形态与设计令牌 + 布局与取舍；为何这样布局/配色/信息层级；如何对齐业务场景与密度；与默认「无 AI 味道」基线或你指定风格的对应关系
3. 三、需求覆盖矩阵 —— 格式如下
4. 四、假设清单与走查结论 —— 假设清单 / 未定项 / 走查结论（级别·维度·位置·问题描述·改进建议）/ 走查总结（问题总数·最需优先 3 项·整体评价·已自修复·残留）/ 待优化 P2/P3

覆盖矩阵格式：

| 需求 | 页面 | 组件 / 交互 | 状态 |
|------|------|-------------|------|
| R3 运营可批量导入密封点 | 密封点列表 | 工具栏「批量导入」→ 结果弹窗 | 已覆盖 |
| R7 按车间统计泄漏率 | 概览页 | 统计卡 + 近 30 天趋势 | 部分（无下钻） |
| R11 审批流可配置 | — | — | 未覆盖（PRD 未定义节点） |

未覆盖项必须写明原因，禁止静默跳过。

阶段6 · 确认闸口 → 墨刀导出（硬规则）

等待你明确回复「HTML 没问题 / 可以了 / 确认」后，才进入墨刀导出。 若你提出修改，回到阶段5 改完、重走走查、再交付确认，绝不提前打包墨刀文件。

1. 打包：单文件直传；多文件将整个目录（index.html + style.css + script.js + pages/ + assets/）打包为 zip，index.html 必须在 zip 根目录，内部用相对路径。
2. 墨刀导入步骤（附给用户）：墨刀 → 新建项目 → 选「HTML 导入」→ 上传 HTML（多文件传 zip）→ 导入后可补交互动效与标注。
3. 输出包：

- prototype_files: <HTML 路径列表 或 zip 路径>
- file_structure: <单文件 / 多文件>
- page_count / page_list
- explanation_doc: <说明.md 路径>
- modao_import: <直传 / zip + 导入步骤>

卡壳检索兜底（旁路）

连续多次无法满足需求时，不要继续硬猜——转向全网检索，用同类产品的功能描述与行业方案补全认知，再回到被打断的阶段继续。

这是旁路，不是第七个阶段：阶段 1–6 的任意位置都可触发，卡点解决后返回原阶段。

何时触发

满足任一即触发（完整判定表见 references/fallback-research.md）：

不触发：口味差异（配色/措辞/布局）、次要信息缺失、用户仍在发散讨论——这些直接改，或走阶段3 声明假设。

判定原则：能问清楚的先问，检索是问不到时的兜底，不是第一选择。

先确认，再检索

判定为卡壳后不得直接开搜——全网检索是对外动作，必须先取得用户明确同意。

把卡点摊开给用户看，同时给出三个出口：

卡点：【一句话，含业务对象】

缺的是：【功能定义 / 业务流程 / 字段集合 / 交互模式 / 行业规范 / 技术约束】

已试过：【哪些方案被否了、为什么】

我想上网查一下同类产品和行业方案里这块通常怎么做，大概需要几分钟。要查吗？

你也可以：1) 直接告诉我答案　2) 给我内部资料或竞品链接　3) 先跳过，我按假设做并标记为待确认

免确认的两种情形：用户主动指示检索（"去查一下""参考下同类产品怎么说"）；同一卡点已获批准但一轮未果、需换关键词再搜一轮。

每个新卡点单独征询，不做一次性打包授权。

怎么做

1. 填卡点卡 —— 卡在哪个阶段 / 具体卡点（必须含业务对象）/ 缺哪类信息 / 找到什么就能继续 / 已尝试过什么。
2. 按序检索 —— L3 标准与规范 → L1 同类产品 → L2 行业方案 → L4 具体实现。B 端场景规范优先：规范错了，抄来的功能全建立在错误边界上。
3. 三重过滤 —— 相关性 / 可信度（官方一手 > 行业媒体 > 社区 > 个人博客 > 营销软文）/ 时效性。营销软文不得作为功能依据。
4. 过吸收三问 —— 是解决我们的问题，还是只是"别人有"？会不会把对方的设计缺陷一起带来？有没有更简单的方案能达到同样效果？
5. 留痕进 PRD 第 12 章 —— 来源 URL + 类型 + 时间 + 可信度 + 采纳结论。未采纳的也记一句话，避免下轮重复检索同一来源。
6. 标注为「外部参考」 —— 检索所得既不是用户原话也不是推导结论，禁止标为「原文」。

硬纪律

• 未经确认不检索 —— 对外动作必须先问，只有用户主动指示或同卡点续搜两种情形例外
• 检索不是首选 —— 能问到用户的先问
• 检索 ≠ 需求 —— 只吸收结构、状态设计、字段语义、交互模式；不吸收商业模式、定价、竞品全部功能清单
• 2 轮上限 —— ≤6 个查询仍无有效结果即停止，把卡点写成 Open Question 请用户补内部资料
• 不得用检索掩盖流程缺陷 —— 若卡点根源是阶段1 分诊错了或阶段3 该问的没问，回那个阶段修正

Non-goals

• 不做 1:1 像素级还原 —— 图像输入只提炼结构，不还原视觉细节
• 不猜测商业模式与定价 —— 输入没有的进 Open Questions，不脑补
• 不替用户做优先级决策 —— 可给 RICE 建议，但标注为"建议，待确认"
• 不编造用户声音 —— 无访谈数据就明说需要做研究，禁止伪造"用户反馈显示…"
• 不做品牌级视觉设计 —— 中保真封顶，不产出视觉稿
• 不提前打包墨刀 —— HTML 未经用户确认，不得产出任何墨刀文件

硬规则

• 先 PRD 后原型：未生成 PRD 不得进入原型编码
• 来源必须标注：PRD 每一条是「原文」还是「推测」必须可见，推测项进 Open Questions
• 验收标准必填：每条 R-x 必须有 AC 覆盖，AC 期望结果必须可测量；无 AC 的需求不得进入开发排期
• 场景清单必交付：第 6 章必须输出边界场景清单（B-x）与权限场景清单（P-x），供测试直接转用例
• 推导优先于发挥：页面必须能追溯到 R-x 或 V-x 规则；PRD 未提的功能模块不得凭空增加
• 假设必须可见：任何"我猜是这样"的决策都要进假设清单
• 状态完备：每个列表有 空 / 加载 / 错误 / 无权限；每个写操作有 成功 / 失败 / 校验中
• 数据真实：字段名取自 PRD 术语表，示例数据符合业务语义，禁用 lorem ipsum
• 零外链：任何外部依赖都不允许，原型必须离线可开，同时满足墨刀导入（此约束针对产物，不限制检索旁路本身联网查资料）
• 墨刀在闸口之后：阶段6 之前不得打包，无论用户多着急
• 检索先确认：卡壳走全网检索前必须取得用户同意；检索所得一律标注为「外部参考」，禁止冒充「原文」

输出约定

<输出目录>/<项目名>/
├── PRD.md              完整版 12 章
├── index.html          原型（多文件模式）
├── style.css
├── script.js
├── pages/
├── 说明.md              功能解释 / 设计思路 / 需求覆盖矩阵 / 假设清单
└── <项目名>.zip         阶段6 墨刀导入包（多文件形态）

流程纪律

• [ ] 阶段1 是否分诊出主导输入形态，未猜测？
• [ ] 阶段2 是否填满了统一需求模型七项，且每项标注了 原文 / 推测？
• [ ] 阶段3 是否按信息量选对了澄清方式（低→少问多假设 / 高→主动抛出 + 捕获风格）？
• [ ] 阶段3 阻断项是否一次性问完（≤8 个），可默认项是否声明假设而未追问？
• [ ] 阶段4 是否产出 12 章完整 PRD，含 Non-goals 与成功指标？
• [ ] 每条 R-x 是否都有 AC 覆盖？依赖是否无环？
• [ ] AC 期望结果是否全部可测量，无"迅速/友好/合理"类模糊词？
• [ ] 第 6 章是否输出边界场景清单（B-x）与权限场景清单（P-x）？
• [ ] check_prd.py 是否跑过且无 ERROR？
• [ ] 是否等用户确认 PRD 后才写原型？
• [ ] 阶段5.1 是否输出五张规划表，页面是否都能追溯到 R-x 或 V-x 规则？
• [ ] 目标形态（PC / 移动端 / 兼顾）是否明确？页面切换实现是否匹配文件结构（单文件 hash / 多文件 <a href> / mobile section.page）？
• [ ] 是否完成四层走查、修复 P0/P1、交付覆盖矩阵与假设清单？
• [ ] check_proto.py 是否跑过且无 ERROR（含 pages/ 子目录）？
• [ ] 是否在用户确认 HTML 后才打包墨刀？
• [ ] 若触发过检索兜底：是否先取得用户同意？检索所得是否都标为「外部参考」并带 URL 进了第 12 章？