需求接收助手（sdlc-intent）
两段式：第一段梳理建立对需求的共识理解，第二段体检尽早暴露需求缺陷。梳理是体检的前提——先与用户对齐理解，再找问题。
前置依赖：python3（parse_doc / scan_refs / resolve_anchors，纯标准库）；飞书输入用 lark-cli（未安装/未登录或权限不足时，按「输入读取」降级为本地文件或文本）。
选择工作流
用户说「评审 / 梳理 / 找问题」时先确认宾语：对象是需求文档才进本 skill；是设计/用例走 sdlc-gate，是技术方案走 sdlc-doubt，是上线前检查走 sdlc-release-check。
按用户意图选择分支：
- 用户说「梳理需求 / digest / 理解需求」，或首次给出需求文档 → 只跑【第一段：需求梳理】，跑完暂停
- 用户说「体检 / 需求评审 / 给需求找问题 / review」→ 跑【第二段：需求体检】；若已存在梳理文档（
sdlc/*/intake/digest-*.md）优先复用，不存在则提示先梳理 - 复用梳理文档前强制版本校验：体检本身要重新读取原文，读取后将本次原文的版本/修订时间与梳理文档头「版本」字段比对——一致 → 直接复用；不一致 → 告知用户「原文已从 vX 更新至 vY，梳理文档基于旧版」，建议重梳理（用户明确说沿用才沿用）；原文无版本信息时，向用户展示梳理文档的梳理日期，请其确认原文是否有更新
- 用户只给文档未指明 → 两段连跑：梳理完成后暂停，向用户展示摘要并提示「请确认或补充业务理解，完成后说“继续体检”」，得到确认再跑体检
- 用户要求「开始开发 / 拆任务 / 写代码」时：先走 sdlc-gate 的开发请求入口；未过 gate 先停，见「下一步（流程衔接）」
输入读取
- 飞书链接（feishu.cn / doubao.com 的 /docx/、/wiki/）：
lark-cli docs +fetch --doc "<URL>" --doc-format markdown（权限不足时向用户说明，不要反复重试） - 原文预处理（仅飞书输入；正文与评论读取后执行一次）：拉取块级 XML（
lark-cli docs +fetch --doc "<URL>" --doc-format xml --detail with-ids），运行scripts/parse_doc.py产出sdlc/<需求名>/intake/doc-<YYYYMMDD>.json与 media/ 目录（输入提取、命令行、块模型、条款级出处、锚点附加与失败回退详见 references/doc-pipeline.md）；parse_doc 内置内容守恒门（conservation-v1，exit 2 = 产物与原文不一致、未落盘、不得回传），doc.json 顶层带guard供平台落库终检；doc.json 存在时，梳理/体检出处尽量写到条款级（「详述N·<小节名>」/「详述N·<序数>」）；解析失败不阻塞梳理（平台回退文本定位） - 飞书链接在读取正文后必须同步读取评论区：
lark-cli drive +list-comments --url "<URL>" --solved-status all --comment-scope all --need-relation --format json（权限不足时同样只向用户说明一次、不重试，正文流程照常继续） - 评论区是正文的补充信息源，正文外的关键决策/变更说明/答疑常在评论区；评论结论与正文不一致时以最新评论为准。本地文件输入或评论数为 0 时记「无评论」，权限不足记「未读取（原因）」，均如实写入梳理文档头「评论区」字段
- 本地 markdown/text 文件：直接 Read
- 文档内嵌表格已随正文返回；若正文出现
<sheet>/<bitable>引用且与核心流程相关，用 lark-sheets/lark-base 下钻读取（有权限时） - 正文出现内嵌附件块（
<figure ...><source ... token="...">）且为原型/演示文件（html 等）时，必须下载读取：lark-cli docs +media-download --token "<token>" --output <本地路径>——markdown 拉取后附件只剩一个自闭合标签，不下载则原型功能面信息完全缺失（原型有而正文无的功能是体检高价值线索）。html 原型体量大（可达数百 KB），只提取结构（页面/导航/弹窗/字段/操作）入上下文，不全量读取。下载失败记「未读取（原因）」写入梳理文档头「原型附件」字段，同评论区口径不重试。原型结构仅供体检阶段交叉核对，不并入梳理功能地图——梳理仍忠实正文+评论区 - 原文内容（正文 + 评论区 + 原型附件）在后续体检阶段还要反复引用，梳理时先在本地留存原始内容（如
/tmp/下临时文件；评论 JSON、正文 markdown、原型文件分开存放） - 变更单增量梳理：变更单 confirm 后的受影响章节局部重检规范见 references/incremental-guide.md（增量包结构、作废清单、anchor 越界纪律；平台侧执行，sdlc-sync 推送时消费）
第一段：需求梳理
复制此 checklist 跟踪进度：
梳理进度： - [ ] Step 1: 通读原文，提取角色与术语 - [ ] Step 2: 按 references/digest-template.md 生成 8 区块梳理文档 - [ ] Step 3: 落盘 sdlc/<需求名>/intake/digest-<YYYYMMDD>.md - [ ] Step 4: 终端展示摘要（含风险分级提议）+ 暂停等待用户确认与分级拍板
Step 2 是核心：读取 references/digest-template.md，严格按模板 8 区块产出，功能地图、流程图、状态机、规则表必须图表化（markdown 表格 + mermaid）。
梳理纪律（违反即返工）：
- 忠实转述原文，不评价、不脑补、不优化——评价是体检阶段的事
- 原文缺失的流转/触发/字段，用 🤔 标注，禁止自行补全
- 对模糊内容的个人理解，逐条记入「假设清单」区块（编号 + 原文位置 + 按 X 理解），并标注类型（推断 = 有原文推导链 / 假设 = 无依据拍板）
- §7 关键规则逐条编 FR 号、状态机图每条流转须有原文出处——编号与出处纪律详见 digest-template 标注约定（FR 编号稳定性、ID 命名空间、评论区判定口径均以模板为权威）
Step 3 落盘路径：当前项目 sdlc/<需求名>/intake/ 目录（不存在则创建），文件名 digest-<YYYYMMDD>.md。
Step 4 暂停：展示各区块摘要（尤其 🤔 集中处和假设清单）与风险分级提议——按 references/risk-tiering.md 评分卡给出 A/B/C 提议+影响面命中依据（拿不准从高，降级需附可核对证据），明确说「请确认或补充业务理解，并对风险分级拍板，完成后说“继续体检”」；拍板后将 digest 头「风险分级」的确认改为日期，然后停止等待。
第二段：需求体检
分级路由（Step 1 时判读）：读 digest 头「风险分级」字段——A 级全阶段跑（阶段0+阶段1+七层）；B/C 级跳过阶段1（视角推导），主会话顺序跑。无该字段（存量文档）= 未分级 = 按 A 级处理并提示补标。判定结果写入体检报告执行摘要首句。分级判定与回写规则见 references/risk-tiering.md。
复制此 checklist 跟踪进度：
体检进度： - [ ] Step 1: 准备输入（原文 + 梳理文档，含用户补充）+ 分级路由（读 digest 头风险分级，缺失按 A 级） - [ ] Step 2: 阶段0 参照系构造——按 references/ref-tables.md 产 refs-<日期>.md（可先跑 scripts/scan_refs.py --mode seeds 供料，构表后 --mode verify 校验） - [ ] Step 3: 阶段1 视角推导（仅 A 级）——按 references/perspectives.md 扇出实现者/测试者推导，产出 D2 候选 - [ ] Step 4: 按 references/dimensions.md 七层维度逐层检查（第 7 层汇流 D1/D2/D3 候选做语义判定） - [ ] Step 5: 按 references/report-template.md 产出体检报告 + PM 确认清单（命中带来源标注） - [ ] Step 6: 终端摘要（各级问题数 + 阻断项列表） - [ ] Step 7: 交互收尾（用户逐条回应后回写梳理文档）
Step 2（阶段0·参照系） 读取 references/ref-tables.md：从梳理产物构造四张参照表（数据字典/指标字典/平行结构矩阵/引用图，按触发特征裁剪），落盘 sdlc/<需求名>/intake/refs-<YYYYMMDD>.md。表中空格、断链、⚠️冲突格即缺失类候选，交给 Step 4 做语义判定；某张表构造不出来本身也是信号，如实记录。可选机械辅助：python3 scripts/scan_refs.py --mode seeds --doc <原文|doc.json>（构表前产断链/并列章节 seed）、--mode verify --doc <原文> --refs <refs.md>（构表后产字段出现位置清单——有录无消的证据义务、机械候选与计数核对）；脚本不可用或输入不含时跳过，不阻塞。
Step 3（阶段1·视角推导，仅 A 级） 读取 references/perspectives.md：以实现者/测试者身份执行推导任务（产出数据流草图/断言草稿，缺陷是推导副产品），用 Agent 工具扇出全新上下文子代理（喂料纪律：只喂任务卡+模块切片+相关表行，不喂全文）；候选按收敛纪律（反向锚点/不与 D1 重复/待裁决只追问）回主会话，标 D2。
Step 4（七层核对） 读取 references/dimensions.md，按层序检查：概念层最先（术语表是后续所有检查的基准），第 7 层外部参照层最后——汇流阶段0 候选（D1）、阶段1 候选（D2）与本层推导（D3）做语义判定与统一分级。该文件定义了每个检查项的命中标准与严重度；规则类/决策类命中按其「决策类型标注」规则在报告类型列标 C 约束 / H 假设（初判带问号）。
体检纪律：
- 每条命中必须附原文定位（章节名 + 关键引文片段），禁止脱离原文泛泛而谈；缺失类无引文可引时按「全文未见 X」问式（见 report-template 撰写规则）
- 七层维度是启发式锚点而非封闭清单：发现维度外的问题也应记录，标注维度为「补充」
- 严重度从严不从宽：拿不准阻断还是严重时，标高一级并在描述中说明（第 7 层例外见 dimensions.md）
- 冲突不裁决：构表或层间检查撞到的口径冲突一律记命中交 PM 裁决，禁止静默择一
Step 5 读取 references/report-template.md，产出两个文件到 sdlc/<需求名>/intake/：
audit-<YYYYMMDD>.md（五章结构：执行摘要/阻断速览/分层明细/主题关联/状态汇总——唯一的成段文字在执行摘要，其余表格化）pm-checklist-<YYYYMMDD>.md（可直接整篇复制发给产品经理的确认清单）
两个文件产出后，必须按 report-template.md 的「终检」清单核对（统计表重数 / 跨文件计数一致 / 主题组关联核对），通过后才进入 Step 6。
Step 7 交互收尾：引导用户对每条问题回应「问 PM」/「按假设 X 处理」/「忽略」；有结论后将其回写至梳理文档的假设清单，形成共识版。用户不想逐条过时直接结束，不强制。
下一步（流程衔接）
- A/B 级：intake 确认后 →
/sdlc-design <需求名>与/sdlc-test cases <需求名>并行独立产出 →/sdlc-gate <需求名>；gate 放行前不写业务代码。 - C 级：
/sdlc-design <需求名>产一页design/plan.md→/sdlc-gate <需求名>C 档主会话自查 → 人工确认放行后开发。 - 用户直接要求开发：先走 sdlc-gate 的开发请求入口；未过 gate 先停，不得把梳理/体检完成当作放行。
边界
- 本 skill 只处理需求文档本身，不读代码库、不做技术设计（设计属后续任务）
- 体检只审需求本身的质量，不评估技术方案的合理性（方案合理性属后续技术设计评审范围）
- 一次处理一份需求文档；多份文档时请用户明确主文档
- 产出语言跟随需求文档语言（中文文档产出中文）
