Context Mode
实践与畅想：构建可回放的 Context Mode 证据召回实验室
用小项目验证检索正确性、字节边界、来源更新和会话范围，不把推测性改进包装成发布承诺。
你将学会
- 版本化预期事实与支持段落，不只保存提示。
- 根据实际分支和字节边界设计样例。
- 诚实标记拟议改进与未测结果。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- 版本化预期事实与支持段落，不只保存提示。
- 根据实际分支和字节边界设计样例。
- 诚实标记拟议改进与未测结果。
把预期答案也做成版本化产物
有用的扩展项目是证据召回实验室：用仓库存放虚构文档、问题和预期支持事实，在每个样例旁保存内容哈希与清单。加入发布阈值、罕见标识符、明确否定及无答案问题。以后升级包时就能依据稳定任务测试，而不是依赖一次令人印象深刻的演示。
应把答案与证据要求分开。例如预期超时值必须包含单位和来源版本，不存在的迁移决定则必须保持未知。模型从旧对话重复正确数字，不能证明本次检索成功。应使用新的测试会话，把实际返回段落与样例清单逐项比较。
将源码观察变成实验
围绕默认字节上限构造密集单行、中日韩文字与 emoji 样例；加入重复标题探索 source/title 融合键，再加入初次无匹配的错词与已有弱匹配的错词。这些案例来自本系列检查过的具体实现分支，是建议实验，而不是断言项目目前无法通过。
再加入带日期事件检查时间线顺序、编辑过的文件来源，以及两个隔离项目标记。记录结果是否当前、完整且范围正确。即使其他存储仍返回段落，来源错误场景也应在报告中可见。会话清理应是显式审查过的测试操作，不能在轮次之间悄悄删除开发者工作历史。
产出读者能够复现的报告
每次运行应注明源码提交或包版本、宿主、运行时、样例哈希、查询模式和全部未测字段。原始证据按适当保留策略存于本地，仅发布无敏感样例结果。这里用简洁 HTML 表格或 SVG 展示通过、失败、未知，比掩盖证据缺失的动画仪表盘更有价值。
可考虑的未来改进包括显式暴露来源不完整状态、区分回退时间戳，以及提供更清晰的候选预算诊断。这些是从所查代码得出的编辑建议，不是上游路线图或实现承诺。首个交付物应是可重复的正确性报告；更丰富的可视化应解释具体失败，而不是夸大项目成熟度。
实施步骤
- 1
创建虚构语料和预期证据清单。
- 2
加入排名、多字节、新鲜度与范围样例。
- 3
在隔离宿主运行并明确清理决定。
- 4
发布可复现的通过、失败、未知报告。
可复制示例
{
"fixture": "release-larch",
"sourceHash": "运行前记录",
"queryMode": "relevance",
"expected": [
"18 秒",
"超过 2% 时回滚"
],
"observed": null,
"status": "未运行",
"upstreamRoadmap": false
}常见问题
这些未来功能是维护者宣布的吗？
不是。这些是依据所查实现提出、明确标注的编辑建议与测试想法。
实验室必须使用 Three.js 吗？
初期不需要。可读的证据表和重点示意图已经足够，除非交互视图能解释真实排名或状态变化问题。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07