CodeBuddy Rules 的 alwaysApply 详解自动加载 vs 手动引用写了一大堆 rules全设成自动加载就完事了错——你可能正在白白浪费宝贵的上下文空间。本文讲透alwaysApply的设计哲学和使用策略。目录什么是 alwaysApply两种模式对比为什么不全开自动加载Token 预算模型手动引用怎么用实战策略哪些该自动哪些该手动一、什么是 alwaysApply每个 rules 文件.codebuddy/rules/*.md顶部都有一个 YAML frontmatter其中alwaysApply字段决定了它的加载方式---enabled:truealwaysApply:true# ← 核心开关priority:highdescription:固件版本管理规范---# 规则正文...alwaysApply取值只有两个值含义true每次对话自动注入无需任何操作打开 CodeBuddy 即生效false平时不加载只有你主动引用时才会注入到当前对话二、两种模式对比维度alwaysApply: truealwaysApply: false触发方式自动会话启动即加载手动需rules/xxx引用占用上下文每次对话都占仅引用时才占适用场景项目基础常识、全局约定特定领域的专项规范遗忘风险无自动生效有可能忘记引用Token 消耗每次都有固定开销用时才产生开销类比理解模式比喻true公司门禁卡 — 进门就生效全天有效false工具箱里的专业设备 — 用到才拿平时不占地三、为什么不全开自动加载核心原因Token 预算有限。每次对话AI 都有一个固定的上下文窗口token 上限。这个窗口里要塞很多东西┌─────────────────────────────────────────────┐ │ AI 上下文窗口 │ │ │ │ ┌───────────────────────────────────────┐ │ │ │ 系统提示词固定 │ │ │ ├───────────────────────────────────────┤ │ │ │ alwaysApply 规则 ① │ │ │ │ alwaysApply 规则 ② │ │ │ │ alwaysApply 规则 ③ ... │ │ │ ├───────────────────────────────────────┤ │ │ │ 项目快照目录结构 │ │ │ ├───────────────────────────────────────┤ │ │ │ ← 你的提问 AI 回复剩余空间→ │ │ │ └───────────────────────────────────────┘ │ └─────────────────────────────────────────────┘自动加载越多 → 留给实际问答的空间越小。后果生成大段代码时可能被截断多轮对话时记忆容量更早耗尽大量无关规则分散 AI 注意力回答质量反而下降四、Token 预算模型举个具体例子。假设你有一个嵌入式项目配了 4 个 rules规则大约 Token 数如果 alwaysApply固件版本管理规范~200 tokens每次占 200CAN/UDS 诊断协议~500 tokens每次占 500A2L 标定规范~300 tokens每次占 300MISRA C 编码规范~400 tokens每次占 400全开方案每次对话固定消耗 ~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 都需要知道吗”回答决策是不知道就没法理解项目→alwaysApply: true不只在做特定类型工作时才需要→alwaysApply: false6.2 典型项目示例以嵌入式固件仓库为例规则主题alwaysApply理由固件版本管理✅true项目基础知识AI 每次都得知道版本号格式和交付目录命名CAN/UDS 诊断协议❌false只在写 UDS 代码时需要。改 Python 脚本时不需要A2L 标定文件规范❌false只在处理标定相关文件时需要。大部分对话不涉及MISRA C 编码规范❌false只在写 C 代码时需要。问 C#/Python 时无关6.3 各类型项目推荐项目类型建议true建议false嵌入式/固件平台架构、版本规范、安全策略UDS 协议、A2L 规范、各外设驱动规范Web 前端技术栈、目录约定、组件命名规范各页面模块的详细规范、第三方库用法微服务后端服务架构、RPC 协议、错误码规范每个微服务的具体业务逻辑规范Python 数据科学数据目录约定、环境配置具体算法实现规范、可视化风格要求6.4 渐进式策略不确定时遵循这个原则初始阶段全设 false只有项目基础 true ↓ 使用一周后发现哪些规则经常需要 引用 ↓ 高频引用的改为 true 低频引用的保持 false ↓ 定期审视规则过时了就更新或删除七、总结要点说明alwaysApply: true每次对话自动加载适合项目基础约定alwaysApply: false需手动rules/xxx引用适合特定领域规范核心矛盾自动加载 vs Token 预算 — 不是越多越好黄金法则“AI 每次都需要知道吗” 是 → true否 → false最佳实践先用 false高频引用的再改 true一句话把 alwaysApply 想象成你工位上的东西 — 键盘鼠标必须随时在桌上true示波器用到时再从柜子里拿false。桌上堆满工具你反而没法干活。本文基于 CodeBuddy Rules 配置机制撰写适用于 CodeBuddy IDE / VS Code 扩展 / CLI 全系列。