bkn-requirement

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

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 内的该文件，不依赖仓库中的其他目录。

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

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

正式输出执行主线是：

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

项目目录与命名规范

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

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

每轮输入材料应归档到：

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 中记录路径。

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

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。

# 《<场景名> 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，不要批量加载全部示例。