为 LLM 更新知识库

让LLM知识库保持鲜活可靠

过时的知识库会导致LLM代理性能出错。文档一旦生成便开始失去时效性——尤其在并行管理数十个项目的场景下。服务变更、状态更新和依赖关系的调整无法自动同步，导致上下文失真。LLM会完全信任所给数据，基于陈旧信息生成解决方案。解决之道在于自动化验证检查，并强制执行行为规则，防止信息熵增。

转向以LLM驱动的开发模式，意味着将重心从重复劳动转移到方法论层面：上下文管理、验证机制与流程组织。工作台作为连接IDE的中心化知识枢纽，却需要持续维护。

自动化文档验证

集成到CI中的验证脚本检查三大核心要素：

• 内部Markdown链接完整性。
• 基于元数据的文档新鲜度（60天阈值）。
• 通过工作区文件实现项目覆盖，确保代理可访问。

首次运行时，会暴露出断裂链接——多为仓库迁移遗留的痕迹。新鲜度检查无需全文重写，只需事实核查。另一脚本汇总Markdown文件中的TODO项，形成部署、CI与项目任务的统一视图。

示例脚本输出：

$ ./tools/validate.sh
[markdown links]
  WARN:  domains/infra/topology.md 中存在断裂链接 -> decisions/adr_007.md
  WARN:  projects/api/architecture.md 中存在断裂链接 -> ../shared/schema.md
  INFO:  189个链接中发现42个断裂

[document freshness — threshold 60d]
  WARN:  过期（87天）：projects/data-pipeline/architecture.md
  INFO:  1份文档超出新鲜度阈值

[project coverage]
  OK:    所有项目均具备工作区文件

=== Result ===
  Errors: 0 | Warnings: 43 | Info: 2

实现方式：300行左右的Bash脚本，专注一致性与可复现性。

文档状态与生命周期

文档按状态分类：活跃、参考、草稿、归档。这有助于代理区分当前内容与历史产物。

• 活跃：每周更新，如战略路线图。
• 参考：稳定不变的协议说明。
• 草稿：进行中的笔记。
• 归档：移至子目录但未删除，仍可搜索。

Git历史不能替代归档——代理识别标签，同时尊重其状态。标题中包含日期与状态，确保透明可见。

Cursor规则：纪律保障

跨所有工作区的全局Cursor规则强制执行行为：

• 每个阶段结束后：在工作台中更新状态、指标与待办事项，并附带任务清单。
• 当上下文窗口耗尽时：生成续写提示，保障会话无缝衔接。
• 发生变更时：在同一会话内更新计划。

这些规则防止会话从过时上下文中启动。

避免元优化陷阱

LLM自动化成本低廉——但也可能引发拖延：构建无实际服务的基础设施，制定无代码支撑的计划。LLM赋予想法极具说服力的形式，模糊了“行动”与“成果”的界限。

警示信号包括：

• 过高估计回报率：一个10小时脚本仅使用5次，实为亏损。
• 创业瘫痪：等待完美前提条件（类型、测试）。
• 过度沉迷工具，忽视实质工作。

距离成果的层级结构

以距离产品产出的远近衡量活动价值：

• 直接成果：可用的产品。
• 基础系统：CI/CD、监控体系。
• 加速器：输入法、Cursor规则、工作台。
• 元加速器：LLM工作流。
• 元层级：反思与总结。

原则：距成果越远的层级，投入时间不超过30%。工作台是加速器；本文属于元层级。

LLM自动化成熟度阶段

发展循序渐进：

• 审核代理输出。
• 实现自主运行并集成CI阻断机制。
• 稳定后构建完整流水线。

常见错误：在缺乏稳固CI基础的前提下自动化循环。

最关键的几点

• 过时上下文会污染LLM：必须自动化链接验证、新鲜度检查与项目覆盖。
• 文档状态（活跃/参考/草稿/归档）为代理提供清晰可信信号。
• Cursor规则确保会话中及时更新与正确续写提示。
• 避免元优化：70%时间投入成果，30%用于工具建设。
• 成熟度从手动审查逐步迈向分阶段流水线。

— Editorial Team