核心工作有哪些产出，如何验证，回头看还有什么可改进？

核心产出是门店指标定义与字段映射、面向 SQL 生成的上下文适配，以及能解释统计口径的查询结果。它们基于电商问数底座展开，重点是让运营问的“本月净销售额”真正对应到业务认可的计算方式。

验证时，我会固定数据和问题，用人工 SQL 作对照，同时检查指标、门店、日期和退款条件。例如本例把净销售额定义为本期实收减本期实际退款，退款按发生时间归属，就要放入上月成交、本月退款和部分退款的数据。成功意味着条件与结果都符合定义，不能只看 SQL 执行成功。

回头看，业务用例能发现口径错误，执行链还需要补一道检查：当前底座纠错后直接执行，未再次校验。下一步优先让纠错结果回到校验，并设置有限重试和失败出口；用“纠错后仍无效”的 SQL 检查它是否会停止执行。

核心交付是设备与手册匹配模块、各召回通道的范围适配，以及有适用出处的故障答复。Ragent 提供通用检索和生成，业务模块把型号、固件版本与手册生效范围变成允许使用的资料，并输出缺少哪些设备信息。

我会把成功分成三种情况：条件和证据完整时，给出受手册支持的答复；型号或版本不明确时，补问具体条件；没有适用资料时，返回缺口。验证用同一故障换型号、同一型号换版本的成组问题，分别检查范围是否正确、关键片段是否召回、建议是否由片段支持。

回头看，静态问题即使通过也不够，手册更新可能让设备映射过期。下一步增加资料变更后的影响检查：新手册适用哪些设备、哪些旧关系需要保留，再回放受影响的问题，确认新版本生效的同时，仍使用旧版本的设备没有被误切换。

核心产出是一份能逐条复核的研究初稿，以及支撑它的证据记录和材料更新清单。基于深度研搜的来源助手与报告生成，我重点设计来源去重、事实时间和结论关联，让研究人员知道哪些判断有依据、哪些地方仍有分歧。

验证会固定研究主题、截止日期和材料，先列关键子问题，再检查结论是否由原文支持、时间是否一致、冲突是否保留。例如“发布样机”“计划交付”和“已经交付”应分别判断，增加几篇转载也不应增加独立佐证。报告更长、来源更多，都不直接算质量提升。

回头看，内容可复核之外，长任务的连续性还有缺口。当前底座使用内存检查点，报告落盘不代表服务重启后还能继续。下一步补持久化与恢复逻辑，在任务中途重启服务，检查能否从正确状态继续，并避免把同一份来源或报告重复处理。

核心交付是外部 Python 设备资料适配服务：把型号和版本映射成 RAGFlow 的检索范围，核对返回片段，再组织有出处的答复。平台的文档解析和检索继续复用，业务增量是设备规则、请求分支和资料更新后的映射维护。

验证会同时看答复和平台调用。没有适用手册时，应在业务服务返回资料缺口，不发检索请求；有适用手册但没有故障证据时，保持原范围返回缺口；证据充分时，答复与引用都应来自允许文档。型号或版本缺失则补问，不能用其他设备的高相似片段顶上。

回头看，单次查询正确还不够，新手册入库后，映射与索引可能尚未同步。下一步把更新拆成可检查的步骤：确认新资料可检索，回放受影响设备的问题，再切换适用映射；失败时保留可恢复的上一版关系，并单独核对旧设备仍需使用的手册。