section-logic-polisher

段落逻辑润色器（论点 + 论证衔接）

触发条件与路由

• 触发词：logic polisher、section logic、thesis statement、connectors、段落逻辑、连接词、论证主线、润色逻辑。
• 适用场景：sections/S*.md 已存在，但读起来像一座座段落孤岛；你希望在运行 section-merger 前，进行一次有针对性、便于调试的自循环。

目的：弥补即使小节篇幅长、引用密集，论文感仍不足的主要问题：

• 缺少或缺乏力度的论点（第 1 段没有明确提出主张）
• 段落间衔接薄弱（段落彼此孤立，缺少承载内容的过渡句）

这是一个局部的、针对每个 H3 的润色步骤，在起草之后、合并之前执行。

注意：如果主要问题是段落数量过多，请在此检查后运行 paragraph-curator。它只会合并相邻段落之间的边界， 并保留所有文字；语义上的冗余仍应由负责撰写的作者处理。

此技能会阻止哪些问题（不会阻止哪些问题）

阻断项（必须修复）：

• 第 1 段缺少明确的论点／要点结论（内容主张）

非阻断项（仅用于诊断）：

• 连接词计数（例如 “moreover/however/therefore”）。计数可以作为段落彼此孤立的参考指标，但将其强行设为配额往往会造成“生成器节奏”（段首副词）。将这些统计数据视为信号，而非目标。

角色提示词：逻辑编辑（论证脉络）

You are the logic editor for one survey subsection.

Your job is to make the subsection read like a single argument:
- paragraph 1 commits to a clear thesis (content claim)
- each paragraph has an explicit logical relation to the previous one
- bridges are content-bearing (contrast/causal/implication), not slide narration

Constraints:
- do not add new citations
- do not change citation keys
- do not invent facts

Editing lens:
- if a paragraph does not advance the argument (claim/contrast/eval/limitation), compress or delete it
- if a transition is empty, rewrite it as a content-bearing bridge

输入

• sections/（预期包含 H3 正文文件，如 S<sec>_<sub>.md）
• outline/subsection_briefs.jsonl（将 thesis + paragraph_plan[].connector_phrase 用作意图依据）
• 可选：outline/writer_context_packs.jsonl（优先使用；包含精简后的锚点／比较信息 + must_use）

输出

• output/SECTION_LOGIC_REPORT.md（论点的 PASS/FAIL；显示连接词统计数据供诊断）

手动／LLM 优先（原地修改）：

• 更新 sections/ 下的 H3 正文文件（例如 sections/S<sec>_<sub>.md），修复论点／衔接（不新增引用；保持键稳定）

工作流（自循环）

1. 运行检查脚本，找出确切的失败文件。

2. 对每个失败的 H3 文件：

• 修改具体的 H3 正文文件（路径模式）：sections/S<sec>_<sub>.md

• 将 outline/subsection_briefs.jsonl 作为小节论点和段落规划意图的准确信息来源。

• 如有，优先使用 outline/writer_context_packs.jsonl，以确保与 must_use 锚点／约束保持一致（不新增引用）。

• 论点（阻断项）

  • 让第 1 段以一句结论优先的论点句收尾。
  • 优先使用内容主张，而非元叙述。避免反复使用 This subsection argues/surveys ... 之类的开头。
  • 最精简的结构（3 句话；改述，不要照抄）：
    1. 主张／张力
    2. 其重要性（与协议／评估的相关性）
    3. 小节将如何化解这一问题（将采用哪些对比／锚点）

• 脉络衔接（仅在需要时修复）

  • 在段落显得衔接不畅之处增加 1–2 句简短的过渡句。
  • 优先使用主题在前的句子以及句中衔接词（because/while/which），而非段首副词。
  • 避免使用 PPT 式导航语句（Next, we ...、We now turn to ...）。

3. 重新运行检查器，直至 output/SECTION_LOGIC_REPORT.md 显示 PASS，然后 继续执行 paragraph-curator、evaluation-anchor-checker、最终的 argument-selfloop 快照，并进行合并。

示例

论点信号（第 1 段）

不佳（仅介绍主题）：

• Tool interfaces vary across agent systems, and many recent works explore different designs.

更佳（结论优先的主张）：

• A central tension in tool interfaces is balancing expressivity with verifiability; as a result, interface contracts often determine which evaluation claims transfer across environments.

不佳（元叙述）：

• This subsection argues that memory is important for agents.

更佳（内容主张）：

• Memory designs trade off retrieval reliability against write-time contamination, and this trade-off shows up as distinct failure modes under fixed evaluation protocols.

衔接段落（避免段落孤岛）

不佳（彼此无关）：

• X does ...（第 2 段）
• Y does ...（第 3 段）

更好（明确关联）：

• Whereas X optimizes for <axis>, Y shifts the bottleneck to <axis>; under fixed budgets, this changes whether the reported gains reflect better planning or simply more expensive search.

完成标准

• output/SECTION_LOGIC_REPORT.md 显示 - Status: PASS
• 没有任何章节文件包含占位符（TODO/…/...）或提纲元标记（Intent:/RQ:/Evidence needs:）
• 每个 H3 都有明确的第 1 段论点；仅在衔接确实不顺畅时添加过渡内容

脚本

快速开始

• uv run python .codex/skills/section-logic-polisher/scripts/run.py --workspace <workspace>

说明：

• 该脚本用于检查，不会改写正文。
• 脚本会输出连接词统计数据以供诊断。不要“为了计数器而写作”；要围绕论证展开。

所有选项

• --workspace <dir>
• --unit-id <U###>
• --inputs <semicolon-separated>
• --outputs <semicolon-separated>
• --checkpoint <C#>

示例

• 默认运行：

  uv run python .codex/skills/section-logic-polisher/scripts/run.py --workspace <workspace>

• 指定输出路径（极少需要覆盖；建议使用默认值）：

  uv run python .codex/skills/section-logic-polisher/scripts/run.py --workspace <workspace> --outputs output/SECTION_LOGIC_REPORT.md