把需求中的疑点追踪到模型对象与验证依据

01

项目背景

有验证连线不等于可验证。

复杂装备评审中，一条需求可能连接了测试用例，却没有说明触发条件、测量对象或通过判据；另一条需求的文字已经修改，关联用例仍沿用旧描述。助手的具体任务是找出这类待核查项，帮助评审人员区分关系缺失与内容不充分。

审查输入包括需求清单、模型对象、规则与验证关系。通过批量请求与响应结构、短编号映射和对象标识，将每条发现关联到具体输入，便于工程师复核与定位。

02

输入组织

保留来源和关系方向。

拟输入范围限定为获准导出的需求编号、标题、正文、关系及相关模型属性。每批绑定模型版本和导出时间，保留原始对象标识；对不允许外发的内容先在受控环境内脱敏，客户名称、个人信息和访问凭据不进入智能体请求或公开案例。

临时短编号可降低引用混淆，映射表与当前会话绑定，返回结果还原到原对象。检索内容保留章节或规则标识，区分验证、满足和精化关系；模型遍历需要完整的关系数据。

03

方法设计

规则检查与语义审阅配合。

拟由确定性工具检查必填属性、关系端点及约定范围内的验证关联，再让 AI 对照需求文本解释歧义，例如只有“及时响应”而没有时间条件。规则命中、语义疑点与证据不足分别记录，语言模型不能凭措辞流畅就把未验证需求判为通过。

工具接口只开放获准的只读查询与校验操作，限定模型、对象集合和返回字段。原文中的命令语句一律作为待分析数据，不能改变工具权限。每条建议附原文片段、关联对象和规则依据；缺少上下文时请求人工补充，不自动补造技术指标。

04

复核过程

问题必须能回到原对象。

试点先选择一个小型功能包，由工程师事先标注已知问题和可接受表达，冻结规则版本后再执行审阅。逐条比较漏报、误报及引用是否正确，检查同名对象、短编号失效和跨版本结果混用，避免一份看似完整的报告实际指向错误需求。

拟交付内容包括输入清单、规则结果、语义问题单和人工裁定记录。修改建议需由责任工程师确认，再对受影响对象重新校验；原始结果和关闭理由同时保留。接口失败、空返回或无法还原编号应标为本次未完成，不能计入审查通过。

05

验证边界

辅助评审不替代工程结论。

验收应分别评价结构校验正确性、语义建议的可用性和证据定位能力，使用未参与调整的人工标注样本。模型关系完整不等于试验成功，需求措辞清楚也不证明设计满足性能；缺少试验记录的结论必须保持未验证状态。

方案实施从有限模型范围与人工复核开始，先验证输入解析、规则执行和问题追溯，再评估 AI 辅助解释的准确性。模型接口检查与 FMEA 关联可作为首批审查对象。

06

实施效果

方法预期让评审意见具备统一对象、版本和证据入口，减少反复寻找原文及确认关联关系的工作；是否实现这些收益，应由试点问题单和人工复核记录支持。

在同等模型规模下比较有效问题识别、误报处理负担与证据定位时间，并记录人工纠正情况，形成后续扩展的评估依据。