# Bkn Requirement

> 当需要从客户背景、拜访准备、业务访谈、会议纪要、录音转写、PRD、BRD、流程说明、系统/数据材料或粗略想法中，整理调研提纲、PRD 迭代、追问清单、验收用例和 BKN_Creator 交接摘要时使用。

- Skill: `openbkn-ai/bkn-requirement` (Agent Skill, multi-file: 26 files)
- Install (CLI): `npx skillmds@latest add openbkn-ai/bkn-requirement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openbkn-ai/bkn-requirement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: openbkn-ai (https://skillmd.com/u/openbkn-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openbkn-ai/bkn-requirement

---


# BKN Requirement

## 目标

在正式 BKN 建模之前使用本 Skill。它负责把客户背景、调研目标、会议纪要、PRD 或业务材料，转化为可被业务专家评审、产品/交付团队使用、AI 工程师追问、并可交给 `bkn-creator` 继续建模的标准 PRD。

当前版本：`V0.7`。V0.7 的主线是“需求发现 Agentic Harness”：会前生成短调研提纲，会后读取 AI 会议纪要，基于上一版 PRD 持续迭代需求文档；正式 PRD、PRD 迭代和 `BKN_Creator` 交接摘要必须经过 Generate → Verify → Revise → Final Gate 的闭环，并保留内部检查 findings 和修订摘要。BKN 元素只用于后台检查和 `BKN_Creator` 交接摘要。

本 Skill 不生成 `.bkn` 文件，不绑定数据来源或平台数据视图，不推送知识网络，也不执行平台操作。这些是 `bkn-creator` 和 `openbkn` 的下游职责。

## 适用场景

当用户需要完成以下任务时使用本 Skill：

- 根据客户名称、行业、部门、拜访目标或粗略方向，准备简短业务调研提纲；
- 基于客户背景和已有材料，生成会前调研参考、参会角色建议和材料索要清单；
- 从访谈纪要、录音转写、PRD、BRD、流程说明、系统截图、数据字典或粗略想法整理需求；
- 从豆包、飞书、腾讯会议等 AI 会议纪要中提取本轮调研更新、待确认问题和 PRD 影响；
- 基于“本轮调研大纲 / 调研目标 + 会议纪要及相关材料 + 上一版 PRD”生成新一版 PRD；
- 帮助 AI 工程师与业务专家对话，澄清业务场景、流程、规则、系统、数据、输入输出和验收样例；
- 将偏技术、偏建模或偏 POC 的材料重构为业务用户可评审的标准 PRD；
- 评估某个业务场景是否已经具备后续 BKN 建模条件；
- 生成业务验收用例、待确认问题和 `BKN_Creator` 交接摘要。

如果用户已经有确认后的建模需求，并明确要求创建、更新、校验、绑定、测试或推送 BKN，应转交 `bkn-creator`。

## 核心原则

默认使用业务语言。业务用户通常表达的是流程、规则、标准、表单、系统、数据、输入、输出、目标、审批和异常；不要要求业务用户先理解对象、关系、指标、算子、行动类型或 Skill。

本 Skill 的 BKN 方法论总纲是 `references/bkn-methodology.md`。涉及对象、事实属性、关系、指标、算子、行动、治理、Agent / Skill 应用层和验证口径时，以该文件为统一边界；`references/bkn-requirement-ontology-discovery.md` 只是在需求发现阶段的业务化裁剪和示例集。

`references/bkn-methodology.md` 随本 Skill 一起分发。单独安装 `bkn-requirement` 后，运行时只读取本 Skill 内的该文件，不依赖仓库中的其他目录。

需求发现生命周期主线是：

```text
Intake → Research Plan → Interview → Meeting Digest
→ PRD Iteration → Readiness Gate → BKN_Creator Handoff
```

正式输出执行主线是：

```text
Archive / Context → Generator → Verifier → Reviser（如有必要）
→ Final Gate → Final Output
```

执行协议见 `references/agentic-harness.md`。`prd_mode`、`prd_iteration_mode` 和 `handoff_mode` 必须执行完整 Harness；`research_plan_mode`、`meeting_digest_mode` 和 `review_mode` 可执行轻量 Harness；`intake_mode` 只输出最小澄清问题。

Harness 的中间产物包括候选结果、`verification_findings`、修订摘要和 Final Gate 结论。除非用户明确要求，这些内部产物不原样写入 PRD 正文，但必须用于判断是否可以输出 Ready。若本轮会在项目目录落盘正式 PRD、PRD 迭代或 handoff，必须同步落盘同名 `*-verification-findings.md`。

BKN 元素承担三类作用：

1. 作为 AI 工程师检查 PRD 完整性的后台维度；
2. 作为追问业务专家时的线索；
3. 作为交给 `bkn-creator` 的摘要，不作为 PRD 主体叙事。

## 核心流程

先判断输入处于需求发现生命周期的哪个阶段。不要把零散背景、拜访准备或会议纪要都强行处理成完整 PRD。

| 输入状态 | 默认模式 | 输出 |
|---|---|---|
| 只有客户名称、行业、部门、拜访目的或粗略方向 | `intake_mode` | 最小澄清问题、调研前置条件 |
| 准备拜访客户，有少量背景材料 | `research_plan_mode` | 客户现场短提纲、会议目标、参会角色建议、材料索要清单 |
| 输入 AI 会议纪要、录音转写或访谈摘要 | `meeting_digest_mode` | 本轮新增事实、假设、冲突、场景、规则、系统数据、待确认问题 |
| 输入调研大纲、会议纪要及相关材料、上一版 PRD | `prd_iteration_mode` | 新一版 PRD、修订摘要、版本记录、成熟度变化、下一轮追问 |
| 已有业务材料、PRD 或 BRD，用户要求“整理需求 / 标准化 PRD / 改写 PRD / 输出正式文档” | `prd_mode` | 业务场景中心 PRD，附质量摘要、待确认问题和 BKN_Creator 交接摘要 |
| 已有 PRD / BRD，用户明确要求“评估 / 评审 / 检查 / 是否可进入 BKN_Creator” | `review_mode` | 质量评分、缺口清单、改写建议 |
| PRD 已确认，需要下游建模交接 | `handoff_mode` | `bkn_creator_handoff` |

## 项目目录与命名规范

每个客户或项目必须有独立项目文件夹，避免多项目资料混在一起。默认目录统一为：

```text
projects/prj-<客户或项目简称>/
```

统一使用 `projects/prj-<项目>/`。该共享项目目录可承载需求发现、PRD、验证输出、`BKN_Creator` 交接摘要、可选本体建模方案和后续 BKN 交付参考。

如用户未提供项目目录，应先建议创建项目目录，再输出文件名建议。不要把不同客户的调研大纲、会议纪要、PRD 和验证输出混放在通用项目根目录。

文件命名规则：

| 文档类型 | 命名格式 |
|---|---|
| 调研大纲 / 调研参考 | `<项目名>-调研大纲.md` 或 `<项目名>-第X轮调研大纲.md` |
| 会议纪要 / 调研备忘 | `YYYYMMDD-<项目名>-第X轮现场交流调研备忘.md` |
| 验证性输出 / meeting digest | `<项目名>-prd-第X轮验证输出.md` |
| PRD 文档 | `<项目名>-PRD vX.Y.md` |

每轮输入材料应归档到：

```text
projects/prj-<客户或项目简称>/inputs/round-XX/
```

推荐命名：

| 输入类型 | 命名格式 |
|---|---|
| 调研大纲 | `YYYYMMDD-<项目名>-第X轮-input-调研大纲.md` |
| 会议纪要 / 录音转写 | `YYYYMMDD-<项目名>-第X轮-input-会议纪要.md` |
| 客户补充材料 | `YYYYMMDD-<项目名>-第X轮-input-客户材料-<材料名>.<ext>` |
| 上一版 PRD 引用 | 不重复复制；在 source manifest 中登记版本和路径 |

不要移动用户原始文件。若用户指定的输入文件不在项目文件夹内，必须先复制到本轮 `inputs/round-XX/` 作为项目证据材料；若输入文件已在项目文件夹内，可以不复制，但必须在输出文档和 `source-manifest.md` 中记录路径。

每轮处理都应生成或更新：

```text
projects/prj-<客户或项目简称>/inputs/round-XX/source-manifest.md
```

`source-manifest.md` 记录本轮原始路径、归档路径、材料类型、用途、处理时间和使用方式。模板见 `assets/source-manifest-template.md`。

输入归档是生成验证输出或 PRD 之前的前置步骤：

1. 先创建 `inputs/round-XX/`；
2. 再复制外部输入文件，或登记项目内已有输入文件；
3. 再检查 `source-manifest.md` 中所有 `是否复制=是` 或 `copied_to_project=true` 的 `归档路径 / archived_path` 是否真实存在；
4. 只有检查通过后，才能在 manifest 中写“已复制”；
5. 如果复制失败、权限不足或路径无法访问，不得伪造归档状态。必须写“是否复制=否”、记录失败原因，并在最终输出开头标注“输入归档未完成”。

第一轮之后有两种输出路径：

- 信息不足以形成 PRD：输出 `<项目名>-prd-第1轮验证输出.md`，用于判断缺口和下一轮调研重点。
- 信息足以形成初版 PRD：输出 `<项目名>-PRD v0.1.md`，并标注 `Draft`、成熟度和未确认事项。

## 项目上下文自动识别

用户只提供项目目录时，采用宽进严出的默认行为：先自动识别最新项目上下文，再根据用户意图选择模式。不要因为用户没有手工列出全部输入文件就停止。

自动识别顺序：

1. 识别最新 PRD：优先选择最高版本号的 `<项目名>-PRD vX.Y.md`；
2. 识别最新验证输出：优先选择最高轮次的 `<项目名>-prd-第X轮验证输出.md`；
3. 识别最新调研大纲、会议纪要和本轮 `inputs/round-XX/` 材料；
4. 若用户说“处理会议纪要 / 看本轮调研”，默认进入 `meeting_digest_mode`；
5. 若用户说“更新 PRD / 迭代需求”，默认进入 `prd_iteration_mode`，使用最新 PRD、最新会议纪要和最新调研大纲；
6. 若用户说“整理需求 / 标准化 PRD / 改写 PRD / 输出正式文档”，默认进入 `prd_mode`，读取最新 PRD 或业务材料并输出标准 PRD；
7. 若用户说“评估 PRD / 评审 PRD / 检查 PRD / 是否可进入 BKN_Creator”，默认读取最新 PRD 并进入 `review_mode`；
8. 若用户说“准备拜访”，默认读取项目背景、上一轮验证输出或上一版 PRD，生成下一轮调研大纲。

只有在同一目录下存在多个同版本 PRD、多个同轮次会议纪要、轮次无法判断或用户意图冲突时，才要求用户确认。本次使用了哪些文件，必须在输出开头列出“本轮输入来源”。

按以下原则执行。不要跳过缺口识别：未确认问题是必需输出，不是失败。

1. **整理输入材料**
   - 识别输入来源：粗略想法、访谈记录、录音转写、PRD、流程图、系统说明、数据字典、截图、历史案例。
   - 在生成验证输出或 PRD 之前，将本轮输入文件归档或登记到项目目录的 `inputs/round-XX/source-manifest.md`。
   - 校验 manifest 中标记为已复制的归档文件确实存在；不存在时必须更正状态并暴露风险。
   - 区分已确认事实、假设、冲突信息和缺失信息。
   - 如果输入是录音转写或会议纪要，读取 `references/meeting-transcript-processing.md`。
   - 如果输入是 PRD 迭代任务，必须同时识别 `research_outline`、`meeting_notes_and_materials` 和 `previous_prd`。

2. **识别业务场景**
   - 先识别业务目标、用户角色、触发条件、当前流程、目标流程、业务输入、业务输出、成功指标。
   - 将材料拆成一个个可验收场景；综合性需求也要拆出主场景和跨场景规则。
   - 每个 P0/P1 场景必须说明它提升哪项业务能力，并识别关键决策点：谁在何时做什么判断、依赖哪些事实和规则、错判代价是什么。
   - 每个 P0/P1 场景必须说明操作闭环：发现 → 判断 → 建议 → 确认 → 执行 → 状态变化 → 追踪 → 反馈。不能只描述“用户查看结果”。
   - 使用 `references/fde-method.md` 中的 FDE 式业务访谈方法；不要把 BKN 映射内容写进 PRD 主体。

3. **还原业务规则与决策**
   - 记录规则口径、判断标准、异常边界、人机协同点、审批点、拒绝执行边界和可配置项。
   - 用业务语言表达规则，不把规则提前写成 BKN 行动、技术算子或平台实现。

4. **发现系统、表单与数据现状**
   - 识别业务系统、表单、数据源、事实来源、关键字段、对象 ID、刷新频率、质量风险、访问限制和外部写回系统。

5. **生成业务验收用例**
   - 每个核心场景至少包含典型用例、边界用例、权限/拒绝用例、数据不足用例和证据解释用例。
   - 验收用例应使用业务输入和业务期望，不以对象 / 关系 / 指标 / 算子作为主字段。
   - 待确认问题与访谈追问清单必须按业务场景组织，并优先使用业务语言。
   - 不要在业务访谈问题中直接问 `object_type`、`relation_type`、`ActionType`、BKN、data_view、主键、关系基数、接口粒度、写回粒度或字段名；如出现这些内容，必须转译成业务动作、业务结果、人工确认、责任人或验收样例，或移入 `需下游建模阶段判定的问题`。
   - 如果确实需要系统、字段、接口、写回或 SLA 级确认，必须放入独立的“系统与数据确认问题”小节，不能挤占每个场景的主追问。

6. **评估需求质量**
   - 标注需求成熟度：`R0 Idea`、`R1 Use Case Brief`、`R2 PRD Candidate`、`R3 PRD Ready`、`R4 Implementation Ready`。
   - 输出业务可读的“需求成熟度与下一步建议”，重点说明当前成熟度、已清楚内容、仍缺关键证据、当前不宜确认范围和建议下一步；不要在 PRD 正文输出内部评分 YAML。
   - 评估时同时判断 `use_case_readiness` 和 `handoff_readiness`：前者看价值、决策和闭环是否成立，后者看下游建模输入是否足够。
   - 使用 `references/quality-scoring.md`。
   - 对 `prd_mode`、`prd_iteration_mode`、`handoff_mode`，必须按 `references/requirement-verifier.md` 生成内部 `verification_findings`，再决定是否进入修订。

7. **生成 BKN_Creator 交接摘要**
   - 仅在 PRD 末尾输出中文业务交接摘要，不输出机器可读 schema。
   - 需求发现阶段的核心始终是业务语言；交接摘要用于帮助后续建模理解业务，不把 PRD 变成建模输入文件。
   - 正文四层业务收敛必须先出现在 PRD 正文的每个核心场景中，再进入文末交接摘要。每个 P0/P1 场景都必须补充“该场景成立所需的业务对象、业务联系、业务逻辑、责任与控制”小节，并记录可由 Skill / Agent 支撑的业务任务线索，说明为什么需要这些内容、它们来自哪个业务规则或验收目标、若不确认会影响什么。
   - PRD 正文优先使用业务标题：`需要识别的业务对象（概念模型层）`、`需要表达的业务联系（关系层）`、`需要判断、计算或推进的业务逻辑（动力层）`、`需要控制的责任、权限与留痕（治理层）`。不要只列名词或“候选：对象清单”，不要用“算子 — ...”作为正文标签。
   - 在进入正文四层业务收敛前，必须先做本体论分类：区分 `对象候选`、`事实属性 / 枚举候选`、`关系候选`、`结果候选`、`指标候选`、`算子 / 逻辑能力候选`、`状态变化`、`行动候选` 和 `治理要求`。不能因为一个词是名词就把它当对象，不能因为一个动作发生在界面上就把它当治理。
   - 判定准则先看 `references/bkn-methodology.md` 的对象、关系、动力层、行动和治理边界，再看 `references/bkn-requirement-method.md` 的“本体论判别纪律”和 `references/bkn-requirement-ontology-discovery.md` 的需求发现裁剪示例。若分类、对象边界、关系成立条件、逻辑归属或行动边界尚不确定，必须标为“待下游建模判定”，不得含混处理。
   - 中文业务可读摘要必须先按场景归纳固定五层交接表，再输出中文全局归并标题：`业务已确认内容`、`仍属建模候选`、`需下游建模阶段判定的问题`。
   - 第 15 节 `BKN_Creator` 交接摘要必须按每个已承诺 P0/P1 场景展开固定五层表格：
     - 概念模型层：`业务对象 | 是什么 | 为什么需要 | 边界 | 确认状态 | 来源 / 验收映射`
     - 关系层：`业务联系 | 连接什么 | 业务含义 | 为什么需要 | 确认状态 | 来源 / 验收映射`
     - 动力层：`类型 | 业务逻辑 | 怎么做 / 怎么判断 | 输出什么 | 边界 | 确认状态 | 来源 / 验收映射`
     - 治理层：`治理点 | 控制什么 | 谁负责 / 谁使用 | 为什么需要 | 确认状态 | 来源 / 验收映射`
     - Skill / Agent 应用层：`Agent 任务 | 帮谁 | 做什么 | 输出要求 | 不能自动做什么 / 风险边界 | 确认状态 | 来源 / 验收映射`
   - 五层表达必须“逐项业务化”：概念模型层要逐个说明每个业务对象是什么、为什么需要；关系层要逐条说明连接什么、业务含义是什么、为什么需要；动力层要逐项说明怎么判断 / 计算 / 推进、输出什么、边界是什么；治理层要逐点说明控制什么、谁负责、为什么需要；Skill / Agent 层要逐项说明帮谁、做什么、输出要求。禁止只列名词、只列关系短语或只写层级概述。
   - `BKN_Creator` 交接摘要必须继承正文场景小结的业务表达，不得把正文里已经说清楚的业务意义压缩回 `SKU、库存、BOM` 这类孤立名词列表；也不得写成 `对象：A、B；关系：A-B；逻辑：X` 这类压缩摘要。
   - 必须执行“确认状态门禁”：全局 `业务已确认内容` 只能放入来自明确场景、有业务证据或验收用例、业务含义清楚、且未标注“待确认 / 未确认 / 待对齐 / 是否 / 范围待定 / 范围待确认 / 候选”的内容；只要一句话含上述任一信号，就不得进入 `业务已确认内容`，必须拆入 `仍属建模候选` 或 `需下游建模阶段判定的问题`。
   - 必须执行“本体一致性门禁”：关系层出现的核心名词必须已在概念模型层逐项说明；动力层输出的结果必须判定为业务对象、派生结果或状态，不得默认升格为对象；`满足方案行`、`缺口行`、`报表行`、`看板指标` 等结果类内容默认进入结果候选，只有能说明稳定身份、生命周期、责任人或后续业务动作时，才可作为对象候选。
   - 必须执行“核心对象优先门禁”：先识别业务上被管理和判断的核心对象，再判断是否需要拆出细分对象。不得把同一核心对象的粒度、状态、数量、口径、扣减项直接拆成多个对象。例如库存场景中，`库存` 应优先作为核心对象；批次、库存状态、库存数量、可用数量、占用数量、占用来源默认作为属性、枚举、计算口径或与生产工单的关系，只有业务按批次或占用事实独立追踪、冻结、释放、审批、盘点、审计时，才可将 `库存批次` 或 `库存占用` 升格为对象候选。
   - 必须执行“规则与角色不对象化门禁”：业务规则、口径、算法判断、建议结果、场景角色名不得默认成为对象。`替代规则` 默认是 `物料 替代 物料` 关系上的约束或 `替代料覆盖判断` 逻辑输入；`拆料来源产品` 默认是 `产品` 或 `库存` 在拆料场景中的角色，不是新对象。只有规则有编号、版本、生效期、审批、发布废止和责任人，或建议结果有确认、调整、分派、关闭、复盘生命周期时，才允许升格为对象候选。
   - 不能把候选对象、关系、事实属性、指标、算子、结果候选或行动伪装成业务已确认事实。
   - 交接摘要生成后必须再次执行 Verifier；若存在 hard stop，先修订，不得输出 Ready。

## 输出模式

用户未指定时，按输入状态自动选择模式，不默认强行输出完整 PRD。

- `intake_mode`：弱输入时输出最小澄清问题。不要生成 PRD。
- `research_plan_mode`：拜访前输出客户现场短提纲、会议目标、参会角色建议和材料索要清单。默认保持 1-2 页，业务化、开放式。
- `meeting_digest_mode`：会后读取 AI 会议纪要，输出本轮调研更新和待确认问题。不要要求 AI 工程师手工填内部调研记录。
- `prd_iteration_mode`：基于三输入模型生成新一版 PRD。
- `prd_mode`：输出标准 PRD，适合业务、产品、客户、交付和项目评审。若输入是已有 PRD / BRD 且用户说“整理需求”，先做轻量质量判断，再直接重构为标准 PRD；质量评分和缺口作为摘要写入 PRD，不作为唯一主交付。若 PRD 写入项目目录，必须同时写入同名 `*-verification-findings.md`。
- `review_mode`：仅在用户明确要求评估、评审、检查或判断是否可进入 `BKN_Creator` 时使用。输出评分、问题和改写建议，不默认生成新版 PRD。
- `handoff_mode`：仅输出交给 `bkn-creator` 的交接摘要，适合 PRD 已确认后的下游交接。

如用户明确要求“只做建模输入”，提醒这属于 `bkn-creator` 范围，并可先输出 handoff。

## PRD 迭代规则

`prd_iteration_mode` 标准输入：

| 输入 | 用途 |
|---|---|
| `research_outline` | 本轮调研大纲、调研目标、原计划确认的问题，用于防止会议纪要输入后 PRD 更新失焦。 |
| `meeting_notes_and_materials` | 本轮会议纪要、录音转写、截图、表单、样例数据、客户补充材料。 |
| `previous_prd` | 上一版 PRD，作为增删改和版本记录的基线。 |

`prd_iteration_mode` 必须输出：

- `updated_prd`：新一版 PRD；
- `revision_summary`：新增事实、修正事实、废弃内容、影响章节；
- `change_log`：版本记录；
- `unresolved_questions`：仍待确认问题；
- `next_research_focus`：下一轮调研重点。

每一版 PRD 都应记录文档版本、当前状态、本轮输入、主要变更和待确认重点。版本记录由 Skill 自动生成，不设计 AI 工程师手工填写的内部调研记录模板。

如果用户只给项目目录，三输入模型可由项目上下文自动识别补齐；如果缺少上一版 PRD，则不要强行进入 `prd_iteration_mode`，应输出 `meeting_digest_mode` 验证结果，或在信息足够时生成 `PRD v0.1 Draft`。

## 标准 PRD 结构

完整 PRD 默认使用以下结构。需要完整模板时读取 `assets/requirements-template.md`。

```markdown
# 《<场景名> PRD》

## 1. 文档信息
## 2. 本轮变更摘要（PRD 迭代时必需）
## 3. 业务背景与目标
## 4. 业务用户与职责
## 5. 场景总览
## 6. 场景需求详述
## 7. 跨场景业务规则
## 8. 业务系统、表单与数据来源
## 9. 权限、审批与合规要求
## 10. 界面 / 交互期望
## 11. 非功能需求
## 12. 业务验收用例
## 13. 待确认问题与访谈追问清单
## 14. 需求成熟度与下一步建议
## 15. BKN_Creator 交接摘要
## 16. 版本记录
```

对于每个已承诺的 P0/P1 场景，`## 6. 场景需求详述` 下还必须包含“场景收敛小结”：

- `需要识别的业务对象（概念模型层）`
- `需要表达的业务联系（关系层）`
- `需要判断、计算或推进的业务逻辑（动力层）`
- `需要控制的责任、权限与留痕（治理层）`

这些内容必须先解释业务意义，再提炼候选建模项；不能只在文末 handoff 中补一张技术表。

`## 15. BKN_Creator 交接摘要` 必须比 `## 6. 场景需求详述` 的场景收敛更完整，不能更抽象。第 6 节可以用业务小结表达，第 15 节必须使用固定五层表格逐项展开，特别是概念模型层必须包含 `边界`，防止对象被过早拆分或误升格。

每个已承诺的 P0/P1 场景还必须具备最小“场景契约”：

- 该场景提升的业务能力；
- 关键决策点；
- 操作闭环；
- 完成判断所需的业务事实、关系和逻辑；
- 对应验收用例。

若某项能力只来自原文引用、缺少正文定义或仍属“范围候选 / 范围待确认”，不要把它放入已承诺的 P0/P1 场景；应降级为候选能力或待确认范围。若仍保留为 P1，则必须补最小场景契约。

## 质量门禁

最终输出前必须按 `references/agentic-harness.md` 执行 Final Gate。除非用户明确要求查看评审过程，内部 `verification_findings` 不原样写入 PRD 正文。

当输出文件落盘时，`verification_findings` 不进入 PRD 正文，但必须写入同目录同名 `*-verification-findings.md`。

Verifier 检查：

- 是否已完成 `references/anti-drift-checklist.md` 的防跑偏检查；
- 是否能让业务专家不懂 BKN 也能评审；
- 是否有明确业务目标、用户角色、触发条件、输入、输出和成功指标；
- 是否按场景组织，而不是按对象、关系、指标、算子、行动组织；
- 每个场景是否有当前流程、目标流程、业务规则、异常边界、人工确认点和界面期望；
- 是否记录业务系统、表单、数据源、事实来源、字段口径、刷新频率、访问限制和数据质量风险；
- 业务验收用例是否覆盖典型问题、分析请求、决策建议、权限拒绝、数据不足和证据解释；
- 待确认问题与访谈追问清单是否按场景组织，并说明“问谁、为什么问、不确认的风险、建议问法”；
- 待确认问题是否优先业务化；若出现 `object_type`、`relation_type`、`ActionType`、BKN、data_view、主键、关系基数、接口粒度、写回粒度或字段名，是否已转译成业务语言或移入 `需下游建模阶段判定的问题`；
- PRD 迭代输出是否包含本轮输入来源、变更摘要、版本记录和下一轮追问；
- 本轮输入文件是否已复制归档或登记到 `inputs/round-XX/source-manifest.md`；
- `source-manifest.md` 中标记为已复制的每个 `archived_path` 是否真实存在；不存在时不得写“已复制”；
- 若输出已落盘，是否同步生成同名 `*-verification-findings.md`；
- `BKN_Creator` 交接摘要是否仅放在末尾，并保持为中文业务可读摘要；
- 交接摘要是否先按场景做五层收敛，再归并为 `业务已确认内容`、`仍属建模候选`、`需下游建模阶段判定的问题`；
- 每个已承诺 P0/P1 场景的第 15 节是否使用固定五层表格：概念模型层、关系层、动力层、治理层、Skill / Agent 应用层；
- 概念模型层是否包含 `业务对象 | 是什么 | 为什么需要 | 边界 | 确认状态 | 来源 / 验收映射`，并说明对象边界而不是只列名称；
- 第 15 节是否没有比第 6 节更抽象，且没有压缩为 `对象：A、B；关系：A-B` 这类名词链；
- 五层表达是否逐项说明“是什么 / 为什么 / 怎么做 / 谁负责 / 输出什么”，而不是只写层级概述或名词清单；
- 全局归并项是否都能追溯到至少一个场景、规则或验收用例；无法追溯的内容不得进入 `业务已确认内容`；
- `业务已确认内容` 是否通过确认状态门禁：不得包含“待确认 / 未确认 / 待对齐 / 是否 / 范围待定 / 范围待确认 / 候选”等信号；
- BKN_Creator 交接摘要是否通过本体一致性门禁：关系层核心名词已在概念模型层出现，结果类内容未被默认当作对象；
- BKN_Creator 交接摘要是否通过本体建模门禁：对象具备身份、生命周期、责任、关系或管理动作；关系连接两个已说明对象；指标具备统一口径；算子说明输入、规则、输出和边界；行动确实改变对象、影响对象或外部系统；治理说明责任、权限、审批、留痕或拒绝自动化边界；
- BKN_Creator 交接摘要是否通过核心对象优先门禁：没有把核心对象的粒度、状态、数量、口径、扣减项过早拆成对象；细分对象必须说明独立生命周期、管理动作或治理必要性；
- BKN_Creator 交接摘要是否通过规则与角色不对象化门禁：没有把规则、口径、算法判断、建议结果或场景角色名直接放入对象层；
- 没有把“算子”作为正文业务标签；PRD 主体应写成业务计算、业务判断、推荐、解释或推进逻辑，算子 / 逻辑能力候选只放入 handoff 或下游建模判定问题。
- 若出现 `hard_stop`，必须进入 Reviser；自动修订最多 2 轮。仍未通过时，输出 fail / warn 原因和下一轮调研问题，不得声明 PRD Ready 或 handoff Ready。

## 参考资料

- BKN 方法论分发快照：`references/bkn-methodology.md`。凡涉及对象、事实属性、关系、指标、算子、行动、治理和 Agent / Skill 应用层判定，以该文件为统一边界；本 Skill 只负责需求发现阶段的业务化表达和交接摘要。
- Agentic Harness 执行协议：`references/agentic-harness.md`，输出正式 PRD、PRD 迭代或 `BKN_Creator` 交接摘要前必读，用于执行 Generate / Verify / Revise / Final Gate 闭环。
- Verifier 规范：`references/requirement-verifier.md`，生成内部 `verification_findings` 时必读，用于判定 hard stop、major、minor 和 final gate。
- 防跑偏检查：`references/anti-drift-checklist.md`，最终输出前必读，用于防止 PRD 重新技术化、候选混入已确认、机器 schema 回潮。
- BKN 需求发现裁剪方法：`references/bkn-requirement-ontology-discovery.md`，生成场景收敛小结和 `BKN_Creator` 交接摘要前必读，用于把 BKN 方法论转译为 PRD 场景中的对象、事实属性 / 枚举、关系、指标、算子、行动、治理和 Agent 任务表达，防止字段化、报表化、界面化建模。
- FDE 业务访谈方法：`references/fde-method.md`，需要 FDE 式追问方法时读取。
- BKN 需求发现方法：`references/bkn-requirement-method.md`，需要把业务材料整理成 PRD 时读取。
- 质量评分规则：`references/quality-scoring.md`，需要评分、成熟度或推荐路线时读取。
- 访谈问题库：`references/interview-question-bank.md`，需要生成访谈提纲或追问清单时读取。
- 会议纪要处理：`references/meeting-transcript-processing.md`，输入是会议纪要、录音转写或访谈摘要时读取。
- 输出结构参考：`references/output-schema.md`，仅在内部检查结构一致性时读取；PRD 正文不输出机器可读 schema。
- FDE 到 BKN 后置映射：`references/fde-bkn-mapping.md`，仅在 `handoff_mode` 或 PRD 已形成后生成 `BKN_Creator` 交接摘要时读取。

## 模板与案例

- 客户现场短提纲：`assets/interview-brief-template.md`，拜访客户或准备访谈提纲时优先使用。
- 调研准备模板：`assets/research-plan-template.md`，已有客户背景和拜访目标时使用。
- 输入源清单模板：`assets/source-manifest-template.md`，每轮归档输入材料时使用。
- 访谈模板：`assets/interview-template.md`，AI 工程师内部参考，不要求业务专家手工填写。
- 需求文档模板：`assets/requirements-template.md`，输出完整 PRD 时使用。
- 业务验收用例模板：`assets/scenario-test-case-template.md`，补充验收用例时使用。
- BKN_Creator 交接模板：`assets/bkn-creator-handoff-template.md`，输出 handoff 时使用。
- Verifier findings 模板：`assets/verification-findings-template.md`，落盘 `*-verification-findings.md` 时使用。
- 下游 Agent / Skill Card 模板：`assets/downstream-agent-card-template.md`，仅在 PRD 完成后且用户要求设计下游 Agent / Skill 时使用。
- 案例：按领域读取 `references/examples/operations-alert-triage.md`、`references/examples/supply-chain-risk.md`、`references/examples/customer-service.md`，不要批量加载全部示例。