Caliber：把 CLAUDE.md 当成会过期的构建产物来维护
Continuously sync your AI setups with one command. Codebase tailor suited agent skills, MCPs and config files for Claude Code, Cursor, and Codex.
秒懂
- 它是什么？
- Caliber 用一条命令为 Claude Code、Cursor、Codex、OpenCode 和 GitHub Copilot 生成并持续同步 AI 上下文文件，核心判断是把配置文件当作随代码演进的产物，而不是一次性手写的文档。
- 适合谁用？
- 如果你的团队同时使用两种以上 AI 编码工具，或者 CLAUDE.md 已经明显落后于代码结构，Caliber 值得先跑一次 caliber score 看清楚现状，再用 bootstrap 和 /setup-caliber 生成配置。如果你只有一个开发者、一份手写规则且改动不频繁，引入 pre-commit 刷新循环带来的收益有限。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 51 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
手写 CLAUDE.md 的失效速度由重构决定
README 开头给出的是一个很具体的场景：手写的 CLAUDE.md 在重构的那一刻就开始过期。智能体引用已经不存在的路径，漏掉新增的依赖，按照昨天的架构给出建议。这个问题与模型能力无关，是文档与代码之间的时间差造成的。
Caliber 面向的是已经用上 AI 编码工具、并且把这些工具纳入团队协作的开发团队。README 明确列出 Claude Code、Cursor、Codex、OpenCode、GitHub Copilot 五个目标平台，说明它假设的读者不是单工具用户。当团队里有人用 Claude Code、有人用 Cursor、有人用 Copilot 时，同一份项目上下文需要以五种不同格式存在，手工维护这五份文件本身就是一项容易出错的重复劳动。Caliber 要解决的是这个重复劳动，以及重复劳动产生的漂移。
确定性评分先审后写
Caliber 的评分不调用 LLM，也不发起 API 请求。README 说明它会拿配置文件与实际项目文件系统做交叉比对：被引用的路径是否存在，代码块是否完整，自上次提交以来是否出现配置漂移。评分拆成 FILES & SETUP、QUALITY、GROUNDING、ACCURACY、FRESHNESS、BONUS 六个维度，总分 100。
这个设计有一个直接后果：分数是可复现的。同一份代码和同一份配置，在不同机器、不同时间跑出来的分数一致，因为中间没有随机采样。README 给出的命令是 caliber score --compare main，用于查看当前分支相对 main 的分数变化。把配置质量变成一个可以在 code review 里讨论的数值，是 Caliber 相对手写文档最实质的差别。
需要指出的是，评分维度里的 GROUNDING 和 ACCURACY 占比分别是 20 分和 15 分，这两个维度衡量的是配置与代码的一致性，而不是配置写得好不好。一份措辞粗糙但路径全部正确的 CLAUDE.md，可能比一份文笔流畅但引用了三个已删除目录的文档得分更高。这个取向是刻意的，也意味着 Caliber 无法告诉你架构描述是否符合团队的实际意图。
bootstrap 只装技能，生成交给你的智能体
安装路径分两步。第一步在终端执行 npx @rely-ai/caliber bootstrap，README 称这一步约 2 秒，且完全本地运行，不调用 LLM，不发送代码。第二步在 Claude Code 或 Cursor 的 CLI 会话中（README 强调是终端里的 CLI 会话，不是 IDE 聊天窗口）输入 /setup-caliber。
这个分工值得注意。bootstrap 负责把 /setup-caliber 这个技能装进你的智能体环境，真正的项目分析、技术栈识别、配置生成由你的智能体完成，用的是你自己的订阅或 API key。Caliber 本身不接触你的代码。
不使用 Claude Code 或 Cursor 的用户走 caliber init，README 说明它是等价的 CLI 向导，支持自带 Anthropic、OpenAI、MiniMax 或 Vertex AI 的 key。这条路径把生成能力从智能体技能里剥离出来，代价是失去了在会话中通过对话微调配置的交互方式。
生成的文件按平台分开。Claude Code 侧包括 CLAUDE.md、CALIBER_LEARNINGS.md、.claude/skills/*/SKILL.md、.mcp.json 和 .claude/settings.json。Cursor 侧是 .cursor/rules/*.mdc、.cursor/skills/*/SKILL.md 和 .cursor/mcp.json。Codex 与 OpenCode 共用 AGENTS.md，技能分别落在 .agents/skills/ 和 .opencode/skills/。Copilot 只有一个 .github/copilot-instructions.md。技能文件采用 OpenSkills 格式，这是跨平台复用的基础，也是为什么同一份技能内容能出现在五个不同目录下。
写入前先备份，写入后有撤销
Caliber 不会在没有确认的情况下覆盖已有配置。流程被描述成类似代码审查的四步：评分、生成差异、逐项接受或拒绝、写入前把原文件存到 .caliber/backups/。任何一次写入之后都可以用 caliber undo 恢复到之前的状态。
这里有一个值得留意的分支逻辑：如果现有配置评分已经达到 95 分以上，Caliber 会跳过整体重新生成，只针对未通过的具体检查项做定点修复。这个阈值设计说明工具本身承认高分配置不应该被大改，避免为了统一格式而破坏团队已经调好的上下文。
对已经在用 AI 编码的团队来说，备份加撤销的组合决定了试错成本。你可以先在一个分支上跑完整流程，看生成的 diff 是否可接受，不满意就回退。这比直接让工具覆盖 CLAUDE.md 要安全得多，也是这类工具能否进入日常流程的关键。
pre-commit 钩子驱动的刷新循环
配置生成之后，Caliber 的循环是这样的：代码演进，新增依赖、重命名文件、调整架构，然后在每次提交时由 pre-commit 钩子自动执行 caliber refresh，重新生成配置。README 的流程图把这个闭环画得很清楚，refresh 是自动的，挂在提交动作上。
这个机制决定了 Caliber 的成本结构。它不是在需要时才手动运行的命令，而是持续占用提交路径的钩子。好处是配置几乎不会落后于代码；代价是每次提交多出一个步骤，而这个步骤的耗时取决于项目规模和生成方式。
Windows 用户在这里会遇到明确的限制。README 说明 Caliber 的 pre-commit 钩子和自动同步脚本使用 shell 语法，推荐使用 Git Bash，因为 Git for Windows 自带它。如果只用 PowerShell，钩子可能被静默跳过。这是一个不会报错、只会不生效的失败模式，排查起来比直接报错更麻烦。README 还提醒不要同时在多个终端运行 Caliber，否则会出现状态冲突和意外的 provider 检测结果。
它不判断配置内容对不对
Caliber 的评分基于文件系统比对，这意味着它能验证的东西有明确边界。路径存在与否、代码块是否存在、是否相对上次提交发生漂移，这些是客观可查的。但 CLAUDE.md 里写的构建命令是否真的能跑通、架构描述是否符合团队当前的设计意图、某个约定是否已经废弃，这些不在评分范围内。
一个具体的失败场景：如果团队把 CLAUDE.md 里的测试命令从 npm test 改成了 pnpm test，但项目里两个脚本都存在，Caliber 的路径与代码块检查不会发现这个问题，因为引用的东西确实存在。配置在形式上完全合规，在语义上已经错了。
另一个边界是语言与框架检测。README 提到支持 TypeScript、Python、Go、Rust、Java、Ruby、Terraform 等，但这个列表之外的内部框架、公司自研 DSL、非标准构建系统，检测效果无法从现有材料确认。仓库的 README 在 Key Features 一节被截断，语言检测的具体实现细节没有完整给出。如果你的项目大量依赖自研工具链，建议先跑 caliber score 看评分维度里哪几项拿不到分，再决定是否值得接入。
与手工维护和纯提示词模板的差别
最直接的替代方案是继续手工维护 CLAUDE.md，把它当作一份需要人肉更新的文档。两者的差别不在于生成质量，而在于触发时机：手工维护依赖某个人记得在重构后更新文档，Caliber 把更新挂在 pre-commit 上。只要团队正常提交代码，配置就会被刷新。这个机制上的差别，比任何单次生成结果的对比都更重要。
另一类替代是各种 CLAUDE.md 模板仓库和提示词集合。这类资源提供的是起点，通常是一份写好的规则文件，你复制过来再改。它们不会读取你的项目结构，不会检测你引用了哪些不存在的路径，也不会在代码变化后重新生成。Caliber 的定位是把配置从静态模板变成随代码演进的产物，代价是引入一个 Node.js 依赖和一个提交钩子。
选择哪条路取决于项目变化的速度。如果代码库结构稳定，一份手写规则可以撑很久，模板方案足够。如果每周都有目录调整和依赖变更，手工维护的收益会迅速变成负数，因为过期的配置会让智能体给出错误的建议，而这种错误不容易被察觉。
许可、维护成本与升级节奏
项目采用 MIT 许可，仓库未归档，默认分支为 master，主要语言是 TypeScript，运行需要 Node.js >= 20。MIT 许可意味着你可以自由使用、修改和再分发，包括在闭源项目中使用。需要注意的实践问题是生成的文件本身是否进入版本控制：如果 CLAUDE.md 和 .cursor/rules/ 提交进仓库，那么每次 refresh 都会产生 diff，团队需要接受这种提交噪音；如果不提交，新成员克隆仓库后就没有可用的配置。README 提到新成员首次会话会收到 bootstrap 提示，说明工具默认倾向于让配置进入仓库。
升级节奏偏快。从发布记录看，v1.53.3、v1.53.4、v1.53.5 三个版本集中在 2026 年 7 月 26 日当天发布。这种频率通常意味着活跃修复，也意味着如果你锁定了某个版本，可能需要主动跟进才能拿到修复。由于 pre-commit 钩子会调用 caliber refresh，版本行为的变化会直接进入提交流程，建议在升级后先在一个分支上验证 refresh 的输出是否符合预期，再合并到主分支。
以上关于许可的判断仅为对 MIT 条款的一般性说明，不构成法律意见，具体合规问题请咨询法务。
编辑结论
如果你的团队同时使用两种以上 AI 编码工具，或者 CLAUDE.md 已经明显落后于代码结构，Caliber 值得先跑一次 caliber score 看清楚现状，再用 bootstrap 和 /setup-caliber 生成配置。如果你只有一个开发者、一份手写规则且改动不频繁，引入 pre-commit 刷新循环带来的收益有限。采用前需要确认三件事：Node.js 是否 >= 20，Windows 上是否有 Git Bash 可用，以及团队能否接受生成文件进入版本控制。撤销路径是 caliber undo，备份在 .caliber/backups/，这两点决定了试错成本的上限。
社区笔记