archive

archive 技能概览

archive 擅长解决什么问题

archive 技能适合团队和独立开发者把一次性的会话知识沉淀成可复用的项目记忆。它不会让修复过程继续淹没在聊天记录里，而是会把调试结论、部署备注和流程经验以结构化 markdown 的形式存进 .archive/YYYY-MM-DD/，再在 .archive/MEMORY.md 中维护一个轻量索引。

谁适合安装 archive

如果你经常反复处理同一类基础设施、CI、发布或调试问题，并希望下次更快恢复上下文，这个 archive 技能就很适合你。尤其当你的工作会跨多个 session、多个 agent，或有多位协作者都需要共享“上次到底发生了什么”的记录时，它的价值会非常明显。

它真正要解决的工作任务是什么

用户并不需要再养成一种新的记笔记习惯。他们真正需要的是：在一项有意义的技术任务刚结束时，可靠地保存高价值上下文，并且在下一次类似任务开始前，能把这些上下文重新调出来。archive 的设计围绕的正是这个工作流，而不是泛泛的文档整理。

为什么 archive 不只是一个普通 prompt

普通 prompt 也可以让 AI “总结一下我们做了什么”。但 archive 技能额外提供了可重复执行的存储模式、必须更新的 memory 索引，以及一个会在 session 启动时自动加载 .archive/MEMORY.md 的 hook。这让 archive for Knowledge Bases 真正具备实用性：archive 不再只是一个容易被遗忘的 markdown 文件，而会成为未来工作的上下文组成部分。

安装前要先看清的关键取舍

archive 故意保持简单。它不提供数据库、向量搜索，也没有自动分类流水线。它的价值来自规范的文件结构、可搜索的 tags，以及 memory 索引。如果你的团队不会持续维护 .archive/MEMORY.md，那 archive 技能的大部分优势都会被削弱。

如何使用 archive 技能

archive 安装方式与优先阅读的仓库文件

一个实用的 archive install 路径是：

1. 在你的 skills system 中，从 ReScienceLab/opc-skills 仓库添加这个技能。
2. 先读 skills/archive/SKILL.md，了解整体工作流。
3. 再读 skills/archive/references/TEMPLATE.md，确认 archive 的必备结构。
4. 如果你关心启动时如何加载上下文，再看 skills/archive/hooks/hooks.json 和 skills/archive/hooks/load-memory.py。
5. 最后检查 skills/archive/.factory-plugin/plugin.json，确认它的预期行为。

如果你只能快速扫一份辅助文件，那就优先看 references/TEMPLATE.md；它最直接地告诉你“好的 archive 输出”应该长什么样。

archive 技能需要哪些输入

要让 archive 技能真正发挥作用，最好提供以下信息：

• 已完成的任务或 incident
• 主要结果
• 采取过的关键步骤
• 重要命令、配置变更或代码决策
• 出错点和最终修复方式
• category 和可能用到的 tags
• 任何相关的旧 archive 条目

缺少这些输入，最终生成的 archive 往往会太空泛，后面几乎帮不上忙。

什么时候触发 archive

适合在以下场景使用 archive：

• 一次成功部署之后
• 一次棘手的调试 session 之后
• 一次迁移或基础设施变更之后
• 一个重大功能完成之后
• 用户明确要求“archive this”的时候

不要把它用于每一次小改动。这个技能是为可长期复用的经验设计的，不是为了记录充满噪音的活动日志。

archive 在实际工作流里怎么用

推荐工作流是：

1. 先查看 .archive/MEMORY.md，看看有没有相关历史记录。
2. 创建或复用 .archive/YYYY-MM-DD/。
3. 按模板结构和 YAML frontmatter 写一份 markdown archive。
4. 在 .archive/MEMORY.md 里补一行索引。
5. 通过 related 字段把相关条目串起来。

更新索引不是可有可无的形式动作。未来能不能快速找回内容，关键就靠这一步。

更强的 archive 技能提示词写法

弱提示词：

• “Archive this session.”

更好的提示词：

• “Use the archive skill to document today’s ECS deploy issue. Include the IAM permission error, the CloudWatch clue, the exact fix, final deploy status, tags for ecs, iam, deploy, category infrastructure, and add a one-line entry to .archive/MEMORY.md. If a related archive exists, link it.”

后者之所以更好，是因为它给了模型足够明确的结构，生成出来的内容才真的可以复用。

如何把模糊目标扩展成完整的 archive 请求

如果你最初的想法只是“把我们学到的东西存起来”，那最好进一步展开成：

• 发生了什么
• 为什么这件事重要
• 哪些地方失败了
• 最终靠什么修好
• 下次第一步应该先检查什么
• 这件事属于哪个 category
• 之后别人应当通过哪些 tags 找到它

这个技能更奖励面向检索的写法，而不是讲故事式的写法。

archive 模板里最关键的字段

根据 references/TEMPLATE.md，最重要的字段是：

• tags：用于基于 grep 的检索
• category：用于索引组织
• related：用于把不同时间的 incident 串联起来

在正文部分，通常最有价值的章节是：

• Summary
• Issues Encountered & Solutions
• Key Changes

如果你跳过具体修复细节，archive 的实用价值会明显下降。

session 启动时的 memory hook 会如何改变 archive 的用法

这个 hook 会在 .archive/MEMORY.md 存在时，于 session 启动阶段把它加载进上下文。也就是说，archive 技能不只是“写下来”这么简单，它还能自动增强未来的回忆与检索能力。从落地采用的角度看，这也是比起临时记在某个 note 文件里，更值得安装这个技能的核心原因之一。

archive for Knowledge Bases 与团队记忆

如果从 archive for Knowledge Bases 的角度理解，可以把 .archive/MEMORY.md 看成目录，把每个按日期保存的 markdown 文件看成一次 incident 或任务记录。它很适合以下内容：

• 反复出现的运维问题
• 带坑点的 release checklist
• 特定环境下的修复方案
• 会带来后续影响的设计决策

但它并不适合承载宽泛的产品文档或面向用户的手册。

实际搜索与查找 archive 的工作流

这个技能明确支持一种轻量检索方式：

• 先查看 .archive/MEMORY.md
• 再使用 grep -ri "keyword" .archive/

对于很多工程团队来说，这已经足够，因为保存下来的内容本来就聚焦、技术性强，而且结构明确。tags 要尽量使用未来大家真的会搜的词：服务名、报错字符串、平台名、组件名。

archive 技能 FAQ

如果我本来就会写笔记，还值得安装 archive 吗？

值得，前提是你现在的笔记不容易找到，或者几乎不会重新进入 agent 的上下文。archive 技能的价值在于，它把存放位置、结构、索引方式和 session 启动时的 memory 加载统一了起来。

archive 技能对新手友好吗？

总体来说是友好的。它的工作流本质上就是 markdown 加一个索引文件。新手最常见的风险是把总结写得太抽象。最好直接套用模板，把具体修复、命令和经验教训填进去，这样最容易上手。

什么情况下不该用 archive？

不要把 archive 用在这些场景：

• 琐碎的小改动
• 临时性的 brainstorming
• 长篇正式文档
• 本该写进永久仓库文档（如 README.md 或 runbooks）的知识

如果一条信息应该长期、持续地指导所有协作者，那它更可能属于标准文档，而不应该只存在于 .archive/ 中。

archive 和常规项目文档有什么区别？

常规文档描述的是系统“应该如何工作”。archive 记录的则是某次任务或 incident 里“实际发生了什么”：走过哪些失败路径、最终的准确修复是什么、以及那些最容易丢失的上下文。它是一层历史性的运维记忆，不是 canonical docs 的替代品。

archive 需要特殊工具吗？

不太需要。核心格式就是 markdown 文件加 .archive/MEMORY.md。仓库里还带了一个在 session 启动时加载 memory 的 hook，但即便不用它，archive 技能仍然可以作为一种纪律化的存储模式发挥作用。

这个 archive 指南的边界是什么？

这份 archive 指南反映的是仓库当前真正支持的能力：基于文件的 archive、索引化 memory、简单 category、related 链接，以及基于 hook 的回忆能力。它并不承诺自动摘要流水线、语义搜索或与外部知识库同步。

如何改进 archive 技能使用效果

写 archive 要面向检索，而不是面向叙事

最好的 archive 输出，是以后回看时能一眼扫到重点。把问题、修复方式和关键命令放在未来读者最容易快速定位的地方。相比精致流畅的叙事，一份直白、可搜索的记录更有价值。

使用大家以后真的会搜的 tags

好的 tags：

• 服务名或工具名
• 精确的子系统名
• 部署平台名
• 错误关键词
• 受影响的环境名

不好的 tags：

• 像 issue、work、update 这种过于泛泛的词

这是提升 archive 使用质量里杠杆最高的做法之一。

让 MEMORY.md 真正有用，而不是流于形式

弱的索引条目可能写成：

• “Fixed deployment issue”

强的索引条目应该写成：

• “ECS deploy failed due to missing IAM permission for secret access; resolved by updating task role policy”

索引的目的，是帮助后来的人判断下一步该点开哪一条 archive。

当失败尝试会影响未来决策时，也要记录下来

如果团队在找到正确方案前，先试了两种错误修复，而且这些错误路径能帮助以后避免重复浪费，就应该写进去。这也是 archive 技能经常比标准文档更有价值的地方：它能保留那些真正重要的“走过的弯路”。

想得到更好的 archive 输出，就先提供更好的输入

在让技能执行 archive 之前，先尽量收集：

• 精确的错误文本
• 相关命令
• 改动过的文件或设置
• 最终验证通过的状态
• 为什么最终修复能生效

这些细节会实质性提升后续复用和搜索效果。

archive 技能使用中的常见失败模式

典型问题包括：

• 没有更新 .archive/MEMORY.md
• tags 过于泛化
• 没有清晰的 category
• summary 只有概述，没有操作细节
• archive 条目与过往 incident 没有关联

大多数 archive 结果不佳，原因都不是模板本身，而是输入信息不完整。

第一版 archive 草稿完成后再迭代一次

写完第一版后，检查这些问题：

• 别人能不能用可能的搜索词找到这条记录？
• summary 有没有写清结果和原因？
• 关键命令或配置变更是否已经包含？
• 未来的 agent 能否看完后知道先试什么？
• 是否应该链接到更早的相关条目？

通常只要做一轮很短的二次检查，archive 质量就会提升很多。

把 archive 和永久文档配合使用，而不是互相替代

如果这次 session 暴露出了一条长期有效的规则，也要同步更新 canonical doc。archive 技能应该保存事件级知识，而不应该变成唯一存放关键团队指导信息的地方。

用明确的团队触发条件提升 archive 采用率

当团队预先定义清楚触发条件时，archive 往往更容易落地，例如：

• 每一次有意外情况的 production deploy
• 每一次修复方式不直观的 incident
• 每一次 migration
• 每一次用户要求“save this for next time”

这样既能保证 archive 持续有价值，也不至于被噪音堆满。