wiki-crystallize

Wiki 晶化

将短暂的对话提炼为持久、结构化的维基知识。

---

配置发现

每次调用都从这里开始。 维基根目录是包含 wiki-config.md 的目录。技能会在运行时确定该目录。此技能写入的页面遵循 wiki-schema.md 中的结构——这两个文件都必须存在。

1. 确定范围：确定你的文件系统范围根目录，即文件系统工具可访问的顶层目录。

2. 范围检查——必须停止：如果范围是裸驱动器根目录（C:\、D:\、/）、操作系统根目录或用户主目录（C:\Users\X、/home/X、/Users/X）→ 立即停止。不要搜索。不要尝试查找 wiki-config.md。直接转到步骤 6。

3. 检查 <available_skills> 中是否有 wiki-config。 记下它是否可用——这会影响下方的建议。捆绑的 references/setup-help.md 也可用；如果用户需要指引或你遇到困难，请阅读该文件。

4. 查找并读取 wiki-config.md：递归搜索（找到第一个匹配项，最多 5 层）。如果找到，请读取它（blacklist、index_excludes、ingested_folder、ingested_subdirs、log_format）。如果未找到，跳到步骤 6。

5. 查找并读取 wiki-schema.md——强制检查：在与 wiki-config.md 相同的目录中，确认 wiki-schema.md 存在且能解析为 YAML。**在明确判定其状态之前（存在 / 缺失 / 格式错误），不要继续执行下方的工作流。**然后：

   • 存在且解析无误 → 读取架构（mandatory_fields、conditional_fields、enums），然后继续执行工作流。

   • 缺失 → 停止。不要继续。不要部署。根据 <available_skills> 中是否包含 wiki-config（见步骤 3）确定回复内容：

     • **wiki-config 可用：**严格按此模式输出——"你的维基缺少 wiki-schema.md。运行 /wiki-config 来部署该文件并完成设置。我会等你完成后再继续。" 结束本轮。不要提供捆绑部署；也不要提供其他选项。当 wiki-config 可用时，应使用其引导式流程。

     • **wiki-config 不可用：**提供捆绑的备用方案——"你的维基缺少 wiki-schema.md，且未安装 wiki-config 技能。我可以从捆绑参考文件中部署默认版本，但建议安装 wiki-config，以使用引导式设置。要部署捆绑的默认版本吗？" 等待用户明确确认。用户同意后，从 references/wiki-schema.md 部署。

   • 格式错误 → 停止。遵循相同的两种情况：

     • wiki-config 可用："你的 wiki-schema.md 格式错误。运行 /wiki-config——它提供引导式修复流程，并会保留你所做的自定义内容。我会等待。" 结束本轮。不要尝试修复或用捆绑版本覆盖。

     • **wiki-config 不可用：**指引用户参阅 references/setup-help.md，获取手动修复说明。如果用户明确要求重置（而非将其作为自动备用方案），请警告这会覆盖所有自定义内容，然后在用户明确同意后部署默认版本。

   如果步骤 4 中找到的 wiki-config.md 本身格式错误，也适用相同的两种情况：wiki-config 可用 → 停止并建议运行 /wiki-config，结束本轮；不可用 → 通过 setup-help.md 引导用户手动修复。

6. 完全找不到配置文件：询问用户维基根目录路径，并在该路径下搜索（最多 5 层）。如果仍未找到，则表示用户尚未建立维基——按照上方的“缺失”分支处理（建议运行 /wiki-config；如果该技能不可用，则提供捆绑部署）。

---

能力要求

此技能需要文件系统读写权限。如果当前界面（网页、移动端）不支持该权限，请提出将维基页面生成为可供用户手动保存的文件。

用途

Crystallize 会将聊天中持久有效的信息（决策、发现、模式、未解决的问题）压缩成结构化的 Wiki 页面，让任何后续会话都能比重读整个聊天记录更快地了解情况。

请广泛使用——任何有意义的事情发生时都可以使用。它并非只用于漫长或耗尽精力的聊天。它是会话管理机制：Wiki 是跨聊天周期持久留存的记忆；聊天记录只是脚手架。结束聊天前就进行 Crystallize，不要把它当作事后清理步骤。

保留： 已做出的决策、已建立的模式、吸取的教训、未解决的问题、当前理解、重要发现。 丢弃： 探索性的来回讨论、走不通的方向、过程性聊天、已被取代的草稿。

级别	使用时机	收尾方式
单次会话	工作会话结束；上下文仍有价值	暂停，不要结束
主题线程	线程跨多个会话后变得冗长	建议重新开始
整个聊天	线程已结束或已明确归档	明确结束

---

输入

提供以下任意一项：

1. 线程摘要（用你自己的话）
2. 粘贴的对话记录或导出内容
3. 对已完成事项和已做决策的描述

如果没有提供上述内容，请先让用户描述本次 Crystallize 应记录的内容，再继续。

---

工作流

Config Discovery 已将 wiki-config.md 和 wiki-schema.md 加载到上下文中。不要重新读取；假设两者均已就绪，从这里开始。

步骤 1 - 阅读 Overview.md

阅读 Overview.md，了解当前的知识状态；Crystallize 是在 Wiki 中补充内容，而不是重复已有内容。

步骤 2 - 分析输入

识别持久有效的知识（决策、发现、模式、未解决的问题、当前的最佳理解），并丢弃对话脚手架（探索性的来回讨论、已被取代的草稿、流程步骤、已纳入的更正）。

步骤 3 - 为这些知识找到现有归属位置

扫描候选页面之前，先确认该主题是否属于现有领域。如果该领域存在 Domain Home，它就是首选目标——扫描页面以确认是否合适，而不是寻找其他选项。优先更新枢纽页面，而不是创建新文件。

阅读 index.md 并扫描以下内容：

• 覆盖此主题的 Domain Home（先检查）
• 标题与主题相符的页面
• 该领域的“Current State”或摘要页面

找到高度匹配的页面： 更新该页面。继续执行步骤 4a。

有多个候选页面或情况不明确： 询问用户：“我找到以下可能适合作为归属位置的页面：[列表]。要更新其中一个，还是新建页面？” 等待用户答复。

没有合适的现有页面： 创建新页面前先征求用户确认，除非内容显然自成一体。

关键规则： 有疑问时，优先更新枢纽页面，而不是新建页面。新页面会使知识图谱碎片化；内容丰富的枢纽则会不断积累价值。

步骤 4a - 更新现有页面

读取目标页面当前的全部内容。整合已提炼的知识：

• 将新的决策、发现或待解问题添加到相应章节

• 更新现已过时的章节

• 不要重复已有内容；请进行综合并合并

• description: 重写 - 如果页面的章节结构发生变化、范围有所调整或添加了大量新内容，请重写 description: 字段。对于对现有章节的增量补充，保持 description: 不变。由 Agent 判断。

• 更新 frontmatter 中的 version:、changes: 和 updated: 字段。保留 date: 不变——它是创建日期。递增 crystallize_count:：读取当前值并加 1；如果该字段不存在，则写入 1。

• 检查 page_type： 确认页面的 frontmatter 中存在 page_type，且仍然准确。如果缺失，根据页面内容和结构推断，然后在写入前向用户确认。如果存在，但页面似乎已超出当前类型的适用范围（例如，knowledge 页面现在充当领域枢纽，或 knowledge 页面已发展成比较性综述），请提出升级建议：“此页面的类型是 <type>，但现在看起来更像 <better-type>。要我顺便更新 page_type 吗？” 切勿自动升级；务必先征求确认。

步骤 4b - 编写新页面

确定 page_type 并加载模板：

从架构枚举中选择 page_type。典型的提炼结果包括：knowledge（单主题发现）、domain-home（正在搭建的领域枢纽）、overview（知识库级综合概览）、survey（跨多个条目的比较性发现）。如果类型不明确，请先询问用户。根据架构枚举进行验证（已在上下文中）。

从 wiki-config.md 读取 templates_folder（已在上下文中）。如果存在，尝试读取 <wiki_root>/<templates_folder>/<page_type>.md。如果找到，将其用作正文框架——替换 {{TITLE}}、{{DATE}}、{{PAGE_TYPE}}、{{DESCRIPTION}}，并填入提炼后的内容。如果模板文件缺失，输出一行：“未找到 <page_type> 的模板——使用默认结构。”，并使用下面的硬编码模板。如果配置中没有 templates_folder，则静默跳过查找，并使用下面的硬编码模板。

回退模板（未找到知识库侧模板时使用）：

---
title: Topic - Current State
version: 1.0
date: YYYY-MM-DD
updated: YYYY-MM-DD
crystallize_count: 1
description: "~200 char synthesis of what this page covers"
changes: "Crystallized from [source chat / session description]"
---

# Topic - Current State

## What Was Established
[2-4 sentences: the core finding or current understanding]

## Key Decisions
[Decisions made, with brief rationale]

## Current Understanding
[The substantive content, structured as appropriate: prose, tables, lists]

## Open Questions
[What remains unresolved. Be specific.]

## Related Pages
[[Related Page 1]], [[Related Page 2]]

## Sources

| Title | Publisher | Date | Links |
|---|---|---|---|

使用 index.md 中的文件夹结构，选择最合适的存放位置。不要放入列入黑名单的路径、raw/、archive/ 或 Projects/。如果位置不明确，请向用户确认。

步骤 5 - 更新 index.md（仅限新页面）

如果在步骤 4b 中创建了新页面，请在 index.md 的正确章节中添加一个条目（一句话，不超过 150 个字符）。如果在步骤 4a 中更新了现有页面，则无需更改索引。

步骤 6 - 如有必要，更新 Overview.md

仅当本次提炼代表重大变化时，才更新 Overview.md 中相关的领域章节：例如，达成了重大决策、完成了一个研究阶段，或确立了一个新领域。不要因增量补充而更新。

步骤 7 - 在 log.md 顶部添加条目

在 log.md 中的标题行下方、所有现有条目上方，添加新条目。

## [YYYY-MM-DD] crystallize | <Topic or Chat Name>
Updated [[Existing Page]] with new findings. [or: Created [[New Page]].]
[Brief note on what was captured. Updated Overview.md: yes/no.]

步骤 7b - 提议归档过长的日志

log.md 只会在开头添加内容，且会无限增长；每次运行 crystallize 和 lint 时都会完整读取，因此过长的日志会持续占用上下文。完成步骤 7 的前置添加后，统计 log.md 中的 ## [ 条目数。如果超过 150，则提议归档（不要自动执行）：

"log.md 有 N 个条目。我可以将最旧的 N-50 个条目移至 archive/log-YYYY-MM-DD.md，并在当前日志中保留最近的 50 个条目。现在归档吗？"

如果用户回答是：将移出的（最旧的）条目写入 <wiki_root>/archive/log-YYYY-MM-DD.md——如果该文件已存在（当天早些时候归档过日志），就在现有内容后追加条目；否则创建该文件，先写入标准日志标题，再写入这些条目。然后将 log.md 重写为标题加上最新的 50 个条目。归档是移动条目，绝不删除它们——审计记录会保存在 log.md 和归档文件中；同一天第二次归档时，会追加到现有文件，而不会覆盖。如果用户回答否：保持 log.md 不变。如果条目数为 150 或更少，则不做任何操作，也不提示。

步骤 8 - 选择结束语

阅读两个信号，决定采用哪种结束语：

信号 1：明确表达的意图。 用户是否使用了明确指向整段聊天的措辞来调用 crystallize（例如“在我关闭这个聊天之前”“结束这个话题”“归档”）？如果是，使用正式结束语。

信号 2：话题积累程度。 目标页面的 crystallize_count（步骤 4a 中已读取）是衡量该话题跨会话被 crystallize 次数的持久指标——即使日志归档，该值仍会保留，因此应优先于统计 log.md 条目数。计数较高（此前已多次 crystallize）意味着该话题内容持续累积，适合重新开始；使用正式结束语。计数为 1（首次 crystallize，或新建页面），或会话聚焦且内容较少时，则使用会话收尾语。

注意：无法从技能内部精确测量上下文窗口的占用情况。应根据可观察到的信号进行定性判断。

会话收尾语 - 话题仍有价值，值得保留已建立的上下文：

"已记录。[[Topic]] 汇总了今天的决定和发现。你可以继续当前聊天，也可以开始新的聊天，两种方式都可以。如果继续，这里的上下文仍有价值；如果重新开始，请先阅读 [[Topic]]。"

正式结束语 - 话题内容较多或用户明确要归档：

"现在可以关闭此聊天。[[Topic]] 已汇总所有值得保留的内容。开始下一个会话时，请先阅读该页面；它能比延续当前聊天更快地帮助你建立新的上下文。"

---

关键规则

1. 提炼，而非照录： wiki 页面应比源内容短得多，结构也更清晰
2. 保留长期有价值的内容，舍弃辅助性内容： 果断筛选能持续积累价值的内容
3. 每个页面都要有 Frontmatter： title、version、date（创建日期，不可更改）、updated（今天）、crystallize_count（创建时为 1；更新时先读取再递增）、changes："Crystallized from [source]"
4. 绝不写入列入黑名单的路径
5. 谨慎更新 Overview.md： 仅在知识确实发生重大变化时更新
6. 用 Wikilinks 提升可搜索性： 始终添加指向相关页面的链接