Retrospective Requirements Analysis

导言

在 AI 开发中，新模型、新算法和新高性能技术经常先以原型、算子替换或小范围穿刺的方式完成验证，正式需求分析却落在后面。此时公司流程仍需要一份完整报告，但任务不应是把代码包装成一段“当时早已想清楚”的故事，而应是从需求片段、代码、测试、实验和运行证据中，回溯一条可审计的决策链。

这篇文章给出一套八阶段方法：从立项边界和证据基线开始，依次重建干系人、场景、根因、需求、质量属性、AI 评测、方案权衡、风险、验收与双向追踪。每个阶段都明确输入、方法、输出和评审门，并把事实、推断、假设、决策和缺口分开记录。

最终目标不是“文档齐了”，而是让审查者能够回答：为什么做、为谁做、解决什么、做到什么程度、为什么选这条技术路线、哪些证据已经验证、哪些仍需责任人确认。

{ width=90% }

自绘小黑认知锚点：已经存在的代码、测试和日志不是“需求原文”，分析者需要把它们回缝到目标、需求、决策和验收，同时把无法证明的部分单独挂成待确认项。

问题不在补文档

“新技术出现就是明确需求”只说对了一半。新技术首先是一个 机会信号：它说明某种能力现在可能可行、成本可能下降，或旧瓶颈可能被绕开；但它还没有回答谁会因此受益、现状损失是多少、应改善到什么程度、哪些边界不能破坏。

一条完整链路应当是：

新模型 / 新算法 / 新算子
  -> 新可行能力或新性能上限
  -> 目标用户的具体场景与当前差距
  -> 可衡量的业务或工程结果
  -> 系统行为、质量、接口与约束要求
  -> 技术方案、验收证据与运行结果

需求分析和技术洞察因此不能混写成同一章“大背景”：

视角	核心问题	典型证据	主要输出
需求分析	为什么做、为谁做、解决什么、做到什么程度	用户流程、事故/工单、业务数据、使用场景、约束	目标、需求规格、验收、优先级、边界
技术洞察	旧技术为何不够、瓶颈在哪、有哪些路线、为何选当前路线	代码、调用链、Profiling、基准、论文/标准、PoC	瓶颈判断、候选方案、权衡、风险、技术决策
反向补全	已实现结果能证明什么、还缺什么、如何恢复决策链	变更集、测试、实验、日志、历史文档、责任人确认	证据账本、推断需求、缺口、追踪矩阵、评审结论

ISO/IEC/IEEE 29148:2018 把需求工程放在完整生命周期中，并规定了需求过程产生的信息项、内容和格式指导。ISO 页面显示该版本在 2024 年确认有效、2026 年进入待修订阶段；因此本文以它作为当前公开基线，但不会把下面的本地模板冒充标准条款逐项合规。

禁止事后合理化

代码能证明系统当前做了什么，测试能证明某个断言在某个环境下通过，基准能证明某组受控条件下的测量结果；它们都不能单独证明原始业务动机、历史决策过程或用户价值。缺少的历史必须标成推断或待确认，不能因为报告需要完整就补成“事实”。

证据优先的回溯模型

反向需求分析的核心动作不是写，而是 分类、连线和暴露缺口。先把输入分成五类陈述：

标签	含义	例子	允许的写法
[F] Fact	可直接回指版本、运行或责任人记录的事实	commit abc 增加 BF16 分支；测试在指定环境通过	陈述事实并附证据 ID
[I] Inference	由多个事实支持、但不是原始记录的解释	分支与基准共同表明主要目标可能是降低长序列显存	写出推理链和置信度
[A] Assumption	报告成立所依赖、尚未确认的前提	目标用户接受回退路径 5% 的性能损失	指定确认人和失效后果
[D] Decision	已确认选择及其后果	采用新算子，保留旧路径作为 fallback	记录责任人、理由和重审触发器
[G] Gap	缺失、冲突或不可复现的证据	没有上线前业务基线；两个文档阈值冲突	放入摘要和阻塞清单

置信度与标签是两条轴：代码事实可以是高置信度，却仍然不能证明业务动机；跨代码、测试和日志一致得到的推断可以是中置信度，但仍需业务责任人确认。

五种机制视图

下面五种视图共同解释“反向补全”如何工作。第一张小黑图看 物理前后变化：碎片证据被缝成链，但未知项不被塞进链里。接下来的图分别看因果、流程、组件协作和数据追踪。

flowchart TB
  subgraph B["B. 因果逻辑"]
    B1["先实现后补文档"] --> B2["原始理由与边界缺失"]
    B2 --> B3["版本化证据 + 分层推断"]
    B3 --> B4["可审计需求基线"]
    B3 --> B5["新增成本：取证、确认、追踪"]
  end

  subgraph C["C. 执行流程"]
    C1["圈定变更"] --> C2["收集证据"] --> C3["重建目标与场景"]
    C3 --> C4["派生需求与质量指标"] --> C5["回溯决策与风险"]
    C5 --> C6["验收与双向追踪"] --> C7["评审基线"]
  end

sequenceDiagram
  participant O as 需求责任人
  participant A as 分析者
  participant R as 代码与证据库
  participant V as 测试/评测系统
  participant P as 运行环境

  A->>R: 固定 commit、路径、配置与历史材料
  R-->>A: 返回版本化事实和冲突
  A->>V: 复核断言、基线、环境和结果
  V-->>A: 返回可重复验证及证据边界
  A->>P: 对照真实场景、监控和事故
  P-->>A: 返回运行结果与未覆盖状态
  A->>O: 提交推断、假设和最小确认问题
  O-->>A: 确认目标、阈值、权衡或保留缺口
  A->>A: 生成需求、决策、风险与追踪矩阵

flowchart LR
  subgraph E["E. 证据数据流"]
    E1["E: 代码/测试/日志/文档"] --> C1["C: 事实/推断/假设"]
    C1 --> S1["S/P: 干系人与场景"]
    S1 --> R1["R/Q: 需求与评测合同"]
    R1 --> D1["D/K: 决策与风险"]
    D1 --> V1["V: 测试/评测/运行结果"]
    V1 --> T1["T: 双向追踪"]
    T1 --> O1["O: 报告基线"]
    T1 --> G1["G: 孤儿项与待确认"]
  end

组件时序要注意对象生命周期：代码、测试、日志等原始证据保持不变；分析者生成的主张、需求和追踪关系可以迭代；责任人的确认不会改写过去，只会改变假设的当前状态。

对象账本

对象	标识	生产者	消费者	生命周期
版本化证据	evidence / E-*	仓库、测试、实验、日志、访谈	主张提取、追踪	原始记录不可改写
主张	claims	对证据的读取与解释	目标、需求、缺口	带 [F/I/A/D/G] 和置信度
场景与干系人	scenarios, stakeholders	场景/JTBD/ConOps 分析	目标与需求	可被责任人确认或否决
需求与评测合同	requirements, quality_contracts	目标、场景、接口和质量分析	决策、代码映射、验证	建立基线后受变更控制
决策与风险	decisions, risks	权衡分析和责任人选择	实现、发布、监控	保留后果和重审触发器
验证与追踪	verifications, trace_rows	测试、评测、运行测量、链接审计	评审与报告	每次变更后重新生成覆盖状态
缺口	gaps	冲突、缺证和孤儿审计	责任人确认与审批	直到解决或显式接受

完整伪代码

INPUT:
  implemented_change
  repository
  verification_artifacts
  runtime_artifacts
  stakeholder_materials

scope = freeze_scope(implemented_change, repository)
evidence = inventory(scope, verification_artifacts,
                     runtime_artifacts, stakeholder_materials)

claims = []
gaps = []
for artifact in evidence:
    observed_claims = read_behavior_and_results(artifact)
    for claim in observed_claims:
        claim.source_id = artifact.id
        claim.kind = classify_as_fact_inference_assumption_decision_or_gap(claim)
        claim.confidence = grade_confidence(claim, evidence)
        claims.append(claim)

gaps.extend(find_conflicts_and_missing_sources(claims, evidence))

stakeholders = reconstruct_stakeholders_and_jobs(claims)
scenarios = reconstruct_normal_boundary_failure_recovery_scenarios(claims)
goals = derive_owner_measurable_goals(stakeholders, scenarios, claims)

requirements = derive_business_user_function_quality_interface_constraint_requirements(
    goals, scenarios, claims
)
quality_contracts = define_measurement_environment_threshold_and_owner(requirements)

decisions = reconstruct_evidenced_options_and_tradeoffs(claims, requirements)
risks = derive_failures_controls_rollout_monitoring_and_rollback(
    requirements, decisions, claims
)
verifications = read_test_eval_and_runtime_oracles(
    verification_artifacts, runtime_artifacts
)

trace_rows = link_bidirectionally(
    goals, stakeholders, requirements, decisions,
    scope.implementation, verifications, runtime_artifacts
)
gaps.extend(find_orphan_and_unverified_nodes(trace_rows))

blocking_questions = select_smallest_owner_questions(gaps)
owner_answers = obtain_or_record_unavailable(blocking_questions)
apply_answers_without_rewriting_history(owner_answers, claims, requirements, decisions)

trace_rows = rebuild_trace_rows_after_answers()
gaps = rebuild_open_gap_list(trace_rows, claims)
report = render_report(scope, evidence, claims, stakeholders, scenarios, goals,
                       requirements, quality_contracts, decisions, risks,
                       verifications, trace_rows, gaps)
validate_report_quality_and_evidence_boundaries(report)

OUTPUT:
  report
  open_gaps
  owner_questions

这套机制适用于已经存在可定位实现和至少一种验证证据的功能。如果连变更范围或任何验证都无法确定，只能先做证据搜集，不能直接生成“完整报告”。它改变的是决策链的 可见性与可追踪性，不会改变代码事实，也不会自动补回真实历史；新增成本是取证、责任人确认和持续维护追踪关系。

阶段一：立项与证据基线

第一阶段先冻结分析对象，而不是先写“项目背景”。至少要记录特性名、产品层级、代码仓、分支、HEAD、提交范围、相关配置、实现时间窗、报告证据截止时间，以及明确不在本次分析中的模块。

必要方法是变更集框定和证据清单。对 Git 变更读取提交、文件、符号和调用路径；对测试读取实际断言和结果；对基准记录模型、数据、硬件、软件、精度、并行配置、预热、重复次数与测量窗口；对日志记录时间、环境和采集完整性。

证据 ID 应按来源分组，例如 E-CODE-001、E-TEST-001、E-BENCH-001、E-OPS-001、E-BIZ-001。每条证据同时写“证明什么”和“不证明什么”。后者能阻止分析者从“有一个性能测试”跳到“用户明确要求提升性能”。

输入	方法	输出	评审门
已穿刺需求、代码/PR、测试、实验、日志、历史文档	文档分析、Git/代码考古、调用/数据流阅读、受控复现	范围基线、证据账本、冲突和缺证清单	关键主张有证据 ID；范围和至少一个验证可定位

先固定再解释

如果实现仍在变化，先固定一个 commit 或发布版本。否则需求、代码和测试三者持续漂移，追踪矩阵会在写完前失效。

阶段二：目标与干系人

第二阶段把“技术可用”转成“谁在什么情况下得到什么进展”。干系人至少包括业务/项目赞助者、直接用户、平台调用方、运维、维护者、测试、数据/安全/合规责任人和被下游变更影响的团队。

Stakeholder Map 用于找角色、影响和决策权；Jobs to Be Done（JTBD） 用于避免把用户提出的实现手段当成真实任务。一个可确认的表达是：

当 <触发条件> 出现时，<角色> 需要 <完成某种进展>，
从而 <获得可衡量结果>，同时避免 <不可接受后果>。

例如，“接入新的长序列 Attention 算子”不是完整工作目标。更接近需求的是：“当训练任务使用指定模型、精度和长序列配置时，训练工程师需要在现有硬件预算内完成训练，并保持数值误差、稳定性和回退能力在批准边界内。”

再用 问题树—目标树 把结果分层：业务或工程结果是顶层目标，用户完成的工作是中层能力，系统行为是下层要求。不要反过来按代码模块组织目标，否则报告会变成模块说明书。

本阶段输出干系人表、JTBD/场景陈述、当前绕行方式、反事实后果和目标指标。评审门是：每个主要目标有场景、责任人、可观察结果和确认状态；业务材料缺失时，应将目标标成 [I] 或 [G]。

阶段三：场景与根因

第三阶段重建改动前系统如何运行。使用 Concept of Operations（ConOps，运行概念） 或场景分析，覆盖正常、边界、失败、恢复、维护和退役状态。NASA 的系统设计指南强调，ConOps 描述系统在生命周期中如何运行以满足干系人期望，技术需求还要覆盖输入、输出、约束以及人和外部系统的交互。NASA Systems Engineering Handbook

过程复杂时，按问题选择视图：泳道图看责任交接，状态机看对象状态，时序图看消息顺序，DFD 看跨边界数据，代码调用链看实现控制流。不要用一张图同时声称业务流程、运行时序和代码实现都已经解释清楚。

根因分析可以用 5 Whys 或问题树，但必须在证据断点处停下。复杂 AI 系统很少只有一个线性根因；模型结构、数据分布、算子支持、内存生命周期、通信、调度和运维配置可能共同形成瓶颈。

存在多个解释时，改用假设驱动分析：

假设	区分性证据	可支持结论	不能支持
峰值主要来自激活	同配置内存快照、序列长度扫描、生命周期图	主要峰值项和近似缩放方向	用户为什么要长序列
新算子是性能提升主因	同机同版本 A/B、调用命中、Profiler	指定环境的算子贡献	全场景或其他硬件收益
兼容问题来自 Shape 分支	失败样本、分支条件、回退日志	特定输入触发机制	所有兼容问题根因

本阶段输出 As-Is 场景、问题影响、原因链、被证伪假设和仍待验证项。评审门是明确区分症状、直接原因、系统性原因和假设。

阶段四：需求与系统边界

第四阶段把目标和场景转成可评审需求。建议使用稳定 ID，避免所有内容都叫“需求”：

类型	ID	回答的问题	例子
业务需求	BR-*	为什么值得做	降低训练资源成本或缩短问题定位周期
用户需求	UR-*	用户要完成什么工作	工程师能在约束配置下完成长序列训练
功能需求	FR-*	系统必须做什么	支持路径命中新算子，不满足条件时回退
质量需求	QR-*	做到什么程度	性能、精度、可靠性、安全、可维护性阈值
接口需求	IR-*	如何与外部交互	输入 Shape、dtype、配置、错误码、版本兼容
约束	CON-*	哪些条件不可突破	不修改模型 API、限定硬件、离线可用、开销上限

Context Diagram + Use Case + Functional Decomposition 是这一阶段的核心组合：上下文图先划清系统控制边界；用例写参与者、前置、主流程、异常和后置；功能分解按用户能力拆成可验证行为，而不是按源码目录拆。

每条规范性需求只承载一个必要行为或约束，并同时记录理由、来源、优先级、责任人和验证方法。诸如“系统应高性能、稳定、易用”不是可验收需求。

NASA 的技术需求定义强调从干系人期望转成经验证的技术要求，并保持输入、输出、关系、约束和交互完整；这也解释了为什么仅从函数签名反推需求必然漏掉运营和人机边界。

本阶段还要主动查异常流：无效输入、部分失败、超时、重试、降级、回退、兼容、升级、观测和清理。评审门是正常与异常路径要么有需求，要么被明确列为非目标。

阶段五：质量属性与 AI 评测

功能正确不等于需求完整。质量属性需要写成 质量属性场景：

刺激来源 -> 刺激 -> 环境 -> 受影响对象 -> 系统响应 -> 可测量阈值

例如：“在支持的模型、BF16 精度和指定序列区间内，当训练任务命中新算子路径时，系统应保持输出误差不超过责任人批准阈值；遇到不支持的 Shape 时，在不改变公开 API 的情况下回退并产生可检索告警。”其中阈值、区间和告警字段都必须有责任人或证据来源。

ISO/IEC 25010:2023 提供九类产品质量特征，可用于需求完整性、设计/测试目标、验收和测量审查。实际报告应按场景裁剪性能、可靠性、安全、兼容、交互/易用、可维护、灵活/可移植与安全性等维度，而不是把标准名词全部复制一遍。

AI、模型、算法和算子需求还需要一份可复现的评测合同：

维度	必须记录
任务边界	目标场景、目标人群/数据分布、明确排除项
版本与来源	模型、数据、代码、权重、许可证和供应链来源
对照条件	baseline/candidate、硬件、软件、精度、并行、seed、采样参数
测量协议	预热、重复次数、统计口径、失败样本、时间窗
指标分层	能力指标、系统指标、业务结果指标、护栏指标
回归与安全	允许方差、回归预算、失败分类、人类接管、fallback
生命周期	上线监控、漂移、事件响应、变更管理和退役

{ width=88% }

自绘小黑认知锚点：穿刺成功只是一个脆弱结果，只有补上基线、环境、阈值、回退和责任人，才会变成可复现的验收合同。

一个穿刺结果只有在环境和阈值所有者被固定后，才能升级为验收条件。否则它只是 E-BENCH-* 证据，不是规范性 QR-*。

NIST AI RMF 1.0用 Govern、Map、Measure、Manage 组织跨生命周期 AI 风险，并明确把用户反馈、申诉/覆盖、退役、事件响应、恢复和变更管理纳入部署后监控。对于生成式 AI，NIST AI 600-1还特别强调内容来源、部署前测试和事件披露。这些是覆盖面参考，不意味着每个底层算子都机械套用全部控制。

本阶段评审门是：所有关键质量主张都有观察量、控制条件、阈值来源和验证责任人；“更快”“更省”“精度无损”等词不能裸奔。

阶段六：方案权衡与决策

事后报告最容易虚构“我们对比了 A/B/C”。只有 issue、实验、分支、失败补丁、评审纪要或责任人确认能证明某方案真的被考虑。显而易见但没有历史证据的方案可以补入报告，但必须写成 [I] 回溯候选，不能证明当时考虑过。

基础决策可以使用 价值—成本—风险矩阵；架构质量冲突较强时，使用 ATAM 风格的效用树和质量场景分析。SEI 对 ATAM 的定义强调：性能、可修改性、安全、可用性等属性会相互影响，方法的作用是暴露架构风险、敏感点和权衡点，而不是给出一个脱离场景的总分。

方案	目标适配	性能/资源	精度/可靠性	兼容与回退	迁移维护成本	可逆性	证据状态
保持旧实现	基线	基线	已知	最好	最低	高	[F]
接入新路径并保留 fallback	目标方案	需受控基准	需误差与回归集	较好	中等	高	[F]/[D] 或 [I]
全量替换旧路径	可能收益更大	需验证	风险集中	较差	较高	低	未证明历史考虑则标 [I]

最终形成 Decision Record：选择、原因、假设、拒绝项、后果、技术债和重审触发器。特别要写清某个“实现约束”为什么被提升为需求；NASA Handbook 也建议需求理由保留原因、假设、运行关系和设计约束，而不是让这些信息随时间丢失。NASA Handbook PDF, p.69

本阶段评审门是：能解释当前实现如何满足高优先场景，以及哪些解释仍是事后推断；不存在“因为代码已经这样写，所以它必然是最佳方案”的循环论证。

阶段七：风险、发布与运营

需求报告不能停在合入代码。使用风险登记表、Premortem 或 FMEA 风格分析，覆盖正确性、数据、性能、兼容、安全、部署、可观测性和维护。严重度、发生依据和可探测性可以用于排序，但序数相乘不是物理概率，也不应伪装成精确损失。

风险	触发与影响	检测	控制	残余风险/责任人
新路径条件误判	不支持输入进入新算子并错误	分支命中日志、负例测试	明确 guard + fallback	需线上样本覆盖
基准不代表生产	穿刺收益无法外推	生产分布对照、分桶监控	灰度、按 Shape/模型分桶	产品/性能责任人
精度回归	局部误差积累为任务退化	单元误差 + 端到端回归	阈值、阻断、回退	模型责任人
依赖或版本变化	升级后行为漂移	版本/能力探测	兼容矩阵、锁定版本	维护责任人

发布部分需要写阶段、目标流量/用户、进入条件、监控指标、停止阈值和 rollback。代码 fallback 只是控制之一；数据回滚、配置恢复、事件响应、用户告知、供应链问题和退役可能由系统外流程负责，也要进入需求链。

对 AI 系统，风险管理是持续活动而不是上线前清单。只要模型、数据、Prompt、算子、硬件或外部服务版本改变，相关评测和风险结论都可能需要重开。

本阶段输出风险登记、灰度计划、监控、事件响应、回退与重审触发器。评审门是每个高影响失败都有检测和处理路径，未解决风险在摘要中显式接受或阻塞发布。

阶段八：验收、追踪与评审

验收要同时区分三件事：实现验证 检查系统是否按需求工作；用户确认 检查是否解决真实任务；价值验证 检查业务或工程结果是否发生。测试通过通常只覆盖第一件事。

Given-When-Then 适合把前置、触发和可观察结果写在一起。Cucumber 的 Gherkin Reference也强调 Then 应面向用户或外部系统可观察结果，而不是深藏在数据库或内部变量中的实现细节。

Scenario: 不支持的 Shape 安全回退
  Given 训练任务使用公开支持的模型 API，但输入 Shape 不满足新算子约束
  When 执行进入 Attention 路径
  Then 系统使用兼容实现完成计算，并产生包含回退原因的可检索事件

双向追踪矩阵连接：

业务目标 -> 用户需求 -> 系统需求 -> 决策/设计
         -> 代码/配置 -> 测试/评测 -> 运行与业务结果

目标	需求	决策/代码	验证	结果	状态
BR-001 资源可承受	QR-001 峰值/吞吐阈值	新路径与 guard	同配置 A/B + 运行分桶	上线结果未采集	部分验证
UR-001 完成长序列任务	FR-001 支持路径执行	dispatch 分支	正常/边界/失败测试	用户确认待补	部分验证
CON-001 不破坏 API	IR-001 接口兼容	wrapper + fallback	兼容回归	已有调用方无异常	需证据 ID

追踪必须双向审计：需求没有验证是覆盖缺口；测试没有需求或风险链接可能是历史行为、隐式需求或过期测试；代码没有需求、约束或风险控制链接则是孤儿实现或待记录技术债。

最后按必要、清晰、完整、一致、可行、可验证、可追踪和不过度规定实现进行评审。NASA Handbook 还要求检查技术正确、干系人满足、可行、可验证、非冗余以及到上层期望的双向追踪。NASA Handbook PDF, pp.69-70

报告首页必须保留“事后重建声明”、实现时间/版本、分析日期、证据截止、未确认项和审批条件。评审门不是让所有空白消失，而是让每个 Must 要求都有链路，让剩余空白都有责任人和处置结论。

完整报告结构

一份可审计的最终报告可以按下面目录组织。ISO 29148 提供需求工程信息项的规范背景，下面是针对“实现先行、事后补全”的本地裁剪，不是标准原文目录。

章节	必须回答	核心交付物
0. 文档控制与重建声明	何时实现、何时回溯、证据截至何时	版本、责任人、状态、审计声明
1. 执行摘要	为什么做、当前结论、最大缺口	一页结论与待决策项
2. 范围与上下文	系统边界、外部接口、非目标	Context、范围、裁剪记录
3. 证据账本	事实来自哪里、不能证明什么	E-*、冲突、缺证
4. 干系人与任务	谁在什么场景取得什么进展	Stakeholder Map、JTBD、绕行
5. 现状与根因	旧流程、影响、原因和反事实	ConOps、问题树、假设账本
6. 目标与指标	成功是什么	业务效果、方案性能、技术监控指标
7. 需求规格	系统做什么、做到什么程度	BR/UR/FR/QR/IR/CON 目录
8. 质量与 AI 评测	如何复现和判断优劣	质量场景、基准/数据/模型/护栏合同
9. 方案与决策	为什么选、代价是什么	候选来源、权衡矩阵、ADR
10. 实现对应	哪些代码实现哪些要求	版本、路径、符号、分支、fallback
11. 风险与合规	如何失败、如何发现和控制	风险登记、责任人、残余风险
12. 验收与验证	怎样判定需求满足	GWT、测试/分析/演示/运行测量
13. 双向追踪	链路是否闭合	目标到结果矩阵、孤儿审计
14. 发布与运营	如何灰度、监控、回退、退役	阶段条件、阈值、事件响应
15. 未决问题与审批	还缺什么、谁决定	最小确认问题、审批条件

每个阶段不需要机械使用全部方法。选择方法的准则是它能消除哪个具体不确定性：不知道用户任务，用 JTBD；不知道运行流程，用 ConOps；不知道根因，用假设驱动；不知道质量冲突，用效用树/ATAM；不知道失败控制，用风险分析；不知道覆盖是否闭合，用追踪矩阵。

穿刺案例

假设团队已经完成一个“新高性能 Attention 算子接入”的穿刺：有 dispatch 代码、若干单元测试和一份单机基准，但没有正式需求报告。正确回溯不是写“为了拥抱先进技术，我们决定接入”，而是按证据逐层恢复：

1. [F] 固定提交、支持 dtype/Shape、调用条件、fallback 和测试断言。
2. [F] 固定基准模型、序列分布、硬件、精度、软件版本、预热和重复次数。
3. [I] 根据内存/性能证据提出目标场景：长序列训练受旧路径资源峰值限制。
4. [G] 如果没有真实任务失败率、排队或资源成本，就不能宣称业务价值已经验证。
5. [A] 请求训练平台、模型和运维责任人确认目标用户、允许误差、兼容范围、灰度和回退阈值。
6. [D] 只有责任人确认后，才把路径选择和阈值写成决策与需求基线。

一个最小追踪片段如下：

层级	内容	证据/状态
机会	新算子在目标硬件上可用	E-DOC-001, [F]
场景	指定模型/精度/长序列训练受旧路径资源限制	E-BENCH-001, [I]，需任务数据
UR-001	工程师可在现有预算内完成目标训练配置	[A]，训练负责人确认
FR-001	满足支持条件时进入新路径，不满足时回退	E-CODE-001, [F]
QR-001	峰值、吞吐、误差满足批准阈值	基准可提供候选值，阈值责任人待确认
IR-001	公开 API、Shape/dtype、错误与告警语义保持兼容	代码 + 兼容回归，部分验证
D-001	采用双路径而非全量替换	若无 ADR，写 [I] 并请求实现负责人确认
V-001	正常、边界、失败、回退、端到端和同配置基准	单测已有；运行和业务结果仍为 [G]

这个例子说明：报告可以完整，但结论不必假装全部确定。完整性的含义是事实有来源、推断有链路、假设有责任人、缺口有处置，而不是每一格都填成绿色。

固化为 Skill

为避免每次从长 Prompt 重新发明流程，仓库中新增了 requirements-analysis-reconstruction Skill。它把证据标签、八个分析阶段及其前后门禁、AI 评测合同、报告模板和追踪规则固化为可执行流程，并提供 Git 证据基线脚本。

最短调用方式是：

使用 $requirements-analysis-reconstruction，基于下面已经穿刺完成的需求、代码范围、测试和实验，补全一份事后需求分析报告。

要求：
1. 不虚构历史动机，区分事实、推断、假设、决策和缺口；
2. 回溯业务目标、用户场景、系统需求、质量/AI 评测、方案权衡、风险、验收和双向追踪；
3. 所有关键结论回指 commit、路径/符号、测试、基准、日志或责任人；
4. 输出未验证 Must 需求和最小责任人确认问题。

输入：
- 已穿刺需求：<内容>
- 代码/PR/commit：<范围>
- 测试与实验：<路径或命令>
- 已知业务/用户信息：<内容，可为空>
- 报告目标路径：<路径>

Skill 的默认产物不仅是正文，还包括 Evidence Ledger、Requirement Catalog、Evaluation Contract、Decision Record、Risk Register、Verification Matrix 和 Traceability Matrix。没有业务材料时，它仍可完成技术事实和实现验证回溯，但会把“为什么值得做”和“谁认可阈值”保留为显式缺口。

常见失败

• 按代码结构写需求：把模块和函数翻译成需求编号，丢失用户能力、场景和系统边界。
• 从测试名推导用户价值：测试只证明其断言，不证明需求必要性和业务结果。
• 把探索基准当承诺：没有固定环境、样本、重复和阈值责任人的数字不能直接进入验收。
• 伪造候选方案：把分析者现在想到的方案写成“当时已对比”，导致报告不可审计。
• 只写正常流程：遗漏无效输入、超时、部分失败、兼容、回退、监控和退役。
• 追踪只有正向链接：只说明需求落在哪段代码，却不检查孤儿代码、孤儿测试和未验证需求。
• 把未知藏在附录：高影响假设和缺口必须进入执行摘要和审批条件。
• 把方法数量当技术性：访谈、5 Whys、FMEA、ATAM、RICE 全部做一遍不代表分析深入；技术性来自对象、证据、边界、阈值和可复现链路。

总结

当敏捷穿刺快于正式流程时，事后需求分析是合理的工程补偿，但必须承认它是 重建 而不是历史复刻。最可靠的结构是：版本化证据先行，用事实、推断、假设、决策和缺口管理认识，再依次闭合目标、场景、需求、质量、决策、风险、验证和运行结果。

完整报告的标准不是字数和章节数，而是每个关键问题都有可追溯答案：目标为什么成立，需求从哪里来，方案为何适配，阈值由谁认可，代码和测试覆盖了什么，运行价值是否真正发生，以及未知项由谁继续解决。

参考资料

• ISO/IEC/IEEE 29148:2018 — Requirements engineering
• ISO/IEC 25010:2023 — Product quality model
• NASA Systems Engineering Handbook — System Design Processes
• NASA Systems Engineering Handbook PDF
• NIST AI Risk Management Framework 1.0
• NIST AI RMF Core
• NIST AI 600-1 — Generative AI Profile
• CMU SEI — Architecture Tradeoff Analysis Method
• Cucumber Gherkin Reference