pm-workflow-studio 0.1.1 → 0.1.2

package/.claude/skills/ui-prototype-design/templates/prototype-review.md

@@ -18,10 +18,10 @@
 
 ## Playwright 截图证据
 
-| 页面 | 桌面 1440x900 | 平板 834x1112 | 移动 390x844 | 控制台错误 |
-|---|---|---|---|---|
-| prototype/directions/index.html | 待补充 | 待补充 | 待补充 | 待补充 |
-| prototype/index.html | 待补充 | 待补充 | 待补充 | 待补充 |
+| 页面 | B 端最小 1280x800 | 默认桌面 1440x900 | 宽屏 1920x1080 | 平板/移动补充 | 控制台错误 |
+|---|---|---|---|---|---|
+| prototype/directions/index.html | 待补充 | 待补充 | 适用时补充 | 非 B 端或响应式需要时补充 | 待补充 |
+| prototype/index.html | 待补充 | 待补充 | 适用时补充 | 非 B 端或响应式需要时补充 | 待补充 |
 
 截图目录：`prototype/review/screenshots/`
 
@@ -39,6 +39,21 @@
 | harden | 长文本、空数据、错误、加载、异常路径 | 待补充 | 待补充 |
 | polish | 最终综合打磨 | 待补充 | 待补充 |
 
+## B 端规范抽检记录
+
+仅在项目被识别为 B 端网页时填写；只记录本次自审实际用到的规范章节和验收标准，不粘贴整份参考文档。
+
+| 检查阶段 | 规范章节 | 验收标准/禁止事项 | 截图或页面证据 | 处理结果 |
+|---|---|---|---|---|
+| 识别和边界 | `使用原则` | 待补充 | docs/ui-design.md | 待补充 |
+| 风格和配色 | `配色流程与色彩系统规则` | 待补充 | 方向 demo 截图 | 待补充 |
+| 画布和密度 | `画布与适配`、`B 端适配与响应式规则` | 待补充 | 1280/1440 截图 | 待补充 |
+| 信息架构和动线 | `格式塔设计原则`、`视觉动线与页面布局模型规则` | 待补充 | 页面截图或访问路径 | 待补充 |
+| 页面模式和数据页面 | `基础组件体系与布局参数规则`、`后台数据页面补充规则` | 待补充 | 表格/筛选/详情页面截图 | 待补充 |
+| 组件和视觉表现 | `视觉层级与组件表现规则`、`后台界面质感细节规则` | 待补充 | 组件、表单、弹窗截图 | 待补充 |
+| 交互流程和状态 | `交互效率与认知负荷规则`、`尼尔森可用性原则补充规则`、`包容性与可理解性补充规则` | 待补充 | 操作路径、错误、空、加载截图 | 待补充 |
+| 问题反查修正 | 对应章节的 `禁止事项` 和 `验收标准` | 待补充 | 修正前后截图 | 待补充 |
+
 ## 已修正问题
 
 | 问题 | 来源 | 修正位置 | 复查结果 |

package/.claude/skills/ui-prototype-design/templates/ui-design.md

@@ -18,8 +18,28 @@
 
 - 页面可见文案、按钮、导航、空状态和提示语禁止使用 emoji。
 - 图标必须使用图标库、SVG 或图片资源，不用 emoji 代替。
-- 正文、表单、按钮、列表文本默认不小于 16px。
-- 辅助说明可小于 16px，但不得低于 14px；移动端优先保持 16px 起。
+- 通用 Web 和移动端正文、表单、按钮、列表文本默认不小于 16px。
+- B 端网页、后台、运营台、管理系统和 SaaS 产品优先遵循 B 端设计规范的文字、间距和控件参数，不强行套用移动端 16px 起规则。
+
+## B 端规范引用记录
+
+- 是否识别为 B 端网页：
+- 判断依据：
+- 章节索引检查：`rg -n "^##|^###" references/b-end-ui-design-spec.md`
+- 本阶段已按需读取的规范章节：
+- 已落入原型的规则：
+- 未采用或偏离规范的原因：
+
+| 阶段门禁 | 已引用章节 | 采用规则 | 对应设计动作 | 状态 |
+|---|---|---|---|---|
+| 识别和边界 | `使用原则` | 待补充 | 判断是否默认应用 B 端规范，记录偏离原因 | 待确认 |
+| 风格和配色 | `配色流程与色彩系统规则` | 待补充 | 先明确品牌调性和产品风格，再做灰度和色彩 token | 待确认 |
+| 画布和密度 | `画布与适配`、`页面基础参数`、`栅格与间距`、`B 端适配与响应式规则` | 待补充 | 按 `1440x900` 设计并校验 `1280x800` 核心内容 | 待确认 |
+| 页面清单和信息架构 | `格式塔设计原则`、`视觉动线与页面布局模型规则` | 待补充 | 按页面类型选择动线，组织分组、对齐和重复结构 | 待确认 |
+| 页面模式和布局骨架 | `基础组件体系与布局参数规则`、`后台数据页面补充规则` | 待补充 | 确定页面模式、固定区、自适应区、表格和筛选骨架 | 待确认 |
+| 组件和视觉表现 | `文本参数`、`图标参数`、`按钮参数`、`输入框参数`、`视觉层级与组件表现规则`、`后台界面质感细节规则` | 待补充 | 收敛字号、间距、控件高度、层级和质感细节 | 待确认 |
+| 交互流程和状态 | `交互效率与认知负荷规则`、`尼尔森可用性原则补充规则`、`包容性与可理解性补充规则` | 待补充 | 补齐反馈、防错、错误修正、权限异常、加载超时和帮助入口 | 待确认 |
+| 原型自审和修正 | 问题对应章节的 `禁止事项` 和 `验收标准` | 待补充 | 根据截图问题反查规范并修正 | 待确认 |
 
 ## 设计方向候选
 
@@ -136,6 +156,8 @@ prototype/
 | 审查项 | 要求 | 状态 |
 |---|---|---|
 | Playwright 截图 | 候选 demo 和完整原型页面覆盖 desktop/tablet/mobile | 待确认 |
+| B 端适配截图 | B 端项目至少覆盖 `1280x800` 和 `1440x900` 核心路径 | 待确认 |
+| B 端规则落地 | 已采用规则必须体现为真实布局、字号、间距、控件高度、状态和响应式实现 | 待确认 |
 | Impeccable critique | 审美、视觉层级、信息架构、AI 味、认知负荷 | 待确认 |
 | Impeccable audit | 可访问性、性能、响应式、语义结构、反模式 | 待确认 |
 | Impeccable adapt | 桌面、平板、移动适配 | 待确认 |

package/.codex/SKILL.md

@@ -182,26 +182,27 @@ Claude Code 结构会创建 `.claude/CLAUDE.md`、`.claude/settings.json`、`.cl
 
 在用户确认前，禁止启动 `product_manager`、`demand_analyst` 或其他子 agent 做需求澄清；禁止把“我总结一下再让子 agent 问你”作为默认流程。若后续需要子 agent 做文档沉淀，必须传递完整用户原话、关键问答记录、未确认假设和待补材料，且不得让子 agent 覆盖用户已确认的表达。
 
-随后只问 3-5 个最关键的问题，必须用普通用户能懂的话，并允许用户“不用一次性全回答，想到什么说什么就行”。问题必须内嵌“高频真实需求”和“真实使用流程”，因为这决定后续需求分析能否识别真需求、剔除伪需求，也决定 UI 页面访问逻辑是否简单易懂。问题默认覆盖：
+随后进入顾问式澄清，而不是直接给完整方案、技术栈或一长串平台推荐。每轮最多问 3 个问题，必须用普通用户能懂的话，并允许用户“不用一次性全回答，想到什么说什么就行”。问题不是固定问卷，主 agent 要先判断当前最大不确定点，再沿着下面的优先级追问：
 
-1. 谁会最常用这个产品？是你自己、某类用户，还是团队里的某个角色？
-2. 他们最频繁、最反复要完成的事情是什么？什么情况下会打开它？
-3. 从打开产品到完成这件事，真实步骤通常是怎样的？现在用什么方式替代？
-4. 你想在什么设备或平台上用？
-5. 除了高频核心流程，还有特别想要的功能吗？哪些可以合并、后置或暂不做，避免页面/模块太多看不懂？
-6. 有没有用过类似产品觉得不错或不喜欢？如环境允许，AI 主动搜索 2-4 个类似产品作参考；如无法联网，说明无法实时搜索，并用本地经验示例且标记待确认。
+1. **解决什么问题**：谁遇到了什么麻烦，为什么现在值得做。
+2. **哪一段最值得先做**：完整想法里哪一小段流程最频繁、最痛、最能验证价值。
+3. **需要什么能力**：如果这是一个 Agent，它需要看懂什么输入、做什么判断、调用什么动作或产出什么内容。
+4. **结果落到哪里**：最终结果是落到文档、表格、任务、消息、系统动作、页面状态，还是交给人确认。
+5. **最小可用 demo**：只保留能证明价值的一条闭环，主动识别可以合并、后置或暂不做的能力。
+
+不要一次性展开很多功能；不要把“可做的东西”当成“首版该做的东西”。如果用户的问题本身还模糊，优先帮用户做需求判断和取舍：这个想法最像在解决哪类问题、第一版该验证哪段流程、哪些能力只是以后扩展。
 
 需求澄清必须包含“术语与概念对齐”。主 agent 遇到用户提到的专业词、行业词、产品形态、技术词或容易多义的普通词时，必须先用白话复述自己的理解，再问用户是不是这个意思；主 agent 自己描述需求时，也要解释关键概念，避免用户表面点头但实际理解不同。典型句式是：“你说的 xxx，我先按 yyy 理解；如果你指的是 zzz，那方案会不一样，我理解得对吗？”
 
-澄清完成标准固定为 8 项：
+澄清完成不是机械填表，而是判断是否已经足够收束出一个最小可用 demo。默认检查 8 个判断锚点：
 
 1. 产品给谁用。
 2. 用户真正的高频需求是什么。
 3. 解决什么场景问题。
-4. 用户想达成什么结果。
-5. 用户从开始到结束的真实使用流程是什么。
+4. 用户想达成什么结果，结果最终落到哪里。
+5. 用户从开始到结束的真实使用流程是什么，哪一段最值得先做。
 6. 首版平台与使用设备。
-7. MVP 必须做和暂不做边界，包括功能整合和页面/模块减负原则。
+7. 最小可用 demo 必须做和暂不做边界，包括能力合并、页面/模块减负和人工兜底原则。
 8. 无阻塞开放问题，包括关键术语和概念没有歧义。
 
 只有 8 项均有答案、关键术语概念已经对齐，并且用户确认“我理解得对”，才能把 `docs/workflow-state.json` 中 `clarification.status` 更新为 `user_confirmed`，把 `clarification.concepts_aligned` 设为 `true`，把 `user_confirmation_required` 设为 `false`，并推荐进入 `analyze`。内部判断通过、文档已写好、审核通过都不等于用户确认。
@@ -209,11 +210,11 @@ Claude Code 结构会创建 `.claude/CLAUDE.md`、`.claude/settings.json`、`.cl
 产品经理继续补齐六个核心问题：
 
 1. 产品是什么，解决什么问题，谁会使用？
-2. 面向什么平台：网页、应用、桌面端、小程序或其他载体？
-3. 用户打开产品后的高频核心场景和真实使用流程是什么？
-4. 用户最反复要完成的真实需求是什么，触发点是什么？
-5. 有哪些参考产品或反向参考？
-6. 必须包含什么，明确不包含什么？哪些能力需要合并或后置来减少用户使用成本？
+2. 当前最值得先做的是哪一段真实流程，为什么。
+3. 如果它是 Agent，必须具备哪些输入理解、判断、执行和产出能力。
+4. 结果落到哪里，用户如何确认它完成得对不对。
+5. 首版运行载体是什么：网页、应用、桌面端、小程序、聊天入口、自动化脚本或其他。
+6. 最小 demo 必须包含什么，明确不包含什么，哪些能力需要合并、后置或人工兜底。
 
 产物：`docs/project-config.md`。
 

package/.codex/agents/product-manager.toml

@@ -38,27 +38,28 @@ developer_instructions = """
 你说的 xxx 产品，核心就是：xxx
 ```
 
-然后用朋友聊天的方式问 3-5 个关键问题，避免专业黑话。问题必须摸清谁在高频使用、为什么反复使用、从开始到完成的真实流程是什么；这是后续识别真需求、剔除伪需求、减少页面和功能成本的依据。默认覆盖：
+然后用朋友聊天的方式做顾问式澄清，避免专业黑话。不要直接给完整方案，不要先推荐很多平台，每轮最多问 3 个问题。你要先判断当前最大不确定点，再围绕这些方向追问：
 
-1. 谁最常用，是自己、某类用户，还是团队里的某个角色。
-2. 他们最频繁、最反复要完成的事情是什么，什么情况下会打开产品。
-3. 从打开产品到完成这件事，真实步骤通常怎样，现在用什么方式替代。
-4. 想在什么设备或平台上用。
-5. 除了高频核心流程，还有什么特别想要；哪些可以合并、后置或暂不做，避免页面/模块太多看不懂。
-6. 有没有用过类似产品觉得不错或不喜欢；如环境允许，主动搜索 2-4 个类似产品作参考。无法联网时要说明，并把本地经验示例标记为待确认。
+1. 解决什么问题：谁遇到了什么麻烦，为什么现在值得做。
+2. 哪一段最值得先做：完整想法里哪一小段流程最频繁、最痛、最能验证价值。
+3. 需要什么 Agent 能力：它要看懂什么输入、做什么判断、调用什么动作或产出什么内容。
+4. 结果落到哪里：文档、表格、任务、消息、系统动作、页面状态，还是交给人确认。
+5. 最小可用 demo：只保留能证明价值的一条闭环，主动识别可以合并、后置或暂不做的能力。
+
+不要一次性展开很多功能；不要把“可做的东西”当成“首版该做的东西”。如果用户的问题本身还模糊，优先帮用户做需求判断和取舍。
 
 还必须做术语与概念对齐：凡是用户提到专业术语、行业概念、产品形态、技术词或多义词，都要用白话复述你的理解，并请用户确认是不是同一个意思；你主动使用的关键概念，也要解释清楚，不能让用户带着误解进入下一阶段。
 
-澄清完成标准固定 8 项：产品给谁用、用户真正的高频需求、解决什么场景问题、用户想达成什么结果、用户从开始到结束的真实使用流程、首版平台与使用设备、MVP 必做和暂不做边界（包括功能整合和页面/模块减负原则）、无阻塞开放问题（包括关键术语和概念没有歧义）。8 项都满足且 `clarification.concepts_aligned=true` 后，必须请用户确认“我理解得对不对”。只有用户明确确认后，才能把 `clarification.status` 设为 `user_confirmed`，把 `completion_criteria.high_frequency_need` 和 `completion_criteria.core_usage_flow` 设为 `true`，把 `user_confirmation_required` 设为 `false`。
+澄清完成不是机械填表，而是判断是否足够收束出一个最小可用 demo。默认检查 8 个判断锚点：产品给谁用、用户真正的高频需求、解决什么场景问题、用户想达成什么结果以及结果落点、用户从开始到结束的真实使用流程以及最值得先做的一段、首版平台与使用设备、最小可用 demo 必做和暂不做边界（包括能力合并、页面/模块减负和人工兜底原则）、无阻塞开放问题（包括关键术语和概念没有歧义）。8 项都满足且 `clarification.concepts_aligned=true` 后，必须请用户确认“我理解得对不对”。只有用户明确确认后，才能把 `clarification.status` 设为 `user_confirmed`，把 `completion_criteria.high_frequency_need` 和 `completion_criteria.core_usage_flow` 设为 `true`，把 `user_confirmation_required` 设为 `false`。
 
 ## 6 个核心问题
 
 1. 产品是什么：一句话描述想做什么、解决什么问题、给谁用。
-2. 平台类型：Web / App / 桌面 / 小程序 / 其他。
-3. 核心场景和高频流程：用户为什么反复打开、打开后从开始到结束做哪几步。
-4. 高频真实需求：用户最反复要完成的事情和触发点。
-5. 参考产品：有没有类似产品或明确不喜欢的产品。
-6. 特殊要求：必须有的功能 / 绝对不想要的东西 / 必须合并或后置的低频功能。
+2. 首段流程：当前最值得先做的是哪一段真实流程，为什么。
+3. Agent 能力：必须具备哪些输入理解、判断、执行和产出能力。
+4. 结果落点：结果落到哪里，用户如何确认它完成得对不对。
+5. 运行载体：网页、应用、桌面端、小程序、聊天入口、自动化脚本或其他。
+6. Demo 边界：必须有的功能 / 绝对不想要的东西 / 需要合并、后置或人工兜底的能力。
 
 ## 对话原则
 

package/.codex/agents/quality-reviewer.toml

@@ -19,7 +19,7 @@ node .agents/skills/pm-workflow/scripts/review_stage.js --root . --stage <init|a
 
 ## 新增硬检查
 
-- `init` 阶段：必须确认 `workflow-state.json` 中 `clarification.status=user_confirmed`，`user_confirmation_required=false`，`clarification.concepts_aligned=true`，并且 8 项澄清完成标准均为 true。尤其是 `high_frequency_need` 和 `core_usage_flow` 必须完成，否则不能判定通过。
+- `init` 阶段：必须确认 `workflow-state.json` 中 `clarification.status=user_confirmed`，`user_confirmation_required=false`，`clarification.concepts_aligned=true`，并且 8 个判断锚点均为 true。尤其是 `high_frequency_need`、`core_usage_flow`、结果落点、最值得先做的一段和最小可用 demo 边界必须清楚，否则不能判定通过。
 - `analyze` 阶段：PRD 必须是最终稿，不能仍为 draft，`待用户回答问题` 不能存在未回答阻塞项，`pending_user_questions` 必须为空。草稿阶段不能触发通过。
 - `analyze` 阶段：必须检查 PRD 是否基于高频真实需求和真实使用流程识别真需求与伪需求，P0 功能是否映射到高频场景和流程位置，是否避免功能清单堆叠。
 - `design` 阶段：UI 可见内容不能使用 emoji；正文、表单、按钮、列表文本默认不小于 16px，辅助说明不得低于 14px。

package/.codex/references/commands/init.md

@@ -26,12 +26,12 @@
    `🤖 AI产品开发工作室已就绪`
    `朋友你好！我是你的产品经理，会带着你一步步把想法变成现实。`
    然后用普通用户能听懂的话确认“我理解得对不对”。
-3. 主 agent 基于当前对话上下文亲自执行需求澄清协议：每轮只问 3-5 个关键问题，必须覆盖谁最常用、用户真正的高频需求、打开产品的触发点、从开始到结束的真实使用流程、设备/平台、类似产品或反向参考、必须做和可以合并/后置/暂不做的功能。用户不用一次性全答，想到什么说什么即可。
+3. 主 agent 基于当前对话上下文亲自执行顾问式需求澄清：不要直接给完整方案，不要先推荐很多平台，每轮最多问 3 个问题。先判断当前最大不确定点，再围绕“解决什么问题、哪一段最值得先做、需要什么 Agent 能力、结果落到哪里、如何收束成最小可用 demo”追问。用户不用一次性全答，想到什么说什么即可。
 4. 做术语与概念对齐：用户提到专业词、行业词、产品形态、技术词或容易多义的普通词时，先用白话复述你的理解，再请用户确认是不是同一个意思；你主动描述需求时，也要解释关键概念，不能默认用户和 AI 使用同一套定义。
-5. 如环境允许，主动搜索 2-4 个类似产品作参考；如无法联网，说明无法实时搜索，并把本地经验示例标记为待确认。
-6. 按 8 项澄清完成标准检查：产品给谁用、用户真正的高频需求、解决什么场景问题、用户想达成什么结果、用户从开始到结束的真实使用流程、首版平台与使用设备、MVP 必做和暂不做边界（包括功能整合和页面/模块减负原则）、无阻塞开放问题（包括关键术语和概念没有歧义）。
+5. 竞品或平台参考只在能帮助用户做取舍时使用；不要把参考产品、平台、技术路线提前展开成方案。如环境允许，可搜索 2-4 个类似产品作参考；如无法联网，说明无法实时搜索，并把本地经验示例标记为待确认。
+6. 按 8 个判断锚点检查是否足够收束：产品给谁用、用户真正的高频需求、解决什么场景问题、用户想达成什么结果以及结果落点、用户从开始到结束的真实使用流程以及最值得先做的一段、首版平台与使用设备、最小可用 demo 必做和暂不做边界（包括能力合并、页面/模块减负和人工兜底原则）、无阻塞开放问题（包括关键术语和概念没有歧义）。
 7. 只有 8 项达标、`clarification.concepts_aligned=true` 并且用户明确确认后，才将 `clarification.status` 写为 `user_confirmed`，`completion_criteria.high_frequency_need=true`、`completion_criteria.core_usage_flow=true`、`user_confirmation_required=false`，`recommended_next=analyze`；否则保持 `user_confirmation_required=true`，把缺口写入 `clarification.missing_context`、`clarification.terminology` 和 `pending_user_questions`。
-8. 沉淀产品定位、目标用户、使用人群、高频真实需求、使用触发点、真实使用流程、页面访问逻辑约束、功能整合原则、平台类型、核心场景、参考产品、术语概念表、必须有功能、明确不要的内容和工作量粗估。
+8. 沉淀产品定位、目标用户、使用人群、高频真实需求、使用触发点、真实使用流程、最值得先做的一段、Agent 能力边界、结果落点、最小 demo 闭环、页面访问逻辑约束、功能整合原则、平台类型、核心场景、参考产品、术语概念表、必须有功能、明确不要的内容和工作量粗估。
 9. 写入或更新 `docs/project-config.md`。
 10. 更新 `docs/workflow-state.json`，设置 `current_stage=init`，记录 `project-config.md` 产物，并把 `recommended_next` 设置为 `clarify init`、`review init` 或 `analyze`。
 

package/.codex/role-skills/quality-review/SKILL.md

@@ -38,7 +38,7 @@ node .agents/skills/pm-workflow/scripts/review_stage.js --root . --stage <stage>
 - 是否存在待补充、待办占位或空表。
 - init 阶段是否已经在 `workflow-state.json` 中达到 `clarification.status=user_confirmed`、`clarification.concepts_aligned=true`，且 8 项澄清标准均完成。
 - analyze 阶段是否为 `文档状态：final`，并且没有未回答的阻塞问题。
-- init 阶段 8 项澄清完成标准是否全部完成，尤其是高频真实需求和真实使用流程。
+- init 阶段 8 个判断锚点是否全部完成，尤其是高频真实需求、最值得先做的一段流程、Agent 能力、结果落点和最小可用 demo 边界。
 - analyze 阶段是否基于高频真实需求和真实使用流程识别真需求与伪需求，P0 是否映射到高频场景和流程位置。
 - design 阶段 UI 可见内容是否使用 emoji，主体字号是否低于 16px。
 - design 阶段页面访问逻辑是否来自真实使用流程，页面和模块是否避免堆叠并记录整合理由。

package/.codex/role-skills/ui-prototype-design/SKILL.md

@@ -19,8 +19,44 @@ description: "界面设计师使用：选择设计方向、编写界面与体验
 
 - 页面可见文案、按钮、导航、空状态和提示语禁止使用 emoji。
 - 图标必须使用图标库、SVG 或图片资源，不用 emoji 代替。
-- 正文、表单、按钮、列表文本不小于 16px。
-- 辅助说明可小于 16px 但不得低于 14px；移动端优先保持 16px 起。
+- 通用 Web 和移动端正文、表单、按钮、列表文本不小于 16px；移动端优先保持 16px 起。
+- B 端网页、后台、运营台、管理系统和 SaaS 产品必须优先遵循 `references/b-end-ui-design-spec.md` 的文字、间距和控件参数，不强行套用 16px 起的移动端规则。
+- B 端常规正文可按规范使用 `13-16`，注释和辅助信息可按规范使用 `10-13`；但核心正文、主操作、关键状态必须清晰可读，不得为了信息密度牺牲可读性。
+
+## B 端设计规范渐进读取
+
+当需求、PRD、架构或用户描述出现后台、管理系统、运营台、SaaS、工作台、CRM、ERP、数据看板、审批、配置、权限、表格、列表、筛选、批量操作等信号时，默认按 B 端网页处理，并引用 `references/b-end-ui-design-spec.md`。
+
+不要在 UI 阶段一开始完整读取整份 B 端参考文档。必须先用 `rg -n "^##|^###" references/b-end-ui-design-spec.md` 查看章节索引，再按当前阶段只读取必要章节；只有当某个设计决策需要参数、禁止事项或验收标准时，才读取对应段落。
+
+B 端规范是阶段门禁，不是可选灵感：一旦识别为 B 端网页，每个阶段都必须按下表读取对应章节、应用设计动作，并在 `docs/ui-design.md` 或 `docs/prototype-review.md` 记录采用结果。若因业务特殊而偏离，必须写明偏离原因和替代规则。
+
+| 阶段门禁 | 使用时机 | 只读取的规范章节 | 必须完成的设计动作 |
+|---|---|---|---|
+| 识别和边界 | UI 阶段开始、读取 PRD 和架构后 | `使用原则` | 判断是否为 B 端；确认是否按 B 端默认规范执行；非 B 端或局部偏离必须记录原因。 |
+| 风格和配色 | 推荐设计方向、确定视觉气质前 | `配色流程与色彩系统规则` | 先明确品牌调性和产品风格，再做灰度层级和色彩 token；不得先靠颜色解决结构问题。 |
+| 画布和密度 | 生成 2-3 个方向 demo 前 | `画布与适配`、`页面基础参数`、`栅格与间距`、`B 端适配与响应式规则` | 默认按 `1440x900` 构思，必须检查 `1280x800` 核心内容可用，`1920x1080` 只做增强。 |
+| 页面清单和信息架构 | 推导访问逻辑、合并页面和模块 | `格式塔设计原则`、`原则到设计动作速查`、`视觉动线与页面布局模型规则`、`视觉动线速查` | 用邻近性、相似性、连续性组织信息，并按页面类型选择 F 型、古腾堡或 Z 型动线。 |
+| 页面模式和布局骨架 | 设计导航、主内容、详情栏、筛选区、弹窗和固定区 | `基础组件体系与布局参数规则`、`B 端适配与响应式规则`、`后台数据页面补充规则` | 先确定页面模式、固定区、自适应区和主内容栅格，再画具体页面。 |
+| 组件和视觉表现 | 设计表单、表格、卡片、按钮、输入框、导航、标签 | `字体选择`、`文本参数`、`图标参数`、`按钮参数`、`输入框参数`、`视觉层级与组件表现规则`、`后台界面质感细节规则` | 收敛字号、间距、控件高度、状态样式和后台适用细节，保证开发可还原。 |
+| 交互流程和状态 | 设计创建、筛选、审批、批量、保存、上传、删除等路径 | `交互效率与认知负荷规则`、`交互规则速查`、`尼尔森可用性原则补充规则`、`包容性与可理解性补充规则` | 降低寻找、选择和记忆成本；补齐状态反馈、错误修正、权限异常、加载超时和帮助入口。 |
+| 原型自审和修正 | Playwright 截图后、Impeccable 审查前后 | 暴露问题对应章节中的 `禁止事项` 和 `验收标准` | 只按问题读取对应段落并修正；每个未通过项必须回到对应规范章节复查，不做整份文档复述。 |
+
+阶段化读取方法：
+
+- 开始阶段：只读章节索引和当前阶段涉及的 `##` 章节。
+- 做具体决策：用 `rg -n "关键词" references/b-end-ui-design-spec.md` 定位具体 `###` 小节，再读取该小节上下文。
+- 写入文档：只摘录实际采用的规则、设计动作和偏离原因，不复制整段规范。
+- 做原型：把已采用规则转换为布局、字号、间距、控件高度、状态、交互和响应式实现。
+- 自审修正：用截图问题反查对应章节的 `禁止事项` 和 `验收标准`，修正后记录证据。
+
+B 端规范引用要求：
+
+- 在 `docs/ui-design.md` 只记录被采用的关键规则和设计取舍，不粘贴整份参考文档。
+- 在 `docs/prototype-review.md` 只记录与截图问题相关的验收标准，不写泛泛的规范摘要。
+- 如果页面不是 B 端网页，例如 C 端营销页、移动 App、游戏或大屏展示，不默认套用 B 端规范；需要使用时必须说明原因。
+- 当 B 端规范与通用审美建议冲突时，以业务效率、信息密度、对齐、复用和可开发还原优先。
+- 不得因为未完整读取参考文档而跳过规范；应按阶段最小读取、持续遵守、按问题补读。
 
 ## 输出
 
@@ -32,18 +68,19 @@ description: "界面设计师使用：选择设计方向、编写界面与体验
 ## 设计流程
 
 1. 先做上游前置审查，确认高频真实需求、使用人群和真实使用流程清晰；发现歧义先报告。
-2. 推荐 2-3 个差异化设计方向。
-3. 为每个方向生成一个可打开的首页 demo，放在 `prototype/directions/`，并生成 `prototype/directions/index.html` 作为预览索引。
-4. 在 `docs/ui-design.md` 中写清每个方向的 demo 路径；没有 demo 的方向不得交给用户选择。
-5. 等用户选择，或在用户明确授权后使用第一推荐。
-6. 从真实使用流程推导页面访问逻辑，页面数量以完成高频路径为准。
-7. 设计页面清单、布局、组件、状态和流程；页面模块不能堆叠过多，能合并的入口、状态、表单、列表、详情必须合并。
-8. 基于选定方向构建完整高保真 HTML 原型。
-9. 在 `docs/ui-design.md` 记录页面访问逻辑和模块整合理由。
-10. 使用 Playwright 对候选 demo 和完整原型逐页截图，覆盖 desktop/tablet/mobile。
-11. 使用 Impeccable 做专项审查和修正，最多两轮。
-12. 写入 `docs/prototype-review.md`，记录截图证据、审查结论、修正项和遗留问题。
-13. 如 UI 决策改变上游事实，回写上游文档并记录同步说明。
+2. 判断是否为 B 端网页；如果是，先查 `references/b-end-ui-design-spec.md` 章节索引，并在 `docs/ui-design.md` 建立 B 端规范引用记录。
+3. 推荐 2-3 个差异化设计方向；B 端项目在推荐前必须读取配色、画布、密度和适配相关章节。
+4. 为每个方向生成一个可打开的首页 demo，放在 `prototype/directions/`，并生成 `prototype/directions/index.html` 作为预览索引。
+5. 在 `docs/ui-design.md` 中写清每个方向的 demo 路径和已采用的 B 端规则；没有 demo 的方向不得交给用户选择。
+6. 等用户选择，或在用户明确授权后使用第一推荐。
+7. 从真实使用流程推导页面访问逻辑，页面数量以完成高频路径为准；B 端项目必须读取信息架构和视觉动线章节。
+8. 设计页面清单、布局、组件、状态和流程；B 端项目必须按阶段读取页面模式、布局骨架、数据页面、组件表现和交互状态章节。
+9. 基于选定方向构建完整高保真 HTML 原型；已采用的 B 端规则必须落成真实布局、字号、间距、控件高度、状态和响应式实现。
+10. 在 `docs/ui-design.md` 记录页面访问逻辑、模块整合理由、B 端规范采用结果和偏离说明。
+11. 使用 Playwright 对候选 demo 和完整原型逐页截图，B 端项目必须覆盖 `1280x800`、`1440x900`，必要时补 `1920x1080`；非 B 端按实际设备覆盖 desktop/tablet/mobile。
+12. 使用 Impeccable 做专项审查和修正，最多两轮；B 端项目必须把发现问题反查到对应 B 端规范章节的禁止事项和验收标准。
+13. 写入 `docs/prototype-review.md`，记录截图证据、审查结论、B 端规范抽检、修正项和遗留问题。
+14. 如 UI 决策改变上游事实，回写上游文档并记录同步说明。
 
 ## Impeccable 使用清单
 
@@ -116,8 +153,13 @@ prototype/
 - 页面访问逻辑是否来自真实使用流程。
 - 页面数量和模块数量是否服务高频路径，而不是堆叠低频功能。
 - 能合并的入口、状态、表单、列表、详情是否已经合并并记录理由。
+- B 端项目是否已识别并按阶段引用 `references/b-end-ui-design-spec.md`，而不是一次性完整读取。
+- B 端项目是否完成识别、配色、画布、信息架构、布局骨架、组件表现、交互状态和自审修正的阶段门禁。
+- B 端项目是否在 `docs/ui-design.md` 和 `docs/prototype-review.md` 记录实际采用的规范章节、设计动作、偏离原因和验收结果。
+- B 端项目是否把规范落成真实原型实现，而不是只在文档中引用。
 - 设计方向是否都有可打开的首页 demo，而不是只有文字说明。
 - 是否有 Playwright 截图证据并覆盖 desktop/tablet/mobile。
+- B 端项目是否至少检查 `1280x800` 与 `1440x900` 下的核心路径。
 - 是否完成 Impeccable 审查、修正和复查记录。
 - 是否沉淀了可复用布局，并能支撑后续开发稳定复现。
 - 成功、失败、空、加载状态是否覆盖。