BitFun 子模块设计：需求影响分析
July 7, 2026 · View on GitHub
上游文档：design.md 模块角色：在需求、验收标准、API 契约、设计决策、发布或事故场景中，召回受影响的代码、测试、文档、负责人、发布和运行指标候选。
1. 模块定位
需求影响分析服务复杂项目和高风险生命周期场景。用户处理 spec/API/发布/事故，或配置化策略判断变更可能影响多个工程资产时，本模块给出候选影响面、置信度、证据和验证建议。
它输出候选集合；高风险、低置信链接进入人工确认队列，确认或拒绝结果写回 交付物图谱，用于后续校准。
快速路径下，本模块以摘要中的下一步建议呈现，例如“可能需要需求/影响确认”。
2. 行业参照与设计约束
| 参照 | 启发 |
|---|---|
| TraceLLM | LLM 可辅助建立轨迹链接，但需要人工确认和持续校准 |
| LLM-driven requirements change impact analysis | 影响分析应衡量召回、精度和人工检查成本 |
| Rovo acceptance criteria 检查 | PR 可检查代码是否满足关联工作项的验收标准 |
| Kiro Specs | spec 应作为 AI 原生交付物参与实现、测试和追踪 |
| MBSE traceability | 复杂系统中需求、模型、验证之间需要结构化追踪 |
设计约束：
- 已确认关系和显式 issue/spec 链接优先于纯 LLM 语义召回；完整图谱优先召回从最小图谱具备后再启用。
- 项目画像必须说明项目结构、负责人、验证能力和未知区域。
- 高风险低置信影响项必须人工确认。
- 输出必须包含信心、证据、推荐/强制检查和残余风险。
- 确认/拒绝结果必须反馈到交付物图谱。
- 普通 PR 默认使用轻量变更就绪度；影响分析由 spec/API/发布/事故或高风险信号触发。
3. 范围与边界
范围：
- 识别变更需求、验收标准、API 契约、设计决策、发布/事故信号。
- 从交付物图谱、代码图谱、静态依赖、历史记录和 LLM 语义扩展召回候选。
- 生成推荐/强制检查和人工确认清单。
- 为发布就绪度和事故到测试回归提供候选关系。
边界：
- 需求管理工具保留系统主权，BitFun 只读取、链接和投影影响候选。
- 影响面以候选、置信度和证据表达，完整性通过人工确认和后验反馈逐步校准。
- 本模块生成建议和候选关系，代码或测试修改由任务执行链路处理。
- 低置信 LLM 推断进入候选状态，通过/就绪依据来自确认关系、验证证据和策略。
- 质量保障要求较低的任务只显示轻量下一步建议。
4. 输入、输出与数据模型
输入：
| 输入 | 示例 |
|---|---|
| 需求差异 | issue 描述、验收标准、spec diff |
| 项目画像 | 模块边界、负责人、验证能力、未知区域 |
| API 契约变更 | DTO、Tauri 命令、MCP 工具结构、OpenAPI |
| 交付物图谱 | requirement -> spec -> diff/test/审查链接 |
| 代码图谱 | 文件、符号、导入、测试 |
| 历史记录 | 历史事故、审查问题、不稳定测试 |
| 运行期信号 | 事故、指标、轨迹/日志链接、告警 |
| 人工提示 | 负责人、模块、风险标签 |
输出：
interface ImpactCandidate {
artifact_id: string;
artifact_type: string;
confidence: number;
evidence: EvidenceReference[];
reason: string;
recommended_checks: RequiredCheck[];
required_checks: RequiredCheck[];
confirmation: "required" | "optional" | "not_required";
residual_risk?: string;
user_visible_mode: "hidden_hint" | "summary" | "review_queue" | "release_gate";
}
5. 核心流程
检测明确的 spec/API/发布/事故触发
-> 分类变更类型和风险
-> 加载项目画像和未知区域
-> 召回显式 issue/spec 链接和已确认关系
-> 通过静态依赖和历史记录扩展
-> 按需进行 LLM 语义扩展
-> 按置信度、风险和检查成本排序候选
-> 生成检查和确认队列
-> P2+ 将确认/拒绝结果写回交付物图谱
召回策略：
| 策略 | 作用 |
|---|---|
| 显式链接优先召回 | 使用关联 issue/spec、用户提供的验收标准和已确认关系 |
| 图谱优先召回 | P3+ 使用已确认需求、spec、文件、测试和审查链接 |
| 静态扩展 | 通过导入、符号引用和测试映射扩展 |
| 历史扩展 | 结合事故、审查问题、不稳定测试和热点文件 |
| LLM 语义扩展 | 在语义相似但无结构链接时生成候选 |
6. 显露策略
| 场景 | 行为 |
|---|---|
| 快速路径普通改动 | 不展示影响分析；最多进入下一步建议 |
| PR 就绪度且有关联 issue/spec | 展示摘要级候选和推荐检查 |
| 高风险 API/schema/契约变更 | 进入审查队列，要求人工确认关键候选 |
| 发布就绪度 | 未确认高风险候选进入残余风险 |
| 事故回溯 | 输出事故到测试回归候选 |
治理规则：
- 置信度分层：已确认链接 > 静态依赖 > 历史共同变更 > LLM 候选。
- 人工确认：高风险低置信候选进入确认队列。
- 反向学习：确认、拒绝、遗漏项都写回图谱和评测待办。
- 门禁集成：未确认的高风险候选不能直接通过；可进入降级状态或残余风险。
- 成本控制：优先使用图谱和静态分析，LLM 语义扩展只处理候选不足或歧义场景。
7. 分阶段落地
| 阶段 | 目标 |
|---|---|
| P0 | 不作为默认能力；只保留数据模型和隐藏提示 |
| P1 | PR 关联 issue/spec 的摘要候选和推荐检查 |
| P2 | 显式链接优先影响视图、静态依赖扩展、确认队列 |
| P3 | 图谱优先召回、发布就绪度、事故到测试回归、LLM 语义候选 |
| P4 | 精度/召回校准、长期需求追踪质量指标 |
8. 风险与反证
| 风险 | 反证或治理要求 |
|---|---|
| 影响分析拖慢普通开发 | 快速路径不展示、不阻塞 |
| 高召回导致低价值候选过多 | 输出必须排序，并显示人工检查成本 |
| 高精度导致漏项 | 对高风险区域保留低置信候选和降级状态 |
| LLM 语义幻觉 | LLM 结果只能作为候选，需要证据和确认 |
| 影响面过期 | 图谱边需要新鲜度；diff、测试或审查变化触发更新 |
| 与就绪度脱节 | 每个高风险候选必须映射检查或残余风险 |
| 团队不确认链接 | 确认动作必须嵌入 PR 审查、发布或事故流程 |
9. 成功标准
- 普通任务只接收轻量下一步建议。
- 明确需求或 API 变更能生成可解释影响候选。
- 高风险候选有人工确认路径。
- 确认/拒绝结果写回交付物图谱。
- 强制要求/推荐检查能覆盖主要影响类别。
- 精度、召回、人工检查成本和误打断率可量化。