切换外观
Fold skill：语义判断与可靠操作
状态：「何时调用」「时间流逝信号」「上下文视图」「动作与命令」「一次整理怎样完成」是首切片要求；对照评估是待执行的验证计划。未决问题见决策记录。
本文承接形式模型与用户故事；字段定义见信息契约，实现边界见架构。
Skill 把语义判断指引与成套可执行工具一起交付。指引帮助 Agent 决定怎样表达与取舍；CLI 负责读取、校验、保存和查询，Agent 不在每一轮重新实现它们。
语义估计指引包含两方面帮助：把待判断的问题转换成更准确、一致的表达；让 Agent 看见作出判断所需的当前状态与用户上下文。
问法更清楚、上下文更完整，估计才有依据；新的背景促使重新比较。
何时调用
Fold 用于把持续变化的信息整理成可供后续使用的当前状态。用户不在场是首个验证场景，不是使用门槛。一次 Agent 运行里：
- 开始时：运行
fold state，读取当前层、时长投影和尚未收到处理确认的批注。批注是方向性提示，不是任务清单。 - 工作中：只在产生用户可见变化的里程碑提交，例如一件事完成、同一件事的状态改变、几件事可以合并说、发现需要用户参与的新事项。不要逐步提交过程消息。
- 结束前：提交本轮检查结果。有变化时提交声明；只确认批注时用空
declarations与相应acknowledges；两者都没有时提交空批次，记录checked，不制造条目更新。 - 紧急事项：需要立刻打断用户时先走即时渠道，再根据持续关注价值决定怎样纳入 Fold。即时通知与后续状态整理可以同时需要。
宿主因空事件窗口、周期回顾或健康检查而调用 Agent 时，也适用这一流程。没有新业务事件仍可能需要重新整理；具体判断见理解时间流逝信号。
SKILL.md 的 description 应描述场景而非功能，草稿如下：
当你需要把持续变化的进度、结果、发现或用户反馈整理成当前状态时使用。
适用于：后台任务完成、同一件事状态更新、多件事合并汇报、发现需要用户
参与的事项，以及收到空事件窗口、周期回顾或资料陈旧提示后重新审视旧状态。
用户是否在场不影响使用；需要立刻打断时先走即时渠道，再按持续关注价值
整理到 Fold。估计要回答什么
每次整理的目标统一表达为：
用户下次回来时，哪些内容会改变其理解或行动？如果延后表达、缩短表达或省略它，可能造成什么后果？
这使“重要”有了具体对象、时机与后果。它不仅包括需要用户动手的事情，也包括能让用户修正判断、了解结果或放心等待的信息。“PR 已合并”可能无需行动，却能让用户停止等待；“只差银行流水”让用户知道下一步；一篇文章是否值得保留，要看它是否服务于用户明天的讨论。
Agent 默认用五档 weight 表达比较结果，份额由脚本派生。需要超出默认尺度时，可以提交非空的 share 覆盖派生值，并同时提供 reason；这条例外路径保留 Agent 对尺度的控制。脚本检查最终预算，不自行降档或驱逐。
理解反馈与业务策略
领域模型描述可以进入判断的基础形式。Skill 帮助 Agent 理解这些形式，再依据当前业务的用途与规则处理；不预设一套通用的“已阅后必须降到哪里”或“已处理后必须退出”的业务流程。
先弄清当前权重表达什么。 通知中心可能主要表达尚未告知的价值，近期重点概览可能主要表达持续影响。用户已阅后，前者可以将关注归零，后者可以继续保留；用户已经知道，不等于事情已经没有用途。业务已有明确规则时应用规则，需要语义判断的部分再结合上下文比较。
处理反馈时，依次区分：
- 收到的是什么。 保留反馈原意、来源、时间及目标。用户确认已阅、用户报告处理完成、Agent 确认批注，是不同事实；不要用一次页面打开或缺少回复代替它们。
- 它改变了什么依据。 已阅提供关于用户知晓的证据；已处理或给出决定，可能消除原有等待或改变事项状态。检查影响范围，不把针对一个部分的反馈扩成整个事项已完成。
- 业务还需要什么。 结合系统用途、已知策略、当前事实与用户目标，判断剩余的告知价值、行动需要或持续影响。相同反馈可以合理地导向保留、降低关注、零关注或其他业务处理。
- 如何解释并表达决定。 说明用到了哪份反馈、什么业务依据以及仍不确定什么，再选择当前工具支持的操作。业务语义上的权重为 0 不等于现有 CLI 的
weight接受数字 0；需要按操作契约表达退出当前关注等结果。
没有明确业务策略时，说明正在依据什么用途作判断及采用的暂定理解；不要悄悄把通知中心、待办清单或某种看板的习惯当成所有场景的默认规则。内容被更新或合并后，借原目标与历史关联判断此前反馈还适用于什么，而不是仅凭换了 ID 就重新解释为未阅。
时间输入同样要先理解，再决定。 零事件窗口、周期回顾或资料陈旧提示可以使旧状态值得重新审视（见理解时间流逝信号），但不预先决定增权、降权或撤下。用户要求稍后提醒时，宿主到点输入的是一次带原意与目标的新信号；Agent 应按现在的事实和业务策略重新判断，不能直接复用当时的结论。例如已有证据表明事项失效，轻量说明原事项失效是一个可选业务处理，并非通用规则。
评价这种理解时，要同时检查两点：同一策略下是否准确解释反馈；改变业务策略后，是否能作出有依据的不同决定。固定 read → 降权 这样的映射看似稳定，却可能始终误解业务目标。
让估计看到足够的上下文
fold state 的读取视图包含：
| 上下文 | 为什么影响判断 |
|---|---|
| 当前同层的全部条目摘要、预算、份额与 rank | 估计相对关注价值，知道新增内容将与什么竞争；已有份额只是此前判断的结果。 |
各条目的时长投影：age、since_update、until_due、until_stale | 结合时间理解进展与等待的后果，再由 Agent 判断关注价值。 |
状态为 saved 的批注及其所在条目 | 表示尚未收到处理确认；条目或其祖先被撤下后，未确认批注仍可取得。 |
last_seen_at 与 since_seen | 首切片一律为 null，表示尚未采集用户阅读行为。Agent 调用 state 或用户留下批注，都不能据此推导用户看过哪些内容。 |
last_checked_at | 可从最近的 checked 事件取得，表示最近一次产生 checked 的整理时间，不涵盖其他类型的提交，也不表示用户阅读时间或外部来源已核验。 |
| 按需的子层、来源附件与变化历史 | 检查摘要是否遗漏关键事实，理解条目为何被缩小、合并或撤下。 |
宿主还可通过调用上下文提供时间流逝信号，包括已知的时间窗口、唤醒原因与采集情况。这些信息帮助理解沉默与回顾时机，不属于 state 新增的字段；用户目标、偏好与承诺也由宿主补充。
上下文的选择不能只依赖当前份额。一个长期占很小份额的条目，也可能收到决定性的用户反馈；未确认批注和与当前目标相关的历史，应有独立进入上下文的路径。被撤下的内容是否重新纳入，由新背景决定；“不在当前层”不等于“不值得再看”。
用视觉概览定位全局与变化
条目较多、需要比较层级关系或接续此前整理时，可给 fold state 加上 --overview，让工具从同一份已捕获状态生成真实 HTML/DOM 截图。Agent 选择看什么，渲染器负责布局；视觉概览用于定位值得核对的内容。
overview 只用于快速概览，必须结合同一次读取的完整 state JSON 使用。 Agent 不能只看图片或视觉 diff 就作出判断、调整份额或提交变更；图中展示的范围和字段可能不完整，看图之后仍须读取状态并核对依据。
读图时，同一层卡片占预算矩形的面积比例就是其最终 share / budget，包括显式份额覆盖。面积表达已分配的关注；kind、档位标签和变化用颜色、边框或图标辅助表达，不额外改变面积。
- 区分未展示与留白。 筛选掉的 active 份额保留为中性“未展示”区域，不能把剩余卡片放大，也不能把这部分当成未分配预算。真实留白只对应该层
budget - used。 - 只在同层比较面积。 子层使用独立预算矩形，不乘父项份额；不同层的面积不能直接比较。同层 diff 的两端保持同一尺度，撤下或合并的旧项放在当前预算矩形外，或置于独立的等尺度基线图。
- 小卡片仍保留真实比例。 文字放不下时，按 ID 查看框外详情，或扩大整块画布；不靠提高最小卡片面积或把文字缩得不可读来塞满卡片。
- 先确定观察范围。 用可选的
view选择条目 ID、展开深度和字段，不编写布局或改写摘要。通常保留未变化的上下文；只看变化须明确选择changes_only，并留意范围与省略提示。 - 再选择比较起点。 以此前的
event_seq请求 diff，不用 revision 代替。工具以同一个now投影两端，帮助区分状态变化与单纯的时间流逝；端点 diff 不代表期间每一步过程，需要过程时查询history。 - 结合完整 state 核对。 检查图和
overview.json中的版本范围、省略及未展示变化提示；若有分图，按说明查看全部相关图片。再读取完整state.json中的同层条目、预算和尚未确认的批注，按 ID 核对本次判断涉及的字段、子层与关系；需要比较变化时同时读取diff.json。核对范围不能只限于图上的条目，图片没有显示某项或某个字段，不足以断言它不存在或未变化。 - 把渲染作为可选读取能力。 原有 stdout 状态 JSON 保持可用。缺少浏览器时，请求图片会明确失败，Agent 继续依据 JSON 整理；选图、生成或查看图片、读取 diff 都不确认批注、不产生用户阅读记录，也不改写共享状态。
完整 state 可以分段读取，不必一次性全部放进模型上下文。先用 overview.json 和它列出的 PNG 定位，再从完整 state.json 核对上述全局上下文与具体依据；未展示条目和待确认反馈也要进入核对范围。分段读取不能省略 state 核对这一步。普通 stdout 保留，调用适配器或输出重定向可以避免整份输出自动进入上下文。
输出文件、默认视图及差异字段以视觉概览规范为准。视觉输出在所选范围内等价表达已有内容，不新增事实或重写摘要。
理解时间流逝信号
长期没有新事件时，旧摘要与旧份额可能一直保留，而期限、资料的适用性和等待的后果已经改变。Agent 每次接到时间流逝信号，都应重新问：这些旧结论现在还适用吗？继续这样表达，会让用户误解什么或错过什么？ 没有新增业务事实，也可以有新的整理判断。
三类常见的复合信号
下列是业务系统可能交给 Agent 的信号特征，可以同时出现。它们包含时间流逝与调用背景，不要求宿主使用统一格式，也不要求 Fold 内置 tick、周期任务或健康检查。
| 宿主可能的实现 | Agent 可能收到的信息 | 怎样理解 |
|---|---|---|
| tick 与事件批处理绑定 | “09:00—12:00，共 3 小时，所订阅渠道收到 0 条事件。” | 这个窗口内没有收到所述范围的事件；仍要检查期限、等待与资料适用性。事件数量为零也是有范围的观测信息。 |
| 主动回顾间隔 | “现在是每日整理时间，请回顾过去一天与仍在持续的事项。” | 这是回顾旧状态与历史的时机。检查旧判断、未兑现的预期、分散内容与待确认反馈；调用本身没有验证外部事实。 |
| 外部健康检查唤醒 | “报价来源已三天没有成功更新，超过业务系统的一天复核间隔。” | 先辨认检查针对哪个对象、依据什么时间或规则，再判断应补充观测、修改表达还是调整关注；陈旧提示本身不能给出最新报价。 |
先确定沉默能够说明什么
结合信号和可取得的上下文，辨认当前时刻、窗口起止与时长、涉及的来源或事项、唤醒原因，以及采集是否正常、是否有漏采或延迟。只有“现在到每日整理时间”的提示时，不补出一个已被完整观测的全天窗口。缺失信息保留为未知，不把每一项都变成必须向用户追问的前置条件。
“没有收到事件”只描述接收结果。只有在观测覆盖与渠道正常有依据、且相关变化按渠道规则应产生事件时，沉默才支持“在这个范围内没有观测到该类变化”。它不能证明现实中什么都没发生；断连期间的零事件更不能支持原状仍然成立。若预期某时之前会收到回复或结果却未收到，等待本身可能已需要关注，但不能直接写成对方拒绝、任务失败或用户不关心。
收到的窗口描述的是过去。若唤醒消息延迟送达，用调用方当前 now 读取状态，同时保留原窗口的边界；不把窗口之后的时间也声称为已观测。处理信号时以当前状态与已有历史核对，避免迟到提示覆盖后来已确认的结果。
多类信号同时到达时，结合它们的范围与原因完成一轮连贯整理；重叠窗口不能相加成更长的连续沉默，重复提示也不增加证据强度。宿主把入站事件按窗口打包，与 Fold 保存声明的原子批次是两层概念。
重新判断事实的适用性与关注价值
- 读取当前状态并选择复核范围。 将本次时间信号与时长投影、来源和历史放在一起。检查信号涉及的事项及其关联项；广泛的周期回顾还应覆盖长期未动的条目和待确认批注，不只看当前大份额事项。需要时取回已缩小或撤下的相关历史。
- 检查时间是否改变了结论的适用条件。 行动截止是否临近或已过，参考资料是否仍适用，承诺或等待是否超过原有预期，用户目标是否仍与旧表达相符。不能用统一的“多久算旧”或固定衰减替代这些判断。
- 按需要补充观测或明确未知。 若新的判断依赖外部现状，通过宿主已有能力和授权核对有关来源；取得新结果后再更新事实。暂时无法核实时，保留可追溯的旧证据，把依赖新鲜度的结论表达为“最后已知……，当前待核实”，而不是继续把旧结论写成当前已确认。这个范围限定本身可以是有意义的内容更新。
- 重新比较当前关注。 同一组事实经过时间推移，可以需要不同的表达与份额：截止临近可能提高关注，久未兑现的预期可能需要说明，已无当前用途的成果可缩小或撤下。有依据的调整由 Agent 明确声明；仍然成立的内容可以保持。
例如，12:00 的零事件窗口没有提供新报价，但旧报价明确在 11:00 失效，Agent 应将当前购买选项改为“待新报价”；出行事项是否继续保留另行判断。同一窗口里，付款期限已过且没有可用的新支付结果，Agent 可以保留账单关注并写清“最后记录为未支付，当前支付状态待核实”，不能声称已核实仍未支付。若事项的期限、依据和关注价值都未改变，保持条目也是有效结论。
用真实变化结束本轮整理
入站的“零业务事件”不等于提交空批次。Agent 完成上述判断后，有摘要、档位、期限或活动状态等有效变化就提交相应声明；没有业务变化和新增确认才提交 checked。仅确认反馈时沿用现有确认流程。一次新的复核使用新的批次身份，同一次提交的重试仍遵循批次与回执。
不要为每个 tick 创建一个展示条目，也不要为了让状态显得新鲜而改写日期、重复提交原内容或延长 stale_after。checked 只证明做过一次整理检查，不证明所有来源都被成功复查。因“当前待核实”而更新摘要，会更新条目的资料时间，却不会使原有证据变新；核对新鲜度时仍须看来源与实际观测依据。
健康提示中的“很久没更新”，可能指很久没整理、条目资料未改、或外部来源很久未成功观测，三者不能互相代替。后续重复唤醒时，已有的“待核实”表述若仍准确且没有新判断，保持即可；若等待继续带来不同后果，再作明确调整。
这些指引帮助已被唤醒的 Agent 理解时间。宿主须提供调用机会或时间上下文；完全没有再次调用时，Skill 本身不能推进状态。调度边界见架构。
用一致的语义描述候选
| 容易混淆的表达 | 更适合估计的表达 |
|---|---|
| “账单过期了。” | “付款截止已过；有当前支付依据时说明是否仍未支付，否则保留最后已知状态并标明待核实。” |
| “这个报价今天过期。” | “此价格今天之后不能购买；出行需求是否仍存在另行判断。” |
| “大项目，写了很多进度。” | “当前哪项结果、阻塞或选择会改变用户的理解；细节量另行说明。” |
| “很紧急，所以最重要。” | “延后到下次查看会有什么后果，该后果与用户目标有何关系。” |
| “用户一直没有点。” | “首切片未采集用户阅读行为；不能从缺少记录推断用户没有看或不感兴趣。” |
| “三天没消息，所以没有变化。” | “这三天在什么范围内没有收到消息；哪些结论仍有依据，哪些需要复核？” |
| “刚做过检查，资料就是新的。” | “本轮整理发生过；资料是否仍适用，要看来源是否成功核对以及证据覆盖到何时。” |
重要性、紧迫性、任务规模和内容字数可以相关，但不是同一个量。转换也不能擅自补全事实：原始记录只说“已提交付款”，就不能写成“付款成功”。
比较方案，给出可核查的说明
让模型比较“保留或增加这项，会让什么让位；被让位的内容是否仍能充分表达”，而非为每个条目孤立打分。沿用 US-03：
- 保留阅读推荐，降低周报档位：适用于阅读与用户近期目标直接相关的情况。
- 撤下阅读推荐，同时保留已完成周报的结论：适用于当前没有阅读用途证据、签证需要用户参与的情况。
选择其中一种时，reason 字段写出足以复核的说明：
签证代理确认缺银行流水；用户已确定出差安排；周报已有完成稿。提高签证档位，周报保留结果与待核对点，阅读推荐暂离父层。不清楚阅读推荐是否用于近期会议，若用户补充这种用途应重新比较。
未知不必包装成置信度。模型直接指出缺什么、它可能改变哪项判断，以及当前采用了什么暂定假设。
用明确动作操作状态
Skill 的可执行部分是一个 CLI，四个子命令：
fold state --now <ts> # 状态投影与待确认批注
fold state --now <ts> --overview <output-dir> [--view <view.json>] [--diff-from <event_seq>]
fold commit <file> --now <ts> --actor <name> # 校验并保存声明批次
fold annotate <id> "<text>" --now <ts> --batch-id <batch> # 保存批注，actor 固定为 user
fold history [id] # 查询完整批次记录
fold history --batch <batch> # 核对某次写入的实际结果提交前准备：
- 使用 JSON 批次，先确定
batch_id，再填写声明与要确认的批注。YAML 仅用于设计用例。 - 为命令提供
now；脚本不读时钟。commit指明 Agent 身份，annotate的身份固定为user。 - 字段、请求身份与回执的精确定义见信息契约。下面是结束时没有新变化的请求示例。
json
{
"batch_id": "run-20261009-final-check",
"declarations": [],
"acknowledges": []
}| 动作 | Agent 决定什么 | 脚本执行什么 |
|---|---|---|
新建与覆盖（new / supersedes） | 新信息属于新事项还是已有事项，当前摘要和依据是什么。 | 按补丁合并并校验最终状态，保留省略的可选字段。 |
合并（merges） | 哪些同层叶子可以共同表达，合并后的摘要是什么。 | 校验首切片支持的结构，保留来源与批注以及历史追溯关系。 |
子层（children） | 哪些细节属于哪个主题，哪些原有孩子明确撤下。 | 校验目标集合与显式撤下声明，分别检查各层预算。 |
调整档位（weight / share） | 哪些条目让位。 | 派生份额，计算各层总量，超额整批拒绝并返回数值；不自行选择让位对象。 |
撤下与重新纳入（withdraw / supersedes） | 哪项暂时退出、哪项重新值得关注。 | 撤下整棵子树；恢复时只纳入明确声明的条目，保留资料与反馈。 |
确认批注（acknowledges） | 哪些批注已纳入整理或已作出明确回应。 | 保存首次确认，重复确认不覆盖原绑定。 |
准备声明时特别检查：
- 补丁： 非
withdraw声明每次填写weight、kind。省略可选字段表示保留；需要清空时按字段契约使用允许的null。 - 合并： 首切片只合并同层 active 叶子；所有来源项都不能带有历史子树，结果也必须是叶子。后续更新指向合并后的条目，旧项保留到后继的追溯关系。
- 子层：
children表达目标集合，省略则保留。若移除原有 active 直接孩子，包括清空子层，必须在同批显式withdraw每个被移除的直接孩子；父项的reason不能代替撤下声明。detail-of不在首切片支持范围内。 - 恢复： 对已撤下条目使用原 ID 的
supersedes，逐项声明要恢复的内容；恢复孩子时，最终父项也须为 active。已合并旧项按后继处理，不走撤下恢复路径。 - 来源： 补充来源属于资料更新，会更新条目的
updated_at；仅凭来源增加，不能声称任务取得了进展。
无变化、批注确认与业务更新
根据本轮实际结果解释回执：
- 既无业务变化，也无新增确认时，
checked表示完成了检查，不代表事项更新。 - 只有新批注确认时，
acknowledge表示反馈已纳入整理或得到回应，不代表外部行动完成。 - 有业务变化时，区分内容、结构、分配和来源的变化，不把它们一律描述为任务进展。
同内容补丁、重复确认、单独修改 reason 或自动元数据都不能制造事项更新。事件与 revision 的精确规则见信息契约。批注的 saved 应解释为“尚未收到处理确认”，不能解释为“Agent 尚未读取”。
一次整理怎样完成
正在绘制图表…
查看图表定义
flowchart TD
R["fold state：读取状态、时长与待确认批注"] --> J["Agent 比较，准备 batch_id 与完整请求"]
J --> C["fold commit"]
C -->|"结构或预算不满足"| Fix["按错误修正声明或重新取舍"]
Fix --> C
C -->|"committed 或 already_committed"| Done["按回执区分检查、批注确认与业务变化"]
C -->|"batch_id_conflict"| Conflict["核对原回执与差异字段，不换 ID 绕过冲突"]
C -->|"存储失败或未收到回执"| Q["fold history --batch：查询原 batch_id"]
Q -->|"找到完整批次记录"| Done
Q -->|"未找到"| Retry["保留原 ID、actor 与内容重试；now 可更新"]
Retry --> C
Q -->|"暂时无法核对"| Pending["保留原请求，待存储恢复后继续核对"]
Pending --> Q
一次整理是一个批次：US-03 中“增加签证、降低周报、PR 和机票档位、撤下阅读推荐”是相互依赖的取舍，整批检查、整批接受。批次可能已经保存，调用者却没有收到回执；上述核对路径也适用于 annotate。
按结果选择下一步：
- 校验拒绝： 根据字段、结构或预算错误修正声明。缺少显式撤下时，先核对受影响的孩子和后代；脚本不替 Agent 作删除或让位判断。
- 身份冲突： 阅读
original_receipt与differing_fields，核对请求和意图；不能换 ID 绕过冲突。只有核对后确认是独立的新操作，才另建批次。 - 结果未知： 用
history --batch核对原 ID。未找到时保留同一请求重试，可以使用当前now；若此前已提交，会返回首次接受的结果，不刷新时间。 - 暂时无法核对： 保留请求并说明结果尚未确认，恢复后继续查询。
精确的重复比较与回执字段以批次与回执为准；文件写入与故障恢复见本地提交与恢复。
两类一致性都需要
无关措辞变化应保持主要判断稳定，相关背景变化应触发重估。
无关变化下保持稳定。 事实和用户背景相同，仅改写等义句、调整互不依赖条目的顺序或替换序号时，主要取舍应当稳定。某条消息排在提示的最后，不应无故变得更重要。稳定不要求每次生成相同的摘要，检查的是关键事项是否仍可见、相对关系是否无故反转、理由是否仍受相同证据支持。固定映射只保证相同预算与档位、未使用覆盖时得到相同份额，不证明语义判断正确。
相关变化下能够调整。 用户说明“这篇文章是明天会议必读材料”，或账单从未支付变成已确认支付时，估计应重新考虑。即使没有新业务事件，时间推移导致期限临近、旧依据失效或等待后果改变，也应触发重估。一直维持原排序也可能是一种失败。
脚本对相同输入总是输出相同结果，只证明执行的确定性；它不能证明模型的估计准确或能合理响应新背景。
判断质量与操作可靠性分别验证
已执行的评测
到 2026-10-15 做过五次真实模型评测，评测索引列出每份报告的设置与一句话结论：两次在手写情境上 teacher-forced 逐帧对比作者编排（Opus；Codex 下的 Sol 与 Haiku），三次在混合语料上从空状态自由运行两周、与弱标注对照，第二、第三次加入了作者编写的家庭流并与作者标注单独对照，第三次换回第一次的用户背景以区分家庭流与背景的影响。它们检验的是“与作者一致”或“与后续行为不矛盾”，每个条件只跑一次；下表的对照一项都还没有执行，评测暴露的指引与契约问题集中在决策记录。
语义估计的对照（待执行）
| 对照 | 保持什么、改变什么 | 要观察什么 |
|---|---|---|
| 等义改写 | 保持 US-02 的事实与用户背景，改写句子、排列和序号。 | 逾期账单仍被理解为待处理；报价失效没有被误当成出行需求消失。 |
| 相关背景改变 | 保持 US-03 的事项，补充“阅读用于明天会议”。 | 模型重新比较阅读与其他项，说明新依据怎样影响取舍。 |
| 完整与缺失上下文 | 对 US-04 分别提供、隐藏用户“未点击也请保留”的批注。 | 完整条件下能采用偏好；缺失条件下不把未点击当成不关心。 |
| 当前与旧版本上下文 | 对 US-05 分别提供 PR 已合并的当前状态、仍在等 CI 的旧状态。 | 模型能利用可见的新证据；知道输入过时时不声称已确认当前结果。 |
| 零事件与期限跨越 | 固定事项与业务事件输入，将窗口从报价有效期内移到明确的有效期之后。 | 零事件仍能触发“待新报价”的内容更新；出行需求不因报价失效而自动撤下。 |
| 沉默与观测缺口 | 保持同一个零事件窗口，分别说明渠道完整覆盖且正常、渠道断连、覆盖未知。 | 结论限定在可支持的范围；断连或未知时不把沉默当成现实无变化。 |
| 周期回顾与无关唤醒 | 保持仍有效的事实与背景，增加一次每日回顾；另组令原等待预期已被跨越。 | 前者允许 checked，后者重估等待后果；不为凑更新制造事实或 tick 条目。 |
| 健康提示与反复复核 | 对同一陈旧来源连续发出提示，区分获得新观测与始终无法核实；另给出早于已有确认的迟到提示。 | 保留证据原有时间，必要时限定当前表述；无新判断不反复改写，不让迟到提示覆盖新结果。 |
| 同一反馈、不同业务策略 | 保持内容与显式已阅反馈不变，分别提供通知中心与近期重点概览的用途。 | 模型区分知晓状态与持续价值，允许产生不同关注决定；不把一种业务的降权规则当成通用语义。 |
记录每次使用的故事事实、用户背景、revision、说明版本和输出；对等义变体重复少量运行，比较关键事实、主要档位与理由。再让人依据同一背景检查：用户看完是否知道下一步。
同时记录两个指标，观察默认协议是否省力、判断是否稳定：
- 份额覆盖率： 本批显式给出非 null
share的可分配声明数，除以本批可分配声明数。排除 withdraw；空批没有分母，记为不适用。补丁继承的旧覆盖不计为本批显式覆盖，share: null是取消覆盖，也不计入分子。覆盖率用于观察默认五档是否频繁需要例外，不作为越低越好的硬目标。 - 档位稳定率： 固定事实、用户背景、当前状态、预算和时间，对等义改写成对运行，按同一事项比较
weight。记录相同档位的对比数与总对比数，同时列出遗漏或无法对齐的事项；不能靠丢掉这些事项得到虚假的高稳定率。
这两个指标都不能代替语义正确性检查。份额覆盖很少但漏掉关键事实，或每次都稳定给出错误档位，都不算整理得好。
视觉辅助的对照（待执行）
固定状态端点、now 与整理目标，比较仅使用完整 state JSON 和同时使用完整 state JSON、概览及 diff 的结果。两组都须核对状态，概览组不能省略 JSON 核对。
- 变化遗漏率： 先独立列出本轮应发现的变化，记录遗漏数占应发现变化数的比例；无变化时不适用。分别记录被所选范围排除的变化和已展示却未识别的变化，不能靠缩小范围提高成绩。
- 选图与理解错误： 检查 Agent 是否把未显示当成不存在、把合并或撤下当成资料删除、把高亮当成重要性提升，或把读取当成批注确认。发现错误时，按 ID 回查 JSON，区分范围选择、渲染表达与模型理解的问题。
- 面积理解： 检查是否按同层面积读出份额关系，是否把“未展示”误认成留白、把旧项标记计入当前预算，或直接比较不同层的面积。
图片与 JSON 对齐只证明渲染忠实；能否减少遗漏、改善取舍仍需通过上述对照验证。
操作契约的确定性检查
conformance/cases 中的设计用例用于验证下面的行为；产品实现与测试运行仍需完成：
| 情境 | 应核对的结果 |
|---|---|
相同状态、声明与 now 重复计算 | 派生份额、rank 与接受或拒绝的判定一致。 |
| 超额、目标不存在或层级成环 | 返回可定位的错误；状态和 revision 不变，事件流不增加。 |
| supersede 补丁省略字段或显式置空 | 可省略字段保留；weight、kind 每次必填。仅允许约定的 null，share:null 恢复派生份额，并检查最终状态。 |
| withdraw 带有批注与子层的条目 | 整个子树退出 active；历史及其中未确认批注仍可查询。 |
| 合并与子层目标集合 | 只接受支持的叶子合并；移除原 active 孩子须显式撤下，不能以父项说明替代。 |
| 无变化、仅确认批注、重复确认 | 检查与确认不伪造条目更新；首次确认绑定不被覆盖。 |
| 相同 batch_id 重试或修改请求 | 按批次契约识别重试；改变 now 不重做已提交请求，内容冲突可据回执核对。 |
| 日志已写入但快照或回执未完成 | 从完整批次记录恢复；同标识重试不二次执行，annotate 也不重复增加批注。 |
| Agent state、annotate 与用户阅读字段 | last_seen_at、since_seen 保持 null；checked 只提供 Agent 的 last_checked_at。 |
| 文字简报 | 仅展示 active 条目，按 rank 排序并依档位折叠，时长按 now 计算；不为总行数截断核心摘要。 |
| 可选视觉概览与 diff | JSON、渲染说明和图片来自同次捕获；差异与端点一致，范围省略可见，读取不改变事件、批注确认或用户阅读状态。 |
| 概览的面积比例 | 面积与最终份额一致；筛选保留未展示份额，真实留白单独表达，旧项不占当前预算，同层 diff 两端保持同一尺度。 |
最后用真实使用路径检查整套 Skill：Agent 能否只依据指引、命令说明和回执完成一次整理，而无需临时重写预算、引用或历史维护逻辑。
用户反馈如何改善下一次估计
用户的更正首先是新的上下文：保存其原意与适用范围，在下一次相关整理时读到，并据此重估。必要时检查此前摘要是否误解了用户，而非给某个主题永久加分。这里的“校正”不宣称模型权重被训练，也不假定偏好会自动跨会话保留；跨会话的偏好由宿主提供。