reflect-and-improve

反思与改进

这是一个元技能，会在此工具包中的其他技能生成产物后运行。它会诚实地提出一个问题：根据目标衡量，这项改动真的让论文变得更好了吗，还是只是让它变得不一样？ 它会根据（a）目标、（b）论文的 .paper-memory/profile.yml、（c）适用于该任务的评分标准，以及（d）过往的 .paper-memory/lessons.md 来评估新产物；在严格的预算内迭代；拒绝接受会降低可量化分数的改动；并记录经验教训，让下一篇论文从一开始就做得更好。

它是副驾驶，而不是驾驶员。它提出建议；作者决定并进行编辑。

何时使用

• 在 polish-prose、write-rebuttal、write-abstract、 preflight-check、tailor-to-venue、draft-related-work 或任何 会生成产物的技能之后使用，并进行审慎的第二轮检查——“新版本真的更好吗，还是我引入了退步？”
• “在我保留这次改写前，反思一下／评估一下／自我审查一下。”
• “我的编辑有帮助吗？”／“这变好了吗？”／“我该撤销吗？”
• 记录可长期复用的经验教训（例如“我们总是过度弱化摘要中的表述”），让整个工具包在这篇及今后的论文中不再重犯。

何时不使用（请诚实评估成本）

反思意味着额外进行一轮大模型处理，还需要作者投入精力。只有存在可量化或有评分标准支撑的目标时，它才有价值。以下情况应跳过（或只进行一次快速检查）：

• 没有可供衡量的目标——纯粹基于偏好的编辑（例如没有评分标准，只要求“听起来更好”）归根结底只是品味问题；读一遍就够了。
• 生成产物的技能已经给出一个明确分数，且分数没有变化（例如，预检前后都没有问题）。重新运行检查器本身就是反思；直接这样做，无需再进行文字评估。
• 产物非常短（例如只改一行）。循环带来的额外开销超过了它的价值。

如果用户要求反思无法量化的内容，请告知这一点，然后提供单轮检查。

输入

1. 要评估的产物：新文本／文件（最好也提供它替代的版本，这样就能通过差异而非感觉来判断“是否更好”）。
2. 目标：生成产物的技能需要实现什么，用一句话说明（“将摘要缩减到 200 词，同时不遗漏贡献”“回应 R2 对可靠性的质疑”）。
3. .paper-memory/profile.yml——作者／论文的定位信息。如果文件不存在，请先用 paper-profile 创建（或手动填写以下最低限度的字段）。没有定位信息的反思只会给出泛泛的建议。
4. 可量化目标（如有）：
   • 脚本评分（预检错误数量、polish-prose 的可读性／模糊措辞计数、摘要词数与投稿场所的限制、引用核验失败数）；
   • 或 references/ 中的评分标准（或 simulate-reviewers/references/rubrics.md 中的评分标准），并在修改前后按 1–5 分评分。
5. .paper-memory/lessons.md——在开始时阅读，以便让评估结合具体情况，避免重复已记录的建议。

.paper-memory/ 约定

在用户的论文工作目录中按项目创建的目录（绝不放在此仓库中）。该技能会在使用时创建此目录。请告知用户将 .paper-memory/ 添加到其 .gitignore 中，除非他们希望将定位和经验教训与论文一同纳入版本控制。此目录仅存储在本地；不会上传任何内容。

• profile.yml — 领域（systems/theory/applied/empirical/survey/position）、贡献类型、目标受众与会议档次、风险偏好、写作偏好（链接到 match-style）、限制条件。最简起始模板见 references/paper-memory-schema.md。
• lessons.md — 持续积累、去重并注明日期的经验教训。其他技能（preflight-check、polish-prose、verify-citations、simulate-reviewers）发现问题时会在此追加内容，并在启动时读取此文件。格式和维护规则见 schema 参考文档；这些规则由 scripts/reflect_log.py 强制执行。
• decisions.md — 关于会议、赛道和定位的决策及其理由（由 select-venue / plan-submission 写入）；此处会读取该文件以了解背景。

流程

此循环采用有界的反思 / 自我优化：评析 → 修订 → 重新评分 → 仅在可测量地有所改进时保留。限制迭代次数；无提升时停止。

1. 确定基线——先测量。 在评析之前，先记录成果相对于目标的当前分数。选择成本最低且有效的测量方式：如果产出该成果的技能有检查器，就重新运行检查器（优先采用——结果具有确定性）；否则，按相关评分标准打 1–5 分。记录如下：

   python3 scripts/reflect_log.py score --memory .paper-memory \
       --skill polish-prose --metric hedge-count --before 11
   

   如果没有可测量的目标，请明确说明，进行一次定性评析后停止——不要假装存在某个数值。

2. 读取记忆。 提取反复出现的经验教训，避免重复过去的建议或再次引入已知回退：

   python3 scripts/reflect_log.py recurring --memory .paper-memory
   

   读取 profile.yml。对于重视表达风格的立场论文，“收紧每个句子”的评析并不合适；对于风险偏好较高的系统论文，“增加更多保留语气”的评析也不合适。根据 profile 调整评析。

3. 依据四个锚点进行具体评析，并逐项列出发现：

   • 目标——是否完整且仅完成了所要求的具体事项？
   • Profile——是否符合领域、受众、投稿场合级别和表达风格？
   • 评分标准——根据相较于上一版本的表现，为适用维度（严谨性、清晰度、新颖性阐述、答辩回应度）打 1–5 分。
   • 经验教训——是否重复了已记录的问题，或解决了这类问题？ 按 {退步/改进之处、证据、最小修正方案} 的格式逐项撰写。

4. 作出决定——回退防护不可妥协。 以与基线相同的方式计算修改后的分数并进行比较：

   python3 scripts/reflect_log.py score --memory .paper-memory \
       --skill polish-prose --metric hedge-count --before 11 --after 6
   

   脚本会输出分差和判定结果。绝不接受任何导致可测量分数下降的改动（预检错误增多、评分标准平均分降低、超过字数上限、出现新的引用错误），即使文字“感觉”更好也不行——可测量的退步胜过主观感受。结果：保留（可测量地有所改进）／还原（可测量地变差——建议采用上一版本）／持平（没有可测量的变化——由作者自行决定，不要再浪费一次迭代）。

5. 在预算内迭代。 如果判定为保留，但仍未达到目标且未超过迭代上限（默认总共 3 轮），则针对最重要的一项发现进行重点修订，然后返回第 4 步。出现以下情况时停止：达到目标、达到迭代上限，或连续两轮没有可测量的提升（收益递减——这是应当停止的可靠信号）。

6. 追加长期有效的经验教训。 如果循环发现值得保留的规律，请记录下来，去重并标注日期：

   python3 scripts/reflect_log.py append --memory .paper-memory \
       --skill polish-prose --scope recurring \
       --issue "abstract over-hedges the contribution" \
       --rec "state the result as a claim once, then qualify in the body"
   

   对于针对特定论文的备注，使用 --scope this-paper；对于跨论文的规律，使用 recurring（此类记录永不清除）。脚本会按 (skill, issue) 去重并写入日期。

7. 维护。 定期清理过时的 this-paper 经验教训，并执行数量上限（recurring 经验教训始终保留）：

   python3 scripts/reflect_log.py prune --memory .paper-memory \
       --keep 50 --stale-days 365
   

   关于此流程实现的模式及其失效方式（奖励作弊、迎合式自我肯定、来回摇摆），请参阅 references/reflection-loop.md；关于文件格式，请参阅 references/paper-memory-schema.md。

输出

• 一份评析：按锚点（目标 / profile / 评分标准 / 经验教训）列出发现，每项均附证据和最小修正方案。
• 一项有前后分数支撑、而非凭感觉作出的保留 / 还原 / 持平判定。若判定为还原，请建议采用上一版本，并说明哪项测量结果下降。
• 零条或多条追加至 .paper-memory/lessons.md 的经验教训。
• 如实说明置信度，以及反思无法测量的内容。

根据学科调整

此循环和记忆机制与具体领域无关；只有评分标准和指标带有计算机科学领域的倾向。将你所在领域的评审表替换为评分标准，将投稿场合的篇幅 / 格式限制替换为脚本指标，并将你的引用格式替换为验证钩子。.paper-memory/ 架构保持不变。

防护原则

• 绝不接受可衡量的退步。 分数降低就必须回滚，无论新版本感觉多好。这正是此技能的全部意义。
• 反思并非没有成本。 说明成本；没有可衡量的目标时，跳过迭代循环，改为提供单轮处理——不要为了迭代而凭空编造指标。
• 循环次数有限。 设置严格的迭代上限；没有可衡量的提升时就停止。绝不无限循环。
• 不要自我吹捧。 默认不要批准自己之前的输出；由基线测量结果裁决，而不是依据你之前的推理。
• 绝不捏造分数、评分标准数值或“改进”——要么进行测量，要么说明无法测量。引用问题交由 verify-citations 处理，格式问题则直接由 preflight-check 拒绝。
• 绝不向任何地方提交内容；绝不承诺会被接受。.paper-memory/ 保持本地——提醒用户将其加入 .gitignore。