hiui-refine

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

HiUI 页面需求细化

HiUI Page Requirement Refinement

版本信息

Version Information

当前版本：
```
2.0.0
```
更新时间：
```
2026-07-16
```
版本定位：HiUI Page Workflow 家族化命名版本
本次升级摘要：
- canonical skill 名已统一为
```
hiui-refine
```
- 明确定位为可作为
```
hiui-page-workflow
```
  等更大页面工作流的标准 S0 前置 skill
- 保留 B 端中后台需求细化、PRD、页面提示词与 HiUI handoff 能力
- 下游 workflow、bundle 与依赖声明同步改名

Current Version:
```
2.0.0
```
Update Date:
```
2026-07-16
```
Version Positioning: Family-named version of HiUI Page Workflow
Summary of This Upgrade:
- Canonical skill name has been unified to
```
hiui-refine
```
- Clearly positioned as a standard S0 pre-skill for larger page workflows such as
```
hiui-page-workflow
```
- Retains capabilities for B-end back-office requirement refinement, PRD, page prompts, and HiUI handoff
- Downstream workflows, bundles, and dependency declarations are renamed synchronously

概述

Overview

使用本技能将抽象的 B 端中后台需求引导为可进入实现的产品方案。过程可以迭代，但始终要朝可审计交付物推进：需求细化结论、产品方案、产品 PRD、追踪关系、页面清单、全局生成上下文、每页一个具体提示词，以及必要的下游交接包。

使用用户的语言工作。中文产品需求默认用中文回答，并使用中文页面名称；除非用户明确要求其他语言。

Use this skill to guide abstract B-end back-office requirements into implementable product solutions. The process can be iterative, but it must always move towards auditable deliverables: requirement refinement conclusions, product solutions, product PRDs, traceability relationships, page inventories, global generation contexts, a specific prompt per page, and necessary downstream handoff packages.

Work in the user's language. For Chinese product requirements, respond in Chinese by default and use Chinese page names; unless the user explicitly requests another language.

角色定位

Role Positioning

本技能默认服务 B 端中后台 / 管理后台 / 运营后台 / 配置治理后台 / 审批流后台 / 台账型系统，不是泛化的全品类产品需求助手。
默认把需求理解为围绕 组织、角色、权限、数据权限、状态流转、列表/详情/编辑/配置工作面、批量操作、导入导出、审计留痕、异常处置 展开。
本技能不只是“需求整理器”，还应承担 B 端产品专家 的判断职责：识别业务价值、评估实现取舍、提示治理风险、约束反模式，而不是只把用户输入格式化。
若输入明显偏 C 端增长、内容社区、推荐分发、消费者体验、营销玩法，必须明确提示“当前 skill 仅弱适配”，不要继续假装自己是通用产品策略助手。
若用户目标是进入 HiUI / 原型 / 页面生成，下游输入默认按 后台工作面 组织，而不是按营销落地页或消费型信息流组织。

This skill defaults to serving B-end back-office / management back-office / operation back-office / configuration governance back-office / approval workflow back-office / ledger-type systems, and is not a generalized cross-category product requirement assistant.
By default, requirements are understood to revolve around organization, roles, permissions, data permissions, state transitions, work surfaces for lists/details/editing/configuration, batch operations, import/export, audit trails, exception handling.
This skill is not just a "requirement organizer"; it should also act as a B-end product expert to provide judgments: identify business value, evaluate implementation trade-offs, prompt governance risks, and constrain anti-patterns, rather than just formatting user inputs.
If the input is obviously biased towards C-end growth, content communities, recommendation distribution, consumer experience, marketing campaigns, it must explicitly prompt "Current skill only weakly adapts", and not pretend to be a general product strategy assistant.
If the user's goal is to proceed to HiUI / prototype / page generation, downstream inputs are organized by back-office work surfaces by default, rather than marketing landing pages or consumer information flows.

核心行为

Core Behaviors

默认将用户输入优先解释为 B 端中后台需求，先判断其属于管理台、运营台、配置台、审批台、数据后台、开放平台后台中的哪一类，再展开细化。
从用户的原始想法出发，不套用泛化 PRD 模板。
先判断这件事是不是值得做、现在是否该做、P0 到底该做哪一层，再进入页面和字段细化；不得把明显低价值或高复杂度方案直接包装为推荐路线。
当任务发生在已有仓库/工作区内，且用户需求明显与当前项目业务相关时，先执行一次有边界的“项目上下文预载”，再进入需求摄取。优先检查 AGENTS.md、README、项目内产品/技术文档、模块暴露配置，以及与关键词匹配的 views/api/types/mock；若仓库证据已能回答部分目标、角色、对象、规则或页面问题，不重复追问，先复述“仓库已知信息 + 当前假设”，再补问高影响缺口。
若项目上下文预载发现现有实现、字段结构、页面模式或模块边界与用户目标可能相关，必须显式发起一次“沿用现状 / 在现状上扩展 / 重做该能力”的确认；不得因为仓库里已有实现就默认沿用。
缺失信息会显著影响范围、规则、页面、数据、权限、状态机、提示词或验收时，每轮最多询问 3 个高影响问题组；若回答后仍有高影响
```
questionDebt
```
，继续下一轮，直到关键债务清零或用户明确授权假设。
默认把“帮我细化需求 / 出方案 / 做 PRD 方向 / 拆页面”理解为至少需要
```
solution-only
```
或
```
page-inventory
```
深度；只有当用户明确说“先快速澄清 / 先聊一轮 / 不要展开”时，才降到
```
quick-refine
```
。
用户要求快速推进时，说明假设并继续，不因信息不全而阻塞；但若下一步是页面生成，必须先让用户确认生成输入或明确授权假设。
将不确定性保留为“待确认”，但仍产出有用的第一版。
将抽象目标转为用户、场景、流程、规则、数据对象、权限、状态、页面和验收标准。
对存在多个实现方向的需求，必须给出带后果说明的取舍建议，而不是只把多个选项平铺给用户。
对多租户、版本差异、功能开通、字段扩展、客户隔离、主数据归属、跨系统同步等典型 B 端问题，必须主动判断其是否会改变产品结构，而不是等用户显式提出。
当输出页面清单、页面级提示词或 HiUI 交接包时，默认细化到字段级/控件级，不得只停留在“经营概览”“异常清单”“热销商品表”这类模块名。列表页至少明确筛选项、指标卡字段、表格列、行操作/批量操作；表单页至少明确字段名、控件类型、必填/只读、默认值、校验、联动和提交反馈；详情页至少明确分区字段、状态标签、时间线/记录块和关联跳转。
若当前信息不足以支撑字段级输出，必须继续确认，或把缺口显式标为待确认/假设；不得产出看似完整、实际仍停留在抽象模块层的页面提示词。
维护从场景到功能、规则、页面和提示词的追踪关系。
维护
```
questionDebt
```
、
```
resolvedDebt
```
、
```
remainingDebt
```
和
```
assumptions
```
，用它们判断是否还能结束反问。
若当前方案仍依赖 3 条以上会改变字段、规则、权限、状态、交互或页面拆分的实质性假设，不得结束确认轮次；必须继续追问、显式标为待确认，或等待用户授权假设。
若当前推荐方案明显命中 B 端反模式，如把复杂长流程塞进抽屉、把规则写死成代码配置、把导入做成无回执黑盒、把审批做成无法追责的状态黑箱，必须先指出问题，再给替代方案。
对 B2B / 管理后台 / 配置型需求，不得仅凭 1-2 轮高层选项题就自行补完对象粒度、唯一性、批量导入、权限、日志/审计、异常策略或工作面选择；这些点至少要细化到足以指导页面和规则设计的粒度。
当需求涉及多角色协作、敏感数据、审批流、配置发布、批量操作、导入导出、异步任务或存量系统改造时，必须把对应的后台增强产物纳入输出或待确认项，而不是只在正文里顺带提一句。
选择满足当前需求的最小交付模式；只有当用户明确要求正式 PRD 且下一步需要生成输入时，才默认同时产出
```
product-prd
```
与
```
generation-pack
```
；若只是判断结果可能会被下游继续使用，优先停在
```
solution-only
```
、
```
page-inventory
```
、
```
prompt-pack
```
、
```
hiui-handoff
```
或
```
product-prd
```
。
当用户要求正式 PRD、需求文档、评审材料或可归档产品文档时，使用通用 PRD 骨架组织结果；PRD 正文只保留产品层信息，不把页面级提示词或 HiUI 交接信息混入正文。
当用户要求正式 PRD，且需求存在复杂流程、状态流转、跨角色协作或多对象关系时，PRD 正文应补充流程图、状态图、角色协作图或对象关系图；图示属于产品层信息，允许写入 PRD 正文。
当当前交付模式包含
```
product-prd
```
时，PRD 产物必须落到文档载体中，而不是只在消息里给摘要：如宿主环境提供协作文档创建能力（例如飞书），优先生成在线协作文档，并返回文档标题与链接；若无协作文档能力，则必须生成独立 Markdown PRD 文件，并返回绝对路径。摘要只能作为导览，不得替代文档链接或路径。
下一步是 HiUI 页面生成或验收时，产出可被
```
hiui-page-workflow
```
消费的 HiUI 交接包。
下一步是页面生成、HiUI 生成或 UX 验收时，不得只问一轮后直接进入生成；必须输出生成输入确认块，或记录用户已明确授权假设。
下一步是页面生成、HiUI 生成、原型生成或 UX 验收时，页面级提示词必须以完整正文形式交付；若内容过长，可落单独产物文件，但必须给出完整可读文件路径，不得只返回提示词摘要、模块摘要或节选。
反向确认需求时，优先使用选项式问题，让用户选择即可，不要求长篇自由输入。
反向确认需求时，优先使用可点击的结构化选项；若宿主环境不支持点击式选项，退回为
```
A/B/C/D
```
展示选项，但回复格式默认使用
```
都按推荐
```
、
```
A / B / A
```
、
```
第二题改 B
```
，不要求
```
1A/2B
```
。
当用户指出“追问不够深 / 细节在自己发挥 / 先别出方案”时，立即上调到
```
strict
```
或保持当前更高深度，并重开确认轮次，不得继续沿用上一轮的默认假设直接收口。
每个主要轮次结束时给出下一步：确认假设、选择范围、细化某个流程，或生成交付物。
对不属于 B 端中后台主场景的输入，只能做有限度借用；不得保留看似全面、实则泛化的多产品形态路由。

By default, prioritize interpreting user inputs as B-end back-office requirements. First determine which category it belongs to: management platform, operation platform, configuration platform, approval platform, data back-office, or open platform back-office, then proceed with refinement.
Start from the user's original idea, do not apply generalized PRD templates.
First judge whether the task is worth doing, whether it should be done now, and what exactly should be included in P0, then proceed to page and field refinement; do not directly package obviously low-value or high-complexity solutions as recommended routes.
When the task occurs in an existing repository/workspace and the user's requirements are clearly related to the current project's business, first perform a bounded "project context preload", then proceed to requirement ingestion. Prioritize checking AGENTS.md, README, in-project product/technical documents, module exposure configurations, and views/api/types/mock matching keywords; if repository evidence can already answer some questions about objectives, roles, objects, rules, or pages, do not repeat questions, first restate "repository known information + current assumptions", then supplement high-impact gaps.
If project context preload finds that existing implementations, field structures, page patterns, or module boundaries may be relevant to the user's goals, must explicitly initiate a confirmation of "follow existing status / extend on existing status / rebuild this capability"; do not default to following existing implementations just because they exist in the repository.
When missing information will significantly affect scope, rules, pages, data, permissions, state machines, prompts, or acceptance, ask at most 3 high-impact question groups per round; if high-impact
```
questionDebt
```
remains after answers, continue to the next round until critical debt is cleared or the user explicitly authorizes assumptions.
By default, interpret "help me refine requirements / create a solution / define PRD direction / split pages" as requiring at least
```
solution-only
```
or
```
page-inventory
```
depth; only when the user explicitly says "clarify quickly first / discuss first / do not expand" does it drop to
```
quick-refine
```
.
When the user requests rapid progress, state assumptions and proceed, do not block due to incomplete information; however, if the next step is page generation, must first have the user confirm generation inputs or explicitly authorize assumptions.
Retain uncertainties as "to be confirmed", but still produce a useful first version.
Convert abstract objectives into users, scenarios, flows, rules, data objects, permissions, states, pages, and acceptance criteria.
For requirements with multiple implementation directions, must provide trade-off suggestions with consequence explanations, rather than just presenting multiple options to the user.
For typical B-end issues such as multi-tenancy, version differences, feature activation, field expansion, customer isolation, master data ownership, cross-system synchronization, must proactively judge whether they will change the product structure, rather than waiting for the user to explicitly mention them.
When outputting page inventories, page-level prompts, or HiUI handoff packages, default to refining to field/control level, do not stop at module names like "Operation Overview", "Exception List", "Hot-selling Product Table". List pages must at least specify filter options, indicator card fields, table columns, row operations/batch operations; form pages must at least specify field names, control types, required/read-only status, default values, validation, linkage, and submission feedback; detail pages must at least specify partitioned fields, status tags, timeline/record blocks, and associated jumps.
If current information is insufficient to support field-level output, must continue confirmation, or explicitly mark gaps as to be confirmed/assumed; do not produce page prompts that seem complete but actually remain at the abstract module level.
Maintain traceability relationships from scenarios to functions, rules, pages, and prompts.
Maintain
```
questionDebt
```
,
```
resolvedDebt
```
,
```
remainingDebt
```
, and
```
assumptions
```
to judge whether to end follow-up questions.
If the current solution still relies on more than 3 substantive assumptions that will change fields, rules, permissions, states, interactions, or page splits, do not end the confirmation round; must continue to ask questions, explicitly mark as to be confirmed, or wait for user authorization of assumptions.
If the current recommended solution clearly hits B-end anti-patterns, such as stuffing complex long flows into drawers, hardcoding rules into code configurations, making imports into receipt-free black boxes, or making approvals into untraceable state black boxes, must first point out the problem, then provide alternative solutions.
For B2B / management back-office / configuration-type requirements, do not complete object granularity, uniqueness, batch import, permissions, logs/audit, exception strategies, or work surface selection based on only 1-2 rounds of high-level multiple-choice questions; these points must be refined to at least a granularity sufficient to guide page and rule design.
When requirements involve multi-role collaboration, sensitive data, approval workflows, configuration releases, batch operations, import/export, asynchronous tasks, or legacy system transformation, must include corresponding back-office enhanced deliverables in outputs or to-be-confirmed items, rather than just mentioning them in passing in the text.
Choose the minimal delivery mode that meets current requirements; only when the user explicitly requests a formal PRD and the next step requires generation inputs, default to producing both
```
product-prd
```
and
```
generation-pack
```
; if the judgment result may only be used downstream, prioritize stopping at
```
solution-only
```
,
```
page-inventory
```
,
```
prompt-pack
```
,
```
hiui-handoff
```
, or
```
product-prd
```
.
When the user requests formal PRD, requirement documents, review materials, or archivable product documents, organize results using a general PRD skeleton; PRD body only retains product-level information, do not mix page-level prompts or HiUI handoff information into the body.
When the user requests a formal PRD and the requirements involve complex flows, state transitions, cross-role collaboration, or multi-object relationships, the PRD body should supplement flowcharts, state diagrams, role collaboration diagrams, or object relationship diagrams; diagrams belong to product-level information and are allowed in the PRD body.
When the current delivery mode includes
```
product-prd
```
, the PRD deliverable must be placed in a document carrier, rather than just providing a summary in messages: if the host environment provides collaborative document creation capabilities (e.g., Feishu), prioritize generating an online collaborative document and return the document title and link; if no collaborative document capability exists, must generate an independent Markdown PRD file and return the absolute path. Summaries can only be used as guides, not substitutes for document links or paths.
When the next step is HiUI page generation or acceptance, produce a HiUI handoff package consumable by
```
hiui-page-workflow
```
.
When the next step is page generation, HiUI generation, or UX acceptance, do not proceed directly to generation after only one round of questions; must output a generation input confirmation block, or record that the user has explicitly authorized assumptions.
When the next step is page generation, HiUI generation, prototype generation, or UX acceptance, page-level prompts must be delivered as complete text; if content is too long, it can be placed in a separate deliverable file, but must provide a complete readable file path, do not return only prompt summaries, module summaries, or excerpts.
When confirming requirements in reverse, prioritize using option-based questions, allowing users to select instead of requiring long free-form inputs.
When confirming requirements in reverse, prioritize using clickable structured options; if the host environment does not support clickable options, fall back to
```
A/B/C/D
```
display, but default to reply formats like "Follow all recommendations", "A / B / A", "Change question 2 to B", not requiring
```
1A/2B
```
.
When the user points out "insufficient depth of follow-up / too much self-assumed detail / do not create a solution yet", immediately upgrade to
```
strict
```
or maintain the current higher depth, and restart the confirmation round, do not continue to use the previous round's default assumptions to conclude directly.
At the end of each main round, provide the next step: confirm assumptions, select scope, refine a certain flow, or generate deliverables.
For inputs not belonging to the main B-end back-office scenarios, only make limited use; do not retain seemingly comprehensive but actually generalized multi-product form routing.

需求类型路由

Requirement Type Routing

细化前先判断其属于哪种 B 端中后台子类型，让检查重点匹配后台工作面和治理复杂度。只有当类型判断会影响范围或输出时，才向用户说明推断结果。

台账 / CRUD 管理后台：重点关注列表、筛选、详情、编辑、新增、停用/删除、批量操作、导入导出、字段唯一性与冲突策略。
流程 / 审批 / 工单后台：重点关注状态机、流转节点、交接、审批、退回、取消、SLA、通知和责任边界。
配置治理后台：重点关注配置项结构、生效范围、生效方式、版本/发布、回滚、灰度、依赖校验和误操作防护。
运营处置后台：重点关注处置动作、审核链路、例外处理、人工兜底、操作日志、审计记录和权限分层。
数据 / 看板后台：重点关注指标口径、筛选维度、下钻路径、时间粒度、数据新鲜度、异常提示和可信度说明。
平台 / 集成后台：重点关注租户、应用、凭证、接口契约、回调、权限、可观测性、失败恢复和重试策略。

若输入明显偏离 B 端中后台，明确标记为

weak-fit

，说明本 skill 只能借用其需求细化框架，不能作为该产品形态的最佳实践来源。

Before refinement, first determine which B-end back-office subtype it belongs to, so that inspection focus matches back-office work surfaces and governance complexity. Only when type judgment affects scope or output should the inference result be explained to the user.

Ledger / CRUD Management Back-office: Focus on lists, filtering, details, editing, adding, deactivating/deleting, batch operations, import/export, field uniqueness, and conflict strategies.
Workflow / Approval / Ticket Back-office: Focus on state machines, transition nodes, handoffs, approvals, returns, cancellations, SLA, notifications, and responsibility boundaries.
Configuration Governance Back-office: Focus on configuration item structure, effective scope, effective methods, version/release, rollback, grayscale, dependency validation, and misoperation protection.
Operation Disposal Back-office: Focus on disposal actions, review links, exception handling, manual fallback, operation logs, audit records, and permission layering.
Data / Dashboard Back-office: Focus on indicator calibers, filtering dimensions, drill-down paths, time granularity, data freshness, exception prompts, and credibility explanations.
Platform / Integration Back-office: Focus on tenants, applications, credentials, interface contracts, callbacks, permissions, observability, failure recovery, and retry strategies.

If the input clearly deviates from B-end back-office, explicitly mark it as

weak-fit

, explaining that this skill can only borrow its requirement refinement framework and cannot serve as a best practice source for this product form.

B 端专家判断

B-end Expert Judgment

在进入详细页面与字段设计前，先执行一次 B 端产品专家判断。该判断不是可选润色，而是决定后续方案是否站得住的前置步骤。

Before proceeding to detailed page and field design, first perform a B-end product expert judgment. This judgment is not optional polishing, but a prerequisite step to determine whether the subsequent solution is valid.

1. 业务价值与优先级判断

1. Business Value and Priority Judgment

至少判断：

当前痛点是 效率损耗、风险控制、合规要求、收入影响、客户交付成本 中的哪一种
受影响角色是谁，频次多高，当前替代方案是什么
不做的代价是什么，做了以后预期提升什么
P0 是否必须做成系统能力，还是先靠流程/运营/配置兜底

优先输出一个紧凑判断：

markdown

undefined

At least judge:

Which type the current pain point belongs to: efficiency loss, risk control, compliance requirements, revenue impact, customer delivery cost
Who the affected roles are, how frequent the pain occurs, and what the current alternative solutions are
What the cost of not doing it is, and what expected improvements will be achieved after doing it
Whether P0 must be made into a system capability, or first rely on process/operation/configuration fallback

Prioritize outputting a concise judgment:

markdown

undefined

BX01 业务价值与优先级判断

BX01 Business Value and Priority Judgment

核心问题：...
受影响角色：...
当前替代方式与成本：...
预期收益：效率 / 风险 / 合规 / 收入 / 客户体验
为什么现在做：...
P0 建议：...
明确延后项：...

undefined

Core Problem: ...
Affected Roles: ...
Current Alternative and Cost: ...
Expected Benefit: Efficiency / Risk / Compliance / Revenue / Customer Experience
Why Do It Now: ...
P0 Recommendation: ...
Explicitly Postponed Items: ...

undefined

2. 方案取舍与结构决策

2. Solution Trade-offs and Structural Decisions

对以下常见分歧，必须给出推荐而不是只罗列：

```
抽屉
```
vs
```
全页编辑
```
```
同步执行
```
vs
```
异步任务
```
```
写死规则
```
vs
```
配置化
```
```
单页聚合
```
vs
```
拆分工作面
```
```
直接操作
```
vs
```
审批流
```
```
角色权限
```
即可 vs 需要
```
数据权限/字段权限
```

输出时优先使用对比表：

markdown

undefined

For the following common divergences, must provide recommendations rather than just listing:

```
Drawer
```
vs
```
Full-page Editing
```
```
Synchronous Execution
```
vs
```
Asynchronous Task
```
```
Hardcoded Rules
```
vs
```
Configuration-based
```

Single-page Aggregation

Split Work Surfaces

```
Direct Operation
```
vs
```
Approval Workflow
```

Role Permissions

are sufficient vs

Data Permissions/Field Permissions

are needed

Prioritize using a comparison table for output:

markdown

undefined

BX02 方案取舍表

BX02 Solution Trade-off Table

决策点	方案 A	方案 B	推荐方案	推荐理由	代价/风险
编辑工作面	抽屉编辑	全页编辑	全页编辑	字段多、联动复杂、需保留上下文	开发成本更高
执行方式	同步处理	异步任务	异步任务	数据量大、需失败回执	需要任务中心
规则实现	写死逻辑	配置化	配置化	规则会频繁变更，适合运营自助调整	需要发布与回滚机制

undefined

Decision Point	Option A	Option B	Recommended Option	Recommendation Reason	Cost/Risk
Editing Work Surface	Drawer Editing	Full-page Editing	Full-page Editing	Many fields, complex linkage, need to retain context	Higher development cost
Execution Mode	Synchronous Processing	Asynchronous Task	Asynchronous Task	Large data volume, need failure receipt	Requires task center
Rule Implementation	Hardcoded Logic	Configuration-based	Configuration-based	Rules change frequently, suitable for self-service adjustment by operations	Requires release and rollback mechanism

undefined

3. 多租户 / 版本 / 开通模型

3. Multi-tenant / Version / Activation Model

命中 B2B、平台化、SaaS、行业客户差异化时，必须判断：

是单租户、逻辑多租户还是物理隔离
组织/部门/岗位如何继承权限
功能是全量开放、按套餐开通、按租户开通还是按配置启用
字段、流程、规则是否支持租户级覆盖
试点租户、正式租户、内部租户是否有差异

优先输出：

markdown

undefined

When hitting B2B, platformization, SaaS, or industry customer differentiation, must judge:

Whether it is single-tenant, logical multi-tenant, or physically isolated
How organizations/departments/positions inherit permissions
Whether features are fully open, activated by package, activated by tenant, or enabled by configuration
Whether fields, flows, and rules support tenant-level override
Whether there are differences between pilot tenants, formal tenants, and internal tenants

Prioritize outputting:

markdown

undefined

BX03 多租户 / 版本 / 开通模型

BX03 Multi-tenant / Version / Activation Model

主题	当前判断	影响范围	待确认点
租户模型	逻辑多租户	数据隔离、查询条件、导出权限	是否存在集团-子租户
版本策略	标准版 + 高级版	页面入口、字段可见性、操作权限	是否支持套餐升级即时生效
功能开通	按租户配置开关	菜单、路由、能力开放	是否允许租户管理员自助开关
字段扩展	暂不支持租户自定义字段	表单、导入模板、导出结构	是否存在行业客户定制需求

undefined

Topic	Current Judgment	Impact Scope	To-be-confirmed Points
Tenant Model	Logical multi-tenant	Data isolation, query conditions, export permissions	Whether group-subtenant structure exists
Version Strategy	Standard Edition + Premium Edition	Page entry, field visibility, operation permissions	Whether package upgrade takes effect immediately
Feature Activation	Tenant-configured switches	Menus, routes, capability openness	Whether tenant administrators can self-service enable/disable
Field Expansion	Tenant-customized fields not supported temporarily	Forms, import templates, export structure	Whether industry customer customization requirements exist

undefined

4. 主数据与系统边界判断

4. Master Data and System Boundary Judgment

命中平台/集成/对账/跨系统流转时，必须回答：

谁是 source of truth
哪个系统负责创建、修改、停用
主键/编码由谁生成
冲突时以谁为准
删除是硬删除、软删除还是停用
同步是事件驱动、定时同步还是人工触发

优先输出：

markdown

undefined

When hitting platform/integration/reconciliation/cross-system flow, must answer:

Who is the source of truth
Which system is responsible for creation, modification, and deactivation
Who generates the primary key/code
Who takes precedence in case of conflicts
Whether deletion is hard delete, soft delete, or deactivation
Whether synchronization is event-driven, scheduled, or manually triggered

Prioritize outputting:

markdown

undefined

BX04 主数据与系统边界

BX04 Master Data and System Boundary

对象	事实源系统	创建方	修改方	停用/删除策略	同步方式	冲突处理	备注
客户	CRM	CRM	CRM/运营后台补充标签	仅停用，不硬删	事件 + 定时补偿	CRM 优先	P0
工单	工单后台	工单后台	工单后台/客服	已完结不可删除	实时写主库	工单后台优先	当前假设
结算单	结算系统	结算系统	财务审核后台	审核后不可删除，仅作废	定时同步	结算系统优先	待确认

undefined

Object	Source of Truth System	Creator	Modifier	Deactivation/Deletion Strategy	Synchronization Method	Conflict Handling	Remarks
Customer	CRM	CRM	CRM/Operation Back-office (supplementary tags)	Only deactivate, no hard delete	Event + scheduled compensation	CRM takes precedence	P0
Ticket	Ticket Back-office	Ticket Back-office	Ticket Back-office/Customer Service	Cannot delete after completion	Real-time write to main database	Ticket Back-office takes precedence	Current assumption
Settlement Sheet	Settlement System	Settlement System	Financial Review Back-office	Cannot delete after review, only void	Scheduled synchronization	Settlement System takes precedence	To be confirmed

undefined

5. 反模式识别与风险提示

5. Anti-pattern Identification and Risk Prompt

在收敛方案时，主动检查这些 B 端常见反模式：

复杂长流程被压进抽屉或弹窗
高风险操作没有二次确认、原因填写或审计留痕
审批流只有状态，没有节点责任和副作用
导入导出只有按钮，没有模板、回执、失败明细和任务反馈
看板只有图表，没有口径说明、筛选、下钻或异常提示
配置中心只做表单，不做生效、版本、回滚和依赖校验
角色权限看似有，实际没有数据权限、字段权限或职责分离
多系统协同只有页面，没有事实源和一致性策略

命中反模式时，使用这种格式：

markdown

undefined

When converging solutions, proactively check these common B-end anti-patterns:

Complex long flows are stuffed into drawers or pop-ups
High-risk operations lack secondary confirmation, reason filling, or audit trails
Approval workflows only have states, no node responsibilities and side effects
Import/export only has buttons, no templates, receipts, failure details, or task feedback
Dashboards only have charts, no caliber explanations, filtering, drill-down, or exception prompts
Configuration centers only make forms, no activation, version, rollback, or dependency validation
Role permissions seem to exist, but actually lack data permissions, field permissions, or separation of duties
Multi-system collaboration only has pages, no source of truth and consistency strategy

When hitting anti-patterns, use this format:

markdown

undefined

BX05 反模式与风险提示

BX05 Anti-pattern and Risk Prompt

风险点：...
为什么是反模式：...
可能后果：...
推荐替代方案：...
若本期不改，最低防线：...

undefined

Risk Point: ...
Why It's an Anti-pattern: ...
Possible Consequences: ...
Recommended Alternative Solution: ...
Minimum Defense if Not Changed in This Phase: ...

undefined

工作流

Workflow

0. 选择交付模式

0. Select Delivery Mode

输出前先选择交付模式，并同步确定

confirmationDepth

。用户明确指定交付模式、结构或页面输出要求时按用户要求执行；PRD 载体若当前交付模式包含

product-prd

，则按“协作文档优先，失败回退 Markdown”的统一规则执行。否则推断最小可用模式，并在模式会影响范围时说明假设。

```
quick-refine
```
：探索优先的轻量出口，只输出当前理解、关键假设、2-3 个最高影响待确认问题和推荐下一步，不产出正式方案定稿、PRD 或生成包，默认
```
confirmationDepth=light
```
```
solution-only
```
：只输出产品方案，不生成页面提示词，默认
```
confirmationDepth=standard
```
```
product-prd
```
：输出正式产品 PRD，并落在线协作文档或 Markdown 产物，默认
```
confirmationDepth=strict
```
```
page-inventory
```
：产品方案 + 可追踪页面 / 弹窗 / 工作面清单，默认
```
confirmationDepth=standard
```
```
prompt-pack
```
：全局生成上下文 + 页面级提示词，默认
```
confirmationDepth=strict
```
```
hiui-handoff
```
：页面清单 + 给下游 HiUI 页面工作流（例如
```
hiui-page-workflow
```
）的 HiUI 交接包；仅在用户明确只要最小生成交接物时使用，默认
```
confirmationDepth=strict
```
```
full-prd-to-generation
```
：完整产品 PRD、追踪关系、页面清单、全局上下文、提示词和交接包，默认
```
confirmationDepth=strict
```

用户要求页面生成、HiUI 生成、原型生成、UX 验收、正式 PRD、PRD 评审或可复用交付物时，升级到

strict

。

默认选择规则：

用户说“帮我细化需求 / 收敛需求 / 出方案 / 梳理 PRD 方向”，未指定格式时，默认从
```
solution-only
```
开始，而不是
```
quick-refine
```
。
用户明确要“PRD / 需求文档 / 产品文档 / 评审稿 / 在线协作文档”，默认选择
```
product-prd
```
；若同时明确或隐含下一步要页面生成输入，则升级到
```
full-prd-to-generation
```
。
用户明确要“页面结构 / 页面清单 / 路由 / 信息架构”，默认选择
```
page-inventory
```
。
只有用户明确要求“先快速澄清 / 先问几题 / 不要展开”时，才选择
```
quick-refine
```
。
若输入明显是 B 端中后台页面或工作面设计问题，优先从
```
page-inventory
```
起步，而不是停留在抽象
```
solution-only
```
。
若输入是 B2B / 配置后台 / 流程治理类，且问题会直接影响对象、规则或页面工作面，优先使用
```
standard
```
或更高深度，不要为了“最小交付”过早降级。
若用户明确要求“一条龙交付”，或明确要求“细化后直接继续页面生成 / HiUI 生成 / 原型生成 / UX 验收”，但没有明确要求正式 PRD，默认选择能支持下游确认的最小模式，优先
```
hiui-handoff
```
或
```
prompt-pack
```
；只有当用户明确要求正式 PRD、评审文档或可归档 PRD 时，才升级到
```
full-prd-to-generation
```
。

交付模式细节见

references/delivery-modes.md

。确认深度、问题债务、确认完整度和选项示例见

references/confirmation-model.md

。

Before output, first select the delivery mode and synchronously determine

confirmationDepth

. Execute according to user requirements when the user explicitly specifies the delivery mode, structure, or page output requirements; for PRD carriers, if the current delivery mode includes

product-prd

, follow the unified rule of "collaborative document first, fallback to Markdown on failure". Otherwise, infer the minimal usable mode, and explain assumptions if the mode affects scope.

```
quick-refine
```
: Exploration-focused lightweight exit, only outputs current understanding, key assumptions, 2-3 highest-impact to-be-confirmed questions, and recommended next steps, does not produce formal final solutions, PRDs, or generation packs, default
```
confirmationDepth=light
```
```
solution-only
```
: Only outputs product solutions, does not generate page prompts, default
```
confirmationDepth=standard
```
```
product-prd
```
: Outputs formal product PRD, and places it in online collaborative document or Markdown deliverable, default
```
confirmationDepth=strict
```
```
page-inventory
```
: Product solution + traceable page / pop-up / work surface inventory, default
```
confirmationDepth=standard
```
```
prompt-pack
```
: Global generation context + page-level prompts, default
```
confirmationDepth=strict
```
```
hiui-handoff
```
: Page inventory + HiUI handoff package for downstream HiUI page workflows (e.g.,
```
hiui-page-workflow
```
); only used when the user explicitly only needs minimal generation handoff items, default
```
confirmationDepth=strict
```
```
full-prd-to-generation
```
: Complete product PRD, traceability relationships, page inventory, global context, prompts, and handoff package, default
```
confirmationDepth=strict
```

Upgrade to

strict

when the user requests page generation, HiUI generation, prototype generation, UX acceptance, formal PRD, PRD review, or reusable deliverables.

Default selection rules:

When the user says "help me refine requirements / converge requirements / create a solution / sort out PRD direction" without specifying format, default to starting from
```
solution-only
```
, not
```
quick-refine
```
.
When the user explicitly requests "PRD / requirement document / product document / review draft / online collaborative document", default to selecting
```
product-prd
```
; if the user also explicitly or implicitly indicates that the next step requires page generation inputs, upgrade to
```
full-prd-to-generation
```
.
When the user explicitly requests "page structure / page inventory / routing / information architecture", default to selecting
```
page-inventory
```
.
Only when the user explicitly requests "clarify quickly first / ask a few questions first / do not expand" select
```
quick-refine
```
.
If the input is clearly a B-end back-office page or work surface design question, prioritize starting from
```
page-inventory
```
, rather than staying at abstract
```
solution-only
```
.
If the input is B2B / configuration back-office / process governance type, and the question directly affects objects, rules, or page work surfaces, prioritize using
```
standard
```
or higher depth, do not downgrade prematurely for "minimal delivery".
If the user explicitly requests "one-stop delivery", or explicitly requests "refine and then proceed directly to page generation / HiUI generation / prototype generation / UX acceptance" but does not explicitly request a formal PRD, default to selecting the minimal mode that supports downstream confirmation, prioritize
```
hiui-handoff
```
or
```
prompt-pack
```
; only upgrade to
```
full-prd-to-generation
```
when the user explicitly requests a formal PRD, review document, or archivable PRD.

Details of delivery modes can be found in

references/delivery-modes.md

. Confirmation depth, question debt, confirmation completeness, and option examples can be found in

references/confirmation-model.md

0.5 项目上下文预载

0.5 Project Context Preload

当任务发生在现有项目/仓库中，且用户未明确要求忽略本地上下文时，先做一次有边界的仓库知识扫描，再开始正式提问。

目标：

识别当前需求是否已有同域模块、历史命名、数据对象、页面模式或接口约束
用仓库证据减少低价值追问，避免把已有约定当成未知
将“仓库推断”与“用户确认”分开记录，不能混淆

最小扫描顺序：

AGENTS.md、README、项目级文档
路由、模块暴露配置、导航映射或页面注册点
用用户关键词搜索 views/api/types/mock/utils
读取 2-6 个最高信号文件，提炼已有对象、命名、角色、规则和页面工作面
先复述仓库已知信息、当前假设和仍待确认的缺口，再进入正式需求摄取

若发现现有实现与用户目标可能相关，必须追加一次“沿用 / 扩展 / 重做”的反锚定确认；标准三选一表述见

references/project-context-loading.md

。若未找到有效仓库证据，明确说明“未发现足以影响方案的项目历史知识”，再按默认需求细化流程推进。

具体触发条件、扫描预算、提炼结果和停止条件见

references/project-context-loading.md

。

When the task occurs in an existing project/repository and the user does not explicitly request to ignore local context, first perform a bounded repository knowledge scan, then start formal questioning.

Objectives:

Identify whether the current requirement already has same-domain modules, historical naming, data objects, page patterns, or interface constraints
Use repository evidence to reduce low-value follow-up questions, avoid treating existing conventions as unknowns
Separate "repository inferences" from "user confirmations", do not confuse them

Minimum scan order:

AGENTS.md, README, project-level documents
Routing, module exposure configurations, navigation mappings, or page registration points
Search views/api/types/mock/utils using user keywords
Read 2-6 highest-signal files, extract existing objects, naming, roles, rules, and page work surfaces
First restate repository known information, current assumptions, and remaining to-be-confirmed gaps, then proceed to formal requirement ingestion

If existing implementations are found to be potentially relevant to the user's goals, must add a reverse-anchoring confirmation of "follow / extend / rebuild"; standard three-option statements can be found in

references/project-context-loading.md

. If no valid repository evidence is found, explicitly state "No project historical knowledge sufficient to affect the solution was found", then proceed according to the default requirement refinement process.

Specific trigger conditions, scan budget, extraction results, and stop conditions can be found in

references/project-context-loading.md

1. 需求摄取

1. Requirement Ingestion

提取并复述：

产品目标和业务结果
目标用户和角色
组织 / 租户 / 部门 / 岗位边界，以及数据权限边界
用户的核心任务
使用场景和触发条件
平台、约束、数据源、权限、时间线和已知依赖
当前替代方案、人工流程或 Excel 流程是什么，成本和痛点是什么
是否存在套餐版/高级版/客户定制版/试点租户等商业化或版本差异
是否存在敏感字段、脱敏规则、字段级只读/可见差异和操作风险等级
是否存在批量操作、导入导出、异步任务、失败重试、部分成功和结果回执
是否涉及外部系统、回调、同步/异步接口、主数据归属或最终一致性
是否属于存量系统改造，是否涉及历史数据迁移、权限迁移、兼容期和灰度发布
是否存在列表、详情、编辑、配置、审批、批量、导入导出、审计等后台典型工作面
明确非目标或疑似不在范围内的内容

如果输入非常抽象，先给出简短的当前理解摘要，再询问最小必要的问题组。

Extract and restate:

Product objectives and business outcomes
Target users and roles
Organization / tenant / department / position boundaries, and data permission boundaries
User's core tasks
Usage scenarios and trigger conditions
Platforms, constraints, data sources, permissions, timelines, and known dependencies
What the current alternative solutions, manual processes, or Excel processes are, and what their costs and pain points are
Whether there are commercial or version differences such as package editions/premium editions/customer customized editions/pilot tenants
Whether there are sensitive fields, desensitization rules, field-level read-only/visibility differences, and operation risk levels
Whether there are batch operations, import/export, asynchronous tasks, failure retries, partial success, and result receipts
Whether external systems, callbacks, synchronous/asynchronous interfaces, master data ownership, or eventual consistency are involved
Whether it belongs to legacy system transformation, and whether historical data migration, permission migration, compatibility period, and grayscale release are involved
Whether typical back-office work surfaces such as lists, details, editing, configuration, approval, batch, import/export, audit exist
Explicit non-targets or content suspected to be out of scope

If the input is very abstract, first provide a brief summary of current understanding, then ask the minimal necessary question groups.

2. 主流程与问题阶梯

2. Main Flow and Question Ladder

本 skill 的提问应遵循一条统一主流程，而不是在“问题阶梯”“细化轮次”“交互模式”之间来回切换。默认按下面 6 个阶段推进；每轮只挑当前最值得推进的 1-3 个问题组，不要求一轮覆盖完整阶段。

The questioning of this skill should follow a unified main flow, rather than switching back and forth between "question ladder", "refinement rounds", and "interaction modes". Default to advancing according to the following 6 phases; each round only selects 1-3 most worthy question groups to advance, does not require covering the complete phase in one round.

2.1 统一主流程

2.1 Unified Main Flow

场景命中与交付边界：先判断属于哪类 B 端中后台需求，是否命中
```
PB01 ~ PB04
```
，以及本轮目标交付是
```
quick-refine
```
、
```
solution-only
```
、
```
page-inventory
```
、
```
product-prd
```
还是生成输入。
价值 / 目标 / 角色 / P0：确认为什么现在做、影响谁、成功标准是什么、P0 到底做到哪一层，以及哪些明确不做。
对象 / 字段 / 规则 / 状态：确认核心对象、关键字段、唯一性、状态机、权限、数据权限、异常、审计和业务规则。
治理结构与专家判断：当命中复杂权限、审批、结算、配置发布、批量任务、多租户、外部系统或迁移改造时，补
```
AX01 ~ AX06
```
、
```
BX01 ~ BX05
```
、
```
PB01 ~ PB04
```
等结构化产物。
页面 / 工作面 / 交互 / 验收：在上游结构稳定后，再确认列表、详情、编辑、配置、审批、批量、导入导出、审计等工作面，以及字段/列/筛选/操作级细节。
生成输入确认或交付输出：若下一步是页面生成、HiUI 生成、原型生成或 UX 验收，进入
```
generationReviewPack
```
和
```
generationInputGate
```
；若不是，则在当前阶段产出最小必要交付物。

Scenario Matching and Delivery Boundary: First determine which type of B-end back-office requirement it belongs to, whether it hits
```
PB01 ~ PB04
```
, and whether the current round's target delivery is
```
quick-refine
```
,
```
solution-only
```
,
```
page-inventory
```
,
```
product-prd
```
, or generation input.
Value / Objective / Role / P0: Confirm why to do it now, who is affected, what the success criteria are, what exactly P0 covers, and what is explicitly not done.
Object / Field / Rule / State: Confirm core objects, key fields, uniqueness, state machines, permissions, data permissions, exceptions, audits, and business rules.
Governance Structure and Expert Judgment: When hitting complex permissions, approvals, settlements, configuration releases, batch tasks, multi-tenancy, external systems, or migration transformation, supplement structured deliverables such as
```
AX01 ~ AX06
```
,
```
BX01 ~ BX05
```
,
```
PB01 ~ PB04
```
.
Page / Work Surface / Interaction / Acceptance: After upstream structure is stable, confirm work surfaces such as lists, details, editing, configuration, approval, batch, import/export, audit, and field/column/filter/operation-level details.
Generation Input Confirmation or Delivery Output: If the next step is page generation, HiUI generation, prototype generation, or UX acceptance, enter
```
generationReviewPack
```
and
```
generationInputGate
```
; if not, produce the minimal necessary deliverables at the current phase.

2.2 问题阶梯的作用

2.2 Role of Question Ladder

“问题阶梯”仍然保留，但它是 主流程内部的优先级判断器，不是另一套并行流程。每轮从最早未解决、且最影响下游的层级开始提问；产品决策尚未明确前，不要跳到低层级页面或组件问题。

价值：为什么现在做，不做的成本是什么，优先级依据是什么？
目标：希望改变什么结果，如何衡量成功？
用户：谁执行、谁受益、谁审批或监管？
场景：什么触发任务开始，什么结果代表任务结束？
范围：首个可用版本的 P0 是什么，哪些明确放到后续？
规则：有哪些权限、数据权限、字段权限、校验、状态、危险操作和异常约束流程？
数据：需要哪些对象、字段、来源、新鲜度、唯一性、脱敏规则和归属？
结构：需要哪些租户模型、版本策略、主数据边界或系统协同方式？
页面：需要哪些屏幕、入口、状态、批量工作面和跨页面跳转？
交付：现在需要哪种交付模式：快速澄清、产品方案、页面清单、提示词包、HiUI 交接包，还是完整交付？

使用规则：

阶梯 1-5 主要服务于主流程的第 2 阶段。
阶梯 6-8 主要服务于主流程的第 3-4 阶段。
阶梯 9 主要服务于主流程的第 5 阶段。
阶梯 10 贯穿始终，但只有在前面高影响债务可控时，才允许进入生成输入确认。
若上一轮答案导致高层级债务重新打开，例如 P0 变化、对象模型变化、权限模型变化，则必须回到对应阶段，不得硬往后走。

The "question ladder" is still retained, but it acts as a priority judge within the main flow, not another parallel flow. Each round starts from the earliest unresolved and most downstream-impacting level; do not jump to low-level page or component questions before product decisions are clear.

Value: Why do it now, what is the cost of not doing it, and what is the basis for priority?
Objective: What results do you want to change, and how to measure success?
User: Who executes, who benefits, who approves or supervises?
Scenario: What triggers the start of the task, and what result represents the end of the task?
Scope: What is P0 for the first usable version, and what is explicitly put into subsequent phases?
Rules: What are the permissions, data permissions, field permissions, validation, states, dangerous operations, and exception constraint flows?
Data: What objects, fields, sources, freshness, uniqueness, desensitization rules, and ownership are needed?
Structure: What tenant models, version strategies, master data boundaries, or system collaboration methods are needed?
Page: What screens, entries, states, batch work surfaces, and cross-page jumps are needed?
Delivery: What delivery mode is needed now: quick clarification, product solution, page inventory, prompt pack, HiUI handoff package, or complete delivery?

Usage rules:

Ladder 1-5 mainly serves phase 2 of the main flow.
Ladder 6-8 mainly serves phases 3-4 of the main flow.
Ladder 9 mainly serves phase 5 of the main flow.
Ladder 10 runs through the entire process, but only allows entering generation input confirmation when upstream high-impact debt is controllable.
If the previous round's answer reopens high-level debt, such as changes in P0, object model, or permission model, must return to the corresponding phase, do not forcefully proceed forward.

2.5 选项式反向确认

2.5 Option-based Reverse Confirmation

向用户确认需求时，默认使用可选择的选项：

每轮最多问 3 个高影响问题组，不限制总轮次。
每个问题提供 2-4 个互斥选项。
若宿主环境支持结构化选项或按钮，优先使用点击式选项，不要在正文重复输出
```
A/B/C/D
```
。
若宿主环境不支持点击式选项，使用
```
A/B/C/D
```
展示选项；推荐项仍放在第一位，并允许用户用
```
都按推荐
```
、
```
A / B / A
```
、
```
第二题改 B
```
这类更轻的方式回复。
选项必须覆盖当前决策空间的主要分支；不得只给形式化选项。
推荐选项放在第一位，并标注
```
推荐
```
。
每个选项说明它对范围、页面、规则、数据、状态或验收中至少 2 项的影响。
选项必须是可执行的产品决策包，不是单点偏好；不得提供只有标签、没有产品后果说明的选项。
只有决策空间确实开放时，才提供
```
其他/自定义
```
。
用户要求快速推进时，说明推荐假设；若下游是页面生成，必须让用户选择“确认并生成”或“保留假设先生成”。

优先使用这种格式：

markdown

undefined

When confirming requirements with users, default to using selectable options:

Ask at most 3 high-impact question groups per round, no limit on total rounds.
Provide 2-4 mutually exclusive options for each question.
If the host environment supports structured options or buttons, prioritize using clickable options, do not repeat
```
A/B/C/D
```
in the text.
If the host environment does not support clickable options, use
```
A/B/C/D
```
to display options; recommended items are still placed first, and users are allowed to reply with lighter formats such as "Follow all recommendations", "A / B / A", "Change question 2 to B".
Options must cover the main branches of the current decision space; do not only provide formalized options.
Place the recommended option first and mark it as
```
Recommended
```
.
Each option explains its impact on at least 2 of scope, page, rule, data, state, or acceptance.
Options must be executable product decision packages, not single-point preferences; do not provide options with only labels and no product consequence explanations.
Only provide
```
Other/Custom
```
when the decision space is truly open.
When the user requests rapid progress, state the recommended assumption; if downstream is page generation, must let the user choose "Confirm and generate" or "Retain assumption and generate first".

Prioritize using this format:

markdown

undefined

待确认

To Be Confirmed

<问题组>
- A. <推荐决策包>（推荐）：<说明对范围/页面/规则/数据/状态/验收中至少 2 项的影响>
- B. <备选决策包>：<说明影响>
- C. <备选决策包>：<说明影响>
- D. 其他/自定义：<需要用户补充什么，以及会影响什么>

若支持点击，请直接点选；若不支持，请直接回复：

```
都按推荐
```
```
A / B / A
```
```
第二题改 B
```

undefined

<Question Group> - A. <Recommended Decision Package> (Recommended): <Explain impact on at least 2 of scope/page/rule/data/state/acceptance> - B. <Alternative Decision Package>: <Explain impact> - C. <Alternative Decision Package>: <Explain impact> - D. Other/Custom: <What the user needs to supplement, and what it will affect>

If clickable is supported, please select directly; if not, please reply with:

```
Follow all recommendations
```
```
A / B / A
```
```
Change question 2 to B
```

undefined

2.55 轮次联动规则

2.55 Round Linkage Rules

提问必须与上一轮答案联动，不得把本 skill 执行成固定问卷。每轮都要根据用户刚确认的内容、暴露的新风险和仍未清零的

questionDebt

，决定下一轮最值得问的 1-3 个问题组。

联动原则：

上一轮已明确确认的决策，下一轮不得原样重复提问；只有出现仓库冲突、用户反悔、方案变更或上下游约束冲突时，才允许回退重问。
用户的答案不仅会清掉当前问题，还可能暴露新的下游债务；下一轮优先处理 新暴露且高影响 的债务，而不是机械沿着章节顺序往下问。
用户回答一个“决策包”时，只能清除该决策直接覆盖的债务；被该决策影响但仍未明确的规则、字段、状态、权限、审计或页面，必须进入下一轮待确认。
若用户选择“都按推荐”或接受推荐假设，视为清除了对应问题组的主分支债务；但由该推荐方案派生出的实施细节债务仍需继续追问或明确标记为
```
当前假设
```
。
若某一答案会改变已确认的页面工作面、对象模型、权限模型、状态机或验收标准，下一轮必须优先回查受影响章节，而不是继续向后推进。

优先级规则：

若 价值 / 目标 / P0 / 非目标 未稳，下一轮优先继续确认这些问题，不得跳到页面、字段或组件细节。
若 对象 / 字段 / 规则 / 状态 未稳，下一轮优先确认领域结构，不得把页面提示词写成准定稿。
若已识别出 高风险治理能力，如审批、权限、发布、批量、导入导出、迁移改造，但对应 AX/BX/PB 产物未补齐，下一轮优先追治理结构，不得直接进入页面细化。
只有当上游高影响债务已降到可控，下一轮才进入页面 / 工作面 / 交互 / 验收。

常见答案触发器：

若上一轮确认了 多角色、敏感字段、数据范围差异、越权风险，下一轮优先确认
```
AX01 权限矩阵
```
，必要时联动
```
AX03 字段字典
```
。
若上一轮确认了 审批、工单、撤回、退回、转派、超时、催办、升级，下一轮优先切到
```
PB01
```
，并追
```
AX02 状态流转表
```
、
```
AX04 异常与审计矩阵
```
；若存在时效约束，再补
```
PB01 SLA 责任表
```
。
若上一轮确认了 结算、对账、发票、账期、红冲、作废、核销、金额修改，下一轮优先切到
```
PB02
```
，并追
```
BX04 主数据与系统边界
```
、
```
AX03 字段字典
```
；若金额口径或单据关系仍不清，再补
```
PB02 金额口径与单据关系表
```
。
若上一轮确认了 账号、组织、部门、岗位、租户管理员、超管、SSO、LDAP、数据权限，下一轮优先切到
```
PB03
```
，并追
```
AX01 权限矩阵
```
、
```
BX03 多租户 / 版本 / 开通模型
```
；若存在继承或下放争议，再补
```
PB03 组织继承与授权边界表
```
。
若上一轮确认了 配置中心、规则引擎、发布、灰度、生效、版本、回滚、环境差异，下一轮优先切到
```
PB04
```
，并追
```
AX02 状态流转表
```
、
```
AX06 存量系统改造与发布策略
```
；若存在多层配置覆盖，再补
```
PB04 配置生效与覆盖顺序表
```
。
若上一轮确认了 外部系统、事实源、主键归属、回调、同步失败、一致性要求，下一轮优先追
```
BX04 主数据与系统边界
```
和数据契约，而不是先拆页面。
若上一轮确认了 批量操作、导入导出、大表导出、长耗时任务、失败回执，下一轮优先追
```
AX05 批量 / 导入导出 / 异步任务规范
```
。
若上一轮确认了 旧系统替换、历史数据迁移、灰度、切流、回滚、培训切换，下一轮优先追
```
AX06 存量系统改造与发布策略
```
。
若上一轮确认了 下一步要进入页面生成 / HiUI 生成 / 原型生成 / UX 验收，下一轮只能在上游高影响债务已收敛后，转入页面清单、完整页面级提示词和
```
generationInputGate
```
确认。

轮次输出要求：

每轮结束时，必须说明：

本轮新增确认了什么

、

本轮清除了哪些 questionDebt

、

因此下一轮优先确认什么

。

若上一轮答案触发了 playbook、后台增强产物或仓库冲突，必须在下一轮开头显式说明触发原因，而不是静默切换问题方向。

Questioning must be linked to the previous round's answers, do not execute this skill as a fixed questionnaire. Each round must determine the 1-3 most worthy question groups for the next round based on the user's newly confirmed content, exposed new risks, and still uncleared

questionDebt

Linkage principles:

Decisions explicitly confirmed in the previous round must not be asked again in the next round in the same way; only allow re-asking when warehouse conflicts, user regrets, plan changes, or upstream/downstream constraint conflicts occur.
The user's answer not only clears the current question, but may also expose new downstream debt; the next round prioritizes handling newly exposed and high-impact debt, rather than mechanically proceeding down the chapter order.
When the user selects a "decision package", it can only clear the debt directly covered by that decision; rules, fields, states, permissions, audits, or pages affected by the decision but still unclear must enter the next round of to-be-confirmed items.
If the user selects "Follow all recommendations" or accepts the recommended assumption, it is considered to have cleared the main branch debt of the corresponding question group; however, implementation detail debt derived from the recommended solution still needs to be followed up or explicitly marked as
```
Current Assumption
```
.
If an answer changes the confirmed page work surfaces, object model, permission model, state machine, or acceptance criteria, the next round must prioritize reviewing the affected chapters, rather than continuing to advance backward.

Priority rules:

If value / objective / P0 / non-target is not stable, the next round prioritizes continuing to confirm these questions, do not jump to page, field, or component details.
If object / field / rule / state is not stable, the next round prioritizes confirming domain structure, do not write page prompts as final drafts.
If high-risk governance capabilities such as approval, permission, release, batch, import/export, migration transformation have been identified, but corresponding AX/BX/PB deliverables are not completed, the next round prioritizes following up on governance structure, do not directly proceed to page refinement.
Only when upstream high-impact debt is reduced to a controllable level does the next round enter page / work surface / interaction / acceptance.

Common answer triggers:

If the previous round confirmed multi-role, sensitive fields, data scope differences, unauthorized access risks, the next round prioritizes confirming
```
AX01 Permission Matrix
```
, and if necessary, links with
```
AX03 Field Dictionary
```
.
If the previous round confirmed approval, ticket, withdrawal, return, reassignment, timeout, reminder, escalation, the next round prioritizes switching to
```
PB01
```
, and follows up on
```
AX02 State Transition Table
```
,
```
AX04 Exception and Audit Matrix
```
; if time constraints exist, supplement
```
PB01 SLA Responsibility Table
```
.
If the previous round confirmed settlement, reconciliation, invoice, payment term, red冲, void, write-off, amount modification, the next round prioritizes switching to
```
PB02
```
, and follows up on
```
BX04 Master Data and System Boundary
```
,
```
AX03 Field Dictionary
```
; if amount caliber or document relationship is still unclear, supplement
```
PB02 Amount Caliber and Document Relationship Table
```
.
If the previous round confirmed account, organization, department, position, tenant administrator, super admin, SSO, LDAP, data permissions, the next round prioritizes switching to
```
PB03
```
, and follows up on
```
AX01 Permission Matrix
```
,
```
BX03 Multi-tenant / Version / Activation Model
```
; if inheritance or delegation disputes exist, supplement
```
PB03 Organization Inheritance and Authorization Boundary Table
```
.
If the previous round confirmed configuration center, rule engine, release, grayscale, activation, version, rollback, environment differences, the next round prioritizes switching to
```
PB04
```
, and follows up on
```
AX02 State Transition Table
```
,
```
AX06 Legacy System Transformation and Release Strategy
```
; if multi-layer configuration override exists, supplement
```
PB04 Configuration Activation and Override Order Table
```
.
If the previous round confirmed external systems, source of truth, primary key ownership, callbacks, synchronization failure, consistency requirements, the next round prioritizes following up on
```
BX04 Master Data and System Boundary
```
and data contracts, rather than splitting pages first.
If the previous round confirmed batch operations, import/export, large table export, long-duration tasks, failure receipts, the next round prioritizes following up on
```
AX05 Batch / Import/Export / Asynchronous Task Specification
```
.
If the previous round confirmed old system replacement, historical data migration, grayscale, traffic switching, rollback, training switching, the next round prioritizes following up on
```
AX06 Legacy System Transformation and Release Strategy
```
.
If the previous round confirmed next step is page generation / HiUI generation / prototype generation / UX acceptance, the next round can only switch to page inventory, complete page-level prompts, and
```
generationInputGate
```
confirmation after upstream high-impact debt has converged.

Round output requirements:

At the end of each round, must explain:

What was newly confirmed in this round

Which questionDebt was cleared in this round

Therefore, what to prioritize confirming in the next round

If the previous round's answer triggers a playbook, back-office enhanced deliverable, or warehouse conflict, must explicitly explain the trigger reason at the beginning of the next round, rather than silently switching question directions.

2.6 下游生成输入确认

2.6 Downstream Generation Input Confirmation

当下一步是页面生成、HiUI 生成、原型生成或 UX 验收时，需求确认和生成输入确认必须分开处理：

```
requirementGate
```
：确认产品目标、MVP、P0 场景、角色权限、核心规则和状态机；若命中后台增强场景，还要确认对应矩阵或策略是否已补齐。
```
generationInputGate
```
：确认页面清单、页面级提示词、HiUI 页型建议、路由、状态和验收标准。
```
generationReviewPack
```
：给用户确认用的审阅材料，必须包含完整页面级提示词；若当前交付模式包含 PRD，再额外包含 PRD 文档证据。没有这份材料，
```
generationInputGate
```
不能进入
```
confirmed
```
。
```
promptCompleteness
```
：内部校验 generation-pack 是否已达到可消费粒度；未通过时只能继续确认，或标记为待确认版本。用户回答过澄清问题，不等于已确认页面生成输入。进入下游生成前，必须展示生成输入确认块：

markdown

undefined

When the next step is page generation, HiUI generation, prototype generation, or UX acceptance, requirement confirmation and generation input confirmation must be handled separately:

```
requirementGate
```
: Confirm product objectives, MVP, P0 scenarios, role permissions, core rules, and state machines; if back-office enhanced scenarios are hit, also confirm whether corresponding matrices or strategies are completed.
```
generationInputGate
```
: Confirm page inventory, page-level prompts, HiUI page type recommendations, routing, states, and acceptance criteria.
```
generationReviewPack
```
: Review materials for user confirmation, must include complete page-level prompts; if the current delivery mode includes PRD, additionally include PRD document evidence. Without this material,
```
generationInputGate
```
cannot enter
```
confirmed
```
.
```
promptCompleteness
```
: Internal check whether generation-pack has reached consumable granularity; if not passed, can only continue confirmation, or mark as to-be-confirmed version. Answering clarification questions does not mean page generation input is confirmed. Before proceeding to downstream generation, must display the generation input confirmation block:

markdown

undefined

生成输入确认

Generation Input Confirmation

我将基于以下内容生成页面：

MVP 范围：...
P0 场景：...
角色与权限：...
核心数据对象：...
状态 / 生命周期：...
后台增强产物（如权限矩阵 / 状态流转表 / 字段字典 / 异常与审计矩阵 / 批量规范）：...
页面清单：...
页面级提示词（完整正文或完整文件路径）：...
HiUI 页型建议：...
假设与风险：...

请选择：

A. 确认并生成
B. 调整 MVP / P0 场景
C. 调整页面清单 / 页面提示词
D. 保留当前假设，先生成一版

只有用户选择 A 或明确说“确认并生成”，才可记录 `generationInputGate.status = confirmed`。只有用户选择 D 或明确说“按你的假设推进 / 保留假设先生成 / 不用再确认”，才可记录 `generationInputGate.status = assumption-authorized`。
进入该确认块前，必须先展示 `generationReviewPack`：
- `PRD evidence`：仅当当前交付模式包含 PRD 时必填；值为在线协作文档标题 + 链接，或 Markdown 文件绝对路径
- `页面清单`
- `完整页面级提示词`：允许内联，或以独立文件承载并给出完整路径；不允许只给摘要
- `backend-ops-pack`：仅在命中后台增强场景时必填；值为内联正文、独立文件路径，或明确列出本轮已确认的后台增强产物清单
进入 `generationInputGate` 的最小前提：P0 关键页面已通过页型对应的字段粒度校验，且 B2B / 管理后台需求中的高影响“对象 / 字段 / 规则 / 状态 / 异常 / 审计”缺口已处理。若需求涉及多角色、多状态流转、敏感字段、批量任务、导入导出、外部依赖或存量改造，对应的后台增强产物也必须达到可消费粒度。页型级粒度要求与 `draft generation-pack / consumable generation-pack` 的区分，以 `references/confirmation-model.md` 和 `references/delivery-modes.md` 为准。
若当前只能产出产品方案、页面骨架、抽象版页面提示词、提示词摘要，或在交付模式包含 PRD 时只有“PRD 摘要而无文档链接/路径”，这些内容最多只能作为评审草稿，不得包装成可直接下游消费的 generation-pack，也不得进入生成输入确认块。
这些表达不能自动视为授权假设：`生成页面`、`继续`、`开始吧`、`端到端`、`一条龙`。

I will generate pages based on the following content:

MVP Scope: ...
P0 Scenarios: ...
Roles and Permissions: ...
Core Data Objects: ...
State / Lifecycle: ...
Back-office Enhanced Deliverables (e.g., permission matrix / state transition table / field dictionary / exception and audit matrix / batch specification): ...
Page Inventory: ...
Page-level Prompts (complete text or complete file path): ...
HiUI Page Type Recommendations: ...
Assumptions and Risks: ...

Please select:

A. Confirm and Generate
B. Adjust MVP / P0 Scenarios
C. Adjust Page Inventory / Page Prompts
D. Retain Current Assumptions, Generate a Version First

Only when the user selects A or explicitly says "Confirm and generate" can `generationInputGate.status = confirmed` be recorded. Only when the user selects D or explicitly says "Proceed with your assumptions / Retain assumptions and generate first / No need to confirm again" can `generationInputGate.status = assumption-authorized` be recorded.
Before entering this confirmation block, must display `generationReviewPack`:
- `PRD evidence`: Required only when current delivery mode includes PRD; value is online collaborative document title + link, or absolute path of Markdown file
- `Page Inventory`
- `Complete Page-level Prompts`: Allowed to be inline, or carried in an independent file with complete path provided; summaries are not allowed
- `backend-ops-pack`: Required only when back-office enhanced scenarios are hit; value is inline text, independent file path, or explicitly listed inventory of confirmed back-office enhanced deliverables in this round
Minimum prerequisite for entering `generationInputGate`: P0 key pages have passed field granularity verification corresponding to page types, and high-impact "object / field / rule / state / exception / audit" gaps in B2B / management back-office requirements have been addressed. If requirements involve multi-role, multi-state transition, sensitive fields, batch tasks, import/export, external dependencies, or legacy transformation, corresponding back-office enhanced deliverables must also reach consumable granularity. Page-type granularity requirements and distinction between `draft generation-pack / consumable generation-pack` are based on `references/confirmation-model.md` and `references/delivery-modes.md`.
If only product solutions, page skeletons, abstract page prompts, prompt summaries can be produced, or only "PRD summary without document link/path" when delivery mode includes PRD, these contents can only be used as review drafts, cannot be packaged as generation-pack directly consumable by downstream, and cannot enter generation input confirmation block.
These expressions cannot be automatically regarded as assumption authorization: `Generate pages`, `Continue`, `Start`, `End-to-end`, `One-stop`.

2.7 问题债务与确认完整度

2.7 Question Debt and Confirmation Completeness

使用

questionDebt

判断反问是否可以结束，而不是用“是否问满 3 个问题”判断。

内部按这些类别维护问题债务：业务价值 / 优先级、目标 / 成功指标、用户 / 角色 / 权限、P0 场景、MVP 范围 / 非目标、核心流程、业务规则、数据对象 / 字段、状态机 / 生命周期、权限矩阵 / 数据权限、字段字典 / 脱敏规则、多租户 / 版本 / 开通模型、主数据 / 系统边界、批量操作 / 导入导出 / 异步任务、异常 / 审计 / 风险、外部依赖 / 数据契约、迁移 / 灰度 / 发布策略、页面清单 / 路由、交付模式 / 下游用途。

若执行了项目上下文预载，内部额外维护：

```
repoFindings
```
：仓库中已找到的对象、命名、页面模式、接口约束或历史实现证据
```
repoAssumptions
```
：基于仓库证据形成、但尚未被用户确认的推断
```
repoConflicts
```
：仓库证据与用户口述、已有材料或当前方案之间的冲突点
```
repoGaps
```
：仓库扫描后仍缺失、且会显著影响范围或交付的关键信息

每轮确认后，更新：

```
resolvedDebt
```
：本轮已确认内容
```
remainingDebt
```
：仍会影响范围、页面、规则、权限、数据、状态、异常、验收或下游生成输入的未知项
```
assumptions
```
：当前用于推进的假设
```
nextAction
```
：继续确认、输出交付物、等待授权假设或调整范围

输出时，显式区分三类信息：

```
用户已确认
```
：用户明确给出的目标、规则、范围、页面或决策
```
仓库已知 / 仓库推断
```
：来自本地文档、代码、接口、类型或已有页面的证据与推断
```
当前假设
```
：为了推进而采用、但尚未被用户确认的推荐方案

仓库证据只能减少问题债务，不能替代用户确认；若仓库证据与用户意图可能冲突，优先发起确认，不得直接收口。

需要继续确认时，输出轻量确认进度：

markdown

undefined

Use

questionDebt

to judge whether follow-up questions can end, rather than using "whether 3 questions have been asked".

Internally maintain question debt by these categories: business value / priority, objective / success metrics, user / role / permission, P0 scenario, MVP scope / non-target, core flow, business rules, data object / field, state machine / lifecycle, permission matrix / data permission, field dictionary / desensitization rules, multi-tenant / version / activation model, master data / system boundary, batch operation / import/export / asynchronous task, exception / audit / risk, external dependency / data contract, migration / grayscale / release strategy, page inventory / routing, delivery mode / downstream usage.

If project context preload is executed, additionally maintain internally:

```
repoFindings
```
: Evidence and inferences of objects, naming, page patterns, interface constraints, or historical implementations found in the repository
```
repoAssumptions
```
: Inferences formed based on repository evidence but not yet confirmed by users
```
repoConflicts
```
: Conflicts between repository evidence and user statements, existing materials, or current solutions
```
repoGaps
```
: Key information still missing after repository scanning that will significantly affect scope or delivery

After each round of confirmation, update:

```
resolvedDebt
```
: Content confirmed in this round
```
remainingDebt
```
: Unknown items that still affect scope, page, rule, permission, data, state, exception, acceptance, or downstream generation input
```
assumptions
```
: Current assumptions used to advance
```
nextAction
```
: Continue confirmation, output deliverables, wait for assumption authorization, or adjust scope

When outputting, explicitly distinguish three types of information:

```
Confirmed by User
```
: Objectives, rules, scope, pages, or decisions explicitly provided by the user
```
Known from Repository / Inferred from Repository
```
: Evidence and inferences from local documents, code, interfaces, types, or existing pages
```
Current Assumptions
```
: Recommended solutions adopted to advance but not yet confirmed by users

Repository evidence can only reduce question debt, cannot replace user confirmation; if repository evidence may conflict with user intent, prioritize initiating confirmation, do not conclude directly.

When needing to continue confirmation, output lightweight confirmation progress:

markdown

undefined

确认进度

Confirmation Progress

已确认：

<2-4 条关键已确认内容>

本轮新增确认 / 清除的债务：

<本轮新增确认了什么>
<本轮清除了哪些最高影响 questionDebt>

仍待确认：

<2-4 条最高影响问题债务>

当前假设：

<1-3 条当前使用的推荐假设>

下一步：

<因此下一轮优先确认什么，以及为什么>
```
继续确认 <最高影响方向>
```

接受当前假设，输出 <目标交付物>

```
调整 <范围 / 页面 / 规则>
```


不要每轮展示完整 `questionDebt` 大表；内部完整，外部轻量。

Confirmed:

<2-4 key confirmed items>

Newly Confirmed / Debt Cleared in This Round:

<What was newly confirmed in this round>
<Which highest-impact questionDebt was cleared in this round>

Still to Be Confirmed:

<2-4 highest-impact questionDebt>

Current Assumptions:

<1-3 current recommended assumptions>

Next Step:

<Therefore, what to prioritize confirming in the next round, and why>

Continue confirming <highest-impact direction>

Accept current assumptions, output <target deliverables>

```
Adjust <scope / page / rule>
```


Do not display the full `questionDebt` table in each round; keep it complete internally and lightweight externally.

2.8 防过早收口

2.8 Prevent Premature Closure

出现以下任一情况时，不得因为“已经问了两轮”或“已经能写出方案”就结束确认：

仍有 2 个以上高影响
```
remainingDebt
```
会改变字段、权限、状态、异常、导入策略、日志/审计、页面工作面或验收标准。
当前仍无法说明业务价值、P0 理由或为什么推荐某一方案；此时不得把结果写成专家建议或定稿方案。
当前输出中的关键规则主要来自假设，而不是用户确认；尤其是唯一性、覆盖策略、删除/停用、导入冲突、版本/生效方式。
用户输入属于 B2B / 管理后台 / 配置治理类，但对象粒度、角色权限、批量操作、异常路径、审计/历史、数据来源中仍有关键缺口。
已经识别出高风险后台能力，如审批、发布、批量导入导出、敏感字段、存量迁移或外部回调，但还没有补齐对应矩阵、策略或回退方案。
已命中多租户、版本差异、主数据归属或系统边界问题，但仍未说明事实源、开通模型或冲突处理策略。
交互设计刚因用户反馈发生变化，例如从抽屉改为表格内编辑；此时应回到相关问题债务，继续确认被该变化影响的校验、保存策略、状态和边界情况。

如果需要继续确认，优先按“规则 / 数据 / 异常 / 体验”顺序补问，而不是马上输出完整方案。

命中

references/confirmation-model.md

中的

antiPrematureClosure

信号时，除继续确认外，还必须把

generationInputGate

视为未就绪，不得继续停留在

ready-for-review

。

Do not end confirmation because "two rounds of questions have been asked" or "a solution can already be written" if any of the following situations occur:

There are still more than 2 high-impact
```
remainingDebt
```
that will change fields, permissions, states, exceptions, import strategies, logs/audit, page work surfaces, or acceptance criteria.
Currently unable to explain business value, P0 reasons, or why a certain solution is recommended; do not write the result as expert advice or a final solution at this time.
Key rules in current output mainly come from assumptions, not user confirmation; especially uniqueness, override strategies, deletion/deactivation, import conflicts, version/activation methods.
User input belongs to B2B / management back-office / configuration governance type, but there are still key gaps in object granularity, role permissions, batch operations, exception paths, audit/history, data sources.
High-risk back-office capabilities such as approval, release, batch import/export, sensitive fields, legacy migration, or external callbacks have been identified, but corresponding matrices, strategies, or fallback solutions have not been completed.
Multi-tenant, version differences, master data ownership, or system boundary issues have been hit, but source of truth, activation model, or conflict handling strategy has not been explained.
Interaction design has just changed due to user feedback, such as switching from drawer to in-table editing; at this time, return to relevant question debt and continue to confirm verification, saving strategies, states, and boundary situations affected by the change.

If confirmation needs to continue, prioritize following up in the order of "rules / data / exceptions / experience", rather than immediately outputting a complete solution.

When hitting

antiPrematureClosure

signals in

references/confirmation-model.md

, in addition to continuing confirmation, must treat

generationInputGate

as not ready, cannot stay in

ready-for-review

3. 主流程执行映射

3. Main Flow Execution Mapping

“细化轮次”不再作为另一套独立流程存在，而是作为上方统一主流程的执行映射。每轮保持简洁，不要过度记录显而易见的内容。

主流程阶段 1：场景命中与交付边界 判断需求类型、主 playbook、主流程对象和目标交付模式；若在仓库中执行，同时完成项目上下文预载与“沿用 / 扩展 / 重做”判断。
主流程阶段 2：价值 / 目标 / 角色 / P0 收敛业务价值、成功指标、受影响角色、P0 场景、MVP 边界和非目标；若这些未稳，不得进入页面细化。
主流程阶段 3：对象 / 字段 / 规则 / 状态 收敛对象模型、关键字段、状态流转、权限、异常、审计、数据来源和唯一性/冲突规则。
主流程阶段 4：治理结构与专家判断 按命中场景补齐
```
AX01 ~ AX06
```
、
```
BX01 ~ BX05
```
、
```
PB01 ~ PB04
```
；这一步是条件插层，但一旦触发就是必经阶段，不能跳过。
主流程阶段 5：页面 / 工作面 / 交互 / 验收 把上游已确认结构翻译为导航、页面、工作面、字段/列/筛选/操作、状态和验收标准。
主流程阶段 6：追踪与交付 分配
```
S/F/R/D/P/PR
```
ID，验证追踪关系，并只输出所选交付模式需要的章节；若下游需要页面生成或验收，还要进入
```
generationReviewPack
```
与
```
generationInputGate
```
。

执行要求：

阶段 4 是 条件插层，不是可选润色；命中治理复杂度后必须执行。
阶段 5 只能建立在阶段 2-4 的高影响债务已收敛或已获授权假设之上。
阶段 6 不等于默认进入生成；若用户只要方案、PRD 或页面清单，应在对应最小交付模式结束。

"Refinement rounds" no longer exist as another independent process, but as an execution mapping of the unified main flow above. Keep each round concise, do not over-record obvious content.

Main Flow Phase 1: Scenario Matching and Delivery Boundary Determine requirement type, main playbook, main flow object, and target delivery mode; if executed in a repository, complete project context preload and "follow / extend / rebuild" judgment at the same time.
Main Flow Phase 2: Value / Objective / Role / P0 Converge business value, success metrics, affected roles, P0 scenarios, MVP boundaries, and non-targets; if these are not stable, do not proceed to page refinement.
Main Flow Phase 3: Object / Field / Rule / State Converge object model, key fields, state transitions, permissions, exceptions, audits, data sources, and uniqueness/conflict rules.
Main Flow Phase 4: Governance Structure and Expert Judgment Supplement
```
AX01 ~ AX06
```
,
```
BX01 ~ BX05
```
,
```
PB01 ~ PB04
```
according to hit scenarios; this step is a conditional interlayer, but once triggered, it is a necessary phase and cannot be skipped.
Main Flow Phase 5: Page / Work Surface / Interaction / Acceptance Translate upstream confirmed structure into navigation, pages, work surfaces, field/column/filter/operation, states, and acceptance criteria.
Main Flow Phase 6: Traceability and Delivery Assign
```
S/F/R/D/P/PR
```
IDs, verify traceability relationships, and only output chapters required by the selected delivery mode; if downstream requires page generation or acceptance, also enter
```
generationReviewPack
```
and
```
generationInputGate
```
.

Execution requirements:

Phase 4 is a conditional interlayer, not optional polishing; must be executed after hitting governance complexity.
Phase 5 can only be built on the basis that high-impact debt in phases 2-4 has converged or assumption authorization has been obtained.
Phase 6 does not mean default entry into generation; if the user only needs solutions, PRDs, or page inventories, end at the corresponding minimal delivery mode.

追踪模型

Traceability Model

当输出不只是快速摘要时，使用稳定 ID：

```
S01
```
：用户场景
```
F01
```
：功能 / 模块
```
R01
```
：业务规则
```
D01
```
：数据对象
```
P01
```
：页面 / 弹窗 / 工作面
```
PR01
```
：页面提示词

复杂需求要包含覆盖矩阵，展示“场景 -> 功能 -> 规则 -> 页面 -> 提示词”的关系。表格结构见

references/output-templates.md

。

When output is not just a quick summary, use stable IDs:

```
S01
```
: User Scenario
```
F01
```
: Function / Module
```
R01
```
: Business Rule
```
D01
```
: Data Object
```
P01
```
: Page / Pop-up / Work Surface
```
PR01
```
: Page Prompt

For complex requirements, include a coverage matrix showing the relationship of "Scenario -> Function -> Rule -> Page -> Prompt". Table structure can be found in

references/output-templates.md

B 端专家产物

B-end Expert Deliverables

当用户希望获得的不只是“整理后的需求”，而是“带判断的产品建议”时，优先补充以下专家产物。它们可单独输出，也可并入产品方案、PRD 附录或

backend-ops-pack

。

```
BX01 业务价值与优先级判断
```
：回答为什么做、为什么现在做、为什么是 P0
```
BX02 方案取舍表
```
：回答为什么选这个方案而不是另一个
```
BX03 多租户 / 版本 / 开通模型
```
：回答租户隔离、套餐差异、功能开通和客户差异化
```
BX04 主数据与系统边界
```
：回答事实源、创建归属、同步方式和冲突解决
```
BX05 反模式与风险提示
```
：回答当前方案哪里危险、为什么危险、最低防线是什么

When users want more than "organized requirements" but "product suggestions with judgments", prioritize supplementing the following expert deliverables. They can be output separately, or incorporated into product solutions, PRD appendices, or

backend-ops-pack

```
BX01 Business Value and Priority Judgment
```
: Answers why to do it, why do it now, why it is P0
```
BX02 Solution Trade-off Table
```
: Answers why choose this solution over others
```
BX03 Multi-tenant / Version / Activation Model
```
: Answers tenant isolation, package differences, feature activation, and customer differentiation
```
BX04 Master Data and System Boundary
```
: Answers source of truth, creation ownership, synchronization method, and conflict resolution
```
BX05 Anti-pattern and Risk Prompt
```
: Answers where the current solution is dangerous, why it is dangerous, and what the minimum defense is

高频行业 Playbook

High-frequency Industry Playbook

当需求明显命中以下高频 B 端场景时，不要只沿用通用需求细化流程；必须切换到对应 playbook，把该场景的关键问题、关键产物和关键反模式纳入本轮输出或待确认项。

When requirements clearly hit the following high-frequency B-end scenarios, do not only follow the general requirement refinement process; must switch to the corresponding playbook, and incorporate key questions, key deliverables, and key anti-patterns of the scenario into this round's output or to-be-confirmed items.

PB01 工单 / 审批 / SLA Playbook

PB01 Ticket / Approval / SLA Playbook

触发信号：

工单、审批、派单、转派、退回、撤回、催办、升级、超时、SLA、节点责任
多角色接力处理、流程节点流转、时限约束、人工处置闭环

必问问题：

工单/单据由谁发起，谁接单，谁处理，谁审批，谁兜底
状态节点有哪些，哪些节点可回退、撤回、转派、加签或终止
SLA 从哪个时点开始计时，到哪个时点结束，超时后怎么升级
驳回、退回、取消、作废、重新提交之间的边界是什么
是否需要催办、提醒、抄送、升级、自动转派或人工兜底

必须产物：

```
AX02 状态流转表
```
```
AX04 异常与审计矩阵
```
```
BX02 方案取舍表
```
如存在时效管理，再补一个
```
PB01 SLA 责任表
```

markdown

undefined

Trigger signals:

Ticket, approval, assignment, reassignment, return, withdrawal, reminder, escalation, timeout, SLA, node responsibility
Multi-role relay processing, process node transition, time limit constraints, manual disposal closure

Mandatory questions:

Who initiates, accepts, processes, approves, and provides fallback for tickets/documents
What state nodes exist, which nodes allow return, withdrawal, reassignment, addition of signatories, or termination
When does SLA start and end timing, how to escalate after timeout
What are the boundaries between rejection, return, cancellation, void, and resubmission
Whether reminders, notifications, copies, escalation, automatic reassignment, or manual fallback are needed

Mandatory deliverables:

```
AX02 State Transition Table
```
```
AX04 Exception and Audit Matrix
```
```
BX02 Solution Trade-off Table
```
If time management exists, supplement a
```
PB01 SLA Responsibility Table
```

markdown

undefined

PB01 SLA 责任表

PB01 SLA Responsibility Table

节点	责任角色	开始计时点	截止时限	超时处理	通知对象	备注
待受理	一线客服	工单创建成功	15 分钟	超时升级给组长	客服/组长	P0
待审批	审批人	提交审批后	4 小时	超时催办，24 小时后转上级	审批人/创建人	待确认
待处理	处理人	审批通过后	2 个工作日	超时转派或升级	处理人/主管	当前假设


常见反模式：
- 只有状态，没有节点责任人
- 只有流程图，没有 SLA 起止口径
- 把退回、驳回、取消、终止混成一个动作
- 只做审批通过，不做超时、转派、催办和人工兜底

Node	Responsible Role	Start Time Point	Deadline	Timeout Handling	Notification Recipient	Remarks
Pending Acceptance	Frontline Customer Service	After ticket creation success	15 minutes	Escalate to team leader on timeout	Customer Service/Team Leader	P0
Pending Approval	Approver	After submitting approval	4 hours	Remind on timeout, escalate to superior after 24 hours	Approver/Initiator	To be confirmed
Pending Processing	Processor	After approval passes	2 working days	Reassign or escalate on timeout	Processor/Supervisor	Current assumption


Common anti-patterns:
- Only states, no node responsible persons
- Only flowcharts, no SLA start/end calibers
- Mix return, rejection, cancellation, termination into one action
- Only implement approval passing, no timeout, reassignment, reminder, or manual fallback

PB02 结算 / 对账 / 发票 Playbook

PB02 Settlement / Reconciliation / Invoice Playbook

触发信号：

结算单、账单、对账单、应收应付、开票、红冲、作废、税额、核销、账期
金额口径、单据关联、财务审核、对账差异、发票流转

必问问题：

金额从哪里来，谁是事实源，金额口径如何定义
结算周期、账期、出账、锁账、核销、作废、红冲的规则是什么
对账是逐笔对账、汇总对账还是差异对账，差异如何归因和处理
发票是申请、审核、开具、寄送、签收还是只登记结果
金额字段是否允许修改，修改后是否影响历史单据或审计

必须产物：

```
BX04 主数据与系统边界
```
```
AX02 状态流转表
```
```
AX03 字段字典
```
如涉及账务口径，再补一个
```
PB02 金额口径与单据关系表
```

markdown

undefined

Trigger signals:

Settlement sheet, bill, reconciliation sheet, accounts receivable/payable, invoicing, red冲, void, tax amount, write-off, payment term
Amount caliber, document association, financial review, reconciliation differences, invoice flow

Mandatory questions:

Where does the amount come from, who is the source of truth, how is the amount caliber defined
What are the rules for settlement cycle, payment term, billing, locking accounts, write-off, void, red冲
Whether reconciliation is item-by-item, summary, or difference reconciliation, how to attribute and handle differences
Whether invoice is application, review, issuance, delivery, sign-off, or only result registration
Whether amount fields can be modified, and whether modification affects historical documents or audits

Mandatory deliverables:

```
BX04 Master Data and System Boundary
```
```
AX02 State Transition Table
```
```
AX03 Field Dictionary
```

If accounting caliber is involved, supplement a

PB02 Amount Caliber and Document Relationship Table

markdown

undefined

PB02 金额口径与单据关系表

PB02 Amount Caliber and Document Relationship Table

单据/对象	金额字段	口径说明	来源系统	是否可编辑	关联单据	异常处理	备注
结算单	settlementAmount	最终应结金额	结算系统	否	对账单/发票	差异需人工复核	P0
对账单	reconAmount	对账汇总金额	对账服务	否	结算单	差异生成对账异常	当前假设
发票申请	invoiceAmount	申请开票金额	财务后台	审核前可改	结算单	超开需拦截	待确认


常见反模式：
- 页面做出来了，但金额口径没定义
- 结算、对账、发票三条线没有关系模型
- 作废、红冲、冲销、重开边界不清
- 允许人工改金额，但没有审计和影响面说明

Document/Object	Amount Field	Caliber Explanation	Source System	Editable	Associated Documents	Exception Handling	Remarks
Settlement Sheet	settlementAmount	Final payable amount	Settlement System	No	Reconciliation Sheet/Invoice	Differences require manual review	P0
Reconciliation Sheet	reconAmount	Reconciliation summary amount	Reconciliation Service	No	Settlement Sheet	Differences generate reconciliation exceptions	Current assumption
Invoice Application	invoiceAmount	Applied invoicing amount	Financial Back-office	Editable before review	Settlement Sheet	Over-issuance needs to be blocked	To be confirmed


Common anti-patterns:
- Pages are built, but amount caliber is not defined
- Settlement, reconciliation, and invoice lines have no relationship model
- Boundaries between void, red冲, write-off, reissuance are unclear
- Allow manual modification of amounts, but no audit and impact explanation

PB03 账号 / 组织 / 权限 Playbook

PB03 Account / Organization / Permission Playbook

触发信号：

账号、成员、组织、部门、岗位、角色、权限、数据权限、租户管理员、SSO、邀请、禁用
人员管理、组织架构、职责分离、越权控制、账号生命周期

必问问题：

组织、部门、岗位、角色分别代表什么，谁继承谁
账号生命周期是邀请、激活、冻结、禁用、离职回收还是别的模型
权限是按角色、岗位、部门、数据范围还是字段范围生效
是否存在租户管理员、超管、审计员、只读角色等特殊身份
是否需要 SSO、LDAP、第三方身份源或跨租户账号策略

必须产物：

```
AX01 权限矩阵
```
```
AX03 字段字典
```
```
BX03 多租户 / 版本 / 开通模型
```
如组织关系复杂，再补一个
```
PB03 组织继承与授权边界表
```

markdown

undefined

Trigger signals:

Account, member, organization, department, position, role, permission, data permission, tenant administrator, SSO, invitation, disable
Personnel management, organizational structure, separation of duties, unauthorized access control, account lifecycle

Mandatory questions:

What do organization, department, position, role represent, who inherits from whom
What is the account lifecycle model: invitation, activation, freeze, disable, resignation recovery, or others
Whether permissions take effect by role, position, department, data scope, or field scope
Whether special identities such as tenant administrator, super admin, auditor, read-only role exist
Whether SSO, LDAP, third-party identity sources, or cross-tenant account strategies are needed

Mandatory deliverables:

```
AX01 Permission Matrix
```
```
AX03 Field Dictionary
```

BX03 Multi-tenant / Version / Activation Model

If organizational relationships are complex, supplement a

PB03 Organization Inheritance and Authorization Boundary Table

markdown

undefined

PB03 组织继承与授权边界表

PB03 Organization Inheritance and Authorization Boundary Table

维度	定义	是否继承	可否下放	冲突处理	备注
部门权限	部门级基础菜单权限	是	否	上级覆盖下级	P0
岗位权限	岗位职责权限包	否	是	岗位权限与角色取并集	当前假设
数据权限	按部门/本人/全部数据范围	是	是	就近最小权限优先	待确认
字段权限	敏感字段查看与编辑权限	否	否	超管例外	P0


常见反模式：
- 只有角色权限，没有数据权限
- 组织结构和权限结构混为一谈
- 禁用账号不回收权限、不处理在途任务
- 敏感字段只做前端隐藏，不做产品规则和审计口径

Dimension	Definition	Inheritable	Delegable	Conflict Handling	Remarks
Department Permission	Department-level basic menu permission	Yes	No	Superior overrides subordinate	P0
Position Permission	Position responsibility permission package	No	Yes	Position permission and role take union	Current assumption
Data Permission	Data scope by department/self/all	Yes	Yes	Nearest minimal permission takes precedence	To be confirmed
Field Permission	Sensitive field view and edit permission	No	No	Super admin exception	P0


Common anti-patterns:
- Only role permissions, no data permissions
- Mix organizational structure and permission structure together
- Disable accounts without revoking permissions or handling in-transit tasks
- Only hide sensitive fields on the frontend, no product rules and audit calibers

PB04 配置中心 / 发布 / 回滚 Playbook

PB04 Configuration Center / Release / Rollback Playbook

触发信号：

配置中心、规则引擎、发布、灰度、生效、回滚、版本、草稿、审批发布、环境差异
参数配置、策略配置、开关控制、模板配置、运营规则

必问问题：

配置项粒度是什么，按租户、按环境、按业务线还是按对象生效
生效方式是即时、定时、灰度还是审批后发布
版本模型是什么，是否支持草稿、历史版本、对比、回滚
配置冲突如何处理，优先级和覆盖顺序是什么
发布失败、回滚、依赖校验和误操作防护怎么做

必须产物：

```
BX02 方案取舍表
```
```
AX02 状态流转表
```
```
AX06 存量系统改造与发布策略
```
如配置复杂，再补一个
```
PB04 配置生效与覆盖顺序表
```

markdown

undefined

Trigger signals:

Configuration center, rule engine, release, grayscale, activation, rollback, version, draft, approval release, environment differences
Parameter configuration, strategy configuration, switch control, template configuration, operation rules

Mandatory questions:

What is the configuration item granularity, does it take effect by tenant, environment, business line, or object
Whether activation method is immediate, scheduled, grayscale, or post-approval release
What is the version model, whether draft, historical version, comparison, rollback are supported
How to handle configuration conflicts, what are the priority and override order
How to handle release failure, rollback, dependency validation, and misoperation protection

Mandatory deliverables:

```
BX02 Solution Trade-off Table
```
```
AX02 State Transition Table
```

AX06 Legacy System Transformation and Release Strategy

If configuration is complex, supplement a

PB04 Configuration Activation and Override Order Table

markdown

undefined

PB04 配置生效与覆盖顺序表

PB04 Configuration Activation and Override Order Table

配置层级	生效范围	优先级	生效方式	回滚方式	备注
全局默认配置	全租户	1	发布后生效	回退到上一版本	P0
租户级配置	单租户	2	发布后覆盖全局	租户级回滚	当前假设
活动级临时配置	单活动/短期	3	定时生效/失效	到期自动失效	待确认


常见反模式：
- 把配置中心做成“提交即生效”的普通表单
- 没有版本、对比、回滚和依赖校验
- 全局配置和租户配置覆盖顺序不清
- 只做页面，不做发布流程和失败兜底

Configuration Level	Effective Scope	Priority	Activation Method	Rollback Method	Remarks
Global Default Configuration	All tenants	1	Takes effect after release	Roll back to previous version	P0
Tenant-level Configuration	Single tenant	2	Overrides global after release	Tenant-level rollback	Current assumption
Activity-level Temporary Configuration	Single activity/short-term	3	Scheduled activation/deactivation	Expires automatically	To be confirmed


Common anti-patterns:
- Make configuration center a regular form with "submit and take effect immediately"
- No version, comparison, rollback, or dependency validation
- Override order between global and tenant configurations is unclear
- Only build pages, no release process and failure fallback

Playbook 使用规则

Playbook Usage Rules

命中某个 playbook 时，至少在本轮输出中显式标记：
```
当前命中 PB0X
```
若需求同时命中多个 playbook，先按 主流程对象 选主 playbook，再把其余 playbook 作为补充约束
playbook 不是装饰性章节；命中后必须影响问题轮次、产物选择、页面提示词和门禁判断
若用户提供的需求明显属于上述四类之一，但输出中没有体现对应 playbook 的关键问题、关键产物或反模式检查，视为未完成

When hitting a playbook, at least explicitly mark in this round's output:
```
Current hit PB0X
```
If requirements hit multiple playbooks at the same time, first select the main playbook according to main flow object, then treat other playbooks as supplementary constraints
Playbooks are not decorative chapters; after hitting, must affect question rounds, deliverable selection, page prompts, and gate judgment
If the user's provided requirements clearly belong to one of the four categories above, but the output does not reflect key questions, key deliverables, or anti-pattern checks of the corresponding playbook, it is considered incomplete

B 端增强产物

B-end Enhanced Deliverables

当命中对应场景时，除标准产品方案/页面清单/提示词外，还应补充以下后台原生产物。若当前轮次无法完整产出，必须至少显式记录为待确认项，不得静默略过。

AX01 权限矩阵

：适用于多角色、多租户、敏感数据、字段级可见性或危险操作场景。至少包含

角色 / 岗位 / 资源对象 / 动作 / 数据范围 / 字段范围 / 脱敏规则 / 审批或二次确认要求 / 审计要求

。

AX02 状态流转表

：适用于审批、工单、发布、处置、配置生效等有生命周期状态的需求。至少包含

当前状态 / 触发动作 / 执行角色 / 前置条件 / 后置状态 / 副作用 / 通知对象 / 是否可撤回或补偿

。

AX03 字段字典

：适用于对象复杂、跨页面共享字段或与接口/导入模板强绑定的需求。至少包含

字段名 / 含义 / 类型 / 来源 / 是否必填 / 默认值 / 校验 / 枚举 / 显隐规则 / 是否脱敏 / 是否可编辑

。

AX04 异常与审计矩阵

：适用于运营处置、人工兜底、危险操作、合规留痕或故障回退场景。至少包含

异常场景 / 用户可见提示 / 系统记录 / 审计日志 / 补救动作 / 是否通知 / 是否可重试

。

AX05 批量 / 导入导出 / 异步任务规范

：适用于批量变更、大表导出、文件导入、长耗时任务。至少包含

触发方式 / 规模限制 / 预校验 / 部分成功策略 / 失败明细 / 进度反馈 / 结果回执 / 幂等与重试 / 权限要求

。

AX06 存量系统改造与发布策略

：适用于旧系统替换、规则重构、字段改版、平台迁移。至少包含

现状问题 / To-Be 差异 / 数据迁移 / 权限迁移 / 兼容期 / 灰度范围 / 回滚方案 / 培训或运营切换要求

。

后台增强产物不是固定都要输出。应根据需求命中场景选择最小集合：

命中 多角色 / 敏感字段 / 数据权限 时，至少输出
```
AX01
```
，必要时连带
```
AX03
```
命中 审批 / 工单 / 发布 / 生命周期 时，至少输出
```
AX02
```
命中 运营处置 / 高风险动作 / 合规要求 时，至少输出
```
AX04
```
命中 批量处理 / 导入导出 / 长耗时任务 时，至少输出
```
AX05
```
命中 旧系统改造 / 平滑迁移 / 上线切换 时，至少输出
```
AX06
```

When hitting corresponding scenarios, in addition to standard product solutions/page inventories/prompts, supplement the following back-office native deliverables. If complete output cannot be achieved in the current round, must at least explicitly record it as a to-be-confirmed item, do not skip silently.

AX01 Permission Matrix

: Applicable to scenarios with multi-role, multi-tenant, sensitive data, field-level visibility, or dangerous operations. At least includes

Role / Position / Resource Object / Action / Data Scope / Field Scope / Desensitization Rule / Secondary Confirmation or Approval Requirement / Audit Requirement

AX02 State Transition Table

: Applicable to requirements with lifecycle states such as approval, ticket, release, disposal, configuration activation. At least includes

Current State / Trigger Action / Executing Role / Precondition / Post State / Side Effect / Notification Recipient / Whether Retractable or Compensable

AX03 Field Dictionary

: Applicable to requirements with complex objects, cross-page shared fields, or strong binding with interfaces/import templates. At least includes

Field Name / Meaning / Type / Source / Required / Default Value / Validation / Enumeration / Visibility/Linkage Rule / Desensitization/Editing Rule

AX04 Exception and Audit Matrix

: Applicable to scenarios such as operation disposal, manual fallback, dangerous operations, compliance trails, or fault rollback. At least includes

Exception Scenario / User-visible Prompt / System Record / Audit Log / Remedial Action / Whether to Notify / Whether Retryable

AX05 Batch / Import/Export / Asynchronous Task Specification

: Applicable to batch changes, large table export, file import, long-duration tasks. At least includes

Trigger Method / Scale Limit / Pre-validation / Partial Success Strategy / Failure Details / Progress Feedback / Result Receipt / Idempotency and Retry / Permission Requirement

AX06 Legacy System Transformation and Release Strategy

: Applicable to old system replacement, rule reconstruction, field revision, platform migration. At least includes

Current Problem / To-Be Difference / Data Migration / Permission Migration / Compatibility Period / Grayscale Scope / Rollback Plan / Training or Operation Switch Requirements

Back-office enhanced deliverables do not need to be output fixedly. Select the minimal set according to the hit scenario:

When hitting multi-role / sensitive fields / data permissions, at least output
```
AX01
```
, and
```
AX03
```
if necessary
When hitting approval / ticket / release / lifecycle, at least output
```
AX02
```
When hitting operation disposal / high-risk actions / compliance requirements, at least output
```
AX04
```
When hitting batch processing / import/export / long-duration tasks, at least output
```
AX05
```
When hitting old system transformation / smooth migration / launch switch, at least output
```
AX06
```

B 端增强产物模板

B-end Enhanced Deliverable Templates

以下模板可直接写入对话、Markdown 产物、PRD 附录或

backend-ops-pack

。若信息尚未确认，用

待确认

、

当前假设

、

不适用

标记，不得留空白列假装已收敛。

The following templates can be directly written into conversations, Markdown deliverables, PRD appendices, or

backend-ops-pack

. If information is not yet confirmed, mark with

To be confirmed

Current assumption

Not applicable

, do not leave blank columns pretending to have converged.

AX01 权限矩阵模板

AX01 Permission Matrix Template

适用时机：

多角色、多岗位、多租户
存在数据范围隔离
存在字段脱敏、字段只读
存在危险操作、审批或双人复核

markdown

undefined

Applicable occasions:

Multi-role, multi-position, multi-tenant
Data scope isolation exists
Field desensitization, field read-only exists
Dangerous operations, approval, or double review requirements exist

markdown

undefined

AX01 权限矩阵

AX01 Permission Matrix

角色/岗位	资源对象	动作	数据范围	字段范围	脱敏规则	二次确认/审批要求	审计要求	备注
超级管理员	账号	查看/新增/编辑/停用	全量	全字段	不脱敏	停用需二次确认	记录操作者、时间、前后值	P0
运营专员	工单	查看/处理	所属团队	除手机号外可见	手机号后四位可见	转派需填写原因	记录处理动作与原因	当前假设
财务审核员	结算单	查看/审核	所属租户	金额字段只读、发票字段可见	银行账号脱敏	审核通过需二次确认	审核日志保留 180 天	待确认


最小要求：
- 每个关键角色至少覆盖一个核心资源对象
- 危险动作必须写明二次确认、审批或双人复核要求
- 涉及敏感信息时，必须写清脱敏口径，而不是只写“部分可见”

Role/Position	Resource Object	Action	Data Scope	Field Scope	Desensitization Rule	Secondary Confirmation/Approval Requirement	Audit Requirement	Remarks
Super Administrator	Account	View/Add/Edit/Disable	Full	All fields	No desensitization	Secondary confirmation required for disabling	Record operator, time, before/after values	P0
Operation Specialist	Ticket	View/Process	Own team	Visible except mobile number	Last four digits of mobile number visible	Reason required for reassignment	Record processing action and reason	Current assumption
Financial Reviewer	Settlement Sheet	View/Review	Own tenant	Amount fields read-only, invoice fields visible	Bank account desensitized	Secondary confirmation required for approval pass	Audit logs retained for 180 days	To be confirmed


Minimum requirements:
- Each key role covers at least one core resource object
- Dangerous operations must specify secondary confirmation, approval, or double review requirements
- When sensitive information is involved, must specify desensitization caliber, not just "partially visible"

AX02 状态流转表模板

AX02 State Transition Table Template

适用时机：

审批流、工单流、发布流、处置流
任一对象存在 3 个及以上业务状态
状态变化会触发通知、审计、回调或副作用

markdown

undefined

Applicable occasions:

Approval workflow, ticket workflow, release workflow, disposal workflow
Any object has 3 or more business states
State changes trigger notifications, audits, callbacks, or side effects

markdown

undefined

AX02 状态流转表

AX02 State Transition Table

当前状态	触发动作	执行角色	前置条件	后置状态	副作用/系统动作	通知对象	可撤回/补偿	备注
草稿	提交审核	创建人	必填字段完整	待审核	生成提交记录	审核人	可撤回，撤回后回到草稿	P0
待审核	审核通过	审核员	审核意见非空	已生效	写入生效时间、发布版本	创建人/订阅人	不可撤回，可走停用流程	当前假设
待审核	驳回	审核员	驳回原因必填	已驳回	记录驳回原因	创建人	不适用	P0
已生效	停用	管理员	无未完成关联任务	已停用	写入停用日志、触发缓存失效	运营负责人	可恢复，恢复后回到已生效	待确认


最小要求：
- 每个业务状态至少要有进入路径和离开路径
- 写清副作用，不得只写“更新状态”
- 若状态不可逆，必须明确补偿或替代流程

Current State	Trigger Action	Executing Role	Precondition	Post State	Side Effect/System Action	Notification Recipient	Retractable/Compensable	Remarks
Draft	Submit for Review	Creator	Required fields complete	Pending Review	Generate submission record	Reviewer	Retractable, returns to draft after withdrawal	P0
Pending Review	Approve	Reviewer	Review comment not empty	Activated	Write activation time, release version	Creator/Subscriber	Not retractable, can go through disable process	Current assumption
Pending Review	Reject	Reviewer	Rejection reason required	Rejected	Record rejection reason	Creator	Not applicable	P0
Activated	Disable	Administrator	No unfinished associated tasks	Disabled	Write disable log, trigger cache invalidation	Operation Leader	Restorable, returns to activated after restoration	To be confirmed


Minimum requirements:
- Each business state has at least an entry path and an exit path
- Specify side effects, do not only write "update state"
- If state is irreversible, must explicitly specify compensation or alternative process

AX03 字段字典模板

AX03 Field Dictionary Template

适用时机：

对象复杂、跨页面复用字段多
页面、接口、导入模板共享同一批字段
存在枚举、联动、显隐、脱敏或只读控制

markdown

undefined

Applicable occasions:

Complex objects, many cross-page reused fields
Pages, interfaces, import templates share the same set of fields
Enumeration, linkage, visibility, desensitization, or read-only control exists

markdown

undefined

AX03 字段字典

AX03 Field Dictionary

字段名	含义	类型	来源	必填	默认值	校验规则	枚举/示例	显隐/联动规则	脱敏/编辑规则	备注
tenantId	所属租户 ID	string	系统注入	是	当前登录租户	不可为空	`t_1001`	创建后只读	不脱敏，不可编辑	P0
status	状态	enum	系统计算/人工操作	是	`draft`	必须为合法状态值	`draft/pending/active/disabled`	随流程变化	不脱敏，部分角色只读	需对齐 AX02
ownerMobile	负责人手机号	string	人工输入	否	空	11 位手机号	`138****1234`	仅在负责人类型=内部员工时展示	默认脱敏，管理员可查看明文	待确认
effectiveTime	生效时间	datetime	人工选择	否	立即生效	不得早于当前时间	`2026-07-16 18:00`	当生效方式=定时生效时必填	不脱敏，可编辑至生效前	P1


最小要求：
- 关键字段要说明来源，是人工录入、系统计算还是外部同步
- 枚举字段必须列值域
- 与权限、状态、导入模板强耦合的字段要写备注引用

Field Name	Meaning	Type	Source	Required	Default Value	Validation Rule	Enumeration/Example	Visibility/Linkage Rule	Desensitization/Editing Rule	Remarks
tenantId	Tenant ID	string	System injected	Yes	Current logged-in tenant	Cannot be empty	`t_1001`	Read-only after creation	No desensitization, cannot edit	P0
status	State	enum	System calculated/manual operation	Yes	`draft`	Must be a valid state value	`draft/pending/active/disabled`	Changes with process	No desensitization, read-only for some roles	Need to align with AX02
ownerMobile	Owner Mobile Number	string	Manual input	No	Empty	11-digit mobile number	`138****1234`	Only displayed when owner type = internal employee	Default desensitized, administrator can view plaintext	To be confirmed
effectiveTime	Activation Time	datetime	Manual selection	No	Immediate activation	Cannot be earlier than current time	`2026-07-16 18:00`	Required when activation method = scheduled activation	No desensitization, editable before activation	P1


Minimum requirements:
- Key fields must explain the source: manual input, system calculation, or external synchronization
- Enumeration fields must list value ranges
- Fields strongly coupled with permissions, states, import templates must have remarks referencing

AX04 异常与审计矩阵模板

AX04 Exception and Audit Matrix Template

适用时机：

高风险操作、人工处置、合规留痕
失败后需要补救、通知或可重试
用户提示和系统日志不能混写

markdown

undefined

Applicable occasions:

High-risk operations, manual disposal, compliance trails
Remediation, notification, or retry is needed after failure
User prompts and system logs cannot be mixed

markdown

undefined

AX04 异常与审计矩阵

AX04 Exception and Audit Matrix

异常/风险场景	用户可见提示	系统记录	审计日志	补救动作	通知对象	可重试	备注
导入文件格式错误	提示模板错误并给下载入口	记录任务失败原因	记录导入人、文件名、失败原因	允许重新上传	导入发起人	是	P0
批量停用部分失败	提示“3 条成功，2 条失败”并可下载明细	保存成功/失败明细	记录每条对象的停用结果	支持按失败明细重试	操作人/管理员	是	当前假设
审核通过后回调下游失败	提示“审核成功，下游同步失败，系统稍后重试”	记录回调响应码	记录审核人与回调失败上下文	系统自动重试，超限后人工介入	运维/业务负责人	是	需结合平台策略
超级管理员删除高风险配置	弹确认框并要求填写原因	记录删除请求	记录操作前后值、原因、审批链路	不支持直接恢复，需走回滚流程	安全管理员	否	待确认


最小要求：
- 区分用户提示、系统记录、审计留痕三层
- 高风险动作必须说明是否可重试、是否可恢复
- 涉及通知时必须写通知对象，不得只写“通知相关人员”

Exception/Risk Scenario	User-visible Prompt	System Record	Audit Log	Remedial Action	Notification Recipient	Retryable	Remarks
Import File Format Error	Prompt template error and provide download entry	Record task failure reason	Record importer, file name, failure reason	Allow re-upload	Import initiator	Yes	P0
Partial Failure in Batch Disable	Prompt "3 succeeded, 2 failed" and allow downloading details	Save success/failure details	Record disable result of each object	Support retry by failure details	Operator/Administrator	Yes	Current assumption
Callback to Downstream Failed After Approval	Prompt "Approval succeeded, downstream synchronization failed, system will retry later"	Record callback response code	Record reviewer and callback failure context	System automatically retries, manual intervention after exceeding limit	Operation/Business Leader	Yes	Need to align with platform strategy
Super Administrator Deletes High-risk Configuration	Pop up confirmation box and require reason input	Record deletion request	Record before/after values, reason, approval link	Direct recovery not supported, need to go through rollback process	Security Administrator	No	To be confirmed


Minimum requirements:
- Distinguish between user prompts, system records, and audit trails
- High-risk operations must specify whether retryable or recoverable
- When notification is involved, must specify notification recipient, not just "notify relevant personnel"

AX05 批量 / 导入导出 / 异步任务规范模板

AX05 Batch / Import/Export / Asynchronous Task Specification Template

适用时机：

文件导入、批量变更、大表导出
任务执行超过前端同步等待时间
存在部分成功、失败明细、结果回执

markdown

undefined

Applicable occasions:

File import, batch changes, large table export
Task execution exceeds frontend synchronous waiting time
Partial success, failure details, result receipt exist

markdown

undefined

AX05 批量 / 导入导出 / 异步任务规范

AX05 Batch / Import/Export / Asynchronous Task Specification

场景	触发方式	规模限制	预校验	执行方式	部分成功策略	失败明细	进度反馈	结果回执	幂等/重试	权限要求	备注
批量导入账号	上传 Excel	单次 5000 行	模板校验、必填校验、唯一性预检	异步任务	成功与失败分开统计	支持下载失败行	任务中心 + 站内消息	导入结果文件保留 7 天	文件指纹去重，允许手动重试	账号管理-导入	P0
批量停用商品	列表勾选 + 批量操作	单次 200 条	校验状态是否可停用	同步 + 后台补偿	显示成功/失败数量	表格弹层展示失败原因	前端即时反馈	操作完成 toast + 审计记录	失败项可二次重试	商品运营-停用	当前假设
导出对账单	筛选后点导出	单租户 10 万条	权限校验、导出字段校验	异步任务	不适用	失败时给失败原因	任务中心	下载链接 24 小时有效	同条件 10 分钟内复用同一任务	对账单-导出	待确认


最小要求：
- 写明同步还是异步
- 写明失败明细承载方式
- 大于前端即时处理能力的任务，必须给进度反馈和结果回执

Scenario	Trigger Method	Scale Limit	Pre-validation	Execution Method	Partial Success Strategy	Failure Details	Progress Feedback	Result Receipt	Idempotency/Retry	Permission Requirement	Remarks
Batch Import Accounts	Upload Excel	5000 rows per time	Template validation, required validation, uniqueness pre-check	Asynchronous task	Separate statistics for success and failure	Support downloading failed rows	Task Center + In-site Message	Import result file retained for 7 days	File fingerprint deduplication, manual retry allowed	Account Management - Import	P0
Batch Disable Products	List selection + batch operation	200 items per time	Validate whether state can be disabled	Synchronous + backend compensation	Display success/failure count	Table pop-up shows failure reason	Frontend immediate feedback	Operation completion toast + audit record	Failed items can be retried a second time	Product Operation - Disable	Current assumption
Export Reconciliation Sheet	Click export after filtering	100,000 items per tenant	Permission validation, export field validation	Asynchronous task	Not applicable	Provide failure reason when failed	Task Center	Download link valid for 24 hours	Reuse same task within 10 minutes for same conditions	Reconciliation Sheet - Export	To be confirmed


Minimum requirements:
- Specify synchronous or asynchronous
- Specify failure detail carrier method
- Tasks exceeding frontend immediate processing capability must provide progress feedback and result receipt

AX06 存量系统改造与发布策略模板

AX06 Legacy System Transformation and Release Strategy Template

适用时机：

旧系统升级、新旧规则并存
涉及历史数据迁移、权限迁移、切流或灰度
需要回滚、培训、运营切换

markdown

undefined

Applicable occasions:

Old system upgrade, coexistence of old and new rules
Involves historical data migration, permission migration, traffic switching, or grayscale
Requires rollback, training, operation switch

markdown

undefined

AX06 存量系统改造与发布策略

AX06 Legacy System Transformation and Release Strategy

主题	现状 As-Is	目标 To-Be	改造策略	风险	灰度/切换方式	回滚方案	负责人/协同方	备注
数据迁移	老表字段缺少租户维度	新模型按租户隔离	脚本补齐租户字段后分批迁移	脏数据导致迁移失败	先灰度 10% 租户	保留老表读能力 7 天	后端/DBA	P0
权限迁移	老系统仅角色权限	新系统含数据权限和字段脱敏	先映射角色，再补数据范围	角色映射错误导致越权	仅对试点租户开启	一键回切旧权限配置	后端/安全/产品	当前假设
功能切换	老后台仍可编辑	新后台接管编辑能力	先只读旧后台，再切新后台写入	双写不一致	分租户切流	关闭新入口，恢复旧入口	前端/后端/运营	待确认
培训与运营	线下口口相传	提供操作手册与公告	上线前培训 + 上线后答疑群	一线使用不熟导致误操作	试点团队先培训	延长双系统并行期	运营/客服/培训	P1


最小要求：
- 至少覆盖数据迁移、权限迁移、切换方式、回滚方案 4 类
- 若无存量系统，明确写 `不适用`
- 灰度与回滚不能只写“支持”，必须写范围和动作

Topic	Current As-Is	Target To-Be	Transformation Strategy	Risk	Grayscale/Switch Method	Rollback Plan	Owner/Collaborator	Remarks
Data Migration	Old table lacks tenant dimension	New model isolates by tenant	Script supplements tenant fields then migrates in batches	Dirty data causes migration failure	Grayscale 10% tenants first	Retain old table read capability for 7 days	Backend/DBA	P0
Permission Migration	Old system only has role permissions	New system includes data permissions and field desensitization	First map roles, then supplement data scope	Role mapping error causes unauthorized access	Only enable for pilot tenants	One-click rollback to old permission configuration	Backend/Security/Product	Current assumption
Function Switch	Old back-office still editable	New back-office takes over editing capability	First set old back-office to read-only, then switch to new back-office writing	Double-write inconsistency	Switch by tenant	Close new entry, restore old entry	Frontend/Backend/Operation	To be confirmed
Training and Operation	Offline word-of-mouth	Provide operation manual and announcement	Training before launch + Q&A group after launch	Frontline unfamiliarity causes misoperation	Train pilot team first	Extend dual-system parallel period	Operation/Customer Service/Training	P1


Minimum requirements:
- At least cover 4 categories: data migration, permission migration, switch method, rollback plan
- If no legacy system, explicitly write `Not applicable`
- Grayscale and rollback cannot only write "supported", must specify scope and actions

后台覆盖矩阵模板

Back-office Coverage Matrix Template

当需求复杂且输出不止一页时，除“场景 -> 功能 -> 规则 -> 页面 -> 提示词”外，建议补一张后台增强覆盖矩阵，确保关键治理结构没有游离在页面之外。

markdown

undefined

When requirements are complex and output has more than one page, in addition to "Scenario -> Function -> Rule -> Page -> Prompt", it is recommended to supplement a back-office enhanced coverage matrix to ensure key governance structures are not separated from pages.

markdown

undefined

后台增强覆盖矩阵

Back-office Enhanced Coverage Matrix

场景 ID	功能 ID	规则 ID	页面 ID	提示词 ID	后台增强产物 ID	说明
S01	F01	R01/R03	P01/P02	PR01/PR02	AX01/AX03	列表与编辑页受权限矩阵和字段字典约束
S02	F02	R04/R05	P03	PR03	AX02/AX04	审批流页面受状态流转和异常矩阵约束
S03	F03	R06	P04	PR04	AX05	导入任务页依赖批量任务规范


使用要求：
- 每个 P0 场景至少映射到一个后台增强产物或明确标记 `不需要`
- 若页面提示词受 AX 产物约束，矩阵中必须能追溯到对应 AX ID

Scenario ID	Function ID	Rule ID	Page ID	Prompt ID	Back-office Enhanced Deliverable ID	Explanation
S01	F01	R01/R03	P01/P02	PR01/PR02	AX01/AX03	List and edit pages are constrained by permission matrix and field dictionary
S02	F02	R04/R05	P03	PR03	AX02/AX04	Approval workflow pages are constrained by state transition and exception matrix
S03	F03	R06	P04	PR04	AX05	Import task page relies on batch task specification


Usage requirements:
- Each P0 scenario maps to at least one back-office enhanced deliverable or is explicitly marked as `Not needed`
- If page prompts are constrained by AX deliverables, the corresponding AX ID must be traceable in the matrix

生成产品方案

Generate Product Solution

生成页面清单前，先输出紧凑的方案章节：

产品定位：一句话说明
MVP 目标：首个可用版本必须满足什么
用户角色：角色、岗位、租户/组织关系及权限差异
业务价值：核心痛点、当前替代方式、为什么现在做、P0 理由
核心流程：从入口到完成的编号流程，优先体现后台操作链路与责任交接
功能模块：按功能 ID 分组的能力
后台工作面：列表、详情、编辑、配置、审批、批量、导入导出、审计等工作面如何分配
数据对象：带数据 ID 的重要实体、关键字段、唯一性、归属和来源
业务规则：带规则 ID 的约束、校验、权限、数据权限和状态流转
行业 playbook 判断：若命中
```
PB01 ~ PB04
```
，显式写明
```
当前命中 PB0X
```
、主 playbook、补充 playbook，以及该方案受哪些行业约束
方案取舍：说明关键结构性决策及其推荐理由
多租户 / 版本 / 开通模型：若相关，说明能力如何按租户、版本或配置生效
主数据与系统边界：若相关，说明事实源、同步方向和冲突处理
后台增强产物：根据命中场景补充权限矩阵、状态流转表、字段字典、异常与审计矩阵、批量规范或迁移策略
成功指标：优先写成效率、准确率、SLA、异常率、处理时长、操作成本等后台指标
风险、假设、非目标和开放问题：只保留影响产品决策的内容

业务规则必须具体到足以指导设计和实现。复杂产品中，要按权限、数据权限、校验、生命周期/状态、数据可见性、审计/历史、通知、SLA、失败恢复、冲突/幂等、指标/数据口径分类。

Before generating page inventory, output a concise solution chapter:

Product Positioning: One-sentence explanation
MVP Objective: What the first usable version must satisfy
User Roles: Roles, positions, tenant/organization relationships, and permission differences
Business Value: Core pain points, current alternative methods, why do it now, P0 reasons
Core Flow: Numbered flow from entry to completion, prioritize reflecting back-office operation links and responsibility handoffs
Function Modules: Capabilities grouped by function ID
Back-office Work Surfaces: How to allocate work surfaces such as lists, details, editing, configuration, approval, batch, import/export, audit
Data Objects: Important entities with data IDs, key fields, uniqueness, ownership, and sources
Business Rules: Constraints, validation, permissions, data permissions, and state transitions with rule IDs
Industry Playbook Judgment: If hitting
```
PB01 ~ PB04
```
, explicitly state
```
Current hit PB0X
```
, main playbook, supplementary playbook, and which industry constraints the solution is subject to
Solution Trade-offs: Explain key structural decisions and their recommended reasons
Multi-tenant / Version / Activation Model: If relevant, explain how capabilities take effect by tenant, version, or configuration
Master Data and System Boundary: If relevant, explain source of truth, synchronization direction, and conflict handling
Back-office Enhanced Deliverables: Supplement permission matrix, state transition table, field dictionary, exception and audit matrix, batch specification, or migration strategy according to hit scenarios
Success Metrics: Prioritize writing as back-office metrics such as efficiency, accuracy, SLA, exception rate, processing duration, operation cost
Risks, Assumptions, Non-targets, and Open Questions: Only retain content that affects product decisions

Business rules must be specific enough to guide design and implementation. In complex products, classify by permissions, data permissions, validation, lifecycle/state, data visibility, audit/history, notification, SLA, failure recovery, conflict/idempotency, indicator/data caliber.

生成产品 PRD

Generate Product PRD

当用户要求正式 PRD、需求文档、产品文档、评审材料或在线协作文档时，基于已确认内容生成产品 PRD。正文结构见

references/product-prd-template.md

。

生成规则：

PRD 正文包含：文档信息、背景与目标、用户与场景、核心功能需求、业务规则、异常流程、页面清单、依赖与风险、验收标准、待确认项/下一步。
当需求命中后台增强场景时，PRD 正文或其附录应明确引用对应后台增强产物；至少要说明这些产物是否已确认、以何种形式交付。
当需求命中
```
PB01 ~ PB04
```
时，PRD 正文或其附录还应明确引用相应 playbook 的关键约束或场景表，例如 SLA 责任、金额口径、组织继承边界、配置覆盖顺序；不能只写通用功能描述。
PRD 正文不得包含：页面级提示词、HiUI 交接包、机器计划、生成 gate 细节。
若仍存在高影响
```
remainingDebt
```
，PRD 只能标记为“草稿 / 待确认版本 / 评审稿”，不得写成已确认定稿。
背景首句优先回答“为什么现在做”；目标优先写成“当前值 -> 目标值 -> 时间范围”；非目标必须显式列出。
功能描述优先使用“触发条件 -> 处理逻辑 -> 输出结果”；验收标准尽量写成可判断通过/不通过的表述。
当文字和表格不足以清晰表达产品结构时，应补图而不是继续堆字；图示类型与一致性检查按
```
references/product-prd-template.md
```
、
```
references/delivery-modes.md
```
执行。

输出渠道规则：先按

references/product-prd-template.md

执行

hasFeishuDocCapability

、

onFeishuWriteFailure = fallbackToMarkdown

和

messageReturnFormat = title + link_or_path + short_summary

。

若当前交付模式包含
```
product-prd
```
，且宿主环境存在协作文档创建能力（例如飞书），优先生成在线协作文档，并返回文档标题与链接；若协作文档写入失败，再 fallback 到 Markdown 文件并返回路径。只在消息中内联 PRD 正文而不产出文档，不算完成。
若用户同时明确需要 PRD 与下游生成输入，或当前交付模式已经确认是
```
full-prd-to-generation
```
，同时产出 PRD 与生成包；否则保持所选最小交付模式，不自行扩写。二者必须分开展示或分开存放，不得混成单一正文。

When the user requests formal PRD, requirement documents, product documents, review materials, or online collaborative documents, generate product PRD based on confirmed content. Body structure can be found in

references/product-prd-template.md

Generation rules:

PRD body includes: document information, background and objectives, users and scenarios, core functional requirements, business rules, exception flows, page inventory, dependencies and risks, acceptance criteria, to-be-confirmed items/next steps.
When requirements hit back-office enhanced scenarios, PRD body or its appendix should explicitly reference corresponding back-office enhanced deliverables; at least explain whether these deliverables are confirmed and in what form they are delivered.
When requirements hit
```
PB01 ~ PB04
```
, PRD body or its appendix should also explicitly reference key constraints or scenario tables of the corresponding playbook, such as SLA responsibility, amount caliber, organization inheritance boundary, configuration override order; cannot only write general function descriptions.
PRD body must not include: page-level prompts, HiUI handoff packages, machine plans, generation gate details.
If high-impact
```
remainingDebt
```
still exists, PRD can only be marked as "Draft / To-be-confirmed Version / Review Draft", cannot be written as confirmed final version.
The first sentence of background prioritizes answering "why do it now"; objectives are prioritized to be written as "current value -> target value -> time range"; non-targets must be explicitly listed.
Function descriptions prioritize using "trigger condition -> processing logic -> output result"; acceptance criteria are written as much as possible as statements that can judge pass/fail.
When text and tables are not sufficient to clearly express product structure, supplement diagrams instead of continuing to pile up words; diagram types and consistency checks are executed according to
```
references/product-prd-template.md
```
and
```
references/delivery-modes.md
```
.

Output channel rules: First execute

hasFeishuDocCapability

onFeishuWriteFailure = fallbackToMarkdown

, and

messageReturnFormat = title + link_or_path + short_summary

according to

references/product-prd-template.md

If current delivery mode includes
```
product-prd
```
and the host environment has collaborative document creation capabilities (e.g., Feishu), prioritize generating an online collaborative document and return the document title and link; if collaborative document writing fails, fallback to Markdown file and return path. Only inline PRD body in messages without producing documents is not considered completed.
If the user explicitly needs both PRD and downstream generation inputs, or current delivery mode is confirmed as
```
full-prd-to-generation
```
, produce both PRD and generation pack at the same time; otherwise, maintain the selected minimal delivery mode, do not expand automatically. The two must be displayed or stored separately, cannot be mixed into a single body.

就绪检查

Readiness Check

以下内容已确认或明确假设后，再进入页面清单和提示词：

P0 用户场景已列出。
主要角色和权限差异已明确。
已说明业务价值、P0 理由和推荐方案依据，而不是只有功能罗列。
核心对象和生命周期状态已定义。
关键业务规则和异常已捕获。
命中的后台增强产物已经产出或显式标为待确认。
若命中 B2B/SaaS/平台化场景，多租户、版本差异、功能开通和主数据边界已明确，或显式标记为待确认。
入口和完成结果已明确。
用户已选择或接受目标平台和输出格式。

如果就绪度较弱但用户要求输出，继续产出，但必须标记假设和风险。若输出会被下游用于页面生成，不得把弱就绪伪装成已确认；必须让用户确认生成输入或明确授权假设。

如果仍有高影响

remainingDebt

，不得把结果标为

confirmed

；只能继续确认、标为假设，或等待用户明确授权假设。

Proceed to page inventory and prompts only after the following content is confirmed or explicitly assumed:

P0 user scenarios are listed.
Main roles and permission differences are clear.
Business value, P0 reasons, and recommended solution basis are explained, not just function lists.
Core objects and lifecycle states are defined.
Key business rules and exceptions are captured.
Hit back-office enhanced deliverables are produced or explicitly marked as to-be-confirmed.
If hitting B2B/SaaS/platformization scenarios, multi-tenant, version differences, feature activation, and master data boundaries are clear, or explicitly marked as to-be-confirmed.
Entry and completion results are clear.
User has selected or accepted target platform and output format.

If readiness is weak but user requests output, continue to produce, but must mark assumptions and risks. If output will be used downstream for page generation, do not pretend weak readiness as confirmed; must let user confirm generation inputs or explicitly authorize assumptions.

If high-impact

remainingDebt

still exists, do not mark the result as

confirmed

; can only continue confirmation, mark as assumption, or wait for user explicit authorization of assumptions.

生成页面清单

Generate Page Inventory

创建覆盖所有 P0 流程的页面清单。每行必须包含：

页面 ID
页面名称
工作面类型：page、modal、drawer、step flow、tab、detail panel、configuration panel 或 embedded work surface
路由或位置，若相关
关联的场景 ID、功能 ID、规则 ID 和提示词 ID
用户目标
入口和出口
核心模块
关键字段/列/筛选/操作摘要，至少说明本页展示什么、编辑什么、按什么筛选、可执行哪些关键动作
主要操作
需设计的状态：默认、空、加载、错误、权限受限、成功，以及相关边界情况
依赖或所需数据
关联后台增强产物 ID，若相关
MVP 优先级：P0、P1、P2

当目标平台是 HiUI 或管理后台/B2B 时，给出 HiUI 页型建议：

table-basic

、

table-stat

、

tree-table

、

tree-split

、

drawer-form

、

drawer-detail

、

full-page-edit

、

full-page-detail

、

data-visualization

、

feedback

、

non-typical

或

unresolved

需要严格表格结构时，使用

references/output-templates.md

。

不要机械拆页。独立导航目的地、持久 URL、职责边界或长流程使用新页面；本地任务、确认、快速编辑、渐进披露或紧密耦合的子流程使用 modal、drawer、detail panel、tab 或 step flow。

Create a page inventory covering all P0 flows. Each row must include:

Page ID
Page Name
Work Surface Type: page, modal, drawer, step flow, tab, detail panel, configuration panel, or embedded work surface
Route or Location, if relevant
Associated Scenario ID, Function ID, Rule ID, and Prompt ID
User Objective
Entry and Exit
Core Modules
Summary of Key Fields/Columns/Filters/Actions: at least explain what this page displays, edits, filters by, and what key actions can be performed
Main Operations
States to Design: default, empty, loading, error, permission restricted, success, and related boundary situations
Dependencies or Required Data
Associated Back-office Enhanced Deliverable ID, if relevant
MVP Priority: P0, P1, P2

When target platform is HiUI or management back-office/B2B, give HiUI page type recommendation:

table-basic

table-stat

tree-table

tree-split

drawer-form

drawer-detail

full-page-edit

full-page-detail

data-visualization

feedback

non-typical

, or

unresolved

When strict table structure is needed, use

references/output-templates.md

Do not split pages mechanically. Use new pages for independent navigation destinations, persistent URLs, responsibility boundaries, or long flows; use modal, drawer, detail panel, tab, or step flow for local tasks, confirmation, quick editing, progressive disclosure, or tightly coupled sub-flows.

生成全局上下文

Generate Global Context

页面级提示词前，先写一个所有页面继承的全局上下文：

产品名称、定位和平台
目标用户和角色/权限模型
导航模型和页面层级
核心数据对象和命名约定
共享业务规则和状态定义
共享 UI / 组件约束或设计系统
共享状态、反馈模式和文案语气
已知假设和不在范围内的内容

这样可以防止独立生成的页面在术语、字段、导航、权限和视觉系统上漂移。

Before page-level prompts, write a global context inherited by all pages:

Product name, positioning, and platform
Target users and role/permission model
Navigation model and page hierarchy
Core data objects and naming conventions
Shared business rules and state definitions
Shared UI / component constraints or design system
Shared state, feedback mode, and copy tone
Known assumptions and out-of-scope content

This prevents independently generated pages from drifting in terminology, fields, navigation, permissions, and visual systems.

生成页面级提示词

Generate Page-level Prompts

对清单中的每个页面，写一个可供其他 AI 生成页面设计、原型或实现的提示词。每个提示词需要能独立使用，同时引用全局上下文。

每个页面提示词必须包含：

提示词 ID、页面 ID、页面名称，以及关联场景/功能/规则 ID
页面目的和目标用户
用户目标和本页完成标准
布局结构和信息层级
模块级结构拆解，不能只写抽象模块名；每个模块要说明位置、职责和承载的信息
每个模块的字段/列/筛选项/操作明细：名称、含义、组件或展示方式、是否必填/只读、来源或口径、默认值/空值、校验/显隐/联动条件
列表型页面还需给出筛选区、指标区、表格列、排序/分页、行操作、批量操作；表单型页面还需给出字段分组、控件类型、保存策略、提交反馈；详情型页面还需给出信息分区、状态标签、时间线/记录块与跳转关系
有帮助时给出可被下游 agent 直接消费的示例数据结构或字段示例
主要操作和次要操作
交互规则、校验规则、权限规则和状态变化
若命中
```
PB01 ~ PB04
```
，必须在提示词中显式带入对应 playbook 的页内约束，例如 SLA 节点责任、金额口径与单据关系、组织继承与授权边界、配置生效与覆盖顺序；不得只在全局上下文轻描淡写
若页面受权限矩阵、状态流转表、字段字典、批量规范或异常矩阵约束，必须明确引用其关键约束，而不是在页面提示词中重新脑补
默认、空、加载、错误、权限、成功和相关边界状态
跨页面导航和交接行为
已知视觉或组件系统约束
验收标准

避免“做得好看”“现代化看板”这类空泛提示，除非用户明确要求风格探索。用具体布局、内容、行为、状态和验收要求替代。

当这些提示词将被用于下游生成确认时，必须交付完整正文，而不是摘要版。若内容过长，可写入独立产物文件；但确认前必须给出完整文件路径，并确保用户可以直接查看全文。

若页面提示词中仍有 3 个以上会改变布局、字段、校验或操作的重要空白，或主要内容仍只是抽象模块名而没有字段/列/筛选/动作明细，必须回退到继续确认或标记为待确认版本，不得作为可直接生成的提示词包输出。

For each page in the inventory, write a prompt that can be used by other AI to generate page designs, prototypes, or implementations. Each prompt needs to be usable independently while referencing the global context.

Each page prompt must include:

Prompt ID, Page ID, Page Name, and associated scenario/function/rule ID
Page purpose and target users
User objective and completion standard for this page
Layout structure and information hierarchy
Module-level structure breakdown, cannot only write abstract module names; each module must explain position, responsibility, and carried information
Details of fields/columns/filters/actions for each module: name, meaning, component or display method, required/read-only status, source or caliber, default value/empty value, validation/visibility/linkage conditions
List-type pages must also provide filter area, indicator area, table columns, sorting/pagination, row operations, batch operations; form-type pages must also provide field grouping, control types, saving strategy, submission feedback; detail-type pages must also provide information partitions, status tags, timeline/record blocks, and jump relationships
Provide sample data structures or field examples that can be directly consumed by downstream agents when helpful
Main operations and secondary operations
Interaction rules, validation rules, permission rules, and state changes
If hitting
```
PB01 ~ PB04
```
, must explicitly bring in in-page constraints of the corresponding playbook in the prompt, such as SLA node responsibility, amount caliber and document relationship, organization inheritance and authorization boundary, configuration activation and override order; cannot only mention lightly in global context
If page is constrained by permission matrix, state transition table, field dictionary, batch specification, or exception matrix, must explicitly reference its key constraints, rather than reimagining in page prompts
Default, empty, loading, error, permission, success, and related boundary states
Cross-page navigation and handoff behaviors
Known visual or component system constraints
Acceptance criteria

Avoid vague prompts like "make it beautiful" "modern dashboard" unless the user explicitly requests style exploration. Replace with specific layout, content, behavior, state, and acceptance requirements.

When these prompts will be used for downstream generation confirmation, must deliver complete text, not summary versions. If content is too long, can be written into independent deliverable files; but before confirmation, must provide complete file path and ensure users can directly view the full text.

If there are more than 3 important gaps in page prompts that will change layout, fields, validation, or operations, or main content is still only abstract module names without field/column/filter/action details, must return to continue confirmation or mark as to-be-confirmed version, cannot output as prompts directly usable for generation.

生成 HiUI 交接包

Generate HiUI Handoff Package

当用户需要 HiUI 页面生成、页面验收，或交接给下游 HiUI 页面工作流（例如

hiui-page-workflow

）时，在页面清单和提示词后增加一个紧凑的交接包。模板见

references/hiui-handoff-template.md

。

交接包必须包含：

产品名称、目标平台和建议 workflow level
页面列表：页面 ID、页面名称、路由/位置、HiUI 页型、优先级、关联场景/规则/提示词 ID，以及需设计状态
共享全局上下文引用和组件/设计系统约束
关联后台增强产物及其状态：哪些已确认、哪些待确认、哪些仅按假设推进
会影响生成或验收的数据/mock 假设、权限假设和开放风险
推荐生成顺序，通常先生成 P0 列表/详情/编辑/核心流程页面
```
requirementGate
```
与
```
generationInputGate
```
的状态；若仍有缺口，必须标为
```
assumption-authorized
```
或
```
blocked
```
，不能写成已确认。

When users need HiUI page generation, page acceptance, or handoff to downstream HiUI page workflows (e.g.,

hiui-page-workflow

), add a concise handoff package after page inventory and prompts. Template can be found in

references/hiui-handoff-template.md

Handoff package must include:

Product name, target platform, and recommended workflow level
Page List: Page ID, Page Name, Route/Location, HiUI Page Type, Priority, Associated Scenario/Rule/Prompt ID, and states to design
Reference to shared global context and component/design system constraints
Associated back-office enhanced deliverables and their status: which are confirmed, which are to-be-confirmed, which are only advanced according to assumptions
Data/mock assumptions, permission assumptions, and open risks that will affect generation or acceptance
Recommended generation order, usually generate P0 list/detail/edit/core flow pages first
Status of
```
requirementGate
```
and
```
generationInputGate
```
; if gaps still exist, must mark as
```
assumption-authorized
```
or
```
blocked
```
, cannot write as confirmed.

交互模式

Interaction Mode

用户希望继续细化时

When User Wants to Continue Refinement

使用循环：

总结当前版本和变化。
更新
```
questionDebt
```
，识别 1-3 个最高影响问题组。
提出覆盖主要决策分支的选项式确认问题，或给出推荐假设。
根据用户答案更新范围、流程、追踪关系、页面和提示词。
输出轻量确认进度，并决定继续确认、输出交付物、等待授权假设或调整范围。

这里的“根据用户答案更新”不是泛化表述；必须显式体现上一轮答案如何清除

questionDebt

、触发 playbook / AX / BX 产物，或改变下一轮问题方向。

继续细化时，默认按“统一主流程”的阶段顺序推进：

场景命中与交付边界
价值 / 目标 / 角色 / P0
对象 / 字段 / 规则 / 状态
治理结构与专家判断
页面 / 工作面 / 交互 / 验收
生成输入确认或交付输出

补充规则：

若当前只是输出方案、PRD 或页面清单，而不是进入页面生成，下游可在阶段 5 或阶段 6 的非生成出口结束，不必强行进入
```
generationInputGate
```
。
若命中后台增强场景，阶段 4 自动成为必经阶段，而不是“有空再补一张矩阵”。
若命中
```
PB01 ~ PB04
```
，对应 playbook 的必问问题与结构化产物应优先进入阶段 3-4，不得等到页面阶段再补。

Use the cycle:

Summarize current version and changes.
Update
```
questionDebt
```
, identify 1-3 highest-impact question groups.
Propose option-based confirmation questions covering main decision branches, or give recommended assumptions.
Update scope, flow, traceability relationships, pages, and prompts based on user answers.
Output lightweight confirmation progress, and decide to continue confirmation, output deliverables, wait for assumption authorization, or adjust scope.

The "update based on user answers" here is not a generalized statement; must explicitly reflect how the previous round's answer clears

questionDebt

, triggers playbook / AX / BX deliverables, or changes the next round's question direction.

When continuing refinement, default to advancing according to the phase order of the "unified main flow":

Scenario Matching and Delivery Boundary
Value / Objective / Role / P0
Object / Field / Rule / State
Governance Structure and Expert Judgment
Page / Work Surface / Interaction / Acceptance
Generation Input Confirmation or Delivery Output

Supplementary rules:

If currently only outputting solutions, PRDs, or page inventories rather than entering page generation, downstream can end at non-generation exits of phase 5 or 6, do not force entry into
```
generationInputGate
```
.
If hitting back-office enhanced scenarios, phase 4 automatically becomes a necessary phase, not "fill a matrix when free".
If hitting
```
PB01 ~ PB04
```
, mandatory questions and structured deliverables of the corresponding playbook should be prioritized in phases 3-4, do not wait until page phase to supplement.

用户希望立即输出时

When User Wants to Output Immediately

在假设基础上产出第一版完整结果。清晰标记假设，并包含“下一轮建议确认”。若用户要的是 PRD 或评审稿，保持正式文档口吻，但显式区分“已确认”“当前假设”“待确认项”。若该结果下一步会进入页面生成、HiUI 生成、原型生成或 UX 验收，需要先区分

评审草稿

与

生成稿

：前者可用于讨论方向，但不得进入生成输入确认；后者只有在关键页面已通过字段/列/筛选/操作级粒度校验后才允许进入生成输入确认。若当前仍存在会改变对象模型、字段、权限、状态、交互或关键规则的高影响

remainingDebt

，只能输出“第一版方案 + 待确认点 + 推荐下一轮问题”，不得把这些内容写成已收敛的定稿。

Produce the first complete version based on assumptions. Clearly mark assumptions, and include "recommended next round confirmation". If the user wants PRD or review draft, maintain formal document tone, but explicitly distinguish "confirmed", "current assumption", "to-be-confirmed items". If the next step of this result is page generation, HiUI generation, prototype generation, or UX acceptance, need to distinguish between

review draft

and

generation draft

: the former can be used for direction discussion, but cannot enter generation input confirmation; the latter can only enter generation input confirmation after key pages pass field/column/filter/operation-level granularity verification. If high-impact

remainingDebt

that will change object model, fields, permissions, states, interactions, or key rules still exists, can only output "first version solution + to-be-confirmed points + recommended next round questions", cannot write these contents as converged final version.

用户已有 PRD、笔记或外部材料时

When User Already Has PRD, Notes, or External Materials

读取材料，提取已有决策，识别缺口，避免重复询问材料里已经存在的信息。然后按工作流输出规范化结果。

Read materials, extract existing decisions, identify gaps, avoid repeating questions already existing in materials. Then output standardized results according to workflow.

产物策略

Deliverable Strategy

短输出直接在对话中回答。长提示词包、完整 PRD 或 HiUI 交接包，如果用户要求可复用文件，则建议或创建单独产物。产物分层：

```
product-prd
```
：仅允许产品层章节；有协作文档能力时必须落在线协作文档并返回链接，无协作文档能力时必须落为独立 Markdown 文档并返回绝对路径。
```
generation-review-pack
```
：仅用于用户确认，必须包含页面清单、完整页面级提示词；若当前交付模式包含
```
product-prd
```
，再额外包含
```
product-prd
```
的链接或路径证据；不得只保留摘要。
```
backend-ops-pack
```
：仅在命中后台增强场景时产出，允许包含权限矩阵、状态流转表、字段字典、异常与审计矩阵、批量规范、迁移发布策略；可独立文件，也可作为 generation-pack 的附属 section。
```
generation-pack
```
：仅允许全局上下文、页面清单、页面级提示词和 HiUI 交接包；若命中后台增强场景，可附带或引用
```
backend-ops-pack
```
。
```
full-prd-to-generation
```
必须拆成
```
product-prd
```
与
```
generation-pack
```
两个独立 section 或文件。人审优先用在线协作文档或 Markdown；只有机器交接或校验需要时才用 JSON。各模式允许出现的章节与禁止项，以
```
references/delivery-modes.md
```
为准。

Short outputs are answered directly in conversations. For long prompt packs, complete PRDs, or HiUI handoff packages, if users request reusable files, suggest or create separate deliverables. Deliverable layering:

```
product-prd
```
: Only allows product-level chapters; must be placed in online collaborative document and return link if collaborative document capability exists, must be placed as independent Markdown document and return absolute path if no collaborative document capability.
```
generation-review-pack
```
: Only used for user confirmation, must include page inventory, complete page-level prompts; if current delivery mode includes
```
product-prd
```
, additionally include link or path evidence of
```
product-prd
```
; cannot only retain summary.
```
backend-ops-pack
```
: Only produced when hitting back-office enhanced scenarios, allows including permission matrix, state transition table, field dictionary, exception and audit matrix, batch specification, migration release strategy; can be independent file, or attached as a section of generation-pack.
```
generation-pack
```
: Only allows global context, page inventory, page-level prompts, and HiUI handoff package; if hitting back-office enhanced scenarios, can attach or reference
```
backend-ops-pack
```
.
```
full-prd-to-generation
```
must be split into two independent sections or files:
```
product-prd
```
and
```
generation-pack
```
. Human review prioritizes online collaborative documents or Markdown; only machine handoff or verification requires JSON. Allowed chapters and prohibited items for each mode are based on
```
references/delivery-modes.md
```
.

质量门禁

Quality Gate

最终输出前检查产品完整性：

产品目标、目标用户、P0 场景、MVP 边界和非目标明确。
成功指标或验收信号已定义。
组织 / 租户 / 部门 / 岗位 / 数据权限边界已明确，或显式标记为待确认。
核心对象、生命周期状态、权限、校验和异常路径已覆盖。
若命中多角色、多状态、批量、导入导出、敏感字段、外部依赖或存量改造场景，对应后台增强产物已产出或显式标记为待确认。
若为 B2B / 管理后台 / 配置治理需求，对象粒度、唯一性/冲突规则、批量导入或批量操作、日志/审计策略、工作面选择至少已确认或显式标为假设。
列表、详情、编辑、配置、审批、批量、导入导出、审计这些后台典型工作面，已明确哪些在 P0、哪些不做。
若存在多个可行方案，已明确推荐方案及不推荐其他方案的原因。
若存在多租户、版本差异、主数据归属、系统边界或客户差异化问题，已输出专家判断而不是把问题留给下游实现猜测。
若需求明显命中工单/审批/SLA、结算/对账/发票、账号/组织/权限、配置中心/发布/回滚之一，已应用对应 playbook，而不是只做通用后台需求细化。
每个 P0 场景至少映射到一个页面、弹窗或工作面。
每个生成的页面、弹窗、抽屉或工作面都能追溯到 P0/P1 场景、功能和提示词，或明确标记为支撑性基础设施。
每个页面都有清晰用户目标、入口、出口、数据依赖和提示词 ID。
用于生成的页面清单至少包含关键字段/列/筛选/操作摘要；页面级提示词至少包含字段清单、列清单或等价的控件明细结构。
CRUD 操作在合理时包含权限、校验、反馈、失败状态和审计/历史。
业务规则在相关时区分权限、校验、生命周期/状态、数据可见性、审计/历史、通知/SLA、失败恢复、冲突/幂等和指标定义。
搜索、筛选、排序、分页、导入导出、批量操作、通知和审计/历史只在有依据时加入。
全局上下文能防止跨页面命名、数据、导航、权限和组件漂移。
页面清单避免过度拆分，也避免把不同职责过度压缩到一个工作面。
页面提示词具体到其他 agent 无需重复询问同一批产品问题。
若页面提示词仍以抽象模块名替代字段、列、筛选项或操作明细，则判定为未完成，不得标记为
```
confirmed
```
。
如果下一步很可能是 HiUI 生成，HiUI 交接包包含路由、HiUI 页型、状态、优先级、提示词 ID、假设和生成顺序。
如果下一步很可能是页面生成，必须包含
```
generationInputGate
```
状态；未确认时只能是
```
ready-for-review
```
、
```
assumption-authorized
```
或
```
blocked
```
，不得默认为
```
confirmed
```
。
如果下一步很可能是页面生成，必须同时具备
```
generationReviewPack
```
：页面清单、完整页面级提示词；若当前交付模式包含 PRD，再额外要求 PRD 在线文档链接或 Markdown 路径。任一必填项缺失都不得标记为可确认生成。
如果下一步很可能是页面生成，且页面受权限矩阵、状态流转、字段字典或批量规则强约束，这些后台增强产物必须已进入
```
generationReviewPack
```
或
```
backend-ops-pack
```
。
如果输出正式 PRD，正文必须包含背景、目标、非目标、功能、规则、异常、页面清单、风险和验收标准；不得混入页面级提示词或 HiUI 交接信息。
如果输出正式 PRD，且需求包含复杂流程、状态流转、跨角色协作或多对象关系，正文还必须包含相应图示，或显式说明当前为何可不补图。
最终输出前必须说明确认完整度；若存在
```
remainingDebt
```
，必须列入待确认或假设，不能隐藏。
开放问题仅保留会改变范围、行为、数据、权限、UI 或交付方式的决策。
若正文中有 3 条以上会改变页面、字段、规则或验收的关键假设，必须回退为“待确认版本”而不是“已收口方案”。
若当前运行在已有仓库中且需求与项目强相关，必须已利用本地高信号上下文，或明确说明为何未利用。

Check product completeness before final output:

Product objectives, target users, P0 scenarios, MVP boundaries, and non-targets are clear.
Success metrics or acceptance signals are defined.
Organization / tenant / department / position / data permission boundaries are clear, or explicitly marked as to-be-confirmed.
Core objects, lifecycle states, permissions, validation, and exception paths are covered.
If hitting multi-role, multi-state, batch, import/export, sensitive fields, external dependencies, or legacy transformation scenarios, corresponding back-office enhanced deliverables are produced or explicitly marked as to-be-confirmed.
If it is B2B / management back-office / configuration governance requirements, object granularity, uniqueness/conflict rules, batch import or batch operations, log/audit strategy, work surface selection are at least confirmed or explicitly marked as assumption.
Typical back-office work surfaces such as lists, details, editing, configuration, approval, batch, import/export, audit are clearly defined which are in P0 and which are not done.
If multiple feasible solutions exist, recommended solution and reasons for not recommending other solutions are clear.
If multi-tenant, version differences, master data ownership, system boundary, or customer differentiation issues exist, expert judgment is output rather than leaving the problem to downstream implementation guesses.
If requirements clearly hit one of ticket/approval/SLA, settlement/reconciliation/invoice, account/organization/permission, configuration center/release/rollback, corresponding playbook is applied, rather than only performing general back-office requirement refinement.
Each P0 scenario maps to at least one page, pop-up, or work surface.
Each generated page, pop-up, drawer, or work surface can be traced to P0/P1 scenario, function, and prompt, or explicitly marked as supporting infrastructure.
Each page has clear user objective, entry, exit, data dependency, and prompt ID.
Page inventory used for generation includes at least summary of key fields/columns/filters/actions; page-level prompts include at least field list, column list, or equivalent control detail structure.
CRUD operations include permissions, validation, feedback, failure states, and audit/history when reasonable.
Business rules distinguish permissions, validation, lifecycle/state, data visibility, audit/history, notification/SLA, failure recovery, conflict/idempotency, and indicator definition when relevant.
Search, filtering, sorting, pagination, import/export, batch operations, notification, and audit/history are only added when there is basis.
Global context prevents cross-page naming, data, navigation, permissions, and component drift.
Page inventory avoids excessive splitting, also avoids over-compressing different responsibilities into one work surface.
Page prompts are specific enough that other agents do not need to repeat the same batch of product questions.
If page prompts still use abstract module names instead of fields, columns, filters, or operation details, it is judged as incomplete, cannot be marked as
```
confirmed
```
.
If next step is likely HiUI generation, HiUI handoff package includes routing, HiUI page type, state, priority, prompt ID, assumptions, and generation order.
If next step is likely page generation, must include
```
generationInputGate
```
status; when unconfirmed, can only be
```
ready-for-review
```
,
```
assumption-authorized
```
, or
```
blocked
```
, cannot default to
```
confirmed
```
.
If next step is likely page generation, must have
```
generationReviewPack
```
at the same time: page inventory, complete page-level prompts; if current delivery mode includes PRD, additionally require PRD online document link or Markdown path. Any missing required item cannot be marked as confirmable for generation.
If next step is likely page generation, and page is strongly constrained by permission matrix, state transition, field dictionary, or batch rules, these back-office enhanced deliverables must have entered
```
generationReviewPack
```
or
```
backend-ops-pack
```
.
If outputting formal PRD, body must include background, objectives, non-targets, functions, rules, exceptions, page inventory, risks, and acceptance criteria; cannot mix page-level prompts or HiUI handoff information.
If outputting formal PRD, and requirements include complex flows, state transitions, cross-role collaboration, or multi-object relationships, body must also include corresponding diagrams, or explicitly explain why no diagrams are needed currently.
Must explain confirmation completeness before final output; if
```
remainingDebt
```
exists, must be included in to-be-confirmed or assumptions, cannot hide.
Open questions only retain decisions that will change scope, behavior, data, permissions, UI, or delivery method.
If there are more than 3 key assumptions in the body that will change pages, fields, rules, or acceptance, must return to "to-be-confirmed version" rather than "converged solution".
If currently running in an existing repository and requirements are strongly related to the project, must have utilized local high-signal context, or explicitly explain why not utilized.

Validation

最终输出前，按以下顺序做一次自检，并在必要时回退到继续确认而不是强行收口：

交付模式校验：确认当前输出与
```
quick-refine
```
、
```
solution-only
```
、
```
product-prd
```
、
```
page-inventory
```
、
```
prompt-pack
```
、
```
hiui-handoff
```
或
```
full-prd-to-generation
```
之一匹配，没有多写无关章节，也没有遗漏该模式要求的核心内容。
确认状态校验：核对
```
confirmationDepth
```
、
```
resolvedDebt
```
、
```
remainingDebt
```
、
```
assumptions
```
是否一致；若仍存在高影响
```
remainingDebt
```
，不得把结果写成
```
confirmed
```
。
项目上下文校验：如果当前处于已有仓库中且需求与项目强相关，确认已完成最小仓库证据预载，并记录
```
repoFindings / repoAssumptions / repoConflicts / repoGaps
```
；若未使用本地上下文，必须说明原因，如“未找到有效证据”“与当前需求无关”或“用户明确要求忽略实现”。
下游门禁校验：如果下一步是页面生成、HiUI 生成、原型生成或 UX 验收，确认输出中包含生成输入确认块，并且
```
requirementGate
```
、
```
generationInputGate
```
状态合法；未获确认时只能写
```
ready-for-review
```
、
```
assumption-authorized
```
或
```
blocked
```
。
专家判断校验：确认已说明业务价值、P0 理由、推荐方案依据；若命中多租户、版本或主数据边界问题，也已给出专家判断。缺失时不得自称专家建议。
Playbook 校验：若需求明显命中
```
PB01 ~ PB04
```
之一，确认对应 playbook 的必问问题、必须产物和反模式检查已被执行；缺失时回退继续确认。
PRD 文稿校验：若输出
```
product-prd
```
或
```
full-prd-to-generation
```
，确认 PRD 正文结构符合
```
references/product-prd-template.md
```
，并且未混入页面级提示词、HiUI 交接包或机器执行细节；同时确认 PRD 已落在线协作文档或 Markdown 文件，并返回链接或路径。
字段粒度校验：若输出包含
```
page-inventory
```
、
```
prompt-pack
```
、
```
hiui-handoff
```
或
```
full-prd-to-generation
```
的 generation-pack，确认关键页面已细化到字段/列/筛选/操作级，而不是只有抽象模块名；若仍有高影响缺口，回退到继续确认或待确认版本。
后台增强产物校验：若命中权限复杂、状态复杂、批量任务、敏感字段、外部依赖或迁移改造场景，确认所需后台增强产物已输出、可追溯、粒度足以约束页面与规则；缺失时回退继续确认。
追踪关系校验：当输出包含页面清单、提示词或 HiUI 交接包时，确认每个 P0 场景至少映射到功能、规则、页面或工作面；每个页面都能追溯到场景、功能、规则、提示词或相关后台增强产物。
产品完整性校验：对照上方“质量门禁”，检查目标、角色、范围、规则、数据、状态、异常、页面、验收与风险是否成套闭环；缺项时补齐或显式标记为假设/待确认。

命中以下任一条件时，必须回退到继续确认、调整范围或标记为待确认版本，不得继续输出为

confirmed

、定稿 PRD 或可直接下游消费的生成包：

```
remainingDebt
```
中仍有
```
2
```
个及以上会改变字段、权限、状态、页面工作面或验收标准的高影响未知项
```
repoConflicts
```
非空，且尚未通过用户确认解决“沿用 / 扩展 / 重做”的冲突
当前无法说明做这件事的业务价值、P0 依据或推荐方案理由，却试图输出“专家建议”
需求明显命中
```
PB01 ~ PB04
```
，但对应的关键问题、产物或反模式检查没有出现
```
product-prd
```
与
```
generation-pack
```
出现内容串写，例如 PRD 正文混入页面提示词、HiUI handoff 或 gate 细节
generation-pack 中的关键页面仍停留在抽象模块名，没有字段/列/筛选/操作级细化
命中后台增强场景，但权限矩阵、状态流转、字段字典、批量规范或迁移策略仍缺失，导致页面或规则无法稳定落地
命中多租户、版本差异、主数据归属或系统边界问题，但仍未回答事实源、开通模型或冲突处理
下一步准备进入页面生成、HiUI 生成、原型生成或 UX 验收，但
```
generationInputGate.status
```
既不是
```
confirmed
```
也不是
```
assumption-authorized
```

Before final output, perform a self-check in the following order, and return to continue confirmation if necessary rather than forcing convergence:

Delivery Mode Validation: Confirm current output matches one of
```
quick-refine
```
,
```
solution-only
```
,
```
product-prd
```
,
```
page-inventory
```
,
```
prompt-pack
```
,
```
hiui-handoff
```
, or
```
full-prd-to-generation
```
, no irrelevant chapters are added, and core content required by the mode is not missing.
Confirmation Status Validation: Check consistency of
```
confirmationDepth
```
,
```
resolvedDebt
```
,
```
remainingDebt
```
,
```
assumptions
```
; if high-impact
```
remainingDebt
```
still exists, cannot write the result as
```
confirmed
```
.
Project Context Validation: If currently in an existing repository and requirements are strongly related to the project, confirm minimal repository evidence preload is completed, and
```
repoFindings / repoAssumptions / repoConflicts / repoGaps
```
are recorded; if local context is not used, must explain reasons such as "no valid evidence found", "irrelevant to current requirements", or "user explicitly requests ignoring implementation".
Downstream Gate Validation: If next step is page generation, HiUI generation, prototype generation, or UX acceptance, confirm output includes generation input confirmation block, and
```
requirementGate
```
,
```
generationInputGate
```
status is legal; when unconfirmed, can only write
```
ready-for-review
```
,
```
assumption-authorized
```
, or
```
blocked
```
.
Expert Judgment Validation: Confirm business value, P0 reasons, recommended solution basis are explained; if hitting multi-tenant, version, or master data boundary issues, expert judgment is also provided. Cannot claim as expert advice if missing.
Playbook Validation: If requirements clearly hit one of
```
PB01 ~ PB04
```
, confirm mandatory questions, mandatory deliverables, and anti-pattern checks of the corresponding playbook have been executed; return to continue confirmation if missing.
PRD Manuscript Validation: If outputting
```
product-prd
```
or
```
full-prd-to-generation
```
, confirm PRD body structure conforms to
```
references/product-prd-template.md
```
, and no page-level prompts, HiUI handoff packages, or machine execution details are mixed in; also confirm PRD has been placed in online collaborative document or Markdown file, and link or path is returned.
Field Granularity Validation: If output includes
```
page-inventory
```
,
```
prompt-pack
```
,
```
hiui-handoff
```
, or generation-pack of
```
full-prd-to-generation
```
, confirm key pages are refined to field/column/filter/operation level, not just abstract module names; if high-impact gaps still exist, return to continue confirmation or to-be-confirmed version.
Back-office Enhanced Deliverable Validation: If hitting complex permissions, complex states, batch tasks, sensitive fields, external dependencies, or migration transformation scenarios, confirm required back-office enhanced deliverables are output, traceable, and granular enough to constrain pages and rules; return to continue confirmation if missing.
Traceability Relationship Validation: When output includes page inventory, prompts, or HiUI handoff package, confirm each P0 scenario maps to at least function, rule, page, or work surface; each page can be traced to scenario, function, rule, prompt, or related back-office enhanced deliverable.
Product Completeness Validation: Check against the above "Quality Gate" to see if objectives, roles, scope, rules, data, states, exceptions, pages, acceptance, and risks form a closed loop; supplement or explicitly mark as assumption/to-be-confirmed if missing.

Must return to continue confirmation, adjust scope, or mark as to-be-confirmed version, cannot continue to output as

confirmed

, final PRD, or generation pack directly consumable by downstream if any of the following conditions are hit:

```
remainingDebt
```
still has
```
2
```
or more high-impact unknowns that will change fields, permissions, states, page work surfaces, or acceptance criteria
```
repoConflicts
```
is not empty, and the conflict of "follow / extend / rebuild" has not been resolved through user confirmation
Currently unable to explain business value, P0 basis, or recommended solution reasons, but tries to output "expert advice"
Requirements clearly hit
```
PB01 ~ PB04
```
, but corresponding key questions, deliverables, or anti-pattern checks do not appear
```
product-prd
```
and
```
generation-pack
```
have content cross-writing, such as PRD body mixing page prompts, HiUI handoff, or gate details
Key pages in generation-pack still stay at abstract module names, no field/column/filter/operation-level refinement
Hit back-office enhanced scenarios, but permission matrix, state transition, field dictionary, batch specification, or migration strategy are still missing, leading to unstable page and rule implementation
Hit multi-tenant, version differences, master data ownership, or system boundary issues, but still do not answer source of truth, activation model, or conflict handling
Next step is to enter page generation, HiUI generation, prototype generation, or UX acceptance, but
```
generationInputGate.status
```
is neither
```
confirmed
```
nor
```
assumption-authorized
```

Guardrails

Must not 把模糊输入直接包装成“完整 PRD”或“已确认方案”；确认不足时必须显式保留
```
remainingDebt
```
或
```
assumptions
```
。
Must not 为了减少反问而跳过高影响问题；但也不得为低价值细节过度追问，始终保持每轮最多 3 个高影响问题组。
Before 进入页面生成、HiUI 生成、原型生成或 UX 验收，必须 confirm 生成输入已被用户确认，或明确记录为
```
assumption-authorized
```
/
```
blocked
```
。
Must not 把“继续”“开始吧”“生成页面”等泛化表述自动视为假设授权；只有用户明确 confirm 生成输入或明确授权假设，才可进入下游生成。
Must not 虚构业务规则、字段、权限、状态机、接口约束或成功指标；缺失时只能标记为假设、待确认或推荐方案。
Must not 机械套用模板导致输出与后台形态不匹配；管理后台、运营后台、配置治理后台、流程审批后台、数据后台、平台后台必须按对应重点收敛。
Must not 将本 skill 漂移成泛 C 端、内容社区、增长活动或营销策略助手；若输入不属于 B 端中后台，应明确提示弱适配，而不是假装全面覆盖。
Must not 用“经营概览”“异常清单”“商品表”“配置区”等抽象模块名替代字段、列、筛选、操作、校验和状态说明；若无法细化，必须继续确认或标记为待确认版本。
Validate 页面清单、提示词、HiUI handoff 和门禁状态彼此一致；不得输出无法被下游消费的松散页面提示词。
Must not 把页面级提示词、HiUI 交接信息、机器计划或 gate 细节塞进正式 PRD 正文；这些内容只能放在独立生成包或附录中。
Must not 在进入
```
generationInputGate
```
时只给页面提示词摘要；确认前必须提供完整页面级提示词。若当前交付模式包含 PRD，也不得只给 PRD 摘要，必须提供在线文档 PRD 链接或 Markdown 路径。
Must not 在未说明风险的情况下扩张范围；新增页面、流程、批量操作、导入导出、通知、审计等能力时，必须说明其业务依据。
Must not 默认脑补租户模型、数据权限模型、组织架构或审计要求；这些是 B 端后台的高影响决策，缺失时必须显式追问或标记为假设。
Must not 只做需求归纳，不做 B 端专家判断；当用户要的是“出方案/给建议/评审方向”时，必须补充价值判断、方案取舍和结构决策。
Must not 把“能做”误写成“该做”；若需求存在明显低价值、高复杂度、低频人工可兜底或治理成本过高的问题，必须指出而不是盲目推荐系统化。
Must not 命中高频行业场景却仍按纯通用后台方式处理；工单/审批/SLA、结算/对账/发票、账号/组织/权限、配置中心/发布/回滚必须优先套用对应 playbook。
Must not 遇到多租户、版本差异、客户定制、功能开通时只写页面差异，不写产品模型。
Must not 遇到跨系统对象时只写接口存在，不写事实源、创建归属、同步方式、冲突处理和停用策略。
Must not 把权限矩阵、状态流转、字段字典、批量规范、迁移策略仅写成一两句抽象描述；命中相关场景时必须产出结构化结果，或明确说明当前尚未补齐。
Must not 忽略高风险后台动作的安全约束，例如二次确认、原因填写、双人复核、撤销/补偿、审计留痕和通知策略。
Must not 在导入导出或异步任务场景里漏掉预校验、部分成功、失败明细、进度反馈、回执下载、幂等与重试。
Must not 在平台/集成后台场景里只写页面，不写数据契约、回调、同步方式、失败恢复和一致性策略。
Must not 放过明显反模式，例如复杂流程硬塞抽屉、审批无责任节点、看板无口径、导入无回执、配置无版本回滚；命中时必须主动指出。
Must not 忽略可显著降低
```
questionDebt
```
的本地高信号知识源；若当前仓库中存在相关文档、模块、接口、类型或 mock，必须先利用或明确说明为何跳过。
Must not 把仓库证据写成用户确认；仓库中的命名、实现和规则只能作为候选上下文、冲突信号或复用线索。
Must not 被现有实现锚定而直接收口；若仓库已有页面模式、字段结构或模块边界与用户目标可能冲突，必须显式提出“沿用现状 / 新开能力 / 重构归并”的确认问题。

Must not directly package vague inputs as "complete PRD" or "confirmed solution"; must explicitly retain
```
remainingDebt
```
or
```
assumptions
```
when confirmation is insufficient.
Must not skip high-impact questions to reduce follow-up; but also must not over-ask for low-value details, always keep at most 3 high-impact question groups per round.
Before entering page generation, HiUI generation, prototype generation, or UX acceptance, must confirm generation inputs have been confirmed by users, or explicitly record as
```
assumption-authorized
```
/
```
blocked
```
.
Must not automatically regard generalized expressions such as "Continue", "Start", "Generate pages" as assumption authorization; only when users explicitly confirm generation inputs or explicitly authorize assumptions can downstream generation be entered.
Must not fabricate business rules, fields, permissions, state machines, interface constraints, or success metrics; mark as assumption, to-be-confirmed, or recommended solution when missing.
Must not mechanically apply templates leading to output mismatched with back-office form; management back-office, operation back-office, configuration governance back-office, process approval back-office, data back-office, platform back-office must converge according to corresponding priorities.
Must not drift this skill into a generalized C-end, content community, growth activity, or marketing strategy assistant; if input does not belong to B-end back-office, should explicitly prompt weak adaptation, rather than pretending to cover comprehensively.
Must not use abstract module names such as "Operation Overview", "Exception List", "Product Table", "Configuration Area" to replace explanations of fields, columns, filters, operations, validation, and states; if unable to refine, must continue confirmation or mark as to-be-confirmed version.
Validate consistency between page inventory, prompts, HiUI handoff, and gate status; do not output loose page prompts that cannot be consumed by downstream.
Must not stuff page-level prompts, HiUI handoff information, machine plans, or gate details into formal PRD body; these contents can only be placed in independent generation packs or appendices.
Must not only provide page prompt summaries when entering
```
generationInputGate
```
; complete page-level prompts must be provided before confirmation. If current delivery mode includes PRD, also must not only provide PRD summary, must provide online document PRD link or Markdown path.
Must not expand scope without explaining risks; when adding pages, flows, batch operations, import/export, notifications, audits, etc., must explain their business basis.
Must not default to imagining tenant models, data permission models, organizational structures, or audit requirements; these are high-impact decisions for B-end back-office, must explicitly follow up or mark as assumption when missing.
Must not only perform requirement induction, but also provide B-end expert judgment; when users want "create a solution / give advice / review direction", must supplement value judgment, solution trade-offs, and structural decisions.
Must not mistake "can do" for "should do"; if requirements have obvious low value, high complexity, low frequency that can be covered manually, or excessive governance costs, must point it out rather than blindly recommending systematization.
Must not still handle high-frequency industry scenarios in a purely general back-office way; ticket/approval/SLA, settlement/reconciliation/invoice, account/organization/permission, configuration center/release/rollback must prioritize applying corresponding playbooks.
Must not only write page differences when encountering multi-tenant, version differences, customer customization, feature activation, but not write product models.
Must not only write that interfaces exist when encountering cross-system objects, but not write source of truth, creation ownership, synchronization method, conflict handling, and deactivation strategy.
Must not only write abstract descriptions for permission matrix, state transition, field dictionary, batch specification, migration strategy; must produce structured results when hitting relevant scenarios, or explicitly explain that it has not been completed currently.
Must not ignore security constraints for high-risk back-office actions, such as secondary confirmation, reason filling, double review, revocation/compensation, audit trails, and notification strategies.
Must not miss pre-validation, partial success, failure details, progress feedback, receipt download, idempotency, and retry in import/export or asynchronous task scenarios.
Must not only write pages in platform/integration back-office scenarios, but not write data contracts, callbacks, synchronization methods, failure recovery, and consistency strategies.
Must not ignore obvious anti-patterns, such as stuffing complex flows into drawers, approvals without responsible nodes, dashboards without calibers, imports without receipts, configurations without version rollback; must proactively point out when hitting.
Must not ignore local high-signal knowledge sources that can significantly reduce
```
questionDebt
```
; if relevant documents, modules, interfaces, types, or mock exist in the current repository, must utilize first or explicitly explain why skipped.
Must not write repository evidence as user confirmation; naming, implementations, and rules in the repository can only be used as candidate context, conflict signals, or reuse clues.
Must not be anchored by existing implementations and conclude directly; if existing page patterns, field structures, or module boundaries in the repository may conflict with user goals, must explicitly propose a confirmation question of "follow existing status / open new capability / refactor and merge".

参考

References

```
references/confirmation-model.md
```
：确认深度、问题债务、确认完整度和选项质量示例
```
references/output-templates.md
```
：输出表格、追踪矩阵、全局上下文、页面提示词和最终检查清单
```
references/product-prd-template.md
```
、
```
references/delivery-modes.md
```
：正式 PRD 结构、协作文档/Markdown 协议与交付模式规则

references/hiui-handoff-template.md

、

references/project-context-loading.md

、

references/forward-test-examples.md

：HiUI 交接、项目上下文预载与最小前向验证样例

```
references/confirmation-model.md
```
: Confirmation depth, question debt, confirmation completeness, and option quality examples
```
references/output-templates.md
```
: Output tables, traceability matrices, global context, page prompts, and final checklists
```
references/product-prd-template.md
```
,
```
references/delivery-modes.md
```
: Formal PRD structure, collaborative document/Markdown protocol, and delivery mode rules

references/hiui-handoff-template.md

references/project-context-loading.md

references/forward-test-examples.md

: HiUI handoff, project context preload, and minimal forward verification examples