version: "1.0.0" name: review-loop description: 复盘闭环——把记忆里"待验证"的决策拿出来对照实际走势，回填真实结果并提炼教训。当用户说"回顾一下我这段时间的操作""我上次的判断对了吗""帮我复盘""最近哪些判断错了"时使用。

复盘闭环

何时使用

• "回顾一下我这段时间的操作"
• "我上次的判断对了吗？"
• "帮我复盘一下最近两个月的决策"
• "最近哪些判断错了？"
• "我之前记的那个看法，后来怎么样了？"
• "看看我这段时间胜率怎么样？"

核心机制

记忆库不是日记本，是要结账的账本。记一条决策时，结果还不知道，所以 outcome 先写"待验证"。过一段时间真实走势出来了，复盘闭环就是把同一个 decision 再记一次，把 outcome 换成真实结果，relation 从占位的 no_effect 改成真实因果（caused/enabled/prevented/no_effect）。

三个关键动作，缺一不可：

1. 查：用 causal-memory-search_causal 找出 outcome 里带"待验证/预期/预计/关注后续"字样的旧决策——这些就是账没结的部分。
2. 核：对每条决策去核对实际发生了什么（涨了还是跌了、判断的方向对不对、时间窗口对不对）。能拿行情数据就拿，不要凭印象。
3. 写：用 causal-memory-record_decision 把同一条 decision 文本再记一次，outcome 写真实结果、relation 写真实关系、context 补上复盘时的新事实。同一 decision + 同一 task_tag 会被系统认成"同一条经验的新证据"，从而覆盖旧结论。

什么时候回填：只在结果真的明朗之后回填。判断周期未走完、走势还在半路的，保持"待验证"不动，不要为了凑数提前写结论——污染记忆库比空着更糟。

回填后如果发现新旧结论打架：不要手工抹掉旧记录，用 causal-memory-resolve_updates 让系统判断新证据是否推翻旧教训，正式做超替（supersede），旧记录仍然可审计。

如果发现某条经验本身就是错的（比如当时记反了因果方向）：用 causal-memory-invalidate_decision 软失效掉，附上理由，不要硬删。

工具链

A. 查记忆（只读）

1. causal-memory-causal_directory(limit) —— 先看最近决策目录，快速定位这段时间都记过什么。这是最省事的入口。
2. causal-memory-search_causal(query, task_tag, limit) —— 按主题或任务类别检索历史决策。

• 找待验证项：query 传"待验证""预期""预计""关注后续"，或直接传用户说的主题（如"光模块""半导体""我的操作"）。
• task_tag 用用户的操作类型，如 trade-review、market-judgment、sector-call；不确定就不传，先宽搜。

1. causal-memory-search_memory(query) —— 不确定该查事实还是查决策时用，一次融合检索。
2. causal-memory-search_facts(query) —— 需要核对"我当时设定的参数/偏好是什么"时用（比如止损线、仓位上限当时定的是多少）。
3. causal-memory-search_patterns(query) —— 找出跨任务的共性：哪些判断反复错、哪些是重复成功、哪些互相矛盾。这是提炼教训的富矿。
4. causal-memory-reconstruct_lesson(query) —— 当某一类决策反复出现时，让它重建一段完整教训叙事，比自己一条条拼更接近"经验"。
5. 核对实际情况时配合数据工具：用 astock-data-get_a_hist 取真实涨跌与时间窗口，必要时用 causal-event_study 验证事件窗口——拿到实际走势后再下「对了/错了」的判断。

B. 写记忆（会落库）

1. causal-memory-record_decision(decision, outcome, relation, task_tag, context, confidence_source) —— 本技能的核心写操作。复盘时对每条待验证决策调一次：

• decision：必须和当初记的完全同一条文本（可原样复制，也可用同一句核心判断），否则系统认不出这是同一条经验的新证据。
• outcome：真实结果，写具体——"第 3 个交易日方向反转，区间 -6%，判断错"，而不是"跌了"。
• relation：真实关系，只能是 caused / enabled / prevented / no_effect。
• 决策确实导致了好结果 → caused
• 决策为结果创造了条件但不是唯一原因 → enabled
• 决策避免了一个坏结果 → prevented
• 有决策和没决策都一样，纯属碰巧 → no_effect（不要为了好看全写 caused）
• task_tag：与当初一致，否则会被当成另一类任务。
• context：复盘时的处境，写清时间窗口、行情环境、当时的关键约束。同一 task_tag + 相近 context 才会被系统当作可比分支，未来做反事实对比时才有证据。
• confidence_source：复盘结论来自客观数据用 temporal（时间已验证）；来自规则判断用 rule；来自用户确认用 user_feedback；模型推断用 llm_inferred。复盘场景优先 temporal 或 user_feedback。

1. causal-memory-record_fact(key, value, scope, confidence) —— 复盘后发现稳定的新事实才记（例如"该标的日波动常超 5%，不适合窄止损"）。不是复盘主产物，别滥用。
2. causal-memory-resolve_updates(limit, apply) —— 发现新旧结论矛盾时调用。先 `apply=false` 预览，逐条看过判断是否合理，确认无误再 apply=true 落地。
3. causal-memory-invalidate_decision(edge_id, reason) —— 确认某条旧经验本身记错了（因果方向反了、数据源错了），软失效并写明理由。

C. 校准检查（做完复盘顺手看一眼）

1. causal-memory-prediction_report() —— 看历史反事实预测的实际命中率。如果这个数字持续偏低，说明决策前的预测环节本身不可靠，而不只是某次判断错了，值得在结论里点出来。

输出格式

复盘输出必须包含以下小节，缺一不可：

1. 复盘范围：本次覆盖的时间区间、检索到的待验证决策条数、实际完成核对的条数（没核对完的要说清为什么，例如"3 条周期未走完，保持待验证"）。
2. 逐条核对表：每条一行或一块，含 决策原文 / 原预期 / 实际情况 / 判定（对 / 错 / 部分对 / 周期未走完） / 回填的 relation。
3. 命中率统计：写清分母——已结账条数中判断正确 X 条，命中率 X%。周期未走完的不计入分母，单独列出。可附按 task_tag 或板块的分组命中率。
4. 提炼出的教训：那些已写入记忆的教训（列出 decision 核心句 + relation），而不是泛泛而谈。反复错、反复对的模式要单独点名。
5. 矛盾处理记录：调用了 resolve_updates 的，说明预览结论与实际落地了哪几条；调用 invalidate_decision 的，说明失效了哪条、为什么。
6. 未结账清单：仍然"待验证"的决策列表及其预计的验证时点，方便下次继续复盘。

记忆价值

只记不复盘，记忆就是一堆死数据；坚持复盘，它会变成三样东西：

• 你自己的命中率曲线：同一类判断（某个板块、某种战法）长期对得多还是错得多，一眼可查，不用靠感觉。
• 可比的因果证据：因为每条都带了 context，未来做决策前用 causal-memory-counterfactual_query 对比两个选项时，才有真实的历史分支可比，而不是空对空。
• 能被推翻的教训：新旧证据打架时由 resolve_updates 正式超替，错误经验由 invalidate_decision 软失效——记忆库会自己纠错，越用越准。

用久了，causal-memory-reconstruct_lesson 能直接讲出"你在什么行情下容易错"这种个人化的经验叙事，这是任何通用模型都给不了的。

合规边界

• 本技能只做记录与呈现：记录已发生的决策与结果，呈现历史命中率、分布与统计。
• 不输出买卖建议、不判断"接下来该买什么"、不给目标价、不做收益承诺。
• 命中率、胜率是历史统计，明确标注样本量与时间区间，不等于未来表现，不构成对未来结果的保证。
• 复盘结论一律表述为"过去这段时间的判断表现如何"，不表述为"因此现在应该怎么做"。
• 涉及具体标的的历史涨跌，来自行情工具的真实数据时注明数据来源；无法核实的写"未核实"，不要补一个看起来合理的数字。

常见问题

1. "待验证"的决策搜不出来怎么办？ 先把 query 放宽：直接搜用户说的主题词，或用 causal-memory-causal_directory 拉最近决策目录人工扫一遍。当初 outcome 如果没写"待验证"字样，用主题词 + task_tag 宽搜比用关键词更有效。
2. 回填时 decision 文本写得不完全一样，会不会变成两条？ 会。同一条经验的新证据要靠 decision 文本 + task_tag 才能对上，所以最稳的做法是把原决策文本原样复制过来，只改 outcome / relation / context。写完用 search_causal 复查一眼，确认没有出现孤立的重复条目。
3. 没走完周期的决策要不要先回填？ 不要。提前写结论会污染记忆库，让未来的反事实对比建立在假证据上。宁可留在"未结账清单"里，下次再复盘。
4. relation 全都想写 caused？ 克制。判断对了但其实是市场普涨、属于运气，就该写 no_effect。诚实标注运气，命中率统计才有意义。