企业官网建设流程全解析

SurfSense 仓库 .cursor 技能库：Update Triggers 与 Cross-Skill Memory Integration 实战指南

【免费下载链接】SurfSenseOpen-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok, Indeed, Google Search, Maps etc) through one platform, API or MCP server. Join our Discord: https://discord.gg/ejRNvftDp9项目地址: https://gitcode.com/GitHub_Trending/su/SurfSense

本指南围绕当前仓库.cursor/skills目录下 SEO/GEO 技能库中 memory-management 技能的核心参考文档 update-triggers-integration.md 展开，系统讲解跨会话项目记忆（Campaign Memory）在特定事件后的更新触发流程、月度与季度归档例行程序，以及它与 keyword-research、rank-tracker、competitor-analysis 等八个 SEO 技能之间的记忆写入与晋升协作机制。读完本文，你将掌握如何在 Claude Code 等 Agent 会话环境中，把"排名检查、竞品分析、内容审计、季度报告"等高频事件自动沉淀为可检索、可归档、可跨技能复用的项目记忆资产。

一、前置背景：三层记忆体系与本文的定位

在进入"更新触发器"细节之前，有必要先理解该参考文档所属的 memory-management 技能的整体架构。根据 memory-management/SKILL.md 的定义，该技能实现了一套 HOT / WARM / COLD 三层记忆系统：

该技能承担"Campaign Memory Loop"的系统角色：定义项目上下文如何被捕获（capture）、晋升（promote）、降级（demote）与归档（archive），并充当跨技能项目状态查询的聚合器。而本文讲解的 update-triggers-integration.md，正是这套体系里"事件驱动写入"与"技能间协作"两大机制的实操规范：

• Update Triggers（更新触发器）：定义在排名检查、竞品分析、审计、月/季度报告等特定事件结束后，应如何系统性地更新记忆；
• Archive Management（归档管理）：定义月度与季度两个周期上的记忆清理与冷存储迁移例行程序；
• Cross-Skill Memory Integration（跨技能记忆集成）：定义八个兄弟 SEO 技能产出结果后，各自的记忆写入落点与晋升规则。

这三个部分共同回答了同一个问题：Agent 在一场又一场会话中"做过的事、测得的数据、得出的结论"，如何不丢失、不混乱、不过期地沉淀下来。

二、更新触发器（Update Triggers）：事件结束后的系统化记忆更新

该参考文档的核心主张是：记忆更新不应靠临场发挥，而应被"特定事件"触发并遵循固定流程。文档给出了四类触发事件，下面逐一展开，并结合仓库内相关技能的 SKILL.md 说明其底层依据。

2.1 排名检查之后（After Ranking Check）

排名检查（rank check）完成后，按以下顺序更新记忆：

1. 更新 CLAUDE.md 中的 Hero Keywords 表格（写入当前排名）；
2. 将带日期的快照保存到memory/monitoring/rank-history/YYYY-MM-DD-ranks.csv；
3. 记录发生显著位移的关键词；
4. 更新 CLAUDE.md 中的 "Last Metrics Update" 日期；
5. 若 Hero 关键词位移超过 ±5 位，创建一条预警笔记（alert note）。

其中两条规则有仓库级的直接佐证：

• ±5 位移触发预警与 alert-manager/SKILL.md 中的阈值体系一致：该技能将 "Keyword positions >3 position drop" 定义为 Warning、">5 position drop" 定义为 Critical，预警触发的边界与更新触发器中 ±5 位的警戒线完全对齐；
• CSV 快照的持久化对应 rank-tracker 技能的契约输出。rank-tracker 在 rank-tracker/SKILL.md 中将自己的系统角色定义为"将性能变化转化为增量、预警与下一步行动"，其产出（排名快照）正是写入memory/monitoring/rank-history/的数据来源。

从 references/examples.md 给出的完整示例看，一次规范的排名更新应包含：排名对比表（含 Previous / Current / Change / Target / Status 五列）、Notable Changes 说明、Updated Files 清单（指明 CLAUDE.md 与 CSV 两个落点），以及下轮检查建议时间。这正是"更新触发器"第 1、2、3 步在真实对话中的落地形态。

2.2 竞品分析之后（After Competitor Analysis）

竞品分析结束后，按以下流程更新记忆：

1. 更新 CLAUDE.md 的 Primary Competitors 区块（DA 数值、相对位置）；
2. 将完整报告保存到memory/research/competitors/YYYY-MM-DD-analysis.md；
3. 更新memory/research/competitors/下的竞品概述笔记；
4. 在热缓存（hot cache）中记录竞品的新策略。

该流程与 competitor-analysis 技能的分工清晰：competitor-analysis 负责"分析"（产出关键词、内容、外链、AI 引用、流量份额差距等结论），memory-management 负责"沉淀"。注意 competitor-analysis/SKILL.md 明确将 DA（Domain Authority）作为对标维度，这也解释了为何更新触发器要求同步更新 CLAUDE.md 中的 DA 数值——CLAUDE.md 的热缓存模板（见 references/hot-cache-template.md）中，Primary Competitors 区块的标准格式即为[Competitor] (DA: [X])+ "Our position vs. them" 相对评估。

2.3 审计之后（After Audit）

无论审计类型是技术审计（Technical）、内容审计（Content）还是外链审计（Backlink），都遵循统一流程：

1. 将完整报告保存到memory/audits/[type]/YYYY-MM-DD-[audit-name].md；
2. 提取 Top 3-5 条行动项，写入 CLAUDE.md 的 Current Optimization Priorities；
3. 若审计包含指标数据，同步更新 Key Metrics Snapshot；
4. 若审计催生了新计划（initiative），创建对应的 campaign 条目。

这一流程的"行动项提升"逻辑与 promotion-demotion-rules 的晋升机制呼应：审计报告属于 WARM 层的详细数据，而 Top 3-5 行动项属于需要每个会话都可见的 HOT 层内容，因此必须"提取关键结论写入 CLAUDE.md，把细节留在memory/audits/"。仓库中的 hot-cache-template.md 为 Current Optimization Priorities 提供了标准格式（含 Status、Expected Impact、Deadline 三个字段），可以直接作为行动项条目的模板。

2.4 月报 / 季报之后（After Monthly/Quarterly Report）

周期性报告发布后，执行以下更新：

1. 将报告保存到memory/monitoring/reports/[period]/YYYY-MM-report.md；
2. 用报告数据更新 CLAUDE.md 的 Key Metrics Snapshot 中所有指标；
3. 审查热缓存，降级（demote）过时条目；
4. 更新 campaign 状态；
5. 归档已完成的 campaign。

Key Metrics Snapshot 的字段结构同样由热缓存模板定义：Organic Traffic、Avg. Position、Total Keywords Ranking、Page 1 Rankings、Domain Authority、CITE Score、Last Content Audit Score、Total Backlinks 等，且每个指标都必须保留 "Previous" 列用于环比对比（该要求同时出现在 memory-management SKILL.md 的 Content Validation 检查清单中）。这说明周期性报告不仅是"存档"，更是热缓存指标刷新的数据源——报告驱动快照刷新，快照又驱动下一轮的对比基线。

三、归档管理（Archive Management）：让记忆保持"热而不胀"

记忆系统最大的风险不是记不住，而是记太多导致热缓存臃肿。memory-management 技能对热缓存有硬性约束：memory/hot-cache.md上限 80 行、超过 25KB 需警告并精简（见 SKILL.md 的 Memory Hygiene Checks）。归档管理正是防止热缓存膨胀的例行机制。

3.1 月度归档例行程序（Monthly Archive Routine）

1. 审查 CLAUDE.md，找出 30 天内未被引用的条目；
2. 将过期条目迁移到合适的冷存储（cold storage）位置；
3. 创建月度快照：memory/monitoring/snapshots/YYYY-MM-CLAUDE.md；
4. 压缩旧的 rank-history 导出（保留近期快照以便快速访问）；
5. 用当月新术语更新 glossary。

3.2 季度归档例行程序（Quarterly Archive Routine）

1. 审查整个冷存储目录结构；
2. 压缩超过 6 个月的文件；
3. 创建季度总结报告；
4. 更新 glossary 中的项目时间线；
5. 审计所有活跃 campaign，归档已完成的。

月度与季度例行程序背后的生命周期规则来自 references/promotion-demotion-rules.md，其量化边界为：

• 降级（Demote）：HOT → WARM 的标准是"30 天内未被引用"；WARM → COLD 的标准是"90 天以上未被引用"；
• 关键词降级触发条件：30+ 天未被引用、目标排名已达成并稳定 60+ 天、已不在活跃策略中、被更高优先级目标替代；
• 竞品降级触发条件：60+ 天无显著动态、跌出相关度 Top 5、不再争夺相同关键词；
• Campaign 降级触发条件：完成 30+ 天、被取消或无限期搁置。

月度例行程序覆盖 HOT→WARM 的降级与月度快照，季度例行程序则覆盖更深的冷存储治理——两者共同保证"热缓存保持 80 行以内的可读性，历史数据始终可回溯"。

四、跨技能记忆集成（Cross-Skill Memory Integration）

这是该参考文档的第二个核心主题：memory-management 是协议层（protocol layer）的横切技能，它不产出 SEO 结论，而是作为八个兄弟技能的统一记忆落点。文档逐一给出了每个技能运行后的记忆写入规范，下表为完整汇总：

4.1 与内容质量审计的集成（CORE-EEAT 评分）

当 content-quality-auditor 运行结束后，记忆更新的关键规则是：若 CORE-EEAT 评分 < 60（评级 Poor/Low），必须在 Active Campaigns 区块中标记该页面。这条规则直接对应 content-quality-auditor/SKILL.md 中"80 项 CORE-EEAT 审计、加权评分、veto 检查"的输出模型——审计报告产生评分，而评分低于阈值的页面会被记忆系统提升为需要跨会话跟踪的活跃修复项。同时，各维度得分需留存用于趋势分析（对应 Key Metrics Snapshot 中 "Last Content Audit Score" 字段的 Previous 对比要求）。

4.2 与域名权威审计的集成（CITE Score）

当 domain-authority-auditor 运行结束后，记忆更新要求：保存完整报告到memory/audits/domain/YYYY-MM-DD-cite-audit.md，更新 CLAUDE.md 中的 CITE Score，记录 veto 项状态与维度得分，并与上次 CITE 审计进行对比。仓库中的 domain-authority-auditor/SKILL.md 证实了该评分的构成：CITE Score = C × w_C + I × w_I + T × w_T + E × w_E（按域名类型应用加权权重），且任何 veto 项触发时 CITE Score 直接封顶为 39（Poor）——这意味着记忆系统中"CITE Score 数值"与"veto 状态"必须同时记录，才能在后续会话中正确解读分数。

4.3 集成机制的底层逻辑

从 memory-management/SKILL.md 的 Hook 集成说明可以看到这套协作如何自动化运行：

• SessionStart 钩子：自动加载memory/hot-cache.md，提醒过期的 open-loops 条目，加载memory/wiki/index.md；
• PostToolUse 钩子：任何 WARM 文件写入后，静默刷新 wiki 索引；
• Stop 钩子：提示保存会话发现，自动将 veto 问题追加到热缓存，并向索引追加 changelog。

也就是说，八个技能各自的"记忆写入规范"（上文表格）通过这三类钩子在每次会话中持续执行，无需用户记忆任何内部约定——用户只需要说出"记住这个""保存进度""项目状况"等自然语言触发词（SKILL.md 的 metadata.triggers 中定义了中英日韩西葡多语种触发词），记忆系统就会按本文的规范完成更新。

五、验证检查点（Validation Checkpoints）：如何确认记忆更新到位

该参考文档的流程并非"写了就算"，memory-management 技能在 SKILL.md 中提供了配套的验证清单，用于核对每次更新是否真正落地：

Update Validation（更新验证）：

• 排名检查后，memory/monitoring/rank-history/中存在带日期的快照或导出；
• 竞品分析后，memory/research/competitors/中存在带日期的文件；
• 审计后，Top 行动项出现在 CLAUDE.md 的 priorities 中；
• 月度报告后，指标快照反映最新数据。

Structure / Content / Lookup Validation：

• memory/hot-cache.md存在且不超过 80 行；
• CLAUDE.md 的 "Last Updated" 日期为当前；
• 热缓存中每个关键词都有 current rank、target rank 与 status；
• 每个竞品都有 DA 与位置评估；
• 每个活跃 campaign 都有进度百分比与预计完成日期；
• Key Metrics Snapshot 保留 "Previous" 值用于对比；
• 测试查找流程：引用一个术语，验证能在正确的层级（HOT → Wiki Index → glossary → COLD）找到它。

这套清单既服务于人工复核，也作为 Agent 自查的标准——任何一次事件驱动更新后，都可以对照上述条目确认没有遗漏落点。

六、实践注意事项与边界

结合该参考文档与 memory-management SKILL.md 的 Practical Limitations 一节，在真实项目中使用这套更新机制时需注意：

1. 并发写入安全：多个会话并行时务必使用带时间戳的文件名（如YYYY-MM-DD-ranks.csv），避免覆盖；
2. 冷存储按需加载：WARM/COLD 文件仅在需求触发时加载，热缓存（hot-cache.md）才是跨会话的主通道，因此"重要结论必须提升到 CLAUDE.md"这一原则不能省略；
3. 数据新鲜度：超过 90 天的数据应标记为待刷新，wiki 索引的mtime字段可用于检测过期；
4. 触发阈值对齐：本文中 ±5 位位移预警、评分 < 60 标记、veto 封顶 39 分等规则，分别与 alert-manager、content-quality-auditor、domain-authority-auditor 的阈值定义保持一致，修改任一技能的阈值时需同步核对更新触发器中的对应数值；
5. 从手动到自动化：当前仓库的 skill 体系同时支持"连接 SEO 工具自动取数"与"纯手动数据"两种模式——未连接工具时，排名、DA、指标由用户手动提供（见 SKILL.md 的 Data Sources 一节），更新触发器本身不依赖外部工具即可运行。

七、总结

update-triggers-integration.md 虽然篇幅不长，却承担了整套 SEO/GEO 技能库中"记忆保鲜"的核心职责：它以四类事件触发器（排名检查、竞品分析、审计、周期性报告）定义了 HOT 层与 WARM 层的写入时机与落点，以月/季度双周期归档程序约束了记忆的温度管理，并以八技能的集成规范把 keyword-research、rank-tracker、competitor-analysis、content-gap-analysis、seo-content-writer、content-quality-auditor、domain-authority-auditor 的产出统一收敛进同一套可检索、可对比、可跨会话传承的项目记忆结构。对任何以 Agent 长周期方式运营 SEO/GEO 项目的团队而言，这套"事件驱动 + 温度分层 + 技能协作"的记忆治理模式都值得直接落地复用。

【免费下载链接】SurfSenseOpen-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok, Indeed, Google Search, Maps etc) through one platform, API or MCP server. Join our Discord: https://discord.gg/ejRNvftDp9项目地址: https://gitcode.com/GitHub_Trending/su/SurfSense