图已经写入，任务就完成了吗：如何确定验证的停止条件

返回 TraceWise 项目总览

一批资料已经导入，图上的节点和关系都出现了，但用户点击来源仍然打不开。工程上可以说“写入完成”，产品是否也可以说“任务完成”？答案取决于用户下一步要做什么。

如果目标只是保存候选结果，写入可能已经达到约定；如果目标是基于这些资料开展有依据的调查，来源读取就是完成条件的一部分。验证应该停在哪里，要先从用户承诺推导，而不是从最后一个成功接口推导。

Google SRE 的测试章节区分开发期与生产测试，并指出测试消耗时间和计算资源。它支持按问题选择检查层次，而不是无限增加测试。下面的完成条件与反例，是我结合 TraceWise 经验整理的方法。Testing for Reliability

先检查用户能否完成下一步

9 月 12 日的一次 a15/post26 本地批量执行有明确的写入证据：348 块、11,136 条剩余关系完成，最终图指纹与封存预期相等；浏览器读取到 12,491 个节点与 11,200 条关系。同次记录中，Evidence 请求却返回 409，来源读取仍待写后视图准备。

正确的判断需要同时保留这两个结果。已经写入的关系不应再次导入，来源追溯也不能提前标成通过。对“完整导入并用于调查”的承诺，这仍是未闭合的环节；它不会因为其他检查已经很多就变成可选优化。

工作清单还暴露了一个相邻问题：无法确认当前 Evidence，不等于 Evidence 缺失。修复后的浏览器记录将 12,491 个节点保留为 unknown，没有把它们加入缺失 Evidence 的修复清单。未知状态需要恢复读取或继续核对，已确认缺失才适合引导用户补充材料。

这张表按声明的范围组织检查，不把它们排列成单一等级。一个检查的价值，在于它是否回答了当前尚未解决的问题。

先区分证据状态

TraceWise 使用五个明确状态描述当前结论：

• verified：通过真实执行、浏览器、持久化状态或结构化验收确认；
• code-confirmed：从源码、类型、配置或合同确认，但未完成相应端到端运行；
• partial：路径的一部分成立，用户结果或关键边界仍不完整；
• blocked：需要当前不可得的权限、环境、数据或产品决定；
• superseded：新证据推翻或替代旧结论，旧材料仍保留为历史。

这些词不是成熟度徽章。例如 verified 必须带范围：“在两个受控本地项目、指定版本和指定依赖下 verified”，而不能被简写成“生产可靠”。code-confirmed 也不是低价值，它允许我们准确说明设计和控制流，同时避免假装已经运行。

查看原图

方法图：证据不是勋章等级，而是有明确适用范围的声明许可。

验证要从最小反例开始

大规模测试适合确认整体回归，但通常不是发现根因的第一步。TraceWise 的几个关键修复都来自很小的反例。

反例一：历史版本 ID 被保存，却没有参与计算

历史版本修复中的期望行为是：用户显式选择实体 v1，规则就使用 v1 状态。旧实现的实际行为是：运行记录保存了 v1 ID，规则输入却从实体 latest 读取 v2。

最小案例只需要两个版本：

v1: status = at-risk
v2: status = on-track
请求显式选择 v1

如果结果仍按 v2 计算，就证明“历史版本参与推演”的产品合同不成立。修复发生在权威版本读取层，而不是在结果页补一个 v1 标签。回归进一步覆盖缺失、重复、跨 Graph 和实体不匹配 ID，确保错误选择失败关闭。

反例二：compatible=true 掩盖了 Snapshot 假绿

早期 Snapshot preview 主要检查 schema 标签，无法证明 dangling reference、ID 冲突、Scope 漂移和遗漏分区都可处理。更关键的是，导入只恢复部分核心知识，却被容易地理解成备份恢复。

功能合同改为“创建核心知识副本”：Preflight 明确 restored 和 omitted sections，绑定请求 fingerprint，写入隔离 draft project，并保存 immutable applied 或 partial receipt。

验证因此必须同时检查：拒绝错误输入、源项目保持不变、目标身份重新映射、覆盖面准确呈现，以及失败后留下可解释状态。

反例三：让真实数据库失败，而不是 mock 一个异常

Graph 与 Foundation 同属一次业务动作，不代表它们拥有统一事务。受控验收先让 Graph 成功，再真实中断 Foundation PostgreSQL。如果系统仍显示整体成功或整体回滚，就说明失败语义失真。

这条历史受控路径保留 applied_with_foundation_pending；恢复数据库后对原 ReviewDecision 手动 retry，随后 exact replay deduplicate。这个案例证明指定路径下的部分成功和恢复合同，不证明通用跨存储事务或自动恢复。

反例四：第二个项目打破单项目偶然性

第一个 Pilot 成功后，身份模型仍可能只对特定 ID 偶然成立。第二个真实项目 model-post-training 暴露了 product project ID 与 Graph authority project ID 的混用。

修复后，它拥有独立 Registration，迁移 107 条 Evidence，从正式可复现 wheel 重开；第一个 Pilot、受保护产品行和未 opt-in 项目保持不变。这个验收比再增加一层抽象更有价值，因为它直接验证“项目级 Authority”是否真的按项目工作。

它仍不能推导第三个项目、全组织部署或生产流量下都成立。

验证层次必须与声明匹配

不同检查回答不同问题。选择其中哪些，应当由这次改动影响的行为决定。

代码是否表达了预期契约

检查类型、import boundary、schema、版本 pin、包内容和禁止依赖。它适合回答“设计是否被代码表达”“产品是否越过公共边界”。

它不能证明数据库真的写入，也不能证明浏览器中的用户路径可用。

曾经出错的行为是否得到修复

使用最小反例和相邻负例验证具体不变量。历史版本、Evidence drift、wrong reviewer、direct apply denial、重放冲突都属于这一层。

它的目标是让缺陷在最小范围内稳定失败，然后确认根层修复，不是用 mock 的绿色结果替代真实系统。

用户路径在实际依赖下能否完成

运行真实 ASGI、SQLite、PostgreSQL、Neo4j、Qdrant 或浏览器路径，检查返回、持久化状态、重启恢复和失败分支。例如 ReviewDecision 不只看 HTTP 结果，还直接检查 Graph、Foundation Memory、transition、receipt 和 sync state。

这层能够支持“在该受控环境中 verified”，不能自动支持生产认证。

交付物能否定位并重新构建

独立类型、lint、测试、构建、wheel 内容、安装来源和包哈希共同确认交付物能够从明确版本定位。TraceWise 当前正式基线还使用独立构建根验证 wheel identity，并在非 editable 安装中检查公共路径。

可复现包证明交付身份，不等于业务结果或模型效果。

为什么“全量跑一遍”不是每次都对

Google SRE 的测试章节明确提醒，系统级和生产级测试比单元测试昂贵，测试成本会影响开发效率。TraceWise 因此按风险选择验证：

交付版本需要执行约定的完整检查；后续若代码或关键配置变化，应重新检查受影响部分。微小编辑无需机械重复全部检查，但构建工具跳过的类型或 lint 也不能记为已经通过。

24 小时空等为什么被删除

Stage B 曾把空闲运行 24 小时当作完成门槛。后来重新审阅时发现，环境没有生产流量，也没有新的请求、并发、网络分区或恢复事件。时间经过本身没有触达任何新路径，因此不会增加稳定性证据。

这个门槛被标记为 superseded。保留下来的是真正发生过的证据：

• 24 次受控 Authority 操作；
• approve、restart reload、exact replay 和 unavailable/recovery；
• legacy 写入阻断；
• clone rehearsal；
• 原有项目数据零变化；
• 320/375/414/768/1440 像素浏览器检查。

生产 traffic、long-running soak 和 canary 仍然未验证。只有经过了相关负载与事件，运行时长才会增加对应的可靠性证据。

停止条件是一项工程能力

我用下面几个问题判断当前工作是否可以结束，而不要求每个小改动都执行同一套测试：

1. 用户被承诺的可见结果已经完成；
2. 如果是在修复缺陷，原来的反例是否已经通过；
3. 相关的相邻错误输入或失败分支是否得到检查；
4. Authority、失败状态和恢复语义得到对应范围的检查；
5. 文档和交付物使用同一当前口径；
6. 未完成部分是否区分了原定目标缺口、可选改进和其他目标；
7. 继续工作只会扩大范围，而不会关闭当前风险。

停止并不意味着系统再无问题。它意味着当前目标已经有足够证据。若来源打不开仍影响原定任务，这就是必须补齐的缺口；若任务仅要求保存结果，新增自动分析才可能属于另一个目标。区分的依据应是承诺，而不是剩余工作的难度。

哪些数字可以说，哪些不能说

TraceWise 可以陈述有明确来源的事实，例如：第二个受控本地项目迁移 107 条 Evidence、一个 Stage B 验收记录 24 次受控 Authority 操作、特定版本的完整回归通过多少测试。

但这些数字不能自动变成：

• 模型准确率提升；
• 用户效率提升某个百分比；
• 生产可靠性或 SLA；
• 企业级隔离；
• 市场采用规模。

性能和效果结论需要明确样本、baseline、指标定义和运行条件。开发数据上的配对比较可以支持当前调试与采用判断；对未见任务的泛化结论，还需要独立材料和相应的评估设计。

检索实验：工程回归完成后，为什么还没到最终验收

2026 年 9 月的检索工作把这个区别具体化了。相关历史实验使用 Foundation post22 开发候选，当时正式基线为 a12/post10。后续服务化集成没有重新生成这组质量成绩。

首先，工程问题有自己的结束点。维护式图视图在固定本地对照中保持返回顺序、分数与非易变引用一致；撤销一条 Evidence 后，受影响对象退出当前结果，旧视图标识被拒绝。它们回答了读取机制和失效路径的问题。继续重复同一条查询，不会告诉我们用户换一种问法后是否还能找到所需知识。

其次，开发题用于比较策略。正文检索以同一候选池、最终条数与上下文预算比较向量基线和重排，71 道支持明确的题中，最终完整保留已声明依据的数量从 51 增至 60。节点检索则出现不同方向：12 道实体题，多信号完整命中 11 道，语义模式命中 10 道。两组结果分别支持保留正文重排候选，以及不全面替换节点默认策略。

这些题仍由 AI 编写、复核，且存在历史暴露。75 份排序与覆盖计算经另一份实现重新核对一致，解决的是评分程序是否算对；它不能改变题目的作者来源，也不能让已经看过的材料成为独立测试集。

因此，本轮停止了对同一批开发题继续调权补分。保留现有默认、保存候选配置与失败案例，等待未暴露材料来回答下一层问题。停止的是已经完成的开发对照，独立质量验收仍未完成。

要重新启动评测，应先说明新信息是什么：新的独立问题、变化的任务范围，还是新的候选机制。只有换了目录或把旧问题改写一遍，不能为再次运行提供新的判断依据。

旧验收什么时候需要重开

一次验收属于某个版本、配置、数据与操作路径。a17 完成服务客户端集成，并不能把旧版使用本地 Memory 的测试升级成共享服务运行证据；同样，旧页面通过检查，也不能保证新来源展示仍然正常。

我会先检查变化是否穿过关键主张的依据链：读数据的来源变了没有，身份和权限入口变了没有，页面如何展示结果变了没有。如果只是与这些路径无关的文案修改，没有理由重跑模型；如果来源坐标或展示组件改变，就需要回到实际引用的内容与位置。

反例同样可以改变停止决定。用户换一个项目就出现身份冲突，说明原来“按项目工作”的证据不足；同一个结论被新依赖版本破坏，就应定位被替代的检查，而不是沿用旧的通过数字。

对于需求仍在探索的原型，不必预先证明所有生产条件；但应把本次承诺限定到实际要交付的结果。对于已承诺的完整工作流，也不能在局部成功之后临时缩小完成标准。

让停止决定可以被复核

完成一次验证之前，我会把结果写成一句具体的话：在什么版本和输入下，用户完成了什么操作，关键失败时看到了什么，还缺哪一步。这比“全部通过”更容易被下一位维护者检验。

历史版本案例提醒我们检查实际计算输入，批量写入案例提醒我们走到来源读取，检索对照提醒我们把工程正确与内容质量分开。它们共同支持一种工作方法：先明确需要减少的不确定性，再取得相称的证据。

当原定用户结果和关键失败分支已有依据，继续重复相同检查的价值会下降；当用户下一步仍走不通，再多的局部通过也不能成为停止理由。