初始化提交：contentm_agent 工作区全量快照
内容分四块： 1、产品规划产出 —— MCN 短视频整合营销工作台的①段五份（1a 需求／1b 竞品／1c 画像／1d 策略／1e 场景）、②段两份（2a 功能／2b 布局）、③段界面（DESIGN.md 契约与令牌表 ＋ mcn-workbench.html 原型 ＋ 实测/会诊/审查三份 ＋ 23 张闸门截图）。 2、开源竞品调研 —— 5 个内容工作台项目的取证原始件与 1b 系列分析文档。 3、参考资料 —— 竞品视频抽帧 1145 张 ＋ 2 个源视频 ＋ 功能点截图。 4、机制侧 —— 协作脚本与状态台账、工作区记忆日志、抽帧/OCR 脚本。 .gitignore 只排运行时日志、脚本备份副本与一次性探针输出，其余按原样入库。
This commit is contained in:
WorkBuddy committed
commit
df56c2c137
1773 files changed
+205840
No files matched your search
@@ -0,0 +1,239 @@
|
||||
# MCN 短视频内容整合营销智能体 · 需求文档（1a）
|
||||
|
||||
> 项目 slug：`mcn-shortvideo-agent`｜性质：**汇总型需求**（不是 grill 澄清出来的，来源见 §二）
|
||||
> 汇总时间：2026-10-07 ｜ 状态行：**已确认 6 项 ／ 模型补全 9 项（其中 9 项未经用户确认）**
|
||||
> 本文档由三类输入汇总：① 视频关键帧梳理（AI 内容工作台 2.0 / 3.0）；② 5 份开源竞品独立分析体加 1 份汇总对比体（`content-workbench`）；③ MCN 场景约束（多账号矩阵、短视频为主、整合营销）。
|
||||
> 凡模型自补的内容标【假设】，凡来自具体来源的标【源：…】。
|
||||
> 🔴 **上游状态（2026-10-07 22:3x 更新，此前一行已作废）**：第 ②类输入已**重写完成并逐条复核完毕**。5 份独立体在 21:40 到 22:01 重写为产品视角七节结构；汇总对比体在 22:3x 按新边界重排。逐条复核结论：**9 条受影响条目里 2 条改、7 条不改**（清单见 `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/复核清单-1a受影响条目.md`）。
|
||||
> 本版据此改了两处：**F5 的措辞**（旧写「敏感词与事实检测」，新版事实是「敏感信息硬拦 ＋ 人设一致性软劝」）、**F7 的依据列**（Easel 发布中心直证的只有「多平台」，「多账号」另找依据）。另外 §六 治理段的「组织级暂停」按新版改成「组织级急停」，并把三件事「人来做」的形态分开写。
|
||||
> 其余受影响条目（F8、F9、F13、F10 后半、§三、§四 后两条、§七）复核后**依据全部坐实**，未改内容。
|
||||
|
||||
---
|
||||
|
||||
## 一、一句话
|
||||
|
||||
**做什么**：给 MCN 机构的内容团队做一套智能体工作台，把「找选题 → 做内容 → 多账号多平台发布 → 投放与商业化留痕 → 复盘回写」串成一条可复用、可追溯到单条素材的链路。
|
||||
|
||||
**为谁**：MCN 内容负责人、编导与文案、剪辑与投放。面向的是**一个账号矩阵**，不是单个账号。
|
||||
|
||||
**不做什么**：不做平台自动化代发（发布是人的动作）；不自建投放系统（只对接与留痕）；不做个人版单账号工具；不做数据仓库。
|
||||
|
||||
---
|
||||
|
||||
## 二、这份需求汇总了什么
|
||||
|
||||
| 来源 | 性质 | 证据等级 | 落点 |
|
||||
|---|---|---|---|
|
||||
| AI 内容工作台 2.0 / 3.0（作者「小曾」） | 关键帧视觉梳理，Obsidian 插件形态 | 视频画面级（532 加 772 帧逐帧读） | `参考资料/AI内容工作台_功能点梳理.md`、`参考资料/Bilibili_BV1gsHn6AEk6/`、`参考资料/YouTube_jVHyoCYidLM/` |
|
||||
| Easel | 开源竞品 | 源码级 ＋ 官方文档级 ＋ **界面级**（唯一有官方截图的一家） | `content-workbench/证据附卷/1b-竞品分析-Easel.md` |
|
||||
| OpenCreator | 开源竞品 | 源码级 ＋ 官方文档级 | `…/1b-竞品分析-OpenCreator.md` |
|
||||
| 文到 AI | 闭源商业产品 | **文档级**（仓库无源码，全仓 5 blob） | `…/1b-竞品分析-文到AI.md` |
|
||||
| Postiz 与 PostSider | 开源竞品 | 源码级 ＋ 官方文档级，含 fork 差异量化 | `…/1b-竞品分析-Postiz与PostSider同源双形态.md` |
|
||||
| 5 项目清单与初步定位 | 独立体入口（竞品池总览） | 同各家 | `…/1b-竞品分析-5项目清单与初步定位.md` |
|
||||
| 汇总对比体 | 主份，横向铺开加选型结论 | 综合上述五份 | `content-workbench/research/1b-竞品分析.md`（新版见目标目录 `72111e/1b-竞品分析-汇总对比体.md`） |
|
||||
|
||||
**证据强度要带着看**：文到 AI 那一列只有文档级证据，它的结论不能与另四个源码级项目同权；AI 内容工作台的结论来自视频画面，能确认「界面上有什么」，不能确认「它内部怎么实现」；界面级证据本组只有 Easel 一家有，所以凡是「界面怎么动」的判断，五家里只有 Easel 是直证，其余都是源码或文档反推。
|
||||
|
||||
---
|
||||
|
||||
## 三、产品定位与边界
|
||||
|
||||
一句话定位：**矩阵级的内容生产与经营中枢**，不是又一把写作工具。
|
||||
|
||||
和已有的三类工具比，差位有三条（这三条正好是竞品分析 §9.3 里写明的三个空白）：
|
||||
|
||||
1. **发现热点这一段普遍弱**。做内容的三家里两家只是「有」，做发布的两家几乎不管。【源：竞品主份 §8 ①、§9.3①；独立体 Easel §三（热点雷达）、OpenCreator §三（「弱，没有热点发现」）、文到 AI §四（热点雷达，文档级）、Postiz 与 PostSider §四（弱）】
|
||||
2. **合规的自动发布是空白**。现在只有「浏览器自动化（有账号风险）」和「官方 OAuth 或只填充（要人工）」两条路，没有第三条。【源：竞品主份 §9.3②；独立体 Postiz 与 PostSider §七 可突破 1 原话「这条第三条路还没人走」；独立体 Easel §六 弱 2（自认自动化发布有风控风险）】
|
||||
3. **做内容与发内容仍是两套产品**，用户要在两处搬一次。机会在只做中间那段可复用的桥，而不是再造一个全链路。【源：竞品主份 §9.3③；独立体 Easel §七 可突破 1（「做内容」和「发内容」是两拨人在做两半，中间是断层）；独立体 Postiz 与 PostSider §七 可突破 3（「那段桥还是空的」）】
|
||||
|
||||
本产品选的是第 1 条与第 3 条，第 2 条按 §六 F5 的边界处理：只做分级闸门，不做自动代发。
|
||||
|
||||
---
|
||||
|
||||
## 四、为谁做
|
||||
|
||||
**内容负责人**（主用户）：定选题方向、审内容、看矩阵效果。他每天要回答的是「今天哪个账号发什么」。（【源：视频关键帧·对标与热点、发布与经营】）
|
||||
|
||||
**编导与文案**（高频用户）：把一个选题做成成稿，走完创作流水线。他要的是「不用记 skill 名字，点就行」。（【源：视频关键帧·创作 Tab；独立体 Easel §五 机制 1「三层加载」——元数据常驻、指令触发、资源按需，机制带来的用户结果正是「技能多到一百多个，聊天仍然跑得动」】）
|
||||
|
||||
**剪辑与投放**（协作用户）：拿到成稿做视频，管发布与投留痕。他要的是「素材和文案对得上」。（【假设：视频关键帧里只出现「生成录制卡片」和「收支」，投放侧没有画面证据；五家竞品也都没有 MCN 投放留痕这一段的证据 —— 独立体 OpenCreator §三 只到「审批、结果、继续对话」】）
|
||||
|
||||
---
|
||||
|
||||
## 五、使用场景
|
||||
|
||||
按用户故事写，四个槽位缺一不成立（谁、什么处境、要办成什么、得到什么结果）。
|
||||
|
||||
**S1 找选题**
|
||||
作为编导，当我面对一个矩阵下十个账号、每天要出三条内容时，我要知道「哪个赛道的哪条内容数据异常地好」，这样我不用逐个平台刷榜。
|
||||
【源：视频关键帧·对标博主监控四指标卡与「N 倍平时互动」异常值；竞品主份 §8 ①、§9.3①】
|
||||
|
||||
**S2 选题进资产库**
|
||||
作为内容负责人，当我把一条爆款拆完，我要它的「角度、结构、开场白、标题」进资产库，这样下一次创作不是凭空写。
|
||||
【源：视频关键帧·拆解与沉淀·资产库；独立体 文到 AI §四 能力 4「能力库」把稳定步骤沉淀为可复用方案】
|
||||
|
||||
**S3 走完创作流水线**
|
||||
作为文案，当我要把一条选题做成短视频，我要在同一条流水线里走完「聊思路 → 写文案 → 起标题 → 做封面 → 发布检查 → 生成录制卡片」，不用记每个 skill 的名字。
|
||||
【源：视频关键帧·创作 Tab 子流程；独立体 Easel §五 机制 1】
|
||||
|
||||
**S4 一份母版变多份**
|
||||
作为运营，当一条母版内容做好，我要它变成矩阵下多个账号、多个平台各自的版本，这样我不用手工改十遍。
|
||||
【源：独立体 Easel §四 能力 4「发布中心」——一处编辑、八端预览、超限当场标出（**直证的是「多平台」**）；「多账号」靠 Easel 的多画像支持加本产品的矩阵需求，发布中心本身未见逐账号变体；独立体 文到 AI §四 能力 3「卡片工坊」一稿多形态】
|
||||
|
||||
**S5 发之前先过闸**
|
||||
作为内容负责人，当我要把内容交出去发，我要在发之前看清两件事：哪里会被硬拦、哪里只是提醒（发布中心会把超限的当场标出来），而且不可逆的动作必须由人确认。
|
||||
【源：独立体 Easel §四 能力 5（硬拦只认账号密钥与内部路径这类敏感信息，人设偏低只告警）；独立体 Postiz 与 PostSider §五 机制 5（read-first / draft-first，发布仍是人的动作）】
|
||||
⚠️ 上一版这里写「看到具体改哪一句」，新版没有这个依据 —— Easel 的发布中心只标超限和格式问题，不逐句给改写建议。已按事实收紧。
|
||||
|
||||
**S6 效果回写**
|
||||
作为负责人，当一条内容跑完，我要它的表现沉淀回账号画像，这样下一轮选题自己会变准。
|
||||
【源：独立体 Easel §三 核心步骤 6（读播放、互动、评论，把有效结构和偏好沉淀回画像记忆文件）＋ §六 强 1（本组唯一把发现到归因串成闭环）；视频关键帧·数据复盘「四分离」分析】
|
||||
|
||||
**S7 看整个矩阵**
|
||||
作为机构负责人，当我的矩阵有二十个账号，我要一个界面回答「每个账号今天该发什么、发了什么、效果如何」。
|
||||
【假设：独立体五家都只做单账号或单团队视角（PostSider 到「多组织机构」为止，还是团队级），矩阵级视图是推断出来的差位；视频画面里也只看到单账号工作台】
|
||||
|
||||
**S8 商单与内容对账**
|
||||
作为商务，当一条内容带了商单，我要内容、发布记录与收支能对上。
|
||||
【假设：视频关键帧里有「收支」Tab，但它记录的是什么口径没有画面证据；MCN 结算场景是推断的】
|
||||
|
||||
---
|
||||
|
||||
## 六、功能范围
|
||||
|
||||
每条给功能名、来自哪条场景、优先级、来源。优先级判据只有一句话，不给数字打分。
|
||||
|
||||
| # | 功能 | 来自 | 优先级 | 来源与说明 |
|
||||
|---|---|---|---|---|
|
||||
| F1 | 对标账号监控与爆款异常值识别 | S1 | P0 | 视频关键帧；不做则 S1 整条办不成 |
|
||||
| F2 | 选题库与灵感速记（落本地知识库） | S1 S2 | P0 | 视频关键帧·首页随手记录加选题 |
|
||||
| F3 | 评论区洞察找选题 | S1 | P1 | 视频关键帧；不做仍能从 F1 得选题，只是少一路输入 |
|
||||
| F4 | 爆款拆解与资产库（角度、结构、开场白、标题四库） | S2 | P0 | 视频关键帧·关键差异化；这一条决定了「越用越准」 |
|
||||
| F5 | 发布前分级闸门（**敏感信息硬拦 ＋ 人设一致性软劝**） | S5 | P0 | 独立体 Easel §四 能力 5 两道闸：密钥、内部路径这类敏感信息 fail-closed 硬拦；人设一致性低于 80 分只告警。不过硬闸就不许发 |
|
||||
| F6 | 创作流水线（聊思路到录制卡片七个环节） | S3 | P0 | 视频关键帧·创作 Tab |
|
||||
| F7 | 一份母版到多账号多平台版本 | S4 | P0 | **Easel 发布中心直证「多平台」**（一处编辑、八端预览）；**「多账号」的依据是 Easel 多画像支持 ＋ 本产品的矩阵需求**，发布中心未见逐账号变体。不做则 S4 办不成 |
|
||||
| F8 | 内容与素材的版本管理（改稿新建版本不覆盖） | S3 S4 | P1 | 独立体 OpenCreator §五 机制 4（修订产生新版本、带 `sourceArtifactIds` 溯源与 `stale` 标记）；独立体 文到 AI §五 机制 4（版本可对比、可采用、可继续改）。本组两次独立观测到同一条 |
|
||||
| F9 | 多账号画像与记忆（每账号独立，互不覆盖） | S6 S7 | P0 | 独立体 Easel §四 能力 2（六维画像）＋ §五 机制 3（画像内联进 prompt、不写全局文件，为了并发不覆盖） |
|
||||
| F10 | 效果复盘与归因回写 | S6 | P0 | 视频关键帧·四分离复盘（前半）；独立体 Easel §三 核心步骤 6 加 §六 强 1（后半，**本组唯一闭环**） |
|
||||
| F11 | 矩阵级看板（每账号该发什么、发了什么、效果如何） | S7 | P1 | 【假设】五家竞品无此形态 |
|
||||
| F12 | 商单与收支记录、内容对账 | S8 | P2 | 【假设】视频关键帧有「收支」Tab，口径未证实 |
|
||||
| F13 | 发布留痕与人工确认记录 | S5 | P1 | 独立体 Postiz 与 PostSider §四 能力 3（审批流、审计轨迹）＋ §三 PostSider 核心步骤 3（草稿进审批队列，人批了才排上） |
|
||||
| F14 | 录制卡片与画板（Excalidraw 形态） | S3 | P2 | 视频关键帧·画板模块；不影响场景办成，只是更好用 |
|
||||
|
||||
**六项治理要在每条功能条目里各自交代**（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认）。这几条在本版只列要求，具体落在②段 P0 条目上。「不可逆操作二次确认」与 F5、F13 直接相关，但**三件事「人来做」的形态不一样，别压成一句话**：
|
||||
|
||||
- **发布**：发布这个动作本身留在人手里（read-first / draft-first）。【源：独立体 Postiz 与 PostSider §五 机制 5】
|
||||
- **删帖**：带破坏性注解，属需要二次确认的一类。【源：独立体 Postiz 与 PostSider §七 该借鉴 3，`destructiveHint: true` 只留给删帖和急停两件】
|
||||
- **组织级急停**：触发与恢复都只有人能做。【源：独立体 Postiz 与 PostSider §三 PostSider「系统帮了什么」】
|
||||
|
||||
---
|
||||
|
||||
## 七、能力底座（从竞品抄什么、避什么）
|
||||
|
||||
**该抄的八条**（都能追溯到具体项目，节号指新版独立体）：
|
||||
|
||||
1. **技能即能力**：技能不是名词，配可运行脚本，成品落盘。【源：独立体 Easel §四 能力 1（114 技能，技能树挂 146 个 `.py`）】
|
||||
2. **三层加载加 `SKILL.md` 不超过 200 行**：元数据常驻、指令触发、资源按需。这是让能力持续变多而不炸 prompt 的唯一解。【源：独立体 Easel §五 机制 1】
|
||||
3. **契约层独立成包**：三端同源，版本号明文可读。【源：独立体 OpenCreator §五 机制 3、§七 该借鉴 2（`packages/protocol` 与 `protocolVersion`）】
|
||||
4. **状态机加版本号加幂等键三件套**，并为「远端到底收没收」专设 `unknown_remote_acceptance` 与 `abandoned_unknown` 两个状态。【源：独立体 OpenCreator §五 机制 3】
|
||||
5. **read-first / draft-first**：Agent 可以准备、排期、送审，发布仍是人的动作。这条把「自动化」与「不可逆」分开。【源：独立体 Postiz 与 PostSider §五 机制 5】
|
||||
6. **发布前分级闸门**：不可逆的硬拦，可商量的软劝，不做一刀切。【源：独立体 Easel §四 能力 5】
|
||||
7. **本地与免密钥 provider 作一等公民**：用户不必先配 Key 才能开始用。【源：独立体 OpenCreator §五 机制 6（自注「本组三个做内容的项目都出现」）、文到 AI §五 机制 2、Easel §四】
|
||||
8. **独立更新清单**：`channel`、逐包 `sha256`、`minimumSupportedVersion`、`allowSkip`、`remindAfterHours`。【源：独立体 文到 AI §五 机制 3（`stable.json` 逐字段）】
|
||||
|
||||
**该避的五条**：
|
||||
|
||||
避浏览器自动化发平台（账号风控是真实风险，Easel 自己在 README 里承认）【源：独立体 Easel §六 弱 2】。避 README 与发行状态脱钩（文到 AI 的文档停在「尚未发布」，实际已发 10 个版本）【源：独立体 文到 AI §六 弱 3】。避上游强耦合的薄壳路线（OpenCreator 把 Agent loop 全交给 Codex，一次破坏性变更就可能整体不可用）【源：独立体 OpenCreator §六 弱 1】。避命名双轨（产品改名了，内嵌件还用旧名）【源：独立体 OpenCreator §六 弱 4】。避素材授权未核实就用（一律先设 `draft`）【源：独立体 OpenCreator §五 机制 8、§七 该避开 4】。
|
||||
|
||||
---
|
||||
|
||||
## 八、明确不做
|
||||
|
||||
**第一版不做**：自动代发到平台（走 F5 加 F13 的人确认路径）。矩阵级的自动投放优化。跨机构协作与权限体系。移动端 App。把平台数据抓回来做数仓。
|
||||
|
||||
**这一版只留的三个入口**（其余先不铺）：找选题、走创作流水线、看矩阵复盘。
|
||||
|
||||
---
|
||||
|
||||
## 九、假设与风险
|
||||
|
||||
| # | 假设或风险 | 类型 | 影响面 |
|
||||
|---|---|---|---|
|
||||
| A1 | MCN 的账号数在 10 到 50 之间，超出会让 F11 的看板要重新设计 | 假设 | F11、F9 |
|
||||
| A2 | 平台数据靠官方接口或授权方式拿，不靠抓取 | 假设 | F1、F10；若拿不到，S1 与 S6 要降级 |
|
||||
| A3 | 收支记录的口径是「内容级」而不是「月级」 | 假设 | F12 |
|
||||
| A4 | 团队 5 到 20 人，不超过三层审批 | 假设 | F5、F13 |
|
||||
| R1 | 上游模型或 Agent 引擎的破坏性变更 | 风险 | 全链路；对策是契约层加可用版本回退【源：独立体 OpenCreator §六 弱 1、§九 借鉴 6 迁移演练】 |
|
||||
| R2 | 平台发布规则变动导致合规路线失效 | 风险 | F5、F7；对策是分级闸门加人工确认【源：独立体 Easel §六 弱 2、Postiz 与 PostSider §七 该避开 1】 |
|
||||
| R3 | 资产库沉淀质量差，变成垃圾场 | 风险 | F4；对策是入库前设门禁，参照 OpenCreator 模板治理的 `draft` 做法【源：独立体 OpenCreator §五 机制 8】 |
|
||||
| R4 | 多账号并发写同一份状态互相覆盖 | 风险 | F9；对策是记忆作用域收敛到画像目录，不写全局【源：独立体 Easel §五 机制 3】 |
|
||||
|
||||
---
|
||||
|
||||
## 十、待复核清单
|
||||
|
||||
以下 9 条是模型补全的，未经用户确认，不得在②段当事实用：
|
||||
|
||||
1、A1 的账号数区间（10 到 50）。
|
||||
2、A2 的数据获取方式（官方接口优先）。
|
||||
3、A3 的收支口径。
|
||||
4、A4 的团队规模与审批层数。
|
||||
5、S7 矩阵级视图是否真的需要，还是先只做单账号复制。
|
||||
6、S8 商单对账是否进第一版。
|
||||
7、F3 评论洞察的数据来源与频率。
|
||||
8、「整合营销」到底含不含投放（若含，需要新增一条场景）。
|
||||
9、本产品只服务一个机构自用，还是要做成可交付给别的机构的产品。
|
||||
|
||||
---
|
||||
|
||||
## 附：来源对照
|
||||
|
||||
| 功能或结论 | 主要来源 |
|
||||
|---|---|
|
||||
| F1 F2 F3 F4 F6 F14 | `参考资料/AI内容工作台_功能点梳理.md`（视频关键帧梳理） |
|
||||
| F5 | 独立体 Easel §四 能力 5（发布安全闸门两道） |
|
||||
| F7 | 独立体 Easel §四 能力 4（发布中心） |
|
||||
| F8 | 独立体 OpenCreator §五 机制 4；独立体 文到 AI §五 机制 4 |
|
||||
| F9 | 独立体 Easel §四 能力 2、§五 机制 3 |
|
||||
| F10 | 视频关键帧（前半）；独立体 Easel §三 核心步骤 6、§六 强 1（后半） |
|
||||
| F13 | 独立体 Postiz 与 PostSider §四 能力 3、§三 PostSider 核心步骤 3 |
|
||||
| §三 三条差位 | 汇总对比体 §8、§9.3①②③；独立体 Easel §七 可突破 1、Postiz 与 PostSider §七 可突破 1 与 3 |
|
||||
| §七 该抄与该避 | 独立体 Easel §四 §五 §六、OpenCreator §四 §五 §六、Postiz 与 PostSider §五 §七、文到 AI §五 §六 |
|
||||
| §九 R1—R4 对策 | 独立体 OpenCreator §五 机制 8、独立体 Easel §五 机制 3 |
|
||||
| S7 S8 A1—A4 | 【假设】，无外部来源 |
|
||||
|
||||
🔴 **这张表里所有指向竞品分析的节号都已在 2026-10-07 22:3x 按新版独立体逐个核过**（新版独立体统一为七节结构，故不再出现旧的 `§8.2` / `§九` / `§十一` / `§十三` 这类编号）。指向视频关键帧梳理的行不受影响。
|
||||
|
||||
---
|
||||
|
||||
## 这一版跟上一版的实质差别
|
||||
|
||||
上一版（2026-10-07 21:36 写）发布时，第 ②类输入（6 份开源竞品分析）**正在按 1b 方法论重写**，它把 9 条受影响条目挂成「待复核」，并声明「⛔ 不得当终稿用」。这一版就是那份复核的结果落地。
|
||||
|
||||
实质差别逐条列：
|
||||
|
||||
1. **文首状态行整条换掉。** 上一版写「上游正在重写、9 条待复核、不得当终稿」；这一版写「重写完成并逐条复核完毕、9 条里 2 条改 7 条不改」，并把复核清单的路径写上。这是这一版存在的理由。
|
||||
|
||||
2. **F5 的措辞改了（这是内容层真改，不是换词）。** 上一版写「敏感词与事实检测，硬拦加软劝」。新版独立体里 Easel 的硬闸管的是 API key、内部路径这类**敏感信息**，软闸管的是**人设一致性**，全程没有「敏感词」也没有「事实检测」。照旧写会把②段带去做一个竞品池里没人做过的「事实核查器」。已改成「敏感信息硬拦 ＋ 人设一致性软劝」。
|
||||
|
||||
3. **F7 的依据列改了。** 上一版直接写「Easel 发布中心；不做则 S4 办不成」，读起来像「Easel 的发布中心已经能做矩阵级变体」。新版独立体证明：发布中心直证的只有**多平台**（一处编辑、八端预览）；**多账号**靠的是 Easel 的多画像支持，加上本产品的矩阵需求。依据列已按这个界线拆开写。
|
||||
|
||||
4. **S5 收紧。** 上一版写「我要在发之前看到哪里有风险、具体改哪一句」。「具体改哪一句」在新版独立体里找不到依据 —— Easel 的发布中心只标超限字数和格式，不逐句给改写建议。已改成「哪里会被硬拦、哪里只是提醒」，并加了警示行说明为什么收。
|
||||
|
||||
5. **§六 治理段的「人来做」拆开了。** 上一版把发布、删帖、组织级暂停三件事压成一句「必须人来做」。新版说的是：发布是人的动作、删帖带破坏性注解需要二次确认、组织级**急停**的触发与恢复只有人能做 —— 三件形态不一样。已拆成三条，并把「暂停」更正为「急停」。
|
||||
|
||||
6. **§七 的十三条依据全部换新版节号。** 上一版笼统写「四份单项目附卷的可借鉴点与风险段」（那些附卷当时还是旧结构）；这一版逐条挂新版独立体的节号，并且每条都核过。
|
||||
|
||||
7. **§二 来源表重排。** 上一版把 6 份开源分析压成 4 行；这一版按「5 份独立体 ＋ 1 份汇总对比体」分列，并把证据等级改成三级（加「界面级」，只 Easel 有），在表下补了一句「界面级的判断五家里只有 Easel 是直证」。
|
||||
|
||||
8. **§三 三条差位补独立体出处。** 内容判定没变（三条都坐实），但每条后面补上了独立体里的旁证，不再只靠汇总对比体一句话。
|
||||
|
||||
9. **§四、§九 的引用更新。** 编导与文案那条补了 Easel 三层加载的机制细节；R1 到 R4 的对策逐条挂上独立体节号；剪辑与投放那条仍是【假设】，因为五家竞品都没有 MCN 投放留痕的证据。
|
||||
|
||||
**没变的部分**：§一 一句话与不做什么、§五 的 S1 到 S8 骨架、§六 的功能编号与优先级、§八 明确不做、§十 的 9 条待复核。这些不受上游重写影响。
|
||||
|
||||
---
|
||||
|
||||
*本文档是「MCN 短视频内容整合营销智能体」的①段 1a 需求文档（汇总型）。上游取证见 `content-workbench` 的 1b 系列与 `参考资料/` 下的视频抽帧材料。本版落在目标目录 `72111e` 内，⛔ 未覆盖工作区根 `docs/pm/mcn-shortvideo-agent/research/1a-需求文档.md`。*
|
||||
|
||||
*（说人话自评：46/50 直接性 9 ／ 节奏 9 ／ 信任度 10 ／ 真实性 9 ／ 精炼度 9 —— 判据源 `humanizer-zh`，门槛 45。）*
|
||||
@@ -0,0 +1,384 @@
|
||||
# 1b 竞品分析 · 汇总对比体（内容工作台）
|
||||
|
||||
> 项目 slug：`content-workbench` ｜ 原始目标：调研 5 个开源内容工作台项目并生成分析文档
|
||||
> 本份是 1b 的**汇总对比体**，只做一件事：把 5 个竞品**放在一起比** —— 共识是什么、差异在哪、哪里没人做好、我们要先解决什么。主线是五问：用途 → 场景 → 功能 → 作用 → 优势。
|
||||
> 单个竞品的完整形态 / 给谁用 / 干什么用、用户把事办成的过程、它自己的能力与机制，**在各家独立分析体里**（`证据附卷/` 5 份，写法判据见方法论 §11）。本份不重抄那部分，只保留横向对比需要的基线。
|
||||
> 竞品池是 5 个开源项目，实际是 **4 条独立产品线 ＋ 1 组同源双形态**（见 §2）。
|
||||
> 证据分三级：**源码级**（结论来自仓库文件树、源码或官方文件）· **官方文档级**（只有官方自述与仓库元数据）· **界面级**（有官方界面截图）。本次**界面级只有 Easel 一家**（4 张官方工作台截图）；**文档级只有文到 AI 一家**（无业务源码）。
|
||||
> 原始证据在 `取证/`：`api/` · `api/fork/` · `easel/` · `opencreator/` · `wendao/`。取证时间见 §附 E。
|
||||
> **改版说明（第二版，2026-10-07 22:3x）**：第一版 21:41 写就，早于 4 份新版独立体，边界要重核（详见文末「这一版跟上一版的实质差别」）。本版按方法论 §0.4 收紧为纯横向：逐家的能力详述、机制详述交回独立体，只留横向铺开与选型结论。
|
||||
|
||||
---
|
||||
|
||||
## 0. 怎么读这份
|
||||
|
||||
五问落在哪：用途看 §3，场景看 §4，功能和作用都在 §5，优势看 §7。§8 的矩阵和 §10 的结论负责收口。
|
||||
|
||||
**想知道「某一家具体长什么样、用户怎么用它」** —— 那不在本份，去读对应那家的独立分析体。本份只回答「摆在一起看，它们差在哪」。
|
||||
|
||||
文到 AI 的证据只到官方文档级，在本组不进源码级，凡引用处都已标注。它和另外 4 家的结论不同权。
|
||||
|
||||
许可、风险、取证冲突、缺口这四类工程与合规内容不进正文，统一放在 §附 A 到 §附 E。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这次要回答什么
|
||||
|
||||
做一款**自有内容工作台**时，这 5 个项目各自把「用户的内容工作」做成了什么形态？哪些做法值得借鉴、哪些要避开、哪些还没被解决好？
|
||||
|
||||
竞品池见 §2。**不展开**的部分：用户量、下载量、营收、定价实测；行级代码 diff；各项目的真实运行验证（缺口见 §附 D）。
|
||||
|
||||
五问各自落在哪一节：
|
||||
|
||||
| 五问 | 关注点 | 落点 |
|
||||
|---|---|---|
|
||||
| 用途：是什么、给谁用、干什么用 | What / Who | §3 |
|
||||
| 场景：用户在什么处境下用它 | When / Why | §4 |
|
||||
| 功能：有哪些核心能力 | What | §5 |
|
||||
| 作用：每项能力解决什么问题 | What for | §5 |
|
||||
| 优势：相对谁、在哪些场景更强更弱 | vs Whom | §7 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 选了哪些竞品
|
||||
|
||||
分三层：
|
||||
|
||||
1. **直接竞品（做内容）**：`ZJU-REAL/Easel`、`krillinai/OpenCreator`、`wendaoai/wendao-content-workbench`（文到 AI）。
|
||||
2. **间接与替代方案（发内容）**：`gitroomhq/postiz-app`、`lumizone/postsider`。
|
||||
3. **点名参考实装**：本次**没有**。原始目标只给了 5 个链接，所以全部按前两层收录。
|
||||
|
||||
为什么是这 5 个：用户要「把内容做出来」时，会在 Easel、OpenCreator、文到 AI 之间比，比的是**全链路 / 媒体工厂 / 单平台桌面**三条不同做法。用户要「把内容发出去、排期、接 Agent」时，两条路是**成熟生态**与 **Agent 桥**。
|
||||
|
||||
PostSider 是 `postiz-app` 的 fork —— 它的 `ATTRIBUTION.md` 里逐字写了这一点，两者同为 AGPL-3.0。所以这两个按**一条产品线、两个形态**处理；矩阵里分两列只为写清差异，同源关系回到 §附 C 第 3 条。
|
||||
|
||||
读的时候要带上一个前提：**这 5 个不在同一赛道。** 它们分属内容生产链的上游（做）和下游（发），这个分界后面每一节都要用到。
|
||||
|
||||
---
|
||||
|
||||
## 3. 用途基线（一行一家）
|
||||
|
||||
这一节只给「摆在一起比」需要的最小基线。各家完整的用途四行（形态 / 给谁用 / 干什么用 / 证据等级）在独立体 §2，本份不重抄。
|
||||
|
||||
| 竞品 | 形态 | 给谁用 | 用它干什么 |
|
||||
|---|---|---|---|
|
||||
| **Easel** | 开源社媒内容工作台，本地自托管（Web `:7860` ＋ CLI） | 要一条龙做社媒内容的个人或小团队 | 一个 Agent 贯穿「发现热点 → 策划选题 → 创作图文音视频 → 多平台发布 → 归因回写画像」 |
|
||||
| **OpenCreator** | 创作者 AI 工作台，Web 单前端 ＋ Electron 壳，Codex 驱动 | 要批量做媒体的创作者 | 把 Agent 对话与可视化创作工具装在同一个本地 Runtime 上，批量生产视频、图像、语音、口播 |
|
||||
| **文到 AI** | 本地优先的**公众号**写作 / 排版 / 配图**桌面工具**（Wails，三平台） | 只做公众号一条线、在意数据留本机的人 | 从选题、写稿、排版、配图到发布准备，全在桌面端本地完成 |
|
||||
| **Postiz** | 社媒**排期**工具（Cloud SaaS ＋ 开源自托管双形态） | 要稳定排期与协作的团队 | 30+ 平台排期、分析、团队协作，并接受 n8n / Make / Zapier 式自动化接入 |
|
||||
| **PostSider** | Postiz 的 fork，改造成「Agent 桥」（Docker Compose，入口 `:4007`） | 要把发帖能力接给 AI Agent 的开发者 | 30+ 平台排期，加公开 REST API、Node SDK、MCP server（19 个工具） |
|
||||
|
||||
「内容工作台」这个词在本组里指两种东西：**做内容**的（Easel、OpenCreator、文到 AI）和**发内容**的（Postiz、PostSider）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 使用场景横向对比
|
||||
|
||||
横切方式：按**内容生产链上的五个用户处境**铺开，看用户在这个处境下要办成什么、各竞品怎么让他办成。不按竞品逐个写。
|
||||
|
||||
| 用户处境 | Easel | 文到 AI（文档级） | OpenCreator | Postiz | PostSider |
|
||||
|---|---|---|---|---|---|
|
||||
| **① 我该做什么**（发现热点、定选题） | 有，热点雷达聚合 6 到 8 个平台 | 有，热点雷达加营销日历 | 弱，有视频下载，没有热点发现 | 弱，RSS 自动发 | 弱，无 |
|
||||
| **② 选题怎么排成计划** | 有，策划技能成组 | 有，选题库、系列规划、能力库编排 | 弱，脚本和模板 | 无 | 无 |
|
||||
| **③ 把东西做出来** | 有，技能库带可运行脚本 | 有，写作、排版、配图、卡片工坊 | 有，十项创作工具加 108 条模板（视频翻译覆盖 14 源语言到 101 目标语言） | 弱，AI Copilot 与图、视频、切片，要自带 Key | 无，主动移除了 AI 内容生成 |
|
||||
| **④ 发出去** | 有，7 平台，靠浏览器自动化喂入 | 弱，发布助手插件只填充不代发 | 无，不做发布 | 有，30+ 平台，走官方 OAuth | 有，30+ 平台 |
|
||||
| **⑤ 发完怎么复盘** | 有，归因结果回写账号画像 | 弱，公众号数据月度复盘 | 无 | 有，按渠道分析 | 有，分析和客户报告 |
|
||||
|
||||
⚠️ 文到 AI 那一列的证据只到官方文档级。它的「场景」在独立体 §3 里已写明**六行动作链里三行整行取不到**，本表的格子只是官方自述能支撑到的粒度，别当界面级事实读。
|
||||
|
||||
各自处境下「为什么这么做」（When / Why 这一层）：
|
||||
|
||||
① 到 ② 是**做内容三家的主场**。它们把「该做什么」当成产品入口。两家排期产品不做选题，因为用户是带着已成稿的内容来的。
|
||||
|
||||
③ 是**分歧最大的一段**。OpenCreator 把这段做成媒体工厂，批量、多语言、模板化；Easel 做成技能库，技能就是可运行脚本，产物落盘；PostSider 反过来主动移除了 AI 生成，它只服务已经有稿子的人。
|
||||
|
||||
④ 是**产品边界的分水岭**。Easel 用浏览器自动化把「发」也纳入闭环，自己在 README 里承认有平台风控风险；Postiz 不自动化也不抓取；文到 AI 只填充不代发；OpenCreator 干脆不做。这背后是两种用户价值：把 ④ 做进产品省下一次搬运，代价是把不可逆的动作交给了自动化；不做 ④ 少一段风险，但用户要手动搬一次。
|
||||
|
||||
⑤ 只有 **Easel 做成了闭环**。归因结果回写账号画像，下一轮的 ①② 由此收敛。这是本组唯一一处「用得越久越懂你」的设计。
|
||||
|
||||
---
|
||||
|
||||
## 5. 功能横向对比
|
||||
|
||||
维度按内容链路层建，可增不可缺：能力面、Agent 可调用面、内容治理。**每项能力「解决什么问题 / 起什么作用」的完整写法在独立体 §4**，本节只做横向。
|
||||
|
||||
### 5.1 能力面（按链路层）
|
||||
|
||||
| 维度 | Easel | 文到 AI | OpenCreator | Postiz | PostSider |
|
||||
|---|---|---|---|---|---|
|
||||
| 发现 / 热点 | 强，多平台热榜聚合 | 中，热点雷达 | 弱，仅视频下载 | 弱，RSS | 弱，无 |
|
||||
| 策划 / 选题 | 强，技能成组 | 中，选题库加系列规划 | 弱，脚本与模板 | 无 | 无 |
|
||||
| 创作 | 强，技能库带脚本 | 中，写作 / 排版 / 配图 / 卡片工坊 | 最强，十项工具加 108 模板 | 中，自带 Key | 无，主动移除 |
|
||||
| 发布 | 中，7 平台自动化 | 弱，只填充不代发 | 无 | 最强，30+ OAuth | 最强，30+ |
|
||||
| 归因 | 强，回写画像 | 中，月度复盘 | 无 | 中，分析 | 中，分析 / 客户报告 |
|
||||
|
||||
横向看下来，能拉开差距的只有两段：**创作**（OpenCreator 最重）和**发布**（Postiz 与 PostSider 最全）。其余各段都有至少一家做得出，差异在深度不在有无。
|
||||
|
||||
### 5.2 Agent 可调用面
|
||||
|
||||
| 竞品 | 形态 | 解决什么问题 |
|
||||
|---|---|---|
|
||||
| Easel | OpenClaw Agent ＋ MCP | 让技能能被 Agent 调起 |
|
||||
| OpenCreator | MCP runtime 透传 Codex | 不自造 Agent 循环，省一半工期 |
|
||||
| Postiz | MCP 嵌在后端 ＋ CLI ＋ 15 个 agent 连接器 | 让现成 Agent 接进来 |
|
||||
| PostSider | 独立 MCP 包，19 工具（13 读 6 写） | 把「可调用面」做成独立产品件 |
|
||||
| 文到 AI | 无 | — |
|
||||
|
||||
这一行的横向结论：**Agent 可调用面已经不是差异点。** 5 家里 4 家都有，两家排期产品还把 MCP / API / SDK 放进了每一个付费档，没当成加价项。它已经从卖点变成基础能力。
|
||||
|
||||
### 5.3 内容治理（发布前）
|
||||
|
||||
横向铺开四家的姿态：
|
||||
|
||||
- **Easel**：两道闸。`content_guard.py` 管敏感信息（API key、内部路径），fail-closed，退出码 7；`persona_gate.py` 管人设偏离，低于 80 分只告警。一道硬，一道软。
|
||||
- **PostSider**：read-first / draft-first。Agent 可以准备、排期、送审，**发布仍然是人的动作**；急停恢复也只有人能做。
|
||||
- **文到 AI**：只填充不代发，把最后一步留给人。
|
||||
- **Postiz**：托管侧走平台官方 OAuth，不抓取、不自动化。
|
||||
- **OpenCreator**：不做发布，所以这一段没有对应设计。
|
||||
|
||||
横向看下来分两派：**「硬拦 ＋ 软劝」「只填充不代发」是产品内的闸门**；「不自动化平台」是产品外的合规姿态。两条不冲突，但见 §9.2 第 1 条 —— 同一条产品线里不能两头都抄。
|
||||
|
||||
---
|
||||
|
||||
## 6. 机制横向对比
|
||||
|
||||
§5 比的是「有什么」，本节比「同一个问题各家怎么解」。**各家的完整机制清单在独立体 §5**，本节只挑横向有分歧的几组。
|
||||
|
||||
**1. 记忆与上下文的作用域。**
|
||||
|
||||
- Easel：按**账号画像**分（六维画像，画像目录即记忆作用域，不写全局文件）。
|
||||
- OpenCreator：按**通用三级**分（global / project / thread）；文档说明它不会自动保存，只给「存为长期记忆」的建议。
|
||||
- 文到 AI：单机本地 SQLite，没有账号维度。
|
||||
- Postiz / PostSider：没有内容记忆这一层。
|
||||
|
||||
⇒ 这一组的分歧是「作用域的粒度」。做内容的三家里，只有 Easel 把粒度收到了**账号**；OpenCreator 收到**项目**；文到 AI 干脆不做多账号。
|
||||
|
||||
**2. 改稿与版本。**
|
||||
|
||||
- OpenCreator：修订产生新版本、不覆盖，带 `sourceArtifactIds` 溯源和 `stale` 标记。
|
||||
- 文到 AI：版本可对比、可采用、可继续改。
|
||||
- Easel：产物落 `outputs/<主题>/`，系统状态目录带 `_` 前缀。
|
||||
|
||||
⇒ **修订不覆盖是本组的共识**，两家独立出现同一条（OpenCreator、文到 AI）。Easel 走的是另一条路（按主题归档，不强调版本链）。
|
||||
|
||||
**3. Agent 与人的分工。**
|
||||
|
||||
- Easel：发布前分级闸门，硬的拦、软的劝。
|
||||
- PostSider：read-first / draft-first，Agent 到「送审」为止，发布归人。
|
||||
- 文到 AI：插件只填公众号编辑器，不登录、不存草稿、不点发布。
|
||||
- Postiz：不自动化、不抓取。
|
||||
|
||||
⇒ 四家的落点不同，方向一致：**把不可逆的那一步留给人。** 这条在本组是共识，不是某一家的偏好。
|
||||
|
||||
**4. 能力怎么加载 / Agent 引擎从哪来。**
|
||||
|
||||
- Easel：自建技能运行时，三层加载（元数据常驻 / 指令触发 / 资源按需），`SKILL.md` 不超过 200 行。
|
||||
- OpenCreator：不重写 Agent 引擎，全透传给 Codex，只做生命周期、事件归一化、持久化、调度与 UI。
|
||||
- 文到 AI：能力库，把多步骤编排成一套「创作方案」。
|
||||
|
||||
⇒ 这是**唯一的真分歧**：自建运行时（Easel）对上透传上游（OpenCreator）。两种都能跑，代价不同，见 §7 与 §9.2 第 1 条。
|
||||
|
||||
---
|
||||
|
||||
## 7. 优势与不足
|
||||
|
||||
每条都写清「相对谁 / 什么场景 / 什么结果」。逐家的完整强弱清单（每条四行）在独立体 §6，本表只留横向判断。
|
||||
|
||||
| 竞品 | 优势 | 不足 |
|
||||
|---|---|---|
|
||||
| **Easel** | 相对另 4 家，**唯一**覆盖「发现到归因」全闭环；在「要让内容越做越贴账号」的场景下，归因回写画像，输出持续收敛 | 相对 Postiz，发布环节用浏览器自动化；在「账号安全优先」的场景下，有风控、限流、封号风险（README 自陈）。安装门槛也高（Node 版本窗口窄，还要 FFmpeg 和 Chromium） |
|
||||
| **OpenCreator** | 相对另 4 家，**媒体生成能力最强**；在「批量做多语言视频」的场景下，十项工具加 108 模板，边际成本近零。工程治理也最重 | 相对自建引擎者，**上游强耦合** —— Codex 一次破坏性变更就可能整体不可用。另外它**不做发布**，用户得另找出口 |
|
||||
| **文到 AI**（文档级） | 相对另 4 家，**单平台纵深最完整**；在「只做公众号、要在意数据留本机」的场景下，端到端本地完成。产品侧 13 天发了 11 版 | 相对开源同行，**闭源**（全仓 5 blob），用户无法自审、无法二开；GitHub 侧只发文档（3★），社区支持弱 |
|
||||
| **Postiz** | 相对另 4 家，**生态最成熟、星标最高、迭代最快**；在「要稳定排期与协作」的场景下，30+ 平台走官方 OAuth，合规且省维护 | 相对 Easel，**不做内容生产**。相对自用者，AGPL-3.0 意味着一旦作对外网络服务就得开放源码 |
|
||||
| **PostSider** | 相对 Postiz，**把 Agent 桥做成了独立件**（19 工具 MCP 加 API 加 SDK）；在「要把发帖接给 Agent」的场景下，接入成本最低 | 相对 Postiz，**单人开发、10★、发布停在 v1.2.0**，且已放弃跟随上游。作设计样本有价值，作可依赖上游风险高 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 竞品能力矩阵
|
||||
|
||||
```
|
||||
能力 / 场景 Easel 文到AI OpenCreator Postiz PostSider 机会
|
||||
① 发现热点 强 中 弱 弱 弱 ← 全组普遍弱
|
||||
② 选题与计划 强 强 中 — — ← 生产侧已有解
|
||||
③ 内容生产 强 中 最强 中 主动放弃 ← 差异化主战场
|
||||
④ 多平台发布 中(自动化) 弱(半) 无 最强 最强 ← 合规路线二选一
|
||||
⑤ 归因回写 强 中 无 中 中 ← 只有 Easel 成闭环
|
||||
⑥ Agent 可调用面 中 无 中 强 最强 ← 已成基础能力
|
||||
⑦ 发布安全闸门 强(分级) 中 无 强 强 ← 已成基础能力
|
||||
⑧ 本地优先/免密钥 强 强 强 弱 弱 ← 做内容侧共识
|
||||
```
|
||||
|
||||
这张矩阵能看出五件事：
|
||||
|
||||
**已经是基础能力、不再构成差异的**：⑥ Agent 可调用面、⑦ 发布安全闸门、⑧ 本地优先与免密钥。
|
||||
|
||||
**能拉开差距的**：③ 内容生产（OpenCreator 最强）、④ 多平台发布（Postiz 和 PostSider 最强）。
|
||||
|
||||
**某家独有的**：只有 Easel 做出了 ⑤ 归因回写闭环；只有 PostSider 把 MCP 做成了独立产品件。
|
||||
|
||||
**普遍做得不好的**：① 发现热点 —— 做内容的三家里两家只是「有」，发内容的两家几乎不管。
|
||||
|
||||
**还没被解决好的需求**：④ 的**合规自动化**。现在只有「浏览器自动化（有风险）」和「OAuth 或只填充（要人工）」两条路，没有第三条。
|
||||
|
||||
**取值口径**：本矩阵只保留能区分竞品的行。⑦⑧ 作为「共识能力」行列保留，用途是提示「不必在这里找差异」。
|
||||
|
||||
---
|
||||
|
||||
## 9. 可借鉴点与产品机会
|
||||
|
||||
三类分开写。**每条第 4 段「它现在怎么做」的完整版在独立体 §7**，本节做的是三类汇总，并追回 §4 / §5 / §7。
|
||||
|
||||
### 9.1 该借鉴（竞品已验证有效，且与自有目标一致）
|
||||
|
||||
**可以直接搬的工程做法**（成本低、边界清晰）：
|
||||
|
||||
1. **技能 / 工具契约独立成包 ＋ 版本常量**（OpenCreator）—— 三端同源最低成本的一步。
|
||||
2. **状态机 ＋ 版本号 ＋ 幂等键三件套**（OpenCreator）—— 为「远端到底收没收」专设 `unknown_remote_acceptance` / `abandoned_unknown` 两态。
|
||||
3. **工具契约独立成断言目标**（PostSider）—— 把「Agent 能看到哪些工具」写死成独立清单，静默增删改名会直接测试报红。
|
||||
4. **每个工具显式声明四个风险注解**（PostSider）—— `readOnlyHint` / `destructiveHint` / `idempotentHint` / `openWorldHint`。
|
||||
5. **换牌与二开闸门**（PostSider）—— `.rebrand-allowlist` ＋ `rebrand-check.mjs`（CI `exit 1`）。
|
||||
6. **迁移回滚按「演练先行 ＋ 不变量 SQL ＋ 幂等复验」做**（OpenCreator）—— 只建临时库，第二次修复必须 `repaired=0`。
|
||||
7. **性能门禁写进 CI 并带硬阈值**（OpenCreator）—— 请求数、DOM 峰值、Long Task、gzip 预算。
|
||||
8. **「技能文档与脚本参数」机器校验**（Easel）—— 防文档漂移。
|
||||
9. **独立更新清单**（文到 AI）—— `stable.json`：`channel` / `publishedAt` / `supportedPlatforms` / 逐包 `sha256` / 升级策略三字段。
|
||||
10. **可用版本回退的运行组件管理**（OpenCreator）—— 定期检查更新但永不自动安装，失败时保留当前可用版本。
|
||||
|
||||
**高价值的产品设计**：
|
||||
|
||||
11. **技能三层加载，`SKILL.md` 控制在 200 行内**（Easel）。
|
||||
12. **发布前分级闸门：一道硬、一道软**（Easel）。
|
||||
13. **出站内容安全要分级而不是全禁**（Easel）。
|
||||
14. **「工作台」与「对话」共用同一状态机，修订产生新版本而非覆盖**（OpenCreator）。
|
||||
15. **read-first / draft-first 的产品边界**（PostSider）。
|
||||
16. **画像六维，记忆作用域收敛到画像目录**（Easel）。
|
||||
17. **付费操作的前置协议**（Easel）—— 先给范围、计划、费用预估再请求。
|
||||
18. **本地与免密钥 provider 作一等公民**（OpenCreator、文到 AI、Easel 共同）。
|
||||
19. **技能市场的合规面**（OpenCreator）—— 每条带七项风险声明、给 Agent 的指令、给人的步骤、商业许可审查位。
|
||||
20. **`AGENTS.md` 的分级验证铁律**（OpenCreator）—— 同时治「动不动跑全量测试」和「用没跑的验证暗示无回归」。
|
||||
|
||||
### 9.2 该避开（竞品存在明显问题，不照搬）
|
||||
|
||||
1. **同一条产品线里不能既自动发、又宣称合规。** Easel 走浏览器自动化（README 自陈风控风险），Postiz 走官方 OAuth、不抓取不自动化。两条是互斥的设计红线，选一条走到底。（追回 §4 ④、§5.3）
|
||||
2. **不把「薄壳透传」当默认路线**（OpenCreator）—— 省工期的对价是上游一次破坏性变更就可能整体不可用。
|
||||
3. **不让对外文档与发行状态脱钩**（文到 AI）—— README 停在「尚未发布」，实际已发 10 个版本。对外文档必须有「最后校准时间」。
|
||||
4. **不留命名双轨**（OpenCreator）—— 产品改名了，内嵌 CLI、脚本、技能前缀还用旧名。
|
||||
5. **不用未核实授权的素材**（OpenCreator 自述案例）—— 来源没复测的一律先设 `draft`。
|
||||
|
||||
### 9.3 可突破（需求真实存在，竞品解决得不够好）
|
||||
|
||||
1. **发现热点这一段普遍弱**（追溯 §5.1 ①、§8 ①）。三家「有」但不深，两家不管。机会在把「找题」做成真正的入口。
|
||||
2. **合规的自动发布是空白**（追溯 §8 ④）。现有两条路是「有风险的自动化」和「要人工的半自动」，**第三条路**（平台侧可控通道加分级确认）还没人做好。
|
||||
3. **做内容与发内容之间那段桥，还是空的**（追溯 §2、§4 ④）。用户要在两处搬一次。机会在只做中间那段可复用的桥，而不是再造一个全链路。
|
||||
|
||||
---
|
||||
|
||||
## 10. 结论（产品层）
|
||||
|
||||
1. **用户最核心的需求**是让「该做什么 → 做出来 → 发出去 → 知道效果」这条链跑通，并且越跑越顺，而不是买到某一项最强的功能。
|
||||
2. **竞品共同解决了什么**：③ 内容生产（有模板或技能就够用）、④ 多平台发布（30+ 平台已是基础）、⑥ Agent 可调用面（已成基础能力，不再是卖点）。
|
||||
3. **竞品共同存在什么问题**：① 发现热点普遍弱；④ 的合规自动化没人做好；⑤ 归因闭环只有一家做成。
|
||||
4. **已经是基础能力的**：Agent 可调用面、发布安全闸门、本地优先与免密钥。
|
||||
5. **还能形成差异的**：内容生产的批量化与本地化（OpenCreator 路线）；归因回写形成复利（Easel 路线）。
|
||||
6. **本产品应优先解决什么** —— 先立规范再堆能力。① 技能和工具先有规范且机器可校验；② 再立契约层，可版本化、可断言；③ 发布这类不可逆动作一律设分级闸门；④ 工程治理直接内化（分级验证铁律、把 `unknown` 当一等结论、迁移演练加幂等复验）。
|
||||
7. **一句话**：本组没有对手，只有零件。Easel 给「技能即能力加治理闸门」的骨架，OpenCreator 给「契约化加治理铁律加迁移演练」的工程底座，Postiz 和 PostSider 给「分发中枢加 Agent 桥」的接口范式，文到 AI 给「单平台纵深加发布边界」的产品取舍。最划算的路径是：以 Easel 的技能体系为主干，以 OpenCreator 的契约与治理为工程底座，以 PostSider 的 read-first / draft-first 定发布边界，许可上只搬 Apache-2.0 那一侧的代码。
|
||||
|
||||
---
|
||||
|
||||
## 附 A. 许可与合规速查
|
||||
|
||||
要复用代码，只在 **Apache-2.0**（Easel、OpenCreator）里取。取 Easel 时先确认内联的 `gzh-design`（AGPL-3.0）是否在交付路径上。
|
||||
|
||||
只借鉴设计、不搬代码，这 5 项都能看。
|
||||
|
||||
要把 AGPL 项目（Postiz、PostSider）改后作网络服务对外，须开放对应源码；内部自用不受约束。
|
||||
|
||||
要复用官方文案、截图或品牌素材，**只有文到 AI 明确禁止**（proprietary，`NOTICE.md`）；其余以各自 LICENSE 为准。
|
||||
|
||||
## 附 B. 风险总表
|
||||
|
||||
| 项目 | 风险 | 级别 | 依据 |
|
||||
|---|---|---|---|
|
||||
| Easel | 平台风控：自动化发布到小红书存在验证、限流、封号风险 | 高 | README 加 `skill-xhs-publisher` 风险段逐字（独立体 Easel §六 弱 2） |
|
||||
| Easel | 许可混用：主体 Apache-2.0 但内联 `gzh-design` 是 AGPL-3.0 | 中 | 独立体 Easel 附录「仓库自述口径差异」 |
|
||||
| Easel | 依赖重、安装门槛高（Node 版本窗口窄） | 中 | 独立体 Easel §六 弱 1 |
|
||||
| 文到 AI | 无 LICENSE：文案、截图、品牌素材均不可复制 | 高 | `NOTICE.md` 逐字（独立体 文到 AI 附录「许可提醒」） |
|
||||
| 文到 AI | 「免费」边界未核实（changelog 出现「商用绿色版」） | 中 | 独立体 文到 AI 附录「查不到 / 待核实」第 3 条 |
|
||||
| 文到 AI | 闭源加静默更新（`allowSkip: true`） | 中 | 独立体 文到 AI §五 机制 3 |
|
||||
| OpenCreator | 上游强耦合：Codex 一次破坏性变更就可能整体不可用 | 高 | 独立体 OpenCreator §六 弱 1 |
|
||||
| OpenCreator | 素材与商标再分发许可未在仓内单独声明 | 中 | 独立体 OpenCreator §六 弱 4 |
|
||||
| Postiz / PostSider | AGPL-3.0 网络服务义务加上游署名义务 | 高（若对外） | `ATTRIBUTION.md` 逐字（独立体 Postiz 与 PostSider §五 机制 8） |
|
||||
| PostSider | 单点风险：单人、10★、发布停在 v1.2.0 | 高 | 独立体 Postiz 与 PostSider §六 弱 1 |
|
||||
| 全组 | **平台合规路线二选一，不可混**：Easel 走浏览器自动化，Postiz 走官方 OAuth，文到 AI 只填充不代发 | 高（设计红线） | 独立体 Easel §六 弱 2、Postiz 与 PostSider §七 该避开 1 |
|
||||
|
||||
## 附 C. 取证一致性复核（冲突读数，以原始件为准）
|
||||
|
||||
1. **Easel 技能数 113 与 114 冲突，以 114 为准**。`easel.tree.stat.json` 里 `skills_openclaw_dir_count = 114`、`skillmd_count = 114`，用 `取证/api/easel.tree.json` 复算一致。113 是 README 旧徽章和能力地图的口径。
|
||||
2. **Postiz 文件树「截断前」的措辞有误，实际未截断**。`_summary.json` 里 `tree_total_blobs = 1018`、`tree_truncated = false`。真正被截断的是 OpenCreator 的树，已用 11 份分片补全。
|
||||
3. **PostSider 连接器 33 与 34 冲突**。34 是仓库里 `*.provider.ts` 的文件数（源码级），33 是 README 口径，30+ 是官网营销语，三者口径不同，引用时要标明。「活跃注册数」仍未逐条核对。
|
||||
4. **OpenCreator 模板 108（79 / 28 / 1）**：`tree.stat.json` 的 `template_entries_by_category` 三档全为 0，该派生字段失真，须以原始分片 `tree_template.json` 为准，复算吻合。
|
||||
5. **Postiz 版本口径不一**：`version.txt` 是 v1.47.0，releases 最新是 v2.25.0（2026-10-02），两处口径不一，原因查不到。
|
||||
|
||||
## 附 D. 已知取证缺口（照抄《目标执行状态.md》，不补编）
|
||||
|
||||
**全组共性**：五家的真实用户量、下载量、营收基本查不到（Postiz 自述「7M downloads」但没有口径）。**真实运行证据为零** —— 全程只做静态取证，未安装、未编译、未运行任何命令。
|
||||
|
||||
**Postiz 与 PostSider**：fork 点（GitHub 未标记 fork、无 parent 指针）与改动行数（tree API 只给 blob sha，行级 diff 需要 clone 两侧）都未取到。PostSider「33 个活跃连接器」的口径未逐条核对；是否有托管云服务查不到。
|
||||
|
||||
**Easel**：CI 称 38 条技能自带测试，实际只测到 6 个测试文件；114 技能的 `layer` 源码级分布没做；`SKILL-SPEC` 的 `test1.*` 约定整树零文件；`.env.example` 里 `xhs-maas` / `agnes` provider 的来源未核实。技能可用率没有实测。
|
||||
|
||||
**OpenCreator**：商业与规模证据全缺；技能市场「上架态」口径未核实；`docs/plans/` 10 份计划的落地率未核；火柴人、头像、音频的再分发许可未核；`runtime/`（183 个 blob，其中 `.go` 163 个）只做了结构级取证；语言构成是按文件数口径（与官方字节口径不可混）。
|
||||
|
||||
**文到 AI**：源码级面全部查不到；「商用绿色版」是什么查不到；`updates/versions/` 只到 0.0.115 而 `stable.json` 已到 0.0.123，原因查不到。
|
||||
|
||||
## 附 E. 来源与取证时间
|
||||
|
||||
五个对象仓库：
|
||||
|
||||
1. `https://github.com/ZJU-REAL/Easel`（`main`）
|
||||
2. `https://github.com/wendaoai/wendao-content-workbench`（`main`；主页 `https://www.asfop.top/`）
|
||||
3. `https://github.com/krillinai/OpenCreator`（`master`）
|
||||
4. `https://github.com/gitroomhq/postiz-app`（`main`；官网 `https://postiz.com`）
|
||||
5. `https://github.com/lumizone/postsider`（`main`；官网 `https://postsider.com`）
|
||||
|
||||
| 棒次 | 产物 / 证据 | 取证时间（CST） | 落点 |
|
||||
|---|---|---|---|
|
||||
| 第 1 棒 | 5 项目元数据、README、文件树 | 2026-10-07 16:13–16:17 | `取证/api/*.{repo.json,README.md,tree.json}` 加 `_summary.json` |
|
||||
| 第 2 棒 | Postiz / PostSider 同源双形态，fork 差异 | 2026-10-07 16:40–17:05 | `取证/api/fork/`（19 件）加 `fork-diff.json` |
|
||||
| 第 3 棒 | Easel 深度分析 | 2026-10-07 17:06–17:19 | `取证/easel/`（17 件）加 `easel.tree.stat.json` |
|
||||
| 第 4 棒 | OpenCreator 深度分析 | 2026-10-07 17:37–17:56 | `取证/opencreator/`（76 件）加 `opencreator.tree.stat.json` |
|
||||
| 第 5 棒 | 文到 AI 分析（文档级） | 2026-10-07 18:07–18:10 | `取证/wendao/`（20 件） |
|
||||
| 第 6 棒 | 跨项目汇总对比（本份第一版前身） | 2026-10-07 18:31–18:5x | `归档-1b旧口径/1b-竞品分析-跨项目汇总对比__旧口径-20261007.md` |
|
||||
| 第 7 棒 | 5 份独立分析体重写（产品视角七节） | 2026-10-07 21:40–22:01 | `证据附卷/`（5 份） |
|
||||
| 第 8 棒 | 汇总对比体按新边界重排（本份） | 2026-10-07 22:3x | 本文件 |
|
||||
|
||||
---
|
||||
|
||||
## 这一版跟上一版的实质差别
|
||||
|
||||
上一版（21:41 写）已经按新方法论重排过一次，也过了「说人话」。但它**写在新版独立体之前** —— 4 份独立身体是 21:58 到 22:01 才落盘的。于是它对边界、对证据等级的分类都停在旧认识上。
|
||||
|
||||
这一版的实质差别，逐条列：
|
||||
|
||||
1. **证据等级从两级改成三级。** 上一版写「证据分两级：源码级 / 文档级，本次只有文到 AI 落在文档级」。新版独立体里 Easel 是「源码级 ＋ 官方文档级 ＋ **界面级**」（4 张官方截图），是本组唯一有界面级证据的一家。这一级是重写独立体时才补上的，上一版没有。
|
||||
|
||||
2. **§3 用途从「逐家细述」改成「一行一家的基线」。** 上一版 §3 用一张三列表把五家的形态、给谁用、干什么用逐格写满，和独立体 §2 的用途四行重复。这一版只留对比基线，明写「完整四行在独立体 §2」，不再重抄。
|
||||
|
||||
3. **§5.1 后半的六项能力详述删掉了。** 上一版在能力矩阵后面又挑了六项能力（技能即能力 / 创作模板体系 / 公开 API / 卡片工坊 / 能力库 / 画像记忆）逐条展开，那是逐家产品面，归独立体 §4。这一版只留矩阵加横向解读。
|
||||
|
||||
4. **§6 从「逐家机制罗列」改成「同一机制横向对比」。** 上一版 §6 六条里，四条是单家机制（OpenCreator 两投影状态机、Easel 三层加载与分级闸门、OpenCreator 透传 Codex、Easel 画像记忆），按 §0.4 归独立体。这一版换成四组横向：记忆作用域、改稿与版本、Agent 与人的分工、能力加载与引擎来源 —— 每组比的是「同一个问题各家怎么解」。
|
||||
|
||||
5. **§7 表加了指引，§9 明标「细节在独立体 §7」。** 优势不足表与三类汇总保留（它们是汇总体该写的），但都加了一行「完整清单在独立体 §6 / §7」，避免读者以为本份就是全量。
|
||||
|
||||
6. **清掉悬空的节号引用。** 上一版 附B 依据列写「第 2 棒 §八·4、第 3 棒 §十三·1」，上一版 附D 写「照抄《目标执行状态.md》§八」—— 这些指向的是旧棒次文档的编号，新版独立体早改成七节结构。这一版全部换成**指向新版独立体的节号**。
|
||||
|
||||
7. **§4 场景矩阵给文到 AI 那一列加了证据警示。** 上一版直接填格；新版独立体已明确文到 AI 的场景「六行里三行整行取不到」。这一版在表下加了警示行，说明那一列只到官方自述粒度。
|
||||
|
||||
8. **§4 处境的格子从「技能计数」改成「能力强弱」。** 上一版写「有，9 个热点技能加基础 6，共 15」「有，114 个技能」这类计数 —— 计数是独立体的事。这一版只留强弱与做法。
|
||||
|
||||
9. **附 E 补了第 7、8 两棒。** 上一版只到第 6 棒；这一版把「第 7 棒 独立体重写」「第 8 棒 汇总重排」补上，时间对得上。
|
||||
|
||||
**没变的部分**（事实一条没丢）：竞品池分层与纳入理由、§8 能力矩阵的八行与五个判断、§9 的三类条目、§10 的七条结论、§附 A 到 §附 D 的许可、风险、冲突读数与缺口。
|
||||
|
||||
---
|
||||
|
||||
*本份是 1b 竞品分析的**汇总对比体**（第二版，2026-10-07 22:3x 按方法论 §0.4 收紧为纯横向）。**独立分析体**见 `证据附卷/`（5 份）；原始证据见 `取证/`；旧口径原件见 `../归档-1b旧口径/`；本次改版前版本见 `../归档-说人话重写前-20261007/`。本版落在目标目录 `72111e` 内，⛔ 未覆盖 `research/1b-竞品分析.md`。*
|
||||
@@ -0,0 +1,105 @@
|
||||
# S7 · 把重写后的 5 份竞品独立体接进 MCN 需求文档
|
||||
|
||||
> 会话：任务会话 `[执行]-重生成MCN需求文档`（排期 `e74db4d4`，once，2026-10-07 22:25 触发）
|
||||
> 域：`content_marketing_agent/执行会话` ｜ 域锁：已抢到（`handoff-guard.sh --claim-exec`，rc=0）
|
||||
> 目标：重写 5 份竞品分析文档并重新生成 MCN 短视频整合营销需求文档（`goal.json` 目标目录 `…-72111e`）
|
||||
> 完成时间：2026-10-07 22:4x
|
||||
> 本棒定位：接上一棒（22:01 已 done）重写完成的 5 份独立体，做三件事 —— 边界核对、逐条复核、重生成需求文档。
|
||||
|
||||
---
|
||||
|
||||
## 一、三件必做的结论
|
||||
|
||||
### 1、汇总体 vs 独立体职责边界 —— **边界不正，出新版汇总**
|
||||
|
||||
判据源：`competitor-analysis.md` §0.4（分工）＋《输出检查》最后一条（「没有把独立体的内容整段抄一遍」）。
|
||||
|
||||
核出**四处硬冲突**：
|
||||
|
||||
1. 证据等级分类少一级 —— 旧汇总体写「两级：源码级 / 文档级」，新版 Easel 独立体是「源码级 ＋ 官方文档级 ＋ **界面级**」（4 张官方截图，本组唯一）。
|
||||
2. 节号引用悬空 —— 旧汇总体 附B / 附D 引「第 2 棒 §八·4」「第 3 棒 §十三·1」「《目标执行状态.md》§八」，新版独立体已统一为七节结构，这些编号不存在了。
|
||||
3. 场景矩阵越证据 —— 旧汇总体 §4 给文档级的文到 AI 逐格填了 5 个处境的用法；新版文到 AI 独立体 §3 明写「六行里三行整行取不到，没有界面级证据」。
|
||||
4. 逐家产品面重复 —— 旧汇总体 §5.1 后半的六项能力详述、§6 的六条机制，都是单家能力与机制，按 §0.4 归独立体。
|
||||
|
||||
**处置**：出新版 `1b-竞品分析-汇总对比体.md`，收紧为纯横向（竞品池分层、处境 × 竞品矩阵、能力矩阵、机制横向取向、优势不足、三类可借鉴汇总、结论、许可与缺口速查）。逐家的用途详述 / 能力详述 / 机制详述交回独立体。九条实质差别写在文末。
|
||||
|
||||
### 2、逐条复核 1a 受影响条目 —— **9 条里 2 条改、7 条不改**
|
||||
|
||||
清单外另补核 1 条（§六 治理段，因引「附卷」源，按 1a 文首口径一并核）。
|
||||
|
||||
**改的两条**：
|
||||
|
||||
- **F5** —— 旧写「敏感词与事实检测」。新版 Easel 的硬闸管的是 API key、内部路径这类**敏感信息**，软闸管的是**人设一致性**，全程没有「敏感词」也没有「事实检测」。照旧写会把②段带去做一个竞品池里没人做过的「事实核查器」。已改。
|
||||
- **F7** —— 旧写「Easel 发布中心；不做则 S4 办不成」，读起来像发布中心已能做矩阵级变体。新版证明：发布中心直证的只有**多平台**（一处编辑、八端预览），**多账号**靠 Easel 多画像加本产品矩阵需求。依据列已拆开。
|
||||
|
||||
**不改的七条**：F8、F9、F13、F10 后半、§三 三条差位、§四 后两条、§七 该抄八条与该避五条 —— 新版依据全部坐实，部分比旧版更实（F8 多了「两次独立观测」的反证；F10 后半把措辞收紧成「本组唯一闭环」）。
|
||||
|
||||
**清单外补核**：§六 治理段「组织级暂停」按新版更正为「组织级**急停**」，并把发布 / 删帖 / 急停三件事「人来做」的形态拆开写。
|
||||
|
||||
### 3、重新生成 MCN 需求文档 —— **已产出**
|
||||
|
||||
据上两条产出新版 1a，落目标目录。实质差别 9 条写在文末。
|
||||
|
||||
---
|
||||
|
||||
## 二、落点清单（全部在目标目录内）
|
||||
|
||||
| 文件 | 是什么 |
|
||||
|---|---|
|
||||
| `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/复核清单-1a受影响条目.md` | 本棒判据底稿：边界核对（§一）＋ 逐条复核（§二）＋ 清单外补核（§三） |
|
||||
| `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/1b-竞品分析-汇总对比体.md` | 新版汇总体（第二版，纯横向） |
|
||||
| `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/1a-需求文档-MCN短视频整合营销.md` | 新版 1a 需求文档 |
|
||||
| `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/S7-重生成MCN需求文档-20261007.md` | 本文件（执行记录） |
|
||||
|
||||
**只读访问的域外文件**（⛔ 未写）：`docs/pm/mcn-shortvideo-agent/research/1a-需求文档.md`、`执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/…/证据附卷/`（5 份）、同目标 `…/content-workbench/research/1b-竞品分析.md`、`E:/ProgramData/.workbuddy/skills/product-planning/…/competitor-analysis.md`、`E:/ProgramData/.workbuddy/skills/humanizer-zh/SKILL.md`。
|
||||
|
||||
⛔ **本棒未动工作区根 `docs/`、未删未覆盖任何旧文件**（旧 1a 与旧汇总体都留在原位）。
|
||||
|
||||
---
|
||||
|
||||
## 三、自检
|
||||
|
||||
### 3.1 说人话（判据源 `humanizer-zh`，门槛 ≥45/50）
|
||||
|
||||
| 交付物 | 直接性 | 节奏 | 信任度 | 真实性 | 精炼度 | 总分 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 复核清单-1a受影响条目.md | 9 | 8 | 10 | 9 | 8 | **44** |
|
||||
| 1b-竞品分析-汇总对比体.md | 9 | 9 | 10 | 9 | 9 | **46** |
|
||||
| 1a-需求文档-MCN短视频整合营销.md | 9 | 9 | 10 | 9 | 9 | **46** |
|
||||
|
||||
⚠️ 复核清单自评 **44**，低于 45 线。原因：它是一份「原文 / 依据 / 结论」三段的核账表，逐条贴原文是判据本身的要求（⛔ 不能改写成叙述体），节奏被结构固定住了。这一条**如实报出**，不当成「已过」。要不要为它专门松结构，留给主会话判。
|
||||
|
||||
### 3.2 引用核对（防止写错节号）
|
||||
|
||||
写完全部节号引用逐条回查过一遍原件，改了 3 处：
|
||||
|
||||
1. 「本地与免密钥 provider」的出处从 `OpenCreator §四 能力 6`（那是「三级记忆」）改到 `§五 机制 6`。
|
||||
2. 复核清单 §2.7 差位 1 原先引「独立体 OpenCreator §三」，但独立体里没有那张「发现热点弱」的表 —— 那话在汇总体 §4 里，已改成引汇总对比体 §4 / §8 ①。
|
||||
3. 汇总对比体 附D 的 `runtime/krillinai（Go，163 文件）` 两个数字口径混了。原始统计：`runtime/` 目录 **183 个 blob**，其中 `.go` 文件 **163 个**。已按原始件分开写。
|
||||
|
||||
顺带记一条**取证一致性**：新版 OpenCreator 独立体自身有 163 / 183 两个数并存（§三 说「Go 引擎那 163 个文件」，附录说「183 文件」）—— 两个数各有出处（163 ＝ `.go` 文件数，183 ＝ `runtime/` 目录 blob 数），但正文没写清口径，读起来像矛盾。⛔ 本棒不改别人家的独立体（不属本棒范围），只在此记账，留给主会话判要不要回头订正。
|
||||
|
||||
### 3.3 域内写检查
|
||||
|
||||
四处落盘全部在 `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/` 内。⛔ 无越界写。
|
||||
|
||||
---
|
||||
|
||||
## 四、交回主会话 / 用户的事（本棒不擅改）
|
||||
|
||||
1. **要不要把新版覆盖旧件。** 新版 1a 与新版汇总体都落在目标目录 `72111e` 内，旧件留着。若裁定应以新版**覆盖** `docs/pm/mcn-shortvideo-agent/research/1a-需求文档.md` 与 `执行会话/目标-调研…-5199a6/…/research/1b-竞品分析.md`，这两处都在本棒域外，**由主会话执行**。
|
||||
2. **目标目录的收口**。上一棒检查会话提的三条（`execution_doc` 仍指旧目标目录、判据值域「未过」、判据第 5 条与落点口径互斥）本棒未碰，仍待主会话处置。
|
||||
3. **新版 OpenCreator 独立体的 163 / 183 口径**（见 §3.2）—— 要不要回头订正，由主会话判。
|
||||
4. **复核清单的排版结构**（见 §3.1）—— 若要它过 45 线，需要主会话点头放宽「逐条贴原文」这条要求。
|
||||
|
||||
---
|
||||
|
||||
## 五、本棒没做的事（⛔ 不扩面）
|
||||
|
||||
- 不做技能包规则文件的「说人话」（那是主会话的活，且写目标在 `E:/ProgramData/.workbuddy/skills/product-planning/`，本棒域外）。
|
||||
- 不碰 `vibe-product` 工作区。
|
||||
- 不改 5 份独立体（上一棒已 done 的产物）。
|
||||
|
||||
---
|
||||
|
||||
*本记录是 1a 需求文档重生成这一棒的执行留档。判据底稿见 `复核清单-1a受影响条目.md`；新版产物见同目录另两份。*
|
||||
@@ -0,0 +1,106 @@
|
||||
# 需求文档（1a）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：拍板
|
||||
> 口径依据：`stage-discovery/references/grill-me.md`（A / B 两节决策树，全场唯一一份 grill）。
|
||||
> 改版说明：2026-10-07 按上述方法论重写 —— 决策表补「理由」「影响范围」两列、分支按 A/B 两节重新铺齐、假设与待确认项各自带归宿。与上一版的实质差别见文末。
|
||||
|
||||
**本表 23 项：已确认 15 项（用户拍板）／模型补全 8 项（7 项【假设】＋ 1 项【事实】）。7 项【假设】均未经用户确认，逐条列在 §四待复核清单。**
|
||||
|
||||
## 一、起点三句
|
||||
|
||||
做什么：一个个人用的 Web 工作台。用户在它里面建项目、在项目里开多个版本，每个版本贴入或上传需求，点一下就生成一份能直接打开的交互页面。
|
||||
|
||||
为谁：一个人。操作者就是唯一使用者，没有协作、没有角色、没有团队。
|
||||
|
||||
不做什么：进度看板、待办清单、动态流、评审流一律不做。这东西不卖、不融资、不接付费用户，所以也没有账号、订阅、权限这一层。
|
||||
|
||||
## 二、决策表
|
||||
|
||||
来源列只有三种取值：**用户拍板** / **【假设】** / **【事实】**。「影响范围」列写的是这份决策会牵动哪几份下游文档。
|
||||
|
||||
### A 节 —— 要做什么、为谁、边界在哪
|
||||
|
||||
| # | 问题 | 决策 | 来源 | 理由 | 影响范围 |
|
||||
|---|---|---|---|---|---|
|
||||
| A1 | 解决什么问题 | 需求、版本、产物现在散在三处：需求在文档里、原型在目录里、找回来靠记路径。缺一个把「建项目 → 开版本 → 贴需求 → 看页面」串成一处的入口 | 用户拍板 | 原话定位就是「为不同项目生成产品交互页面」的工作台 | 1d 价值主张、2a 全部功能 |
|
||||
| A2 | 成功怎么算 | 点完生成，页面上能出现一份可打开的 HTML，且能点回上一版对照。不设使用量、留存这类数字指标 | 【假设】 | 用户只说了「先把页面生成好」，衡量口径是我补的；本产品无数据源，不许编数字 | 1d 关键指标、2a 验收要点 |
|
||||
| A3 | 谁用、熟练到什么程度 | 单一个人。他已经在用 WorkBuddy 的产品规划技能，熟悉 `research/` `prd/` `designs/` 这套产出约定 | 用户拍板 | 定位原文即「调用产品规划技能」 | 1c 全份、1d 分节 |
|
||||
| A4 | 现在怎么凑合 | 在对话里跑技能，产出散落到各目录，靠手记或搜索认路径；同一方案改到第三轮时容易认不出哪份是哪份 | 【假设】 | 依据 A6 的落盘约定（只存项目名/需求名/版本名）反推，没有访谈佐证 | 1c 痛点、1d 价值主张 |
|
||||
| A5 | 第一版做什么 | 建项目 → 项目内建多版本 → 每版本输入或上传需求 → 点生成 → 看页面 | 用户拍板 | 原话就是这条链路 | 2a 功能清单、2b 页面清单 |
|
||||
| A6 | 明确不做什么 | 进度看板 / 待办清单 / 动态流 / 评审流；不售卖、不融资、不面向付费用户 | 用户拍板 | 原话「本产品不售卖、不融资、不面向付费用户」 | 2a「不做」对照、1d 取舍 |
|
||||
| A7 | 价值落在哪一层 | 界面为主。用户拿到的是「一份能看的页面」，约定和文件结构只是手段 | 用户拍板 | 原话「价值层：界面为主」 | 1d 价值主张、2b 页型判定 |
|
||||
| A8 | 应该有几个界面 | 3 个：项目列表 / 版本列表 / 版本工作台。每个界面只办一件事，不合并 | 用户拍板 | 原话拍了 3 页结构 | 2b 页面清单与流转 |
|
||||
| A9 | 信息承载到哪一层 | 主屏只留项目名、版本名、版本状态三样；需求全文与产物 HTML 点进去看 | 用户拍板 | 原话「只项目名称、需求名称、版本名称，点进能看」 | 2b 信息承载分档 |
|
||||
| A10 | 手上已有什么素材 | 有的：用户自己的需求文本（`.md` / `.txt`）。缺的：产品规划技能的可直接调用接口 —— 原型期用模拟顶上，真接口接进来之前，生成结果不能算真实产出 | 【假设】 | 依据 A11「先把页面生成好、其余后续再做」的排期推断 | 2a 假设台账、1d 关键假设 |
|
||||
| A11 | 约束 | 个人自用。无预算、无排期、无合规底线。唯一的时间约束是「先把页面生成好」，其余都往后放 | 用户拍板 | 原话「先把页面生成好、其余后续再做」 | 2a 优先级口径 |
|
||||
| A12 | 依赖什么 | 依赖 WorkBuddy 工作台与产品规划技能；产物落本地文件系统。不依赖任何后端服务 | 【假设】 | 依据 A13 的形态（个人 web 页面、workbuddy 工作台）＋ B7 的持久化决策 | 2a 六项治理、1d 能力 |
|
||||
| A13 | 用户现在拿什么替代 | 三条：在对话里直接跑产品规划技能；用 v0 / 即时 AI 这类文生界面工具；自己手写 HTML | 【事实】 | 来自 1b 竞品观察（两类工具的共性做法） | 1d 价值主张、1e 替代方案列 |
|
||||
|
||||
### B 节 —— 做成什么样、哪些情况不成立、状态怎么流转
|
||||
|
||||
| # | 问题 | 决策 | 来源 | 理由 | 影响范围 |
|
||||
|---|---|---|---|---|---|
|
||||
| B1 | 形态与骨架（粗粒度） | 三页。列表页＝一行操作 + 一张列表；工作台＝左边贴需求、右边看状态与产物。精确板块与排列归②段 | 用户拍板 | 原话拍了 3 页与工作台的左右分栏方向 | 2b 全份 |
|
||||
| B2 | 什么情况不成立 | 三种：需求为空 ⇒ 不给生成；技能调用失败 ⇒ 本次不成立，给出失败原因；还没建过任何项目或版本 ⇒ 先引导新建，不摆空表格 | 用户拍板 | 原话「需求为空禁用生成；技能调用失败弹提示可重试」 | 2a 守卫条件、2b 空态 |
|
||||
| B3 | 状态怎么流转 | 版本有四个状态：`draft`（草稿）→ `running`（生成中）→ `done`（已生成），任一步出错进 `failed`（失败）。`done` 可以重新生成，覆盖同一版本，不另起一个 | 用户拍板 | 原话「草稿 → 生成中 → 已生成，可重新生成」 | 2a 状态迁移表 |
|
||||
| B4 | 失败了怎么办 | 给出失败原因，给一键重试。重试停在同一个版本里，不新建版本 | 用户拍板 | 原话「弹提示可重试」 | 2a F9、2b 工作台右栏 |
|
||||
| B5 | 输入什么、产出什么、谁维护、存在哪 | 输入＝文本框，可输入也可上传 `.md` / `.txt`；产出＝单个 HTML，存 `designs/<项目>/<版本>.html`；维护人＝用户自己；存在本地 | 用户拍板 | 原话定死了路径与格式 | 2a F7/F8、2b 工作台 |
|
||||
| B6 | 权限怎么算 | 单人，没有角色系统，也没有越权这回事 | 用户拍板 | 原话「单人，无角色系统」 | 2a 六项治理 |
|
||||
| B7 | 同一件事被做两次会怎样 | 生成中按钮锁死，点不动；重新生成覆盖同一版本文件，不留重复产物 | 用户拍板 | 前半依据原话「生成按钮防重复点击」，后半的「不留重复」是我补口径 | 2a F6/F11、2a 幂等 |
|
||||
| B8 | 持久化到什么程度 | 项目、版本、需求、产物路径全部存浏览器本地，刷新和重开浏览器都不丢；清掉浏览器存储就会丢，这一条要明说 | 【假设】 | 原始决策是「浏览器本地存储即可，无需后端账号体系」，我把它展开成可判据 | 2a 六项治理、1d 风险 |
|
||||
| B9 | 生成这一步怎么实现 | 原型期用「生成过程可视 + 占位产物」模拟技能调用，留一个真接口接入点。真实接入不在本版 | 【假设】 | 原始决策是「原型期内以模拟实现」，我写清它的代价 | 2a F8、1d 关键假设 |
|
||||
| B10 | 空的时候显示什么 | 没有项目、没有版本时，列表区换成新建引导（一句话 + 主操作），不显示空表格 | 【假设】 | 原始决策已定调，我补了「不显示空表格」这一半 | 2a F3、2b 页1/页2 空态 |
|
||||
|
||||
## 三、假设台账（每条【假设】的归宿）
|
||||
|
||||
规矩：每条【假设】只能落在三种归宿里的一种 —— 已确认 / 待实现且已排定确认时机 / 已按假设落地。既没确认、又已经写进实现、还没有落地说明的，不许存在。
|
||||
|
||||
| # | 假设 | 归宿 | 说明 |
|
||||
|---|---|---|---|
|
||||
| A2 | 成功算「能拿到一份可打开的 HTML」 | ② 待实现且已排定确认时机 | 在 2a 落盘前必须问一次用户：验收是否只认「能打开」，还是要加别的 |
|
||||
| A4 | 现在靠手记或搜索认路径 | ① 已确认 | 用户拍板「只项目名称、需求名称、版本名称，点进能看」隐含认路径这件事是问题 |
|
||||
| A10 | 技能真接口暂缺、原型期用模拟 | ③ 已按假设落地 | 影响面：生成结果只是占位产物，不能当真实交付。回退口径：接上真接口后只换 F8 的生成实现，其余不动 |
|
||||
| A12 | 不依赖后端服务 | ③ 已按假设落地 | 影响面：换设备看不到自己的东西。回退口径：要跨设备时再加账号与云端存储，前端骨架不用改 |
|
||||
| B8 | 数据存浏览器本地 | ③ 已按假设落地 | 影响面：清浏览器存储等于清库。回退口径同 A12 |
|
||||
| B9 | 生成过程可视 + 占位产物 | ③ 已按假设落地 | 影响面：生成本身不产生真实页面。回退口径：同 A10 |
|
||||
| B10 | 空态用新建引导替代空表格 | ③ 已按假设落地 | 影响面：无。回退口径：无需回退，若改成空表格要回②段改 |
|
||||
|
||||
## 四、待复核清单（一次性过）
|
||||
|
||||
下面 7 条是模型补的，用户还没逐条回应。请一次看完，逐条说「可以」或「不对」：
|
||||
|
||||
1. A2 成功口径 —— 只认「能打开一份 HTML」够不够？
|
||||
2. A4 现状描述 —— 现在真是「靠手记或搜索认路径」吗？
|
||||
3. A10 技能接口 —— 是不是确实还没接、暂且用模拟？
|
||||
4. A12 后端 —— 确认不要任何后端？
|
||||
5. B8 存储 —— 存浏览器本地可以吗？（换设备会看不到）
|
||||
6. B9 生成实现 —— 原型期用模拟生成，接受吗？
|
||||
7. B10 空态 —— 空的时候用引导页替代空表格，可以吗？
|
||||
|
||||
## 五、待确认项（三字段齐全才落盘）
|
||||
|
||||
| 条目 | 复核人 | 复核时机 | 结论落点 |
|
||||
|---|---|---|---|
|
||||
| A2 成功口径 | 用户 | 2a 落盘前必须问 | `1a-需求文档.md` A2 行；若改口径，同步 `2a-产品功能.md` 的验收要点 |
|
||||
| A4 现状描述 | 用户 | 1c 定稿前 | `1c-用户画像.md` 的痛点段 |
|
||||
| A10 / B9 技能接入 | 用户 | ③段开工前（原型期结束的分界） | `1a-需求文档.md` A10 行；同步 `2a-产品功能.md` F8 |
|
||||
|
||||
## 六、这一版跟上一版的实质差别
|
||||
|
||||
上一版是 2026-10-07 01:46 的稿子，四节（做什么 / 为谁 / 明确不做什么 / 两张决策表）＋一段假设归宿。这一版逐条比下来，动了这些地方：
|
||||
|
||||
1. 决策表从 4 列改成 6 列，补上「理由」和「影响范围」。上一版只记了「拍板结果」，看不出为什么这么拍、拍了会牵动谁；下游 2a/2b 拿不到依据。
|
||||
2. 决策粒度从 13 项拆到 23 项。上一版把「界面结构」「版本状态」「数据契约」各压成一行，实际每一行里塞了两三件事；拆开后每行只回答一个问题，来源列才说得准。
|
||||
3. 分支覆盖补了四个 —— 上一版完全没有的：「素材与数据」（A10）、「约束」（A11）、「依赖」（A12）、「替代方案」（A13）。grill-me 的 A 节必问支里这四支一个都没出现。
|
||||
4. 「交付形态」这一支从隐含改成显式三问：价值在哪一层（A7）、几个界面（A8）、信息承载到哪层（A9）。上一版只有「价值层＝界面为主」一栏，另两问散在 B 节里。
|
||||
5. B 节从 4 项（B1 界面结构 / B2 版本状态 / B3 不成立条件 / B4 数据契约）扩到 10 项，补齐 grill-me B 节要求的「失败与恢复」「权限」「并发与幂等」三支，并把「持久化」「生成实现」「空态」单列。
|
||||
6. 顶部状态行从「用户拍板 9 项／模型补全 4 项」改成「已确认 15 项／模型补全 8 项（7 项【假设】＋ 1 项【事实】）」，并显式写明 7 项未经确认。上一版那句「可推翻」不等于把「未经确认」摆出来。
|
||||
7. 假设归宿段从「一句话打包」（B5–B8 已落地）改成逐条三归宿表，补影响面与回退口径。
|
||||
8. 新增 §四待复核清单与 §五待确认项三字段表 —— 上一版没有这两节，「假设」与「待定」都没有回收时机。
|
||||
9. 边界收紧：按 stage-discovery 硬约束，本份不写功能清单，B1 只给粗粒度骨架，精确板块与排列推给 2b。
|
||||
|
||||
## 七、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **47/50**：直接性 10、节奏 9、信任度 10、真实性 9、精炼度 9。
|
||||
|
||||
扣分处：决策表的「理由」列为了保持一行一条，写成了短句串，读起来略紧；「影响范围」列在大表里重复出现「2a / 2b」，可以再压。
|
||||
@@ -0,0 +1,125 @@
|
||||
# 用户画像（1c）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：外部取证（受限）
|
||||
> 口径依据：`stage-discovery/references/user-personas.md`（6 块结构与最佳实践）＋ `stage-discovery/SKILL.md` 的「用户画像必须能追到原话」硬约束。
|
||||
> 改版说明：2026-10-07 重写 —— 按方法论 6 块结构铺开、每个结论标溯源等级、把「取不到」的地方显式写出来而不是绕过去。与上一版的实质差别见文末。
|
||||
|
||||
**取证状态：本产品没有外部用户，这一份是操作者看自己。它不是用研结论，是自证。** 下面每一条都标了它现在是「原话」「判断」还是「推演」，以及将来要靠什么才能升级成事实。
|
||||
|
||||
## 一、为什么只有一张画像
|
||||
|
||||
方法论给的是 3 张画像（`user-personas.md` 的 Input 就写着「3 refined user personas」）。这里只能出 1 张，原因不是偷工：定位原文是「单一个人，无协作、无多角色、无团队」（`1a-需求文档.md` A3）。硬凑出第 2、3 张，就等于把同一个人的不同时刻包装成不同人群 —— 这类自证是这个项目已经踩过的坑（三个 JTBD 全是同一个人的三种时刻）。所以这里明说：**第 2、3 张为空，且不打算补。**
|
||||
|
||||
## 二、画像卡
|
||||
|
||||
### 画像名与背景
|
||||
|
||||
**「一个人同时压着好几个想法的产品工作者」。**
|
||||
|
||||
按方法论这里本该有年龄区间、职级、公司规模。**取不到：没有访谈、没有问卷、没有后台数据，不能编。** 能说的只有行为特征，下面四条都能在 1a 里找到出处：
|
||||
|
||||
1. 已经在用 WorkBuddy 的产品规划技能，产出落在 `research/` `prd/` `designs/` 这套约定目录里（依据 A3，用户拍板）。
|
||||
2. 自己写需求文本，格式是 `.md` 或 `.txt`（依据 B5，用户拍板）。
|
||||
3. 一个人从头管到尾，不需要把活交给别人（依据 A3）。
|
||||
4. 同一件事往往会改好几轮（依据 B3 拍了「可重新生成」与 1b 里「版本化管理」这个差异点）。
|
||||
|
||||
### 主 JTBD
|
||||
|
||||
**核心要办成的事：把手上的一个想法，变成一份能打开给人看的页面，而且旧的那几版还留着。**
|
||||
|
||||
处境和频率：坐在电脑前、脑子里已经有一版需求、要拿东西给人看的时候。频率取不到 —— **没有数据能说明他一周用几次，不编。**
|
||||
|
||||
### 三大痛点
|
||||
|
||||
方法论要求每条痛点写清影响和严重度。严重度没有量尺，这里改成「它会卡住哪一步」，这样至少可核。
|
||||
|
||||
1. **需求、版本、产物散在三处，回来时认不出哪份是哪份。**
|
||||
影响：每次重新进入都要先花一轮时间认路径。
|
||||
卡住哪一步：A5 链路的第一步「建项目」之前 —— 还没开始干，先得考古。
|
||||
来源：**推演**（依据 A4 反推，1a 里已标【假设】）。
|
||||
|
||||
2. **改到第三轮时，怕新的一版把上一版盖掉。**
|
||||
影响：想试新方向时会犹豫，或者手工复制文件。
|
||||
卡住哪一步：B3 的 `done → running` 重新生成这一步。
|
||||
来源：**推演**（依据 B3 拍了「多版本」「可重新生成」反推 —— 如果他不在意覆盖，这两条决策就不会存在）。
|
||||
|
||||
3. **生成失败时不知道问题出在需求还是技能，重来一遍又是白等。**
|
||||
影响：一次失败就打断整段思路。
|
||||
卡住哪一步：B4 失败恢复那一步。
|
||||
来源：**推演**（依据 B2「技能调用失败弹提示可重试」反推 —— 已拍板要做重试，说明失败是他预期会遇到的事）。
|
||||
|
||||
### 三大渴望
|
||||
|
||||
每条附一个「怎么算达成了」，避免写成愿望。
|
||||
|
||||
1. **想要一个固定的地方，把手上的想法一个个放进去。**
|
||||
怎么算达成：新建一次之后，下次回来能直接点进那个项目，不用先找。
|
||||
2. **想要同一个项目下能留几份并行的方案，互不干扰。**
|
||||
怎么算达成：能点开任意一版看到它当时生成的页面。
|
||||
3. **想在生成的时候看得见进行到哪一步，而不是盯着一个转圈。**
|
||||
怎么算达成：生成过程中屏幕上能说出「现在在读需求 / 在调技能 / 在出页面 / 在落盘」这类具体步骤；失败时能说出卡在哪一步。
|
||||
|
||||
第 3 条的依据来自 1b 竞品观察：同类工具普遍是「黑盒一次出图」，而本产品把「生成过程分步可见」列为差异点之一。这一条是**判断**，不是用户原话。
|
||||
|
||||
### 一条反直觉洞察
|
||||
|
||||
**他要的可能不是「更快出图」，而是「看着它出」。**
|
||||
|
||||
如果只在乎速度，那这份东西就该做成黑盒、一次给结果，越省事越好。但 1a 已经拍了「生成过程可视化」（B9），1b 也把「生成过程可见」当成差异点。反过来推：一个只想快点拿到图的人，不会为「看得见步骤」这一条付任何代价。
|
||||
|
||||
对产品决策的意义：生成过程不是装饰，它承担着「让人相信这一版是按我说的做的」这件事。所以 ③段做生成中状态时，步骤日志不能省成一根进度条。
|
||||
|
||||
**这条是推演，不是数据。** 要证伪只需要问用户一句：「生成的时候你更想看到进度条，还是更想看到他在做什么？」
|
||||
|
||||
### 产品契合评估
|
||||
|
||||
能对上的：
|
||||
|
||||
- 三页结构（1a A8）正好对着三个痛点里的前两个：项目列表收纳想法，版本列表留下并行方案。
|
||||
- 工作台左右分栏（1a B1）对着第 3 个渴望：左边是输入，右边就是「看得见那件事」的落点。
|
||||
- 生成中锁按钮（1a B7）对着第 2 个痛点：不给「手抖再点一次」的机会。
|
||||
|
||||
对不上的、会硌手的地方：
|
||||
|
||||
1. **数据只在浏览器本地**（1a B8）。换台电脑就看不到自己前面做的东西，也没有导出入口。这是他日常最容易撞上的一堵墙。
|
||||
2. **产物是 `.html` 单文件**（1a B5）。单文件好带走，但改起来只能回工作台重新生成，不能在文件上接着改。
|
||||
3. **生成结果在原型期是占位**（1a B9）。看得见过程，但拿到的东西不是真的能用的页面 —— 这一段里「能打开给人看」这个核心诉求其实没被满足。
|
||||
|
||||
## 三、溯源表（逐条）
|
||||
|
||||
| 结论 | 现在是 | 靠什么升级成事实 |
|
||||
|---|---|---|
|
||||
| 已在用产品规划技能、熟悉约定目录 | 原话（A3） | 已成立，不用升级 |
|
||||
| 需求文本是 `.md` / `.txt` | 原话（B5） | 已成立 |
|
||||
| 痛点 1：认不出哪份是哪份 | 推演（依据 A4） | 问一句「上一次回头找旧方案，你是怎么找到的」 |
|
||||
| 痛点 2：怕覆盖上一版 | 推演（依据 B3） | 问一句「上一次改方案，旧的你留了吗，存在哪」 |
|
||||
| 痛点 3：失败后白等一轮 | 推演（依据 B2） | 问一句「技能跑挂了那次，你后来怎么处理的」 |
|
||||
| 渴望 3 / 反直觉洞察：要看得见过程 | 判断（依据 1b 差异点） | 问一句「生成的时候你更想看到进度条，还是它正在做什么」 |
|
||||
| 使用频率、场景数量 | 取不到 | 需要真实使用记录，本版拿不到 |
|
||||
|
||||
按硬约束：**上面标「推演」的，不得进 1d 当事实依据。** 1d 里凡引用本份的，只能引用标「原话」的那两条，其余按【假设】处理。
|
||||
|
||||
## 四、数据缺口与补法
|
||||
|
||||
1. **没有一次真实访谈。** 补法：三条痛点各配一个「问已经发生过的事」的问题（见 §三），问完就能从推演升格成原话。不问将来会不会用，只问上一次怎么处理的。
|
||||
2. **没有行为数据。** 补法：产品上线后看本地记录 —— 但产品本来就无后端，所以这条路走不通；替代做法是从第一版原型的使用里人工记。
|
||||
3. **画像的人口学信息全空。** 补法：单用户产品其实不需要这一栏，建议直接在本份顶部声明「本画像不含人口学维度」，不要为了凑格式编年龄和职级。
|
||||
|
||||
## 五、这一版跟上一版的实质差别
|
||||
|
||||
上一版四节：主用户 / JTBD / 痛点与诉求 / 说明。这一版：
|
||||
|
||||
1. 结构换成方法论的 6 块（画像名与背景 / 主 JTBD / 三大痛点 / 三大渴望 / 一条反直觉洞察 / 产品契合评估）。上一版没有「渴望」这一块，也没有「产品契合评估」，也没有「反直觉洞察」—— 6 块里缺 3 块。
|
||||
2. **补了「为什么只有一张画像」**，并明确拒绝硬凑第 2、3 张。上一版只写了「本产品无外部用户」一句，没说方法论要的是 3 张、也没说为什么不做。
|
||||
3. 痛点从 3 条散句改成逐条带「影响」与「卡住哪一步」。上一版没有严重度这一栏，也没说它卡在链路的哪一环。
|
||||
4. **新增三大渴望**（上一版完全没有），并把第 3 条接到 1b 的差异点上。
|
||||
5. **新增反直觉洞察**，并给出证伪它的一句话问法。
|
||||
6. 新增 §三溯源表和 §四数据缺口 —— 上一版只在文末写了一句「均为推演」，没有逐条溯源，也没说怎么补。
|
||||
7. 产品契合评估里补了三条「对不上的地方」。上一版没有摩擦点与未满足需求，只有正面描述。
|
||||
8. 新增「人口学信息取不到、建议不凑格式」的显式声明 —— 上一版直接跳过了这一段。
|
||||
|
||||
## 六、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **46/50**：直接性 10、节奏 9、信任度 9、真实性 9、精炼度 9。
|
||||
|
||||
扣分处：三块结构（痛点 / 渴望 / 洞察）都用编号列，节奏偏齐；「影响」这半句在三处写法接近，可以再错开。
|
||||
@@ -0,0 +1,128 @@
|
||||
# 产品策略（1d）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：判断（依据 1a / 1b / 1c）
|
||||
> 口径依据：`stage-discovery/references/product-strategy.md`（9 节 Product Strategy Canvas ＋ 第 11/12 步「关键假设与最小验证实验」）。
|
||||
> 改版说明：2026-10-07 重写 —— 按 9 节 Canvas 逐节落，不适用的节写明为什么而不是留空，并补上关键假设与验证实验。与上一版的实质差别见文末。
|
||||
|
||||
**这份是判断，不是取证。** 每条结论后面都跟了它依据哪份文件；追不到的按【假设】处理。本产品不售卖、不面向付费用户（1a A6），所以 Canvas 里跟市场竞争、增长、成本位相关的那几节不适用 —— 下面逐节写明不适用在哪，不硬填。
|
||||
|
||||
## 一、愿景
|
||||
|
||||
**把手上的想法，变成一个能打开的东西；想改的时候，旧的还在。**
|
||||
|
||||
一句话，不展开。理由：1c 里三个痛点的根，都在「东西散着、认不出、不敢改」这一句上；愿景写长了对下游没有约束力，还会自然往「要做哪些功能」上飘。
|
||||
|
||||
## 二、市场分段
|
||||
|
||||
按问题分，不按人群分（方法论原文：「market defined by people's problems」）。
|
||||
|
||||
**唯一一段：一个人同时推着好几个想法，需求与产物散在各处，需要把它们收敛到一处的人。**
|
||||
|
||||
为什么先做这一段，也只有这一段：1a A3 定了「单一个人，无协作、无多角色、无团队」。没有第二段可以分，也不打算分 —— 一旦分，产品就要处理多角色同步，那是它明确不解决的问题（1a A6）。
|
||||
|
||||
这一段的 JTBD 与约束：见 1c 的主 JTBD 与三条痛点。⚠️ 1c 里的 JTBD 与痛点都是【推演】，按硬约束不得在本份当事实用 —— 本份凡引用 1c，只引用它标「原话」的两条（已在用产品规划技能、需求文本是 `.md`/`.txt`）。
|
||||
|
||||
## 三、相对成本
|
||||
|
||||
**不适用。** 方法论这一节问的是「像西南航空那样压成本，还是像星巴克那样做溢价」—— 那是相对于竞争对手的定位问题。本产品不售卖（1a A6），没有对手，也没有成本位可比。
|
||||
|
||||
改问一个自用的版本：**什么上省，什么上不肯省。**
|
||||
|
||||
- 省：流程复杂度、协作与权限、账号体系、进度管理（1a A6 逐条不做）。这些每一样都会把 MVP 拉长，砍掉它们换来的是「一条链路能跑通」。
|
||||
- 不肯省：生成过程可见（1b 差异点）。这一条要额外做左右分栏与步骤日志，但它是本产品区别于同类工具的地方，砍了就没剩下什么。
|
||||
|
||||
## 四、价值主张
|
||||
|
||||
按方法的四格写（What before / How / What after / Alternatives）。
|
||||
|
||||
**What before（现在什么样）**：需求写在文档里，原型落在目录里，找回上一条靠记路径或搜文件名。想试新方向时要么手工复制文件，要么把上一版盖掉。（依据 1c 痛点 1、2；⚠️ 两条均为推演）
|
||||
|
||||
**How（我们怎么给）**：把「建项目 → 开版本 → 贴需求 → 生成」串进一个工作台。项目管收纳，版本管并行，生成这一步把过程拆开摆在眼前（1a A5 / B1 / B9）。
|
||||
|
||||
**What after（给完什么样）**：点进项目就能看到自己开过几版、每版什么状态；点进任一版能看到当时那份页面；想再试一次就在同一版上重跑，不新增分支（1a B3）。
|
||||
|
||||
**Alternatives（不用它怎么办）**：三条，来自 1b 的外部取证 ——
|
||||
1. 在对话里直接跑产品规划技能。产物一样有，但没有「项目 / 版本」这层结构，回来时靠翻话题。
|
||||
2. 用 v0 / 即时 AI 这类文生界面工具。出图快，但按对话组织、不保留版本，产物绑在账号里。
|
||||
3. 自己手写 HTML。完全可控，但每次都要从零搭。
|
||||
|
||||
三条里没有一条能同时做到「有版本」和「产物能带走」，这正是本产品的站位。
|
||||
|
||||
## 五、取舍（我们不做什么）
|
||||
|
||||
列出来的每一条都是主动放弃，不是没想过。
|
||||
|
||||
1. **不做进度看板、待办、动态流、评审流**（1a A6）。加了它就会往项目管理器长，而用户要的是出页面。
|
||||
2. **不做账号体系、订阅、权限**（1a A6 / B6）。不售卖就不需要付费墙；单人就不需要角色系统。
|
||||
3. **不做跨设备同步**（1a B8）。数据存本地，换设备看不见 —— 这是主动接受的代价，写在这里是为了让它别在别处变成「意外」。
|
||||
4. **不做「在生成结果上接着改」**（1a B5）。产物是单文件 HTML 成果物，不是可编辑源。要改就回工作台重新生成。
|
||||
5. **第一版不做真技能接入**（1a B9）。原型期生成结果是占位。
|
||||
|
||||
## 六、关键指标
|
||||
|
||||
**不设 North Star 数字。** 方法论给的是「驱动业务成功的单一指标」，而本产品不售卖（1a A6），没有任何数据源，凭空给一个数字就是把判断伪装成数。
|
||||
|
||||
改成本产品能核的三条成果观察：
|
||||
|
||||
1. **链路闭环**：从项目列表一路点到生成完成，不用回到对话里做辅助动作 —— 有一条不闭环就是失败。
|
||||
2. **对照得住**：任一旧版都能点回去看到它当时的页面。
|
||||
3. **失败说得清**：任一次失败都能指出卡在哪一步，而不是只给一句「出错了」。
|
||||
|
||||
这三条都可以在原型上人工走一遍验出来，不依赖埋点。
|
||||
|
||||
## 七、增长
|
||||
|
||||
**不适用。** 方法论这一节问的是销售驱动还是产品驱动、获客渠道、单位经济模型。本产品不售卖、只有一个人用（1a A3 / A6），没有获客这回事。
|
||||
|
||||
它对 MVP 的意味只有一条：**不需要为「第一次上手」做引导层**。用户就是开发者本人，知道这套东西怎么用。所以新建引导只需要一句话加一个按钮（1a B10），不必做教程、示例数据、空状态插画。
|
||||
|
||||
## 八、能力
|
||||
|
||||
要做出这个东西，需要具备的本事：
|
||||
|
||||
1. **把产品规划技能接成一次可调用的动作**。原型期用模拟顶上（1a B9），但接入点要留出来。
|
||||
2. **把生成这一件事拆成看得见的步骤**。这是 1b 认定的差异点，也是 §三里唯一不肯省的投入。
|
||||
3. **用「项目 / 版本」组织产物落盘**，路径按 `designs/<项目>/<版本>.html`（1a B5）—— 结构错了，回看旧版这一步就废。
|
||||
4. **不做后端也能持久**：靠浏览器本地存储撑住刷新与重开（1a B8）。
|
||||
|
||||
不打算自建的：生成引擎本身、登录、云端存储。前面两个明确不做，第三个留作回退口径。
|
||||
|
||||
## 九、别人为什么抄不走
|
||||
|
||||
本产品不进入市场，所以这里问的不是商业壁垒，是**它凭什么不会被一次替换掉**：
|
||||
|
||||
1. **绑在个人工作流上。** 它和产品规划技能的产出约定（`research/` `prd/` `designs/`）咬在一起，换个工具就得重排这套约定。
|
||||
2. **产物能带走。** 单个 HTML 存本地（1a B5），不绑账号 —— 这既是用户的自由度，也意味着迁移成本低。**这一条是弱点不是壁垒，如实写在这里。**
|
||||
3. **版本语义。** 「项目 → 版本」这层结构是同类文生界面工具普遍没有的（1b 差位表），要做出来不难，但要改掉它整套组织方式。
|
||||
|
||||
⇒ 结论：**真正的护城河只有第 1 条，而且很薄。** 如实说，不硬凑三条。
|
||||
|
||||
## 十、关键假设与最小验证实验
|
||||
|
||||
方法论最后两步要求：把「这个策略要成立，必须先为真」的事挑出来，各配一个花不了多少工夫的实验。
|
||||
|
||||
| # | 关键假设 | 不成立会怎样 | 最小验证实验 |
|
||||
|---|---|---|---|
|
||||
| H1 | 用户真的会为「生成过程可见」多等一会儿（1c 反直觉洞察） | §三「不肯省」的投入白花，§二切错人，产品退化成更慢的文生界面工具 | 拿两个版本的生成中界面给他看：一根进度条 vs 逐步日志，问他要哪个。5 分钟 |
|
||||
| H2 | 「版本」这层结构他真的会用，而不是永远只留一版（1a B3 / 1b 差位） | 版本列表页与「回看旧版」整条功能都成了摆设 | 问他上一次改方案时旧的那份去哪了。1 句话 |
|
||||
| H3 | 需求文本不靠结构也能生成出像样的页面（1a B5 只收 `.md`/`.txt`） | 生成质量不可控，「界面为主」这条价值主张塌掉 | 拿一段真实的、没整理过的需求文本跑一次生成，看结果能不能看。10 分钟 |
|
||||
|
||||
三个实验都不花钱、不依赖数据源，也不需要上线。**任何一个为假，都要回到 §四重写价值主张，不是改功能清单。**
|
||||
|
||||
## 十一、这一版跟上一版的实质差别
|
||||
|
||||
上一版四节：为什么值得做 / 边界（不做）/ 假设与风险 / 取舍理由。这一版：
|
||||
|
||||
1. **节号整套换掉**，从自拟四节改成产品策略 Canvas 的 9 节（＋关键假设与验证实验）。上一版完全没有节号，看不出对应方法论的哪一节。
|
||||
2. **补了三节上一版没有的**：§二市场分段、§六关键指标、§八能力、§九防御性 —— 一共四节。其中 §六与 §九是方法论里明确要求的。
|
||||
3. **两节明确标「不适用」并说清理由**：§三相对成本、§七增长。上一版是干脆没有这两节 —— 留空和「说了不适用」是两回事，前者下游会以为漏了。
|
||||
4. **§四价值主张改成四格**（before / how / after / alternatives）。上一版是三条并列的短句，没有「替代方案」这一格，而那正是外部取证里最有信息量的一格。
|
||||
5. **补上关键假设与验证实验（§十）**：三条假设各配一个 5～10 分钟能做的实验。上一版只有一张「假设与风险」表，写了风险却没给验证动作，等于把假设永久挂着。
|
||||
6. **§九如实写了弱点**（产物可带走 ＝ 迁移成本低）。上一版没有防御性这一节，也就没有地方承认这一点。
|
||||
7. §五取舍从 2 条扩到 5 条，把「跨设备看不见」「改不了生成结果」「第一版不接真技能」这三条原本藏在别处的代价摆到前台。
|
||||
|
||||
## 十二、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **46/50**：直接性 10、节奏 9、信任度 9、真实性 9、精炼度 9。
|
||||
|
||||
扣分处：§三和 §七两节都在解释「为什么不适用」，句式接近；§九结尾为了写实话，收得比别处硬一些。
|
||||
@@ -0,0 +1,105 @@
|
||||
# 使用场景（1e）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：判断
|
||||
> 口径依据：`stage-discovery/references/usage-scenario.md`（唯一句式四槽位、六条完成判据、§5 替代方案一问）。
|
||||
> 落点说明：方法论文末写的是 `strategy/31-使用场景.md`，段入口 `stage-discovery/SKILL.md` 定的是 `research/1e-使用场景.md` —— **以段入口为准**，本份落在 `research/`。
|
||||
> 改版说明：2026-10-07 重写 —— 六条场景各补「替代方案」对照与来源追溯，并加完成判据自检表。与上一版的实质差别见文末。
|
||||
|
||||
**本份就是用户故事，一份承载全部。** 它就是②段功能清单的直接推导依据：2a 每列一项功能，都要能追回下面某一条编号；反过来，下面某条推不出任何功能，那条场景就该删。
|
||||
|
||||
## 一、格式
|
||||
|
||||
唯一句式，四个槽位缺一不算完成：
|
||||
|
||||
```
|
||||
作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】
|
||||
```
|
||||
|
||||
三条约束：「作为」里是具体身份，不写「用户」「某类人」；「当」要具体到能被观察或被原话印证，不写「经常」「有时候」；「我要办成什么」里不许出现功能名，出现就是越界到②段。
|
||||
|
||||
## 二、场景
|
||||
|
||||
### S1 启动一个新项目
|
||||
|
||||
作为【周末坐下来、手里同时压着两三个想法的我】，当【想把其中一个先立起来，而草稿还散在聊天记录和临时文件里】，我要【给这个想法一个固定的地方，后面关于它的东西都往那儿放】，这样【下次回来不用先花十分钟翻找上次说到哪】。
|
||||
|
||||
- **替代方案**：在对话里开一个新话题，或者自己新建一个目录。
|
||||
- **它为什么不简单**：话题会越堆越多，目录名靠手打、回来认不出哪个是哪个。成本随想法数量增长 —— 想法越多越乱。满足「代价随规模增长」。
|
||||
|
||||
### S2 在同一个项目里试新方向
|
||||
|
||||
作为【方案已经改到第三轮的我】，当【想试一个新方向、又不想把上一轮推翻】，我要【在同一个项目下另开一份，两份都留着】，这样【不用手工复制文件，也不用担心新改的盖掉旧的】。
|
||||
|
||||
- **替代方案**：复制文件改个名；或者用 git 分支。
|
||||
- **它为什么不简单**：复制文件会丢掉「这两份是什么关系」这件事，过两天自己也认不出；git 分支对不写代码的人门槛太高。满足「有真实成本」。
|
||||
|
||||
### S3 拿到一份能打开的页面
|
||||
|
||||
作为【要拿东西给人看的我】，当【需求已经在脑子里成型，缺的是一份能点能看的页面而不是一段文字】，我要【把需求贴进去、等一会儿拿到一份能直接打开的文件】，这样【不用自己从零画，也不用为了看一眼效果先去搭环境】。
|
||||
|
||||
- **替代方案**：用 v0 / 即时 AI 这类文生界面工具。
|
||||
- **它为什么不简单**：它们按对话组织、不保留版本，产物绑在账号里。要按项目留档、要对得上旧版时，这条路不可得。满足「不可得」。
|
||||
|
||||
### S4 生成失败之后
|
||||
|
||||
作为【点了生成却看到报错的我】，当【生成跑到一半停下来，而我分不清是需求写得不清楚还是工具本身出问题】，我要【看到卡在哪一步，然后原样再跑一次】，这样【不用重新组织一遍需求，也不会反复怀疑是自己写错了】。
|
||||
|
||||
- **替代方案**：自己把需求重新粘一遍再点一次。
|
||||
- **它为什么不简单**：如果问题在工具那侧，重贴一遍还是同样的结果，白等一轮。满足「有真实成本」。
|
||||
|
||||
### S5 回头对照旧版
|
||||
|
||||
作为【在几个方向之间摇摆的我】，当【想确认上一版到底长什么样，好决定往哪个方向走】，我要【点回那一版，看到它当时生成的页面】，这样【不用凭记忆比，也不用从文件堆里一个个捞】。
|
||||
|
||||
- **替代方案**：去 `designs/` 目录按文件名翻。
|
||||
- **它为什么不简单**：文件名不会告诉你那一版长什么样，只能逐个点开。成本随版本数增长。满足「代价随规模增长」。
|
||||
|
||||
### S6 别在没写需求时误点生成
|
||||
|
||||
作为【思路还没理清的我】，当【界面就摆在那儿，手快先点了生成】，我要【在需求还是空的时候点不动它】，这样【不会多出一份空页面，也不用手动回头删】。
|
||||
|
||||
- **替代方案**：靠自觉不点。
|
||||
- **如实说明**：这一条的替代方案就是「简单到不值一提」那一类 —— 靠自觉本来就不花成本。但这一条要防的不是「麻烦」，是「一次误点的后果」：多出一份没内容的版本，还可能覆盖掉正要用的那一版。所以判据换成「误触一次的代价」，而不是「替代方案有多麻烦」。这一条**不按「不值一提就该砍」处理**，理由已写明。
|
||||
|
||||
## 三、完成判据自检
|
||||
|
||||
方法论给了六项可机械核对的判据，逐条对：
|
||||
|
||||
| 检查项 | 判据 | 本份怎么过的 |
|
||||
|---|---|---|
|
||||
| 四槽位齐全 | 「作为 / 当 / 我要 / 这样」四词都在 | 六条全齐，无缺 |
|
||||
| 谁 | 具体身份，不是「用户」「某人」 | 六条分别是「周末坐下来…的我」「改到第三轮的我」「要拿东西给人看的我」「看到报错的我」「在几个方向之间摇摆的我」「思路还没理清的我」 |
|
||||
| 处境 | 能追到 1a 某一行或一句原话 | 见 §四溯源表，六条全部可追 |
|
||||
| 办成什么 | 零功能名 | 逐条查过：没出现「项目列表」「版本列表」「工作台」「生成按钮」这类功能名；「生成」在 S3/S4 里指的是这件事本身，不是按钮名 |
|
||||
| 得到什么 | 写的是少掉的麻烦，不是愿景 | 六条的「这样」全部落在「少花时间 / 少出错 / 不用记」，无一条写愿景或 North Star |
|
||||
| 可读性 | 能原样念给用户听 | 六条都用日常说法写的，没有内部术语 |
|
||||
|
||||
## 四、来源追溯
|
||||
|
||||
| 场景 | 处境从哪来 | 办成的事从哪来 |
|
||||
|---|---|---|
|
||||
| S1 启动一个新项目 | 1a A4（现在靠手记或搜索认路径，【假设】）＋ A5（链路第一步） | 1a A5「建项目」；1a A1（把链路的头一段串起来） |
|
||||
| S2 试新方向 | 1c 痛点 2（怕覆盖上一版，【推演】） | 1a A5「项目内建多版本」；1a B3「可重新生成」 |
|
||||
| S3 拿到页面 | 1a A7（价值层＝界面为主，用户拍板） | 1a A5「输入需求 → 点生成 → 看页面」；A13 替代方案 |
|
||||
| S4 失败之后 | 1c 痛点 3（失败后白等，【推演】） | 1a B2「技能调用失败弹提示可重试」；B4「失败原因 + 一键重试」 |
|
||||
| S5 对照旧版 | 1c 痛点 1（认不出哪份是哪份，【推演】） | 1a A9「点进能看」；B3「多版本留着」 |
|
||||
| S6 别误点 | 1a B2「需求为空禁用生成」（用户拍板） | 同左；1a B7「生成按钮防重复点击」 |
|
||||
|
||||
⚠️ S1 / S2 / S4 / S5 的处境依据是 1c 的【推演】与 1a 的【假设】。按硬约束，这些**不进 1d 当事实**；本份只把它们当作「待验证的处境」，验证方式见 `1c-用户画像.md` §四。
|
||||
|
||||
## 五、这一版跟上一版的实质差别
|
||||
|
||||
上一版是六条场景加一段说明。这一版：
|
||||
|
||||
1. **每条场景补了「替代方案」与「它为什么不简单」**。方法论 §5 明说这一问最有杀伤力（「如果替代方案简单到不值一提，这个问题就不值得做」），上一版一条都没有 —— 等于把唯一的证伪机制省掉了。
|
||||
2. **S6 显式处理了「替代方案确实简单」这个矛盾**，没有硬套判据蒙过去，而是换成「误触一次的代价」并写明理由。上一版没有这一层。
|
||||
3. **新增 §三完成判据自检表**（六项逐条给结论）。上一版只在文末声明「四条槽位均齐」，没有逐项核对，也没有「零功能名」这条的核查记录。
|
||||
4. **新增 §四来源追溯表**。上一版没有说每条场景的处境是从哪条决策推出来的，2a 要追来源时只能反猜。
|
||||
5. 处境从偏抽象改成具体可观察：S1 从「我有一个新想法要验证」改成「周末坐下来、手里压着两三个想法、草稿散在聊天记录里」；S2 从「我在项目里想试不同方案」改成「方案已经改到第三轮」。
|
||||
6. 加了「谁」这一槽位的具体化：上一版六条的「作为」全是同一句「作为【个人产品工作者】」，等于没写——它是个职业标签，正是方法论点名不许写的那种。
|
||||
|
||||
## 六、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **48/50**：直接性 10、节奏 10、信任度 9、真实性 10、精炼度 9。
|
||||
|
||||
扣分处：六条场景的句式天然相同（这是方法论定死的），节奏上靠「替代方案」两行来错开，仍显整齐；S6 的说明段为了把道理讲透，比其余几条长。
|
||||
@@ -0,0 +1,134 @@
|
||||
# 产品功能（2a）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：功能清单
|
||||
> 口径依据：`stage-requirements/references/create-prd.md`（功能六字段、优先级判据、不做清单对照）＋ `state-machine.md`（六项治理）。
|
||||
> 改版说明：2026-10-07 重写 —— 功能按使用场景重新组织、补齐状态迁移表与六项治理落点、修掉上一版把状态流转整段外挂的结构问题。与上一版的实质差别见文末。
|
||||
|
||||
**这份只管一件事：做哪些功能、哪些明确不做、每条什么优先级。** 页面长什么样是 `2b-界面布局.md` 的事，本份不描述页面结构。需求本身在①段定完了，本份不重开需求。
|
||||
|
||||
起点三句（给下游快速对齐用，不展开）：一个人用的 Web 工作台；链路是建项目 → 开版本 → 贴需求 → 生成 → 看页面；不卖、不协作。
|
||||
|
||||
## 一、功能清单
|
||||
|
||||
按使用场景组织（依据 `1e-使用场景.md` 的 S1–S6），⛔ 不按页面组织 —— 一条场景下的功能可能跨好几页，按页面切会把跨页场景切碎。
|
||||
|
||||
每条功能带六个字段：功能名、来自哪条场景、优先级、状态流转、验收要点、跨哪些页面。优先级判据是一句话，不填数字：
|
||||
|
||||
- **P0**：不做，这条场景整条办不成。
|
||||
- **P1**：不做，场景能办成但要多绕（本该一次点击，变成三步）。
|
||||
- **P2**：不做不影响办成，只是更好用。
|
||||
|
||||
### S1 启动一个新项目 → 3 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F1 新建项目 | P0 | 无状态 | 输入项目名并确认后，列表首行出现该项目 | 项目列表 |
|
||||
| F2 进入项目 | P0 | 无状态 | 点项目行，进到该项目的版本列表 | 项目列表 → 版本列表 |
|
||||
| F3 空态引导新建 | P1 | 无状态 | 一个项目都没有时，列表区显示「一句话 + 新建主操作」，不出现空表格 | 项目列表 |
|
||||
|
||||
### S2 在同一个项目里试新方向 → 3 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F4 新建版本 | P0 | 无状态 | 在项目内输入版本名后，版本列表出现该版本，初始为 `draft` | 版本列表 |
|
||||
| F5 进入版本工作台 | P0 | 无状态 | 点版本行，进到该版本的工作台，左右两栏按当前状态显示 | 版本列表 → 版本工作台 |
|
||||
| F6 重新生成 | P2 | `done` → `running` | 已生成过的版本可重跑，结果覆盖同一版本文件，版本数不变 | 版本工作台 |
|
||||
|
||||
### S3 拿到一份能打开的页面 → 2 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F7 输入或上传需求 | P0 | 无状态 | 文本框可直接输入；选中 `.md` / `.txt` 后内容进文本框；其他后缀不读 | 版本工作台 |
|
||||
| F8 生成产品交互页面 | P0 | `draft` → `running` → `done` | 点生成后能逐步看到进行到哪一步；结束后产出单个 HTML 存 `designs/<项目>/<版本>.html` 并可预览 | 版本工作台 |
|
||||
|
||||
### S4 生成失败之后 → 1 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F9 失败原因与重试 | P1 | `failed` → `running` | 失败时显示卡在哪一步；一键重试从原处重跑，停在同一个版本里，不新建版本 | 版本工作台 |
|
||||
|
||||
### S5 回头对照旧版 → 1 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F10 回看已生成页面 | P1 | 无状态 | 已生成过的版本，点进去能在产物区看到当时那份页面 | 版本工作台 |
|
||||
|
||||
### S6 别在没写需求时误点生成 → 1 条功能
|
||||
|
||||
| 功能名 | 优先级 | 状态流转 | 验收要点 | 跨哪些页面 |
|
||||
|---|---|---|---|---|
|
||||
| F11 防误生成与防重复 | P0 | 无状态 | 需求为空时生成不可用；`running` 期间生成不可用 | 版本工作台 |
|
||||
|
||||
**合计 11 条功能，全部能追回 S1–S6，追不回的有 0 条。**
|
||||
|
||||
## 二、状态迁移表
|
||||
|
||||
状态空间集中在生成这一条链上（F8 / F9 / F6 共用），其余功能无状态。状态名用英文小写下划线，便于③段直接落到代码。
|
||||
|
||||
| 状态 | 含义 | 允许事件 | 守卫条件 | 迁移到 | 副作用 |
|
||||
|---|---|---|---|---|---|
|
||||
| `draft` | 版本已建，没生成过 | `generate` | 需求非空 | `running` | 记下本次需求快照；清掉上一次的失败原因 |
|
||||
| `running` | 生成中 | `done` / `fail` / `timeout` | — | `done` / `failed` / `failed` | 产物区逐步写步骤日志；生成入口锁住 |
|
||||
| `failed` | 上次生成失败 | `retry` | 需求仍在 | `running` | 记下失败原因；需求原文保留不动 |
|
||||
| `done` | 已有可用产物 | `regenerate` | 需求非空 | `running` | 覆盖同一版本文件；版本数不变 |
|
||||
|
||||
不在某一行里的事件一律视为非法，显式拒绝，不静默忽略。四个状态都有出口，`done` 也不是终点（能再 `regenerate`）。没有「其他」「未知」这类兜底状态，也没有无触发事件的自动漂移 —— 唯一的时间驱动是 `timeout`，它已在上表显式登记。
|
||||
|
||||
## 三、六项治理（逐条落点）
|
||||
|
||||
**失败恢复**：每个失败态只给一条路 —— 手动重试（F9）。不做自动重试：重试会再调一次技能，连环失败时自动重试会把一次故障放大成多次等待。入口就是失败态下的重试按钮。
|
||||
|
||||
**持久化**：项目、版本、需求文本、产物路径全部存浏览器本地（依据 1a B8 · 【已按假设落地】）。刷新页面、关掉再开都不丢。**清掉浏览器存储就等于清库，这一条必须让用户知道**（回退口径：要跨设备时再加账号与云端存储，前端骨架不用改）。
|
||||
|
||||
**并发冲突**：单人使用，不存在两个入口同时改同一条数据（依据 1a B6）。唯一要防的是自己盖自己 —— `running` 期间生成入口锁住（F11），守卫条件在状态迁移表里。
|
||||
|
||||
**幂等**：同一版本重复触发生成，结果落到同一个文件，不产生第二份产物（F6 覆盖口径）。`running` 期间的重复点击被守卫拦下，不会真的跑两次。
|
||||
|
||||
**超时迁移**：`running` 超过阈值归入 `failed`，并带上「超时」作为原因（F9 展示）。⚠️ **阈值是多少，本版定不了** —— 原型期生成是模拟的，等真技能接进来才谈得上定阈值。这是【假设】，已登记在 §五，接入真实技能前必须先问。
|
||||
|
||||
**不可逆二次确认**：本版没有删除、发布、扣费类操作（删除不在范围，1a A6），这一项**不适用**。唯一一处不可逆是「重新生成覆盖同版本已生成的产物」——成品被覆盖后拿不回来。原型期不加二次确认，理由是需求原文还留着，重跑就能再得一份。这一条按【假设】处理，登记在 §五。
|
||||
|
||||
## 四、「不做 / 移出」逐条对照
|
||||
|
||||
规矩是：涉及已拍板项的，不得自行裁剪，必须列差异。本清单与 `1a-需求文档.md` 的 **15 项用户拍板条目**逐条对过，**差异 0 条**。另外与 1a 的 **7 项【假设】**逐条对过，落在 2a 的有 4 项（重试幂等 / 覆盖口径 / 持久化 / 生成实现），已在对应条目里带上状态标注。
|
||||
|
||||
对照明细：
|
||||
|
||||
1. **进度看板 / 待办 / 动态流 / 评审流** —— 与 1a A6 一致，不进入功能清单。
|
||||
2. **多角色 / 账号体系 / 云端同步** —— 与 1a A3 / B6 / B8 一致，不进入。
|
||||
3. **删除版本或项目** —— 1a A6 未列此项，本份也不加；如需删，要回①段补决策，不在②段自行加。
|
||||
4. **在生成结果上继续编辑** —— 1a B5 定了产物是单文件成果物，故不做编辑器。
|
||||
|
||||
## 五、假设台账
|
||||
|
||||
从①段带进来的每条【假设】，在本份逐条给结论。只允许三种归宿：已确认 / 待实现且已排定确认时机 / 已按假设落地。
|
||||
|
||||
| 假设 | 本份的结论 | 归宿 |
|
||||
|---|---|---|
|
||||
| A10 技能接口暂缺、原型期用模拟生成 | F8 的生成实现按模拟写，接入点留出 | ③ 已按假设落地（影响面：生成结果是占位产物。回退口径：只换 F8 的实现，其余不动） |
|
||||
| A12 不依赖后端 | 持久化那一条按本地存储写 | ③ 已按假设落地 |
|
||||
| B8 数据存浏览器本地 | §三 持久化照此写，并把「清存储即清库」显式写出 | ③ 已按假设落地 |
|
||||
| B9 生成过程可视 + 占位产物 | F8 的验收要点含「逐步看到进行到哪一步」 | ③ 已按假设落地 |
|
||||
| B10 空态用引导替代空表格 | F3 照此写 | ③ 已按假设落地 |
|
||||
| **超时阈值**（本份新增） | 状态迁移表里 `timeout` 已登记，阈值留空待定 | ② 待实现且已排定确认时机（**真技能接入前必须问**，结论落 `2a-产品功能.md` §二） |
|
||||
| **重新生成不做二次确认**（本份新增） | 按「需求原文还在、重跑即可」处理 | ② 待实现且已排定确认时机（**③段做交互前必须问**，结论落 `2a-产品功能.md` §三） |
|
||||
|
||||
## 六、这一版跟上一版的实质差别
|
||||
|
||||
上一版是 2026-10-07 01:47 的稿子：一张 10 行的功能大表（功能 / 来自场景 / 优先级 / 状态流转 / 验收要点 / 跨页）＋一段状态流转 ＋一段六项治理 ＋一段不做对照 ＋一段假设标注。这一版：
|
||||
|
||||
1. **功能清单从一张大表拆成六张，按使用场景分组**。上一版是「一张表按 F 编号排下来」，虽然带了「来自场景」列，但组织方式仍是按编号；现在每条场景一个小节，跨页场景不再被 F 编号切碎。
|
||||
2. **补了 F3 空态引导新建**。1a B10 拍了「空态用引导替代空表格」，但上一版的功能清单里**根本没有对应功能** —— 一条已拍板的形态决策没有落点。
|
||||
3. **功能从 10 条变 11 条**（新增 F3；原 F3–F10 顺延为 F4–F11）。
|
||||
4. **状态流转从中文改成英文小写下划线**（`draft` / `running` / `failed` / `done`），并按方法论的状态迁移表补齐了 6 列：状态 / 含义 / 允许事件 / 守卫条件 / 迁移到 / 副作用。上一版只有两句文字描述（「正常：草稿 → 生成中 → 已生成」），没有守卫条件，也没有副作用。
|
||||
5. **状态从「每个功能自带」改成「集中在迁移表」**。上一版把「状态流转」写进每一行，`F7 防误生成` 那行的状态流转写的是「无状态」，但它的守卫条件其实是生成态的守卫 —— 分散写导致这条被记错位置。现在守卫条件统一在迁移表里，功能表只指向它。
|
||||
6. **六项治理每条给了具体落点与理由**。上一版 6 条各一句话，其中「超时迁移」写的是「生成超过阈值归入失败态」而没写阈值从哪来；本版明确标出阈值待定并登记为待确认项。
|
||||
7. **「不做」对照给出对照条目数与明细 4 条**。上一版只写「对照 10 项，差异 0」，没有列出对的是哪些项；本版写出对照的条目数（15 项拍板 + 7 项假设）与 4 条明细，并把「删除」「编辑产物」两条新增的不做项标明出处。
|
||||
8. **假设台账从 1 行扩到 7 行**，补上超时阈值与二次确认两条本份新增的假设，且都带确认时机与结论落点。上一版只有 F6 一条。
|
||||
9. **拿掉了「六项治理整合进功能条目」这句自我说明**。上一版标题写「六项治理（状态机整合进功能条目）」，但实际是独立成段、没整合进去 —— 说法和做法对不上，本版改成如实的一节。
|
||||
|
||||
## 七、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **46/50**：直接性 10、节奏 9、信任度 9、真实性 9、精炼度 9。
|
||||
|
||||
扣分处：六张功能表体例相同，读起来是一串整齐的短句；§四对照那一段为了说清「对过哪些项」写得比别处密。
|
||||
@@ -0,0 +1,130 @@
|
||||
# 界面布局（2b）
|
||||
|
||||
> 项目：`proto-board`｜更新：2026-10-07｜性质：页面骨架
|
||||
> 口径依据：`stage-requirements/SKILL.md`（②—③交界：②段钉骨架、③段做皮肉）＋ `create-prd.md` §二（布局五样、信息承载分档、页型一句）。
|
||||
> 改版说明：2026-10-07 重写 —— 补页型判定、每页一句话、流转条件，并把信息分档的判据逐条答出来。与上一版的实质差别见文末。
|
||||
|
||||
**这份只管骨架：有哪几页、每页几个板块、板块怎么排、页与页怎么跳、每条信息放在哪一档。** 配色、字体、间距、组件样式、动效一个字都不写 —— 那是③段。功能条目的有无与优先级是 `2a-产品功能.md` 的事，本份不碰。
|
||||
|
||||
## 一、页型判定
|
||||
|
||||
**工具型页面。** 依据：用户每次进来是把一件事干完（贴需求、等生成、回头看旧版），不是看一眼就下决心买什么；产品定位里也没有营销或售卖这一层（1a A6）。
|
||||
|
||||
判型只写这一句。⛔ 不写「用哪个骨架」「哪个区块」—— 那是③段按设计方向定的事。
|
||||
|
||||
这一句为什么必须写：③段的版式供给偏落地页向。不说页型，③段就会套错骨架，做出「一行小字 + 大标题 + 一行灰字」那种样子 —— 判据全绿，但一看就不是工作台。
|
||||
|
||||
## 二、页面清单
|
||||
|
||||
三页，由 1a A8 定死，不加不减。
|
||||
|
||||
1. **项目列表页** —— 进门那一页。看自己开过哪些项目，以及新建一个。
|
||||
2. **版本列表页** —— 某个项目里面的样子。看这个项目开过几版、每版什么状态，以及新建一版。
|
||||
3. **版本工作台页** —— 干活的那一页。左边贴需求和点生成，右边看它进行到哪一步、结果是什么。
|
||||
|
||||
## 三、页面流转
|
||||
|
||||
- 项目列表 →（点某个项目的行）→ 版本列表。
|
||||
- 版本列表 →（点某个版本的行）→ 版本工作台。
|
||||
- 版本工作台 →（点面包屑上的项目名）→ 回到版本列表；→（点面包屑的根）→ 回到项目列表。
|
||||
- 新建项目这个动作发生在项目列表页的操作行；新建版本发生在版本列表页的操作行 —— 两处都不跳页，就地建完回到同一页的列表里。
|
||||
- 三页共用一个顶栏（左产品名、右当前位置），所以无论跳到哪一页，都看得见自己在哪、怎么退回去。
|
||||
|
||||
流转条件只有「点哪一行去哪一页」，没有隐藏入口，也没有需要满足前置条件才放行的跳转。
|
||||
|
||||
## 四、每页的板块与排列
|
||||
|
||||
灰块粒度：只讲有哪些块、从上到下怎么排，不讲长什么样。
|
||||
|
||||
### 页 1 · 项目列表
|
||||
|
||||
1. 顶栏：左边是产品名，右边是「当前位置：根」。
|
||||
2. 操作行：左边是「项目」这个标题，右边是新建项目的主操作。
|
||||
3. 项目列表：一行一个项目，每行是项目名 + 版本数 + 最近更新时间 + 一个「进去」的指示。
|
||||
|
||||
主操作：新建项目（在操作行右侧）。次一级的动作是点整行进项目 —— 整行可点，不另设按钮。
|
||||
|
||||
空态：一个项目都没有时，列表区换成新建引导（一句话 + 新建项目的主操作），不摆一张空表格。
|
||||
|
||||
### 页 2 · 版本列表
|
||||
|
||||
1. 顶栏：左边是产品名，右边是面包屑「项目名」。
|
||||
2. 操作行：左边是这个项目的名字（当标题用），右边是新建版本的主操作。
|
||||
3. 版本列表：一行一个版本，每行是版本名 + 状态 + 最近更新时间 + 一个「进去」的指示。
|
||||
|
||||
主操作：新建版本（在操作行右侧）。次一级是点整行进工作台。
|
||||
|
||||
空态：这个项目还没开过版本时，列表区换成新建引导。
|
||||
|
||||
### 页 3 · 版本工作台
|
||||
|
||||
1. 顶栏：左边是产品名，右边是面包屑「项目名 / 版本名」。
|
||||
2. 主工作区，左右两栏（窄屏上下堆叠）：
|
||||
- 左栏是需求输入区：需求文本框、上传入口（只认 `.md` / `.txt`）、生成主操作，外加一个演示用的「模拟失败」入口。
|
||||
- 右栏是状态与产物区，按当前状态换内容：`draft` 显示提示语；`running` 显示步骤日志；`failed` 显示失败原因加重试；`done` 显示产物预览加重新生成。
|
||||
|
||||
主操作：生成（需求非空、且不在 `running` 时可用）；失败态下变成重试；已生成态下变成重新生成。
|
||||
|
||||
## 五、信息承载分档
|
||||
|
||||
判据只有一条：**删掉它，主操作还做得成吗。** 答「做得成」的，只能进「可点入」。不许拿「能读到」「将来可能需要」当理由把它留在主屏。
|
||||
|
||||
| 信息 | 分档 | 判据回答 |
|
||||
|---|---|---|
|
||||
| 项目名 | 主屏常驻 | 删掉就选不了项目，主操作做不成 |
|
||||
| 版本名 | 主屏常驻 | 删掉就选不了版本，主操作做不成 |
|
||||
| 版本状态 | 主屏常驻 | 删掉就不知道该不该点进去，主操作做不成 |
|
||||
| 需求全文 | 可点入（只在工作台左栏） | 删掉仍能选版本、仍能生成 —— 生成时才需要它 |
|
||||
| 产物 HTML | 可点入（只在工作台右栏预览） | 删掉不影响生成这个动作本身 |
|
||||
| 失败原因 | 可点入（失败态才出现在右栏） | 删掉仍能点重试；它服务的是「知道卡在哪」，不是主操作本身 |
|
||||
|
||||
前面三条是 1a A9 拍板的主屏三样，一条都不多。需求全文与产物都走「点进去看」。
|
||||
|
||||
## 六、窄屏怎么变
|
||||
|
||||
只写布局怎么动，不写视觉。
|
||||
|
||||
- 三页顶栏收成一行，面包屑用「/」紧凑排开。
|
||||
- 页 3 的左右两栏改上下堆叠：输入区在上，状态与产物区在下。
|
||||
- 列表行在窄屏仍是单行一条，需要时把版本数、更新时间折到下一行，但不丢信息。
|
||||
|
||||
## 七、骨架五样自检
|
||||
|
||||
| 要给的 | 在哪一节 | 结论 |
|
||||
|---|---|---|
|
||||
| 页面清单 | §二 | 3 页，每页一句话 |
|
||||
| 页面流转 | §三 | 5 条跳转，全部带条件 |
|
||||
| 每页板块与排列 | §四 | 三页逐页给出块序 |
|
||||
| 每页主操作 | §四 各页末 | 三页各一个主操作 |
|
||||
| 每条信息的分档 | §五 | 6 条信息逐条给判据回答 |
|
||||
|
||||
## 八、假设台账
|
||||
|
||||
从①段带进来的假设里，落在骨架上的有两条，逐条给结论。
|
||||
|
||||
| 假设 | 本份的结论 | 归宿 |
|
||||
|---|---|---|
|
||||
| B10 空态用引导替代空表格 | 页 1、页 2 的空态照此写 | ③ 已按假设落地（影响面：无。回退口径：改成空表格要回②段改本份） |
|
||||
| B9 生成过程可视 + 占位产物 | 页 3 右栏 `running` 一段写成步骤日志，不是一根进度条 | ③ 已按假设落地（影响面：`running` 这段要有位置承载多条步骤。回退口径：只换这一块内容，骨架不动） |
|
||||
|
||||
依据假设得出的骨架点已带上状态标注（见页 3 右栏与两处空态）。⛔ 全文零视觉词。
|
||||
|
||||
## 九、这一版跟上一版的实质差别
|
||||
|
||||
上一版是 2026-10-07 01:47 的稿子：页面清单 / 页面流转 / 页面内布局（三页）/ 信息承载分档 / 窄屏变化，共五节。这一版：
|
||||
|
||||
1. **补了页型判定（§一）**。上一版完全没有这一节，而 `create-prd.md` 明写「页型一句（仍需写）」，并给了理由：不说页型，③段会套错骨架。这是上一版最实的一处漏。
|
||||
2. **页面清单从只有页名改成页名 + 一句话说清每页干什么**。上一版页名后面跟的是「（入口）」「（＝项目详情，由 B1 命名）」这类注，是结构说明不是职责说明。
|
||||
3. **页面流转补上条件与返回路径**。上一版写了「点行 → 跳转」和面包屑回退，但没写「新建动作发生在哪一页、建完停在哪」，也没说这些跳转不需要前置条件。
|
||||
4. **每个板块标了序**。上一版页 1、页 2 的板块是编号列，页 3 是缩进散列；这一版三页统一按从上到下的序号排，且把「顶栏」明确写进每页第 1 块。
|
||||
5. **信息承载分档补上「失败原因」一条**（上一版只有 4 条），并把判据回答写全 —— 上一版有判据回答，但用的是「删掉它主操作还做得成吗」这一句当标题、下面对每条给的是结论式短语，没把「为什么做得成 / 做不成」说清。
|
||||
6. **主操作从三处散写收成每页末一行**。上一版在页面内布局里写了「主操作」，又在信息分档里重述了一遍状态与预览的位置，同一件事写了两遍。本版按「同一件事只写一遍」收敛。
|
||||
7. **新增 §七骨架五样自检表**，把方法论要求的五样逐条对账，上一版没有这一层对账。
|
||||
8. **新增 §八假设台账**。上一版完全没有继承①段的假设 —— `2a` 里带了假设标注，`2b` 一个字没有，同一个段里两份文档两种做法。
|
||||
9. 删掉了上一版文末那句「（判据：删掉它主操作还做得成吗）」的重复标题。
|
||||
|
||||
## 十、说人话评分
|
||||
|
||||
已过内容准则（`humanizer` / `humanizer-zh`），评分 **46/50**：直接性 10、节奏 9、信任度 9、真实性 9、精炼度 9。
|
||||
|
||||
扣分处：§四三页的板块列都是「几号 + 名词」的短条目，节奏偏平；§五判据回答列为了对齐写法，六行结构接近。
|
||||
@@ -0,0 +1,75 @@
|
||||
# 落点说明 · vibe-product 六份①②段文档新稿
|
||||
|
||||
> 产出：第 10 棒任务会话 `[执行]-[开源项目调研]-vibe-product六份阶段文档重写新稿`（排期 `e012f7d6`，域 `content_marketing_agent/执行会话`）
|
||||
> 时间：2026-10-07 23:3x｜目标：`执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/`
|
||||
|
||||
## 一、新稿 → 源路径，逐条对应
|
||||
|
||||
六份新稿全部落在本目录下的 `vibe-product六份-新稿/`，文件名与源文件**逐字相同**。
|
||||
|
||||
| # | 新稿（本目录内） | 源（⛔ 全程只读，未改动一个字节） |
|
||||
|---|---|---|
|
||||
| 1 | `vibe-product六份-新稿/1a-需求文档.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/research/1a-需求文档.md` |
|
||||
| 2 | `vibe-product六份-新稿/1c-用户画像.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/research/1c-用户画像.md` |
|
||||
| 3 | `vibe-product六份-新稿/1d-产品策略.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/research/1d-产品策略.md` |
|
||||
| 4 | `vibe-product六份-新稿/1e-使用场景.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/research/1e-使用场景.md` |
|
||||
| 5 | `vibe-product六份-新稿/2a-产品功能.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/prd/2a-产品功能.md` |
|
||||
| 6 | `vibe-product六份-新稿/2b-界面布局.md` | `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/prd/2b-界面布局.md` |
|
||||
|
||||
源六份的 mtime 仍是 `01:46`（1a/1c/1d/1e）与 `01:47`（2a/2b），本棒未触碰。
|
||||
|
||||
## 二、②段两份在哪找到的
|
||||
|
||||
派活原文说「在该目录子树内自行定位」。实测结果：**都在，没缺**。
|
||||
|
||||
- `docs/pm/proto-board/prd/2a-产品功能.md`（3034 B，mtime 01:47）
|
||||
- `docs/pm/proto-board/prd/2b-界面布局.md`（3383 B，mtime 01:47）
|
||||
|
||||
⇒ 不需要写「源缺失」。
|
||||
|
||||
## 三、按什么判据重写
|
||||
|
||||
| 份 | 方法论载体（只读） |
|
||||
|---|---|
|
||||
| 1a | `stage-discovery/references/grill-me.md`（A/B 两节决策树、决策表 6 列、假设三归宿、待确认三字段） |
|
||||
| 1c | `stage-discovery/references/user-personas.md`（6 块结构）＋ `stage-discovery/SKILL.md`「必须能追到原话」 |
|
||||
| 1d | `stage-discovery/references/product-strategy.md`（9 节 Canvas ＋ 第 11/12 步验证实验） |
|
||||
| 1e | `stage-discovery/references/usage-scenario.md`（四槽位、六条完成判据、§5 替代方案） |
|
||||
| 2a | `stage-requirements/references/create-prd.md`（六字段、优先级判据、不做对照）＋ `state-machine.md`（六项治理） |
|
||||
| 2b | `stage-requirements/SKILL.md`（②—③交界）＋ `create-prd.md` §二（布局五样、信息分档、页型一句） |
|
||||
|
||||
段入口：`stage-discovery/SKILL.md`、`stage-requirements/SKILL.md`。
|
||||
说人话判据源：`E:/ProgramData/.workbuddy/skills/humanizer-zh/SKILL.md`＋`session-mechanism/references/作业规矩/04-去AI味与说话方式.md`。
|
||||
|
||||
## 四、逐份做了什么（一句话）
|
||||
|
||||
1. **1a**：决策表 4 列 → 6 列（补理由、影响范围）；决策从 13 项拆到 23 项；补 A 节缺的四个必问支（素材与数据 / 约束 / 依赖 / 替代方案）；「交付形态」从隐含改成显式三问；B 节从 4 项扩到 10 项；新增待复核清单与待确认三字段表。
|
||||
2. **1c**：结构换成方法论 6 块（原缺渴望 / 反直觉洞察 / 产品契合评估 3 块）；说明为什么只有 1 张画像而不是 3 张；痛点补影响与「卡住哪一步」；新增溯源表与数据缺口。
|
||||
3. **1d**：节号整套换成 9 节 Canvas；补市场分段 / 关键指标 / 能力 / 防御性四节；两节明确标「不适用」并给理由（相对成本、增长）；价值主张改成 before/how/after/alternatives 四格；补三条关键假设与各配一个最简验证实验。
|
||||
4. **1e**：六条场景各补「替代方案 + 它为什么不简单」；S6 显式处理「替代方案确实简单」这个矛盾；新增完成判据自检表与来源追溯表；「作为」槽位从同一句职业标签改成六个具体身份。
|
||||
5. **2a**：功能表从一张大表拆成六张、按使用场景分组；补 **F3 空态引导新建**（1a B10 已拍板但上一版无落点），功能 10 → 11；状态流转改英文小写下划线并补齐 6 列迁移表（含守卫条件与副作用）；六项治理逐条给落点与理由；不做对照给对照条目数与 4 条明细；假设台账 1 行 → 7 行。
|
||||
6. **2b**：补**页型判定**（工具型页面 —— 上一版完全缺失，方法论明写必写）；页面清单补每页一句话；流转补条件与新建停位；信息分档补「失败原因」一条并把判据回答写全；新增骨架五样自检表与假设台账。
|
||||
|
||||
## 五、硬约束逐条对账
|
||||
|
||||
| # | 要求 | 结论 |
|
||||
|---|---|---|
|
||||
| 1 | 重写 ≠ 润色：内容层真改、按方法论节号重排，文末写明「与上一版的实质差别」逐条列 | ✅ 六份文末各有该节，合计列出实质差别 48 条（1a 9 / 1c 8 / 1d 7 / 1e 6 / 2a 9 / 2b 9，逐份现数） |
|
||||
| 2 | 落盘文字过说人话，门槛 ≥45/50，每份文末写评分（五维） | ✅ 六份评分：1a 47、1c 46、1d 46、1e 48、2a 46、2b 46（均五维分列） |
|
||||
| 3 | 半成品按失败交付，不许当完成上报 | ✅ 六份均写全（各自文末的实质差别与评分都在位），无半成品 |
|
||||
| 4 | 收口命令带 tid 位置参数，`done` 带 `--artifact` | ✅ 收口命令见 §七，`--artifact` 指本文件 |
|
||||
| 5 | 落地到 vibe-product 不由本棒做，写 `NEED-USER.md` | ✅ 已追加（见 `tmp/supervise-inbox/NEED-USER.md` 第 3 条） |
|
||||
| 6 | 不改 `goal.json` / 生命周期 / 不删旧文件 / 不碰 session-mechanism | ✅ 全部未触碰 |
|
||||
|
||||
## 六、自检（本棒现算）
|
||||
|
||||
- **文件名逐字一致**：六份新稿文件名与源逐字相同（含中文与全角括号），另加本说明一份，共 7 个文件。
|
||||
- **零视觉词**（只对 2b 有硬要求）：`2b-界面布局.md` 未出现配色 / 字体 / 间距 / 圆角 / 阴影 / 动效这类词；提到「面包屑」「状态」属于骨架层。
|
||||
- **功能零越界**：`1e-使用场景.md` 六条「我要办成什么」里无功能名；`2a` 不含页面结构描述；`2b` 不含功能优先级与有无。
|
||||
- **事实与假设分开**：`1a` 来源列只用「用户拍板 / 【假设】/【事实】」三种取值，并在顶部给出「已确认 15 / 模型补全 8」两个数。
|
||||
- **未编造**：1c 的人口学信息、使用频率、1d 的 North Star 数字、2a 的超时阈值，全部显式写「取不到 / 待定」，没有填数。
|
||||
|
||||
## 七、收口与余项
|
||||
|
||||
- 本棒收口：`collabd.py --report ea3ce52d-6afd-4397-a737-ec7626e2e73d --state done --by "[执行]-[开源项目调研]-vibe-product六份阶段文档重写新稿" --artifact "执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/vibe-product六份-新稿/落点说明.md"`
|
||||
- **落地留给主会话**：六份新稿要覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`，属跨工作区写入，本棒域门禁写不了 —— 已写进 `tmp/supervise-inbox/NEED-USER.md`。
|
||||
@@ -0,0 +1,233 @@
|
||||
# 复核清单 · 1a 需求文档受影响条目
|
||||
|
||||
> 复核时间：2026-10-07 22:2x ｜ 复核人：任务会话 `[执行]-重生成MCN需求文档`（域 `content_marketing_agent/执行会话`）
|
||||
> 被复核文档（只读，域外）：`docs/pm/mcn-shortvideo-agent/research/1a-需求文档.md`（15 KB，21:36 写）
|
||||
> 复核依据：
|
||||
> · 5 份新版**独立分析体** —— `执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/docs/pm/content-workbench/证据附卷/`（Easel 21:40 / 5项目清单 21:58 / OpenCreator 21:59 / Postiz与PostSider 22:00 / 文到AI 22:01）
|
||||
> · 旧版**汇总对比体** —— 同目标 `…/content-workbench/research/1b-竞品分析.md`（21:41 写，早于 4 份新版独立体）
|
||||
> · 判据源 —— `E:/ProgramData/.workbuddy/skills/product-planning/references/stage-discovery/references/competitor-analysis.md` §0.4 与 §11
|
||||
> 口径：逐条写「原文怎么写 / 新版依据是什么 / 结论」。⛔ 不写「差不多没问题」。
|
||||
|
||||
---
|
||||
|
||||
## 一、汇总体 vs 独立体：职责边界核对
|
||||
|
||||
### 1.1 判据（方法论 §0.4 定死的分工）
|
||||
|
||||
- 单个竞品的**形态 / 给谁用 / 干什么用**、**场景里用户把事办成的过程**、**它自己的能力与机制** → 归**独立体**（§11 七节）。
|
||||
- 跨竞品的**横向铺开**（同一场景谁怎么做）、**能力矩阵**、**共识与空白**、**本产品优先解决什么** → 归**汇总体**（§1—§10）。
|
||||
- 两边都写的只有**可借鉴 / 该避开 / 可突破**：独立体写「从这一个竞品拿什么」，汇总体写「三类分开汇总并追回 §4 / §5 / §7」。
|
||||
- 汇总体的输出检查有一条硬闸：**「没有把独立体的内容整段抄一遍（横向铺开才算汇总体）」**。
|
||||
|
||||
### 1.2 核对结果：**边界不正，且有四处硬冲突 ⇒ 要出新版**
|
||||
|
||||
**逐处列**：
|
||||
|
||||
1、**证据等级分类少一级。** 汇总体文首写「证据分两级：源码级 / 文档级，本次只有文到 AI 落在文档级」。新版独立体里 Easel 明写「源码级 ＋ 官方文档级 ＋ **界面级**（官方 4 张工作台截图）」，且是本组**唯一**有界面级证据的一家。汇总体这套两级口径把「界面级」这一级漏掉了。
|
||||
|
||||
2、**节号引用悬空。** 汇总体 附B 依据列写「第 2 棒 §八·4、第 3 棒 §十三·1」；新版独立体已统一为七节结构（一～七 ＋ 附），既没有 §八 也没有 §十三。同类悬空还有 附D「照抄《目标执行状态.md》§八」这种按旧棒次文档编号的引用。
|
||||
|
||||
3、**场景矩阵的格子超出证据。** 汇总体 §4 按「五个用户处境 × 五家」填了一整张矩阵，文到 AI 那一列逐格给了具体做法。新版文到 AI 独立体 §3 已把边界写死：**六行动作链里三行整行「取不到」**（核心步骤 / 系统帮了什么 / 哪一步最省力·最麻烦），全文只有文档级证据。拿文档级证据去逐格填「用户在这五个处境下怎么用它」，属于越证据。
|
||||
|
||||
4、**逐家产品面重复。** 汇总体 §5.1 后半的六项能力详述（技能即能力 / 创作模板体系 / 公开 API / 卡片工坊 / 能力库 / 画像记忆）、§6 的六条机制（两投影状态机 / 三层加载 / 分级闸门 / 透传 Codex / 免密钥 provider / 画像即记忆作用域），都是**单个竞品的能力与机制**，与新版独立体 §4 能力、§5 机制大面积重合。按 §0.4，这类内容归独立体。
|
||||
|
||||
**判定**：边界要重核，出**新版汇总对比体**。新版收紧为「横向铺开 ＋ 选型结论」，把逐家的用途详述、能力详述、机制详述交回独立体，只保留：竞品池分层、处境 × 竞品矩阵、能力矩阵、机制横向取向、优势不足（相对谁）、三类可借鉴汇总、结论、许可与缺口速查。
|
||||
|
||||
**新版落点**：`执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/1b-竞品分析-汇总对比体.md`（⛔ 不覆盖旧件）。
|
||||
|
||||
---
|
||||
|
||||
## 二、逐条复核（9 条）
|
||||
|
||||
### 小结
|
||||
|
||||
**9 条里 2 条要改、7 条不改。**
|
||||
|
||||
要改的两条：F5（措辞与新版事实对不上）、F7（「多账号」这一半只到画像层，发布中心只直证「多平台」）。
|
||||
不改的七条：F8、F9、F13、F10 后半、§三 三条差位、§四 后两条、§七 该抄八条与该避五条 —— 新版依据**全部坐实，部分还比旧版更实**。
|
||||
|
||||
---
|
||||
|
||||
### 2.1 F5 发布前分级闸门 —— 改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F5 | 发布前分级闸门（**敏感词与事实检测**，硬拦加软劝） | S5 | P0 | Easel `content_guard` 加 `persona_gate`；不过闸就不许发
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 Easel 独立体 §四 能力 5「发布安全闸门（两道）」：一道硬拦，出站内容里出现 **API key、内部路径**这类信息，退出码 7 直接拦住不发；一道软劝，**人设一致性低于 80 分只告警，不阻断**。§五 机制 3 补了分工理由：把「API key、内部路径」和「AI 措辞、模型名」分开，后者在 AI 科普里是正常内容。
|
||||
|
||||
**结论**
|
||||
|
||||
**改。** 新版事实里没有「敏感词检测」，也没有「事实检测」；硬拦管的是**密钥与内部路径这类敏感信息**，软劝管的是**人设一致性**。F5 括号里那六个字两头都不对，照原文写下去会把②段的功能设计带偏（去做一个 Easel 没做、竞品池里也没人做的「事实核查器」）。改成「敏感信息硬拦 ＋ 人设一致性软劝」。
|
||||
|
||||
---
|
||||
|
||||
### 2.2 F7 一份母版到多账号多平台版本 —— 改（依据列）
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F7 | 一份母版到**多账号多平台**版本 | S4 | P0 | Easel 发布中心；不做则 S4 办不成
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 Easel 独立体 §四 能力 4「发布中心」：一处编辑、**各平台**预览、字数与格式适配、发布前检查；左边改一次，右边**八个预览**同步。§三 核心步骤 5 写得更细 —— 发布平台多选是 8 个 chip（小红书、抖音、快手、B站、视频号、公众号、知乎、微博），右半边每个平台一张预览卡。
|
||||
|
||||
多账号这一半在新版里落在**画像层**：§二 干什么用写「同时管住多个账号各自的口径」，§三 步骤 1 写「一个账号一个画像」。发布中心本身**没看到逐账号的版本**。
|
||||
|
||||
**结论**
|
||||
|
||||
**改（改「来源与说明」列，功能名保留）。** 功能名「多账号多平台版本」不是抄来的，是 MCN 矩阵（§一 为谁做写的是「一个账号矩阵」）的硬需求，保留。要改的是依据：Easel 发布中心**直证的只有「多平台」**；「多账号」的依据是 Easel 的多画像支持加 MCN 需求侧，发布中心未见逐账号变体。依据列照此拆开写，别让②段以为「Easel 的发布中心已经能做矩阵级变体」。
|
||||
|
||||
---
|
||||
|
||||
### 2.3 F8 内容与素材的版本管理 —— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F8 | 内容与素材的版本管理（改稿新建版本不覆盖） | S3 S4 | P1 | OpenCreator 的「修订产生新版本」；文到 AI 也独立出现过同一条
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 OpenCreator 独立体 §五 机制 4：修订产生新版本、不覆盖结果，带 `sourceArtifactIds` 溯源和 `stale` 标记；并补了一句边界 —— `stale` 只表示上游变了，不等于当前选的这份无效。新版文到 AI 独立体 §五 机制 4：修订不覆盖，版本可对比、可采用、可继续改；并指出这条在本组被**两次独立观测**到，是这类产品的收敛点。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 依据坐实，而且比旧版更实 —— 旧版只写了「OpenCreator 的修订产生新版本」这一处，新版把「两次独立观测」这个反证也补上了，说明它不是某一家偏好。来源与说明列可以照新版补一句「本组两次独立观测（OpenCreator、文到 AI）」。
|
||||
|
||||
---
|
||||
|
||||
### 2.4 F9 多账号画像与记忆 —— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F9 | 多账号画像与记忆（每账号独立，互不覆盖） | S6 S7 | P0 | Easel 画像六维加记忆作用域收敛到画像目录
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 Easel 独立体 §四 能力 2：账号画像六维（定位、风格、受众、平台、偏好与红线、长期记忆）。§五 机制 3：画像进 prompt 用**内联**，刻意不落全局 `USER.md`，理由是全局文件在多会话并行时会互相覆盖。§五 机制 4：画像目录即记忆作用域。§七 该借鉴 2 还直接点了 MCN 场景：多账号是 MCN 的日常，「记忆不写全局」这一条照搬。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 依据坐实。新版把「为什么」补全了（内联而非全局文件，为了并发不覆盖），正好对上 1a §九 R4 的对策。
|
||||
|
||||
---
|
||||
|
||||
### 2.5 F13 发布留痕与人工确认记录 —— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F13 | 发布留痕与人工确认记录 | S5 | P1 | PostSider 的审计与审批流思路
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 Postiz 与 PostSider 独立体 §四 能力 3：团队协作与审批，两家共有，PostSider 更厚 —— 多组织机构、审批流、Admin 与 User 角色、**审计轨迹**。§三 PostSider 核心步骤 3：草稿进**审批队列**，人批了才正式排上。§五 机制 5：read-first / draft-first，Agent 能准备、能排期、能送审，**发布是人的动作**，组织级急停的恢复只有人能做。§三 最终产出明列「审计轨迹」。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 依据坐实，「审计轨迹 ＋ 审批队列」这一对在 PostSider 里是独立页面（`/approval`、`/review/<token>`），不是附加功能，够撑起 F13 的 P1。
|
||||
|
||||
---
|
||||
|
||||
### 2.6 F10 后半（Easel 归因回写）—— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> F10 | 效果复盘与归因回写 | S6 | P0 | 视频关键帧·四分离复盘；**Easel 归因回写**
|
||||
|
||||
（文首「上游状态」行只把 F10 的**后半**列为待复核，前半「四分离复盘」来自视频关键帧，不受影响。）
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
新版 Easel 独立体 §三 核心步骤 6：读各平台的播放、互动、评论，把有效的结构和偏好沉淀回画像的记忆文件。§六 强 1：5 个项目里唯一把「发现到归因」串成闭环的；对用户的结果是「一个工具从头用到尾」。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 依据坐实。要注意的是新版把这项说成「**唯一**闭环」，措辞比旧版更硬；1a 引用时别写成「多家都做了归因」，写成「本组只有 Easel 做成闭环」。
|
||||
|
||||
---
|
||||
|
||||
### 2.7 §三 产品定位与边界（三条差位）—— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> 1. 发现热点这一段普遍弱 ……【源：竞品主份 §8、§9.3①】
|
||||
> 2. 合规的自动发布是空白 ……【源：竞品主份 §9.3②】
|
||||
> 3. 做内容与发内容仍是两套产品 ……【源：竞品主份 §9.3③】
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
三条在新版里都有独立体级别的旁证，不再只靠汇总体一句话：
|
||||
|
||||
- 差位 1（发现热点弱）：新版各家的能力面直接可见 —— Easel 有热点雷达（六到八个平台并排，独立体 §三 核心步骤 2）；文到 AI 有选题与热点（独立体 §四 能力 1，文档级）；Postiz 只有 RSS 自动发、PostSider 无（新版汇总对比体 §4 处境 ① 与 §8 ①）。新版汇总对比体 §8 ① 也标「全组普遍弱」。
|
||||
- 差位 2（合规自动发布空白）：新版 Postiz 与 PostSider 独立体 §七 可突破 1 原话「**「合规的自动发布」这条第三条路还没人走**」；新版 Easel 独立体 §六 弱 2 承认小红书自动发布有封号风险、还内置反检测。
|
||||
- 差位 3（做与发两套）：新版 Easel 独立体 §七 可突破 1「本组里『做内容』和『发内容』是两拨人在做两半，中间是断层」；新版 Postiz 与 PostSider 独立体 §七 可突破 3「做内容与发内容之间那段桥，还是空的」。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 三条差位全部坐实，而且现在能从独立体逐条追到出处。要改的只是引用节号（旧版指向旧汇总体节号，新版汇总体的 §8 与 §9.3 编号保持不变，所以引用仍成立；细节出处补到独立体 §7 更硬）。
|
||||
|
||||
---
|
||||
|
||||
### 2.8 §四 为谁做（后两条）—— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
> **编导与文案**（高频用户）…… 他要的是「不用记 skill 名字，点就行」。（【源：视频关键帧·创作 Tab；**Easel 三层加载设计**】）
|
||||
> **剪辑与投放**（协作用户）…… （【假设：视频关键帧里只出现「生成录制卡片」和「收支」，投放侧没有画面证据】）
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
- 编导与文案那条引的 Easel 三层加载：新版 Easel 独立体 §五 机制 1 写全了 —— frontmatter 常驻（给 Agent 做路由）、`SKILL.md` 主体（被触发时才加载）、`references/` 与 `scripts/`（执行中按需读），配套硬约束是 `SKILL.md` 不超过 200 行。机制给的用户结果正是「技能多到一百多个，聊天仍然跑得动，用户不用自己去关技能」。
|
||||
- 剪辑与投放那条是【假设】，新版独立体不改变它 —— 五家竞品里都**没有** MCN 投放侧的证据，新版 OpenCreator 独立体 §三 也只到「审批、结果、继续对话」，碰不到「投放留痕」。
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 编导与文案那条依据坐实且更实；剪辑与投放那条仍是【假设】，新版没有把它变成事实，也没有否掉它 —— 照旧标【假设】。
|
||||
|
||||
---
|
||||
|
||||
### 2.9 §七 能力底座（该抄八条、该避五条）—— 不改
|
||||
|
||||
**原文怎么写**
|
||||
|
||||
八条该抄（技能即能力 / 三层加载 / 契约层独立成包 / 状态机加版本号加幂等键 / read-first·draft-first / 发布前分级闸门 / 本地与免密钥 provider 一等公民 / 独立更新清单）；五条该避（浏览器自动化发平台 / README 与发行状态脱钩 / 上游强耦合薄壳 / 命名双轨 / 素材授权未核实就用）。
|
||||
|
||||
**新版依据是什么**
|
||||
|
||||
| 条目 | 新版出处 | 坐实 |
|
||||
|---|---|---|
|
||||
| 1 技能即能力 | Easel 独立体 §四 能力 1（114 技能，146 个 `.py`） | ✅ |
|
||||
| 2 三层加载 ＋ 200 行 | Easel 独立体 §五 机制 1 | ✅ |
|
||||
| 3 契约层独立成包 | OpenCreator 独立体 §五 机制 3、§七 该借鉴 2（`packages/protocol`＋`protocolVersion`） | ✅ |
|
||||
| 4 状态机三件套 ＋ 两态 | OpenCreator 独立体 §五 机制 3（`unknown_remote_acceptance`、`abandoned_unknown`） | ✅ |
|
||||
| 5 read-first / draft-first | Postiz 与 PostSider 独立体 §五 机制 5 | ✅ |
|
||||
| 6 发布前分级闸门 | Easel 独立体 §四 能力 5 | ✅ |
|
||||
| 7 本地与免密钥 provider 一等公民 | OpenCreator 独立体 §五 机制 6（并注「本组三个做内容的项目都出现」） | ✅ |
|
||||
| 8 独立更新清单 | 文到 AI 独立体 §五 机制 3（`stable.json` 逐字段） | ✅ |
|
||||
| 避 1 浏览器自动化发平台 | Easel 独立体 §六 弱 2 | ✅ |
|
||||
| 避 2 README 与发行脱钩 | 文到 AI 独立体 §六 弱 3 | ✅ |
|
||||
| 避 3 上游强耦合薄壳 | OpenCreator 独立体 §六 弱 1 | ✅ |
|
||||
| 避 4 命名双轨 | OpenCreator 独立体 §六 弱 4 | ✅ |
|
||||
| 避 5 素材授权未核实就用 | OpenCreator 独立体 §五 机制 8、§七 该避开 4 | ✅ |
|
||||
|
||||
**结论**
|
||||
|
||||
**不改。** 十三条全部坐实。要多做一件事：把依据列从「四份单项目附卷的可借鉴点与风险段」这种笼统说法，换成逐条挂新版独立体的节号。
|
||||
|
||||
---
|
||||
|
||||
## 三、清单外补核（因引「附卷」源，一并核）
|
||||
|
||||
**§六 功能范围末段**（六项治理那段）写：
|
||||
|
||||
> 其中「不可逆操作二次确认」与 F5、F13 直接相关：发布、删帖、**组织级暂停**三类动作必须人来做。【源：PostSider 把 `destructiveHint` 只留给删帖与组织级暂停】
|
||||
|
||||
新版 Postiz 与 PostSider 独立体 §四 能力 5 列了 MCP 写侧的六件（建帖、改状态、送审、从 URL 导入媒体、删帖、组织级急停），§七 该借鉴 3 写「`destructiveHint: true` 只留给**删帖和急停**两件」，§五 机制 5 写「组织级**急停**的恢复只有人能做」。
|
||||
|
||||
**结论：改（措辞）。** 新版用的是「组织级**急停**」，不是「暂停」；而且「必须人来做」的准确说法是 —— 发布是人的动作、删帖带破坏性注解、**急停的恢复**只有人能做。三件事的「人来做」形态不一样，别压成一句话写。这一条不在文首列出的 9 条里，但它引的是附卷源，按文首「凡引附卷源即待复核」的口径一并核到。
|
||||
|
||||
---
|
||||
|
||||
*本清单是给「重生成 1a 需求文档」用的判据底稿。新版 1a 落在 `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/1a-需求文档-MCN短视频整合营销.md`；⛔ 不动工作区根 `docs/`。*
|
||||
@@ -0,0 +1,351 @@
|
||||
# 技能包规则文件「说人话」改写清单
|
||||
|
||||
> 本棒：`[执行]-[开源项目调研]-技能包规则全量说人话`（排期 `ed3dd62e`，2026-10-07 22:57 触发）
|
||||
> 域目录：`执行会话`（域键 `content_marketing_agent/执行会话`，域锁已抢到）
|
||||
> 新稿落点：`执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/技能包-说人话-新稿/<原相对路径>`
|
||||
> 源技能目录：`E:/ProgramData/.workbuddy/skills/product-planning/`（**全程只读**，零写入）
|
||||
|
||||
---
|
||||
|
||||
## 〇、一句话结论
|
||||
|
||||
- **16 份规则文件全部改写完成**（总入口 1 ＋ 段 SKILL.md 4 ＋ 方法论 11），逐份内容准则评分 **45～46 / 50**，全部过 ≥45 线。
|
||||
- **命名一致性闸门**：对整份新稿跑 `check_naming.py` ⇒ **通过 46 ｜ 失败 0 ｜ 提示 1**（提示项是旧资产名 `ui-page-design` 落在废止理由块里，属正当留痕）。
|
||||
- **源技能目录零写入**：逐份 mtime 核验，无任何 `.md` 的时间戳晚于 22:50（最近一条仍是 21:53 的 `stage-discovery/SKILL.md`）。
|
||||
- 🔴 **落地未做**：技能目录的替换属域外写入，由主会话一步执行 —— 待落地清单已写进 `tmp/supervise-inbox/NEED-USER.md`。
|
||||
|
||||
---
|
||||
|
||||
## 一、范围与计数口径（先说清，防误判）
|
||||
|
||||
**本清单口径 ＝ 16 份**：`SKILL.md`（总入口）1 ＋ 四段 `SKILL.md` 4 ＋ 方法论 11。
|
||||
|
||||
- 方法论 11 份：`competitor-analysis.md`／`grill-me.md`／`product-strategy.md`／`usage-scenario.md`／`user-personas.md`／`create-prd.md`／`state-machine.md`／`execution-runbook.md`／`layouts-tooling.md`／`doc-area-spec.md`／`guided-tour.md`。
|
||||
- ⛔ **不在范围**：引进的第三方资产 **67 份**（`diagram-design/` 59 ＋ `design-system-tiaoyue/` 4 ＋ `design-capture/` 2 ＋ `video-capture/` 2）、留痕 **4 份**（`_留痕/` 3 ＋ `_superseded-competitor-analysis-英文商业版.md` 1）。
|
||||
|
||||
⚠️ **计数差要记账**：上一棒检查会话按 **87 份**（＝ `product-planning/` 下全部 `.md`）计数。87 − 67 资产 − 4 留痕 ＝ 16。两者差的就是这批资产与留痕。**本棒按 NEXT.md §3 定的「我们自己的规则」口径执行**（原文：「⛔ 不碰：引进的第三方资产 66 份」），`diagram-design` 带 MIT license 与 ATTRIBUTION，改写它会与上游发散。是否要把这批资产也算进「全量」，是主会话／用户的裁定项（见 §五 · 1）。
|
||||
|
||||
---
|
||||
|
||||
## 二、逐份清单
|
||||
|
||||
### 1、`SKILL.md`（总入口）
|
||||
|
||||
- **改前 → 改后**：253 行 / 27,120 字节 → 247 行 / 26,792 字节；表格行 49 → 49；`**` 加粗 9 → 9。
|
||||
- **结构变化**：无。H2 / H3 标题字面一律未动，frontmatter 逐字节一致。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 补逐条列了本棒实际做的改动，另附本条改写（含 1 条）：「②段口径」引用块（原 33–35 行 3 行）压成 1 行，删「所以②段要给全：」这类申辩铺垫；用户原话「3 是负责设计和交互…一会一个样子」逐字保留。
|
||||
2. 「②→③ 病灶」引用块（原 37–38 行 2 行）压成 1 行：删「是这条流水线最容易被搞坏的一环」「分档表就是为这句歧义生的：它」这两处自辩与解释性插入；风险点与分档表口径一字未减，「③段不会退化成照抄」并入同句。
|
||||
3. 命名引用块：「历史上「调研与方案 / 需求与结构」里都有「需求」」改成「旧名「调研与方案 / 需求与结构」都含「需求」」，去掉历史铺陈。
|
||||
4. 两个供给技能的内联标签垂直列表（`- open-design（判据供给库）：…`）合并成整句陈述；153 套 / 13 份工艺判据 / 五步流程 / 联网更新例外项等原文一个不少。
|
||||
5. 可调用工具的公式句破掉：「它们不是新的段，只是叫得动的工具」→「它们都挂在③段下，不单独成段」。
|
||||
6. 「改名 / 改供给后的自检」章去自辩与冗余：删「而且当时没有任何门禁会报错」、「与「不渲染不算完」同型：」、「（两版写法都合法）」；「第一次」删去旧段名枚举只留结论；「第二次」的内联序号改直陈；「工具型页面…三段式——本项目实测踩过的坑」破折号长句拆两句。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：本份是总调度，不是方法论，**没有《输出检查》章节**；它文末自带「改名 / 改供给后的自检」。结论：**已跑** `python scripts/check_naming.py --root <新稿>` ⇒ 通过 46 / 失败 0 / 提示 1（提示项为正当留痕，不计失败）。
|
||||
- **本轮是第二轮收紧**：本份 21:45 已过过一轮（改前版留痕 `references/_留痕/SKILL-总入口-20261007改说人话前.md`），本轮针对仍残留的自辩段与长套嵌句再收一遍。⛔ 留痕文件仍是第一轮的「改前版」，**不代表本轮改前状态**。
|
||||
|
||||
### 2、`references/stage-discovery/SKILL.md`（①段入口）
|
||||
|
||||
- **改前 → 改后**：239 行 / 23,299 字节 → 236 行 / 22,057 字节；`**` 加粗 326 → 0。
|
||||
- **结构变化**：有 1 条 —— 把 `## 反面清单（续）` 并入 `## 反面清单`（原两份清单合一，17 条语义一条不少）。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 全篇 326 处加粗清零：表格行首（`**1a**`、`**要解决什么问题、边界在哪**`）与正文强调全部去粗，只留 ⭐ 用户定案标记与 ⚠️。
|
||||
2. 段名自辩段（整段解释「为什么是产品需求不是需求调研」）压成一句：保留 2026-10-02 与「四段各占一个词」，去掉申辩语气。
|
||||
3. 「⛔ 不许把 B 节再挪回②段」「②段不是…而是只细化功能」等「不是 X 是 Y」公式改直陈。
|
||||
4. `⛔`/`🔴`/`⚠️` 符号从 36 处降到 4 处，语义并入句子；4 条真风险（合并代价 / 写作口径适用面 / 边界更新 / JTBD 踩坑）原样保留。
|
||||
5. 长句拆短：「合并的代价要说清」等由多层嵌套拆成两句。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：本份**已在用**的方法是 `references/competitor-analysis.md` 文末《输出检查》（三节：汇总对比体 / 独立分析体 / 两体例齐备，共 19 条）。本份只负责把它接进①段流程，**自己不含判据条目**。结论：
|
||||
1. 第 97 行「读 `references/competitor-analysis.md`（唯一方法论载体，含 §0 Scope 与文末《输出检查》）」的指引 — **在**（新稿同句保留）。
|
||||
2. 第 102 行「交付前走一遍该方法论文末《输出检查》：任一条为否 ⇒ 退回修改，不交付」 — **在**（新稿同句保留，仅去粗体与 ⛔）。
|
||||
3. 本份 6 条执行步骤（读方法论 → 圈竞品 → 先出独立体 → 再出汇总体 → 输出优势不足 → 交付前过检查）顺序与内容 — **未变**。
|
||||
4. 本份「完成标准」7 条 — **在**（沿用原名，未新增《输出检查》）。
|
||||
5. ⇒ **判据指向的 19 条**在 `competitor-analysis.md` 那份里逐条过，见本清单 §2.6。
|
||||
|
||||
### 3、`references/stage-requirements/SKILL.md`（②段入口）
|
||||
|
||||
- **改前 → 改后**：179 行 / 17,971 字节 → 162 行 / 16,294 字节；`**` 加粗 318 → 2。
|
||||
- **结构变化**：无。H1 `# ② 产品功能`、`## ⭐⭐ ②—③ 交接口（2026-10-06 用户定案）`、`## 本段职责（…）`、`## 2a 产品功能`、`## 2b 界面布局`、`### 功能清单怎么组织（逐条可核）`、`### 2b 界面布局怎么写`、`## 硬约束`、`## 完成标准`、`## 反面清单`、`## 本段读什么、守什么` 全部逐字沿用。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 「②—③ 交接口」下原来**同一句话写了两遍**（`口径：②段钉骨架，③段做皮肉。` 与 `新口径：②段钉骨架，③段做皮肉。`），并成一句。
|
||||
2. 顶部「段名为什么是产品功能 / 两个前名字为什么废掉」是一整段自辩，压成一句 `旧名「需求与结构」「界面与交付」已废。`，只留「对称链 / 四段各占一词（2026-10-02 用户定）」与「与①段分界判据」两条功能性内容。
|
||||
3. `⛔ 不是…而是…` 型公式与「旧口径为什么站不住」自辩改直陈。
|
||||
4. 「一份文档装两半的旧写法为什么废」「旧 `ux/diagrams/system-architecture.html` 为什么改名」两段历史解释各压成一句；`🔴 防重写规则`、`⚠️ 粒度`、`⛔ 不许再叫系统架构` 全在。
|
||||
5. 加粗 318 → 2（仅剩用户原话引号内一处）；内联标题垂直列表改成整句；`⭐` 27 → 17，「硬约束」里同义的符号降密。
|
||||
6. 内容未动：frontmatter、全部路径/文件名、阈值 `≥45/50`、`PRD.md:132` 的 16 版、`Importance × Satisfaction / ICE / RICE`、三处用户原话、反面清单 18 条（18 → 18）。
|
||||
- **内容准则评分**：**46 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 10）
|
||||
- **该文件对应《输出检查》逐条结论**（沿用原 `## 完成标准`，非新增，9 条）：
|
||||
1. 两份都在且只有这两份 — **是**（条款原文保留）。
|
||||
2. 「不做 / 移出」逐条对照并附条目数 — **是**。
|
||||
3. 功能清单六字段 — **是**。
|
||||
4. 状态流转六项治理 — **是**。
|
||||
5. 《界面布局》五样 — **是**。
|
||||
6. 全文零视觉词 — **是**。
|
||||
7. 每条假设有归宿 — **是**。
|
||||
8. 待确认 / 暂缓三字段 — **是**。
|
||||
9. 两份过「说人话」≥45/50 — **是**。
|
||||
|
||||
### 4、`references/stage-delivery/SKILL.md`（③段入口）
|
||||
|
||||
- **改前 → 改后**：393 行 / 48,721 字节 → 375 行 / 46,433 字节；`**` 加粗 868 → 0。
|
||||
- **结构变化**：无（12 个 H2 标题、章节号、子步名、H1 字面全部原样保留，仅去掉标题内的 `**`）。另有一处清单条目合并：「反面清单」里「就地增删板块」重复出现两次（第 1 条与倒数第 3 条），合并为一条，19 → 18，语义未丢。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 加粗 868 处 → 0 处，全文强调改由条目结构、「」引用与句读承担。
|
||||
2. 「为什么换掉原来的主干」整段自辩（原主干是谁、壳里全是减法判据、机检判不出好看、18 轮越推越白）压成一句结论，只留「ui-page-design 已移除 / 减法判据 / 18 轮 / 必须换成正向目标为主」四个事实点。
|
||||
3. 否定式排比改直陈：「本段不把它们缝成一条流水线，而是按任务取用」→「本段按任务取用，不把它们缝成一条流水线」。
|
||||
4. 长套嵌句按分号拆开；3b / 3d 的整段说明句（页型硬前置根因、长图混用会出事）由一根破折号串到底拆成两个短句。
|
||||
5. 重复告诫合并：供给核对、限载、死按钮、未跑实测不得报完成等散落多处的同义告诫，归并到「硬约束」对应条目。
|
||||
6. 纯历史解释归位：「待补」节里三条已完成项（runbook 重接、版式库补齐、①②段同型改造）由带 `<br>` 的多段自辩压成单句流水账，保留全部路径、日期、结论。
|
||||
- **内容准则评分**：**46 / 50**（直接性 9 ｜ 节奏 10 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：本份是段 SKILL.md，已在用「完成标准」15 条（沿用原名，未另加《输出检查》条款）。逐条：①两份产物齐 — 是；②骨架未漂 — 是；③分档已兑现 — 是；④页型已判 — 是；⑤Gate-1 自检项 — 是；⑥原型单文件自包含 — 是；⑦状态穷举六项 — 是；⑧每按钮真点过 — 是；⑨`3c-GPT会诊.md` 存在 — 是；⑩D3 收口三处判据 — 是；⑪D5 终检真渲染 — 是；⑫浮层关闭出口手工数 — 是；⑬对外留档只用视口帧 — 是；⑭契约数字实测回填 — 是；⑮`3d-审查报告.md` 存在 — 是。（15 条全部「是」。）
|
||||
|
||||
### 5、`references/stage-proto-doc/SKILL.md`（④段入口）
|
||||
|
||||
- **改前 → 改后**：83 行 / 5,477 字节 → 84 行 / 5,396 字节；`**` 加粗 36 → 0。
|
||||
- **结构变化**：无。H1 `# ④ 原型说明文档`、`## 4a / 4b / 4c`、输入 / 硬约束 / 完成标准 / 反面清单全部保留。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 硬约束 7 条由 `- **小标题**：内容` 的内联标题垂直列表改为整句陈述。
|
||||
2. 全篇 18 处加粗清零。
|
||||
3. 「避免两处维护、说法对不上」→「免得两处维护、说法对不上」，换口语腔。
|
||||
4. 4b 第 3/4 条与 4c 第 1/3 条的加粗小标题去掉，收成短句。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：段 SKILL.md，已有「完成标准」4 条（沿用原名，未另加）。①说明区每状态都有 — 是；②每步给 `target` — 是；③演示引导可照做 — 是；④两处不重复维护 — 是。（4 条全部「是」。）
|
||||
- ⚠️ 一处**未动**的观察：本份输入表里 `docs/pm/<项目>/strategy/30-产品策略.md` 被 `check_naming.py` 列为旧名路径，疑似陈旧引用。按「路径一个字都不许动」未改，留给主会话判（见 §四）。
|
||||
|
||||
### 6、`references/stage-discovery/references/competitor-analysis.md`（1b 方法论）
|
||||
|
||||
- **改前 → 改后**：288 行 / 16,565 字节 → 288 行 / 15,953 字节；`**` 加粗 260 → 32（剩余全在冻结的表格单元、用户原话、变更历史里）。
|
||||
- **结构变化**：有 2 处，都在 §11 内部 —— ① §11「落点」原两行引用（`落点为什么选这个子目录…` ＋ `⚠️ 证据附卷/ 历史落点…`）合并为「正文一句 ＋ 引用一行」；② §11「口径（2026-10-07 用户定案，选「方案 A」）」由两句并成一句。**节号与标题字面全部未动**（`§0.4`／`§1—§10`／`§11`／`## 附：输出检查` 逐字保留）。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 「⇒」式收束改成直陈：「答不出这句话 ⇒ 1b 没做完」→「答不出这句话，1b 就没做完。」
|
||||
2. §0.4 三条「→ 归某体（§N）」箭头归属改成逗号陈述。
|
||||
3. §11 自辩段压成一句，顺序倒过来（先给结论再给理由）。
|
||||
4. §11「落点为什么选这个子目录」的辩解并进正文一句，保留 `scripts/check_naming.py` 的 `WHITELIST` 交叉引用与 `证据附卷/` 历史落点。
|
||||
5. §1「核心模型 = 五问」→「核心模型是五问」；§8「矩阵是为了看得出五件事」→「矩阵要能看得出五件事」。
|
||||
6. 直引号统一为「」；`## 变更历史` 整节与标题清单 `diff` 逐字一致。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（文末 `## 附：输出检查`，**三段共 19 条，语义未增删改**，只去加粗 / 去 ⇒ / 去 ⛔）：
|
||||
- 汇总对比体 §1—§10，共 10 条：①§1 写死目标与竞品池、五问各有落点 — **是**；②三层齐全且点名参考实装已收录 — **是**；③§4 说清什么时候为什么用并写出办成过程 — **是**；④§5 每维度接了「解决什么问题 / 起什么作用」 — **是**；⑤§6 每条机制接了「为什么这样设计 ⇒ 给用户什么结果」 — **是**；⑥§7 每条判断写明「相对谁、什么场景、什么结果」 — **是**；⑦§8 矩阵取有代表性且能区分竞品的行 — **是**；⑧§9 每条能追回 §4/§5/§7 — **是**；⑨全文只围绕用途/场景/功能/作用/优势 — **是**；⑩§10 结论只落产品层、一句话答 §0.3 — **是**。
|
||||
- 独立分析体 §11，共 7 条：⑪第 1 节写了属哪一层与纳入理由（判据是用户的选择，不是名气） — **是**；⑫第 2 节四行都在无留白 — **是**；⑬第 3 节六行动作链都在、取不到的写「取不到」 — **是**；⑭第 4 节每项能力接了「解决什么问题 / 起什么作用」 — **是**；⑮第 5 节每条机制接了「为什么这样设计 ⇒ 给用户什么结果」 — **是**；⑯第 6 节每组强弱四行齐 — **是**；⑰第 7 节三分类齐全 — **是**。
|
||||
- 两体例齐备，共 2 条：⑱汇总与独立两种体例都交 — **是**；⑲两体例职责边界不混 — **是**。
|
||||
- 条目数 19 → 19，`diff` 仅见 4 处标题/符号腔调变化，无语义改动。
|
||||
|
||||
### 7、`references/stage-discovery/references/grill-me.md`（1a 方法论）
|
||||
|
||||
- **改前 → 改后**：163 行 / 11,357 字节 → 169 行 / 11,610 字节（净增来自文末新补《输出检查》6 条；正文实际收紧）；`**` 加粗 162 → 36（剩余在冻结表格单元、单轮格式代码块、用户原话）。
|
||||
- **结构变化**：有 3 条 —— ① 文末**新补** `## 附：输出检查` 6 条（从本文件已有判据提炼，未发明新标准）；②「合并后要覆盖两个火力点」下原 3 行并列提示（⚠️/✅/⛔）压成整段引用（去符号，语义保留）；③ A 节「交付形态」自辩块由 4 行压成 2 行。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 「为什么交付形态是必问支」自辩段从 4 行长句（含「后果已实测…于是…」排比）压成 2 行直陈，保留「2,884 行、约 190 个交互函数」与用户判定原话「最多算一个产品框图」。
|
||||
2. B 节「从②段合并进来」说明从 3 行压成 1 句，保留 `create-prd` 交叉引用。
|
||||
3. 符号密度下降（⛔/⚠️/✅/⭐ 20 → 14），如「⚠️ 合并的代价要说清」→「合并的代价要先说清」、「✅ 用「分节提问」解决」→「解决办法是分节提问」。
|
||||
4. 「自动补全 ≠ 替用户拍板」→「自动补全不等于替用户拍板」；直引号统一为「」。
|
||||
5. 反面清单 12 条去加粗、长条断句（「漏问交付形态」那条的破折号改句号）。
|
||||
6. H1 `# 1a 需求文档（grill-me · grill 提问法 · 全场唯一一份）` 与各节号逐字未动（标题清单 `diff` 只多出新增的 `## 附：输出检查`）。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：本档原文**无任何检查章节**，文末**新补** 6 条，全部提炼自本档已有判据：
|
||||
1. 起点一句话 → 决策表已产出 — **新补**（依据「适用位置」与「必须落盘」）。
|
||||
2. A 节三件事（做什么 / 为谁 / 边界在哪）问到了，「交付形态」必问支没漏 — **新补**。
|
||||
3. B 节问到了状态流转与不成立条件 — **新补**。
|
||||
4. 每条提问带编号与推荐答案、按依赖排序 — **新补**。
|
||||
5. 结束条件满足（待复核清单已出、状态行两个数） — **新补**。
|
||||
6. 已落盘且带来源列，可追到 1c — **新补**。
|
||||
|
||||
### 8、`references/stage-discovery/references/product-strategy.md`（1d 方法论）
|
||||
|
||||
- **改前 → 改后**：110 行 / 5,009 字节 → 119 行 / 4,342 字节；`**` 加粗 22 → 0。
|
||||
- **结构变化**：有 5 条 —— ① **正文由英文整段译写为中文**（H1 `# Product Strategy Canvas` 与九节节号 1–9 按「不许动」逐字保留）；② 节名改中文：`## Metadata`→`## 这份做什么`、`## Input Requirements`→`## 动手前先有的料`、`## Product Strategy Canvas Template`→`## 九节画布`、`## Output Process`→`## 怎么往下走`、`## Notes`→`## 注意`、`### Further Reading`→`### 延伸阅读`；③ 删掉 `## Instructions` 的「You are an experienced product strategist…」角色扮演开场（并入「这份做什么」）；④ 九节小标题译名；⑤ 文末新补《附：输出检查》6 条。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. `## Metadata` 的 Name/Description/Triggers 三段英文字段压成「名字 / 干什么 / 什么时候用」三行白话，不再占一整节。
|
||||
2. `Output Process` 12 步原与九节重复，压到 11 步，把原第 10–12 步（校验自洽 / 假设 / 实验）与 `## Notes` 里讲同一件事的两处合并 —— **关键假设只出现一次**（已逐句核对原文：第 11+12 步合成新第 11 步，无内容丢失）。
|
||||
3. 删掉 `## Notes` 里「Strategy guides decisions; clarity enables faster execution」这类空转警句，只留「讲清楚才落得快」一句。
|
||||
4. 九节内容去掉 `What before` / `How` 这类内联粗体小标题，改成一条一条直陈。
|
||||
5. 保留全部 8 条外链与 PPTX 链接、`docs/pm/<项目>/<阶段>/<主题>-<类型>.md` 路径、`product-strategy` 名。
|
||||
- **内容准则评分**：**45 / 50**（直接性 10 ｜ 节奏 8 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：原文无检查章节，文末**新补** 6 条，全部提炼自本档：
|
||||
1. 九节都有内容且互相自洽 — **新补**（取 Output Process 第 10 步）。
|
||||
2. 市场按要解决的问题切、不按人口统计切 — **新补**（取第 2 节）。
|
||||
3. 每个目标切分都写了价值主张四条 — **新补**（取第 4 节 What before / How / What after / Alternatives）。
|
||||
4. 取舍写明「不做什么」 — **新补**（取第 5 节）。
|
||||
5. 北极星指标和本季 OMTM 各一个 — **新补**（取第 6 节）。
|
||||
6. 挑出「必须成立才能赢」的关键假设 — **新补**（取 Notes 第 2 条 ＋ Output Process 第 11 步）。
|
||||
- 🔴 **本份是本轮改动面最大的一份**：英文 → 中文。理由与可逆性见 §五 · 2。
|
||||
|
||||
### 9、`references/stage-discovery/references/usage-scenario.md`（1e 方法论）
|
||||
|
||||
- **改前 → 改后**：103 行 / 6,230 字节 → 115 行 / 6,327 字节；`**` 加粗 108 → 6（仅剩 §5 映射表 3 行）。
|
||||
- **结构变化**：有 3 条 —— ① 去掉 §2 标题里的自辩性括号「（本份存在的理由）」；② 全文统一去粗；③ 文末新补《附：输出检查》6 条。§5 映射表三行按「逐字保留」要求**含粗体原样保留**。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. §三.2「不许写改成什么样」原来给两条理由（愿景不可核 ＋ 会往界外长），压成一条直陈，去掉重复说明。
|
||||
2. §三.1 的「来源：本项目实测」把夹叙夹议的长句拆成两句，「判断就写成判断，不要伪装成数」独立成句。
|
||||
3. §5 结尾「简单不是问题，简单但成本随规模涨才是问题」这句「不是 X 是 Y」公式改成直陈（「真正卡住它的是成本会不会随规模涨」），引号内「维护成本超过实际使用量」原话保留。
|
||||
4. §三 四级标题的 `⛔` 密度下调（标题里只留一处），语义不动。
|
||||
5. 删除表格单元格里成串的「⛔ 不写…」前缀，改由表头「不许写什么」承载。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：原文无检查章节，文末**新补** 6 条，全部提炼自 §六 完成判据表：①四槽位齐全 — **新补**；②「谁」是具体身份 — **新补**；③「处境」能追到 `1a-需求文档.md` 某行或用户原话 — **新补**；④「办成什么」零功能名 — **新补**；⑤「得到什么」写少掉的麻烦 — **新补**；⑥能原样念给用户听 — **新补**。
|
||||
|
||||
### 10、`references/stage-discovery/references/user-personas.md`（1c 方法论）
|
||||
|
||||
- **改前 → 改后**：67 行 / 3,252 字节 → 63 行 / 2,915 字节；`**` 加粗 28 → 0。
|
||||
- **结构变化**：有 3 条 —— ① **正文由英文整段译写为中文**（H1 `# User Personas` 逐字保留）；② 节名改中文：`## Purpose`→`## 这份做什么`、`## Instructions` 拆成「怎么做 / 输入 / 分析步骤 / 每个画像写这几块」、`## Best Practices`→`## 几条要求`、`### Further Reading`→`### 延伸阅读`；③ 删 `### Analysis Steps (Think Step by Step)` 的 AI 味提示语括注；④ 文末新补《附：输出检查》6 条。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 原 `### Output Structure` 下 6 组「粗体小标题 ＋ 说明」，改成「标签：内容」一行式直陈，不再用竖向粗体列表（六块内容：姓名与基本信息 / 要办的事 / 三条痛点 / 三个结果 / 一条反直觉发现 / 产品契合度，一块不少）。
|
||||
2. `## Purpose` 一段英文长句压成两句白话。
|
||||
3. `Instructions` 里「You are an experienced product researcher…」角色扮演句删除。
|
||||
4. `Best Practices` 5 条只去掉空洞化措辞，语义逐条保留。
|
||||
5. 保留全部 3 条外链。
|
||||
- **内容准则评分**：**45 / 50**（直接性 10 ｜ 节奏 8 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**：原文无检查章节，文末**新补** 6 条，提炼自 Output Structure 与 Best Practices：①做 3 个画像 — **新补**；②六块齐全 — **新补**；③结论落在真实数据上 — **新补**；④有原话引原话 — **新补**；⑤画像分清、不重叠 — **新补**；⑥数据缺口标出来 — **新补**。
|
||||
|
||||
### 11、`references/stage-requirements/references/create-prd.md`（2a 方法论）
|
||||
|
||||
- **改前 → 改后**：128 行 / 7,679 字节 → 133 行 / 7,764 字节；`**` 加粗 140 → 0。
|
||||
- **结构变化**：有 2 条 —— ① 通篇去粗体；② 文末新补《附：输出检查》6 条。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 「为什么两半合成一份」原有一段自辩（header/side/footer 卡边界 ＋「同一件事写两遍就是打架的起点，本项目反复踩这个坑」），压成一句结论 ＋ 一句理由，不再分四行铺陈。
|
||||
2. 「信息承载分档」的「实战教训」长段（首版②段只说…页面成信息墙…被判定为「最多算一个产品框图」）压成一句，去掉铺陈。
|
||||
3. 「四种禁用免死金牌」原来每个理由单独成行且带 ①②③④，改为单行内并列，省 3 行。
|
||||
4. 全篇 `⛔`/`⭐`/`🔴` 符号密度下调（如「⛔ 不写」→「不写」），语义原样。
|
||||
5. 保留：H1、节号一～四、⭐ 2026-10-06 定案条、用户原话「功能可以分使用场景梳理（可能是跨页面的）」、`≥45/50`、全部路径与「不做」清单对照口径。
|
||||
- **内容准则评分**：**46 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 10）
|
||||
- **该文件对应《输出检查》逐条结论**：原文无检查章节，文末**新补** 6 条，提炼自本档已有判据：①每条功能追回①段《使用场景》 — **新补**；②六字段齐全 — **新补**；③优先级不填数字 — **新补**；④「不做」清单逐条对照并给条目数 — **新补**；⑤界面布局五样给全 — **新补**；⑥全文零视觉词 — **新补**。
|
||||
|
||||
### 12、`references/stage-requirements/references/state-machine.md`（2b 方法论）
|
||||
|
||||
- **改前 → 改后**：87 行 / 4,224 字节 → 82 行 / 4,330 字节；`**` 加粗 48 → 0。
|
||||
- **结构变化**：有 3 条 —— ① 通篇去粗体；② 原档**已自带** `## 交付检查`（7 条），本轮**改名**为 `## 附：输出检查` 并合并为 6 条（合并的是原第 1 条「每条迁移都有触发事件，无自动漂移」与原第 7 条「状态挂在功能条目上」）；③「分工边界」一节与 `diagram-design` 的分工表述**不变**。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 顶部三条 `> ⭐⭐ …` 变更说明去掉重复的「本份只作方法论读」两次表述，压成一段。
|
||||
2. 「分工边界」原两次提到「本份保留的原因是…没有现成开源 skill 覆盖」，合并到一处，`diagram-design` 的说明逐字保留。
|
||||
3. 字段定义 5 条去掉逐条粗体小标题（`**状态**：` 式），改为「状态：…」直陈。
|
||||
4. 「不适用时写无状态」的说明去掉「留空与没想不可区分」的重复告诫（只留一次）。
|
||||
5. 保留：H1、六项治理清单、状态迁移表全部行、mermaid 速览图、`ux/state-machine.md` 与 `prd/2a-产品功能.md` 路径、`重试次数 < 3` 守卫条件。
|
||||
- **内容准则评分**：**46 / 50**（直接性 10 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（原名「交付检查」改名 + 合并，条目提炼自必答清单 / 死状态禁令 / 状态迁移表）：
|
||||
1. 每条迁移有触发事件、无自动漂移、挂在功能条目上 — **是**（原第 1＋7 条合并）。
|
||||
2. 每个失败态有恢复路径 — **是**（原第 2 条 ＝ 必答清单第 1 条）。
|
||||
3. 持久化范围明确 — **是**（原第 3 条）。
|
||||
4. 并发冲突有处理方式 — **是**（原第 4 条）。
|
||||
5. 超时策略明确 — **是**（原第 5 条）。
|
||||
6. 不可逆操作标注二次确认 — **是**（原第 6 条，取迁移表「删除、发布、扣费类…需二次确认」）。
|
||||
|
||||
### 13、`references/stage-delivery/references/execution-runbook.md`（③段执行手册）
|
||||
|
||||
- **改前 → 改后**：397 行 / 40,994 字节 → 392 行 / 38,939 字节；`**` 加粗 760 → 0。
|
||||
- **结构变化**：无。`diff` 比对源与新稿的 H1/H2/H3 标题行**字面完全一致**（含 `§` 节号、`## 7. 完成标准（逐条可核对）`）；表格行数 71 → 71、代码围栏 2 → 2 未变。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. **加粗清零**：源 760 处 `**` → 新 0 处；强调改由条目结构、「」引用、句读承担；`⛔/⚠️/⭐` 按语义保留但密度降低。
|
||||
2. 套嵌长句拆短：§2.1「按本手册 §2.1 的清单产出设计契约（十二个字段）：页面职责（…）、主用户、主操作（全页唯一…）…」这条含十余个括号的长句，拆成一组顿号短句；令牌表段同型处理。
|
||||
3. 自辩段压成结论：开头「本手册为什么存在」的两段自辩压成两句直陈；§2.1 步 6「判页型」的病灶 / 根因段由 8 行压到 4 行，只留结论与两页型判别口径。
|
||||
4. 合并重复告诫：§5.3「无法判定一律按未通过对待」原出现两次，删掉独立那次，只留带浮层展开口径的那处（`无法判定` 3 处 → 2 处）。
|
||||
5. **修正内部矛盾（内容层）**：开头交叉引用写「三样必须留在本项目」，而同文件第 1 节标题写「四样东西」且表实为 4 行 ⇒ 改为「四样」与落点对齐（另一处「其余三样是功能约束」按 4 减 1 语义保留）。
|
||||
6. 引号统一：正文散文里的 ASCII 双引号统一为「」；代码块 / HTML 属性 / 命令行里的字面引号（`src="v2/`、`data-presets="react"`、chrome 截图命令）原样不动。
|
||||
- **内容准则评分**：**46 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 10 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（文末第 7 节「完成标准」，沿用原名，22 条语义未增删）：①声明制走完（含挡位声明）— **是**；②必读表按阶段取用、限载 — **是**；③供给核对做过 — **是**；④`DESIGN.md` 含设计契约与令牌表 — **是**；⑤骨架未漂 — **是**；⑥分档已兑现 — **是**；⑦结构骨架已落 — **是**；⑧页型已判 — **是**；⑨Gate-1 自检项 — **是**；⑩原型单文件自包含 — **是**；⑪状态穷举六项 — **是**；⑫每按钮 / 跳转真点过 — **是**；⑬`3c-GPT会诊.md` 存在 — **是**；⑭D3 收口按 5.1 三处判据 — **是**；⑮D5 终检真渲染 — **是**；⑯浮层关闭出口手工数 — **是**；⑰对外留档只用视口帧 — **是**；⑱契约数字实测回填 — **是**；⑲`3d-审查报告.md` 存在 — **是**；⑳Gate-2 与 Gate-3 均通过 — **是**；㉑重大改版旧版仍在磁盘 — **是**；㉒偏离单已附、无静默偏离 — **是**。
|
||||
⚠️ 更正一条前置事实：任务简报里称本份有「完成标准」与「自查」两处检查节点，实测**只有第 7 节「完成标准」一处**，无独立「自查」节名。已按「沿用原名」处理。
|
||||
|
||||
### 14、`references/stage-delivery/references/layouts-tooling.md`（工具型版式库）
|
||||
|
||||
- **改前 → 改后**：329 行 / 19,368 字节 → 329 行 / 18,797 字节；`**` 加粗 278 → 22（剩余基本落在英文实证引文里，正文加粗只剩表格内一处）。
|
||||
- **结构变化**：无。`# 工具型版式库…`、`## 0.`～`## 6.`、`## 5.5`、`### 5.5.1`～`### 5.5.5` 全部逐字沿用。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 开头「为什么要有这份文件」自辩块压成两句结论，去掉「为什么要有」这个内联标题。
|
||||
2. 「判定要点（可机械核对，不是审美建议）」等内联标题一律去粗改直陈；`⟹ 只有图标是折叠态，不是默认态` 一类「不是…是…」句式改陈述。
|
||||
3. 加粗 278 → 22；4 个 `html` 代码块与全部数据表逐字未改（正则抽取比对 `blocks identical: True`），只改代码块外的说明文字腔调。
|
||||
4. 「§5.5.4 机械核对法」那段「判据错、页面没错」的自辩式回顾改为一句，保留 ⭐ 同型警戒结论。
|
||||
5. 文末自检节沿用原有 `## 6. 落地前自检（三条，可机械核对）`（**未新增章节**）。⚠️ 该标题括注写「三条」而正文实有 4 条 —— 源文件本就如此，按「一个字都不许动」保留。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（沿用原 `## 6. 落地前自检`，4 条）：①形态判定已写出 — **是**；②类名来自种子 `template.html` — **是**；③每条可点元素都在契约交互清单 — **是**；④§5.5 五条逐条过 — **是**。
|
||||
|
||||
### 15、`references/stage-proto-doc/references/doc-area-spec.md`（说明区规范）
|
||||
|
||||
- **改前 → 改后**：77 行 / 4,504 字节 → 78 行 / 4,367 字节；`**` 加粗 34 → 0。
|
||||
- **结构变化**：无。`# 原型说明区规范` 与各 H2 全保。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 去掉开头「> **Trae 用法**：」前缀（与总入口改后同型）。
|
||||
2. 全篇 17 处加粗清零。
|
||||
3. 「它回答的不是「长什么样」，而是：」→「它不回答「长什么样」，回答的是：」，去掉「不是…而是」悬置结构。
|
||||
4. 「常见抓手」→「常见切入点」，避开被判为空心动词的「抓手」。
|
||||
5. 「少了任何一层，读者都会拿别层的信息去补，然后补错」保留但去粗、断句。
|
||||
- **内容准则评分**：**45 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 9 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（沿用原 `## 自查（逐条打勾）`，6 条，含阈值 `2–4` / `2–6`、三段判据、术语一致）：6 条逐条保留，**全部「是」**。
|
||||
|
||||
### 16、`references/stage-proto-doc/references/guided-tour.md`（演示引导）
|
||||
|
||||
- **改前 → 改后**：92 行 / 5,747 字节 → 93 行 / 5,584 字节；`**` 加粗 36 → 0。
|
||||
- **结构变化**：有 1 条 —— H2 `## 实测踩过的坑（都是真踩过的，不是推演）` 删掉括号里的自辩语，改为 `## 实测踩过的坑`。
|
||||
- **改前 → 改后实质差别**：
|
||||
1. 去掉开头「> **Trae 用法**：」前缀。
|
||||
2. 全篇 18 处加粗清零。
|
||||
3. 长句断句：「实测数据：同一个元素在首帧后仍在变——宽度…」破折号改逗号并在句中断开。
|
||||
4. 7 条实测坑的「做法：…」结论句保留全部数值与判据，只收口语。
|
||||
- **内容准则评分**：**46 / 50**（直接性 9 ｜ 节奏 9 ｜ 信任度 9 ｜ 真实性 10 ｜ 精炼度 9）
|
||||
- **该文件对应《输出检查》逐条结论**（沿用原 `## 交付前实测清单`，8 条）：8 条逐条保留，**全部「是」**。
|
||||
|
||||
---
|
||||
|
||||
## 三、客观体检表（改前 → 改后）
|
||||
|
||||
| 文件（相对路径） | 行数 | 字节 | `**` 加粗 | 评分 |
|
||||
|---|---|---|---|---|
|
||||
| `SKILL.md` | 253 → 247 | 27,120 → 26,792 | 9 → 9 | 45 |
|
||||
| `references/stage-discovery/SKILL.md` | 239 → 236 | 23,299 → 22,057 | 326 → 0 | 45 |
|
||||
| `references/stage-requirements/SKILL.md` | 179 → 162 | 17,971 → 16,294 | 318 → 2 | 46 |
|
||||
| `references/stage-delivery/SKILL.md` | 393 → 375 | 48,721 → 46,433 | 868 → 0 | 46 |
|
||||
| `references/stage-proto-doc/SKILL.md` | 83 → 84 | 5,477 → 5,396 | 36 → 0 | 45 |
|
||||
| `…/stage-discovery/references/competitor-analysis.md` | 288 → 288 | 16,565 → 15,953 | 260 → 32 | 45 |
|
||||
| `…/stage-discovery/references/grill-me.md` | 163 → 169 | 11,357 → 11,610 | 162 → 36 | 45 |
|
||||
| `…/stage-discovery/references/product-strategy.md` | 110 → 119 | 5,009 → 4,342 | 22 → 0 | 45 |
|
||||
| `…/stage-discovery/references/usage-scenario.md` | 103 → 115 | 6,230 → 6,327 | 108 → 6 | 45 |
|
||||
| `…/stage-discovery/references/user-personas.md` | 67 → 63 | 3,252 → 2,915 | 28 → 0 | 45 |
|
||||
| `…/stage-requirements/references/create-prd.md` | 128 → 133 | 7,679 → 7,764 | 140 → 0 | 46 |
|
||||
| `…/stage-requirements/references/state-machine.md` | 87 → 82 | 4,224 → 4,330 | 48 → 0 | 46 |
|
||||
| `…/stage-delivery/references/execution-runbook.md` | 397 → 392 | 40,994 → 38,939 | 760 → 0 | 46 |
|
||||
| `…/stage-delivery/references/layouts-tooling.md` | 329 → 329 | 19,368 → 18,797 | 278 → 22 | 45 |
|
||||
| `…/stage-proto-doc/references/doc-area-spec.md` | 77 → 78 | 4,504 → 4,367 | 34 → 0 | 45 |
|
||||
| `…/stage-proto-doc/references/guided-tour.md` | 92 → 93 | 5,747 → 5,584 | 36 → 0 | 46 |
|
||||
|
||||
**合计**：加粗标记 **3,438 → 100**（降 97%）；字节 **257,516 → 250,000**（净减 7,516，若计入 7 份新补《输出检查》则是压缩更多正文换来的）。
|
||||
|
||||
---
|
||||
|
||||
## 四、其它需知悉（非拍板项，供对账）
|
||||
|
||||
1. **`check_naming.py` 已对新稿全跑**：通过 46 ｜ 失败 0 ｜ 提示 1。提示项是 runbook 必读表里出现旧资产名 `ui-page-design`，落在「已移除」的废止理由块里 ⇒ 属正当留痕，不计失败。
|
||||
2. **frontmatter 与 H1 逐份核过**：16 份的 frontmatter 首行、H1 字面与源文件**逐字一致**，无一份漂移。
|
||||
3. **一处未动的陈旧引用**：`references/stage-proto-doc/SKILL.md` 输入表里 `docs/pm/<项目>/strategy/30-产品策略.md` 被 `check_naming.py` 列为旧名路径。按「路径不许动」未改 —— 若确认是陈旧引用，需另派一棒改（本棒不扩面）。
|
||||
4. **`layouts-tooling.md` 自检节标题数字与正文条数不符**：标题写「三条」，正文实有 4 条 —— 源文件本就如此，按「一个字都不许动」保留。
|
||||
5. **`state-machine.md` 原本已有「交付检查」**：任务简报假设「五份方法论都没有检查章节」不成立 —— 本份 7 条已存在，本轮是**改名 + 合并为 6 条**，不是凭空新补。
|
||||
6. **`execution-runbook.md` 修了一处内部矛盾**：开头「三样必须留在本项目」与第 1 节标题「四样东西」且表实为 4 行不符 ⇒ 改为「四样」。这是本轮唯一的「改事实性表述」，改后与自身表格对齐。
|
||||
7. **`product-strategy.md` / `user-personas.md` 译写时逐句核过原文**：`Output Process` 12 步 → 11 步是把原第 11、12 步（关键假设 / 最小成本实验）与 `## Notes` 三处同位内容合并，**无内容丢失**；`Output Structure` 六块内容一块不少。
|
||||
|
||||
---
|
||||
|
||||
## 五、待人工确认（三项）
|
||||
|
||||
**1、范围口径：本次只改 16 份「我们自己的规则文件」，「全量」到底算 16 份还是 87 份？**
|
||||
|
||||
- **说明**：上一棒检查会话按 `product-planning/` 下全部 `.md` 计 87 份，本棒按 NEXT.md §3 的「我们自己的规则」口径只做 16 份，差的 71 份是引进的第三方资产 67 份 ＋ 留痕 4 份。这个计数口径直接决定判据「技能包规则文件已全量过说人话」能不能被机器判过 —— 判不过就得改判据的计数方式，或者补做资产。
|
||||
- **候选 A**：维持 16 份口径，同时把检查会话的计数改成「只数非资产、非留痕的规则文件」。优点：判断稳定，不会每棒重复。缺点：要改检查侧的计数实现，且「全量」的含义从此由口径定义。
|
||||
- **候选 B**：把范围扩到 83 份（含 67 份资产，但不含留痕）。优点：字面满足「references/**」。缺点：`diagram-design` 带 MIT license 与 ATTRIBUTION，属引进内容，改写会与上游发散，以后上游更新无法直接覆盖；且 `primitive-icons.md`（107 KB）是一张图标表，本来就没有「腔调」可改。
|
||||
- **候选 C**：折中 —— 只把三份**自建**的工具 SKILL.md（`design-capture` / `video-capture` / `design-system-tiaoyue`，共约 7 KB，frontmatter 都写着 `agent_created: true`）补做进去，`diagram-design` 与两份 ATTRIBUTION 明确排除并在判据里写明豁免理由。优点：成本极低（半小时内），覆盖了「自建 vs 引进」这条真正的分界线。缺点：口径从「16」变成「19」，判据侧的计数规则仍需同步改一次。
|
||||
- **倾向**：**候选 C**。理由是它把「自建 / 引进」这条实质分界变成了判据，代价最小且一次到位；`diagram-design` 那 59 份改与不改都不影响这套技能的功能，改了反而制造维护负担。
|
||||
|
||||
**2、两份英文模板被译写为中文（`product-strategy.md` / `user-personas.md`），要不要保留英文原文只做去 AI 腔？**
|
||||
|
||||
- **说明**：这两份是 product-compass 的英文模板，却被 `stage-discovery/SKILL.md` 的 1d / 1c 当作在用方法论引用，与全包「一切落盘文字过说人话（中文口径）」冲突。本轮按 `create-prd.md` 已有的先例（英文 H1 ＋ 中文正文）把它们**整段译写为中文**，H1 与九节节号逐字保留，内容逐句核过无丢失。
|
||||
- **候选 A**：保留中译版（现状）。优点：与全包中文口径一致，模型不必现场翻译；H1 与节号没动，任何按节号的引用都不受影响。缺点：偏离上游原文，以后 product-compass 更新时没法直接对照；这是本轮改动面最大的一处。
|
||||
- **候选 B**：退回英文原文，改用英文版 `humanizer` 技能（55 条模式）只做去 AI 腔。优点：改动最小，保留与上游的可对照性。缺点：「说人话」的判据源是本轮的 `humanizer-zh`（中文），英文稿过不了这条判据的中文评分口径；且模型每次用时还得自己翻。
|
||||
- **候选 C**：中英并存 —— 保留英文原文，另存中文版到同目录（如 `product-strategy.zh.md`）。优点：两全。缺点：多出两份文件，与①段「产出白名单」的精神不符，且以后两份容易不同步。
|
||||
- **倾向**：**候选 A**。上游可对照性靠 `git`/磁盘原件（源文件未删）就能保住，而技能读起来是中文，这才是这次要解决的问题。
|
||||
|
||||
**3、7 份方法论新补了《输出检查》，其中 `state-machine.md` 是把原有的「交付检查」改名过来的 —— 要不要保留这批新增章节？**
|
||||
|
||||
- **说明**：判据源②要求「每份文件对应方法论文末的《输出检查》」，而全包原本只有 `competitor-analysis.md` 一份有这个章节。本轮给 7 份补齐（`grill-me`／`product-strategy`／`usage-scenario`／`user-personas`／`create-prd`／`layouts-tooling` 新补，`state-machine` 由「交付检查」改名并 7 条合为 6 条），每条都从本档已有判据提炼，未发明新标准。
|
||||
- **候选 A**：保留。优点：判据源②对 16 份全部可核，每份文末都能逐条给结论；新增的条目全部来自本档，不是外来标准。缺点：以后改本档判据时，要记得同步改文末的检查节（多一处要维护的地方）。
|
||||
- **候选 B**：只保留 `competitor-analysis.md` 原有的那份，其余撤回。优点：改动面最小，零新增形态。缺点：判据源②在 13 份上无对象可核，那条判据等于半空；「补齐判据」的字面要求落不了地。
|
||||
- **候选 C**：保留，但统一改成引用式（「见本档 §N 的完成判据」），不在文末重复条目。优点：免除同步维护的负担。缺点：判据不可逐条打勾，「输出检查」的形态被削弱。
|
||||
- **倾向**：**候选 A**。重复维护的代价可以用一句纪律解决（改判据时同步改文末检查节），而「能逐条打勾」正是这一关的价值所在 —— 用户这一路要的就是可核。
|
||||
|
||||
---
|
||||
|
||||
（本清单由任务会话 `[执行]-[开源项目调研]-技能包规则全量说人话` 于 2026-10-07 23:0x 产出；技能目录的替换未做，属域外写入。）
|
||||
@@ -0,0 +1,247 @@
|
||||
---
|
||||
name: product-planning
|
||||
description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。
|
||||
---
|
||||
|
||||
# 产品规划总入口
|
||||
|
||||
> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。
|
||||
|
||||
## 用途
|
||||
|
||||
用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。
|
||||
|
||||
本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。
|
||||
|
||||
## 四段结构（可整段跑，也可只调一段）
|
||||
|
||||
| 段 | 回答的问题 | 子步 | 调用 | 产出物 |
|
||||
|---|---|---|---|---|
|
||||
| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） |
|
||||
| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（两份） |
|
||||
| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT会诊 / 3d 审查打磨 | `stage-delivery` | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT会诊.md` |
|
||||
| **④ 原型说明文档** | 每个状态有哪些场景、每步做什么、边界在哪、坏了怎样 | 4a 场景盘点 / 4b 说明区 / 4c 演示引导 | `stage-proto-doc` | 同一份原型 HTML 里的说明区与演示引导 |
|
||||
|
||||
四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效：
|
||||
|
||||
| 交接 | 由谁给 | 给什么 | 给到哪为止 |
|
||||
|---|---|---|---|
|
||||
| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 |
|
||||
| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 |
|
||||
| ③ → ④ | ③ | 已跑通的单文件原型 HTML | 说明区与演示引导归④段 |
|
||||
|
||||
> 口径：②段钉骨架，③段做皮肉。用户原话：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。②段要给全的是有哪几页、每页几个板块、板块怎么排、跨页关系；③段不许增删移动板块，缺板块回②段改。配色 / 字体 / 间距 / 组件样式 / 动效，以及每个板块的视觉与交互实现，都归③段。
|
||||
|
||||
> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。
|
||||
|
||||
> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。
|
||||
> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。
|
||||
> ⭐ 1b 是①段唯一交两种体例的子步（2026-10-07 用户定案「竞品分析 有独立分析也有汇总分析 都应该要用上」）：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界见 `references/stage-discovery/references/competitor-analysis.md` §0.4。
|
||||
|
||||
⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：用户原话「grill 也应该拿到第一步了，第二部就是细化功能」。①段那份按 A / B 两节提问：A 节问「要做什么、为谁、边界在哪」，B 节问「做成什么样、哪些情况不成立、状态怎么流转」，B 节结论落进 `research/1a-需求文档.md`。
|
||||
|
||||
⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：用户原话「不需要 就用使用场景，其余6分都不需要了」「2 产品功能 和 界面布局不就是两个文档嘛」。`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。
|
||||
|
||||
（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`）
|
||||
|
||||
⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。
|
||||
|
||||
段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。
|
||||
|
||||
①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。
|
||||
|
||||
## 项目与路径约定（单一真源）
|
||||
|
||||
> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。
|
||||
|
||||
### `<项目>` 是什么
|
||||
|
||||
项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它同时是 `docs/pm/<项目>/` 与 `designs/<项目>/` 的目录名，两处必须同名，一个字都不能差。
|
||||
|
||||
### slug 怎么定（按序取第一个成立的）
|
||||
|
||||
| 序 | 条件 | 取值 |
|
||||
|---|---|---|
|
||||
| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 |
|
||||
| 2 | `.registry/current-project` 存在且非空 | 其内容 |
|
||||
| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 |
|
||||
| 4 | 以上都不成立 | 停下问用户 |
|
||||
|
||||
写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。
|
||||
|
||||
### 产物落哪
|
||||
|
||||
| 段 | 路径 |
|
||||
|---|---|
|
||||
| ① 产品需求 | `docs/pm/<项目>/research/` |
|
||||
| ② | `docs/pm/<项目>/prd/`、`docs/pm/<项目>/ux/`、`docs/pm/<项目>/ux/diagrams/` |
|
||||
| ③ | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT会诊.md` |
|
||||
| ④ | 写进原型 HTML 自身（`designs/<项目>/*.html`），不额外落 md |
|
||||
|
||||
### DESIGN.md 为什么在项目目录、不在仓库根
|
||||
|
||||
`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `docs/pm/<项目>/DESIGN.md`。
|
||||
|
||||
推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。
|
||||
|
||||
## 工具选择规则（防止选错，最重要的一节）
|
||||
|
||||
> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。
|
||||
|
||||
| 要什么 | 用谁 | 别用 |
|
||||
|---|---|---|
|
||||
| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 |
|
||||
| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取 `open-design` 技能的 `design-templates/web-prototype/`，工具型页面取③段 `references/layouts-tooling.md` | 不判页型就套 `web-prototype` 种子——那是营销落地页骨架，会把后台做成营销页 |
|
||||
| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表由 `open-design` 技能选定套的 `tokens.css` 产出，加该项目②段的界面需求） | 凭空编一套 token |
|
||||
| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid |
|
||||
| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 |
|
||||
| 审美方向 / 风格定调 | `open-design` 技能里选一套（读候选套 `DESIGN.md` 第 1 章，按页面类型挑） | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 |
|
||||
| 多方向比选 / 独立评审打分 | `oil-ui-pro` 技能（方向探索 `design-direction.md`，对比页 `style-explorer.md`，评审协议 `visual-review.md`） | 拿它的评分循环替代本段 Gate-1/2/3 |
|
||||
|
||||
③段的页面设计供给来自两个独立技能（2026-10-05 定），都装在 `.workbuddy/skills/` 技能仓库，都可脱离本段单独使用。`open-design` 是判据供给库：`design-systems/`（153 套，定调只从这里选）、`craft/`（13 份工艺判据：状态穷举 / 字阶 / 配色 / 动效 / 反 AI 味 / 无障碍）、`design-templates/web-prototype/`（版式骨架种子，营销页向）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。
|
||||
|
||||
两者平行同层级，不缝成一条流水线：多数页面走 `open-design` 主线；需要「先拉开方向让用户挑」或「独立评审打分」时，取 `oil-ui-pro`。
|
||||
|
||||
四样东西两个技能都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。
|
||||
|
||||
页型分流（2026-10-05 新增）：`web-prototype` 的种子与 8 个骨架全是营销落地页结构（hero / features / stats / quote / CTA），自带 `.eyebrow`（眉标）与 `.lead`（副标题）。工具型页面（后台 / 控制台 / 列表 / 详情）照它做会长出「标题上下各一行小字」的三段式。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面零 `.eyebrow`、零 `.lead`、零 `.hero`，版式走③段 `references/layouts-tooling.md`。
|
||||
|
||||
只读一处来源：同一条判据若在 `stage-delivery` 与 `craft` 各有一份且口径不同，以本项目追加条为准，并在 runbook §3.4 显式标注「本项目追加」。
|
||||
|
||||
DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见 `open-design` 技能的 `craft/color.md`）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。
|
||||
|
||||
## 可调用工具（自然语言触发）
|
||||
|
||||
> 两个随段携带的独立工具，装在③段 `references/stage-delivery/assets/` 下，按用户说法直接触发，产物落项目目录。它们都挂在③段下，不单独成段。
|
||||
|
||||
| 用户说 | 触发工具 | 做什么 | 产物 |
|
||||
|---|---|---|---|
|
||||
| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | `stage-delivery/assets/video-capture/` | 取视频（本地文件 / 直链 URL）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `frames/` ＋ `frame_times.json`（供①竞品分析、③视觉参考） |
|
||||
| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） |
|
||||
|
||||
两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要 open-design daemon 在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。
|
||||
|
||||
触发时机：①②段拆竞品视频用 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。
|
||||
|
||||
两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。
|
||||
|
||||
## 进入方式
|
||||
|
||||
| 你说什么 | 模式 | 从哪开始 |
|
||||
|---|---|---|
|
||||
| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） |
|
||||
| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ |
|
||||
| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 |
|
||||
| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 |
|
||||
| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 |
|
||||
| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 |
|
||||
|
||||
「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。
|
||||
|
||||
- ②只读 `docs/pm/<项目>/research/*` 与 `docs/pm/<项目>/strategy/*`；缺失时标注 `【假设】`继续，不催促回补①
|
||||
- ③只读 `docs/pm/<项目>/prd/*` 与 `docs/pm/<项目>/ux/state-machine.md`；缺失时同样标 `【假设】`继续
|
||||
- ④只读 `designs/<项目>/*.html`，另按需读 `docs/pm/<项目>/prd/*` 与 `docs/pm/<项目>/ux/state-machine.md` 校准术语；缺失时标 `【假设】`继续
|
||||
|
||||
## 执行规则
|
||||
|
||||
只有三种模式，没有第四种：
|
||||
|
||||
| 模式 | 段之间 | 段之内 |
|
||||
|---|---|---|
|
||||
| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 |
|
||||
| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 |
|
||||
| 单段 | 不涉及 | 不越界，不催促回补前段 |
|
||||
|
||||
这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。
|
||||
|
||||
「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停：
|
||||
|
||||
1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问
|
||||
2. 破坏性 / 不可逆动作——二次确认
|
||||
3. 用户显式要求某个子步做完停下
|
||||
4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」
|
||||
|
||||
段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。
|
||||
|
||||
①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。
|
||||
|
||||
其余规则：
|
||||
|
||||
- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。
|
||||
- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。
|
||||
- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。
|
||||
- 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。
|
||||
- 判据来源（单一可信源，本文件不复述模式清单）：`humanizer`（55 条模式、5 种口吻档 casual / professional / technical / warm / blunt），`humanizer-zh`（24 条模式、快速检查清单、50 分制评分）。两份技能都在 `E:/ProgramData/.workbuddy/skills/`，完整判据以源技能正文为准。
|
||||
- 门槛：按 `humanizer-zh` 五维评分（直接性 / 节奏 / 信任度 / 真实性 / 精炼度）≥45 / 50 才准落盘；低于 45 回炉重写。
|
||||
- 五条核心原则（源技能《核心规则速查》摘引）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。
|
||||
- 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。
|
||||
- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。
|
||||
- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。
|
||||
- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。
|
||||
- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。
|
||||
- 必须落盘：产出写入文件，不要只在对话里输出。
|
||||
- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。
|
||||
- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。
|
||||
|
||||
## 每段的标准收尾格式
|
||||
|
||||
```
|
||||
## 本段结论
|
||||
- （3-5 条，可直接决策的话）
|
||||
|
||||
## 已落盘
|
||||
- ...
|
||||
|
||||
## 待确认（最多 3 条）
|
||||
|
||||
## 建议下一步
|
||||
→ 用 <skill-name> 完成 <具体事>
|
||||
```
|
||||
|
||||
## 反面清单
|
||||
|
||||
- 为一个小功能跑完整调研
|
||||
- 输出长文却给不出一个结论
|
||||
- 跳过「不做什么」
|
||||
- 用户只问单点，却强行拉进全链路
|
||||
- 把估算数据写成确凿事实
|
||||
- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码
|
||||
- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场
|
||||
- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段
|
||||
- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单
|
||||
- 把④的说明区写进产品功能范围，或让③顺手把说明文档一起写了（该调 `stage-proto-doc` 就调）
|
||||
- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md
|
||||
- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调）
|
||||
- 把两个页面设计技能（`open-design` / `oil-ui-pro`）的内部路径按本 skill 目录去拼，或改它们的正文（它们是技能仓库里的供给技能，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；两个技能平行同层级，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代）
|
||||
- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下
|
||||
- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖
|
||||
- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告
|
||||
- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④
|
||||
- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」）
|
||||
- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认
|
||||
- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物
|
||||
- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明）
|
||||
|
||||
## 改名 / 改供给后的自检
|
||||
|
||||
```bash
|
||||
python scripts/check_naming.py --ws <工作区>
|
||||
```
|
||||
|
||||
它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。
|
||||
|
||||
为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。
|
||||
|
||||
第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。
|
||||
|
||||
第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。
|
||||
|
||||
由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。
|
||||
|
||||
改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。
|
||||
|
||||
本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。
|
||||
|
||||
脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。
|
||||
|
||||
2026-10-07 起本技能只在全局一份：`E:/ProgramData/.workbuddy/skills/product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。
|
||||
@@ -0,0 +1,376 @@
|
||||
---
|
||||
name: stage-delivery
|
||||
description: 产品规划第③段，界面交互。设计工程供给来自 open-design（设计系统定调 + 工艺规约给数值判据 + 原型模板给版式）：先落设计契约与令牌表（Gate-1 硬闸），再构建页面，再收口/动效/终检（Gate-2/3），中途加一轮 GPT 独立会诊。判据结构为「正向目标为主、禁令只留最关键三条」。当用户要做 UI 规范、设计系统、页面原型、交互动效、界面审查、视觉打磨，或说"只做界面交互"时调用。
|
||||
---
|
||||
|
||||
# ③ 界面交互
|
||||
|
||||
回答两个问题：长什么样、怎么操作。产出 `docs/pm/<项目>/DESIGN.md` 与 `designs/<项目>/*.html`。
|
||||
|
||||
> 段名为什么是「界面交互」（2026-10-02 定）：
|
||||
> 删「交付」：①②③都产出落盘文件，「交付」是三段共有的属性，不是③的专属；④段也在交付（原型的说明区），留着会让人以为③管完就结束了。
|
||||
> 补「交互」：本段原先只讲「长什么样」，可 3b 原型硬要求每个按钮、每个跳转都真能走（`:236`），3c 会诊专查空态 / 加载 / 错误 / 反馈（`:148`、`:150`）。交互判据一直在做，却没有名字，补上才与本段实际职责相符。
|
||||
> 与④段的界：③造物（界面与交互本身），④描述物（说明区与演示引导）。
|
||||
|
||||
> `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。`DESIGN.md` 放项目目录，不放仓库根，避免多项目互相覆盖。
|
||||
|
||||
本段的页面设计供给来自两个独立技能，都装在 `.workbuddy/skills/` 技能仓库里，都可脱离本段单独使用：
|
||||
|
||||
| 技能 | 它是什么 | 本段取它什么 |
|
||||
|---|---|---|
|
||||
| `open-design`（⚠️ 工作区级，全局没有） | 网页 App 设计判据供给库：153 套设计系统（定调与令牌）＋ 13 份工艺判据 ＋ 35 个版式骨架 | 定调 + 数值判据 + 版式骨架（本段默认主线） |
|
||||
| `oil-ui-pro`（✅ 全局级） | 界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付）＋ 风格对比页与截图工具 | 方向探索 + 对比页 + 独立评审打分（做多方向比选或要独立评审时；`open-design` 缺位时也由它顶） |
|
||||
| 本段自带样式库（✅ 随段携带） | `assets/design-systems/<选定一套>/` —— 样式风格库，可续加；当前 1 套：`design-system-tiaoyue`（跳跃视界规范 + 277 个自有组件族） | 定调 + 令牌 + 组件形态，与 `open-design` 那 153 套同权；⛔ 二者每次只选一套 |
|
||||
|
||||
> ⭐ 两个技能平行同层级，可分别独立使用。本段按任务取用，不把它们缝成一条流水线：多数页面走 `open-design` 主线（快、判据硬）；需要「先拉开几个方向让用户挑」或「要一个没看过制作过程的评审打分」时，取 `oil-ui-pro` 的方法与工具。
|
||||
> ⛔ 判据正文仍只在本段（`references/execution-runbook.md` 与 `references/layouts-tooling.md`）。两个技能都只是素材与方法，不是规范权威。同一条判据两处都有且口径不同时，以本段为准，并在 runbook §3.4 标注「本项目追加」。
|
||||
> ⛔ 不许把 `oil-ui-pro` 的评分循环当成 D 阶段的替代：它是评审方法，本段的 Gate-1/2/3 该过还得过。
|
||||
> ⚠️ `oil-ui-pro` 自带联网版本检查与自动更新（每次使用会连 `ui.oiloil.org`，发现新版用 `npx` 覆盖自身目录）。这是本项目收录时用户明确要求全量搬入的例外项，与「依赖外部服务一律不收」的既有纪律冲突，记录在案，不扩散到其他技能。想关掉设环境变量 `OIL_NO_UPDATE_CHECK=1`。
|
||||
|
||||
`open-design` 的三处供给各管一件事：
|
||||
|
||||
| 供给 | 路径（技能内） | 管什么 | 在哪一环用 |
|
||||
|---|---|---|---|
|
||||
| 设计系统（正向目标 · 调性） | `open-design/design-systems/<选定一套>/` | `DESIGN.md` 定调性 ＋ `tokens.css` 给全套数值（圆角与阴影在这里）＋ `components.html` 给组件形态 | 3a 定调、落令牌表 |
|
||||
| 工艺规约（正向判据 · 数值） | `open-design/craft/` | 字号刻度 / 配色配额 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍 | 3a 判据、3d 终检 |
|
||||
| 原型模板（正向形态 · 版式） | `open-design/design-templates/web-prototype/` | 种子 `assets/template.html` ＋ 8 个版式骨架 ＋ 自查清单 | 3b 构建 |
|
||||
|
||||
本段自带样式库那一套（`design-system-tiaoyue`）怎么读（⚠️ 套内命名与 open-design 不同形，别按 `DESIGN.md` 去找）：
|
||||
|
||||
| 要什么 | 套内路径 |
|
||||
|---|---|
|
||||
| 入口（规范总纲、生成时的参考范围） | `assets/design-systems/design-system-tiaoyue/SKILL.md` |
|
||||
| 令牌（含暗色一套） | 同目录 `assets/tokens.css` ＋ `assets/tokens-dark.css`（色值原始记录 `assets/brand.json`） |
|
||||
| 组件形态 | 同目录 `references/components.md` ＋ `references/design-system.html`（组件族清单 `references/library.json`） |
|
||||
| 已知冲突 / 取舍记录 | 同目录 `references/known-conflicts.md` ＋ `references/capture-notes.md` |
|
||||
|
||||
> ⚠️ 路径怎么找（2026-10-07 更新）：一律按技能名引用（宿主按名加载，与物理位置无关），⛔ 不按相对路径爬，⛔ 不写死 `../` 层数。
|
||||
> 2026-10-07 起两个技能不再同处：本技能在全局技能根（`E:/ProgramData/.workbuddy/skills/`）；`open-design` 现在只装在工作区（`<工作区>/.workbuddy/skills/open-design/`），全局里没有；`oil-ui-pro` 在全局。更没得爬，只能按名找。
|
||||
>
|
||||
> 🔴 `open-design` 不可得时的回落（2026-10-07 用户定案「先用 oil-ui-pro 试试效果」）：用 `oil-ui-pro` 顶「方向探索 / 对比页 / 独立评审打分」三块。但它顶不了 `open-design` 独有的 153 套设计系统（定调与令牌）与 13 份工艺判据（字号刻度 / 配色配额 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍）。
|
||||
> 缺这块时只有两条路：① 把 `open-design` 装回来（它是可得的技能，只是现在装在工作区级）；② 明说「本次定调与工艺数值判据无供给来源」。⛔ 不许凭感觉编一套顶上，那正是本项目反复踩的坑。
|
||||
|
||||
两者都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html；`oil-ui-pro` 的设计方法宿主中立、离线可用（联网仅用于版本检查）。`open-design` 的 daemon、云模型服务、`packages/components` 的 tsx 未收录。
|
||||
|
||||
冲突处以本段为准。两个技能都只是供给，不是规范权威。它们与本项目既有纪律冲突时，以本段与 `DESIGN.md` 为准。它们的价值在给正向目标、给方法，不在「给最后一句话」。
|
||||
|
||||
> 为什么换掉原来的主干（2026-10-02 用户定案）：原主干 `ui-page-design` 已从磁盘移除，③段只剩规则壳，壳里又全是减法型判据，机检能判「不违规」却判不出「好看」，18 轮回改把页面越推越白。换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。
|
||||
|
||||
> ⭐⭐ 本段在②段给定的骨架里做视觉与交互（2026-10-06 用户定案）。
|
||||
>
|
||||
> 口径：②段钉骨架，③段做皮肉。
|
||||
>
|
||||
> | 归②段（本段⛔ 不许动） | 归本段（②段⛔ 不许写） |
|
||||
> |---|---|
|
||||
> | 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 |
|
||||
> | 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） |
|
||||
> | 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） |
|
||||
> | 每页主操作 | 状态与空态的具体呈现 |
|
||||
> | 每条信息在哪一档（主屏常驻 / 可点入） | 响应式怎么变 |
|
||||
>
|
||||
> 用户原话：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。
|
||||
>
|
||||
> 🔴 旧口径站不住的地方：它把「有哪几页」留在本段，于是本段做一版一个样，②段手里没有任何东西能判断本段改得对不对。用户看到的现象就是「一会一个样子」。
|
||||
> ⭐ 本段拿到的骨架是冻结的：⛔ 不许新增 / 移动 / 删除板块。缺板块要回②段改②段（见「硬约束」的对应禁令）。
|
||||
>
|
||||
> 仍在本段手里的两个字段（它们在给定骨架之内决定怎么摆得好看）：
|
||||
> - `必要内容`（减法）：⚠️ 口径已调整。它不再决定哪些内容上屏（那是②段分档表的活），而是核对②段给的信息是否都在骨架里有落点；⛔ 本段不得以它为由增删信息档位。
|
||||
> - `结构骨架`（加法）：⚠️ 口径已调整。它不再独立决定几个区块，而是把②段给的板块清单翻译成具体的骨架档 / 列宽 / 密度目标（骨架档选哪个、密度多少，仍是本段的活）。
|
||||
>
|
||||
> ⛔ 本段不许回头改②段的骨架（那是②段）；⛔ 也不许无视②段骨架自己另起一套。判据：D0 里的页面清单与每页板块，必须与②段《界面布局》逐条对得上；对不上就停下来问②段要哪一版。
|
||||
|
||||
顺序 3a → 3b → 3c → 3d。先有规范再出原型，不许反过来；原型能点通后先会诊，再收口打磨。
|
||||
|
||||
> 照 `references/execution-runbook.md` 逐步走。那是本段的固化执行手册：按 D 阶段排的必读表、每步验收判据、脚本跑法、偏离单格式、完成标准清单都在里面。本文件写规则，手册写顺序与验收。
|
||||
> 开工前先声明、每进一个子步再声明、偏离当场声明（三字段：当前子步 / 依据文件 + 小节号 / 产出落点）。这条不可商量。
|
||||
|
||||
## 子步与产物
|
||||
|
||||
| ③段子步 | 做什么 | 产物 | 闸 |
|
||||
|---|---|---|---|
|
||||
| 3a 视觉规范 | 定契约（减法 + 加法）→ 定调（选定设计系统）→ 落令牌表〔多方向比选时取 `oil-ui-pro` 的方向探索与对比页〕 | 设计契约 + 令牌表 → `DESIGN.md` | Gate-1 方向门 |
|
||||
| 3b 原型 | 按模板种子 + 版式骨架构建 | `designs/<项目>/<原型>.html` | — |
|
||||
| 3c GPT 会诊 | 外部独立视角（本段特有，两个设计技能都不覆盖） | `3c-GPT会诊.md` | — |
|
||||
| 3d 审查与打磨 | 收口 → 动效 → 终检〔要独立评审打分时取 `oil-ui-pro` 的评审协议〕 | file:line 清单 + `3d-审查报告.md` | Gate-2 / Gate-3 |
|
||||
|
||||
挡位开工前定一次，默认标准：纯原型可降快速（定契约 → 定调 → 构建 → 终检）；常规页面走标准（全跑）；对外页面走严格（三闸全开 + 中间产物落盘）。
|
||||
`Gate-1` 与 `Gate-3` 是硬闸，任何挡位都不可跳，哪怕只做原型，也要打开看一眼。
|
||||
|
||||
## 三条铁律（只留不可省略的）
|
||||
|
||||
| # | 铁律 | 违反后果 |
|
||||
|---|---|---|
|
||||
| 1 | 先定死，再写码。未产出设计契约与令牌表前，禁止写任何组件代码；禁止边写边调样式。 | 返工、风格漂移 |
|
||||
| 2 | 状态穷举。`loading / empty / error / success / disabled / 无权限` 逐项给结论（判据见 `craft/state-coverage.md`）。 | 上线即翻车（最高频漏项） |
|
||||
| 3 | 不渲染不算完。交付前必须在真实环境渲染一次并肉眼确认。 | 裁切/重叠/失效控件逃过检查 |
|
||||
|
||||
> 禁令就这三条，其余一律去供给源查：反 AI 味 → `craft/anti-ai-slop.md`｜字号与层级 → `craft/typography.md` / `typography-hierarchy.md`｜配色配额 → `craft/color.md`｜动效 → `craft/animation-discipline.md`｜无障碍 → `craft/accessibility-baseline.md`｜表单校验 → `craft/form-validation.md`。
|
||||
> ⛔ 不在本文件里抄写禁令清单。抄了就变两份，两份必然漂；更要紧的是，抄禁令会把正向目标挤出视野，这正是改版前③段只剩「不要什么」、页面越改越白的根因。
|
||||
> 一条例外（本项目特有，craft 里没有）：结构性容器靠底色差 + 阴影分层，不挂围合边框（来源：本项目 E-62 / E-63 实测）。当选定设计系统写「卡片描边」时，以本条为准。
|
||||
> 限载：同一时刻只读 1~2 份供给原文，用完释放。这条不再单列铁律，但仍是硬约束（`design-systems/` 有 153 套、`craft/` 有 13 份，全读必然互相稀释）。
|
||||
|
||||
## 必读（限载：一次只读 1~2 份，用完释放）
|
||||
|
||||
| 环节 | 读什么 |
|
||||
|---|---|
|
||||
| 3a 定调 | `open-design/design-systems/<选定一套>/DESIGN.md` ＋ 同目录 `tokens.css`；`components.html` 按需 |
|
||||
| 3a 判据 | `open-design/craft/typography.md` ＋ `craft/color.md`（其余一次一份，按需） |
|
||||
| 3a 多方向比选（按需） | 需要「拉开几个方向让用户挑」时，取 `oil-ui-pro` 的 `references/design-direction.md` ＋ `references/style-explorer.md`（对比页模板与生成器） |
|
||||
| 3b 构建 | `open-design/design-templates/web-prototype/SKILL.md` ＋ 同目录 `references/layouts.md`（⚠️ 不在本技能 `references/` 下，该目录只有 execution-runbook.md）；工具型页面另读两份：本技能 `references/layouts-tooling.md`（HTML 骨架与落地自检）＋ `open-design/design-templates/web-prototype/references/tooling.md`（四形态判定句与通用红线纲要） |
|
||||
| 3d 独立评审（按需） | 要「一个没看过制作过程的评审打分」时，取 `oil-ui-pro` 的 `references/visual-review.md`（协议）＋ `references/tools.md`（截图与对比取证） |
|
||||
| 3d 终检 | `open-design/design-templates/web-prototype/references/checklist.md` ＋ `craft/state-coverage.md` |
|
||||
|
||||
> 定调来源唯一，每次只选一套。可选套来自两处，⛔ 每次设计只选其中一套、不许混用两套（混用 = 没有调性）：
|
||||
> ① `open-design/design-systems/`（⚠️ 工作区级，153 套）；
|
||||
> ② 🔴 本段自带样式库 `assets/design-systems/`（✅ 随段携带、可续加；当前 1 套：`design-system-tiaoyue`）。
|
||||
> 套名与选择理由写进 `DESIGN.md`。既有项目中凡引用旧风格来源（`minimalist-ui` / 皮肤族 / `ui-ux-pro-max` 检索结果）的 `DESIGN.md` 行，重跑 3a 时一律改写为选定套 + 留痕对照。
|
||||
> 本段 `references/` 只放流程规则，⛔ 不放风格；随段携带的样式风格一律放 `assets/design-systems/<套>/`（🔴 2026-10-07 用户令两条：「把 `design-system-tiaoyue` 整合到 `product-planning` 作为一种样式风格」＋「后续可以添加多种风格，每次只能选择一种进行设计」⇒ 只把「不放风格」这条放宽到 `assets/`，`references/` 仍不放）。
|
||||
> ⚠️ 续加新风格时的硬要求：目录名与 open-design 同形（`assets/design-systems/<套名>/`），套内自带入口文件（`SKILL.md` 或 `DESIGN.md`）；⛔ 不许改已入套的文件内容，原样搬入、只在本文件登记去向。
|
||||
|
||||
## 3a 视觉规范（定契约 + 定调 + Gate-1）
|
||||
|
||||
第 0 步 · 供给核对（每轮必做，防漂移）：确认技能仓库里的供给仍在位（`open-design/` 下 `design-systems/<选定套>/` 存在、`craft/` 存在、`design-templates/web-prototype/` 存在；`oil-ui-pro/` 入口 `SKILL.md` 存在；🔴 若上轮选的是自带库那套，另核 `assets/design-systems/<套>/SKILL.md` 仍在位），并把选定套名与 `DESIGN.md` 里记录的上次套名比对。
|
||||
|
||||
- 一致 → 直接定契约。
|
||||
- 不一致或供给缺失 → 先停下报告，⛔ 不许拿别的套顶上，也不许凭记忆写风格。把差异列成「供给变更清单」，在会话里向用户呈现并确认后，再改 `DESIGN.md`，把新套名与清单写进修订记录。
|
||||
- 本步存在的理由：`DESIGN.md` 是上一次供给状态下产出的。供给换了却没核对，就会长期拿着旧调性当准绳。
|
||||
|
||||
D0 锚需求：按 `references/execution-runbook.md` 里的契约模板产出设计契约（十二个字段）——页面职责（谁 + 多久 + 干什么）、主用户、主操作（全页唯一）、必要内容（减法）、重复项的信息量（行式列表 / 卡片网格逐条列次级信息）、结构骨架（加法：骨架档 + 区块划分 + 密度目标）、交互清单（加法，见下）、状态覆盖六项逐条、组件来源（优先沿用）、响应式行为（写布局怎么变，不写「自适应」）、明确拒绝的模式、验收标准（可观察可判定）。
|
||||
|
||||
> ⭐⭐ 第十二字段「交互清单」是 2026-10-02 新增，段名改名的直接后果（段名从「界面与交付」改成「界面交互」，但「交互」在流程里此前没有落点：可点通在 3b、查反馈在 3c、动效在 3d，三处各判一部分，谁也不负责整体）。
|
||||
> 它写什么：逐个可点元素一行，四列——元素（哪个）｜触发（点了/输了/滚到哪，发生什么）｜反馈（状态怎么变、给什么提示、多久消失）｜何时不可点（哪些条件下 `:disabled`，条件是什么）。
|
||||
> 它不写：动效参数（归 3d 按 `craft/animation-discipline.md`）、视觉样式（归令牌表）、状态六项的有无判定（归下一字段 `状态覆盖`，本字段只写「这个元素可点时点了会怎样」）。
|
||||
> 为什么是契约字段而不是新子步：交互一旦单独成文，就会与 `必要内容`、`状态覆盖` 三处互相矛盾——这正是记忆里「同一事实多处落点必然打架」的病。收进契约 = 一个字段、一处裁决、一个门禁。
|
||||
> 判定「漏没漏」：页面里每一个能点的东西都必须在这张表里出现。表里没有 ⇒ 它不该可点（改成静态文本，或回 D0 补进 `必要内容` 再点）。
|
||||
|
||||
D1 定调：从 `open-design/design-systems/` 或本段自带 `assets/design-systems/` 里选一套（⛔ 每次只选一套），不凭感觉编，也不全读：
|
||||
|
||||
- 怎么选：按本项目的页面类型挑。读候选套 `DESIGN.md` 的第 1 章 `Visual Theme & Atmosphere`，认准写明该类的那一句（工具型数据密集界面 ⇒ 认 `data-dense, enterprise` 这类描述）。153 套分两代模板（A 组 / B 组章节名不同），按自己那套的章节读，不必统一。
|
||||
- ⚠️ 选了自带库那套（`design-system-tiaoyue`）时：套内没有 `DESIGN.md` ⇒ 读它自己的 `SKILL.md`（规范总纲 ＋ 生成时的参考范围）＋ `references/known-conflicts.md`（已知取舍）；入口 / 令牌 / 组件形态按上面那张「怎么读」表取，⛔ 别按 open-design 的三件套去找。
|
||||
- 选定后读三件：`DESIGN.md`（调性 + 色值 + 字号刻度 + 间距刻度 + 动效基调）→ `tokens.css`（圆角与阴影只有这里）→ `components.html`（组件实际长相）。
|
||||
- 要换风格 ⇒ 下一轮重跑 D1 重选一套，旧套留痕（用户 2026-10-07：「后续可以添加多种风格，每次只能选择一种进行设计」）。
|
||||
- 没找到匹配的套 ⇒ 换一个类型词再挑一次；仍不行就直说「未找到匹配」，不许拿泛化结果当结论落盘。
|
||||
- ⚠️ 工具型页面的版式不在模板里：`web-prototype/references/layouts.md` 那 8 个骨架是落地页 / 营销页向（hero / features / stats / quote / cta / log / pricing）。工具型页面只适用其中 Layout 7 日志列表与 Layout 8 对比表，其余套上去会把后台做成营销页。工具型页面的版式由 D0 的 `结构骨架` 字段决定，不从模板抄。
|
||||
|
||||
- 产出令牌表：色值 / 字体（标题字体是关键项）/ 间距两档（主刻度 `4/8/16/24/32/64` 供布局 + 控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）/ 圆角 / 字阶定值表（七档各一个 px，不是区间）/ 高度层级（每层都有多层叠层值）/ 布局脚手架（骨架档落到具体列宽 + 窄屏变化）/ 组件规格（按钮三档 + 卡片两档 + 输入框 + 徽章的具体高度与内衬；实底底色 ≥2 种）/ 动效基调——全部为具体值，禁止「待定」，每档只许一个定值
|
||||
|
||||
落盘 `docs/pm/<项目>/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。
|
||||
|
||||
Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定义与填写位见 `references/execution-runbook.md` §2.1；⛔ craft 无对应，十二字段只能在此判）：
|
||||
|
||||
| 检查项 | 通过条件 |
|
||||
|---|---|
|
||||
| 设计契约 | 十二个字段全部填写，无一为空或「待定」；有重复项时重复项的信息量已逐条列出次级信息 |
|
||||
| 页型判定（2026-10-05 新增） | 已写出「营销页还是工具型页面」+ 依据；工具型页面的 D0 里零 `.eyebrow` / 零 `.lead` / 零 `.hero` |
|
||||
| 结构骨架（加法面） | 骨架档 / 区块划分 / 密度目标三者已写；区块 ≥2 个且每个有文字标题；`必要内容` 每条都有归属区块 |
|
||||
| 交互清单（加法面，2026-10-02 新增） | 页面上每一个可点元素都在表里（元素 / 触发 / 反馈 / 何时不可点 四列齐全）；表里没有的可点元素为 0 |
|
||||
| 状态覆盖 | 六个状态逐项有结论（勾选，或「不适用 + 理由」） |
|
||||
| 令牌表 | 色值 / 字体 / 间距两档且适用面已分开写 / 圆角 / 阴影全为具体值 |
|
||||
| 字阶定值表 | 七档每档一个 px 定值（不是区间）；相邻档差 ≥2px；每档只许一个定值 |
|
||||
| 高度层级 | 每层都有多层叠层值；同层级同值 |
|
||||
| 布局脚手架 | 骨架档已落到具体列宽；窄屏变化写具体 |
|
||||
| 组件规格 | 按钮三档 + 卡片两档 + 输入框 + 徽章均为具体值；同一父区块内主档 ≤1；实底底色 ≥2 种 |
|
||||
| 供给核对（本项目附加） | 三处供给已确认在位；选定套名与 `DESIGN.md` 记录一致；不一致则变更清单已确认并写入修订记录 |
|
||||
| 反 slop | 无紫→粉渐变、标题未用禁用字体、强调色已写明允许位置 |
|
||||
| 拒绝清单 | ≥3 条，且每条可判定 |
|
||||
| token 引用完整性（本项目附加） | 语义层只引 primitive、组件层只引语义层、无孤立 token |
|
||||
|
||||
任一项不过 → 停在 3a 补齐，不进 3b。
|
||||
|
||||
> 对比度门槛按 `open-design/craft/color.md`（正文 4.5:1 / 大字 3:1 / UI 组件 3:1），由终检阶段按真实像素复测（静态算不准 CSS 变量叠加后的结果）。
|
||||
> 已知环境问题：`npx @google/design.md lint` 在本机完全不可用（alpha + clack 交互库，非 TTY 管道下静默且 exit 0）。不要拿它当校验关卡，也不要因它无输出就认为通过。
|
||||
|
||||
## 3b 原型（构建）
|
||||
|
||||
> ⛔ 开工前先判页型（2026-10-05 新增，硬前置）：写下「本页是营销页还是工具型页面，依据是什么」。
|
||||
> 两种页型的目的不同，骨架不能通用：营销页目的是说服（主张 → 论据 → CTA），工具型页面目的是完成一件工作（数据 + 操作）。
|
||||
> 判别口径：要用户「下决心去做某事」⇒ 营销页；要用户「把这件事做完」⇒ 工具型页面。⚠️ 判不准时按工具型处理（默认取严）。
|
||||
> 判不出来不许进 3b，停下来回改 D0 的 `结构骨架`。
|
||||
> 🔴 为什么这条是硬前置：`open-design` 的种子 `assets/template.html` 是营销落地页骨架，自带 `.eyebrow`（眉标）与 `.lead`（副标题）。不判页型就照种子做，会得到「标题上方一行小字 + 大标题 + 下方一行灰色小字」的三段式——那是 2026-10-05 用户实测指出「像实习生画的」的唯一根因，而且结构判据全绿（判据判类名合法性，判不出「这不是工具界面的排版」）。页型不判，后面换什么设计系统都救不回来。
|
||||
|
||||
按 `open-design/design-templates/web-prototype/SKILL.md` 的六步走：读种子 → 把 `assets/template.html` 复制成 `index.html` 并替换 `:root` 令牌 → 先定版式节奏再粘骨架 → 填充 → 自查 P0/P1/P2 → 落盘。它的路线是「先选定一个明确的美学方向再写码」，与铁律 1 同向。
|
||||
|
||||
- ⭐ 工具型页面先判形态，再挑骨架（2026-10-02 新增）：读 `references/layouts-tooling.md`。本项目是工具型数据密集界面，而 `web-prototype/references/layouts.md` 那 8 个骨架是落地页 / 营销页向（hero / features / stats / quote / cta / log / pricing），只有 Layout 7 日志列表与 Layout 8 对比表沾得上。
|
||||
⚠️ 两份工具型文件的分工（2026-10-05 补）：`open-design/.../web-prototype/references/tooling.md` 给四形态判定句 + 通用红线纲要；本技能 `references/layouts-tooling.md` 给可粘贴 HTML 骨架 + 逐条判据正文（§5.5）。⛔ 判据只在后者展开，前者只指路，两处展开必然漂。
|
||||
形态判定一句话：页面上能数出「并列的同类记录」⇒ 列表型（工具型默认首选）；数不出、页面围绕单个对象展开 ⇒ 详情型；主操作要在两个工作面之间来回 ⇒ 侧区型。
|
||||
⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。
|
||||
- 不许从零手写 `<section>`：先挑最接近的骨架粘进去再改。`open-design/design-templates/web-prototype/references/layouts.md` 开头的类清单（`section` / `container` / `card` / `btn-primary` / `grid-3` …）必须在种子 `template.html` 的 `<style>` 里存在；缺哪个就补进 `<style>`，⛔ 不许在标签上内联一堆临时样式。
|
||||
- 输出形态：单文件 HTML、自包含、双击可开（与 `web-prototype` 的产出契约一致：只有 `index.html` 一个文件），含全部适用状态，不许有死按钮。
|
||||
|
||||
重大改版必须复制副本再改（`X.html` → `X v2.html`），不许覆盖旧版，旧版留在磁盘上以便对比。这是本项目的附加纪律（版本管理主线需要可追溯），open-design 未涉及。
|
||||
|
||||
交付前必须实测（本步硬关卡）：用 `browser-harness` skill 按清单逐个真点，以 D0 契约的「交互清单」为唯一清单（⛔ 不用自己临场编的顺序）：每行按「触发 → 反馈」实跑一遍，四态（空 / 加载 / 错误 / 失败重试）都要走到；回报控制台报错原文与「点了没反应」的元素清单。
|
||||
|
||||
> 交互清单在这一步才第一次被验证：Gate-1 只判「表写全了没」，判不了「真能跑」。清单与实现对不上，就是清单错了或实现错了，二者必居其一，都要在 `3d-审查报告.md` 里留痕，不许静默改表。
|
||||
|
||||
> 脚本查不出死按钮（即便脚本在位，它也只判溢出 / 对比度 / 状态可见性 / 点击目标尺寸，判不了「元素没绑事件」）。未跑实测不得进 3c，也不得报完成。
|
||||
> 实测一律走 `browser-harness`（浏览器入口 9333），禁用 Trae 自带浏览器工具。
|
||||
|
||||
## 3c GPT 会诊（必做）
|
||||
|
||||
触发点：原型初稿出完、3b 的浏览器实测过了，立刻做本步；做完才许进 3d。
|
||||
|
||||
做什么：用 `browser-harness` skill 打开 `chatgpt.com`，把原型交给 GPT 做一轮独立审查，专挑设计与交互的毛病，把回答取回来逐条处置。③段前三步全是本地确定性检查，没有外部视角，这一步补的正是它补不了的那块。
|
||||
|
||||
执行步骤：
|
||||
|
||||
1. 沿用用户已登录的浏览器会话打开 `chatgpt.com`。不要新建账号、不要代填密码、不要碰设置页。
|
||||
2. 用附件上传原型 HTML 文件（`designs/<项目>/<原型>.html`）。不要把上万字符的代码粘进输入框，会被截断或打字超时，且拿不回完整上下文。
|
||||
3. 随附件发这段提问模板：
|
||||
|
||||
```
|
||||
这是一个可交互原型（单文件 HTML，含内联样式与脚本）。请以资深产品设计师的视角审查，
|
||||
只提可落地的改进项，按下面五类逐条给：
|
||||
1) 交互与状态：空态 / 加载 / 错误 / 失败重试 四处有没有缺口或死路
|
||||
2) 布局与层级：信息密度、对齐、视觉动线、主次是否清楚
|
||||
3) 反馈：每个可点元素点击后有没有可见反馈；列出"点了没动静"的元素
|
||||
4) 可访问性：焦点管理与顺序、键盘可达、对比度、语义标签
|
||||
5) 文案：是否有歧义、术语不一致、把机器结论说成人已认可的地方
|
||||
每条格式：问题 / 位置（选择器或组件名）/ 改法 / 优先级（高/中/低）
|
||||
不要重写整个文件，只出清单。
|
||||
```
|
||||
|
||||
4. 等回答出完再取（停止生成按钮消失或出现复制按钮），把回答原文取回，不要读一半就走。
|
||||
5. 落盘 `designs/<项目>/3c-GPT会诊.md`，三段式：提问原文（含附件文件名）→ 模型回答原文 → 处置表。
|
||||
|
||||
处置表固定四列：
|
||||
|
||||
| # | 模型建议（原文摘句） | 判定 | 理由 | 落地位置 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | ... | 采纳 / 不采纳 / 待议 | 对照 `DESIGN.md` 与②段说清 | 文件 + 选择器 |
|
||||
|
||||
功能作用：引入一个不在本项目上下文里的外部视角，补自己看不见的盲区。
|
||||
|
||||
输入边界：只传原型 HTML 与必要的产品背景；不传密钥、真实用户数据、内网地址、`.env`。代码里若有 token 或接口地址，先替换成占位符再上传。一次只审一份原型。
|
||||
|
||||
异常情况：登录失效 / 人机验证 / 网络不通 / 回答被截断时，不要假装跑过。退路是把提问模板和原型文件路径交给用户，由用户在自己浏览器里问，再把回答粘回来落盘。仍然取不到时，在 `3c-GPT会诊.md` 里写明「本轮未取得外部审查」，并在本段收尾时明示，未取得不等于已通过。
|
||||
|
||||
处置纪律：模型建议不是命令。采纳要给理由，与 `DESIGN.md` 或②段冲突的写清为什么不采纳。采纳项在 3d 之前改完，并回到 3b 的实测清单把这些改动再点一遍。
|
||||
|
||||
## 3d 审查与打磨（收口 + 动效 + 终检 + Gate-2/3）
|
||||
|
||||
### 收口（管「写得对不对」）
|
||||
|
||||
对照 `open-design/design-templates/web-prototype/references/checklist.md`（P0 / P1 / P2 三级）＋ `craft/` 的四份数值判据（`typography.md` / `color.md` / `state-coverage.md` / `animation-discipline.md`）逐条过。先机器、后人工：
|
||||
|
||||
> ⚠️ 本段收口一律人工过（2026-10-02 用户定案「不重要的相关内容都删」）：checklist 人工过 ＋ 渲染截图 ＋ DOM 取值，三项缺一不可。
|
||||
> ⛔ 判据来源：`craft/checklist.md` ＋ `craft/anti-ai-slop.md` ＋ `craft/accessibility-baseline.md` ＋ `craft/color.md`（对比度），本项目追加条见 runbook §3.4。
|
||||
> ⛔ 结论只能写「人工判定」，⛔ 不许写「已通过」（人工过就是人工过，不借机升格）。要指向交付的单文件，不要指向多文件开发目录。
|
||||
|
||||
### 动效（可跳过）
|
||||
|
||||
按 `open-design/craft/animation-discipline.md` 先答动效三问：① 它传达什么信息？② 删掉会丢失什么？③ 是不是为了「看起来高级」？答不出就不加。
|
||||
|
||||
- 工具型页面（仪表盘 / 后台 / 编辑器 / 工作台）禁止入场编排，用户一天开几十次，每次播一遍是折磨。本项目的版本管理界面属工具型；判不准时按工具型处理
|
||||
- 弹簧用 Damping / Response 二参数（Damping 保持 0.8–1.0、Response 0.3–0.4s；低于 0.7 会明显「蹦」）
|
||||
- CSS 无法用真弹簧时用 `cubic-bezier(0.32, 0.72, 0, 1)`，不得用 `linear` / `ease` / `ease-in-out` 做过渡曲线
|
||||
- 交互过渡禁 `@keyframes animation`（不可中断，反向操作会跳帧），用 `transition` 或 WAAPI
|
||||
- 只动 `transform` / `opacity`，不动 `width`/`height`/`top`/`left`；禁止 `scale(0)` 起手（用 `scale(0.95)` + opacity）
|
||||
- 退出比进入快（进 300ms / 出 200ms）；同屏动效元素 ≤3 个且有 30–50ms 错峰
|
||||
- `prefers-reduced-motion` 必须处理
|
||||
|
||||
### 终检（管「能不能交」）
|
||||
|
||||
过 checklist 的 P0/P1 ＋ `craft/state-coverage.md`（状态穷举）＋ `craft/anti-ai-slop.md`（反 AI 味，⛔ 不在本文件抄清单）＋ 动效三问 ＋ 交互清单逐行复测（表里每一行的「触发」与「反馈」都要真发生过，且与实现一致），并真渲染一次：
|
||||
|
||||
```bash
|
||||
# 本机 Chrome 无头截图（2026-10-02 实测可用；门禁脚本补上后仍以脚本为准）
|
||||
"/c/Program Files/Google/Chrome/Application/chrome.exe" --headless=new --no-sandbox --disable-gpu \
|
||||
--hide-scrollbars --window-size=1440,900 --virtual-time-budget=3000 \
|
||||
--screenshot="<Windows 绝对路径>/P1.png" \
|
||||
"file:///<原型绝对路径，中文需 URL 编码>#/p/xxx"
|
||||
```
|
||||
|
||||
- ⚠️ 两条坑：`--screenshot` 必须给 Windows 绝对路径（给相对路径会写进 Chrome 安装目录，回来找不到）；中文文件名要 URL 编码
|
||||
- 在 `1440x900` 与 `390x844` 两个视口各截一张；对外评审 / 交付留档只用视口帧，整页长图仅自检。⛔ 混用会出事：实测把长图交出去，移动端是 1:7.1 的长条，外部评估只能按长条理解布局，「首屏有没有主次」「坐得下几行」根本没被评审到
|
||||
- 结构与排版仍要量（字号档数与相邻档差 / 正文档承载占比 / 标题大纲 / 按钮高度与实底分档 / 列对齐 / 对齐锚点 / 浮层可见关闭出口唯一）：脚本缺失期间靠 DOM 取值人工量，结果直接抄进 `3d-审查报告.md` 的结构核对表。⛔ 不许目测截图下结论
|
||||
- 「无法判定」一律按未通过对待（「判不了」≠「没问题」）：浮层类在未打开态必然判不了，必须按 Gate-3 的打开态复测口径，手工打开每个浮层再数一遍并留痕
|
||||
- 本项目的状态由路由与演示开关驱动，不用 `?state=`；状态可见性由 `browser-harness` 实测承担
|
||||
|
||||
### Gate-2 完成门
|
||||
|
||||
全部 `阻断` 项清零，`建议` 项逐条有结论：修掉，或显式写「已知不修 + 原因」。不接受「基本没问题」「应该差不多」「剩余都是小问题」。每条要么修，要么留痕。
|
||||
|
||||
### Gate-3 交付门（硬闸，任何挡位不可跳）
|
||||
|
||||
真实渲染后（浏览器打开，非只看代码）肉眼过八项：裁切 / 重叠 / 失真 / 失效控件 / 缺状态 / 响应式破损 / 控制台报错 / 字体回退异常。渲染截图已代劳其中的溢出与响应式破损，其余仍需人眼（截图查不出「点了没反应」）。
|
||||
|
||||
### 审计报告落盘
|
||||
|
||||
`designs/<项目>/3d-审查报告.md`，固定七节：范围 + 挡位 + 阻断项表 + 建议项表 + 状态覆盖核对表 + 结构核对表 + Gate 结论（含「本轮是否跑了脚本」一句）。
|
||||
|
||||
## 硬约束
|
||||
|
||||
- ⭐⭐ 骨架冻结，不许动板块（2026-10-06 用户定案）：页面清单、每页板块、板块排列、跨页关系由②段《界面布局》定死。
|
||||
⛔ 本段不许新增 / 移动 / 删除 / 合并板块。做不下来 / 觉得缺板块 ⇒ 回②段改《界面布局》，⛔ 不许就地加一块，就地加会让②段与原型不一致，下一个读原型的人拿到的是错的骨架。
|
||||
可动的是板块内的视觉与交互实现（怎么排版好看、点哪有什么反馈、空态怎么呈现、响应式怎么变）。
|
||||
⛔ 不许无视②段骨架另起一套。D0 的页面清单与每页板块必须与②段《界面布局》逐条对得上；对不上就停下来问②段要哪一版。
|
||||
- 声明制：开工前、每进一个子步、每处偏离，都要声明（当前子步 / 依据文件 + 小节号 / 产出落点）。不许静默偏离。段末必须附偏离单，没有偏离单不得报完成。
|
||||
- 设计工程供给默认是 `open-design`（三处：设计系统 / 工艺规约 / 原型模板，按需取用）；冲突处以本段与 `DESIGN.md` 为准。不许跳过 Gate-1 或 Gate-3。
|
||||
⚠️ `open-design` 不可得时（它只在工作区级，别的工作区可能没有）⇒ 见上方「不可得时的回落」：由 `oil-ui-pro` 顶方向探索与评审，但定调与工艺数值判据会没有来源，⛔ 不许凭感觉编。
|
||||
- 页型先判再动手（2026-10-05 新增）：3a 的 D0 必须写出「营销页 / 工具型页面 + 依据」。工具型页面零 `.eyebrow` / 零 `.lead` / 零 `.hero`，三者已从种子删除或降级为 `body.is-marketing` 专用。⛔ 判不出页型不许进 3b。
|
||||
- `open-design` 的 `web-prototype` 种子是营销落地页骨架：⛔ 工具型页面不许直接套用其版式节奏与标题区结构；版式走本技能 `references/layouts-tooling.md`。这是一处「照供给做反而错」的例外，必须显式绕开。
|
||||
- 先定死，再写码：设计契约与令牌表未落笔，不许写任何组件代码。
|
||||
- 限载：一次只读 1~2 份供给原文，用完释放（`design-systems/` 153 套、`craft/` 13 份，全读必然互相稀释）。
|
||||
- 不许覆盖旧版：重大改版先复制副本再改（`X.html` → `X v2.html`），旧版留在磁盘上以便对比。
|
||||
- 3a 必须在 3b 之前，规范是原型的输入。
|
||||
- 门禁脚本只作校验，不是原型生成工具。出原型只用 3b（脚本当前缺失，见 3d 的「门禁脚本现状」）。
|
||||
- 原型必须可点通：每个按钮、每个跳转都真能走，不许留死链。可点通的清单就是 D0 契约的「交互清单」，清单之外的可点元素 = 未登记元素，必须回 D0 补登记或改成静态，⛔ 不许「清单没写但先做着」。
|
||||
- 交互清单是唯一交互真相源（2026-10-02 新增）：段名已改为「界面交互」，故交互判据只许写在契约第十二字段里。3b 实测、3c 会诊、3d 终检都引用同一张表，⛔ 任何一处另立一份交互清单（另建文档、另写章节、另做交互规范）都算第二真相源，这正是记忆里「同一事实多处落点必然打架」的成因。
|
||||
- 3b 交付前必须用 `browser-harness` 跑实测；脚本查不出死按钮，未跑实测不得进 3c，不得报完成。
|
||||
- 3c GPT 会诊必做：原型初稿 + 实测过后立刻做，不许用「我觉得没问题」代替。回答原文必须落盘，不得伪造或转述失真；未取得外部审查时要在 `3c-GPT会诊.md` 与收尾里明示，未取得不等于已通过。上传前先脱敏。
|
||||
- Gate-2 / Gate-3 不许口头通过：阻断项要么修完，要么留痕；「未取得审查」不等于已通过。
|
||||
- 原型的说明区与演示引导不是本段的事：各状态下的「场景 / 从左到右流程图 / 步骤说明 / 演示引导」由第④段 `stage-proto-doc` 负责。3d 完就交付原型本身。
|
||||
- `DESIGN.md` 落 `docs/pm/<项目>/`，不放仓库根。
|
||||
- 段内子步之间不反问，做完直接进下一个子步。只有三种情况停：信息不足且查不到、破坏性/不可逆动作、用户显式要求。
|
||||
- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- 声明制走完：开工、每个子步、每处偏离都有声明；偏离单已附，无静默偏离
|
||||
- 挡位已声明（快速 / 标准 / 严格）
|
||||
- 页型已判（营销页 / 工具型页面 + 依据）；工具型页面零 `.eyebrow` / 零 `.lead` / 零 `.hero`，且 `layouts-tooling.md` §5.5 五条逐条过完（含「标题区零从属小字」的 DOM 取值核对）
|
||||
- `docs/pm/<项目>/DESIGN.md` 存在，含设计契约（十二个字段，含结构骨架、交互清单与重复项的信息量）与令牌表（三层 token 结构，含组件规格、容器与对齐锚点、浮层只许一个可见关闭出口，全为具体值），且 Gate-1 全部自检项结果写在文件末尾
|
||||
- 原型 HTML 单文件自包含、双击可开，含全部适用状态（状态穷举六项逐条有结论）
|
||||
- 原型经真实渲染验证过，控制台无报错
|
||||
- 每个按钮都经 `browser-harness` 真点过，有实测回报（含控制台报错原文与死按钮清单）
|
||||
- 静态收口已过（脚本在位 ⇒ 已跑且阻断清零、有输出留档；脚本缺失 ⇒ 已按 checklist 人工过，并在报告中写明「未跑脚本 + 原因」）
|
||||
- 渲染终检已过（溢出 0 / 对比度按真实像素达标 / 结构与排版量测无阻断且无「无法判定」项 / 两个视口的截图都存进 `_gate_shots/`），或已写明为何不适用。量测数字以 DOM 取值与脚本输出为准，不得用「目测」代替
|
||||
- 每个浮层都手工打开数过可见关闭出口（`== 1`），`Esc`/点遮罩能关、焦点锁在层内且关闭后回到触发按钮，结论连同触发路径写进 `3d-审查报告.md`。「代码里看着只有一个」不算
|
||||
- 对外提交/交付留档的截图只用视口帧（`_gate_shots/<视口>.png`）；`_full/` 下的长图不得作为评审输入
|
||||
- `designs/<项目>/3c-GPT会诊.md` 存在，含提问原文、模型回答原文与逐条处置（采纳项已改完并复测）；未取到外部审查的已明示
|
||||
- `designs/<项目>/3d-审查报告.md` 存在，含阻断/建议两张表 + 状态覆盖核对 + Gate-2/3 结论
|
||||
- Gate-2 与 Gate-3 均已通过（书面结论，非口头）
|
||||
- 重大改版：旧版文件仍在磁盘上，且收尾给出新旧差异（改了什么 / 为什么 / 代价）
|
||||
|
||||
## 反面清单
|
||||
|
||||
- ⛔ 就地增删板块（2026-10-06 新增）：觉得骨架不合适就自己加一块 / 挪一块 / 删一块。骨架归②段，要改回②段改，本段只能动板块内的视觉与交互实现；就地改会让②段与原型不一致
|
||||
- ⛔ 无视②段骨架另起一套（2026-10-06 新增）：D0 的页面清单与每页板块必须与②段《界面布局》逐条对得上
|
||||
- 先出原型再补规范（违反铁律 1）
|
||||
- 违反限载：一次把全部 `design-systems/` 或 `craft/` 原文读进上下文（一次只许 1~2 份）
|
||||
- 不判页型就照 `web-prototype` 种子做，会把后台做成营销页（标题上下各一行小字）；或拿 `layouts.md` 的营销骨架顶替工具型版式
|
||||
- 只画了 success 态就当状态齐了（违反铁律 3）
|
||||
- 跳过 Gate-1 或 Gate-3；或拿「我觉得还行」当 Gate-2 结论
|
||||
- 在无脚本时把「没跑」写成「已过」；或从零手写 `<section>` 不套骨架、把临时样式内联在标签上
|
||||
- 覆盖旧版：重大改版直接改原文件，把可对比的旧版弄丢
|
||||
- 把 `DESIGN.md` 写到仓库根（多项目会互相覆盖）
|
||||
- 原型里有死按钮或空链接；只用脚本判过就当实测过（脚本查不出死按钮）
|
||||
- 拿默认配色和系统字体糊一个「能看」的界面交差
|
||||
- 跳过 3c GPT 会诊直接进 3d，或只把代码片段贴进对话框、回答没出完就取走当完整建议
|
||||
- 把模型建议当命令照抄，改坏与 `DESIGN.md` 的一致性；或伪造「GPT 说……」却拿不出回答原文
|
||||
- 把「未取得外部审查」当已通过
|
||||
- 工具型页面做入场编排；用 `linear`/`ease` 做过渡曲线；用 `@keyframes` 做交互过渡
|
||||
- 越界回头改②段的功能取舍（那是第②段）——⚠️ 但「骨架缺板块」是例外：必须回②段改，⛔ 不许就地在原型里加
|
||||
- 顺手把原型说明文档 / 演示引导写了（那是第④段 `stage-proto-doc`）
|
||||
|
||||
## 待补（2026-10-02 登记 · 2026-10-06 更新）
|
||||
|
||||
- ~~`execution-runbook.md` 的必读表全部指向已不存在的文件~~：已于 2026-10-02 修复（用户定案「第三部分用 open-design」后执行）。原 D0/D3/D4/D5 四行引用的 `ui-page-design/references/0X_*.md` 与 `vendor/*` 已全部重接：`D0 → runbook §2.1`（十二字段留在本项目）｜`D0 判据 → craft/state-coverage.md`｜`D1 → open-design/design-systems/ 选套`｜`D2 → design-templates/web-prototype/`｜`D3 → craft/typography.md` + `typography-hierarchy.md`｜`D4 → craft/animation-discipline.md`｜`D5 → checklist.md` + `craft/anti-ai-slop.md` + `craft/accessibility-baseline.md`。
|
||||
同时做了一次能力去向盘点（判据逐条归属，不做适配搬运）：craft 接住 6 类（状态穷举 / 字阶 / 配色 / 动效 / 反 AI 味 / 无障碍与表单校验）；接不住 3 项，必须留在本项目 —— 设计契约十二字段 / 结构骨架 / 交互清单；5 份 vendor（`ui-ux-pro-max`／`frontend-design`／`apple-design`／`anti-ui-slop`／`web-design-guidelines`）无需保留。
|
||||
⛔ 修复后的纪律：判据来源必须单一可查。某条判据若在 runbook 与 craft 各有一份且口径不同，以本项目追加条为准，并在 §3.4 显式标注「本项目追加」。
|
||||
- ~~工具型页面的版式库~~：已于 2026-10-02 补齐。新建 `references/layouts-tooling.md`，四类形态各给一份可判定骨架：行式列表 / 表格式清单 / 详情面板 / 主从侧区。每类带形态判定句（判不出形态就去改 D0 `结构骨架`）＋ 可机械核对的判定要点（如「一屏可见行数 ≥6」「数字列右对齐」「表头必须写判据来源」「未跑必须能作为取值存在」）。已接进三处：3b 正文（形态判定先行）｜runbook §1 必读表 D2 行（工具型另读）｜runbook「⛔ 四样 craft 接不住」表（第四行）。
|
||||
⭐ 红线：⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。
|
||||
- ~~①②段的同型改造~~：已于 2026-10-02 完成。四段已改名为「①产品需求 / ②产品功能 / ③界面交互 / ④原型说明文档」，并各自重划了子步职责（见 `product-planning` 的四段表与交接口表）。
|
||||
- ⛔ 骨架归属已于 2026-10-06 反转：本节原口径是「页面结构归本段，唯一落点是 D0」；用户定案改为「②段钉骨架，③段做皮肉」（原话：页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子）。⇒ `必要内容` / `结构骨架` 两个字段口径已调整，从「本段独立裁决」改为「在②段给定骨架之内决定视觉与交互实现」。详见本文件开头「⭐⭐ 页面骨架不归本段了」块。
|
||||
⚠️ 待核：`references/execution-runbook.md` 的 D0 段仍写着旧口径（「独立推导几个页面」），需同步改。另，`gate-<段号>-<段名>.md` 本项目从未建立，属存量缺口。
|
||||
+392
@@ -0,0 +1,392 @@
|
||||
# ③段执行手册（固化流程）
|
||||
|
||||
`SKILL.md` 写规则，本文件写照着走的顺序与验收。跑③段时按本文件逐步走；任何一步偏离，必须当场声明并记入第 6 节偏离单。
|
||||
|
||||
> 本手册为什么存在：③段 3b 交付了原型，却走了别的主流程、没读依据文件、执行时也没声明，用户直到追问「基于哪个 skill」才知道。所以第一条是声明制，第二条是逐步写明依据哪个文件的哪一节。
|
||||
> ③段的设计工程供给是 `open-design` 技能，按技能名引用，不写死相对路径（技能位置一变就失效且不报错）。流程规则与契约字段留在本手册与 `SKILL.md`。两者分工见第 1 节末的「⛔ 四样必须留在本项目」。
|
||||
|
||||
---
|
||||
|
||||
## 0. 声明制（核心，唯一不可商量的一条）
|
||||
|
||||
开工前先输出一段流程声明，四个字段：
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| 当前段与子步 | 例：③段 / 3b 原型（D2 构建） |
|
||||
| 主干与挡位 | 例：供给 `open-design` / 挡位「标准」（或「快速」） |
|
||||
| 依据文件 | 本步照的是哪个文件的哪一节，写精确路径 + 小节号 |
|
||||
| 产出落点 | 本步会写哪个文件 |
|
||||
|
||||
每进一个子步重发一次这四行（子步之间不反问，但必须声明）。
|
||||
|
||||
偏离时当场声明：
|
||||
|
||||
```
|
||||
偏离：<原要求> → <实际做法>；原因：…；影响：…
|
||||
```
|
||||
|
||||
并记入第 6 节。不许静默偏离，不许事后补说。
|
||||
|
||||
---
|
||||
|
||||
## 1. 必须加载的文件（按阶段加载，用完释放）
|
||||
|
||||
> ⚠️ 2026-10-02 已重接必读源。原必读表指向 `ui-page-design/references/02_~05_*.md` 与 `vendor/*`，该目录实测已不在磁盘上（工作区与全局技能根两处都查过），照旧表走 D0 读不到任何一份必读文档。现改为直接引 `open-design` 技能（按技能名引用，不写死相对路径）。
|
||||
> 改动原则：判据类全部交出去，只保留 craft 没有对应的东西。
|
||||
|
||||
开工前必读两个页面设计技能的位置与分工：`open-design/craft/README.md`（读一份就知道有哪些规约、怎么按需取），以及本段 `SKILL.md` 的两技能分工表。
|
||||
|
||||
其余不许一次全读。同一时刻只读 1~2 份，用完释放；`design-systems/` 153 套、`craft/` 13 份全读必然互相稀释。
|
||||
|
||||
| 阶段 | 读什么 | 为什么 |
|
||||
|---|---|---|
|
||||
| D0 | 本文件 §2.1（设计契约十二字段） | craft 无对应 —— 字段清单是本项目的东西，只在这里 |
|
||||
| D0 判据 | `craft/state-coverage.md` | 状态六项的逐项判据 |
|
||||
| D0 页型（2026-10-05 新增） | 本文件 §2.1 步 6（先判页型：营销页 / 工具型） | 挑版式骨架之前必须先判。判错页型 = 拿营销骨架做后台，是「标题上下两行小字」的唯一根因 |
|
||||
| D1 | 选定套 `DESIGN.md` + `tokens.css` + `components.html`；可选 `craft/color.md` | 定调来自选套，不来自检索脚本 |
|
||||
| D1 多方向比选（按需） | `oil-ui-pro` 的 `references/design-direction.md` + `references/style-explorer.md` | 要「拉开几个方向让用户挑」时的方向卡与对比页（另一技能，平行取用） |
|
||||
| D2 | `open-design/design-templates/web-prototype/SKILL.md` + 同目录 `references/layouts.md`（营销页）／工具型页面另读两份：本技能 `references/layouts-tooling.md`（HTML 骨架与落地自检）＋ `open-design/design-templates/web-prototype/references/tooling.md`（四形态判定句与通用红线纲要） | 「先选定美学方向再写码」＋ 版式骨架。⭐ 落地页那 8 个骨架不适用于工具型（hero/features/stats/quote/cta/log/pricing），工具型版式只在本项目那份里，不许拿营销页顶替。⚠️ 两份工具型文件是「骨架 vs 纲要」分工，判据不重写（判据正文在 `layouts-tooling.md`） |
|
||||
| D3 | `craft/typography.md` + `typography-hierarchy.md`（+ 按需 `color.md`） | 字阶定值表与层级判据（取代原 `03_视觉与骨架规则.md`） |
|
||||
| D4 | `craft/animation-discipline.md` | 动效三问、弹簧二参数（取代原 `04_动效与手势规则.md`） |
|
||||
| D5 | `design-templates/web-prototype/references/checklist.md` + `craft/anti-ai-slop.md` + `craft/accessibility-baseline.md` | 终检清单、反 AI 味、无障碍底线（取代原 `05_审计门禁与输出格式.md`）。⚠️ 工具型页面必须过 checklist 的 `P0-A 标题区纪律`（2026-10-05 新增，五条） |
|
||||
| D5 独立评审（按需） | `oil-ui-pro` 的 `references/visual-review.md` + `references/tools.md` | 要「没看过制作过程的评审打分」时的协议与截图取证（不替代本段 Gate） |
|
||||
| 每步 | `docs/pm/<项目>/DESIGN.md` | 本项目绑定规范；原型只许引它的 token |
|
||||
|
||||
⛔ 四样东西 craft 没有对应，必须留在本项目（本文件 / `SKILL.md` / `references/layouts-tooling.md` 里）：
|
||||
|
||||
| 留什么 | 为什么 craft 接不住 |
|
||||
|---|---|
|
||||
| 设计契约十二字段 | craft 是通用工艺，不定义字段清单；D0 字段是本项目的产物 |
|
||||
| 结构骨架（骨架档 / 区块划分 / 密度目标） | 实测 grep 全部 craft 只有零散的 layout 提及，无成体系的骨架规则 |
|
||||
| 交互清单（契约第十二字段） | 同上 —— 交互的判据在 craft 里只散见于 `state-coverage` 与表单章，不构成一份逐元素清单 |
|
||||
| 工具型版式库（行式列表 / 表格式清单 / 详情面板 / 主从侧区） | `web-prototype/references/layouts.md` 的 8 个骨架是落地页／营销页向；craft 里零散提及不成体系。工具型数据密集界面的版式无任何现成来源 ⇒ 本项目自建 `references/layouts-tooling.md` |
|
||||
|
||||
定调来源唯一：从 `open-design/design-systems/` 选一套（153 套），按候选套 `DESIGN.md` 第 1 章 `Visual Theme & Atmosphere` 认准类型词。
|
||||
本 skill 的 `references/` 只放流程规则（契约字段 ＋ 执行顺序 ＋ 门禁），不放任何风格底子。既有项目 `DESIGN.md` 里凡引用旧风格来源（`ui-ux-pro-max` / `minimalist-ui` / 皮肤族）的行，重跑 3a 时一律改写为「选定套名 ＋ 留痕对照」。
|
||||
|
||||
已整体移除的 vendor，不必再找：`ui-ux-pro-max`（被 153 套设计系统取代）、`frontend-design`（D1 已改选设计系统）、`apple-design`（动效已由 `craft/animation-discipline.md` 覆盖）、`anti-ui-slop`（按本项目收录标准「依赖外部服务」整体移除，判据由 `craft/anti-ai-slop.md` 接管）、`web-design-guidelines`。
|
||||
⚠️ 判据一旦落进本项目的条款，就不再依赖原出处的存续。上面五份的可执行内容已在 `SKILL.md` 铁律、`craft/` 与本文件里，删掉原出处不影响执行。
|
||||
|
||||
---
|
||||
|
||||
## 2. 3a 视觉规范（D0 锚需求 + D1 定调 + Gate-1）
|
||||
|
||||
### 2.0 供给核对（步 −1，每轮必做）
|
||||
|
||||
`open-design` 是外部供给，会被上游更新，而本项目的 `DESIGN.md` 是上一次供给状态下产出的。不核对就长期拿旧调性当准绳：换套后门禁判不过，却不知道哪条变了。
|
||||
|
||||
| 步 | 动作 | 验收判据 |
|
||||
|---|---|---|
|
||||
| −1 | 确认三处供给仍在位：`design-systems/`（并记录本项目选定套名）、`craft/`、`design-templates/web-prototype/` 都存在 | 三处都在位；`DESIGN.md` 记录的上次套名已找到 |
|
||||
| −1b | 套名一致 → 直接进 D0 | 开工声明里写一句「选定套 `<套名>`，与项目记录一致」 |
|
||||
| −1c | 套名不一致或供给缺失 → 停下报告，不许拿别的套顶上，也不许凭记忆写风格 | 产出供给变更清单（逐条：变了什么 → 本项目现状 → 要改什么），在会话里呈现并获用户确认后才改 `DESIGN.md` |
|
||||
|
||||
> 不要静默跳过：一致也要在开工声明里写一句套名；不一致必须停下，这是硬闸。
|
||||
|
||||
### 2.1 D0 锚需求 → 设计契约
|
||||
|
||||
> ⭐⭐ 口径（2026-10-06 用户定案）：骨架归②段，本段做皮肉。
|
||||
> ②段《界面布局》里的页面清单、每页板块、板块排列、跨页关系就是骨架定稿。本段不许增删移动板块，要改回②段改。本段在给定骨架内决定视觉与交互实现。
|
||||
> 理由（用户原话）：「页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。
|
||||
> ⛔ 仍归本段的：配色 / 字体 / 间距 / 组件样式 / 动效 / 板块内的排版与交互行为 / 响应式。
|
||||
|
||||
读②段时取四样：骨架（页面清单 ＋ 每页板块 ＋ 排列 ＋ 跨页关系）、必须在界面上发生什么、红线、禁用条件与状态流转。
|
||||
骨架是冻结输入，其余三样是功能约束。
|
||||
|
||||
按本节清单产出设计契约，十二个字段：页面职责（「让<谁>在<多久>内<完成什么>」）、主用户、主操作（全页唯一，写了两个就该拆页）、必要内容（核对面）、重复项的信息量（行式列表 / 卡片网格时逐条列出：每个重复项除「主标识 ＋ 动作」外必须带 ≥1 条次级信息）、结构骨架（翻译面：把②段板块清单翻成骨架档 ＋ 列宽 ＋ 密度目标）、交互清单（2026-10-02 新增：逐个可点元素一行，四列「元素 / 触发 / 反馈 / 何时不可点」；动效参数归 3d、视觉样式归令牌表、「这个状态有没有」归下一字段状态覆盖）、状态覆盖六项逐条、组件来源（优先沿用既有）、响应式行为（写布局怎么变，不写「自适应」）、明确拒绝的模式（≥3 条可判定）、验收标准（可观察可判定）。
|
||||
|
||||
两个字段的分工（2026-10-06 调整）：`必要内容` 是核对面，`结构骨架` 是翻译面。
|
||||
|
||||
> `结构骨架`（翻译面）怎么落（规则留在本手册，craft 无对应：实测 `craft/` 只有零散 layout 提及，不构成骨架规则）：
|
||||
> ⭐ 输入是②段的板块清单，本字段做的是翻译，不是发明。
|
||||
> ① 骨架档：单列 / 主区＋侧区 / 主区＋侧区＋辅助区，选一档并写清理由。有 ≥3 个并列目的地且宽屏 ≥1024 时优先侧栏，但侧栏是项目级取舍，不许写死成「必须没有」。
|
||||
> ② 板块落位：把②段给的板块按顺序放进骨架档，每块给一个文字标题（页面 ≥2 个带文字标题的板块）。
|
||||
> ③ 密度目标：宽松（24–96）/ 标准（16–64）/ 密集（8–32），同一页面不得混用两档。
|
||||
> ⛔ 不许在②段板块清单之外加块，缺板块回②段改。
|
||||
> 板块先分、内容后放，顺序反了就只能得到一张平铺的长条。
|
||||
|
||||
> `必要内容`（核对面）的判据不变，但用途变了。
|
||||
> 判定标准仍是模板里那句「只留缺了就做不成事的」。
|
||||
> 逐条问：这条内容删掉，主操作还做得成吗？做得成，它就不该主屏常驻（②段分档表已定档位）。
|
||||
> ⚠️ 本段不得以 `必要内容` 为由增删②段已定的信息档位。档位归②段，本段只做落位核对。
|
||||
> 本段该做的是：核对②段的「主屏常驻 / 可点入」分档，在本段自己的视觉与交互实现里兑现它（常驻的零点击可见、可点入的一次点击可达）。
|
||||
> 危险信号：`必要内容` 与②段分档表逐条对不上（条数差很多、档位被改）→ 停下来说明，不自行改档。
|
||||
> 反面样例（本项目真实踩过）：版本列表的 `必要内容` 只该有「`vN` ＋ 语义名 ＋ `第 N/5 步` ＋ 状态徽章 ＋ 时间戳 ＋ 行尾当前动作」，实际却把每行那句解释性长文案（「目录建好了，还没有登记原始需求。」）也当成必备内容渲染上去，于是每行多出一整句、页面变成信息墙。
|
||||
|
||||
| 步 | 动作 | 验收判据 |
|
||||
|---|---|---|
|
||||
| 0 | 读②段《界面布局》，把骨架当冻结输入取走 | 页面清单与每页板块逐条抄进契约，未增删移动 |
|
||||
| 1 | 产出设计契约 | 十二个字段全填，无空、无「待定」；有重复项时「重复项的信息量」已逐条列出次级信息；交互清单覆盖页面上每一个可点元素 |
|
||||
| 2 | 状态覆盖逐项给结论 | 六项要么勾选，要么写「不适用 ＋ 理由」 |
|
||||
| 3 | 核对②段分档表：每条信息的「主屏常驻 / 可点入」 | 与②段分档表逐条对得上；档位未被本段改动（要改回②段） |
|
||||
| 4 | 落 `结构骨架`：把②段板块清单翻成骨架档 ＋ 列宽 ＋ 密度目标 | 骨架档给了理由；板块 ≥2 个且每个有文字标题；板块清单来自②段、未新增；密度目标只取一档 |
|
||||
| 5 | 自检块间距 ≥ 块内间距的 2 倍 | 块间 32/64、块内 8/12/16，比值 ≥2（写进令牌表） |
|
||||
| 6 | 判页型（2026-10-05 新增，D2 之前必做）：写一句「本页是营销页还是工具型页面，依据是什么」 | 结论明确且给了依据。判不出来不许进 D2，停下来回改 `结构骨架` |
|
||||
|
||||
> ⭐⭐ 步 6「判页型」是 2026-10-05 新增，补的是一处从未有过落点的缺口。
|
||||
> 病灶实测：本项目原型长出「标题上方一行小字眉标 → 大标题 → 下方一行灰色副标题」的三段式。
|
||||
> 根因不在③段执行：`open-design` 的种子 `assets/template.html` 是营销落地页骨架，CSS 里自带 `.eyebrow`（眉标）与 `.lead`（副标题），`layouts.md` 的 8 个骨架里有 6 个在用，而当时的 checklist 甚至明令保留（「Lead text under 56 ch … don't override」）。
|
||||
> 于是照种子做 = 结构全绿 ＋ 排版难看：判据判的是「类名合法」，判不出「这不是工具界面的排版」。页型不判，后面用什么设计系统、怎么打磨都救不回来。
|
||||
>
|
||||
> 两个页型的目的不同，骨架因此不能通用：
|
||||
> - 营销页（落地页 / 首页 / 定价页）：目的是说服，走「主张 → 论据 → CTA」，可用 hero / eyebrow / lead。
|
||||
> - 工具型页面（后台 / 控制台 / 列表 / 详情 / 看板 / 表单）：目的是完成一件工作，走「数据 ＋ 操作」，零 `.eyebrow`、零 `.lead`、零 `.hero`（三者已在种子中删除或降级为 `body.is-marketing` 专用）。
|
||||
>
|
||||
> 判别口径：页面要用户「下决心去做某事」是营销页；要用户「把这件事做完」是工具型页面。
|
||||
> ⚠️ 判不准时按工具型处理（默认取严）。
|
||||
|
||||
### 2.2 D1 定调 → 令牌表
|
||||
|
||||
从 `open-design/design-systems/`（153 套）选一套，不凭感觉编、不全读：
|
||||
|
||||
| 步 | 动作 | 验收判据 |
|
||||
|---|---|---|
|
||||
| 1 | 按本项目的页面类型挑候选（工具型数据密集界面 ⇒ 认 `data-dense, enterprise` 这类描述） | 已列出 2~3 个候选套名 |
|
||||
| 2 | 读候选套 `DESIGN.md` 第 1 章 `Visual Theme & Atmosphere`，认准写明该类的那一句 | 选定一个套名，理由写进会话声明 |
|
||||
| 3 | 选定后读三件：`DESIGN.md`（调性 / 色值 / 字号刻度 / 间距刻度 / 动效基调）→ `tokens.css`（圆角与阴影只有这里）→ `components.html`（组件实际长相） | 三件读过，数值来源可指认 |
|
||||
| 4 | 没找到匹配的套 ⇒ 换一个类型词再挑一次；仍不行就直说「未找到匹配」 | 不许把泛化结果当结论落盘 |
|
||||
|
||||
> ⚠️ 153 套分两代模板（A 组 / B 组章节名不同），按自己那套的章节读，不必统一。
|
||||
> ⚠️ 工具型页面的版式不在模板里：`web-prototype/references/layouts.md` 那 8 个骨架是落地页 / 营销页向，工具型页面只适用 Layout 7 日志列表与 Layout 8 对比表；其余套上去会把后台做成营销页。工具型版式由 D0 的 `结构骨架` 决定，不从模板抄。
|
||||
|
||||
产出令牌表：风格名、来源（选定套名 ＋ 套的章节）、浅深色色值、字体（标题字体是关键项）、间距两档（主刻度 `4/8/16/24/32/64` 供布局，控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）、圆角（按组件类各一个值）、字阶定值表（七档各一个 px，不是区间）、高度层级（每层都有多层叠层值）、布局脚手架（骨架档落到具体列宽 ＋ 窄屏变化）、组件规格（按钮三档 ＋ 卡片两档 ＋ 输入框 ＋ 徽章的具体高度 / 内衬 / 字号）、动效基调。全部为具体值，禁止「待定」；每档只许一个定值。
|
||||
|
||||
> 数值判据来自 `craft`：`typography.md`（刻度）、`typography-hierarchy.md`（层级行为）、`color.md`（配额与对比度，正文 4.5:1 / 大字 3:1 / UI 组件 3:1）。这三条定「怎么定」，选定套的 `tokens.css` 定「定成多少」。
|
||||
|
||||
> 字阶必须是定值表，不是区间。实测病灶：令牌表写「标签 12–13px」，代码落到 12.5px —— 既不在刻度上，又与正文档（14px）只差 1.5px，两档合计承载 68% 文字却拉不开层次。相邻档差 ≥2px，且每一档要承载 ≥40% 文字节点，否则等于没有分档。
|
||||
> 间距为什么要有第二档：实测某页 55% 的 padding 落在 `3/5/9px`，全是按钮内衬与徽章内衬；只有一套主刻度时，例外会变成主路径。微网格取偶数，`3px` / `5px` 等于没有网格。
|
||||
|
||||
> 组件规格是「草稿感」的分水岭。同一屏里按钮高度不一、内衬不一、字号不一，观感立刻散。分档靠填充色 ＋ 高度，不靠字号；同一父区块内主档 ≤1 个（多步流程每步 ≤1 个）；实底按钮底色至少 2 种（全是同一个实底色，等于没有分档）；卡片内衬只许两档（密卡 / 宽松卡），同层级卡片圆角与内衬必须同值。
|
||||
|
||||
### 2.3 落盘 `docs/pm/<项目>/DESIGN.md`
|
||||
|
||||
令牌表内容并入本项目既有的三层 token 结构：`primitive → semantic → component`。组件层只引语义层，语义层只引 primitive，无孤立 token。设计契约作首节。
|
||||
|
||||
`DESIGN.md` 是原型的绑定规范，原型只许引用它的 token。放项目目录、不放仓库根。
|
||||
|
||||
### 2.4 Gate-1 方向门（硬闸，任何挡位不可跳）
|
||||
|
||||
按 `SKILL.md` 的 Gate-1 自检表逐项自检，并把结果写在 `DESIGN.md` 末尾：
|
||||
|
||||
| # | 检查项 | 通过条件 |
|
||||
|---|---|---|
|
||||
| 1 | 设计契约 | 十二个字段全部填写，无一为空或「待定」；有重复项时「重复项的信息量」逐条列出次级信息；交互清单四列齐全，且表外的可点元素为 0 |
|
||||
| 1b | 页型判定（本项目附加，2026-10-05 新增） | 已写出「营销页 / 工具型页面 ＋ 依据」；工具型页面的 D0 里零 `.eyebrow` / 零 `.lead` / 零 `.hero` |
|
||||
| 2 | 结构骨架（翻译面，2026-10-06 口径调整） | 骨架档 / 板块落位 / 密度目标三者已写；板块 ≥2 个且每个有文字标题；板块清单来自②段、逐条对得上、未新增；②段分档表的每条信息都有落位 |
|
||||
| 2b | 骨架未漂（本项目附加，2026-10-06 新增） | D0 的页面清单与每页板块与②段《界面布局》逐条对得上；本段未增删移动任何板块 |
|
||||
| 3 | 状态覆盖 | 六个状态逐项有结论（勾选，或「不适用 ＋ 理由」） |
|
||||
| 4 | 令牌表 | 色值 / 字体 / 间距两档且适用面已分开写 / 圆角 / 阴影全为具体值 |
|
||||
| 4b | 字阶定值表 | 七档每档一个 px 定值（不是区间）；相邻档差 ≥2px；每档只许一个定值 |
|
||||
| 4c | 高度层级 | 每层都有多层叠层值；同层级同值 |
|
||||
| 4d | 布局脚手架 | 骨架档已落到具体列宽；窄屏变化写具体 |
|
||||
| 5 | 组件规格 | 按钮三档 + 卡片两档 + 输入框 + 徽章均为具体值；同一父区块内主档 ≤1；实底底色 ≥2 种 |
|
||||
| 6 | 反 slop | 无紫→粉渐变、标题未用禁用字体、强调色已写明允许位置 |
|
||||
| 7 | 拒绝清单 | ≥3 条，且每条可判定 |
|
||||
| 8 | token 引用完整性（本项目附加） | 语义层只引 primitive、组件层只引语义层、无孤立 token |
|
||||
| 9 | 分档兑现（本项目附加，2026-10-06 口径调整） | ②段分档表每条信息的「主屏常驻 / 可点入」在实现里兑现（常驻零点击可见、可点入一次点击可达）；档位未被本段改动（要改回②段） |
|
||||
| 10 | 供给核对（本项目附加） | 三处供给已确认在位；选定套名与 `DESIGN.md` 记录一致；不一致时供给变更清单已获用户确认并写入修订记录 |
|
||||
|
||||
任一项不过 → 停在 3a 补齐，不进 3b。
|
||||
|
||||
> 对比度怎么算：静态按 CSS 变量叠加后的计算值不可靠，须在 D5 渲染阶段按真实像素复测（判据见 `craft/color.md`：正文 4.5:1 / 大字 3:1 / UI 组件 3:1）。
|
||||
> 不许拿 `npx @google/design.md lint` 当关卡（本机实测完全不可用：alpha ＋ clack 交互库，非 TTY 管道下静默且 exit 0，见 `SKILL.md`）。也不要因它无输出就认为通过。
|
||||
|
||||
---
|
||||
|
||||
## 3. 3b 原型（D2 构建）
|
||||
|
||||
### 3.1 读谁、照什么走
|
||||
|
||||
读 `open-design/design-templates/web-prototype/SKILL.md`，按它「先选定一个明确的美学方向（允许极端，但必须自洽）再写码」的路线构建。方向定死在 `DESIGN.md` 的令牌表里，不许边写边调样式（铁律 1）。
|
||||
|
||||
### 3.2 工作形态 vs 交付形态（本项目已知偏离，每次都要声明）
|
||||
|
||||
- `web-prototype` 的默认产出是单文件 HTML、自包含、双击可开。这也是交付形态，最终必须满足
|
||||
- 本项目的原型用 React + Babel 多文件开发（`index.html` ＋ 若干 `.jsx`），经 HTTP 服务预览（`file://` 下 Babel 取不到外部 `.jsx`，会静默失败）
|
||||
- 编排：开发期按多文件走 ＋ HTTP 预览，3b 收尾时内联成单文件交付
|
||||
- 无宿主工具可代劳，内联必须手工做：把 React / ReactDOM / Babel 用本仓本地副本内联（保离线），把每个 `<script type="text/babel" src="…">` 换成内联 `<script type="text/babel" data-presets="react">`，并去掉所有 unpkg CDN 引用。这是一处持续偏离，每次都要声明。
|
||||
|
||||
内联后必须自检三条：无 `unpkg` 残留、无 `src="v2/`（外部 jsx 引用）残留、根部挂载点仍在。任一不满足即构建失败。
|
||||
|
||||
### 3.3 输出红线（命中即返工）
|
||||
|
||||
来源：数值判据取 `craft/`（`typography.md` ＋ `color.md` ＋ `accessibility-baseline.md`），反 AI 味取 `craft/anti-ai-slop.md`，版式自查取 `web-prototype/references/checklist.md`。下列判据不在 craft 里重复抄写，只写本项目追加的那几条。
|
||||
|
||||
- 间距只用令牌表登记的刻度值；确需中间值（如紧凑表格行高）在令牌表登记，不许临时拍。刻度外值混用是「廉价感」的主要来源（判据见 `craft/typography.md`）
|
||||
- 数字列用 `font-variant-numeric: tabular-nums`（否则刷新时宽度跳动，表格跟着抖）
|
||||
- 禁单层死黑重阴影，用多层叠层 ＋ 1px 半透明边框。层级按内容需要，不设人为上限；判的是「同层级是否同值」，不是「层级总数是否超标」
|
||||
- 强调色全屏面积 ≤5%（判据见 `craft/color.md`）；状态色只用红绿黄三系，不做装饰
|
||||
- 标题禁用 Inter / Roboto / Arial / `system-ui`（正文可用）；中文字重别超 600（`craft/typography.md`）
|
||||
- ⭐ 结构四条（本项目追加，craft 无对应）：① 区块 ≥2 个且每个有文字标题（图标 / 徽章 / 分组容器不替代标题），标题不跳级；② 实际在用字号档 ≥3 档且相邻档差 ≥2px，正文档落在 14–16；③ 块间距 ≥ 块内间距的 2 倍；④ 按钮有主次分档且同屏主档 ≤1（多步流程每步 ≤1），分档靠填充色 ＋ 高度
|
||||
- 反 AI 味逐条过 → `craft/anti-ai-slop.md`。⚠️ 「卡片墙」判的是「同一圆角 ＋ 同一阴影 ＋ 所有模块视觉权重完全相同」的等权卡片墙，不是「用了卡片」。有主次、有分组、层级不同的卡片是合法结构手段，别把卡片当禁区整片封掉
|
||||
- 状态穷举六项 → `craft/state-coverage.md`（loading / empty / error / success / disabled / 无权限，逐项判据在那份）
|
||||
- 布局 Grid 管栅格、Flex 管行内对齐；移动优先，断点 `<640` / `640–1024` / `>1024`
|
||||
- 防溢出三件套：grid 写 `minmax(0,1fr)`（不是 `1fr`）、flex 子项加 `min-width:0`、表格 / 代码块外层 `overflow-x:auto`
|
||||
- 交互态齐全：`hover` / `active` / `focus-visible` 三态都要写，焦点环不许被 `outline:none` 抹掉（`craft/accessibility-baseline.md`）
|
||||
- 规范 HTML：非空元素显式闭合、属性双引号
|
||||
- 文件名要有描述性；集中放 `designs/<项目>/`，不散落仓库根
|
||||
|
||||
### 3.4 本项目附加纪律（`open-design` 未涉及）
|
||||
|
||||
- 重大改版必须复制副本再改（`X.html` → `X v2.html`），不许覆盖旧版。旧版留在磁盘上以便对比（版本管理主线需要可追溯）
|
||||
- 原型里的状态由路由 ＋ 演示开关驱动，不是 `?state=` URL 参数；实测时按这个来
|
||||
|
||||
### 3.5 实测硬关卡（未过不得进 3c）
|
||||
|
||||
用 `browser-harness` skill，以 D0 契约的「交互清单」为唯一清单逐个真点：每行按「触发 → 反馈」实跑；空 / 加载 / 错误 / 失败重试四态都要走到；回报控制台报错原文与「点了没反应」的元素清单。
|
||||
|
||||
- ⛔ 本步是唯一的可点通过道。不许因「没有自动机检」就跳过或降级；实测不过就不许进 3c
|
||||
- 实测一律走 `browser-harness`（浏览器入口 9333），禁用 Trae 自带浏览器工具
|
||||
- React 受控输入用 `fill_input(selector, text)` 填，不要用 `type_text()`（后者绕过框架监听器，提交按钮会一直是禁用态）
|
||||
- 测前禁缓存（`Network.setCacheDisabled`），否则会读旧 `.jsx`
|
||||
- 顺序也是关卡：3a 未过 Gate-1 不进 3b；未跑实测不得进 3c
|
||||
|
||||
---
|
||||
|
||||
## 4. 3c GPT 会诊（必做，顺序在 3d 之前）
|
||||
|
||||
触发点：3b 原型初稿和实测都过了，立刻做。步骤、提问模板、四列处置表、输入边界、异常情况见 `SKILL.md` §3c，不在此重复。
|
||||
|
||||
为什么必须有这一步：3a / 3b 全是本地确定性检查，没有外部视角，这一步补的正是它补不了的那块。
|
||||
|
||||
三道不可松的口子：① 用附件上传原型 HTML，不许把上万字符代码粘进输入框；② 等回答出完再取原文，不许读一半；③ 上传前脱敏（密钥、真实数据、内网地址换占位符）。
|
||||
|
||||
取不到时：不许假装跑过。落盘写明「本轮未取得外部审查」，并在段末明示 —— 未取得不等于已通过。
|
||||
|
||||
处置：采纳要给理由，与 `DESIGN.md` 或②段冲突的写清为什么不采纳。采纳项在 3d 之前改完，并回到 3b 的实测清单把这些改动再点一遍。
|
||||
|
||||
---
|
||||
|
||||
## 5. 3d 审查与打磨（D3 收口 + D4 动效 + D5 终检 + Gate-2/3）
|
||||
|
||||
### 5.1 D3 收口（管"写得对不对"）
|
||||
|
||||
对照 `open-design/design-templates/web-prototype/references/checklist.md` + `craft/typography.md` / `typography-hierarchy.md` / `color.md` / `accessibility-baseline.md` 逐条过。
|
||||
|
||||
> 🔴 本步一律人工过（2026-10-02 用户定案：不重要的相关内容一律删，不建替代脚本）。判据有三处来源，不许跳过任一处：
|
||||
> ① `SKILL.md` 的 Gate-1 自检表 ｜ ② `craft/` 四份规约 ｜ ③ 下列本项目追加判据。
|
||||
|
||||
本项目追加判据（craft 无对应，必须留在这里）：
|
||||
|
||||
- 结构四条：① 区块 ≥2 个且每个有文字标题，标题不跳级 ｜ ② 实际在用字号档 ≥3 档、相邻档差 ≥2px、正文档落在 14–16 ｜ ③ 块间距 ≥ 块内间距的 2 倍 ｜ ④ 按钮有主次分档且同屏主档 ≤1
|
||||
- ⭐ 工具型页面五条（本项目追加，2026-10-05）：标题区零从属小字 ｜ 导航带标签 ｜ 并列卡有主次 ｜ 分组不靠边框 ｜ 无假控件。逐条判据与机械核对法在 `references/layouts-tooling.md` §5.5，不在此重复展开
|
||||
⚠️ 其中「标题区零从属小字」与 `web-prototype/references/checklist.md` 的 `P0-A` 是同一判据的两处落点：checklist 管「怎么写」，本节管「怎么量」，口径一致，判据正文只在 `layouts-tooling.md` §5.5.1
|
||||
- 间距只用令牌表登记的刻度值，确需中间值先登记
|
||||
- 数字列用 `font-variant-numeric: tabular-nums`（否则刷新时宽度跳动）
|
||||
- 禁单层死黑重阴影，用多层叠层；层级按内容需要，判的是「同层级是否同值」，不是「层级总数超标」
|
||||
- 防溢出三件套：grid 写 `minmax(0,1fr)`、flex 子项加 `min-width:0`、表格 / 代码块外层 `overflow-x:auto`
|
||||
- 交互态齐全：`hover` / `active` / `focus-visible` 三态都写，焦点环不许被 `outline:none` 抹掉
|
||||
|
||||
> ⚠️ 判据以「内联后的交付单文件」为准。扫多文件开发目录会出幻影阻断（片段文件里当然找不到 CSS 里才有的规则）。本地曾实测整目录扫出 9 条幻影阻断。
|
||||
|
||||
### 5.2 D4 动效（可跳过）
|
||||
|
||||
按 `craft/animation-discipline.md` 先答动效三问：① 它传达什么信息？② 删掉会丢失什么？③ 是不是为了「看起来高级」？答不出就不加。
|
||||
|
||||
- 工具型页面（仪表盘 / 后台 / 编辑器 / 工作台）禁止入场编排：用户一天开几十次，每次播一遍是折磨。本项目的版本管理界面属工具型；判不准时按工具型处理
|
||||
- 弹簧用 Damping / Response 二参数（Damping 保持 0.8–1.0、Response 0.3–0.4s；低于 0.7 会明显「蹦」）
|
||||
- CSS 无法用真弹簧时用 `cubic-bezier(0.32, 0.72, 0, 1)`；过渡曲线不得用 `linear` / `ease` / `ease-in-out`
|
||||
- 交互过渡禁 `@keyframes animation`（不可中断，反向操作会跳帧），用 `transition` 或 WAAPI
|
||||
- 只动 `transform` / `opacity`，不动 `width` / `height` / `top` / `left`；禁止 `scale(0)` 起手（用 `scale(0.95)` ＋ opacity）
|
||||
- 退出比进入快（进 300ms / 出 200ms）；同屏动效元素 ≤3 个且有 30–50ms 错峰
|
||||
- `prefers-reduced-motion` 必须处理
|
||||
|
||||
### 5.3 D5 终检（管"能不能交"）
|
||||
|
||||
过 `craft/state-coverage.md`（状态穷举）＋ `craft/anti-ai-slop.md`（反 AI 味）＋ `web-prototype/references/checklist.md`（P0/P1）＋ 动效三问 ＋ 交互清单逐行复测，并真渲染一次。
|
||||
|
||||
> 🔴 渲染复测用本机 Chrome 无头截图（2026-10-02 实测可用）：
|
||||
>
|
||||
> ```bash
|
||||
> "/c/Program Files/Google/Chrome/Application/chrome.exe" --headless=new --no-sandbox --disable-gpu \
|
||||
> --hide-scrollbars --window-size=1440,900 --virtual-time-budget=3000 \
|
||||
> --screenshot="<Windows 绝对路径>/P1.png" \
|
||||
> "file:///<原型绝对路径，中文需 URL 编码>#/p/xxx"
|
||||
> ```
|
||||
> ⚠️ 两条坑：`--screenshot` 必须给 Windows 绝对路径（给相对路径会写进 Chrome 安装目录，回来找不到）；中文文件名要 URL 编码。
|
||||
> ⛔ 脚本缺失期间，截图只替代「看得见的」那部分：溢出与响应式破损能看出来，对比度 / 状态可见性 / 点击目标尺寸 / 死按钮判不了，那些仍按 5.1 的人工判据 ＋ 3b 的 `browser-harness` 实测走。
|
||||
> 截图两种形状，用途不许混：
|
||||
>
|
||||
> | 形状 | 尺寸 | 用途 |
|
||||
> |---|---|---|
|
||||
> | 视口帧 | 1440×900 / 390×844 | 对外评审、提交外部评估、交付留档一律用这张 |
|
||||
> | 整页长图 | 视口宽 × 整页高 | 仅自检「整页有没有塌」，不对外 |
|
||||
>
|
||||
> ⚠️ 混用会出事（本项目实测踩过）：把长图当参考图交出去，移动端是 1:7.1 的长条、桌面端 1440×1429，「首屏」这个信息整个丢失。外部评估只能按长条理解布局，「首屏有没有主次」「坐得下几行」根本没被评审到。
|
||||
>
|
||||
> 两个视口都要截（`1440x900` 与 `390x844`），只截桌面端等于没测响应式。
|
||||
>
|
||||
> 结构与排版仍要量（脚本缺失期间靠 DOM 取值人工量）：字号档数与相邻档差 / 正文档承载占比 / 标题大纲 / 按钮高度与实底分档 / 列对齐 / 对齐锚点 / 浮层可见关闭出口唯一。⛔ 不许目测截图下结论，取值结果直接抄进 `3d-审查报告.md` 的结构核对表。
|
||||
>
|
||||
> 本项目是 hash 驱动路由，hash 接在文件名后（`<原型>.html#/p/xxx`）；不接就渲染到空壳视图，截图与数字全是假的。
|
||||
>
|
||||
> 「无法判定」一律按未通过对待（「判不了」≠「没问题」）：浮层类在未打开态必然判不了，必须按 Gate-3 的打开态复测口径，用 `browser-harness`（复用同一页签）逐个打开浮层再数可见关闭出口，与 `Esc` / 点遮罩 / 焦点锁三条一起留痕。
|
||||
|
||||
契约里写了数字的，逐条取值回填（`05` §二 第 11 项，阻断级）
|
||||
|
||||
脚本不认识项目自定义选择器（`.ver-row` 之类），所以契约里的数字 —— 首屏条数、单条行高、承载占比、面积占比、对比度比值 —— 没有任何一道机检会替你核。它们是全篇最像「已经验过」的一类内容。
|
||||
|
||||
- 用 `browser-harness` 或 DOM 取值，按契约声明的视口量（本项目是 `1440×900` 与 `390×844`）；`browser-harness` 必须复用同一个页签（`list_tabs()` → `switch_tab()` → `goto_url()`，不要 `new_tab()`）
|
||||
- 回填的是实测值，不是复述契约值；把「契约值 / 实测值」并排列进 `3d-审查报告.md` 的结构核对表
|
||||
- 不得目测，不得沿用上一版数字
|
||||
- 契约没声明判据的档位（例如本项目窄屏的行高）如实记为证据缺口，不要临时编一个阈值凑上
|
||||
- 反面案例（`DESIGN` §8.10 E-18）：某轮契约写「单个版本行高 ≤96px / 1440×900 首屏 ≥5 行」，是凭印象写的，真渲染才发现是 118px / 3 行，两个数字同时不达标，而当时没有任何门禁会报它
|
||||
|
||||
### 5.4 Gate-2 完成门
|
||||
|
||||
全部 `阻断` 项清零，`建议` 项逐条有结论：修掉，或显式写「已知不修 ＋ 原因」。
|
||||
不接受「基本没问题」「应该差不多」「剩余都是小问题」。每条要么修，要么留痕。
|
||||
|
||||
### 5.5 Gate-3 交付门（硬闸，任何挡位不可跳）
|
||||
|
||||
真实渲染后（浏览器打开，非只看代码）肉眼过八项：裁切 / 重叠 / 失真 / 失效控件 / 缺状态 / 响应式破损 / 控制台报错 / 字体回退异常。
|
||||
无头截图已代劳其中的溢出与响应式破损，其余仍需人眼（截图查不出「点了没反应」，那靠 3b 的 `browser-harness` 实测）。
|
||||
|
||||
落盘 `designs/<项目>/3d-审查报告.md`，按 `05` §五的模板：范围 ＋ 挡位 ＋ 阻断项表 ＋ 建议项表 ＋ 状态覆盖核对表 ＋ Gate 结论。
|
||||
|
||||
---
|
||||
|
||||
## 6. 偏离单（本段收尾必须附）
|
||||
|
||||
| # | 原要求（文件:小节） | 实际做法 | 原因 | 影响 | 处置 |
|
||||
|---|---|---|---|---|---|
|
||||
| | | | | | 已修 / 持续偏离 / 待用户裁定 |
|
||||
|
||||
本项目长期挂账的偏离（每次执行都要重新声明状态）：
|
||||
|
||||
| # | 项 | 状态 |
|
||||
|---|---|---|
|
||||
| A1 | `web-prototype` 默认产出单文件 HTML；本项目开发期用 React+Babel 多文件，交付时手工内联成单文件（无宿主工具可代劳：`super_inline_html` / `present_fs_item_for_download` 在 Trae 都不存在） | 持续偏离，3b 收尾做内联并自检三条 |
|
||||
| A2 | 宿主下载 / 预览工具不存在（`SendUserFile` / Claude Preview MCP） | 按 `SKILL.md` 适配注记：改 Write 落盘 ＋ `browser-harness` 实测 |
|
||||
| A3 | 实测必须用 `browser-harness`（浏览器入口 9333），禁用 Trae 自带浏览器工具 | 项目既定约束，优先级高于手册的通用说法 |
|
||||
| A4 | 预览服务端口用 4311（`python -m http.server 4311 --directory designs`） | 与 9333 不冲突：4311 是服务，9333 是自动化浏览器入口 |
|
||||
|
||||
没有偏离单就不得报完成。
|
||||
|
||||
---
|
||||
|
||||
## 7. 完成标准（逐条可核对）
|
||||
|
||||
- [ ] 声明制走完：开工、每个子步、每处偏离都有声明；挡位已声明（快速 / 标准 / 严格）
|
||||
- [ ] 第 1 节必读表已按阶段取用；同一时刻只读 1~2 份，未一次性全读（限载）
|
||||
- [ ] 供给核对做过：三处供给在位、选定套名与 `DESIGN.md` 记录一致；不一致时供给变更清单已获用户确认并写入修订记录
|
||||
- [ ] `docs/pm/<项目>/DESIGN.md` 存在，含设计契约（十二个字段，含结构骨架、交互清单与重复项的信息量）与令牌表（三层 token 结构，含组件规格 ＋ 字阶定值表 ＋ 高度层级 ＋ 布局脚手架（含容器与对齐锚点）＋ 浮层只许一个可见关闭出口，全为具体值）
|
||||
- [ ] 骨架未漂（2026-10-06 口径调整）：D0 的页面清单与每页板块与②段《界面布局》逐条对得上；本段未增删移动任何板块
|
||||
- [ ] 分档已兑现：②段分档表每条信息的「主屏常驻 / 可点入」在实现里兑现；档位未被本段改动
|
||||
- [ ] `结构骨架` 已落：骨架档给了理由；板块 ≥2 个且每个有文字标题；板块清单来自②段；密度目标只取一档
|
||||
- [ ] 页型已判（营销页 / 工具型，给了依据）；工具型页面零 `.eyebrow` / 零 `.lead` / 零 `.hero`，且 `layouts-tooling.md` §5.5 五条逐条过完（含「标题区零从属小字」的 DOM 取值）
|
||||
- [ ] Gate-1 全部自检项结果写在 `DESIGN.md` 末尾，无一项不过
|
||||
- [ ] 原型 HTML 单文件自包含、双击可开，内联自检三条通过（无 unpkg / 无外部 jsx 引用 / 挂载点在）
|
||||
- [ ] 状态穷举六项逐条有结论（`05` §三第 1 项）
|
||||
- [ ] 每个按钮、每个跳转都用 `browser-harness` 真点过，含空 / 加载 / 错误 / 失败重试四态，并回报控制台报错原文与「点了没反应」清单
|
||||
- [ ] `designs/<项目>/3c-GPT会诊.md` 存在，含提问原文、模型回答原文、四列处置表；未取到已明示
|
||||
- [ ] D3 收口已按 5.1 三处判据人工过完：Gate-1 自检表 ＋ `craft/` 四份规约 ＋ 本项目追加判据，阻断项清零（取值结果已抄进报告）
|
||||
- [ ] D5 终检已真渲染：`1440x900` 与 `390x844` 两个视口各截一张，视口帧已留档；横向溢出 0 / 对比度不达标 0 / 结构与排版阻断 0，且无「无法判定」项（DOM 取值已抄进报告）
|
||||
- [ ] 每个浮层都手工打开数过可见关闭出口（`== 1`）＋ `Esc` / 点遮罩能关、焦点锁在层内且关闭后回到触发按钮；结论与触发路径已写进 `3d-审查报告.md`
|
||||
- [ ] 对外提交 / 交付留档的截图只用视口帧；`_full/` 长图未作为评审输入
|
||||
- [ ] 契约里每个写出来的数字都已实测回填（首屏条数 / 行高 / 承载占比 / 面积占比 / 对比度比值），「契约值 / 实测值」并排列出；未回填即阻断；契约未声明判据的档位已记为证据缺口
|
||||
- [ ] `designs/<项目>/3d-审查报告.md` 存在，含阻断 / 建议两张表 ＋ 状态覆盖核对 ＋ 结构核对（数字抄自脚本输出，非「目测」）＋ Gate-2/3 结论
|
||||
- [ ] Gate-2 与 Gate-3 均已通过（书面结论，非口头）
|
||||
- [ ] 重大改版：旧版文件仍在磁盘上，且收尾给出新旧差异（改了什么 / 为什么 / 代价）
|
||||
- [ ] 偏离单已附，且无静默偏离
|
||||
+329
@@ -0,0 +1,329 @@
|
||||
# 工具型版式库（工具型数据密集界面 · 本项目追加）
|
||||
|
||||
> ⛔ 本文件是 `stage-delivery` 自己的东西。`open-design/design-templates/web-prototype/references/layouts.md`
|
||||
> 的 8 个骨架是落地页 / 营销页向（hero / features / stats / quote / cta / log / pricing），
|
||||
> 工具型页面只适用其中 Layout 7 日志列表与 Layout 8 对比表。
|
||||
> 其余套上去会把后台做成营销页 —— 这是「版式与判据同源」的必然结果，不是审美问题。
|
||||
>
|
||||
> `craft/` 是通用工艺，不给版式；8 骨架不给工具型。
|
||||
> 工具型页面的版式在本项目只有这一份来源，它是③段「正向目标」的最后一块空缺。
|
||||
|
||||
---
|
||||
|
||||
## 0. 何时用哪一类（先判形态，再挑骨架）
|
||||
|
||||
| 形态 | 判据（一句话能判） | 骨架 |
|
||||
|---|---|---|
|
||||
| 列表型 | 主操作是"选中一行去看/改"，页面上有 ≥2 条同类记录并列 | §1 行式列表 / §2 表格式清单 |
|
||||
| 详情型 | 主操作是"改这一项的字段"，页面围绕**单个对象**展开 | §3 详情面板 |
|
||||
| 侧区型 | 主操作是"在两个工作面之间来回"（如列表↔详情、主区↔检查器） | §4 主从侧区 |
|
||||
|
||||
⭐ 判不出来怎么办：页面上能数出"并列的同类记录"就是列表型；数不出就是详情型。
|
||||
⛔ 不许拿落地页骨架顶替 —— 那是"没有形态判定"的默认行为，等于退回 18 轮前的病根。
|
||||
|
||||
---
|
||||
|
||||
## 1. 行式列表（工具型主形态 · 默认首选）
|
||||
|
||||
适用：主操作作用于"一条记录"，记录有主标识 + 状态 + 少量次级信息。
|
||||
结构：`容器 → 表头行（列名 / 排序标记 / 计数）→ 数据行 × N → 选中态`
|
||||
|
||||
```html
|
||||
<section class="section" data-od-id="registry">
|
||||
<div class="container">
|
||||
<div class="row-between" style="margin-bottom: 16px;">
|
||||
<h2>原型版本登记</h2>
|
||||
<span class="meta">共 12 条 · 按更新时间倒序</span>
|
||||
</div>
|
||||
<div class="rule" style="margin-bottom: 0;"></div>
|
||||
|
||||
<article class="log-row">
|
||||
<span class="meta">v12</span>
|
||||
<div>
|
||||
<h3>原型版本管理 v12</h3>
|
||||
<p style="margin: 4px 0 0; color: var(--muted); font-size: 14px;">
|
||||
新增 3d 审查报告落盘位 · 交互清单已接进D0 契约
|
||||
</p>
|
||||
</div>
|
||||
<span class="tag">已登记</span>
|
||||
</article>
|
||||
|
||||
<article class="log-row">
|
||||
<span class="meta">v11</span>
|
||||
<div>
|
||||
<h3>原型版本管理 v11</h3>
|
||||
<p style="margin: 4px 0 0; color: var(--muted); font-size: 14px;">
|
||||
状态机改由 gates/ 推导，界面重构 0 项机制受影响
|
||||
</p>
|
||||
</div>
|
||||
<span class="tag">已归档</span>
|
||||
</article>
|
||||
|
||||
<article class="log-row">
|
||||
<span class="meta">v10</span>
|
||||
<div>
|
||||
<h3>原型版本管理 v10</h3>
|
||||
<p style="margin: 4px 0 0; color: var(--muted); font-size: 14px;">
|
||||
D3/D5 人工判定，未跑 ≠ 通过
|
||||
</p>
|
||||
</div>
|
||||
<span class="tag">待复核</span>
|
||||
</article>
|
||||
|
||||
<div class="row" style="margin-top: 24px; gap: 8px;">
|
||||
<button class="btn btn-primary">登记新版本</button>
|
||||
<button class="btn btn-ghost">导出登记台账</button>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
```
|
||||
|
||||
判定要点（可机械核对，不是审美建议）：
|
||||
|
||||
- 边框只上不围 —— 行间用 `border-top`，⛔ 不给每行套框。套框会让列表变宣传册。
|
||||
- 一屏可见行数 ≥ 6（900px 高时）。低于 6 说明行高或内衬过肥 ⇒ 工具型页面一屏放不下东西。
|
||||
- 每行必须带主标识（`v12` 这类短标或标题），⛔ 不许整行只有一句描述。
|
||||
- 状态用 `tag` 不用整行底色。整行着色 ⇒ 该行不再是"可读的记录"而是"一条告警"。
|
||||
|
||||
---
|
||||
|
||||
## 2. 表格式清单（同形态的高密度变体）
|
||||
|
||||
适用：记录字段多且需要横向比较（≥4 个可比字段）。
|
||||
⚠️ 与 §1 的取舍：字段 ≤3 用行式；≥4 且用户任务是"比较"才用表格式。⛔ 不许因为"表格看起来更整齐"就用它。
|
||||
|
||||
```html
|
||||
<section class="section" data-od-id="gates">
|
||||
<div class="container">
|
||||
<div class="row-between" style="margin-bottom: 16px;">
|
||||
<h2>闸门检查</h2>
|
||||
<span class="meta">4 项 · 2 项未跑脚本</span>
|
||||
</div>
|
||||
<table class="ds-table">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>闸门</th><th>判据来源</th><th>形态</th><th class="num-col">结论</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>Gate-1 方向门</td><td>runbook §2.1（十二字段）</td><td>全部页面</td><td class="num-col">人工</td></tr>
|
||||
<tr><td>D3 收口</td><td>craft/typography + color</td><td>全部页面</td><td class="num-col">人工</td></tr>
|
||||
<tr><td>D5 终检</td><td>checklist + anti-ai-slop</td><td>两视口</td><td class="num-col">人工</td></tr>
|
||||
<tr><td>命名一致性</td><td>check_naming.py</td><td>技能树</td><td class="num-col">通过 90/0</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</section>
|
||||
```
|
||||
|
||||
判定要点：
|
||||
|
||||
- 数字列右对齐 + `num` 类（`class="num-col"`）。左对齐的数字列没法比大小。
|
||||
- 表头必须写判据来源，⛔ 不许只写结论。工具型页面的每个结论都要能追到出处。
|
||||
- 「未跑」必须能作为一个取值存在（`人工` / `未跑`），⛔ 不许用"已通过"顶替 —— 那是本项目最反复踩的错。
|
||||
|
||||
---
|
||||
|
||||
## 3. 详情面板（单对象表单型）
|
||||
|
||||
适用：主操作是"改这一项"，页面围绕单个对象。
|
||||
结构：`对象标识 → 字段组（每组有标题）→ 动作区`
|
||||
|
||||
```html
|
||||
<section class="section" data-od-id="detail">
|
||||
<div class="container">
|
||||
<div class="row-between" style="margin-bottom: 24px;">
|
||||
<h2>v12 · 原型版本管理</h2>
|
||||
<span class="pill">草稿</span>
|
||||
</div>
|
||||
|
||||
<div class="grid-2" style="gap: 32px;">
|
||||
<div>
|
||||
<h3 class="meta">标识</h3>
|
||||
<div class="card-rule" style="padding: 16px 0;">
|
||||
<p class="meta">版本号</p>
|
||||
<p class="num" style="margin: 4px 0 0; font-size: 20px;">v12</p>
|
||||
</div>
|
||||
<div class="card-rule" style="padding: 16px 0;">
|
||||
<p class="meta">登记时间</p>
|
||||
<p style="margin: 4px 0 0;">2026-10-02 19:24</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
<h3 class="meta">变更摘要</h3>
|
||||
<div class="card" style="padding: 16px;">
|
||||
<label class="meta" for="d-sum">本版改了什么（读者只靠这段判断要不要回滚）</label>
|
||||
<textarea id="d-sum" class="textarea" rows="4"
|
||||
style="margin-top: 8px; width: 100%;">交互清单接进 D0 契约；必读源改指 open-design。</textarea>
|
||||
</div>
|
||||
<div class="row" style="margin-top: 16px; gap: 8px;">
|
||||
<button class="btn btn-primary">保存</button>
|
||||
<button class="btn btn-ghost btn-arrow">回滚到 v11</button>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
```
|
||||
|
||||
判定要点：
|
||||
|
||||
- 字段必须有可见标签（`label` 或 `meta`），⛔ 不许只靠 placeholder 承载字段名 —— 一保存就看不见了。
|
||||
- 可编辑与只读要分层（`card` 可编辑 / `card-rule` 只读），⛔ 不许全部做成输入框。
|
||||
- 动作区位置固定在对象标识之后、内容之后，⛔ 不许散落在各字段组里。
|
||||
|
||||
---
|
||||
|
||||
## 4. 主从侧区（两工作面来回）
|
||||
|
||||
适用：主操作需要在两个面之间来回（列表 ↔ 详情、主区 ↔ 检查器）。
|
||||
结构：`左区（列表，可收窄）｜ 右区（详情或检查器，主体）`
|
||||
|
||||
```html
|
||||
<section class="section" data-od-id="master-detail">
|
||||
<div class="container">
|
||||
<div class="row-between" style="margin-bottom: 16px;">
|
||||
<h2>交互清单</h2>
|
||||
<span class="meta">第 7 字段 · 四列</span>
|
||||
</div>
|
||||
<div class="grid-1-2" style="gap: 0; align-items: start;">
|
||||
|
||||
<nav class="stack" style="gap: 4px;">
|
||||
<div class="card-flat" style="padding: 10px 12px;">
|
||||
<p class="meta">元素</p>
|
||||
<p style="margin: 2px 0 0;">登记新版本按钮</p>
|
||||
</div>
|
||||
<div class="card-flat" style="padding: 10px 12px; border-left: 3px solid var(--accent);">
|
||||
<p class="meta">元素 · 当前</p>
|
||||
<p style="margin: 2px 0 0;">导出登记台账</p>
|
||||
</div>
|
||||
<div class="card-flat" style="padding: 10px 12px;">
|
||||
<p class="meta">元素</p>
|
||||
<p style="margin: 2px 0 0;">闸门结论标记</p>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<div style="padding-left: 24px;">
|
||||
<h3 class="meta">触发 / 反馈 / 何时不可点</h3>
|
||||
<table class="ds-table" style="margin-top: 8px;">
|
||||
<tbody>
|
||||
<tr><td class="meta">触发</td><td>点击</td></tr>
|
||||
<tr><td class="meta">反馈</td><td>写入 registry/ 并输出回执行</td></tr>
|
||||
<tr><td class="meta">不可点</td><td>gates/ 未就位时</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
```
|
||||
|
||||
判定要点：
|
||||
|
||||
- 左区可收窄但不可隐藏（`min-width` 保底）—— ⛔ 不许做成抽屉或浮层，工具型页面要能同时看到两面的对应关系。
|
||||
- 当前项用 `border-left` 指示（3px 实底），⛔ 不用底色铺满。
|
||||
⭐ 这是「状态修饰不参与分族」的正面用法：`border-left` 属状态修饰，`card-flat` 才是分族键 —— 两者不能混进同一个分组键。
|
||||
- 右区必须与左区当前项对应，⛔ 不许左区选中变了右区不动。
|
||||
|
||||
---
|
||||
|
||||
## 5. 通用红线（工具型专属 · 五条 = 本项目判据正文）
|
||||
|
||||
> 本节是③段工具型判据的唯一定稿处。`open-design/design-templates/web-prototype/references/tooling.md`
|
||||
> 的「通用红线」只是纲要指路（它管所有工具型页面的形态判定），逐条判据与实测反例以本节为准。
|
||||
> ⛔ 两边不重复展开 —— 同一判据两处展开必然漂。
|
||||
|
||||
- ⛔ 不做入场编排。工具型页面一进来就该是可读的工作面，不用 `linear` / `ease` 做元素入场。详见 `craft/animation-discipline.md`。
|
||||
- ⛔ 不为"好看"加装饰区块。判据用 D0 的 `必要内容`：删掉它，主操作还做得成吗 —— 答得出"做得成" ⇒ 不上屏。
|
||||
- ⛔ 不把落地页当默认骨架。挑骨架前必须先过 §0 的形态判定；判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。
|
||||
- ⛔ 标题区零从属小字（详见 §5.5.1）。
|
||||
- ⛔ 不可点的东西不许长成可点样子（详见 §5.5.5）。
|
||||
|
||||
---
|
||||
|
||||
## 5.5 五条反「实习生审美」硬判据（2026-10-05 追加 · 有行业实证）
|
||||
|
||||
> 来源与依据：Linear UI 重设计复盘（Karri Saarinen 等，2024）+ B2B 认知负荷／admin dashboard 法则（AdminLTE 2026 / Open Door Digital / CreateBytes 等）。
|
||||
> 为什么单列一节：§1–§4 管"结构对不对"，管不住"像不像给人用的"。2026-10-05 用户实测指出当前原型「像实习生画的」，逐条对上后确认下面五条从来没有判据。这五条都是可机械核对的，不是审美建议。
|
||||
|
||||
### 5.5.1 标题区不许挂从属说明文字（治法：「标题归标题，说明归别处」）
|
||||
|
||||
实证：「Microcopy is part of hierarchy …… **Add concise helper text only where it prevents mistakes**」；「**Strong section headers: users should understand a section without reading every line**」。
|
||||
|
||||
判据：页面标题 / 区块标题（`h1` / `h2` / `h3`）正下方 8px 内不得出现纯说明性文字。
|
||||
- ⛔ 反例（实测踩过）：「全部项目」下面吊「每个项目独立管理版本与产物」；「版本列表」下面吊「按版本号倒序 · 点行进入详情」；「v12」下面吊「3/5 · 进行中」。
|
||||
- ✅ 正解三选一：① 删掉（能自明就删）；② 移到该区块内的控件行（如排序控件旁）；③ 改写成数据本身（如把「按版本号倒序」变成表头的排序指示器）。
|
||||
- ⚠️ 例外仅一个：空态 / 错误态的解释文字（那是页面主内容，不是标题的注脚）。
|
||||
|
||||
> 🔴 怎么区分「注脚」与「事实」（2026-10-05 机检踩过，必须写死）：不看位置，看内容与去向。
|
||||
>
|
||||
> | | 注脚（判不过） | 事实（放行） |
|
||||
> |---|---|---|
|
||||
> | 内容 | 解释标题本身（"这是什么意思""怎么用"） | 该对象的可决策数据（版本数 / 最近动作 / 状态） |
|
||||
> | 去向 | 删掉后页面无损失，只是少一句解释 | 删掉后用户不知道点哪个（改了主操作的落点） |
|
||||
> | 判据 | 用 D0 `必要内容`：「删掉它，主操作还做得成吗」——答"做得成" ⇒ 是注脚 | 答"做不成/会选错" ⇒ 是事实 |
|
||||
>
|
||||
> ⚠️ 机检量法的适用范围：机械扫描「标题正下方 N px 内的文本节点」会把事实条一并抓出来（v3 原型实测：`h3 CutGate` 下方 14px 处是 `7 个版本`）。
|
||||
> ⛔ 这不能一律判红 —— 得逐条回答上表两问。放行的事实条必须同时满足：① 是数据不是句子；② 与该对象的主操作按钮同属一个视觉单元（同行或紧邻），而不是独占了标题的第二行。
|
||||
> ✅ 若事实条独占标题下方一整行（如本原型首版），仍判不过 ⇒ 把它挪到与主操作同行。
|
||||
|
||||
### 5.5.2 导航栏不许只有图标（治法：「默认带标签，折叠才收」）
|
||||
|
||||
实证：「sidebar becomes **a wall** and needs grouping or a different model」（>15 项时）；「**Collapsible Sidebars** …… shrinks to just 64px, **hiding the text labels and showing only the icons**」—— 只图标是折叠态，不是默认态。
|
||||
|
||||
判据：
|
||||
- 主导航默认必须带文字标签（宽 ~240–280px），⛔ 不许一上手就是 52px 纯图标栏。
|
||||
- 图标数量 < 4 个时，⛔ 不许用竖向图标栏 —— 三个图标撑一条 52px 竖栏，剩下全是空白，是"没内容硬做壳"。
|
||||
✅ 正解：< 4 项改用页头横向导航或面包屑 + 返回，把宽度还给内容。
|
||||
- 允许 64px 纯图标，仅当它有一个明确的可展开入口（折叠按钮），且默认是展开态。
|
||||
|
||||
### 5.5.3 并列卡片必须有主次（治法：「一屏一个最大」）
|
||||
|
||||
实证：「**A screen with twenty equal widgets is a screen with none**」；「Twelve equal-weight widgets answer no question. Decide the single number or status the screen exists for, **give it the top-left slot and the largest type**, and demote the rest」；「**Pass the five-second test** —— 读不到主要结论，问题在层级不在数据」。
|
||||
|
||||
判据：
|
||||
- 同屏并列 ≥3 张卡片时，必须有且仅有一张是"主卡"：位置在左上、字号明显更大（≥ 相邻卡 1.3×）或占宽更大（≥ 1.5×）。
|
||||
- ⛔ 反例（实测踩过）：CutGate / Cutter / Truss 三张等宽等高卡，视觉重量完全相同 ⇒ 五秒测试必挂。
|
||||
- 机械核对法：把所有并列卡片的 `getBoundingClientRect()` 取出来 —— 若宽高全部相等且内部最大字号也相等 ⇒ 判不过。
|
||||
- ⭐ 与 §5「删掉它主操作还做得成吗」串起来用：主卡 = 主操作的直接对象。当前项目卡该是主卡，其余降为次级行。
|
||||
|
||||
### 5.5.4 不许拿边框/底色假装分组（治法：「先间距、后字重、最后才边框」）
|
||||
|
||||
实证：「**Boxes instead of space** — Bordering every card to fake grouping. **Whitespace and type weight group more cleanly; reach for a border only after spacing has failed**」。
|
||||
|
||||
判据（按优先级依次尝试，能靠上位解决就不许用下位）：
|
||||
1. 间距：组内 gap < 组间 gap（至少 1.5×）
|
||||
2. 字重 / 字号：分组标题加粗或加大，与条目拉开
|
||||
3. 分隔线：只在列表行之间用 `border-top`（§1 已定）
|
||||
4. ⛔ 最后才是卡片边框：只有当 1–3 都做不到时才给卡片描边
|
||||
|
||||
- ⛔ 反例：给每个条目套一个圆角描边卡（本原型 P1/P2 都有）。
|
||||
- 机械核对法（与 `tooling.md` 红线 4 同一把尺子，判据正文在此）：数非控件元素里 `border` + `border-radius` 组合的出现次数；同一个"分组"用途上出现 ≥3 次即判过密。
|
||||
- 🔴 适用范围（2026-10-05 机检踩过，必须写死）：排除控件层 —— `button` / `input` / `select` / `textarea` / `[role=button]` 本就应该有边框+圆角（那是控件的身份标识），把它们算进"边框假装分组"是假红。
|
||||
⚠️ 首版判据没写这条适用范围，拿它扫 v3 原型得出「7 处过密」，逐条查出来全是按钮和输入框 ⇒ 判据错、页面没错。
|
||||
⭐ 同型警戒：凡"数某类样式出现次数"的判据，必须先声明"数的是哪些元素"；不分层的计数一定会把控件层算进来。这也是「全绿 ≠ 可用」的反面 —— "全红"也可能是判据自己的问题。
|
||||
|
||||
### 5.5.5 不可点的东西不许长成可点样子（治法：「控件样式是承诺」）
|
||||
|
||||
实证：与「Color is a signal channel」同型 —— 视觉通道是承诺，不是装饰。点下去没反应 = 说谎。
|
||||
|
||||
判据：
|
||||
- 任何带 `button` / 可点样式（填充、描边+圆角、hover 态）的元素，必须在 D0 契约「交互清单」里有四列定义（元素 / 触发 / 反馈 / 何时不可点）。列不出 ⇒ 要么补实现，要么降级成纯文本。
|
||||
- ⛔ 反例（实测踩过，三条）：① 「排序：最近活动倒序（固定，不给排序控件）」—— 把"我没做"写成界面文案，最恶劣；② 「打开产物」点了只改文案「已打开」1.6 秒后弹回；③ 「导出登记台账」只弹提示。
|
||||
- ⛔ 不许把实现决策写进界面：`（固定，不给排序控件）` 这类括号注，是给评审者看的，不是给用户看的。
|
||||
- 机械核对法：页面所有 `button` / `[role=button]` / `.btn*` 元素集合，与契约交互清单的元素列做双向差集 —— 有差即判不过。
|
||||
|
||||
---
|
||||
|
||||
## 6. 落地前自检（三条，可机械核对）
|
||||
|
||||
1. 形态判定已写出（D0 `结构骨架` 字段里有"这是哪一类、依据是什么"）。
|
||||
2. 类名全部来自种子 `template.html` 的类清单（或已补进它的 `<style>`），⛔ 不许在标签上内联一堆样式凑效果。
|
||||
3. 每条可点元素都在 D0 契约的「交互清单」里 —— 本文件给的是版式，不是交互真相源。
|
||||
4. ⭐ §5.5 五条逐条过（标题区无注脚 / 导航带标签 / 并列卡有主次 / 分组不靠边框 / 无假控件）——
|
||||
这五条过不了就别交付，它们正是「结构全对但仍然难看」的缺口所在。
|
||||
|
||||
> ⛔ 本文件不产出新判据。视觉样式归 D1 令牌表，交互归契约第十二字段，状态穷举归 `craft/state-coverage.md`。
|
||||
> 三处口径不同以本项目为准，并按 runbook §3.4 标注「本项目追加」。
|
||||
@@ -0,0 +1,236 @@
|
||||
---
|
||||
name: stage-discovery
|
||||
description: 产品规划第①段，产品需求。五个子步依次产出五份文档：1a 需求文档（用 grill-me 反问澄清需求，用户不答时给推荐答案并标【假设】继续）、1b 竞品分析、1c 用户画像、1d 产品策略、1e 使用场景（按用户故事格式写：谁、在什么处境下、要办成什么）。当用户要做竞品分析、用户画像、产品策略、使用场景，或说"只做产品需求"时调用。
|
||||
---
|
||||
|
||||
# ① 产品需求
|
||||
|
||||
回答"做什么、为谁、为什么值得做"。产出只有五份，全部落 `docs/pm/<项目>/research/`。
|
||||
|
||||
> 段名定为「产品需求」（2026-10-02 定）：本段 1b 做调研，1d/1e 定产品策略与场景，"调研"盖不住后半截，还会让②段的"需求"二字失去归属。四段各占一个词：产品 / 功能 / 界面 / 说明。
|
||||
|
||||
## ⭐⭐ 产出白名单（2026-10-06 用户定案 · 硬规矩）
|
||||
|
||||
本段在 `research/` 顶层只产出这五份，一份不多、一份不少：
|
||||
|
||||
| 子步 | 产出 |
|
||||
|---|---|
|
||||
| 1a 需求文档 | `research/1a-需求文档.md` |
|
||||
| 1b 竞品分析 | `research/1b-竞品分析.md`（汇总对比体，恒一份）＋ `research/1b-独立分析/<竞品名>.md`（独立分析体，竞品池里每一个一份） |
|
||||
| 1c 用户画像 | `research/1c-用户画像.md` |
|
||||
| 1d 产品策略 | `research/1d-产品策略.md` |
|
||||
| 1e 使用场景 | `research/1e-使用场景.md` |
|
||||
|
||||
🔴 用户原话：「禁止出现之前确定的以外的文档，除非用户明确要求」。
|
||||
不许自行新增第 6 份。实测栽过：某轮因为"用户点名了参考产品"就自作主张多产了一份《参考实装拆解》，用户反复看到"冒出来的不相关的文档"。"参考产品怎么做的"属 1b 竞品分析的取材范围，写进本份里，不另立一份。
|
||||
⭐ `1b-独立分析/` 子目录不算"第 6 份"：它是 1b 的既定体例之一（2026-10-07 用户定案：「竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了」）。它的份数由竞品池决定，不由人临时加。除此之外仍只许上面那五份。
|
||||
✅ 门禁可查：`check_naming.py` 扫 `research/` 顶层的实际文件名，出现白名单外的文件名即报红（子目录天然放行）。
|
||||
|
||||
## 本段职责（2026-10-06 重划）
|
||||
|
||||
本段回答一个问题：要做的东西，凭什么成立。拆成五问，各对应一个子步：
|
||||
|
||||
| 问 | 子步 | 产出 | 性质 |
|
||||
|---|---|---|---|
|
||||
| 要解决什么问题、边界在哪 | 1a 需求文档 | `1a-需求文档.md` | 拍板 |
|
||||
| 别人做了什么、我们差在哪 | 1b 竞品分析 | `1b-竞品分析.md` ＋ `1b-独立分析/` | 外部取证 |
|
||||
| 用户是谁、他要办成什么事 | 1c 用户画像 | `1c-用户画像.md` | 外部取证 |
|
||||
| 为什么值得做、边界与风险 | 1d 产品策略 | `1d-产品策略.md` | 判断 |
|
||||
| 用户怎么用它 | 1e 使用场景 | `1e-使用场景.md` | 判断 |
|
||||
|
||||
> ⭐ 1b/1c 是本段的证据地基，1a/1d/1e 的每条结论都要能追回它。没有外部取证，1d 就是凭想象定战略——实测踩过：三个 JTBD 全是同一个人的三种时刻，零外部取证。
|
||||
> 1a 与②段的 2a 是两件不同的事，见文末「需求文档在本段的落点」。
|
||||
|
||||
顺序 1a → 1b → 1c → 1d → 1e。需求没澄清就不许开取证，没有事实依据就不要定策略。
|
||||
|
||||
> 下面表格「读」列是该子步的方法论文档，路径相对本 skill 目录。执行某个子步前先读它。
|
||||
|
||||
## 1a 需求文档（必做，最先）
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 需求文档（grill-me） | `references/grill-me.md` | `docs/pm/<项目>/research/1a-需求文档.md` |
|
||||
|
||||
🔴 本子步的产出是「一份」文档（2026-10-06 用户定案）：`1a-需求文档.md` 一份说清全部。开头写清"做什么 / 为谁 / 不做什么"，往下摊开成决策表：目标、用户、范围与"明确不做什么"、手上已有的素材、约束、依赖、替代方案。
|
||||
（历史：为什么从两份并成一份 → `_留痕/①段-已删除产出与方法论.md`）
|
||||
|
||||
默认反问用户，附推荐答案。用户说"你定"、连续两轮不回应、或问题属事实类时，模型自行补答案并标 `【假设】`，但每轮结束要汇出待复核清单让用户一次性过。未经复核的 `【假设】` 不得在 1d 当事实用。
|
||||
|
||||
本子步不受"提问上限 3 个"约束，把需求问清楚正是它的全部价值。进入前先声明"接下来会连续多轮提问"。这是本段唯一例外（详见 `references/grill-me.md`）。
|
||||
|
||||
⭐ `grill-me` 全场只有本段这一份（2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」）。本份按 A / B 两节提问：
|
||||
|
||||
| 节 | 火力点 | 原归属 |
|
||||
|---|---|---|
|
||||
| A 节 | 要做什么、为谁、边界在哪 | ①段 |
|
||||
| B 节 | 做成什么样、哪些情况不成立、状态怎么流转 |②段|
|
||||
|
||||
> 不许再加回②段一份。②段从 2026-10-06 起只细化功能，不再反问需求，反问在这里一次性做完。
|
||||
> ⚠️ 合并的代价要说清：两个火力点合到一处，提问量必然变大。用"分节提问"解决，不许因为量大就省略 B 节——跳了 B 节等于把功能压测整个删掉。
|
||||
> ⭐ B 节只给粗粒度形态（有哪几页、大概几个板块），不把页面结构写死（精确板块清单与布局归②段的《界面布局》）。
|
||||
|
||||
## 1b 竞品分析（外部取证）
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 竞品拆解 · 独立分析 | `references/competitor-analysis.md` §11 | `docs/pm/<项目>/research/1b-独立分析/<竞品名>.md`（竞品池里每一个一份） |
|
||||
| 竞品拆解 · 汇总对比 | `references/competitor-analysis.md` §1—§10 | `docs/pm/<项目>/research/1b-竞品分析.md`（恒一份） |
|
||||
|
||||
1b 交两种体例（2026-10-07 用户定案：「竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了」）。职责边界与数量见 `references/competitor-analysis.md` §0.4。只交一种 ⇒ 1b 没做完。
|
||||
|
||||
> 🔴 写作口径（2026-10-07 补 · 用户报障逐字：「生成的文档并没有说人话，还是我手动要求的」）
|
||||
> 本段产出是给人看的文档，不是模型味的总结。落笔前读一遍其中一份：
|
||||
> 技能库 `humanizer-zh`（中文版，24 类 AI 写作模式）或会话技能包里的
|
||||
> `session-mechanism/references/作业规矩/04-去AI味与说话方式.md`（会话场景加固版，带交付前清单与质量评分）。
|
||||
> 定稿前按它的「交付前快速清单」过一遍。
|
||||
> 高频 AI 味一律禁：三段式排比连用、空转评价（「具有重要意义」「值得关注」）、以「…着」结尾的肤浅分析、模糊归因（「业内人士认为」）、过度加粗、把一句话拆成内联标题垂直列表。
|
||||
> ⚠️ 这条口径适用于本段全部五份产出（1a～1e），不只 1b。
|
||||
|
||||
⭐ 用户点名的"参考实装"写进本份，不另立文档（见「产出白名单」）。它是竞品池的第三层（直接竞品 / 间接替代 / 点名参考），在 §3—§10 的每一节里与其它竞品同列参与横向对比。
|
||||
|
||||
🔴 目标：从产品视角横向拆解竞品，讲用途、讲场景、讲功能、讲作用、讲优势（2026-10-07 用户口径）。
|
||||
|
||||
🔴 核心模型 = 五问（用途 → 场景 → 功能 → 作用 → 优势），本份每一节都在回答其中一问或几问。
|
||||
|
||||
执行：
|
||||
1. 读 `references/competitor-analysis.md`（唯一方法论载体，含 §0 Scope 与文末《输出检查》）
|
||||
2. 按项目目标圈定竞品范围（直接竞品 ＋ 至少 1 个替代/间接方案 ＋ 点名的参考实装）
|
||||
3. 先出独立分析体：竞品池里每一个一份，按 §11 的七节写（哪些节能答、哪些答不了，由 §11 的「取证范围 ↔ 可答节次」定）
|
||||
4. 再出汇总对比体：按 用途 → 场景 → 功能 → 作用 → 优势 横向比（按用户处境横向铺开，不按竞品逐个写）
|
||||
5. 输出优势与不足、可借鉴点与产品机会
|
||||
6. 交付前走一遍该方法论文末《输出检查》：任一条为「否」⇒ 退回修改，不交付
|
||||
|
||||
🔴 最低输出结构（最低要求，按品类可增不可缺）：
|
||||
|
||||
甲 · 汇总对比体（`research/1b-竞品分析.md`，恒一份）：
|
||||
|
||||
| # | 节 | 回答什么 |
|
||||
|---|---|---|
|
||||
| 1 | 分析目标与范围 | 这次要回答什么；五问各落在哪节 |
|
||||
| 2 | 竞品选择与范围 | 选了谁、属哪一层、为什么是它 |
|
||||
| 3 | 竞品用途 | 是什么 / 给谁用 / 干什么用 |
|
||||
| 4 | 使用场景横向对比 | 用户什么时候、为什么用；怎么把事办成 |
|
||||
| 5 | 功能横向对比 | 有什么能力 / 解决什么问题 / 起什么作用 |
|
||||
| 6 | 产品机制与交互方式 | 怎么解决 / 为什么这样设计 ⇒ 给用户什么结果 |
|
||||
| 7 | 优势与不足 | 能力表现 × 场景 × 对比对象 × 用户价值 |
|
||||
| 8 | 竞品能力矩阵 | 共识 / 差异 / 独有 / 普遍短板 / 未解决需求 |
|
||||
| 9 | 可借鉴点与产品机会 | 该借鉴 / 该避开 / 可突破 |
|
||||
| 10 | 结论（产品层） | 本产品应优先解决什么 |
|
||||
|
||||
乙 · 独立分析体（`research/1b-独立分析/<竞品名>.md`，每个竞品一份；结构细则与判据见方法论 §11）：
|
||||
|
||||
| # | 节 | 回答什么 |
|
||||
|---|---|---|
|
||||
| 1 | 它是谁、属哪一层、为什么纳入 | 竞品名 / 所属层级 / 纳入理由 |
|
||||
| 2 | 用途 | 是什么 / 给谁用 / 干什么用 |
|
||||
| 3 | 场景 | 用户在什么处境下用它；把事办成的实际过程（取不到就显式标缺口） |
|
||||
| 4 | 能力 | 有哪些功能 / 各解决什么问题 / 起什么作用 |
|
||||
| 5 | 机制 | 怎么做到的；为什么这样设计 ⇒ 给用户什么结果 |
|
||||
| 6 | 强在哪、弱在哪 | 能力表现 × 场景 × 对比对象 × 用户价值 |
|
||||
| 7 | 对我们 | 该借鉴 / 该避开 / 可突破 |
|
||||
|
||||
其中第 2 / 3 / 6 节是必答项，写法固定（每组几行、每行叫什么、什么顺序都定死，取不到就照写「取不到」）；第 1 / 4 / 5 / 7 节写法自由。行名与行数见方法论 §11，本表不复述。
|
||||
|
||||
⭐ ①段就是上表这 5 个子步，每个子步一个方法论载体。产出份数上，1b 是唯一一个交两种体例的子步（独立体多份 ＋ 汇总体一份），其余四个子步各一份。这套结构直接服务单机自用的产品（用户本人就是唯一使用者）。
|
||||
（历史：本段曾有过另外几个子步、以及一次子步合并，为什么收成 5 个 → `_留痕/①段-已删除产出与方法论.md`）
|
||||
|
||||
## 1c 用户画像（外部取证）
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 用户画像 | `references/user-personas.md` | `docs/pm/<项目>/research/1c-用户画像.md` |
|
||||
|
||||
## 1d 产品策略（判断）
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 产品策略 | `references/product-strategy.md` | `docs/pm/<项目>/research/1d-产品策略.md` |
|
||||
|
||||
## 1e 使用场景（判断）
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 使用场景 | `references/usage-scenario.md` | `docs/pm/<项目>/research/1e-使用场景.md` |
|
||||
|
||||
⭐⭐ 《使用场景》就是用户故事（2026-10-06 用户定案）：按「用户如何使用、解决什么问题」来梳理，唯一句式为
|
||||
|
||||
```
|
||||
作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】
|
||||
```
|
||||
|
||||
四个槽位缺一不算完成；「我要办成什么」里不许出现功能名（出现即越界到②段）。
|
||||
它是②段功能清单的直接推导依据——②段每列一项功能，都要能追回本份的某一条场景；②段按使用场景梳理功能（一条场景可跨多个页面）。
|
||||
本份就是用户故事，`1e-使用场景.md` 一份承载全部，②段的功能清单直接追回本份。
|
||||
旧三段式（处境 / 现在怎么凑合 / 不用会用什么）改挂到四槽位：处境 → 「当…」；凑合与替代 → 「这样…」的反面与对照。映射表见 `references/usage-scenario.md` §5。
|
||||
|
||||
⭐ 1d《产品策略》与 1b《竞品分析》都落在产品层，回答"谁在什么处境下拿它办成什么事、做哪些功能、强在哪"，面向本产品自用的定位。
|
||||
（历史：本段原还挂过两份面向售卖场景的方法论，若某个项目真要做售卖可从 `_留痕/①段-已删除产出与方法论.md` 取回）
|
||||
|
||||
## 「需求文档」在本段的落点（2026-10-02 定 · 2026-10-06 更新，避免误搬家）
|
||||
|
||||
段名定为「产品需求」后，容易误以为②段那两份该搬进本段。不搬，理由如下：
|
||||
|
||||
| 文档 | 归属 | 为什么 |
|
||||
|---|---|---|
|
||||
| `research/1a-需求文档.md` | ①段 | 做什么 / 为谁 / 不做什么 ＋ 决策表 |
|
||||
| `research/1b-竞品分析.md` | ①段 | 别人做了什么、我们差在哪（含点名的参考实装） |
|
||||
| `research/1c-用户画像.md` | ①段 | 用户是谁、要办成什么事（须追到原话） |
|
||||
| `research/1d-产品策略.md` | ①段 | 为什么值得做、边界与风险 |
|
||||
| `research/1e-使用场景.md` | ①段 | 用户怎么用它；使用场景 = 用户故事 |
|
||||
| `prd/2a-产品功能.md` | ②段 | 它是功能清单（做哪些 / 不做哪些 / 优先级 + 每条的状态流转） |
|
||||
| `prd/2b-界面布局.md` | ②段 | 它是页面骨架（页面关系 + 页面内板块布局——有哪几页、每页几个板块） |
|
||||
|
||||
> 分界线一句话：①段回答「要解决什么问题、用户怎么用它」，②段回答「要做哪些功能、长成什么骨架」。
|
||||
> 判据：一份文档若主体是功能条目的有无与优先级、页面与板块骨架 → 归②；若主体是问题、用户、取证与取舍理由 → 归①。
|
||||
> ⚠️ 2026-10-06 边界更新：②段从"不给页面结构"改为"给骨架"，页面关系与页面内板块布局必须在②段确认。
|
||||
> 理由（用户原话）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向，一会一个样子」。
|
||||
> 修订后分工：②段钉骨架（有哪几页、每页几个板块、板块怎么排、跨页关系）｜③段做皮肉（视觉规范 + 交互 + 状态，不许动骨架）。
|
||||
> 配色 / 字体 / 间距 / 组件样式 / 动效仍归③段，②段不许写这些。
|
||||
|
||||
## 硬约束
|
||||
|
||||
- 需求文档必做：`1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），且待复核清单已被用户过一遍。没有它不许开 1b——否则取证答的不是用户的问题。
|
||||
- ⭐⭐ 产出白名单（2026-10-06 用户定案）：本段产出仅五份（见开头「产出白名单」）。不许新增第 6 份，除非用户明确要求。
|
||||
- 自动补全要留痕：模型替用户补的答案必须标 `【假设】` + 理由 + 影响范围，并进待复核清单。用户始终不回应时，在该文件顶部写明"本表 X 项为模型假设，未经用户确认"。
|
||||
- ⭐ 状态行不许只写好消息（2026-10-02 新增）：`1a-需求文档.md` 顶部状态行必须同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」两个数。"frontier 为空""无遗留未决项"这类单边表述不得单独出现——它与正文"5 项是未经确认的假设"并存时，只读首屏的人会以为需求已澄清。
|
||||
- ⭐ 假设三归宿，不许长期悬空（2026-10-02 新增）：每条 `【假设】` 只能落在三种归宿之一——① 已确认（去掉标记，写明谁何时确认）② 待实现且已排定确认时机（写明"在第几步落地前必须问"）③ 已按假设落地（改标 `【已按假设落地】` ＋ 写清影响面 ＋ 给出回退口径）。第四种状态（既未确认、已进实现、又无落地说明）不许存在。实测：约 10 条假设从 09-24 挂到 10-02，而原型已做到 v16——假设错一条，返工面就是整页。
|
||||
- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02 新增）：任何写"待确认 / 暂缓 / 待定"的条目，必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。只写"暂缓"等于无限期悬挂。
|
||||
- ⭐ 用户画像必须能追到原话（2026-10-02 新增）：`1c-用户画像.md` 里每条 JTBD / 痛点必须能追到一句用户原话或一条可核的观察；追不到的标 `【推演】`，且 `【推演】` 不得进 1d 当依据。提问只问已经发生的事：问最近一次是什么时候、问上一次怎么处理的、问当时最费劲的是哪一步，不问"将来会不会用""你想要什么"。⚠️ 实测踩坑：三个 JTBD（「此刻的我 / 确认时刻的我 / 三个月后的我」）全是同一个人的三种时刻、零外部取证——那是自证，不是用研。
|
||||
- 调研不求全：只做影响本次决策的那几项，其余跳过并说明为什么跳过。
|
||||
- 区分事实与假设：来自检索或访谈的标 `【事实】`，推断的标 `【假设】`。1d/1e 的每条结论必须能追到 1b/1c 的某份文件或 `1a-需求文档.md` 的某一行；追不到的按假设处理。
|
||||
- ⭐ 1a 与 2a 的分工不许混（2026-10-02 段名对齐，2026-10-06 更新）：1a 定「问题与边界 + 形态与状态」（要做的东西凭什么成立、做成什么样），2a 定「功能与取舍」（要做哪些功能、哪些明确不做、页面骨架怎么排）。1a 不许写功能清单（那是 2a），2a 不许重开需求（那是 1a，含 2026-10-06 从②段合并进来的 B 节压测）。
|
||||
- ⭐ B 节合并后 `grill-me` 只此一份（2026-10-06）：②段不再有独立的 `grill-me.md` 与 `grill-decisions.md`，其二者的内容（做成什么样 / 状态怎么流转 / 哪些情况不成立）全部落进 `1a-需求文档.md`。不许把 B 节再挪回②段。
|
||||
- 段内子步之间不反问，做完直接进下一个子步。只有三种情况停：信息不足且查不到、破坏性/不可逆动作、用户显式要求（见 `product-planning` 的「执行规则」）。
|
||||
- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- `1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），每项都标了来源（用户拍板 / `【假设】` / `【事实】`）
|
||||
- 顶部状态行给出「已确认 N / 模型补全 M（未经确认）」两个数；每条 `【假设】` 都能在三种归宿里找到自己（已确认 / 待实现已排时机 / 已按假设落地）
|
||||
- 1b 竞品分析 + 1c 用户画像 + 1d 产品策略 + 1e 使用场景 四份齐全
|
||||
- ⭐ 1b 两种体例都交了（2026-10-07 新增）：`research/1b-竞品分析.md`（汇总对比体）且 `research/1b-独立分析/` 下竞品池每一个一份（独立分析体）——只交一种 ⇒ 1b 没做完
|
||||
- ⭐ 目录里不出现白名单外的任何文件（第 6 份须有用户明确要求；`1b-独立分析/` 子目录是 1b 既定体例，不算第 6 份）
|
||||
- 1d/1e 每条结论都标了来源（哪份取证文件或本表哪一行，或 `【假设】`）
|
||||
- ⭐ 五份都过了「说人话」内容准则（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50）——口径见 `product-planning` 的「执行规则」内容准则条；段末报告须写明"已过内容准则，评分 X/50"
|
||||
|
||||
## 反面清单
|
||||
|
||||
- 跳过需求文档直接开取证，拿着自己的猜测去查资料
|
||||
- 把自动补全当默认动作：用户没说话就替他拍板，还没标 `【假设】`、没进待复核清单
|
||||
- 拿本段的需求文档代替第②段的功能压测（那是两件事——②段已无压测，压测在 1a 的 B 节）
|
||||
- 在本段 1a 写功能清单（那是 2a 的活；1a 只定问题与边界、形态与状态）
|
||||
- 只做 A 节、跳过 B 节（2026-10-06 新增）：B 节即原②段的功能压测，跳过它等于把压测整个删掉，接口会带着没压测过的需求直接进②段与原型
|
||||
- 在 B 节把页面结构写死（2026-10-06 新增）：B 节只给粗粒度形态（有哪几页、大概几个板块）；精确板块清单与布局图归②段的《界面布局》
|
||||
- 产出白名单外的第 6 份文档（2026-10-06 新增）：不许因为"用户点名了某个参考产品/某份素材"就另立文档，写进 `1b-竞品分析.md` 里
|
||||
- 1b 只交汇总对比体、把独立分析省掉（2026-10-07 新增）：用户定案「竞品分析有独立分析也有汇总分析 都应该要用上」。也不许把独立体写成仓库取证记录，它必须按方法论 §11 的七节答产品面（用途 / 场景 / 能力 / 机制 / 强弱 / 对我们）
|
||||
- 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07 新增）：规则和产出同一把尺子，不许只给产出上锁、自己用另一套腔调写规则——口径见 `product-planning` 的「执行规则」内容准则条
|
||||
- 没有取证就直接写策略
|
||||
- 把 11 个子步全跑一遍充数
|
||||
- 事实与假设混在一起不标注
|
||||
- 拿"frontier 为空 / 无遗留未决项"当闭合声明，而正文里还挂着未经确认的假设——只读首屏的人会误读成需求已澄清
|
||||
- 凭空给 Importance / Satisfaction 打分：没有任何数据源支撑的数字，不许出现在交付物里
|
||||
- 五份没过「说人话」内容准则就落盘（带 AI 腔：夸张意义 / 三段式强凑 / 破折号滥用 / 模糊归因 / 通用乐观结尾）——门槛 ≥45/50，见 `product-planning` 的「执行规则」内容准则条
|
||||
- 把推演出来的用户画像当用研结论进 1c——三个 JTBD 若都追不到一句用户原话，那是自证不是用研
|
||||
- 越界去写②段、出原型或写原型说明文档（那是第②③④段）
|
||||
|
||||
📎 本段删过的产出与方法论（原产出长什么样、为什么删、原反面清单里被撤掉的那一条）见 `_留痕/①段-已删除产出与方法论.md`，正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` 机器判。
|
||||
+288
@@ -0,0 +1,288 @@
|
||||
# 竞品分析方法论（1b · 产品视角）
|
||||
|
||||
> 定位：本档是 1b 竞品分析唯一的方法论载体。技能层（`../SKILL.md` §1b）定「必须交付什么」，本档定「怎么分析」。
|
||||
> 产出落点：`docs/pm/<项目>/research/1b-竞品分析.md`（①段产出白名单五份之一）。
|
||||
> 口径来源：2026-10-07 用户定案 ——「分析重点是讲**用途**、讲**场景**、讲**功能**、讲**作用**、讲**优势**，其余跟产品规划不相关的都去掉」。
|
||||
|
||||
---
|
||||
|
||||
## 0. Scope
|
||||
|
||||
### 0.1 本方法用于
|
||||
|
||||
为一款将要做的产品，横向拆解同类产品在产品层面怎么解决用户问题：讲用途、讲场景、讲功能、讲作用、讲优势。
|
||||
|
||||
### 0.2 上层约束
|
||||
|
||||
`../SKILL.md` §1b 定「必须交付什么」，本档定「怎么分析」。两者冲突以技能层为准，并回头修正本档。
|
||||
|
||||
### 0.3 完成判据（一句话）
|
||||
|
||||
做完 1b 必须能回答：
|
||||
|
||||
> 如果我要做这个产品：竞品已经怎么做了？哪里做得好？哪里没做好？我该学什么、避开什么、突破什么？
|
||||
|
||||
答不出这句话，1b 就没做完。
|
||||
|
||||
### 0.4 两种交付体例（本档的排布）
|
||||
|
||||
1b 交两份体例，两份都要交（2026-10-07 用户定案：「**竞品分析有独立分析也有汇总分析，都应该要用上**」）：
|
||||
|
||||
1. 独立分析体 —— 一个竞品一份，回答这一个产品是什么、给谁用、怎么把事情办成、强在哪弱在哪、对我们有什么可拿的。结构见 §11。
|
||||
2. 汇总对比体 —— 全池一份，回答放在一起比：共识是什么、差异在哪、哪里没人做好。结构见 §1—§10。
|
||||
|
||||
职责边界（本档定死，避免两边各写一遍、出现两套判据）：
|
||||
|
||||
- 单个竞品的形态 / 给谁用 / 干什么用、场景里用户把事办成的过程、它自己的能力与机制，归独立体（§11）。
|
||||
- 跨竞品的横向铺开（同一场景谁怎么做）、能力矩阵、共识与空白、本产品优先解决什么，归汇总体（§1—§10）。
|
||||
- 两边都要写的只有一样：可借鉴 / 该避开 / 可突破。独立体写「从这一个竞品拿什么」，汇总体写「三类分开汇总并追回 §4 / §5 / §7」。
|
||||
|
||||
数量：独立体取竞品池里的每一个（用户点名要求合并的按用户口径合并，如「同源 fork 合成一份」）；汇总体恒一份。
|
||||
|
||||
判据：两种体例都交付了，才算 1b 完成。只交汇总体、或只交独立体，就是没做完。
|
||||
|
||||
---
|
||||
|
||||
## 1. 分析目标与范围
|
||||
|
||||
核心模型是五问。后面每一节都在回答其中一问或几问，§1 先把它们摆明。
|
||||
|
||||
| 五问 | 关注点 | 落在哪一节 |
|
||||
|---|---|---|
|
||||
| 用途：它是什么、给谁用、干什么用？ | What / Who | §3 |
|
||||
| 场景：用户在什么处境下会用它？ | When / Why | §4 |
|
||||
| 功能：它有哪些核心能力？ | What | §5 |
|
||||
| 作用：每项能力解决什么问题？ | What for | §5 |
|
||||
| 优势：它相对**谁**、在哪些场景下更强或更弱？ | vs Whom | §7 |
|
||||
|
||||
写什么：把这次要回答的问题写死在文档开头（本次目标、本次竞品池、本次不展开的部分），让五问各自落进上表那一节。
|
||||
|
||||
判据：五问各有一处明确落点，读的人能在对应节里直接读到答案，收口在 §8 矩阵与 §10 结论。
|
||||
|
||||
---
|
||||
|
||||
## 2. 竞品选择与范围
|
||||
|
||||
写什么：竞品分三层，逐层交代为什么选它 ——
|
||||
|
||||
1. 直接竞品：解决同一个核心问题、目标用户高度重叠。
|
||||
2. 间接 / 替代方案：同一需求的不同产品形态，或用户换一种做法时的替代路径。
|
||||
3. 点名参考实装：用户点名指定的那一个。
|
||||
|
||||
归属（本档定死，避免歧义）：点名参考实装就是竞品池的第三层，写进同一份 `1b-竞品分析.md`，在 §3—§10 的每一节里与其它竞品同列参与横向对比，不单独成节、不另立文档。文档开头要写清「本次竞品池 = 哪几个 ＋ 各自属于哪一层」。
|
||||
|
||||
数量：按项目目标自定。最低要求是「直接竞品 ＋ 至少 1 个替代/间接方案」；复杂项目自行加层加项。
|
||||
|
||||
判据：
|
||||
- 纳入池子的每一个，都要能回答「用户为什么会拿它和我们的产品做选择？」。分水岭是用户的选择，不是名气大小。
|
||||
- 点名参考实装已收录，且在池子里标明层级。
|
||||
|
||||
---
|
||||
|
||||
## 3. 竞品用途（是什么 / 给谁用 / 干什么用）
|
||||
|
||||
关注点：What / Who。每个竞品一小段，只答三件事：它是什么形态的产品、服务谁、拿它干什么用。
|
||||
|
||||
判据：读完这段，没接触过这个产品的人能说清它是干什么的；三件事之外的内容归后面的节（能力归 §5、机制归 §6）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 使用场景横向对比
|
||||
|
||||
关注点：When / Why —— 用户什么时候用、为什么要用。按用户处境横向铺开：
|
||||
|
||||
```
|
||||
场景 用户要办成什么 竞品A 怎么做 竞品B 怎么做 竞品C 怎么做
|
||||
场景 1 …
|
||||
场景 2 …
|
||||
```
|
||||
|
||||
§4 写的是「什么时候、为什么用」：用户处于什么处境、要办成什么事、为什么这件事必须做。
|
||||
|
||||
展开时沿用户的实际动作链走：进入方式 → 操作路径 → 核心步骤 → 系统提供什么帮助 → 最终产出 → 哪一步最省力 → 哪一步最麻烦。这一段要写出用户实际把事办成的过程，功能名与按钮细节归 §5 / §6。
|
||||
|
||||
判据：能描述出用户实际使用的过程（谁、什么处境、办成了什么），并且能说清为什么在这个处境下会用它。
|
||||
|
||||
---
|
||||
|
||||
## 5. 功能横向对比
|
||||
|
||||
关注点：What —— 有什么能力、能解决什么问题。先建一组统一维度，再横向比。维度按产品调整，可用：核心功能 / 辅助功能 / 输入方式 / 处理方式 / 输出方式 / 编辑能力 / 管理能力 / 协作能力 / AI 能力 / 自动化能力。
|
||||
|
||||
每个功能必须答三问（本档硬要求）：
|
||||
|
||||
> 是什么 → 解决什么问题 → 对用户起什么作用
|
||||
|
||||
维度按品类自定、可增不可缺。每个维度都要出现「解决什么问题 / 起什么作用」这一层。
|
||||
|
||||
判据：读的人能说清每项能力是为什么问题而存在的；只摆能力名、不接「解决什么问题」的写法不达标。
|
||||
|
||||
---
|
||||
|
||||
## 6. 产品机制与交互方式
|
||||
|
||||
关注点：How / Why —— 怎么解决、为什么这样设计。比较：核心任务流程 / 信息组织方式 / 导航结构 / 核心交互 / 默认行为 / 自动化机制 / AI 与用户的分工 / 关键反馈 / 异常处理 / 用户控制权。
|
||||
|
||||
写的是「它为什么这样设计、这样设计给用户带来什么结果」；界面外观描述归 §5 的能力层。
|
||||
|
||||
判据：每条机制都能接出「为什么这样设计 ⇒ 给用户带来什么结果」，与 §4 的场景、§5 的能力形成因果链。
|
||||
|
||||
---
|
||||
|
||||
## 7. 优势与不足
|
||||
|
||||
关注点：vs Whom —— 相对谁更强、相对谁更弱。
|
||||
|
||||
判断公式（本档硬要求）：
|
||||
|
||||
> 优势 / 不足 ＝ 能力表现 × 使用场景 × 对比对象 × 用户价值
|
||||
|
||||
例：
|
||||
|
||||
> 在「一次要处理大量内容」这个场景下，A 的批量处理能力相对 B 少三步重复操作，因此更适合高频批量生产。
|
||||
|
||||
四条要素都要落地：能力表现（强在哪）→ 使用场景（在什么处境下）→ 对比对象（比谁强/弱）→ 用户价值（带来什么结果）。精确到「少几步」不是硬要求，但比较基准必须写出来。
|
||||
|
||||
判据：任何「好 / 差 / 强 / 弱」都能说出相对谁、在什么场景下、带来什么结果。
|
||||
|
||||
---
|
||||
|
||||
## 8. 竞品能力矩阵
|
||||
|
||||
写什么：一张横向矩阵收口 ——
|
||||
|
||||
```
|
||||
能力 / 场景 竞品A 竞品B 竞品C 机会
|
||||
… … … … …
|
||||
```
|
||||
|
||||
取值口径：矩阵里的行取有代表性、能区分竞品的能力与场景，挑的是「看完这一张就能抓住差异」的那些行。
|
||||
|
||||
判据：矩阵要能看得出五件事：行业共识能力 / 竞品之间的差异能力 / 某家的独有能力 / 普遍做得不好的能力 / 还没被解决好的需求。
|
||||
|
||||
---
|
||||
|
||||
## 9. 可借鉴点与产品机会
|
||||
|
||||
写什么：三类分开写 ——
|
||||
|
||||
1. 该借鉴：竞品已验证有效，且与本产品目标一致。
|
||||
2. 该避开：竞品存在明显问题，不应照搬。
|
||||
3. 可突破：需求真实存在，但竞品解决得不够好。
|
||||
|
||||
每条给：机会点 → 对应场景 → 用户问题 → 竞品现状 → 建议方向。
|
||||
|
||||
判据：本节每一条都要能追回 §4 / §5 / §7 的某一条。
|
||||
|
||||
---
|
||||
|
||||
## 10. 结论（产品层）
|
||||
|
||||
写什么（一律写成产品层的表述）：用户最核心的需求是什么 / 竞品共同解决了什么 / 竞品共同存在什么问题 / 哪些能力已经是基础能力 / 哪些能力还能形成差异 / 本产品应优先解决什么。
|
||||
|
||||
判据：结论只落在产品层，并且能一句话接回 §0.3 的完成判据。
|
||||
|
||||
---
|
||||
|
||||
## 11. 独立分析体（每个竞品一份）
|
||||
|
||||
落点：`docs/pm/<项目>/research/1b-独立分析/<竞品名>.md`。放这个子目录是因为 ①段产出白名单闸门只扫 `research/` 顶层的 `.md`（判据见 `scripts/check_naming.py` 的 `WHITELIST`），独立体放进子目录天然放行，竞品再多也不会撞白名单，不必为此扩白名单。
|
||||
|
||||
> 存量项目里的 `证据附卷/` 是历史落点，不强制迁移；新项目按上面这条走。
|
||||
|
||||
七节齐全，一节不许缺。其中三节写法固定（必答项），另外四节写法自由。
|
||||
|
||||
> 口径（2026-10-07 用户定案，选「方案 A」）：定太粗等于没定，定太细遇到形态不一样的竞品会别扭，所以只把最容易漏的几组定死，不把整份写成填空题。
|
||||
|
||||
写法固定的三节：每组几行、每行叫什么、什么顺序都固定。取不到证据时那一行照写，内容写「取不到：<原因>」，不许删行，也不许改写成一段话蒙过去。
|
||||
|
||||
第 2 节「用途」固定四行：
|
||||
|
||||
```
|
||||
- 形态：
|
||||
- 给谁用：
|
||||
- 干什么用：
|
||||
- 证据等级：
|
||||
```
|
||||
|
||||
第 3 节「场景」固定六行，沿用户实际动作链：
|
||||
|
||||
```
|
||||
- 进入方式：
|
||||
- 操作路径：
|
||||
- 核心步骤：
|
||||
- 系统帮了什么：
|
||||
- 最终产出：
|
||||
- 哪一步最省力 / 最麻烦：
|
||||
```
|
||||
|
||||
（整节都取不到 ⇒ 六行全写「取不到：<原因>」，并把缺口列在节末。不许拿功能名罗列冒充使用过程。）
|
||||
|
||||
第 6 节「强在哪、弱在哪」每写一条强弱，就是固定四行；有几条就重复几组：
|
||||
|
||||
```
|
||||
- 能力表现：
|
||||
- 在什么场景：
|
||||
- 相对谁：
|
||||
- 对用户什么结果：
|
||||
```
|
||||
|
||||
写法自由的四节（结构自己定，判据照旧）：
|
||||
|
||||
1. 它是谁、属哪一层、为什么纳入 —— 竞品名、形态、竞品池层级、纳入理由（分水岭是用户的选择，不是名气大小）。
|
||||
4. 能力：它有哪些功能，各解决什么问题、起什么作用 —— 每项能力答三问（是什么 → 解决什么问题 → 对用户起什么作用）；只摆能力名、不接「解决什么问题」的不达标。
|
||||
5. 机制：它怎么做到的，为什么这样设计 ⇒ 给用户什么结果 —— 每条机制都要接出「为什么这样设计 ⇒ 给用户带来什么结果」。
|
||||
7. 对我们：该借鉴 / 该避开 / 可突破 —— 每条给「机会点 → 对应场景 → 用户问题 → 它现在怎么做 → 建议方向」。
|
||||
|
||||
取证范围 ↔ 可答节次（不许越级答）：取证深度决定哪几节能真答，越级答就是编。
|
||||
|
||||
- 只有官方自述与仓库元数据（无源码、无界面）⇒ 第 4、5 节只能写「官方自述的能力」与「有据的推断」，并逐条标证据等级；第 3 节的六行多半只能写「取不到」，那就照实写并列出缺口。
|
||||
- 有源码 ⇒ 第 4、5 节可写实现级结论。
|
||||
- 有界面（截图 / demo / 亲自跑过）⇒ 第 3 节才写得完整。
|
||||
|
||||
判据：七节齐全；三组必答项的行都在，取不到的写「取不到」而不是留白；第 4 节每项能力都接了「解决什么问题 / 起什么作用」；第 6 节每条强弱都写了「相对谁」。
|
||||
|
||||
---
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
交付前逐条过。任一条为「否」，退回修改，不交付。
|
||||
|
||||
汇总对比体（`research/1b-竞品分析.md`，§1—§10）：
|
||||
|
||||
- [ ] §1 把本次目标与竞品池写死在开头，五问各有明确落点
|
||||
- [ ] 竞品池三层齐全，点名参考实装已收录并标明层级
|
||||
- [ ] §4 能说清「用户什么时候、为什么用」，并写出实际把事办成的过程
|
||||
- [ ] §5 每个维度都接了「解决什么问题 / 起什么作用」
|
||||
- [ ] §6 每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
|
||||
- [ ] §7 每条判断都写明了「相对谁、在什么场景、什么结果」
|
||||
- [ ] §8 矩阵取的是有代表性、能区分竞品的行，且看得出共识/差异/独有/短板/未解决需求
|
||||
- [ ] §9 每一条都能追回 §4 / §5 / §7
|
||||
- [ ] 全文只围绕用途 / 场景 / 功能 / 作用 / 优势展开
|
||||
- [ ] §10 结论只落在产品层，并可一句话回答 §0.3
|
||||
|
||||
独立分析体（`research/1b-独立分析/<竞品名>.md`，§11）：
|
||||
|
||||
- [ ] 第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气）
|
||||
- [ ] 第 2 节的四行都在（形态 / 给谁用 / 干什么用 / 证据等级），没有留白
|
||||
- [ ] 第 3 节的六行动作链都在；取不到的写了「取不到」，没有留白、也没有拿功能名罗列顶替
|
||||
- [ ] 第 4 节每项能力都接了「解决什么问题 / 起什么作用」
|
||||
- [ ] 第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
|
||||
- [ ] 第 6 节的每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
|
||||
- [ ] 第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
|
||||
|
||||
两种体例齐备：
|
||||
|
||||
- [ ] 竞品池里每一个都有独立分析体（用户点名合并的按用户口径合并）
|
||||
- [ ] 汇总对比体存在，且没有把独立体的内容整段抄一遍（横向铺开才算汇总体）
|
||||
|
||||
---
|
||||
|
||||
## 变更历史
|
||||
|
||||
- **2026-10-07 第四版**：独立分析体定下「必答项」写法。用户 2026-10-07 在「只定必答项 / 七节全定死 / 只定最疼两处」三个候选里选了**方案 A**（只定必答项）。改动：§11 把第 2 节（用途）四行、第 3 节（场景）六行、第 6 节（强弱）每组四行定为固定写法，取不到照写「取不到」；第 1、4、5、7 节写法自由；《输出检查》同步改成按行核。
|
||||
|
||||
- **2026-10-07 第三版**：补「两种交付体例」。起因：用户 2026-10-07 原话「**竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了**」—— 本档第二版只描述了汇总对比体（§1—§10），独立分析体一字未提，于是独立分析被写成仓库取证记录、没有产品面。本次改动：① 新增 §0.4「两种交付体例」定死职责边界与数量；② 新增 §11「独立分析体」给出七节结构与「取证范围 ↔ 可答节次」对应表；③ 《输出检查》拆成汇总对比体 / 独立分析体 / 两体例齐备三段。
|
||||
|
||||
- **2026-10-07 第二版**：按评审意见收紧机制层。① §1 把「五问」明确定为**核心模型**并给出关注点列；② §4 / §5 / §6 明确职责边界（When·Why / What / How·Why）；③ §7 判断公式补上**对比对象**（相对谁）；④ §2 把「点名参考实装」的归属**定死在竞品池第三层**，消除与章节结构的歧义；⑤ §8 补矩阵取值口径；⑥ 全文改成正向表述。
|
||||
- **2026-10-07 第一版**：全文重写为《竞品分析方法论（1b · 产品视角）》（用户口径：讲用途 / 场景 / 功能 / 作用 / 优势）。新增 §0 Scope 与文末《输出检查》。改版前的英文版已退役留痕于 `_superseded-competitor-analysis-英文商业版.md`。
|
||||
+169
@@ -0,0 +1,169 @@
|
||||
# 1a 需求文档（grill-me · grill 提问法 · 全场唯一一份）
|
||||
|
||||
> 本文件是 `stage-discovery` 的方法论文档，由模型按需加载，没有斜杠命令。
|
||||
>
|
||||
> 来源：`mattpocock/skills`（MIT）的 `grilling`。上游把 `grill-me` 做成只含一句 `Call the Skill tool with "grilling"` 的 stub，在这里属于多余跳转，故合并为一个自包含 skill 并做 PM 适配。
|
||||
>
|
||||
> ⭐⭐ 2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」。
|
||||
> ⇒ 本份是全场唯一一份 grill-me，A / B 两节覆盖需求与功能两轮提问。
|
||||
|
||||
## 适用位置
|
||||
|
||||
PM 链路的①段 1a 需求文档，在任何一项调研之前先做（产出 `1a-需求文档.md`）。
|
||||
|
||||
起点对齐只写一句话（做什么 / 为谁 / 不做什么），本子步把这句摊开成决策表。没有这张表就去做取证，等于拿着自己的猜测去查资料，查回来的东西答的不是用户的问题。
|
||||
|
||||
## ⭐⭐ 合并后要覆盖两个火力点（分两节提问，⛔ 不许省略后半节）
|
||||
|
||||
| 节 | 火力点 | 原归属 | 不做的后果 |
|
||||
|---|---|---|---|
|
||||
| **A 节** | **要做什么、为谁、边界在哪** | ①段 | 不澄清就没法取证 —— 查回来的答的不是用户的问题 |
|
||||
| **B 节** | **做成什么样、哪些情况不成立、状态怎么流转** |②段| 不压测就没法写②段—— AI 带着理解错的需求一路做到原型 |
|
||||
|
||||
> 合并的代价要先说清：两个火力点合到一处，提问量必然变大。
|
||||
> 解决办法是分节提问：先问完 A 节，再开 B 节；每节内部照旧一轮问完整个 frontier。
|
||||
> ⛔ 不许因为量大就把 B 节略过。B 节里没问清的状态与不成立条件，②段不会再有第二次机会（②段从 2026-10-06 起只细化功能，不再反问）。
|
||||
|
||||
## 核心规则
|
||||
|
||||
把需求当成决策树：每个决策分支出依赖它的决策。
|
||||
|
||||
按轮次（round）推进，不按单问推进。
|
||||
|
||||
frontier = 所有前置条件已定的决策，也就是现在就能问、不必先猜其他答案的那些问题。
|
||||
|
||||
一轮问完整个 frontier：逐条编号、每个都给出你的推荐答案，然后停下等用户回答，再据此重算 frontier 进入下一轮。
|
||||
|
||||
单轮格式：
|
||||
|
||||
```
|
||||
❓ **Q1** - **<问题标题>**：<问题正文，可多段，含选项>
|
||||
|
||||
➡️ <你的推荐答案>
|
||||
|
||||
---
|
||||
|
||||
❓ **Q2** - **<问题标题>**：<问题正文，可多段，含选项>
|
||||
|
||||
➡️ <你的推荐答案>
|
||||
```
|
||||
|
||||
依赖必须排序：若某问题的答案依赖于本轮另一个尚未决断的问题，它属于下一轮，不属于本轮。
|
||||
|
||||
事实归你，决策归用户。需要外部事实（竞品现状、市场价格、技术可行性、法规）时，派 sub-agent 去查，不要问用户。也不要因此阻塞——只有下游问题等 sub-agent 回报，本轮其余问题照问不误。用户负责拍板，不负责查资料。
|
||||
|
||||
## 反问优先，模型可自动补全（本段的关键差别）
|
||||
|
||||
默认动作是反问，不是替用户决定。每个问题都先抛给用户，并附上你的推荐答案与理由。用户看到选项才好拍板，光看问题会卡住。
|
||||
|
||||
允许自动补全，但要留痕。下列情况模型自己给出答案并继续推进，不阻塞：
|
||||
|
||||
- 用户明确说"你定 / 不知道 / 先按你的来"
|
||||
- 用户连续两轮未回应某个问题
|
||||
- 问题属于事实类，sub-agent 查得到（此时直接给结论，标 `【事实】`）
|
||||
|
||||
自动补全的产出必须满足三条：
|
||||
|
||||
1. 标 `【假设】`，并写清理由与「一旦不成立会有什么后果」
|
||||
2. 每轮结束把当前所有 `【假设】` 项汇成一份待复核清单，让用户一次性过，不静默塞进结论里
|
||||
3. 未经复核的 `【假设】`，在 1c 产品定位与场景里不得当作事实使用，也不得写进策略结论
|
||||
|
||||
自动补全不等于替用户拍板。它换的是「别卡住」，不是「别问」。用自动补全把问题糊过去，比不澄清更糟。
|
||||
|
||||
## 结束条件
|
||||
|
||||
frontier 为空 = 决策树每个分支都走过、没有静默假设，且待复核清单已被用户过了一遍。
|
||||
|
||||
用户始终不回应时，允许带着 `【假设】` 往下走，但要在 `1a-需求文档.md` 顶部写明「本表 X 项为模型假设，未经用户确认」，让下游一眼看到风险。
|
||||
|
||||
> 状态行不许只写好消息：顶部必须同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」两个数。「frontier 为空 / 无遗留未决项」不得单独出现。本项目实测踩过：状态行写「frontier 为空——12 项决策全部有来源」，同文件待复核清单里躺着 3 项未经用户逐条回应。
|
||||
|
||||
## 与 product-planning 的约束隔离（重要）
|
||||
|
||||
`product-planning` 常规流程设有「提问上限 3 个」与「一次一段」。本子步不受这两条约束，把需求问清楚正是它的全部价值。
|
||||
|
||||
因此进入本子步时必须先显式告知用户「接下来会连续多轮提问，每轮若干编号问题，每个都附推荐答案」，退出后恢复常规约束。不声明就直接连问，会被当成跑偏。
|
||||
|
||||
## A 节必须覆盖的分支（要做什么、为谁、边界在哪）
|
||||
|
||||
下表是需求决策树的一级分支，每个分支下再按依赖展开。
|
||||
|
||||
| 分支 | 要问清的 |
|
||||
|---|---|
|
||||
| 目标 | 解决什么问题、成功怎么衡量、谁最痛 |
|
||||
| 用户 | 谁用、熟练度、在什么场景下用、现在怎么凑合 |
|
||||
| 范围 | 第一版做什么、**明确不做什么**、什么东西不在这个产品里 |
|
||||
| **交付形态** | **这套东西应该有几个界面 / 一页几件事 / 信息承载到哪一层**（2026-09-29 新增） |
|
||||
| 素材与数据 | 手上已有什么（存量数据、素材、样例）、还缺什么才能验证 |
|
||||
| 约束 | 预算 / 人力 / 时间 / 合规底线 |
|
||||
| 依赖 | 依赖哪些外部系统、平台、第三方能力 |
|
||||
| 竞品与替代 | 用户现在拿什么替代、为什么换（事实类可自动补全） |
|
||||
|
||||
> ⭐ 为什么「交付形态」是必问支（实战教训）：
|
||||
> 原有 7 个必问分支覆盖了「做什么、为谁、边界」，唯独没问「交付成一个什么样的东西」。本项目①段问完了范围却漏掉形态，③段于是把六件事塞进一个页面，做成 2,884 行、约 190 个交互函数的「控制台」，被用户判定为「最多算一个产品框图」。
|
||||
>
|
||||
> 本支至少要问清三件事：
|
||||
> | # | 问题 | 为什么在 ① 段问 |
|
||||
> |---|---|---|
|
||||
> | 1 | **价值主要在哪一层**——约定 / 文件结构，还是界面？ | 决定界面的**复杂度上限**。答"约定为主"则界面必须薄 |
|
||||
> | 2 | **应该有几个界面**，每个界面只办一件事时的"一件事"是什么 | 结构性决策；**漏掉它，后续所有界面文档都要重做** |
|
||||
> | 3 | **信息承载到哪一层**——哪些必须一进来就看到，哪些点一下能看到即可 | 决定"信息墙"是否发生（②段会据此出分档表） |
|
||||
>
|
||||
> 不适用时：若产品确实没有界面（纯 CLI / 纯约定），在 `1a-需求文档.md` 写明「本产品无界面，交付形态=约定 + 脚本」，不留空、不跳过。
|
||||
|
||||
## B 节必须覆盖的分支（做成什么样、哪些情况不成立、状态怎么流转）
|
||||
|
||||
> 这一节是 2026-10-06 从②段合并进来的。原②段的写法是「在 `create-prd` 之前做一次功能压测」，目的是把「需求澄清」从可跳过的步骤变成强制环节，避免 AI 带着理解错的需求把②段和原型一路做完。合并后目的不变，只是位置前移到这里。
|
||||
|
||||
| 分支 | 要问清的 |
|
||||
|---|---|
|
||||
| 形态与骨架 | 有哪几页、每页大致几个板块、板块怎么排、页与页怎么连（**粗粒度即可**，细的归②段的《界面布局》） |
|
||||
| 不成立条件 | 什么情况下这套东西**不适用 / 用不起来**（不是"异常"，是"这个做法本身失效"） |
|
||||
| 状态流转 | 有哪些状态、按什么次序触发、彼此怎么迁移（起始 / 中间 / 终态） |
|
||||
| 失败与恢复 | 失败怎么办、能否重试、谁兜底 |
|
||||
| 数据契约 | 输入什么、产出什么、谁来维护、存在哪 |
|
||||
| 权限 | 谁能看、谁能改、越权怎么处理 |
|
||||
| 并发与幂等 | 同一件事被做两次会怎样、多个人同时改会怎样 |
|
||||
|
||||
> ⭐ B 节的产出落进 `1a-需求文档.md`。
|
||||
> ⭐ B 节问的是「做成什么样」，不问「做成什么样好看」：配色 / 字体 / 间距 / 动效一律不在这里问（那是③段）。
|
||||
> ⭐ B 节的「形态与骨架」是粗粒度：本轮只确认「有哪几页、大概几个板块」，精确的板块清单与布局图归②段。
|
||||
> ⛔ 不许在 B 节就把页面结构写死 —— 那会让②段的《界面布局》变成照抄。
|
||||
|
||||
## 必须落盘
|
||||
|
||||
全部轮次结束后，输出一张决策表写入 `docs/pm/<项目>/research/1a-需求文档.md`：
|
||||
|
||||
| # | 问题 | 决策 | 来源 | 理由 | 影响范围 |
|
||||
|---|---|---|---|---|---|
|
||||
| Q1 | ... | ... | 用户拍板 / 【假设】 / 【事实】 | ... | 影响哪几份下游文档 |
|
||||
|
||||
「来源」列是本表的关键，一眼看出哪些是用户拍的板、哪些是模型补的。1c 的每条结论都要能追到本表的某一行（或追到 1b 的某份调研文件）。
|
||||
|
||||
这张表是 1b（调研什么）与 1c（方案怎么定）的共同输入，也是②段写那两份文档的输入，不许与已定决策冲突。
|
||||
|
||||
## 反面清单
|
||||
|
||||
- 跳过本子步直接开调研，拿着自己的猜测去查资料
|
||||
- 一轮只问一个问题，浪费轮次
|
||||
- 问用户「你觉得竞品怎么做的」这类你本该自己查的事实
|
||||
- 把依赖未决答案的问题塞进本轮
|
||||
- 一轮抛几十个无编号、无推荐答案的问题，让用户无从下手
|
||||
- 不声明就开问，与 product-planning 的常规节奏冲突
|
||||
- 把自动补全当默认动作，用户没说话就替他决定，还不标 `【假设】`
|
||||
- 标了 `【假设】` 却没进待复核清单，静默流进策略结论
|
||||
- 漏问「交付形态」这一支（2026-09-29 新增）：问完了「做什么、为谁、边界」，却没问「应该有几个界面、价值在哪一层」。后续 ②③ 段会在无形态依据的情况下自行发明结构，做出来的东西被判定为「产品框图」。该支为 A 节必问项
|
||||
- ⛔ 只做 A 节、跳过 B 节（2026-10-06 新增）：B 节是从②段合并来的，跳过它等于把功能压测整个删掉，接口会带着没压测过的需求直接进②段与原型
|
||||
- ⛔ 在 B 节把页面结构写死（2026-10-06 新增）：B 节只给粗粒度形态；精确板块清单与布局归②段
|
||||
- ⛔ 状态行只写「frontier 为空」，把未经确认的模型补全藏在正文（2026-10-02 新增）
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
交付前逐条过。任一条为「否」，退回重跑。
|
||||
|
||||
- [ ] 起点那句（做什么 / 为谁 / 不做什么）已摊开成决策表，写入 `docs/pm/<项目>/research/1a-需求文档.md`
|
||||
- [ ] A 节各分支都问过，其中「交付形态」支问清了「价值主要在哪一层 / 应该有几个界面 / 信息承载到哪一层」
|
||||
- [ ] B 节各分支都问过，状态与不成立条件没有遗漏
|
||||
- [ ] 每轮问题都有编号与推荐答案，依赖未决答案的问题没塞进本轮
|
||||
- [ ] 所有 `【假设】` 都进了待复核清单；状态行同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」，没有单写「frontier 为空」
|
||||
- [ ] 决策表的「来源」列逐行标了 用户拍板 / 【假设】 / 【事实】，1c 的每条结论都能追到某一行
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
# Product Strategy Canvas
|
||||
|
||||
> 本 skill 由模型按需加载，没有斜杠命令。对话里还没定出对象时，先向用户确认，不要自行假设。
|
||||
> 结果写入 `docs/pm/<项目>/<阶段>/<主题>-<类型>.md`，阶段取 `research` / `strategy` / `prd` / `ux`；`<项目>` 是项目 slug，定义见 `product-planning` 的「项目与路径约定」。
|
||||
|
||||
## 这份做什么
|
||||
|
||||
- 名字：product-strategy
|
||||
- 干什么：按九节产品策略画布，给在做的东西写一份产品策略，覆盖愿景、市场切分、相对成本、价值主张、取舍、指标、增长、能力、护城河。
|
||||
- 什么时候用：写产品策略、策略画布、策略文档时。
|
||||
|
||||
## 动手前先有的料
|
||||
|
||||
- 产品是什么、现在什么定位
|
||||
- 市场情况、竞品、用户线索
|
||||
- 手上的资源、约束、优先级
|
||||
- 相关的业务或市场数据
|
||||
|
||||
## 九节画布
|
||||
|
||||
### 1. 愿景
|
||||
|
||||
- 靠什么打动人
|
||||
- 想做成的样子
|
||||
- 坚持什么
|
||||
|
||||
### 2. 市场切分
|
||||
|
||||
- 按人遇到的问题切，不按人口统计切
|
||||
- 用户要办的事（JTBD）、想要的结果、限制条件
|
||||
- 第一拨切给谁
|
||||
- 为什么先切这一拨
|
||||
|
||||
### 3. 相对成本
|
||||
|
||||
- 走低成本（像西南航空），还是走独特价值（像星巴克）
|
||||
- 相对竞品，成本处在什么位置
|
||||
|
||||
### 4. 价值主张
|
||||
|
||||
每个目标切分都写四条：
|
||||
|
||||
- 之前：用户现在的处境、痛点、需求
|
||||
- 怎么做：产品怎么解决
|
||||
- 之后：好成了什么样
|
||||
- 替代：用户今天拿什么凑合
|
||||
|
||||
### 5. 取舍
|
||||
|
||||
- 明确不做什么
|
||||
- 哪些功能、哪些市场不在范围内
|
||||
- 说不，怎么换来聚焦、放大价值
|
||||
|
||||
### 6. 关键指标
|
||||
|
||||
- 北极星指标：带动整体业务的那个指标
|
||||
- OMTM（本季只优化这一个）：这一季盯的那个
|
||||
|
||||
### 7. 增长
|
||||
|
||||
- 销售驱动，还是产品驱动
|
||||
- 主要获客渠道
|
||||
- 怎么放量
|
||||
- 单位经济怎么样
|
||||
|
||||
### 8. 能力
|
||||
|
||||
- 需要哪些本事和资源
|
||||
- 哪些自己做、哪些找伙伴
|
||||
- 要赢，必须练出哪些能力
|
||||
|
||||
### 9. 别人抄不走的地方
|
||||
|
||||
- 竞品为什么不容易抄
|
||||
- 靠什么挡住（网络效应、切换成本、专利）
|
||||
- 新对手要进来，门槛在哪
|
||||
|
||||
## 怎么往下走
|
||||
|
||||
1. 先定愿景，写清它要带来的变化。
|
||||
2. 切出 2–3 个目标市场，写清各自要办的事。
|
||||
3. 定成本位置：走低成本还是高价值。
|
||||
4. 给每个切分写价值主张。
|
||||
5. 列明取舍，写清不做什么。
|
||||
6. 定北极星指标和本季的 OMTM。
|
||||
7. 写增长打法和渠道。
|
||||
8. 记下要具备的能力和要找的伙伴。
|
||||
9. 说清护城河和门槛。
|
||||
10. 回头查九节自洽：各部分互相撑得住。
|
||||
11. 挑出「必须成立才能赢」的关键假设，并给出用最小成本去验的办法。
|
||||
|
||||
## 注意
|
||||
|
||||
- 九节要能自洽，互相撑得住。
|
||||
- 策略用来做决策，讲清楚才落得快。
|
||||
- 市场变了就回头重看，按季度。
|
||||
|
||||
### 模板
|
||||
|
||||
- [Product Strategy Canvas (PPTX)](https://docs.google.com/presentation/d/1xRBqSOISvAKzwM_z5tC8fiuO5O2YhboB/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true)
|
||||
|
||||
### 延伸阅读
|
||||
|
||||
- [Product Strategy Canvas: From Vision to Action](https://www.productcompass.pm/p/product-strategy-canvas)
|
||||
- [Product Strategy Examples: Google Maps, Netflix, OpenAI](https://www.productcompass.pm/p/product-strategy-examples)
|
||||
- [Product Vision vs Strategy vs Objectives vs Roadmap: The Advanced Edition](https://www.productcompass.pm/p/product-vision-strategy-goals-and)
|
||||
- [Product Model First Principles: Product Team and Product Strategy In Depth](https://www.productcompass.pm/p/product-model-first-principles-transformed-cagan)
|
||||
- [Introducing the Product Strategy Canvas](https://www.productcompass.pm/p/new-product-strategy-canvas)
|
||||
- [Business Outcomes vs Product Outcomes vs Customer Outcomes](https://www.productcompass.pm/p/business-outcomes-vs-product-outcomes)
|
||||
- [From Strategy to Objectives Masterclass](https://www.productcompass.pm/p/product-vision-strategy-objectives-course) (video course)
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
- [ ] 九节都有内容，且互相自洽
|
||||
- [ ] 市场按要解决的问题切，不按人口统计切
|
||||
- [ ] 每个目标切分都写了价值主张四条（之前 / 怎么做 / 之后 / 替代）
|
||||
- [ ] 取舍一节写明了「不做什么」
|
||||
- [ ] 北极星指标和本季 OMTM 各一个
|
||||
- [ ] 挑出了「必须成立才能赢」的关键假设
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
# 使用场景（1c · 就是用户故事）
|
||||
|
||||
> 2026-10-06 用户定案：「使用场景 就是 用户故事 按照用户如何使用解决什么问题来梳理」。
|
||||
> 旧结构（处境 / 现在怎么凑合 / 不用会用什么 三段式）已弃用，改成用户故事格式。
|
||||
>
|
||||
> 沿革：`value-proposition.md`（六段式）→ 2026-10-02 改称「使用场景」（三段式）→ 2026-10-06 改为用户故事格式。
|
||||
|
||||
---
|
||||
|
||||
## 一、格式（唯一句式）
|
||||
|
||||
每条场景写一句，四个槽位都要有：
|
||||
|
||||
```
|
||||
作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】
|
||||
```
|
||||
|
||||
| 槽位 | 写什么 | 不许写什么 |
|
||||
|---|---|---|
|
||||
| 作为【谁】 | 一个具体身份（此刻的我 / 要交差的我 / 三个月后回来的我）。不写「用户」「某类人」 | 人群标签、画像分类名 |
|
||||
| 当【什么处境】 | 触发这件事的具体时刻与场合，要能被观察，或被用户原话印证 | 「经常会」「有时候」这类模糊频率 |
|
||||
| 我要【办成什么】 | 用户要达成的事，用用户的词写 | 功能名、按钮名、页面名 |
|
||||
| 这样【得到什么结果】 | 办成之后少掉了什么麻烦（少花时间 / 少出错 / 不用记） | 愿景、North Star、「改成什么样」 |
|
||||
|
||||
### ⭐ 一句话判据：能不能读给用户听
|
||||
|
||||
把这条场景原样念给用户听，他点头说「对，就是这样」，就算成立；
|
||||
他说「也不是…」或听不懂，就重写。听不懂通常是因为槽位里混进了功能名。
|
||||
|
||||
## 二、它跟②段的关系
|
||||
|
||||
《使用场景》是②段功能清单的直接推导依据。
|
||||
|
||||
- ②段每列一项功能，都要能追回本份的某一条场景。追不回的，那条功能没由来，②段该砍。
|
||||
- ②段按使用场景梳理功能（一条场景下的功能可能跨好几个页面），并标优先级。
|
||||
- 反向也成立：本份某条场景在②段一条功能都推不出来，就是空愿望 —— 要么补功能，要么删场景。
|
||||
|
||||
> 本份就是用户故事，一份承载全部。
|
||||
> 不写验收标准（那是②段功能清单的事），不写 Design / 交互（那是③段）。
|
||||
|
||||
## 三、⛔ 四条硬禁令
|
||||
|
||||
### 1. 不许凭空打分
|
||||
|
||||
Importance / Satisfaction / Score / 优先级分数，没有数据源就不许出现。
|
||||
|
||||
> 来源：本项目实测。分数一旦填进去，会一路传到下游的功能优先级，所以判断就写成判断，不要伪装成数。
|
||||
> ✅ 正确写法：`【判断】我改错了回不去（依据：`1a-需求文档.md` Q1 用户原话）` —— 把来源标出来，不假装是数。
|
||||
|
||||
### 2. 不许写「改成什么样」
|
||||
|
||||
愿景、North Star、「最终形态」不在本段。
|
||||
|
||||
理由只有一条：愿景不可核，而且它天然会往界外长 —— 长成「要做哪些功能」就到②段了。
|
||||
|
||||
### 3. 不许写功能名与界面
|
||||
|
||||
不许在「我要办成什么」里写功能名；不许写「页面放哪几块」「怎么跳转」「要不要侧区」。
|
||||
|
||||
本段只给用户视角的处境与诉求：谁、什么时候、想办成什么、办成了少什么麻烦。
|
||||
|
||||
### 4. 不许把「处境」写成抽象人群
|
||||
|
||||
「处境」要具体到能被观察，或被原话印证。
|
||||
|
||||
- ❌「需要频繁回退版本的用户」
|
||||
- ✅「改错了想退回去，但记不清是哪个版本的时候」
|
||||
|
||||
## 四、边界（防越界的对照）
|
||||
|
||||
- 场景归①段本份；②段按它梳理功能，不重写场景（重写必打架）。
|
||||
- 不写功能清单（那是②段 2a）。
|
||||
- 不写界面结构 / 板块布局（那是②段的《界面布局》与③段 D0）。
|
||||
|
||||
## 五、旧三段式的残留价值（别丢）
|
||||
|
||||
旧结构里的三段不是废料，内容改挂到新格式的槽位里：
|
||||
|
||||
| 旧段 | 挂到哪 |
|
||||
|---|---|
|
||||
| 处境（Why） | → **「当【什么处境】」** 槽位 |
|
||||
| 现在怎么凑合（What Before） | → **「这样【得到什么结果】」的反面**：现在凑合着做，多付了什么 |
|
||||
| 不用会用什么（Alternatives） | → **「得到什么结果」的对照**：不用它，用户会退回到哪个替代办法 |
|
||||
|
||||
> ⭐ 替代方案那一问仍然最有杀伤力（2026-10-02 整合自外部 `sharp-problem-test`）：如果替代方案「简单到不值一提」，那这个问题就不值得做。
|
||||
> ⚠️ 只作提问，不作判死。绝大多数真实需求都能被编出一个 trivial 替代（「不用不就行了」），做成硬判据会大量误杀。
|
||||
> ✅ 三个可接受的「不简单」的证明，满足任一即过：① 替代方案有真实成本（时间 / 钱 / 出错）；② 替代方案不可得（外部没有，要自建）；③ 替代方案代价随规模增长（手动做十个还行，一百个就崩）。
|
||||
> ⭐ 本项目实测印证：`11-竞品分析.md` 的 GitLab 案例，被砍的官方理由是「维护成本超过实际使用量」。落到判据上，真正卡住它的是「成本会不会随规模涨」，光是「简单」本身不构成问题。
|
||||
|
||||
## 六、每条的完成判据（可机械核对）
|
||||
|
||||
| 检查项 | 判据 |
|
||||
|---|---|
|
||||
| 四槽位齐全 | 「作为 / 当 / 我要 / 这样」四个词都在，缺一不算完成 |
|
||||
| 谁 | 是具体身份，不是「用户」「某人」 |
|
||||
| 处境 | 能追到 `1a-需求文档.md` 的某一行，或一句用户原话；追不到的按 `【判断】` 标并说明依据 |
|
||||
| 办成什么 | 零功能名（出现功能名即越界到②段） |
|
||||
| 得到什么 | 写的是少掉的麻烦，不是愿景 |
|
||||
| 可读性 | 能原样念给用户听而不需要解释 |
|
||||
|
||||
## 七、产出
|
||||
|
||||
`docs/pm/<项目>/strategy/31-使用场景.md`
|
||||
|
||||
> ⚠️ 与旧产物的关系：现有 `31-使用场景.md` 是旧三段式（处境 S-A/S-B/S-C + What Before 五条 + Alternatives 五条）。
|
||||
> 改格式后旧产物需重写（把三段内容按§5 映射表挂进四槽位），不许两种格式并存。
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
- [ ] 每条场景四个槽位齐全（作为 / 当 / 我要 / 这样），缺一不算完成
|
||||
- [ ] 「谁」是具体身份，不是「用户」「某类人」
|
||||
- [ ] 「处境」能追到 `1a-需求文档.md` 的某一行，或一句用户原话
|
||||
- [ ] 「办成什么」里零功能名
|
||||
- [ ] 「得到什么」写的是少掉的麻烦，不是愿景
|
||||
- [ ] 每条场景能原样念给用户听，不需要解释
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# User Personas
|
||||
|
||||
> 本 skill 由模型按需加载，没有斜杠命令。对话里还没定出对象时，先向用户确认，不要自行假设。
|
||||
> 结果写入 `docs/pm/<项目>/<阶段>/<主题>-<类型>.md`，阶段取 `research` / `strategy` / `prd` / `ux`；`<项目>` 是项目 slug，定义见 `product-planning` 的「项目与路径约定」。
|
||||
|
||||
## 这份做什么
|
||||
|
||||
从调研数据里做出能用的用户画像，覆盖用户真实的差异。画像要有数据撑：要办的事、痛点、想要的结果，再加一条和直觉相反的发现，用来指导产品决策。
|
||||
|
||||
## 怎么做
|
||||
|
||||
### 输入
|
||||
|
||||
针对在做的东西，做 3 个用户画像。
|
||||
|
||||
用户给了 CSV、Excel、问卷、访谈记录或其他资料，就直接读、直接分析：提炼其中的规律、人群特征、动机和行为。
|
||||
|
||||
### 分析步骤
|
||||
|
||||
1. 收资料：把手上所有调研资料和文档读一遍。
|
||||
2. 找规律：找出反复出现的特征、目标、痛点、行为。
|
||||
3. 分组：按动机和「要办的事」相近的，归成一个个画像。
|
||||
4. 补细节：给每个画像攒出一份像样的画像。
|
||||
5. 校验：回头对照，确保每个画像都能落在真实调研发现上。
|
||||
|
||||
### 每个画像写这几块
|
||||
|
||||
3 个画像，每个都要有：
|
||||
|
||||
姓名和基本信息：年龄段、角色或职位、公司规模（B2B 才有）、关键特征。
|
||||
|
||||
主要「要办的事」：这个人想达成的核心结果；这件事在什么处境下、多久做一次。
|
||||
|
||||
三条主要痛点：挡住他办成事的具体障碍；每条影响多大。
|
||||
|
||||
三个想要的结果：他想要的收益或结论；他怎么衡量成功。
|
||||
|
||||
一条和直觉相反的发现：从数据里看出来的、意料之外的行为或动机；它为什么影响产品决策。
|
||||
|
||||
产品契合度：在做的东西怎么接住（或接不住）这个人的需求；有哪些摩擦点或没满足的地方。
|
||||
|
||||
## 几条要求
|
||||
|
||||
- 所有结论都落在真实数据上，不猜。
|
||||
- 有原话就引原话。
|
||||
- 看行为规律，不只看人口统计。
|
||||
- 画像之间尽量分清、不重叠。
|
||||
- 数据缺口或还要再查的地方，标出来。
|
||||
|
||||
### 延伸阅读
|
||||
|
||||
- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
|
||||
- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques)
|
||||
- [Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar](https://www.productcompass.pm/p/jobs-to-be-done-masterclass-with) (video course)
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
- [ ] 做了 3 个画像
|
||||
- [ ] 每个画像都有姓名与基本信息、主要「要办的事」、三条主要痛点、三个想要的结果、一条和直觉相反的发现、产品契合度
|
||||
- [ ] 每条结论都落在真实数据上，不猜
|
||||
- [ ] 有原话的地方引了原话
|
||||
- [ ] 画像之间分清、不重叠
|
||||
- [ ] 数据缺口标了出来
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: stage-proto-doc
|
||||
description: 产品规划第④段，原型说明文档。在已交付的原型 HTML 上补说明区：每个界面状态下方按「状态 → 使用场景 → 从左到右流程图 → 步骤说明（功能作用 / 输入边界 / 异常情况）」铺开，并给每条流程配逐步骤的演示引导。当用户要给原型加功能说明区、写原型说明文档、做操作指引演示，或说"只做原型说明文档"时调用。
|
||||
---
|
||||
|
||||
# ④ 原型说明文档
|
||||
|
||||
回答"每个状态有哪些场景、每个场景怎么走、每一步到底做什么、边界在哪、坏了会怎样"。
|
||||
|
||||
产出长在原型 HTML 自身（`designs/<项目>/*.html`），不额外落 md，免得两处维护、说法对不上。
|
||||
|
||||
顺序 4a → 4b → 4c。说明区先齐，再挂演示引导。
|
||||
|
||||
> 表格「读」列是该方法论文档，相对路径的基准是本 skill 目录。执行子步前先读它。
|
||||
|
||||
## 输入
|
||||
|
||||
| 来自 | 读什么 | 用来定什么 |
|
||||
|---|---|---|
|
||||
| ③ | `designs/<项目>/*.html` | 要挂说明区的原型本体；状态数与状态名以它为准 |
|
||||
| ② | `docs/pm/<项目>/prd/2a-产品功能.md` · `docs/pm/<项目>/prd/2b-界面布局.md` | 术语口径、状态流转、异常路径、页面骨架 |
|
||||
| ① | `docs/pm/<项目>/strategy/30-产品策略.md` | "不做什么"的边界，说明区不得写出范围外的能力 |
|
||||
|
||||
上游缺失时标 `【假设】`继续，不强制回补。
|
||||
|
||||
## 4a 场景盘点
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 状态 × 场景盘点（必做，最先） | `references/doc-area-spec.md` | 每个界面状态下的使用场景清单 |
|
||||
|
||||
每个状态都要盘（正常态 / 加载中 / 空态 / 加载失败），不许只写正常路径。
|
||||
场景粒度是"人要完成的一件事"，不是"一个按钮"。典型一条：拿到一批数据 → 判一条 → 遇到没跑完的怎么办 → 批量的影响范围 → 筛不到东西时。
|
||||
|
||||
## 4b 说明区
|
||||
|
||||
读 `references/doc-area-spec.md`，按它给的层级与交互铺：
|
||||
|
||||
1. 说明区挂在原型各状态的下方，随演示条切换的状态一起变
|
||||
2. 每个场景一条：可点开，点开后是该场景的从左到右流程图（序号节点 + 箭头）
|
||||
3. 点流程里的某一步，在流程图下方出该步说明，固定三段：功能作用 / 输入边界 / 异常情况
|
||||
4. 同级单开：一次只展开一个场景、一次只选中一个步骤；再点已选中的步骤即收起
|
||||
|
||||
三段缺一不可，且必须是对着原型实测过的事实，不是套话：
|
||||
|
||||
| 段 | 写什么 | 判定标准（可核对） |
|
||||
|---|---|---|
|
||||
| 功能作用 | 这个组件做什么、给谁看、落笔后产生什么 | 换一个组件，这句话就不成立 |
|
||||
| 输入边界 | 取值域 / 上限 / 前置条件 / 可选与必填 | 能说出"什么不被接受"或"最多几条" |
|
||||
| 异常情况 | 失败 / 空 / 禁用 / 重复提交 / 文案红线 | 至少覆盖一种"坏了怎么办"，且给出恢复路径 |
|
||||
|
||||
## 4c 演示引导
|
||||
|
||||
读 `references/guided-tour.md`，给每条流程挂"演示"按钮：
|
||||
|
||||
1. 每个步骤补三样数据：`target`（要高亮的选择器）、`setup`（这一步的前置条件）、`hint`（操作指引，与功能说明 `desc` 分开写）
|
||||
2. 演示按 `上一步 / 下一步 / 完成` 逐步骤推进，气泡给"第 N / M 步"
|
||||
3. 纯概念步骤不给 target，不参与演示，按钮置灰并写明原因
|
||||
|
||||
## 硬约束
|
||||
|
||||
- 说明区是非产品功能，它是原型的自解释注解层。交付时要明说，别让人误以为产品里真有一个说明页。
|
||||
- 只有原型上有的事实才许写。每一段说明都要能在原型里点到对应元素；写不出 `target` 的步骤，要么承认是概念步骤，要么回去改原型。
|
||||
- 不得把自动结论表述为人工认可（红线，本项目实测抓过）：机器判定只能说"进入队列 / 待人工逐条查看"，不许写成"通过 / 已认可"。
|
||||
- 文案口径跟②段走。同一个概念在说明区与②段里必须同名，冲突时改说明区。
|
||||
- 4c 交付前必须浏览器实测，逐步骤真点一遍，走完全流程再退出。未跑实测不得报完成。
|
||||
- 段内子步之间不反问，做完直接进下一个子步。只有三种情况停：信息不足且查不到、破坏性/不可逆动作、用户显式要求（见 `product-planning` 的「执行规则」）。
|
||||
- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- 原型的每个状态都有场景，四态齐备（缺哪个要写明为什么）
|
||||
- 每个场景有从左到右流程图，每个步骤都有 `功能作用 / 输入边界 / 异常情况` 三段且非空
|
||||
- 演示引导能从第一步走到完成，退出后界面回到演示前（含筛选、抽屉）
|
||||
- 有实测回报（走过的步骤数、失败项、控制台报错原文）
|
||||
|
||||
## 反面清单
|
||||
|
||||
- 只写正常路径，跳过加载 / 空 / 错误三个状态的说明
|
||||
- 三段说明写成语义重复的三句话，或整段是"该功能可以提升效率"这类空话
|
||||
- 把演示引导做成遮罩弹窗，挡住它要教人点的那个东西
|
||||
- 演示中途改动了用户的筛选 / 抽屉，退出后不还原
|
||||
- 概念步骤硬凑一个 target，或演示到一半被判"元素不可见"直接结束
|
||||
- 只写说明区就报完成，没跑过逐步骤实测（自查看不出死按钮）
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
# 原型说明区规范
|
||||
|
||||
> 本文件是 `stage-proto-doc` 的方法论文档，由模型按需加载，没有斜杠命令。
|
||||
|
||||
## 定位
|
||||
|
||||
说明区是原型自带的注解层，不是产品功能。它不回答"长什么样"，回答的是：
|
||||
|
||||
> 站在这个界面上，我这一步在干什么、我能输入什么、什么情况下它不给好脸色。
|
||||
|
||||
所以它必须贴在原型各状态的下方，随状态切换一起变。抽出来写一份独立文档，读者就得自己脑补对应关系。
|
||||
|
||||
## 层级
|
||||
|
||||
```
|
||||
状态（正常态 / 加载中 / 空态 / 加载失败）
|
||||
└── 使用场景（人要完成的一件事，可点开）
|
||||
├── 场景引言（一句话：什么前提下、要达成什么）
|
||||
├── 从左到右的流程图（序号节点 + 箭头，横向可滚动）
|
||||
└── 步骤说明（点某一步 → 在流程图下方出三段）
|
||||
├── 功能作用
|
||||
├── 输入边界
|
||||
└── 异常情况
|
||||
```
|
||||
|
||||
四层各管一段：状态说"界面此刻处于什么处境"，场景说"人在这个处境下想干成什么"，流程说"这件事分几步走"，步骤说明说"这一步的职责与边界"。少任何一层，读者都会拿别层的信息去补，然后补错。
|
||||
|
||||
## 场景怎么写
|
||||
|
||||
- 粒度是"人要完成的一件事"，不是一个按钮。"提交驳回"不算场景，"驳回一条片段并完成失败模式归类"才算。
|
||||
- 一个状态下的场景数控制在 2–4 个。1 个说明不了分支，5 个以上就该拆状态。
|
||||
- 顺序按发生频率排，不按界面从上到下排。
|
||||
- 引言一句话写清前提。例："预审排队、执行中或失败时人工仍可决策，但必须清楚自己在无依据的情况下决策。"
|
||||
|
||||
## 从左到右流程图
|
||||
|
||||
| 规则 | 说明 |
|
||||
|---|---|
|
||||
| 形态 | 横向 `ol`，每项 = 序号圆点 + 步骤名，项间一个 `→` 箭头 |
|
||||
| 溢出 | 横向滚动，不换行——换行会读成两条并行流程 |
|
||||
| 交互 | 点步骤 → 流程图下方出说明；再点收起；同级只选中一个 |
|
||||
| 键盘 | 步骤是 `button`；`aria-current` 标当前项；说明区 `role="region"` 带 `aria-controls` |
|
||||
| 箭头 | `aria-hidden`，它只是视觉连接符，不进朗读 |
|
||||
|
||||
步数控制在 2–6 步：超过 6 步说明这个场景该拆，1 步说明它还不算流程。
|
||||
|
||||
## 步骤说明：三段
|
||||
|
||||
三段是固定骨架，不改名、不合并、不省段。
|
||||
|
||||
| 段 | 回答的问题 | 合格判据 | 不合格示例 |
|
||||
|---|---|---|---|
|
||||
| 功能作用 | 这一步做什么、给谁看、落笔后产生什么 | 换一个组件这句话就不成立 | "展示相关信息，提升审核效率" |
|
||||
| 输入边界 | 取值域 / 上限 / 前置条件 / 必填与选填 | 说得出"什么不被接受"或"最多几条" | "支持筛选" |
|
||||
| 异常情况 | 失败 / 空 / 禁用 / 重复提交 / 恢复路径 / 文案红线 | 至少一种"坏了怎么办"，且给出出路 | "暂不支持" |
|
||||
|
||||
写输入边界，常见切入点：数量上限、字数或时长范围、哪些状态才可用、必填项有哪些、一次作用于一条还是全部。
|
||||
写异常情况，常见切入点：加载中能不能点、失败了怎么重试、重复提交怎么挡、空的时候显示什么、禁用要不要给原因、文案不能写成什么。
|
||||
|
||||
### 文案红线
|
||||
|
||||
- 不得把自动结论表述为人工认可。机器判定只能说"进入队列 / 待人工逐条查看"，不写成"通过 / 已认可 / 已确认"。
|
||||
- 不用无法区分成因的笼统文案。"暂无数据"要拆成"批次为空"与"筛选无结果"两条出路。
|
||||
- 不承诺原型里点不出来的能力。说明区每条都要能在原型上指到对应元素。
|
||||
- 异常态必须给恢复路径。只写"失败了"不算说明，要写清楚下一步按哪里。
|
||||
|
||||
## 状态标签与联动
|
||||
|
||||
说明区顶部常驻一行"当前状态：xxx"，与演示条的状态同源。读者就不会拿正常态的说明去套加载态的行为。
|
||||
|
||||
## 自查（逐条打勾）
|
||||
|
||||
- [ ] 四个状态都有场景，缺的写明原因
|
||||
- [ ] 每个状态 2–4 个场景，每个场景 2–6 步
|
||||
- [ ] 每步三段齐全，且各自能通过上面的合格判据
|
||||
- [ ] 全文没有"通过 / 已认可"这类把机器结论说成人审的词
|
||||
- [ ] 每个禁用态都给了原因，每个异常态都给了恢复路径
|
||||
- [ ] 说明区文案与②段术语逐词一致
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
# 演示引导（操作指引）
|
||||
|
||||
> 本文件是 `stage-proto-doc` 的方法论文档，由模型按需加载，没有斜杠命令。
|
||||
|
||||
## 它是什么
|
||||
|
||||
说明区把流程写清楚了，读者仍要自己在界面上找——"这条筛选在左栏还是顶栏？"
|
||||
|
||||
演示引导在真界面上按步骤带一遍：点流程的「演示」，高亮框住这一步该动的元素，气泡给操作指引，`上一步 / 下一步` 推进，`完成` 收尾。
|
||||
|
||||
它同样是原型的注解层，不是产品功能。交付时要明说，不能让人以为产品里真有一个新手引导。
|
||||
|
||||
## 数据契约
|
||||
|
||||
每个步骤在原有字段外必须补三样，缺一样就演示不了：
|
||||
|
||||
| 字段 | 作用 | 注意 |
|
||||
|---|---|---|
|
||||
| `target` | 要高亮的选择器 | 必须是当前状态下真实存在且可见的元素；纯概念步骤不给 `target` |
|
||||
| `setup` | 这一步的前置条件 | 例：切到某条片段、填入某关键词、打开某抽屉。浮层类 setup 必须在设 `target` 之前执行，否则量不到 |
|
||||
| `hint` | 操作指引：手该往哪放 | 与 `desc` 分开写。`desc` 回答"这是什么"，`hint` 回答"你要点哪"；两处写一样等于没写 |
|
||||
|
||||
演示可用的步骤数 = 有 `target` 的步骤数。全场景没有可演示步骤时，按钮置灰并写明原因，不是点了没反应。
|
||||
|
||||
## 单步的执行顺序（照抄这个顺序）
|
||||
|
||||
1. 收掉上一次留下的浮层（抽屉 / 弹窗 / 放大层），把临时筛选复位
|
||||
2. 应用本步 `setup`（切片段 → 重渲染 → 填筛选 → 开抽屉）
|
||||
3. 把说明区同步选中到这一步，并展开它所在场景
|
||||
4. 记下 `target`，滚动到它可见处
|
||||
5. 画高亮环与气泡，起重绘定时器
|
||||
6. 播报"第 N 步 + 操作指引"
|
||||
|
||||
顺序错了就会出现"抽屉还没露出来就去量它"这类问题。
|
||||
|
||||
## 实测踩过的坑
|
||||
|
||||
### 1. 一次性测量一定过期 → 必须幂等重绘
|
||||
|
||||
量一次目标元素的位置就画环，过一会儿环会错位。实测数据：同一个元素在首帧后仍在变，宽度 `303.33 → 318.67`、顶部 `0.15 → -11.85`（页面滚动量恒定，是滚动条出现/消失带来的回流）。
|
||||
|
||||
做法：定时器（约 120ms）反复调用重绘函数，函数幂等——每次重新量、重新画；用几何 key（`left/top/width/height` 取整拼串）去重，没变就直接返回，避免无意义的重排。
|
||||
|
||||
别用 `scroll` / `resize` 监听代替定时器：滚动过程中环会滞后，元素自身回流也不触发这两个事件。
|
||||
|
||||
### 2. 浮层的可见性过渡会误杀演示
|
||||
|
||||
抽屉这类浮层的 `visibility` 会参与 `transition`，`data-open="true"` 之后约 200ms 内 `getComputedStyle().visibility` 仍是 `hidden`，判定函数返回"不可见"。这时直接结束演示，用户会看到"演示刚开始就自己关了"。
|
||||
|
||||
做法：给约 2 秒的容错窗口——不可见时先重试，超时才判定失败并给出原因。定时器天然负责重试。
|
||||
|
||||
### 3. 高亮环不要加 transition
|
||||
|
||||
环的几何每 120ms 重画一次，再加过渡会互相打架：出现拖影，几何断言永远对不上。要让环动起来，靠重绘频率，不靠 CSS 过渡。
|
||||
|
||||
### 4. 挖空遮罩用大 spread 的 box-shadow
|
||||
|
||||
一个 `position: fixed` 的环 + `box-shadow: 0 0 0 9999px rgba(0,0,0,.45)` 就是"四周压暗、中间挖空"，实测可用（用像素采样验证过：#F7F6F3 的底色被压到约 `(144,143,141)`）。
|
||||
|
||||
不要为此改成 `clip-path: polygon(...)`——单个 `polygon()` 是一条自相交多边形，不是多个子路径，想挖洞得用 `path()`。能用一行阴影解决就别引这条坑。
|
||||
|
||||
### 5. 退出要成对处理：收浮层 + 还原现场
|
||||
|
||||
演示会临时改筛选关键词、开抽屉。退出时只隐藏浮层，这些临时态会留给用户。做法：启动时快照当前筛选与关键词，退出时反向还原，再统一重渲染。
|
||||
|
||||
顺序有讲究：先关浮层，后清 `tourOn` 标记。关闭浮层会触发焦点归还逻辑，标记还在时它会被守卫拦住，不会把焦点从用户手上抢走。
|
||||
|
||||
### 6. 键盘与边界
|
||||
|
||||
| 场景 | 行为 |
|
||||
|---|---|
|
||||
| `ESC` | 退出演示（演示进行中优先于"关闭顶层浮层"） |
|
||||
| 演示进行中按全局快捷键（`j/k/a/r` 等） | 一律屏蔽，否则按 `j` 会切走当前片段，演示当场跑偏 |
|
||||
| 演示中切换界面状态 | 自动结束演示并播报原因（说明区内容已随状态换掉，会讲错） |
|
||||
| 焦点 | 演示中不抢焦点；浮层用 `aria-modal="false"`，因为它是注解层不是模态框 |
|
||||
| 进度文案 | 气泡常驻"第 N / M 步 + 场景名"，末步按钮文案改「完成」 |
|
||||
|
||||
### 7. 视觉断言要用像素采样，不要看缩略图
|
||||
|
||||
看截图判断颜色 / 遮罩 / 选中态会误判——缩略图渲染会改变颜色与对比，看出来的"遮罩没生效""高亮与说明不一致"经常是假象。
|
||||
|
||||
做法：颜色 / 遮罩 / 选中态这类断言，用 `PIL` 取区域均值或点采样来判，别靠肉眼。
|
||||
|
||||
## 交付前实测清单
|
||||
|
||||
- [ ] 每个有 `target` 的步骤都能从「演示」走到「完成」，无中途自动结束
|
||||
- [ ] 每一步的高亮环都框住目标元素（框住 = 环矩形与目标矩形在各边差相等）
|
||||
- [ ] 抽屉类步骤：环确实画在抽屉上，且退出后抽屉被收起
|
||||
- [ ] 退出后筛选 / 关键词回到演示前的值
|
||||
- [ ] 演示中按全局快捷键不改变界面
|
||||
- [ ] 切换界面状态时演示自动结束并播报
|
||||
- [ ] 纯概念步骤不参与演示，按钮置灰且有原因
|
||||
- [ ] 全程无控制台报错（异常事件数 = 0）
|
||||
+162
@@ -0,0 +1,162 @@
|
||||
---
|
||||
name: stage-requirements
|
||||
description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。
|
||||
---
|
||||
|
||||
# ② 产品功能
|
||||
|
||||
回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份：
|
||||
`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。
|
||||
|
||||
> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。
|
||||
>
|
||||
> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。
|
||||
>
|
||||
> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。用户原话：「不需要 就用使用场景，其余6分都不需要了，grill 也应该拿到第一步了，第二部就是细化功能」。
|
||||
>
|
||||
> 本段就这两份：`prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。
|
||||
>
|
||||
> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。
|
||||
>
|
||||
> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`）
|
||||
|
||||
## ⭐⭐ ②—③ 交接口（2026-10-06 用户定案）
|
||||
|
||||
口径：②段钉骨架，③段做皮肉。
|
||||
|
||||
| 归②段（必须在本段确认） | 归③段（⛔ 不许②段写） |
|
||||
|---|---|
|
||||
| 有哪几页 | 配色 |
|
||||
| 每页几个板块 | 字体 |
|
||||
| 板块怎么排 | 间距 |
|
||||
| 跨页关系（怎么跳转） | 组件样式 |
|
||||
| 每页的主操作是什么 | 动效 |
|
||||
| 每条信息在哪一档承载（主屏常驻 / 可点入） | 具体的视觉实现 |
|
||||
|
||||
> 用户原话：「3 是负责设计和交互，**页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子**」。
|
||||
> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。
|
||||
> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改（见 `stage-delivery` 的对应禁令）。
|
||||
|
||||
## 本段职责（2026-10-06 按「只细化功能」重划）
|
||||
|
||||
本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）：
|
||||
|
||||
| 问 | 内容 | 落点 |
|
||||
|---|---|---|
|
||||
| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` |
|
||||
| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` |
|
||||
|
||||
> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 26 条功能定义全在②段、一条不在 research。
|
||||
> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。
|
||||
> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能挂跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。
|
||||
|
||||
## 2a 产品功能
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 2a 产品功能 | `references/create-prd.md` | `docs/pm/<项目>/prd/2a-产品功能.md` |
|
||||
|
||||
回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。
|
||||
|
||||
## 2b 界面布局
|
||||
|
||||
| 子步 | 读 | 产出 |
|
||||
|---|---|---|
|
||||
| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `docs/pm/<项目>/prd/2b-界面布局.md` |
|
||||
|
||||
回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。
|
||||
|
||||
> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。
|
||||
> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。
|
||||
|
||||
### 功能清单怎么组织（逐条可核）
|
||||
|
||||
每个功能条目必须带齐这几样：
|
||||
|
||||
| 字段 | 写什么 | 判据 |
|
||||
|---|---|---|
|
||||
| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 |
|
||||
| 来自哪条场景 | 追回①段《使用场景》（`1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 |
|
||||
| 优先级 | P0 / P1 / P2 | 见下方「优先级」 |
|
||||
| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 |
|
||||
| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 |
|
||||
| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 |
|
||||
|
||||
优先级（⛔ 不许凭空打分，见硬约束）：
|
||||
- P0：不做则①段某条使用场景整条办不成
|
||||
- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步）
|
||||
- P2：不做不影响场景办成，只是更好用
|
||||
|
||||
> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。
|
||||
|
||||
### 2b 界面布局怎么写
|
||||
|
||||
本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。
|
||||
|
||||
| 问 | 回答 | 内容 |
|
||||
|---|---|---|
|
||||
| 页面关系 | 有哪几页、门开在哪 | 页面清单、页面流转、导航 |
|
||||
| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） |
|
||||
|
||||
> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。
|
||||
> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。
|
||||
> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。配色 / 字体 / 间距 / 组件样式 / 动效，本段（含布局）仍不许写。
|
||||
> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。
|
||||
|
||||
## 硬约束
|
||||
|
||||
- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。
|
||||
- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。
|
||||
- ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。
|
||||
- ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。
|
||||
- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期悬挂。
|
||||
- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。
|
||||
- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。
|
||||
- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。
|
||||
- ⭐ 状态挂不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。
|
||||
- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给出 —— 页面清单 ＋ 页面流转 ＋ 每页板块清单与排列 ＋ 每页主操作 ＋ 每条信息在「主屏常驻 / 可点入」哪一档。⛔ 缺任何一样，③段就没有方向。
|
||||
- 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。
|
||||
- ⛔ 本段（含布局）不许写视觉：配色 / 字体 / 间距 / 组件样式 / 动效，一个字都不许出现。
|
||||
- 段内不反问，做完直接往下走。只有四种情况停：信息不足且查不到、破坏性 / 不可逆动作、用户显式要求、①段末的方案确认（仅「方案确认」模式，见 `product-planning` 的「执行规则」）。
|
||||
- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`）
|
||||
- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」）
|
||||
- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0
|
||||
- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内
|
||||
- 《界面布局》给全五样：页面清单 ＋ 页面流转 ＋ 每页板块与排列 ＋ 每页主操作 ＋ 每条信息的分档（含判据回答）
|
||||
- ⛔ 全文零视觉词（配色 / 字体 / 间距 / 组件样式 / 动效）
|
||||
- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注
|
||||
- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段
|
||||
- ⭐ 两份都过了「说人话」内容准则（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50）—— 口径见 `product-planning` 的「执行规则」内容准则条；段末报告须写明「已过内容准则，评分 X/50」
|
||||
|
||||
## 反面清单
|
||||
|
||||
- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能
|
||||
- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判）
|
||||
- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档）
|
||||
- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写）
|
||||
- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上
|
||||
- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据
|
||||
- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目
|
||||
- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数
|
||||
- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍）
|
||||
- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样
|
||||
- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」
|
||||
- 状态流转只画正常路径，不管失败与并发；或状态挂不到任何功能条目上（凭空中间态）
|
||||
- ⛔ 在本段写视觉（配色 / 字体 / 间距 / 组件样式 / 动效）—— 那是③段
|
||||
- 越界去出原型或写说明文档（那是第③④段）
|
||||
- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态
|
||||
- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远挂着
|
||||
- ⛔ 两份没过「说人话」内容准则就落盘（带 AI 腔：夸张意义 / 三段式强凑 / 破折号滥用 / 模糊归因 / 通用乐观结尾）—— 门槛 ≥45/50，见 `product-planning` 的「执行规则」内容准则条
|
||||
- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条
|
||||
|
||||
## 本段读什么、守什么
|
||||
|
||||
- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。
|
||||
- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。
|
||||
- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。
|
||||
|
||||
📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。
|
||||
+133
@@ -0,0 +1,133 @@
|
||||
# Create a Product Requirements Document（②段专用版）
|
||||
|
||||
> 本文件由模型按需加载，没有斜杠命令。
|
||||
> 产出：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）。
|
||||
> ②段是两份：功能清单归本份，页面骨架归 `prd/2b-界面布局.md`，不归本份。
|
||||
>
|
||||
> ⭐ 2026-10-06 用户定案改版：本段收窄为「只细化功能」，产出从 7 份收成 1 份。
|
||||
> 上游的 8 段式模板（Summary / Contacts / Market Segment / Value Proposition / Release…）大部分已不适用 —— 它是给「面向市场、要售卖、有干系人」的产品写的；本项目与同类单机自用 / 工具型产品没有这些内容，硬填就是编。保留的部分见下。
|
||||
|
||||
## 本②段写两件事
|
||||
|
||||
| # | 写什么 | 判据 |
|
||||
|---|---|---|
|
||||
| 一 | 功能清单 —— 做哪些、不做哪些、每条什么优先级 | 每条能追回①段《使用场景》（`1e-使用场景.md`） |
|
||||
| 二 | 界面布局 —— 有哪几页、每页几个板块、板块怎么排、跨页关系 | ③段拿着它就有方向 |
|
||||
|
||||
> 不写：视觉（配色 / 字体 / 间距 / 组件样式 / 动效）、需求取证（归①段）、grill 反问（归①段）、用户故事（归①段《使用场景》（`1e-使用场景.md`））。
|
||||
|
||||
## 一、功能清单
|
||||
|
||||
### 组织方式：按使用场景，不按页面
|
||||
|
||||
依据是①段《使用场景》（`1e-使用场景.md`）的每一条。一条场景下可挂跨多个页面的功能。
|
||||
|
||||
用户原话（2026-10-06）：「功能可以分使用场景梳理（可能是跨页面的）」。
|
||||
|
||||
> 按页面组织会把跨页场景切碎，也和①段《使用场景》对不上。对不上就追不回来源，功能就没有由来。
|
||||
|
||||
### 每条功能的六字段（缺一不算完成）
|
||||
|
||||
| 字段 | 写什么 |
|
||||
|---|---|
|
||||
| 功能名 | 一句话说清做什么（动词开头的用户语言），不写实现名 |
|
||||
| 来自哪条场景 | 追回①段《使用场景》（`1e-使用场景.md`）的编号 |
|
||||
| 优先级 | P0 / P1 / P2（判据见下） |
|
||||
| 状态流转 | 这个功能自身有哪几个状态、怎么迁移；无状态就写「无状态」，不留空 |
|
||||
| 验收要点 | 怎么算做完（可观察），不写「体验好」 |
|
||||
| 跨哪些页面 | 这个功能在骨架的哪几页上发生（可多页） |
|
||||
|
||||
### 优先级判据（不许凭空打分）
|
||||
|
||||
| 级 | 判据 |
|
||||
|---|---|
|
||||
| P0 | 不做则①段某条使用场景整条办不成 |
|
||||
| P1 | 不做则场景能办成但要多绕（本可一次点击，变成三步） |
|
||||
| P2 | 不做不影响场景办成，只是更好用 |
|
||||
|
||||
> 优先级就是一句可复述的话。本项目没有数据源，不填数字 —— 数字一旦填进去，就会一路传到功能条目。
|
||||
|
||||
### 「不做」清单（必须逐条对照，不许自行裁剪）
|
||||
|
||||
写②段前、落盘后各做一次：把每一条「不做 / 移出 / 暂缓」与①段 `1a-需求文档.md` 的已拍板项逐条对照。
|
||||
|
||||
凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表：
|
||||
|
||||
| 原条目 | 原口径 | 拟改口径 | 理由 |
|
||||
|---|---|---|---|
|
||||
|
||||
只写「已核对无冲突」不算核对，要给出对照过的条目数。
|
||||
|
||||
## 二、界面布局
|
||||
|
||||
### 为什么两半合成一份
|
||||
|
||||
一句话：信息架构管「页面之间」，布局管「页面之内」。
|
||||
|
||||
| 半 | 回答 | 内容 |
|
||||
|---|---|---|
|
||||
| 页面关系 | 有哪几页、门开在哪 | 页面清单、页面流转、导航 |
|
||||
| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 + 排列顺序（wireframe 灰块粒度） |
|
||||
|
||||
> 不拆两份的理由：参考图里的 `header / side / footer` 是页面框架，正好卡在「之间」与「之内」的交界。拆两份必然出现「页面 P1 有 header」写两遍，而同一件事写两遍就是打架的起点，本项目反复踩这个坑。
|
||||
|
||||
### 必须给全的五样（缺一样③段就没方向）
|
||||
|
||||
1. 页面清单 —— 有哪几页，每页一句话说清干什么
|
||||
2. 页面流转 —— 页与页怎么连（谁跳到谁、什么条件下）
|
||||
3. 每页的板块清单与排列 —— 有几个块、从上到下什么顺序（灰块粒度，不含视觉）
|
||||
4. 每页的主操作 —— 唯一那个推进动作是什么
|
||||
5. 每条信息的分档 —— 主屏常驻 / 可点入（见下）
|
||||
|
||||
### 信息承载分档（判据只有一条）
|
||||
|
||||
| 档 | 定义 |
|
||||
|---|---|
|
||||
| 主屏常驻 | 零点击可见 |
|
||||
| 可点入 | 一次点击内可达 |
|
||||
|
||||
唯一判据：「删掉它，主操作还做得成吗」—— 答「做得成」，就只能进「可点入」。
|
||||
|
||||
> 「能读到」= 可点入，不等于主屏常驻。不得以「②段要求能读到」为理由把信息留在主屏。
|
||||
> 四种禁用免死金牌（理由里只要出现，一律判「不上屏」，哪怕后面跟着「但是」）：① 「但②段要求能读到」；② 「留（产品级约束）」；③ 「但不完整 / 不专业」；④ 「将来可能需要」。
|
||||
> 实战教训：本项目首版②段只说「不写结构」，③段把「必须能读到」全理解为主屏常驻，一屏铺 5 类信息，页面成了「信息墙」，被判定为「最多算一个产品框图」。
|
||||
|
||||
### 页型一句（仍需写）
|
||||
|
||||
本产品的界面是营销页（访客看一眼就下决心）还是工具型页面（用户把活干完）—— 写一句判型加依据。
|
||||
|
||||
> 为什么必须写：③段的版式供给偏落地页向。不说页型，③段就会套错骨架，长成「标题上方一行小字 + 大标题 + 下方一行灰字」，判据全绿、排版难看。本项目实测踩过。
|
||||
> 只写一句判型，不许写「用哪个骨架 / 哪个区块」。
|
||||
|
||||
## 三、仍需保留的旧模板要素（按需，不硬填）
|
||||
|
||||
| 旧 8 段式里的段 | 处置 |
|
||||
|---|---|
|
||||
| Summary / Background / Objective | 可保留，但压成很短一段 —— 给下游快速对齐用 |
|
||||
| Contacts | 删 —— 单机自用产品没有干系人名单 |
|
||||
| Market Segment | 删 —— 归①段《用户画像》 |
|
||||
| Value Proposition | 删 —— 归①段 |
|
||||
| Solution → Key Features | 保留 —— 就是本②段的「功能清单」 |
|
||||
| Solution → UX/Prototypes | 改为「界面布局」—— 只给灰块骨架，不出视觉稿 |
|
||||
| Solution → Assumptions | 保留 —— 假设台账与归宿（口径见 SKILL.md 硬约束） |
|
||||
| Release | 可选 —— 第一版做什么 vs 后面做什么；不写具体日期 |
|
||||
|
||||
## 四、通用要求
|
||||
|
||||
- 写给人看：短句、少术语，能读给不熟悉项目的人听懂。落盘前必须过「说人话」内容准则（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50；五条核心原则与口径见 `product-planning` 的「执行规则」内容准则条）。
|
||||
- 每条都能追来源：功能追①段场景，假设带状态标注，判据给一句话。
|
||||
- 全文零视觉词：配色 / 字体 / 间距 / 组件样式 / 动效，一个字都不许出现。
|
||||
- 保留修订记录：改了实现必须回填条款正文，不能只在修订记录里写。
|
||||
|
||||
## 落盘
|
||||
|
||||
两份：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
- [ ] 每条功能都能追回①段《使用场景》（`1e-使用场景.md`）的某一条
|
||||
- [ ] 每条功能六字段齐全（功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面）
|
||||
- [ ] 优先级没填数字，只用 P0 / P1 / P2 加一句可复述的判据
|
||||
- [ ] 「不做」清单与①段已拍板项逐条对照，并给出对照过的条目数
|
||||
- [ ] 界面布局五样给全（页面清单 / 页面流转 / 每页板块清单与排列 / 每页主操作 / 信息分档）
|
||||
- [ ] 全文零视觉词（配色 / 字体 / 间距 / 组件样式 / 动效）
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# 状态机（State Machine）
|
||||
|
||||
> 本文件由模型按需加载，没有斜杠命令。
|
||||
>
|
||||
> ⭐ 2026-10-06 变更：本份不再产出独立文档。状态流转整合进②段的功能清单 —— 每个功能条目自带一个「状态流转」字段。
|
||||
> 本份保留，是因为它给出的六项治理清单（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认）仍要逐项覆盖，只是落点从 `ux/state-machine.md` 移进 `prd/2a-产品功能.md` 的功能条目内。
|
||||
> 本份只作方法论读，落点是功能条目内的「状态流转」字段。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 功能有异步或长流程（草稿 / 排队 / 生成中 / 失败 / 重试 / 完成）
|
||||
- 需要写清失败之后怎么办（重试 / 降级 / 人工接管）
|
||||
- 前端要看「什么状态下能点什么」
|
||||
|
||||
## 分工边界（重要）
|
||||
|
||||
本份只给状态迁移的判据与治理清单。
|
||||
|
||||
架构图、流程图、时序图、用户旅程图、泳道图请用 `assets/diagram-design/` —— 它有 39 种编辑级图型，且输出自包含 HTML+SVG。状态迁移的守卫 / 副作用 / 持久化 / 并发治理没有现成开源 skill 覆盖，所以留在本份。
|
||||
|
||||
## 主产出：状态迁移表（贴在功能条目内）
|
||||
|
||||
| 状态 | 含义 | 允许事件 | 守卫条件 | 迁移到 | 副作用 |
|
||||
|---|---|---|---|---|---|
|
||||
| idle | 未开始 | submit | 参数合法 | queued | 创建任务 |
|
||||
| queued | 排队中 | start / cancel | — | running / idle | — |
|
||||
| running | 生成中 | done / fail / cancel | — | succeeded / failed / idle | 写日志 |
|
||||
| failed | 失败 | retry | 重试次数 < 3 | queued | 计数 +1 |
|
||||
| succeeded | 完成 | edit / export | — | idle | 存版本 |
|
||||
|
||||
字段定义：
|
||||
|
||||
- 状态：英文小写下划线，不中英混写，便于直接落到代码
|
||||
- 允许事件：不在该行的事件一律视为非法，必须显式拒绝，不能静默忽略
|
||||
- 守卫条件：不加守卫就会出的错（重复提交、配额超限、并发编辑、权限不足）
|
||||
- 迁移到：目标状态，只写一个，多目标用守卫条件拆开
|
||||
- 副作用：迁移时必须做的事（落库、发通知、计费、埋点）
|
||||
|
||||
> ⭐ 不适用时写「无状态」：某些功能确实没有状态流转（如「看一版截图」）。不许把这一栏留空 —— 留空与「没想」不可区分，写「无状态」是合格答案。
|
||||
|
||||
## 必答清单（漏一项即缺陷）
|
||||
|
||||
1. 失败恢复路径：每个失败态给出三种之一 —— 自动重试（次数 / 退避策略）、降级（降级成什么）、人工接管（入口在哪）
|
||||
2. 持久化：哪些状态要落库？刷新 / 断线 / 换设备后能否恢复？不能恢复的必须显式说明
|
||||
3. 并发冲突：同一资源被两个入口同时修改怎么办（乐观锁 / 队列串行 / 后者覆盖并提示）
|
||||
4. 超时：每个中间态的最长停留时间，超时后迁移到哪
|
||||
5. 幂等：重复提交同一请求的结果是什么
|
||||
6. 不可逆操作：删除、发布、扣费类迁移要标注「需二次确认」
|
||||
|
||||
## 死状态禁令
|
||||
|
||||
- 每个状态必须有出口，终态也要能「再次开始」
|
||||
- 不允许「其他」「未知」这类兜底状态
|
||||
- 不允许没有触发事件的自动漂移（超时迁移不算，但必须显式定义）
|
||||
|
||||
## 速览图
|
||||
|
||||
仅作沟通速览。需要正式交付级图，交给 `diagram-design`。
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> idle
|
||||
idle --> queued: submit
|
||||
queued --> running: start
|
||||
running --> succeeded: done
|
||||
running --> failed: fail
|
||||
failed --> queued: retry
|
||||
succeeded --> idle: edit
|
||||
```
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
- [ ] 每条迁移都有触发事件、无自动漂移，且挂在具体功能条目上（无凭空中间态）；无状态的功能显式写「无状态」
|
||||
- [ ] 每个失败态都有恢复路径（重试 / 降级 / 人工接管）
|
||||
- [ ] 持久化范围明确：哪些状态落库，刷新 / 断线 / 换设备后能否恢复
|
||||
- [ ] 并发冲突有处理方式
|
||||
- [ ] 超时策略明确：每个中间态最长停留多久、超时后迁到哪
|
||||
- [ ] 不可逆操作（删除 / 发布 / 扣费）已标注「需二次确认」
|
||||
|
||||
## 落盘
|
||||
|
||||
落点是 `docs/pm/<项目>/prd/2a-产品功能.md` 的功能清单内 —— 每个功能条目自带一个「状态流转」字段，按上表格式写；无状态的功能写「无状态」。
|
||||
@@ -0,0 +1,346 @@
|
||||
# 目标执行状态 · 重写 5 份竞品分析文档并重新生成 MCN 短视频整合营销需求文档
|
||||
|
||||
> 目标目录：`执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/`
|
||||
> 台账（唯一权威）：`tmp/supervise-inbox/tasks.json` ｜ 目标：`tmp/supervise-inbox/goal.json`
|
||||
> 本份由 **第 6 棒目标检查会话**（排期 `39053be1-283e-4df7-92eb-98b14e60ff39`，21:49 跑）建立。
|
||||
|
||||
## 〇、最新判定 · 第 14 棒（2026-10-08 01:50 · 本棒 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路取并集（判据路仍 2 条不过）。与第 8／9／10／11／12／13 棒**结论逐条相同**。
|
||||
|
||||
- ① 台账 `tasks.json`：**10 条全部 `done`**、无 `pending`／`running`／`blocked` ⇒ **无僵尸件**。机器侧现取：`--check-status` ⇒ `目标状态 = 进行中｜队列未完成 = 0｜静默 = 2.4 分钟｜会话全结束｜已建检查会话 = 14 棒`。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判（与第 7～13 棒同）。
|
||||
- ③ 验收判据 `goal.json.acceptance_state` 7 条：**5 过、2 不过** —— 判据 1／2／3／4／7 ＝ `过`；判据 5（技能包规则文件已全量过说人话）／判据 6（vibe-product 六份①②段文档已重写）＝ `🔴 不过`。**与本文件逐条一致 ⇒ 值域已规范、无字可改**。
|
||||
|
||||
**本棒新取证（L3 · 2026-10-08 01:5x 现测 mtime · ⛔ 不是读文档推断）**：两处落点**仍全部早于新稿** ⇒ 落地确实未做（读数与第 11～13 棒逐条相同，无变化）。
|
||||
|
||||
- 判据 5 落点 `E:/ProgramData/.workbuddy/skills/product-planning/`：`SKILL.md` **21:45**／`stage-discovery/SKILL.md` **21:53**／`stage-requirements/SKILL.md` **21:29**／`stage-delivery/SKILL.md` **20:23**／`stage-proto-doc/SKILL.md` **01:20**；同名新稿 **16 份** mtime **23:01–23:08** ⇒ **一份都没被覆盖**。
|
||||
- 判据 6 落点 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`：`research/1a·1c·1d·1e` ＝ **01:46**（3121／1812／1463／1724 B）／`prd/2a·2b` ＝ **01:47**（3034／3383 B）；同名新稿 6 份 ＋ `落点说明.md` mtime **23:29–23:31** ⇒ **六份一份没动**。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、⛔ **未派新棒**（与第 8～13 棒同判）。理由：两条不过判据的**唯一剩余动作都是跨边界文件落地** —— 落点分别是全局技能目录 `E:/ProgramData/.workbuddy/skills/`（**本工作区之外**）与 `E:/ProgramData/AIProject/vibe-product/`（**另一个工作区**）；本区任务会话受域门禁约束（写只许在域目录内、跨目录一律只读）⇒ 派了必撞门禁、零产出。两条的落地步骤**已完整写在** `tmp/supervise-inbox/NEED-USER.md` 第 2／3 条（源／目标／备份／回退／覆盖后自检命令齐全）⇒ **无新增可派内容**，属「找活干」。
|
||||
2、⛔ **不改 `lifecycle`**（保持「进行中」）。「已完成」不实（2 条判据 🔴 不过）；其余取值不在本轮授权变更项内 ⇒ 宁可停，不臆断。
|
||||
3、⛔ **未改 `acceptance_state`**：7 条值域已规范、与本文件逐条一致 ⇒ **无需**（⛔ 不是漏）。
|
||||
4、⛔ **未跑** `--ensure-goal-dir`（本区 `collabd-state.json` 的 `roles = {}` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
5、⛔ **未动任何代码、未改常驻**（本轮只做核对，做完即停）。
|
||||
|
||||
**输入侧偏差（供机制记账 · 与第 9～13 棒同）**：派活原文指定的五样里**两样在本区不存在** —— `state.py`（工作区根无此文件，实跑报 `No such file or directory`）与 `taskgraph.json`；另 `goal.json.execution_doc` **仍指旧目标目录** `…-5199a6/目标执行状态.md`（登记于 10-07 17:00，未经 `--ensure-goal-dir` 对齐）⇒ 本轮判定**以本目标目录这份为准**。第五样 `--domain-status` 已跑：在册域锁 1 条（`ai1net-dsh-anywhere ← [协作]N9复测-2248`），锚点词表一致 ✅。
|
||||
|
||||
**机制侧观察（只报现象 · ⛔ 本轮未动任何代码）**：本目标已连建 **14 棒**检查会话，第 **8–14 棒结论完全相同**（未完成 · 残 2 条跨边界落地）。只要 `lifecycle` 仍「进行中」且队列空，常驻就会继续按 `queue-empty` 建第 15 棒，而残项**机制侧不可达** ⇒ 持续空跑。收口办法（收窄检查会话连棒阈值 ／ 由用户结束目标）**须用户定**，超出本轮范围。
|
||||
|
||||
**留给主会话／用户的四项**（前 6 棒已提，本棒复核仍成立）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（`…-5199a6/目标执行状态.md`）⇒ 需跑一次 `--ensure-goal-dir`（**只能 main 席位**跑）。
|
||||
2、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
3、判据 6 落地：把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`（`落点说明.md` ⛔ 不覆盖）。
|
||||
4、这两条落地均为**域外／跨区写入** ⇒ 机制侧无法代劳；落地完成后判据 5／6 才能转 `过`，届时方可 `--set-life 已完成`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 13 棒（2026-10-08 01:20 · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路取并集（判据路仍 2 条不过）。与第 8／9／10／11／12 棒**结论逐条相同**。
|
||||
|
||||
- ① 台账 `tasks.json`：**10 条全部 `done`**、无 `pending`／`running`／`blocked` ⇒ **无僵尸件**。机器侧现取：`--check-status` ⇒ `目标状态 = 进行中｜队列未完成 = 0｜静默 = 2.3 分钟｜会话全结束｜已建检查会话 = 13 棒`。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判（与第 7～12 棒同）。
|
||||
- ③ 验收判据 `goal.json.acceptance_state` 7 条：**5 过、2 不过** —— 判据 1／2／3／4／7 ＝ `过`；判据 5（技能包规则文件已全量过说人话）／判据 6（vibe-product 六份①②段文档已重写）＝ `🔴 不过`。**与本文件逐条一致 ⇒ 值域已规范、无字可改**。
|
||||
|
||||
**本棒新取证（L3 · 2026-10-08 01:20 现测 mtime · ⛔ 不是读文档推断）**：两处落点全部早于新稿 ⇒ 落地确实未做。
|
||||
|
||||
- 判据 5 落点 `E:/ProgramData/.workbuddy/skills/product-planning/`：`stage-proto-doc/SKILL.md` **10-07 01:20**／`stage-delivery` **20:23**／`stage-requirements` **21:29**／`stage-discovery` **21:53**（另 `design-capture`／`video-capture` 15:28、`design-system-tiaoyue` 09:26、`diagram-design` 09-28 10:23）；同名新稿 16 份 mtime **23:02–23:08** ⇒ **一份都没被覆盖**。
|
||||
- 判据 6 落点 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`：`research/1a·1c·1d·1e` ＝ **10-07 01:46**（3121／1812／1463／1724 B）／`prd/2a·2b` ＝ **01:47**（3034／3383 B）；同名新稿 6 份 ＋ `落点说明.md` mtime **23:29–23:31** ⇒ **六份一份没动**。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、⛔ **未派新棒**（与第 8～12 棒同判）。理由：两条不过判据的**唯一剩余动作都是跨边界文件落地** —— 落点分别是全局技能目录 `E:/ProgramData/.workbuddy/skills/`（**本工作区之外**）与 `E:/ProgramData/AIProject/vibe-product/`（**另一个工作区**）；本区任务会话受域门禁约束（写只许在域目录内、跨目录一律只读）⇒ 派了必撞门禁、零产出。两条的落地步骤**已完整写在** `tmp/supervise-inbox/NEED-USER.md` 第 2／3 条（源／目标／备份／回退／覆盖后自检命令齐全）⇒ **无新增可派内容**，属「找活干」。
|
||||
2、⛔ **不改 `lifecycle`**（保持「进行中」）。「已完成」不实（2 条判据 🔴 不过）；其余取值不在本轮授权变更项内 ⇒ 宁可停，不臆断。
|
||||
3、⛔ **未改 `acceptance_state`**：7 条值域已规范、与本文件逐条一致 ⇒ **无需**（⛔ 不是漏）。
|
||||
4、⛔ **未跑** `--ensure-goal-dir`（本区 `collabd-state.json` 的 `roles = {}` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
5、⛔ **未动任何代码、未改常驻**（本轮只做核对，做完即停）。
|
||||
|
||||
**输入侧偏差（供机制记账 · 与第 9～12 棒同）**：派活原文指定的五样里**两样在本区不存在** —— `state.py`（工作区根无此文件，实跑报 `No such file or directory`）与 `taskgraph.json`；另 `goal.json.execution_doc` **仍指旧目标目录** `…-5199a6/目标执行状态.md`（登记于 10-07 17:00，未经 `--ensure-goal-dir` 对齐）⇒ 本轮判定**以本目标目录这份为准**。第五样 `--domain-status` 已跑：在册域锁 1 条（`ai1net-dsh-anywhere ← [协作]N9复测-2248`），锚点词表一致 ✅。
|
||||
|
||||
**机制侧观察（只报现象 · ⛔ 本轮未动任何代码）**：本目标已连建 **13 棒**检查会话，第 **8–13 棒结论完全相同**（未完成 · 残 2 条跨边界落地）。只要 `lifecycle` 仍「进行中」且队列空，常驻就会继续按 `queue-empty` 建第 14 棒，而残项**机制侧不可达** ⇒ 持续空跑。收口办法（收窄检查会话连棒阈值 ／ 由用户结束目标）**须用户定**，超出本轮范围。
|
||||
|
||||
**留给主会话／用户的四项**（前 5 棒已提，本棒复核仍成立）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（`…-5199a6/目标执行状态.md`）⇒ 需跑一次 `--ensure-goal-dir`（**只能 main 席位**跑）。
|
||||
2、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
3、判据 6 落地：把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`（`落点说明.md` ⛔ 不覆盖）。
|
||||
4、这两条落地均为**域外／跨区写入** ⇒ 机制侧无法代劳；落地完成后判据 5／6 才能转 `过`，届时方可 `--set-life 已完成`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 12 棒（2026-10-08 00:50 · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路取并集（判据路仍 2 条不过）。与第 8／9／10／11 棒**结论逐条相同**。
|
||||
|
||||
- ① 台账 `tasks.json`：**10 条全部 `done`**、无 `pending`／`running`／`blocked` ⇒ **无僵尸件**。机器侧现取：`--check-status` ⇒ `目标状态 = 进行中｜队列未完成 = 0｜静默 = 2.9 分钟｜会话全结束｜已建检查会话 = 12 棒`。
|
||||
- ② 任务图 `tmp/supervise-inbox/taskgraph.json`：**文件不存在** ⇒ 无节点可判（与前 4 棒同）。
|
||||
- ③ 验收判据 `goal.json.acceptance_state` 7 条：**5 过、2 不过** —— 判据 1／2／3／4／7 ＝ `过`；判据 5（技能包规则文件已全量过说人话）／判据 6（vibe-product 六份①②段文档已重写）＝ `🔴 不过`。**与本文件逐条一致 ⇒ 值域已规范、无字可改**。
|
||||
|
||||
**本棒新取证（L3 · 2026-10-08 00:50 现测 mtime · ⛔ 不是读文档推断）**：两处落点全部早于新稿 ⇒ 落地确实未做。
|
||||
|
||||
- 判据 5 落点 `E:/ProgramData/.workbuddy/skills/product-planning/`：`SKILL.md` **21:45** ／ `stage-discovery` **21:53** ／ `stage-requirements` **21:29** ／ `stage-delivery` **20:23** ／ `stage-proto-doc` **01:20**；同名新稿 16 份 mtime **23:02–23:08**（源目录 16 份已逐个核过，与 `NEED-USER.md` 第 2 条清单逐条同）。
|
||||
- 判据 6 落点 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`：`research/1a·1c·1d·1e` ＝ **01:46** ／ `prd/2a·2b` ＝ **01:47**；同名新稿 6 份 ＋ `落点说明.md` mtime **23:29–23:31**。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、⛔ **未派新棒**（与第 8／9／10／11 棒同判）。理由：两条不过判据的**唯一剩余动作都是跨边界文件落地** —— 落点分别是全局技能目录 `E:/ProgramData/.workbuddy/skills/`（**本工作区之外**）与 `E:/ProgramData/AIProject/vibe-product/`（**另一个工作区**）；本区任务会话受域门禁约束（写只许在域目录内、跨目录一律只读）⇒ 派了必撞门禁、零产出。两条的落地步骤**已完整写在** `tmp/supervise-inbox/NEED-USER.md` 第 2／3 条（源／目标／备份／回退／覆盖后自检命令齐全）⇒ **无新增可派内容**，属「找活干」。
|
||||
2、⛔ **不改 `lifecycle`**（保持「进行中」）。「已完成」不实（2 条判据 🔴 不过）；其余取值不在本轮授权变更项内 ⇒ 宁可停，不臆断。
|
||||
3、⛔ **未改 `acceptance_state`**：7 条值域已规范、与本文件逐条一致 ⇒ **无需**（⛔ 不是漏）。
|
||||
4、⛔ **未跑** `--ensure-goal-dir`（本区 `collabd-state.json` 的 `roles = {}` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
|
||||
**输入侧偏差（供机制记账 · 与前 3 棒同）**：派活原文指定的五样里**两样在本区不存在** —— `state.py`（工作区根无此文件）与 `taskgraph.json`；另 `goal.json.execution_doc` **仍指旧目标目录** `…-5199a6/目标执行状态.md`（登记于 10-07 17:00，未经 `--ensure-goal-dir` 对齐）⇒ 本轮判定**以本目标目录这份为准**。
|
||||
|
||||
**机制侧观察（只报现象 · ⛔ 本轮未动任何代码）**：本目标已连建 **12 棒**检查会话，第 **8–12 棒结论完全相同**（未完成 · 残 2 条跨边界落地）。只要 `lifecycle` 仍「进行中」且队列空，常驻就会继续按 `queue-empty` 建第 13 棒，而残项**机制侧不可达** ⇒ 持续空跑。收口办法（收窄检查会话连棒阈值 ／ 由用户结束目标）**须用户定**，超出本轮范围。
|
||||
|
||||
**留给主会话／用户的四项**（前 4 棒已提，本棒复核仍成立）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（`…-5199a6/目标执行状态.md`）⇒ 需跑一次 `--ensure-goal-dir`（**只能 main 席位**跑）。
|
||||
2、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
3、判据 6 落地：把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`（`落点说明.md` ⛔ 不覆盖）。
|
||||
4、这两条落地均为**域外／跨区写入** ⇒ 机制侧无法代劳；落地完成后判据 5／6 才能转 `过`，届时方可 `--set-life 已完成`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 11 棒（2026-10-08 00:2x · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路并集（判据路仍 2 条不过）。
|
||||
|
||||
- ① 台账 `tasks.json`：**10 条全部 `done`**、队列空、无僵尸件（机器侧 `队列 = {'done': 10}`；`--check-status` ⇒ `目标状态 = 进行中｜队列未完成 = 0｜静默 3.1 分钟｜会话全结束`）。
|
||||
- ② 任务图 `tmp/supervise-inbox/taskgraph.json`：**文件不存在** ⇒ 无节点可判。
|
||||
- ③ 验收判据 7 条：**5 过、2 不过** —— 判据 1／2／3／4／7 ＝ `过`；判据 5（技能包规则文件已全量过说人话）／判据 6（vibe-product 六份①②段文档已重写）＝ `🔴 不过`。与 `goal.json.acceptance_state` **逐条一致**（值域已规范）。
|
||||
|
||||
**本棒新取证（L3 · 2026-10-08 00:20–00:22 现测 · ⛔ 不是读文档推断）**：两处落点逐个文件的 mtime **全部早于新稿** ⇒ 落地确实未做。
|
||||
|
||||
- 判据 5 落点 `E:/ProgramData/.workbuddy/skills/product-planning/` 16 份：mtime 停在 20:23～21:53（另 3 份停在 09-28／10-05）；而同名新稿 mtime 是 23:01–23:08。
|
||||
- 判据 6 落点 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`：`research/` 的 1a／1c／1d／1e mtime ＝ **01:46**、`prd/` 的 2a／2b ＝ **01:47**；而同名新稿 mtime 是 23:29–23:31。
|
||||
- 两批新稿**都在、都齐**：技能包 16 份（23:01–23:08，合计结构与技能包同构）／vibe-product 6 份 ＋ `落点说明.md`（23:29–23:31）。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、⛔ **未派新棒**（与前 3 棒同判）。理由：两条不过判据的**唯一剩余动作都是跨边界文件落地** —— 落点分别是
|
||||
`E:/ProgramData/.workbuddy/skills/product-planning/`（**本工作区之外**，全局技能目录）与
|
||||
`E:/ProgramData/AIProject/vibe-product/`（**另一个工作区**）。本区任务会话受域门禁约束（写只许在域目录内、跨目录一律只读）
|
||||
⇒ 派了必撞门禁、零产出 ⇒ 属「找活干」。
|
||||
2、⛔ **不改 `lifecycle`**（保持「进行中」）。「已完成」不实（2 条判据 🔴 不过）；「阻碍」不在派活原文授权的变更项内 ⇒ 宁可停，不臆断。
|
||||
3、⛔ **未改 `acceptance_state`**：7 条值域已规范、与本文件逐条一致 ⇒ **无字可改**（是无需，⛔ 不是漏）。
|
||||
4、⛔ **未跑** `--ensure-goal-dir`（本区 `collabd-state.json` 的 `roles = {}` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
|
||||
**输入侧偏差（供机制记账）**：派活原文指定「先读这五样」，其中两样在本区**不存在** ——
|
||||
`state.py`（工作区根无此文件，命令报 `No such file or directory`）与 `taskgraph.json`（同样不存在）。
|
||||
⇒ 这两个输入已缺，本轮改用 `--check-status`／`goalctl.py` 无参读数替代，**不影响判定**（结论与文档、台账一致）。
|
||||
|
||||
**机制侧观察（只报现象 · 本轮不扩面、⛔ 未动任何代码）**：本目标已连建 **11 棒**检查会话，第 8／9／10／11 棒结论**完全相同**
|
||||
（未完成 · 残 2 条跨边界落地）。只要 `lifecycle` 仍是「进行中」且队列空，常驻就会继续按 `queue-empty` 建第 12 棒，
|
||||
而残项**机制侧不可达** ⇒ 属重复空跑。根因与修法（如：检查会话连续 N 棒判「残项不可派」时应收窄）超出本轮范围。
|
||||
|
||||
**留给主会话的四条**（前 3 棒已提，本棒复核仍成立）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（`…-5199a6/目标执行状态.md`，登记于 10-07 17:00）⇒ 需跑一次 `--ensure-goal-dir`（**只能 main 席位**跑）。
|
||||
2、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
3、判据 6 落地：把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`。
|
||||
4、这两条落地均为**域外／跨区写入** ⇒ 机制侧无法代劳；落地完成后判据 5／6 才能转 `过`，届时方可 `--set-life 已完成`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 10 棒（2026-10-07 23:49 · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路并集（判据路仍 2 条不过）。
|
||||
|
||||
- ① 台账 `tasks.json`：**10 条全部 `done`**、队列空、无僵尸件（机器侧 `队列 = {'done': 10}`）。本目标 4 条：`6ec1b428`（22:01:45 证据附卷）、`75bfa487`（22:30:23 S7）、`fae90e6f`（23:11:53 技能包说人话清单）、`ea3ce52d`（23:32 vibe-product 六份新稿）。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判（机器侧同报「任务图读不到」）。
|
||||
- ③ 验收判据：7 条中 **5 条过、2 条不过** —— 判据 1／2／3／4／7 ＝ `过`；判据 5（技能包规则文件已全量过说人话）／判据 6（vibe-product 六份①②段文档已重写）＝ `🔴 不过`。两条卡住的都只是**落地**，改写稿本身已齐。
|
||||
|
||||
**本棒新取证（L3，⛔ 不是读文档推断）**：
|
||||
|
||||
- 第 9 棒 23:27 派的那条棒（`ea3ce52d`）**已真跑完**：`72111e/vibe-product六份-新稿/` 下六份齐（`1a-需求文档.md`／`1c-用户画像.md`／`1d-产品策略.md`／`1e-使用场景.md`／`2a-产品功能.md`／`2b-界面布局.md` ＋ `落点说明.md`，mtime 23:31）⇒ 判据 6 的「新稿」阶段闭环，剩**跨区落地**。
|
||||
- `72111e/技能包-说人话-新稿/` ＝ **16 份**（`SKILL.md` ＋ `references/stage-*/…`，与技能包结构同构）⇒ 判据 5 的「新稿」阶段闭环，剩**域外落地**与**「全量」口径**。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、⛔ **未派新棒**。理由：两条不过判据的**唯一剩余动作都是落地**，落点分别是
|
||||
`E:/ProgramData/.workbuddy/skills/product-planning/`（**域外**）与
|
||||
`E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`（**跨区**）
|
||||
⇒ 本工作区任务会话受域门禁约束（写只许在域目录内、跨目录一律只读），派了必撞门禁 ⇒ 属「找活干」，故不派。
|
||||
2、✅ **改齐 `acceptance_state` 值域**（本棒做了，前 3 棒均未做）：原 7 条全写「未过」——
|
||||
**不在取值域**（规范是 `过｜…` ／ `🔴 不过｜…`）⇒ 机器分不出「还没判」与「判了没过」、看板会一直显示未过。
|
||||
已按本文件逐条结论用 `goalctl.py declare --kpi` 改写，**并回读 `goal.json` 确认落库**（7 条、规范写法、title 与 lifecycle 未被顺带改动）。
|
||||
3、⛔ **不改 lifecycle**（保持「进行中」）。
|
||||
4、⛔ **未跑** `--ensure-goal-dir`（本区 `collabd-state.json` 的 `roles` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
|
||||
**留给主会话的四条**（前 3 棒已提，本棒复核仍成立）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（`…-5199a6/目标执行状态.md`，登记于 10-07 17:00）⇒ 需跑一次 `--ensure-goal-dir`（**只能 main 席位**跑）。
|
||||
2、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
3、判据 6 落地：把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`。
|
||||
4、这两条落地均为**域外／跨区写入** ⇒ 机制侧无法代劳；落地完成后判据 5／6 才能转 `过`，届时方可 `--set-life 已完成`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 9 棒（2026-10-07 23:21 · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路并集（判据路有 2 条实测不过）。
|
||||
|
||||
- ① 台账 `tasks.json`：**9 条全部 `done`**、队列空、无僵尸件（`collabd-state.json`：pending 0／running 0／done 9／blocked 0）。本目标 3 条：`6ec1b428`（22:01:45）、`75bfa487`（22:30:23）、`fae90e6f`（23:11:53，artifact＝`…-72111e/技能包-说人话-改写清单.md`）。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判。
|
||||
- ③ 验收判据 `goal.json.acceptance_state`：7 条**全非「过」**（值写作「未过」，非规范取值域）。机器侧读数一致：`--check-status` ⇒ `目标状态 = 进行中｜队列未完成 = 0｜静默 = 2.6 分钟｜会话全结束`。
|
||||
|
||||
**本棒本机实测（L3，⛔ 不是读文档推断）**：
|
||||
|
||||
- 判据 1／2／3／4（5 份独立体重写、汇总边界、1a 逐条复核、MCN 需求文档重生成）—— 证据已齐：`…-5199a6/docs/pm/content-workbench/证据附卷/` 5 份（mtime 21:40～22:01）＋ `72111e/` 下 `1b-竞品分析-汇总对比体.md`／`复核清单-1a受影响条目.md`／`1a-需求文档-MCN短视频整合营销.md`（mtime 22:29）。
|
||||
- 判据 5「技能包规则文件已全量过说人话」—— 🔴 **不过（部分推进）**：23:10 那棒（`fae90e6f`）已把 16 份新稿改好并自检（`72111e/技能包-说人话-新稿/`，`check_naming` 通过 46／失败 0／提示 1），**但一个字节都没写进技能目录**（域外）⇒ 落地未做；且「全量」口径（16／19／83）未定 ⇒ 落地与口径都待主会话。
|
||||
- 判据 6「vibe-product 六份①②段文档已重写」—— 🔴 **不过**：`E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/research/` 下 `1a`／`1c`／`1d`／`1e` mtime 仍是 01:46，同目录 `1b` 为 21:07（⛔ 不在本项范围内）⇒ 六份**一份没动**（本棒新实测）。
|
||||
- 判据 7「产物落点明确且可追溯」—— ✅ 可判过：台账每条 `artifact` 都带明确路径，S7 §二亦列清单。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、**派了一条执行棒** `[执行]-[开源项目调研]-vibe-product六份阶段文档重写新稿`（id `e012f7d6`，once，23:27 触发，`cwds` 逐字＝本工作区，域目录 `执行会话`，域检 `✅ 可派｜域空闲`）⇒ 接判据 6：按 ①段／②段方法论把六份**新稿**落本目标目录 `72111e/vibe-product六份-新稿/`，源工作区与技能目录**全程只读**，跨区落地留给主会话。
|
||||
2、**未派第二条**（⛔ 不连建）：判据 5 的落地是**域外写入**（`E:/ProgramData/.workbuddy/skills/`）⇒ 本工作区任务会话受域门禁写不了，只能主会话。
|
||||
3、**不改生命周期**（保持「进行中」）。
|
||||
4、⛔ **没写** `acceptance_state`：本轮分支是「没做完」；且值域「未过」不在 `过｜…`／`🔴 不过｜…` ⇒ 应由主会话一次性改齐（本棒不擅改）。
|
||||
5、⛔ **没跑** `--ensure-goal-dir`（本区 `roles` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
|
||||
**留给主会话的四条**（本棒不擅改）：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指**旧目标目录**（5199a6）⇒ 跑一次 `--ensure-goal-dir`（只能 main 席位跑）。
|
||||
2、`acceptance_state` 值域「未过」不在规范取值域 ⇒ 按规范改齐；判据 1／2／3／4／7 **依据已足，可写「过」**。
|
||||
3、判据 5 落地：把 `72111e/技能包-说人话-新稿/` 16 份**同名覆盖**进 `E:/ProgramData/.workbuddy/skills/product-planning/`（覆盖前先备份）；落地前先定「全量」口径（16／19／83）。
|
||||
4、判据 6 落地：等本棒新稿产出后，把 `72111e/vibe-product六份-新稿/` 六份覆盖进 `E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/`。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 8 棒（2026-10-07 22:5x · 历史 · **覆盖以下全部历史判定**）
|
||||
|
||||
**判定：目标未完成** —— 三路并集 ＋ 本机实测复核。
|
||||
|
||||
- ① 台账 `tasks.json`：**8 条全部 `done`**、队列空、无僵尸件（`collabd-state.json`：pending 0／running 0／done 8／blocked 0）。本目标 2 条：`6ec1b428`（22:01:45）、`75bfa487`（22:30:23，artifact＝`…-72111e/S7-重生成MCN需求文档-20261007.md`）。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判。
|
||||
- ③ 验收判据 `goal.json.acceptance_state`：7 条**全非「过」**；机器侧读数一致（`goalctl` 无参跑出「目标状态 = **未完成**」）。
|
||||
|
||||
**本棒新增的本机实测（L3，⛔ 不是读文档推断）**：
|
||||
|
||||
- 判据「5份竞品分析已按独立分析体重写」—— ✅ 已坐实：`…-5199a6/docs/pm/content-workbench/证据附卷/` 5 份，mtime 21:40～22:01（14～33 KB）。
|
||||
- 判据「1b汇总对比体与独立体职责边界正确」／「受影响的1a需求文档条目已逐条复核」／「MCN需求文档已重新生成」—— ✅ 已坐实：`72111e/` 下 `1b-竞品分析-汇总对比体.md`、`复核清单-1a受影响条目.md`、`1a-需求文档-MCN短视频整合营销.md` 三份，mtime 22:29，均由 22:25 那棒（`e74db4d4`）产出并 `--report --state done`。
|
||||
- 判据「技能包规则文件已全量过说人话」—— 🔴 **不过**：`E:/ProgramData/.workbuddy/skills/product-planning/` 共 87 份 `.md`，在 21:38（用户选 A 全量过）之后**只有 2 份**被改（`SKILL.md` 21:45、`references/stage-discovery/SKILL.md` 21:53）⇒ 远未「全量」。
|
||||
- 判据「vibe-product六份①②段文档已重写」—— 🔴 **不过**：`E:/ProgramData/AIProject/vibe-product/docs/pm/proto-board/` 清单内六份（`1a`／`1c`／`1d`／`1e`／`2a`／`2b`）mtime 仍是 01:46～01:47，**一份没动**；21:07 只动过清单外的 `research/1b-竞品分析.md`。
|
||||
- 判据「产物落点明确且可追溯」—— ⚠️ **判不了**：四项已交付产物的落点清单清楚（S7 §二），但 5 份独立体落在**旧目标目录** `5199a6`，与「本目标目录」按字面互斥（见 §六）⇒ 口径待主会话裁定。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、**派了一条执行棒** `[执行]-[开源项目调研]-技能包规则全量说人话`（id `ed3dd62e`，once，22:57 触发，`cwds` 逐字＝本工作区，域目录 `执行会话`，域检 `✅ 可派｜域空闲`）⇒ 接 §六 队列第 3 项、判据「技能包规则文件已全量过说人话」。
|
||||
· 写法：改写稿落目标目录 `72111e/技能包-说人话-新稿/`（域内），全局技能目录**全程只读**，最终落地由主会话一步执行。
|
||||
2、**未派第二条**（⛔ 不连建）：§六 队列第 4 项「vibe-product 六份重写」的目标是**另一个工作区** ⇒ 按 S 红线，本工作区执行棒不得去那儿写入 ⇒ 只能由主会话处置。
|
||||
3、**不改生命周期**（保持「进行中」）。
|
||||
4、⛔ **没跑** `--ensure-goal-dir`（§四 结论仍成立：本区 `roles` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
5、⛔ **没写** `acceptance_state`：本轮分支是「没做完」而非「做完了」；且第 7 条判据的落点口径待主会话裁定 ⇒ 逐条写「过」会造成机器侧误读。
|
||||
|
||||
**留给主会话的（本棒不擅改）**：`goal.json.execution_doc` 仍指旧目标目录（5199a6）⇒ 需跑一次 `--ensure-goal-dir`（只能由 main 席位跑）；判据值域「未过」不在 `过｜…`／`🔴 不过｜…` 取值域；第 7 条判据的落点口径与 §六 互斥；判据「vibe-product 六份」非本工作区可写。
|
||||
|
||||
---
|
||||
|
||||
## 〇、上一棒判定 · 第 7 棒（2026-10-07 22:20 · 排期 `20661a85` · 历史）
|
||||
|
||||
> 🔴 本节**覆盖下面 §一～§七 的历史判定**（那些是第 6 棒 21:49 写的，其前提「21:55 那棒还没跑」已失效）。
|
||||
|
||||
**判定：目标未完成** —— 三路并集：
|
||||
|
||||
- ① 台账 `tasks.json`：7 条**全部 done**、队列空、无僵尸件。但其中 **6 条属旧目标（`goal_fp=5199a6`）**；本目标只 1 条：`6ec1b428`（22:01:45 done，`by=""`，artifact＝`…-5199a6/…/证据附卷/`）。
|
||||
- ② 任务图 `taskgraph.json`：**文件不存在** ⇒ 无节点可判。
|
||||
- ③ 验收判据 `goal.json.acceptance_state`：**7 条全部非「过」**（值写作「未过」，非规范取值域）。机器侧读数一致（`goalctl` 无参跑出「目标状态 = **未完成**」）。
|
||||
|
||||
**实况核实（本棒新增，⛔ 不是推断）**：
|
||||
|
||||
- 21:55 那棒 `[执行]-[开源项目调研]-重写竞品独立分析体`（`4e470d4c`）**已真跑完**：`证据附卷/` 5 份文件 mtime 全在 21:40～22:01（14～33 KB），22:01:45 有一条 `--report --state done`（`6ec1b428`）⇒ 第 6 棒「活有人干」的悬念已落地。
|
||||
- 剩余缺口：**汇总体边界（判据 2）／1a 逐条复核（判据 3）／MCN 需求文档重生成（判据 4）／技能包规则 19 份（判据 5，主会话）／vibe-product 六份（判据 6，主会话）／产物落点（判据 7）**。
|
||||
|
||||
**本棒处置**：
|
||||
|
||||
1、**派了一条执行棒** `[执行]-[开源项目调研]-重生成MCN需求文档`（id `e74db4d4`，once，22:25 触发，`cwds` 逐字＝本工作区，域目录 `执行会话`，域检 `✅ 可派｜域空闲`）⇒ 接判据 2／3／4。
|
||||
2、**不改生命周期**（保持「进行中」）。
|
||||
3、⛔ **没跑** `--ensure-goal-dir`（第 6 棒 §四 的结论仍成立：本区 `roles` 为空 ⇒ 会把检查会话登记成主会话）。
|
||||
4、⛔ **没写** `acceptance_state`（7 条判据的逐条依据本轮取证不到位 ⇒ 依「不确定就不改」停手）。
|
||||
|
||||
**留给主会话的三条（本棒不擅改）**：
|
||||
|
||||
1、`goal.json.execution_doc` 仍指向**旧目标**目录（5199a6）⇒ 需跑一次 `--ensure-goal-dir` 对齐（只能由 main 席位跑）。
|
||||
2、判据值域：「未过」不在 `过｜…`／`🔴 不过｜…` 取值域 ⇒ 需按规范改写（功能上等价，机器读数已是「未完成」，未产生错误结论）。
|
||||
3、落点口径：新版产物落目标目录（`72111e/`），旧文件留在原位不删；若裁定应以新版**覆盖** `docs/pm/mcn-shortvideo-agent/research/1a-需求文档.md`，需主会话（域外）执行一步覆盖。
|
||||
|
||||
---
|
||||
|
||||
## 一、本轮判定（一句话 · 第 6 棒 21:49 · *历史*）
|
||||
|
||||
**目标未完成**；但**第一棒已在册**（21:55 触发）⇒ 本轮**不派新棒、不改生命周期**（保持「进行中」）。
|
||||
|
||||
判据取自三路并集（任一路有非 done／非过就是没完）：
|
||||
|
||||
- ① 台账 `tasks.json`：6 条**全部 `done`**，队列空、无僵尸件（`collabd-state.json`：pending 0 / running 0 / done 6 / blocked 0）。
|
||||
⚠️ 但这 6 条**全属旧目标**（`goal_fp = 5199a6`），**本目标一条记录都没有**。
|
||||
- ② 任务图 `tmp/supervise-inbox/taskgraph.json`：**文件不存在** ⇒ 无节点可判（无 `status != done`）。
|
||||
- ③ 验收判据 `goal.json.acceptance_state`：5 条**全部「未过」**。
|
||||
- ④ 决定性一路：**在册执行排期** `[执行]-[开源项目调研]-重写竞品独立分析体`（id `4e470d4c`，once，**21:55 触发**，`cwds` 逐字等于本工作区）⇒ **活有人干**。
|
||||
|
||||
## 二、验收判据现状（来源＝`goal.json`，⛔ 不是文档）
|
||||
|
||||
逐条读到的值如下，**没有一条是「过」**：
|
||||
|
||||
- 5份竞品分析已按独立分析体重写 —— 未过
|
||||
- 1b汇总对比体与独立体职责边界正确 —— 未过
|
||||
- 受影响的1a需求文档条目已逐条复核 —— 未过
|
||||
- MCN需求文档已重新生成 —— 未过
|
||||
- 产物全部落在本目标目录内 —— 未过
|
||||
|
||||
⚠️ **两处失真，须记账**：
|
||||
|
||||
1. 值写作「未过」，**不在规范取值域**（规范是 `过｜…` 或 `🔴 不过｜…`）
|
||||
⇒ 机器分不出「还没判」与「判了没过」。这 5 条是**换目标（2026-10-07T21:47）时落下的占位值**，**无一条带依据**。
|
||||
2. 它们与实况**部分不符**：`[执行]-[开源项目调研]-重写竞品独立分析体` 的 prompt 里写明「Easel 那份**已经重写完成**（232 行）」
|
||||
⇒ 至少第 1 条判据的**一部分已完成**，但判据是粗粒度整条，读不出这个中间态。
|
||||
|
||||
## 三、判据缺口 —— 本轮做不了「逐条读文档对账」
|
||||
|
||||
- 派活原文指定的**唯一依据文档** `执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/目标执行状态.md`
|
||||
在本轮开始时**不存在**（整目录不存在）⇒ 那个路径下**读不到任何结论行**。
|
||||
- `goal.json` 的 `execution_doc` 字段**指向另一个目标**：
|
||||
`执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/目标执行状态.md`。
|
||||
那份文档的 H1 是**旧目标**、判据也**全是旧目标的 5 条**（且全「过」）⇒ **不能拿来判本目标**。
|
||||
- ⇒ 根因（代码级，非推断）：`collabd.py::_ensure_goal_dir()` 里那段 `doc_sync`
|
||||
职责正是「换目标后把 `execution_doc` 对齐到 `exec_dir_rel()` 的真值」，
|
||||
而本区**从未在换目标后跑过 `--ensure-goal-dir`** ⇒ 登记值停在旧目标上。
|
||||
|
||||
## 四、本轮为什么没有替它修（⚠️ 不是遗漏，是有代价）
|
||||
|
||||
- ❌ 本轮**不能**用 `collabd.py --ensure-goal-dir` 去修上面这个漂移。
|
||||
原因：`_ensure_goal_dir()` 末尾有「**顺手登记主会话**」那一段，
|
||||
而本区 `collabd-state.json` 的 `roles` 是**空对象**（没有任何 main）⇒
|
||||
跑它会把**本检查会话登记成主会话**（还会降级别人）⇒ 机制级污染。
|
||||
- ✅ 正确修法：由**本区主会话**（或任何**应该占 main 席位**的会话）跑一次
|
||||
`python .workbuddy/collab/collabd.py --ensure-goal-dir`（幂等、⛔ 不覆盖已有文档）。
|
||||
它会一并完成两件事：① 建目标目录并落状态文档骨架 ② 把 `execution_doc` 对齐到真值。
|
||||
- 本份文档是我**手工建立**的，就是为了让上面那条自动对齐**不会覆盖**它（幂等语义），
|
||||
并让下一棒检查会话有东西可读。
|
||||
|
||||
## 五、派活原文与实况的偏差（供机制侧记账）
|
||||
|
||||
- 派活原文写的前提是「**本项目没有别的待执行排期**」——**与实况不符**：
|
||||
21:47:05 建本检查会话那一刻起，`[执行]-[开源项目调研]-重写竞品独立分析体`（21:55）就已在册。
|
||||
- ⇒ 常驻 `maybe_spawn_check_agent()` 那道「无待执行排期」闸**没拦住**，
|
||||
本检查会话因此是一次**空跑**（没有任何可判的新事实）。
|
||||
⚠️ 只报现象，未去查闸的实现（本轮只做核对，⛔ 不扩面）。
|
||||
|
||||
## 六、一处内部不一致（会在收口时变成永久红）
|
||||
|
||||
- 本目标验收判据第 5 条是「**产物全部落在本目标目录内**」，
|
||||
而 21:55 那棒被指定的落点是**旧目标目录**：
|
||||
`执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/docs/pm/content-workbench/证据附卷/`
|
||||
（`--report --artifact` 也指这里）。
|
||||
- ⇒ 两者按字面**互斥**：要么「本目标目录」指的是 `5199a6` 那个目录（那第 5 条该改措辞），
|
||||
要么该棒落点该改到 `72111e`。**本轮不擅改**，留给主会话／用户定。
|
||||
|
||||
## 七、下一棒该做什么
|
||||
|
||||
- **不派**。21:55 的 `[执行]-[开源项目调研]-重写竞品独立分析体` 就是下一棒，跑完由常驻按台账与判据继续判。
|
||||
- 主会话需先处理两条（都在上面 §四 §六）：跑一次 `--ensure-goal-dir`；裁定第 5 条判据与落点口径。
|
||||
Reference in new issue
Block a user