Cairn是一个实验性插件框架，为AI编程代理（OpenAI Codex和Claude Code）提供智能工作流路由。它根据任务复杂度自动选择适当的工作模式，避免过度规范简单任务或低估复杂任务的风险。

• 原作者/维护者：tavaresgmg
• 来源平台：github
• 原始标题：cairn
• 原始链接：https://github.com/tavaresgmg/cairn
• 来源发布时间/更新时间：2026-06-02T13:15:34Z

Cairn：面向遗留代码的AI编程代理工作流路由系统\n\n随着OpenAI Codex和Claude Code等AI编程代理的普及，开发者面临一个新的问题：如何为这些代理选择合适的工作模式？简单的聊天式交互缺乏结构，容易导致意图丢失；而过度的规范化又会让每个小任务都变成繁琐的流程。\n\nCairn项目提出了"比例深度"（proportional depth）的理念——根据任务复杂度自动选择适当的工作模式，既保持灵活性又确保关键任务的可追溯性。\n\n## 原作者与来源\n\n- 原作者/维护者：tavaresgmg\n- 来源平台：GitHub\n- 原始标题：cairn\n- 原始链接：https://github.com/tavaresgmg/cairn\n- 发布时间：2026年6月2日\n\n## 核心问题：现有框架的两个极端\n\nCairn的文档指出了当前AI编程代理工作流框架的两种典型问题：\n\n### 极端一：结构过少\n\n纯聊天式规划的问题在于：\n- 跨会话的意图难以保持一致\n- 代码审查者无法看到原始设计意图\n- 历史决策缺乏可追溯性\n\n### 极端二：结构过多\n\n过度规范化的框架则导致：\n- 每个任务卡都变成小型产品项目\n- 产生大量不必要的文档和流程负担\n- 简单任务被过度复杂化\n\nCairn试图在这两个极端之间找到平衡点。\n\n## 比例深度：根据风险调整规范程度\n\nCairn的核心设计原则是"比例深度"——任务的规范程度应与其风险和复杂度成正比：\n\n| 任务类型 | 工作模式 | 产出物 |\n|---------|---------|--------|\n| 简单修复 | 直接补丁 | 代码变更 + 简要说明 |\n| 问题诊断 | 诊断模式 | 问题分析报告 + 修复建议 |\n| 需求探索 | 发现模式 | 调研笔记 + 方案对比 |\n| 接口变更 | 增量规范 | 变更规格 + 影响分析 |\n| 大型重构 | 完整跟踪变更 | 设计文档 + 测试计划 + 迁移指南 |\n\n这种分层方法确保简单任务保持轻量，复杂任务获得足够的规划和审查。\n\n## 技术实现：双平台统一源码\n\nCairn的一个显著特点是同时支持OpenAI Codex和Claude Code，且从同一套源码构建：\n\n\nplugins/cairn/\n plugin.manifest.json # 规范元数据（单一真相源）\n .codex-plugin/plugin.json # 生成的Codex插件配置\n .claude-plugin/plugin.json # 生成的Claude Code插件配置\n hooks/ # SessionStart引导（自主层）\n skills/cairn/SKILL.md # 技能定义文档\n\n\nscripts/build-manifests.mjs脚本负责从单一真相源生成两个平台的插件配置，确保功能一致性。\n\n### SessionStart引导机制\n\nCairn通过SessionStart钩子实现"自动路由"——用户无需显式调用Cairn，代理在会话开始时自动检测当前任务上下文，决定是否需要启用结构化工作流。这种设计降低了使用门槛，让规范化的好处"无感化"。\n\n## 借鉴与整合：站在巨人肩膀上\n\nCairn并非从零开始，而是整合了多个成熟方法论的优点：\n\n### BMAD风格\n\n借鉴BMAD（Brainstorming, Modeling, Architecture, Design）的发现、头脑风暴、调研和PRD打磨流程，确保需求阶段充分探索。\n\n### OpenSpec风格\n\n采用OpenSpec的"增量规范"（delta specs）和"活文档"（living specs）理念，让规范随代码演进，而非一次性交付后束之高阁。\n\n### Spec Kit风格\n\n引入阶段分离（phase separation）和产出物一致性检查，确保设计、实现、验证各阶段有明确的边界和交付标准。\n\n### Superpowers/GSD风格\n\n吸收执行纪律、代码审查、验证和持久状态管理的最佳实践，确保高质量交付。\n\n## 工作循环：从想法到实现\n\nCairn定义了一个六步工作循环：\n\n1. 摄入：接收想法、工单、链接或任务卡\n2. 检测：评估任务复杂度和风险等级\n3. 选择：从五种模式中选择最合适的工作方式\n4. 创建：仅生成当前模式所需的产出物\n5. 实现：带着新鲜证据执行编码\n6. 审查：代码审查后归档或清理\n\n这个循环强调"刚刚好"的文档——不多不少，恰如其分。\n\n## 安装与验证\n\n对于Codex用户（已验证）：\n\nbash\ncodex plugin marketplace add tavaresgmg/cairn\ncodex plugin add cairn@cairn\n\n\n项目还提供了本地验证脚本：\n\nbash\nnode scripts/build-manifests.mjs # 重新生成两个平台的配置\nnode scripts/validate-cairn.mjs # 结构验证 + YAML安全检查 + 冒烟测试\n\n\n## 项目状态与路线图\n\n根据文档，Cairn已完成第0-7阶段和第9阶段的构建和本地验证。第8阶段（能力矩阵采用）正在等待官方文档确认最近的钩子特性。\n\n项目文档中提到的docs/roadmap.md和docs/evals/auto-trigger.md包含能力矩阵和剩余跨模型评估缺口。对于希望参与早期测试的开发者，可以参考docs/PRINCIPLES.md了解设计原则。\n\n## 适用场景\n\nCairn特别适合以下场景：\n\n- 遗留代码维护：需要理解复杂历史代码库时，诊断模式帮助系统分析\n- 团队协作：多人共享AI代理会话时，结构化产出物提供上下文连续性\n- 关键功能开发：高风险变更需要可追溯的设计决策记录\n- 代码审查准备：自动生成的规格文档帮助审查者理解变更意图\n\n对于个人快速原型开发，Cairn的轻量级模式不会增加负担；对于企业级项目，其完整跟踪变更模式提供了必要的治理框架。

原作者与来源

• 原作者/维护者：tavaresgmg
• 来源平台：github
• 原始标题：cairn
• 原始链接：https://github.com/tavaresgmg/cairn
• 来源发布时间/更新时间：2026-06-02T13:15:34Z Cairn：面向遗留代码的AI编程代理工作流路由系统\n\n随着OpenAI Codex和Claude Code等AI编程代理的普及，开发者面临一个新的问题：如何为这些代理选择合适的工作模式？简单的聊天式交互缺乏结构，容易导致意图丢失；而过度的规范化又会让每个小任务都变成繁琐的流程。\n\nCairn项目提出了"比例深度"（proportional depth）的理念——根据任务复杂度自动选择适当的工作模式，既保持灵活性又确保关键任务的可追溯性。\n\n原作者与来源\n\n- 原作者/维护者：tavaresgmg\n- 来源平台：GitHub\n- 原始标题：cairn\n- 原始链接：https://github.com/tavaresgmg/cairn\n- 发布时间：2026年6月2日\n\n核心问题：现有框架的两个极端\n\nCairn的文档指出了当前AI编程代理工作流框架的两种典型问题：\n\n极端一：结构过少\n\n纯聊天式规划的问题在于：\n- 跨会话的意图难以保持一致\n- 代码审查者无法看到原始设计意图\n- 历史决策缺乏可追溯性\n\n极端二：结构过多\n\n过度规范化的框架则导致：\n- 每个任务卡都变成小型产品项目\n- 产生大量不必要的文档和流程负担\n- 简单任务被过度复杂化\n\nCairn试图在这两个极端之间找到平衡点。\n\n比例深度：根据风险调整规范程度\n\nCairn的核心设计原则是"比例深度"——任务的规范程度应与其风险和复杂度成正比：\n\n| 任务类型 | 工作模式 | 产出物 |\n|---------|---------|--------|\n| 简单修复 | 直接补丁 | 代码变更 + 简要说明 |\n| 问题诊断 | 诊断模式 | 问题分析报告 + 修复建议 |\n| 需求探索 | 发现模式 | 调研笔记 + 方案对比 |\n| 接口变更 | 增量规范 | 变更规格 + 影响分析 |\n| 大型重构 | 完整跟踪变更 | 设计文档 + 测试计划 + 迁移指南 |\n\n这种分层方法确保简单任务保持轻量，复杂任务获得足够的规划和审查。\n\n技术实现：双平台统一源码\n\nCairn的一个显著特点是同时支持OpenAI Codex和Claude Code，且从同一套源码构建：\n\n\nplugins/cairn/\n plugin.manifest.json 规范元数据（单一真相源）\n .codex-plugin/plugin.json 生成的Codex插件配置\n .claude-plugin/plugin.json 生成的Claude Code插件配置\n hooks/ SessionStart引导（自主层）\n skills/cairn/SKILL.md 技能定义文档\n\n\nscripts/build-manifests.mjs脚本负责从单一真相源生成两个平台的插件配置，确保功能一致性。\n\nSessionStart引导机制\n\nCairn通过SessionStart钩子实现"自动路由"——用户无需显式调用Cairn，代理在会话开始时自动检测当前任务上下文，决定是否需要启用结构化工作流。这种设计降低了使用门槛，让规范化的好处"无感化"。\n\n借鉴与整合：站在巨人肩膀上\n\nCairn并非从零开始，而是整合了多个成熟方法论的优点：\n\nBMAD风格\n\n借鉴BMAD（Brainstorming, Modeling, Architecture, Design）的发现、头脑风暴、调研和PRD打磨流程，确保需求阶段充分探索。\n\nOpenSpec风格\n\n采用OpenSpec的"增量规范"（delta specs）和"活文档"（living specs）理念，让规范随代码演进，而非一次性交付后束之高阁。\n\nSpec Kit风格\n\n引入阶段分离（phase separation）和产出物一致性检查，确保设计、实现、验证各阶段有明确的边界和交付标准。\n\nSuperpowers/GSD风格\n\n吸收执行纪律、代码审查、验证和持久状态管理的最佳实践，确保高质量交付。\n\n工作循环：从想法到实现\n\nCairn定义了一个六步工作循环：\n\n1. 摄入：接收想法、工单、链接或任务卡\n2. 检测：评估任务复杂度和风险等级\n3. 选择：从五种模式中选择最合适的工作方式\n4. 创建：仅生成当前模式所需的产出物\n5. 实现：带着新鲜证据执行编码\n6. 审查：代码审查后归档或清理\n\n这个循环强调"刚刚好"的文档——不多不少，恰如其分。\n\n安装与验证\n\n对于Codex用户（已验证）：\n\nbash\ncodex plugin marketplace add tavaresgmg/cairn\ncodex plugin add cairn@cairn\n\n\n项目还提供了本地验证脚本：\n\nbash\nnode scripts/build-manifests.mjs 重新生成两个平台的配置\nnode scripts/validate-cairn.mjs 结构验证 + YAML安全检查 + 冒烟测试\n\n\n项目状态与路线图\n\n根据文档，Cairn已完成第0-7阶段和第9阶段的构建和本地验证。第8阶段（能力矩阵采用）正在等待官方文档确认最近的钩子特性。\n\n项目文档中提到的docs/roadmap.md和docs/evals/auto-trigger.md包含能力矩阵和剩余跨模型评估缺口。对于希望参与早期测试的开发者，可以参考docs/PRINCIPLES.md了解设计原则。\n\n适用场景\n\nCairn特别适合以下场景：\n\n- 遗留代码维护：需要理解复杂历史代码库时，诊断模式帮助系统分析\n- 团队协作：多人共享AI代理会话时，结构化产出物提供上下文连续性\n- 关键功能开发：高风险变更需要可追溯的设计决策记录\n- 代码审查准备：自动生成的规格文档帮助审查者理解变更意图\n\n对于个人快速原型开发，Cairn的轻量级模式不会增加负担；对于企业级项目，其完整跟踪变更模式提供了必要的治理框架。