Wiki Review

Wiki Review Skill

定位

针对用户指定的单个 wiki 页面，做三件事：

1. 对齐 value-invest 模板：保证多次更新后章节顺序与命名仍然统一
2. 过期内容归档：把已被替代/已触发的内容移到「历史观察」附录
3. 错误信息直接删除：被证伪的内容真删，git log 兜底（不归档进历史观察，避免附录变垃圾场）

核心原则：value-invest 模板（skills/value-invest/templates/stock-analysis.md）是 wiki 个股页面格式的 single source of truth。wiki-review 不发明新结构，只做"回归模板"。

适用范围

仅适用于个股页面（wiki/stocks/<sector>/<name>.md，且排除 wiki/stocks/价格区间总览.md 这类索引文件）。其他类型页面：

硬约束

When to Use

触发（必须满足任一）：

• 用户明确说："review 某页面 / 整理某页面 / 归档某页面 / 某页面格式乱了"
• 用户读完一个页面后说"这页面太长 / 重复 / 看着乱"且明确指了页面

禁止触发：

• 用户没指定具体页面（应反问"哪个页面"）
• 用户在请求新分析或 ingest（那是 value-invest / stock-deep-dive 范畴）
• 全 wiki 扫描（不在本 skill 范围）

注：本 skill 不做"主动建议触发"——LLM 无法可靠计数页面历史触发次数，主动建议易误判。统一由用户主动调用。

Source of Truth：完整目标章节顺序

source of truth 是 skills/value-invest/templates/stock-analysis.md（章节 1-11）。完整目标顺序：

加粗章节（2-12）是 value-invest 模板的核心，相对顺序严格不变。其余章节按上述位置排，缺则不强加。

判定：如果页面里某章节既不属于上述列表也不在命名映射表，归类为"未识别章节"，保留在原位置不动，dry-run 中由用户决策。

章节命名映射表

页面里出现以下旧名时，统一改为右列的模板标准名：

合并冲突处理（针对"价格区间与操作 → 投资结论"等需要合并的映射）：

• 如果目标章节（投资结论）不存在 → 直接把候选段改名为标准名
• 如果目标章节存在但无价格区间表 → 把候选段的价格区间表追加到目标章节末尾
• 如果目标章节存在且已有价格区间表（结构相同） → 用候选段更新最新数据（保留最新版），删除候选段
• 如果目标章节存在且已有价格区间表（结构不同，例如锚点档位数量不一致） → 不自动合并，dry-run 中预览两个表内容请用户决策（保留哪个/手动合并）

如果遇到映射表外的差异，dry-run 中标注"建议改名 X → Y，待用户确认"。不擅自改映射表外的章节名。

内容处理矩阵

关键区分：

• A/B/C 是"过去的有效判断"——归档，便于回看决策演化
• D 是"过去的错误"——删除，避免附录变垃圾场，git log 已能追溯
• 「历史观察」只收 A/B/C，不收 D

安全保险：D 类判定必须有 页面内显式证据（明文标注或 verified 值同框出现）。仅凭 LLM 推测"某数字看着不对" → 降级为待用户决策项，不自动删除。

归档格式

页面末尾建立或追加 ## 历史观察（附录） 章节，归档内容用 <details> 折叠：

## 历史观察（附录）

> 本章节归档已被替代或已触发完成的内容，便于回看历史决策演化。所有内容默认折叠。

<details><summary>YYYY-MM-DD v1 估值（已被 v2 替代，原因：通用自动化毛利率年报 verified 39.42% vs 估算 30%）</summary>

[原内容]

</details>

<details><summary>YYYY-MM-DD 已触发的催化剂：Q1 季报存货验证</summary>

[原内容]

</details>

summary 字段强制格式：必须以 YYYY-MM-DD 开头，紧跟归档类型（v1 / 已触发 / 季度数据等）+ 一句话原因/替代源。例：2026-04-27 v1 估值（已被 v2 替代，原因：...）。日期前缀用于自动按事件日期排序。

追加规则：

• 如果页面已有「历史观察（附录）」章节 → 新归档项插入到引导段（如有）之后、首个已有 <details> 之前（即"最新在最上"）；如果章节内没有引导段（纯 details 列表），直接插入到首个 <details> 之前；不动已有项；保留原引导段文字不覆盖
• 如果没有 → 新建在页面真·最后位置（更新记录之后），使用本节示例中的引导段文字
• 排序口径：按 summary 开头的 YYYY-MM-DD 降序排列（不是 review 当天日期）。事件日期来自被归档内容的原始时间戳（如 v1 估值的创建日、催化剂触发日、季度数据所属季度）；如果原内容里没有可识别的日期，回退到 review 当天日期
• 本次 review 只调整本次新增项的位置，不重排已有归档项的相对顺序

⚠️ 错误信息（D 类）不在归档范围——直接删除，不放入「历史观察」。

执行流程

Step 1: 读取目标页面 + 现状评估

章节边界判定：以 ^## 开头的行作为章节起始，下一个 ^## 之前的所有内容（含子标题 ### 、表格、列表、--- 分隔符）属于该章节。frontmatter（--- 包围的 YAML）+ 文档总标题（# ）不属于任何 ## 章节。

适用范围检查：先确认页面路径符合"适用范围"——如果是非 wiki/stocks/** 路径，立即退出并告知用户"本 skill 暂不支持该路径类型"。

读取 wiki 页面（用 Read 工具一次读完整全文，作为 Step 5 用 Write 整体覆盖的基线），输出：

• 总行数
• 现有章节列表（按出现顺序，列出每个 ## 标题 + 起始行号）
• frontmatter 状态（有 / 无 / updated 字段距今天数）
• 是否已存在「历史观察（附录）」章节

早期退出条件（必须同时满足以下全部才退出）：

• 页面 < 80 行
• 且 章节顺序已对齐 value-invest 模板（无"顺序错乱"项）
• 且 无命名映射差异（章节名都是模板标准名）
• 且 页面正文搜索不到以下多版本关键词：v1 估值 / v2 修订 / 前版 / 已修正 / 已删除 / 已证伪 / 校核未通过 / 口径冲突

满足以上 → 告知"页面已对齐且无过期内容，不需要 review"，停止。否则继续。

隐式"基本信息"段处理：很多页面在 H1 标题（# 公司名 (代码)）下直接列基本信息（市场/行业/市值），没有 ## 基本信息 标题。这种"隐式段"保留在原位（H1 之后、首个 ## 之前），不动不重排。如果用户希望规范化为 ## 基本信息 标题，dry-run 中标注请用户决定。

显式与隐式基本信息共存：极少数情况页面同时有"H1 下的隐式段"和"## 基本信息 显式章节"——dry-run 中标注，建议合并到显式章节，由用户确认。

Step 2: 章节对齐 dry-run

对比页面现有章节 vs value-invest 模板顺序，输出四类差异：

特殊处理：

• ## 产品深度分析 (YYYY-MM-DD) 章节由 stock-deep-dive 输出，不重排不归档，但在重排时把所有此类章节作为一个 block 整体放到位置 17（业务结构之后、相关链接之前）

Step 3: 过期内容识别 dry-run

按"内容处理矩阵"A/B/C/D 扫描，分两个清单：

待归档清单（A/B/C）：

待删除清单（D，错误信息）：

待用户决策清单（不确定项）：

Step 4: 输出完整 Dry-Run Plan

## Wiki Review Plan: {页面路径}

### 现状
- 行数：{n}
- 章节数：{n}
- frontmatter：{有/无} {（如有）updated 距今 {n} 天}
- 「历史观察（附录）」章节：{已存在 / 不存在}

### 章节对齐（{n} 项变动）
| 章节 | 当前位置 | 目标位置 | 操作 |

### 过期内容归档（{n} 处，A/B/C 类）
| # | 章节 | 内容摘要 | 归档类型 | 折叠 summary |

### 错误信息删除（{n} 处，D 类）
| # | 章节 | 内容摘要 | 显式证据 |

### 命名修正（{n} 项，按映射表）
| 当前名 | 改为 |

### 不动的内容
- frontmatter 字段（仅更新 `updated`；缺失时不新建，等用户决定）
- 模板章节内的文字内容
- 「信息来源」章节（完全不动）
- 「更新记录」章节内容（仅在末尾追加一行 REVIEW 日志）
- ingest 数据（财报数字、历史事件、原始引用）
- stock-deep-dive 的 `## 产品深度分析 (YYYY-MM-DD)` 章节内容

### 待用户决策
- 未识别章节 {n} 处（列表）
- 模板缺章 {n} 处（列表，是否补齐）
- 不确定的 D 类候选 {n} 处（仅 LLM 推测无显式证据，建议保留）
- 重复章节 {n} 处（如两个 `## 风险提示`，列出来由用户决定合并/保留）
- 合并冲突 {n} 处（如「投资结论」与「价格区间与操作」结构不同，列出两边表内容由用户决策）
- frontmatter 缺失：{是否新建}
- 「更新记录」章节缺失：{是否新建}

---

**请回复确认或调整**，格式建议：
- "全部按 plan 执行"
- "执行重排和归档，但不动 D 类删除"（用户可选择性放弃某类操作）
- "改 X 项：{具体调整}"

> 用户可以选择性放弃某类操作（如不删 D 类只重排），但**不能改变操作类型本身**——例如不能要求"把 D 类错误信息改为归档而不是删除"，因为这违反 skill 的硬约束（D 类必删）。如有此类要求，回应"该操作违反 wiki-review 硬约束，建议手动处理"。

等用户明确确认后才进入 Step 5。如有疑议，按用户指示调整后再次输出 plan，直到用户说"执行"。

用户拒绝 plan 时：终止 skill，输出 已取消，未对 {页面路径} 做任何修改。不留下任何半成品状态。

Step 5: 执行修改

默认用 Write 整体覆盖。仅当本次改动 ≤ 3 处独立编辑点（如只有 1-2 个命名修正、无重排）时才考虑 Edit。理由：重排涉及多章节移动，多次 Edit 中间状态易出错。

Step 5.0：二次 Read 确认

再次 Read 一次目标文件，对比 Step 1 时的快照。如有变化（用户在交互期间手动改了文件、或外部 hook 修改） → 重新做 Step 2-4 dry-run，不可基于过期快照执行。

Step 5.1：构造完整新版本页面文本（基于刚 Read 的全文）

1. 先抽取每个章节的整段内容（按章节边界规则切片）
2. 检测重复章节（如页面里有两个 ## 风险提示）→ dry-run 已询问用户，按用户决策合并/保留
3. 按"完整目标章节顺序"表拼接：

   frontmatter（更新 updated）
   → 文档 H1 大标题
   → 隐式基本信息段（如有）
   → 各 ## 章节按目标顺序（执行命名映射、A/B/C 归档移出、D 类删除、合并冲突按规则处理）
   → 历史观察附录（含本次新增 + 已有，按事件日期降序）
   

4. 在拼接到「更新记录」章节时追加 REVIEW 日志行（只列出本次实际发生的操作，操作数为 0 的部分跳过）：

   - YYYY-MM-DD REVIEW {仅列实际发生项，例如：}重排 5 章节 + 归档 2 处过期内容 + 改名 1 处章节
   

   完整候选片段：重排 X 章节 / 归档 Y 处过期内容 / 删除 Z 处错误信息 / 改名 W 处章节

Step 5.2：写入文件

用 Write 工具一次性整体覆盖原文件。

Alternative：小改动场景用 Edit（仅当 ≤ 3 处独立编辑点且无章节重排时）：

• 先做命名修正（最安全）
• 再做 D 类删除（独立段落）
• 再做 A/B/C 归档（先抽出原内容，再追加到附录，最后删除原位置）
• 章节重排不要用 Edit，必用 Write

边界处理：

• frontmatter 不存在且用户同意新建 → 按 wiki 标准格式新建：tags: [...] / updated: YYYY-MM-DD
• 「更新记录」章节不存在且用户同意新建 → 按 wiki 标准格式新建（追加在「信息来源」之后、「历史观察」之前）
• 重复章节（如两个 ## 风险提示）→ 按 dry-run 用户决策合并或保留
• 「投资结论」与「价格区间与操作」并存 → 按命名映射表"合并冲突处理"规则执行

Step 6: 收尾

• chat 输出 diff summary，只列实际发生的操作（操作数 0 的项跳过）
• 提示用户用 git diff wiki/path/to/page.md 复核

与其他 skill 的边界

协议：value-invest 模板是 source of truth

如果未来 value-invest 模板章节顺序/命名变化，wiki-review 应跟随，而不是相反。建议在 value-invest SKILL.md 加一行注释，提醒模板修改时同步检查 wiki-review 的"Source of Truth"章节与"命名映射表"。

输出位置

直接修改原 wiki 文件。不生成独立 report 文件。