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`，不要批量加载全部示例。