企业官网建设流程全解析

CodeBuddy Rules 的 alwaysApply 详解：自动加载 vs 手动引用

写了一大堆 rules，全设成自动加载就完事了？错——你可能正在白白浪费宝贵的上下文空间。本文讲透alwaysApply的设计哲学和使用策略。

目录

1. 什么是 alwaysApply
2. 两种模式对比
3. 为什么不全开自动加载
4. Token 预算模型
5. 手动引用怎么用
6. 实战策略：哪些该自动，哪些该手动

一、什么是 alwaysApply

每个 rules 文件（.codebuddy/rules/*.md）顶部都有一个 YAML frontmatter，其中alwaysApply字段决定了它的加载方式：

---enabled:truealwaysApply:true# ← 核心开关priority:highdescription:固件版本管理规范---# 规则正文...

alwaysApply取值只有两个：

二、两种模式对比

类比理解：

三、为什么不全开自动加载

核心原因：Token 预算有限。

每次对话，AI 都有一个固定的上下文窗口（token 上限）。这个窗口里要塞很多东西：

┌─────────────────────────────────────────────┐ │ AI 上下文窗口 │ │ │ │ ┌───────────────────────────────────────┐ │ │ │ 系统提示词（固定） │ │ │ ├───────────────────────────────────────┤ │ │ │ alwaysApply 规则 ① │ │ │ │ alwaysApply 规则 ② │ │ │ │ alwaysApply 规则 ③ ... │ │ │ ├───────────────────────────────────────┤ │ │ │ 项目快照（目录结构） │ │ │ ├───────────────────────────────────────┤ │ │ │ ← 你的提问 + AI 回复（剩余空间）→ │ │ │ └───────────────────────────────────────┘ │ └─────────────────────────────────────────────┘

自动加载越多 → 留给实际问答的空间越小。

后果：

• 生成大段代码时可能被截断
• 多轮对话时记忆容量更早耗尽
• 大量无关规则分散 AI 注意力，回答质量反而下降

四、Token 预算模型

举个具体例子。假设你有一个嵌入式项目，配了 4 个 rules：

全开方案：每次对话固定消耗 ~1400 tokens。
只开 firmware-management：每次固定消耗 ~200 tokens，其他三个用时再引。

假设上下文窗口 8000 tokens，全开方案相当于每句话还没说就先被咬掉 17% 的空间。

五、手动引用怎么用

当alwaysApply: false的规则需要生效时，在对话中@引用：

你：@rules/embedded-c-coding 帮我写一个 GPIO 中断初始化函数

此时规则内容会注入到当前对话，AI 按照 MISRA C 规范生成代码。对话结束后，下次新会话不会自动带上。

引用后的生命周期：

对话 A 对话 B（新会话） │ │ ├─ @rules/xxx → 注入规则 ├─ 未引用 → 规则不在上下文中 ├─ AI 按规则回答 ├─ AI 不记得之前那条规则 └─ 对话结束，规则释放 └─ 需要时重新 @ 引用

六、实战策略：哪些该自动，哪些该手动

6.1 判断标准

问自己这个问题：“这个规则的内容，每次对话 AI 都需要知道吗？”

6.2 典型项目示例

以嵌入式固件仓库为例：

6.3 各类型项目推荐

6.4 渐进式策略

不确定时，遵循这个原则：

初始阶段：全设 false（只有项目基础 true） ↓ 使用一周后：发现哪些规则经常需要 @ 引用 ↓ 高频引用的：改为 true 低频引用的：保持 false ↓ 定期审视：规则过时了就更新或删除

七、总结

一句话：把 alwaysApply 想象成你工位上的东西 — 键盘鼠标必须随时在桌上（true），示波器用到时再从柜子里拿（false）。桌上堆满工具，你反而没法干活。

本文基于 CodeBuddy Rules 配置机制撰写，适用于 CodeBuddy IDE / VS Code 扩展 / CLI 全系列。