source-intake

流程的阶段零：在建模、写需求文档、做原型之前，先判断手上有什么材料，据此确定后续依据、候选需求范围及待确认缺口。档位不裁剪后续阶段。

方法论基础：《决胜B端》三层业务调研框架（战略层→战术层→执行层）与五环节调研法；《决胜体验设计》第 3 章用户调研的方式与技巧、第 4 章场景与旅程分析。

支持用户显式调用与模型自动触发。

为什么需要这一阶段

后续每个阶段都以「存在一份质量足够的 Oracle」为前提：生成需求文档要有依据，审计要有比对基准，写测试要有预言。这个前提从来不会自己报错——材料缺失时，各阶段照常产出看起来完整的文档，只是那些文档没有判据。

本阶段把这个前提变成一次显式检查。

一条不可绕过的裁定

Oracle 必须存在，且必须是文件。 差别只在它从哪来——用户提供的文档、访谈固化成的确认书、还是从运行中的系统反向工程出的基线。没有 Oracle 的项目不接。

理由不是流程洁癖：口头共识不能被 diff、不能被引用到行、不能在下一轮会话里被核对。而下游三类工作全部依赖"能指到某一行"这件事。

一个必须先说清楚的能力边界

方法论认定最有效的业务理解手段是观摩实习、轮岗、进入作业现场、与业务人员建立信任；单纯阅读文档与手册被明确评价为"非常有限"。某些问题（灰色地带的作业实情）即便一对一深度访谈也拿不到，只能靠长期信任关系。

执行本 skill 的 AI 一项都做不到，只能做结构化提问。

由此得出三条硬约束：

1. 访谈模块的产出是待确认的需求草稿，不是权威需求。
2. 报告中必须声明这一局限，不得让读者以为访谈等价于人工调研。
3. 这条局限本身就是「Oracle 必须存在」最硬的论据——AI 无法用现场调研替代文档，所以文档必须存在。

做不到的事要派给做得到的人

"执行者做不到"是换人执行的信号，不是终点。对一个软件系统来说，在跑的系统本身就是作业现场，而用户进得去。

因此凡是执行者够不着、用户够得着的取证动作，都要具体指派出去，并说明它能替掉哪几条缺口——「请导出一份真实业务数据，这一份能一次回答字段实际取值、取整口径、上游数据形态」这样的指派，比一句"执行者无法现场观摩"有用得多。

材料的能力边界分三层

可达（能否取到）/ 保真（取到了提取得对不对）/ 可用（提取对了能不能当依据）。三层各自会失败，混作一层判会漏——后两层由准入四问的可读性与权威性承接，可达这一层属于部署环境：同一个 skill 装在配了企业文档连接器的环境里就取得到，装在裸环境里就取不到。

输入

• 用户明确纳入范围的材料（目录、文件、导出物）
• 本次要交付的变更范围（哪个模块、哪一期、改到什么粒度）

不主动遍历材料目录。若目标项目已有材料索引，先读索引再按锚点定位。

收材料之前先给交付规格

多数提取缺陷在材料交到手上之前就能避免——开口要材料时一并说明怎么给（格式优先级、平台文档导出、截图里的数字不可引用）。规格见 准入四问执行清单 的可读性一问。

只处理已纳入范围的材料，不自行追链

材料里指向其他文档的引用，不自行去追。遇到指向未提供文档的引用，登记为「断链引用」，列进物料清单请用户补，绝不猜测被引用文档的内容。

理由不只是够不着——交叉引用会让范围爆炸，十几份文档能牵出上百份。所以即便材料全部可达，纳入范围仍然由用户确认。

执行流程

第一步：准入四问

逐问给结论，全部写进《源材料准入报告》。

判据展开见 准入四问执行清单。

完备性要分两维看：广度 × 深度

• 广度 = 材料覆盖哪些模块（一份清单）
• 深度 = 每个模块讲到哪一层（业务流程 / 业务规则 / 字段与取值 / 异常与边界）

每一格记三态：有 / 缺（材料该有却没有）/ 下游（本来就由后续阶段产出）。只有标「缺」的才进深度缺口清单——字段清单、状态机这些是数据建模的产出物，材料没有它们不算缺陷。

深度是最容易出问题的一维，范围蔓延多数由双方对深度理解不同而来。缺口清单把广度与深度分开列，深度缺口落到"哪个模块缺哪一层"。

一致性里最先要做的是统一术语

不同团队对同一个对象的叫法常常不一致。术语不统一时，后面所有的"矛盾"都可能是假矛盾。先对齐术语表，再判断是否真冲突。

第二步：判定档位与变更粒度

这里要判两根轴，缺一根就会算错投入。

• 档位 T0–T3 回答「Oracle 从哪来」
• 变更粒度（系统级 / 模块级 / 功能点级）回答「这次要交付的东西有多大」，决定投入多少人力去问人

粒度由本次要交付的变更决定，与材料的体量无关。一份材料描述了整个子域，不代表这次要做整个子域。

粒度不能只给结论。 信息不足时它会系统性上偏，而粒度取决于变更在目标系统架构里的位置——那是用户知道、执行者不可能知道的信息。因此必须同时输出可逐条否掉的边界：范围内、范围外（含假设理由）、一条具名的前提假设及其不成立时的后果、以及验证该假设的方式。把假设摊开，比把假设猜对更重要。

判定树、粒度判据、输出形态、访谈规模对照见 档位判定。

档位不裁剪后续流程。 每一档都走数据建模 → 需求文档 → 审计，产出多厚随本次变更的大小——一个功能点的数据模型本来就只有几行。档位只决定这些阶段的依据从哪来。

范围收敛用加法与减法两个模型，共同使用而非二选一，起点按档位默认但不写死。两模型的做法、适用与各自风险见 档位判定。

初划可交付的需求范围

逐项覆盖原始输入，整理候选范围及未决交叉依赖，交用户初步确认；建模验证后、生成标准前才确认最终范围。划分判据与共享/集成范围处理见档位判定中的需求范围组织，本阶段不生成标准或宣告交付已验收。

第三步（材料不足时）：结构化访谈

目的是把需求固化成可引用的文件，不是替用户做需求分析。

先定规模，再列问题。 访谈的成本落在真人身上且不可回收，规模由第二步判定的变更粒度决定：功能点级走两次短对话，模块级走战术层与执行层两场，系统级三层完整走。战略层是否入场同样由粒度决定——模块级与功能点级默认不安排场次，因为系统级的战略动因在从零立项时就该定下来了。

安排之前分开判撑不撑得起与值不值得，两条都不成立时降级为一次澄清对话。

三条约束不可让：问题清单分两栏（可从材料或实现回答的、必须问人的），只有后一栏进提纲，且物料先行——先出物料清单，材料到位后再编提纲；每个话题的第一问必须是开放式，把候选答案列成选项只能用在对方已经说过的内容上；"执行者倾向"与默认值同属一类，代价落在使用者或数据主体一侧的问题上一律不给。

判据展开、五步骤骨架、三类对象各问什么、提问顺序、场景还原、数据类必问项，见 结构化访谈指引。

产出《需求确认书》与完备度矩阵——每一项标注三态之一：用户确认 / 执行者推断 / 仍空白。推断项与空白项不得当作已确认内容使用。

第四步（T3）：建立现状基线

1. 产出《现状基线》，每条结论带可信度标签 + 证据指针。
2. 实现是「是什么」的权威，用户是「应该是什么」的权威，既有文档在两方面都不是最高权威。 既有文档仍然可以当证据用，可信度按下表封顶。三方冲突进 UNRESOLVED 交人裁定。
3. 迭代的 Oracle = 基线 + 增量意图。T3 产出的是变更需求文档，审计的是变更的完备性：影响面、兼容性、迁移。
4. 回归防线：T3 下编写测试的 oracle 是基线 + 新需求文档——老行为不许变，不只是让新行为对。

现状证据有梯度，代码是其中最贵的一档

默认路径是文档基线：既有需求文档、原型、页面截图、操作手册组装出现状，再用一份真实业务数据导出做抽样校验——抽样能补上文档天然写不细的那一层（实际取值、取整口径、上游数据形态）。

代码基线是加强档：拿得到实现入口或数据结构时才走，可信度更高。拿不到代码不构成阻塞，多数执行者本来就没有实现的访问权——它只决定可信度封到多高。各来源的可信度上限见基线模板的证据梯度表。

取不到就转成问题，绝不阻塞

先列「要判定这次变更，需要知道哪些现状」，再逐项标 能自取 / 要问人 / 无从获得：能自取的先取，要问人的进访谈清单，无从获得的进 UNRESOLVED。任何一格都不会让流程停下来。

代价要落账，不能假装没有影响：可信度按上表封顶、回归防线清单会变薄且薄的地方要点名、没能验证的部分写进基线的「未覆盖区域」。

第五步：输出与交付

可信度四级的定义与各级可陈述强度见 可信度分级。

输出规范

四份模板随本 skill 一同分发，位于 templates/。模板取不到时不阻塞——按上表的「内容」列自行组织，并在产出中注明"未套用模板，格式未经校验"。

缺口清单与物料清单是两样东西，都要给。 缺口清单说的是知识上缺什么（「异常与边界整层缺失」），用户看完知道有问题却不知道该做什么；物料清单说的是请你去拿哪几份东西，每一项带三样：能替掉哪几条缺口、优先级、拿不到的退路。第三样必须有，否则清单会把流程变成阻塞。

后续阶段不得手工遍历材料目录，一律经《源材料索引》按锚点定位。这条规则的目的是让"材料从哪来"始终可追溯，且让索引成为唯一需要维护的入口。

停机条件

同时满足才算完成：

1. 四问全部有结论，缺陷与降级已登记
2. 档位判定完成，且已交用户确认
3. UNRESOLVED 清单交用户裁定完毕
4. 《源材料索引》可用
5. 候选需求范围覆盖原始输入，初步边界、交叉依赖及未决取舍已交用户确认；未决处保留，不代用户定稿

停下交用户：同一个缺口追问两轮仍无答案，或材料补交后四问结论仍不变——不再追问，登记为缺口交用户裁定是否带缺口进入下一阶段。

执行者不得自行宣告准入通过。 准入结论是呈给用户裁定的证据，不是执行者的判断结果。

用户确认用最轻的形式。 口头确定，或在报告中标注确定，即视为 CONFIRMED。这是一个辅助工具，无权要求使用者承担形式化的责任——过重的仪式换不来更可靠的确认，只会让这一步被跳过或敷衍。

放轻的是请用户做什么，不是告诉用户什么。 材料里的错误、不确定、缺漏，一律严肃直白地列出来，一条都不省。

领域扩展

领域特有的准入判据（某领域惯常缺哪一层、该领域材料的典型权威度分布、必问的领域字段）放 references/providers/<domain>/，不改本文件。本轮未附带任何领域 Provider。