先分清在做决定、评审方案，还是治理长期变化

Keel

把架构选择变成有依据的决定

为模块边界、接口切换和长期架构变化提供有依据的判断：比较可行方案，检验既定设计，找出漂移与例外背后的问题，并说明谁能决定、还缺什么证据。

作者 lencx

安装与上手查看 GitHub
Keel：把架构选择变成有依据的决定 项目图片

本页使用入口

  • Codex CLI / IDE：选择 $keel
  • Claude Code 或原生插件：按作者指南另选安装方式
所在仓库 Star
196
资料核对
分类
工程开发产品与项目

先让一个真实选择变得清楚

第一次可以用下面的导出功能练习：比较同步与后台两条方向，明确哪些事实足以支持建议，哪些还需要测量。能指出改变决定的证据，比提前画出一套完整系统更有用。

选一个任务，开始使用

在目标项目根目录安装单独的 keel，确认 Codex 能发现它，再发送一个边界清楚的问题。第一个任务可直接作为设计练习；换成真实项目时，把其中的假设替换为你的材料。

现在需要哪一种架构判断？

从同步导出与后台任务之间作选择；先承认未知规模，再找最便宜、能改变决定的证据。

  1. 为当前项目安装 Keel

    在目标项目根目录的终端运行，确认只选择 keel 与 Codex；此命令未加 -g，采用项目范围。安装器固定为已核对的 1.7.4（Node.js 22.20+），Keel 内容仍取安装时的仓库版本。安装前查看已有同名入口，完成后核对安装摘要和完整目录。

    npx [email protected] add lencx/skills --skill keel -a codex
    查看作者安装说明

    确认装的是完整技能，再开始提问

    检查项目 .agents/skills/keel/ 下保留 SKILL.md 和 references/ 六份文档。在同一项目打开 Codex，用 /skills 或输入 $ 选择 keel；若尚未出现，重新启动 Codex。然后附上材料，说明要做决定、评审还是治理。单独技能与原生插件选一种即可，作者提醒两者同时安装会出现重复入口。

    查看 Codex 的发现与调用规则

  2. 把这段话发给 AI

    四项均为本站根据作者规则编写的使用示例，未实际运行。第一项是有意保留未知的假设场景；其余需附上所列资料。Decision、Judgment 和 Governance 是工作状态，不是终端参数或单独命令。

    $keel 为订单 CSV 导出做一次架构 Decision。这是尚未实施的设计练习，以下是讨论假设，不是代码或实测事实：单体应用已有订单查询与鉴权；目前只有同步导出，没有后台任务框架；新功能必须沿用租户隔离与字段权限。团队希望支持较大导出，但还没有真实行数、耗时、内存或并发基线。 本次只返回分析，不创建文件或执行试验。比较保留同步接口和新增后台任务两种可行方向；如果有更简单且有依据的方向可以提出，不为凑选项扩大系统。先说明选择标准、假设以及谁需要批准新增任务基础设施，不猜实际负责人。 只画出影响选择的入口、状态、可见结果与恢复边界。若采用后台方向，讨论重复请求、任务中断、状态不明时需要的规则与责任；对不适用的环节说明理由。不要把“可以重试”当成恢复已经闭合，也不要虚构压测结果。 给出当前最有依据的阶段性建议。负载或权限事实仍可能改变决定时，标为 Open，列出未知、负责人或职责缺口，以及下一次需要测什么或批准什么。检查两个方向是否用了同一套标准，是否保留了简单方案，是否明确区分了假设与证据。

  3. 检查你拿到的结果

    • 按同一标准比较的少量可行方向，以及有条件的阶段性建议。
    • 只包含适用环节的责任与恢复边界；缺少负责人时明确记录。
    • Open 结论中的决定性未知和下一项测量或批准事项，不冒充已完成验证。
    查看这项任务的作者说明
进一步了解这个 Skill

Keel 面向那些会影响后续修改的问题：功能该放在哪一层，谁决定状态已经生效，接口能否直接更换，一条长期被绕过的规则是否还值得保留。它从你的目标、现有代码和约束出发，只检查可能改变结论的部分。私有小模块也可以使用，所需证据和记录应与影响范围相称。

同一个请求先分清三种工作。Decision 用于选择或改变架构；Judgment 固定你给定的方案，判断它是否可行；Governance 处理已经存在的边界、检查和记录如何恢复、迁移或退出。评审遇到不可行方案时，应交代证据和需要谁作决定，再在获得选择新方案的授权后转入 Decision。架构已定、只剩实现或测试时，Keel 会退出。

它关注可用的结论，也关注结论能否站住：哪些行为已经被调用者依赖，事实以哪里为准，谁有权批准切换，失败后由谁把状态恢复到什么终点。重要未知仍可能改变选择时，结果应标为 Open，给出最有依据的阶段性建议和下一步证据；Closed 表示本次架构判断已闭合，不代表软件已经实现或测试通过。

当前 Keel 是一份主技能和六份按需参考资料，没有附带架构扫描器、后台监控或检查脚本。代码修改、专业评估与验证执行交给对应工作流；它不预设微服务、事件溯源或某个框架，也不要求每个小问题都建立迁移表和治理档案。

来源与核验

资料核对

已全文阅读固定提交的主技能、六份参考及安装和插件资料，并核对安装器与 Codex 官方说明。未安装、运行架构任务或执行第三方脚本；页面展示的是预期用法。

作者说明技能原文任务路由与重写判断接口兼容与切换恢复与检查证据漂移与长期治理架构记录与权限规则理由与有意省略安装器选项与范围MIT 许可

架构明确后，再检查实现质量

把需要保留的边界、契约和恢复条件带到代码评审中，检验实现有没有用过大的文件、扭曲的抽象或分支补丁破坏这些决定。

Thermo-Nuclear Review给 AI 一条维护性审查标准：追踪新增分支与模糊边界，提出能删掉整层复杂度的改法。Matt Pocock Skills按需组合的工程技能：问清需求、整理规格、拆分工单、先测后写、排查 Bug 和检查架构。n8n 官方技能把 n8n 工作流的设计、节点配置、测试与排错接成可检查的流程，从你有权限的实例开始。乔木 Goal把模糊需求整理成结果、验证、约束、写入边界和完成条件，先给草案再用选择题调整。