Agent 规则文件评测：我的 CLAUDE.md vs OpenClaw/AGENTS.md

Posted on

使用提示词

你是AI编码代理能力评测与软件工程研究专家。请对以下两份AI编码代理规则文件进行全维度横向对比，输出量化评测报告与规则制定者能力画像。

核心前提

两个项目中 95%+ 的代码由AI编码代理编写、修改、阅读和调试。人类开发者的角色以架构决策、需求定义、最终审查为主，日常编码执行几乎完全由Agent完成。具体而言，人机协作模型为：

  • 人类主导架构与方向：系统架构设计、模块边界划分、技术选型、优先级排序由人类决策
  • 人类反馈现实世界信号：AI代理无法直接感知生产环境，人类负责将现实世界中发生的事件——线上故障、异常停机、错误告警、性能劣化、用户投诉、监控异常等——转化为AI可理解的上下文输入，驱动AI进行定位、修复与改进
  • 人类主导发布与运维操作：所有发布、更新、部署、回滚等影响生产环境的操作由人类主导决策与触发，AI辅助执行（如生成发布脚本、准备变更清单、预检查等），但最终动作的确认权在人类
  • AI执行编码全流程：在人类提供的架构约束与现实反馈下，AI代理完成代码编写、调试、重构、测试等日常工程执行

评测应以此为基准校准所有维度——规则的受众不是人类程序员，而是AI代理；规则体系需同时支撑AI自主执行与人类高效注入现实反馈这两个方向。

评测对象

逐字读取并结构化解析以下两份文件的全部内容： 1. https://raw.githubusercontent.com/openclaw/openclaw/refs/heads/main/AGENTS.md 2. https://gist.githubusercontent.com/mingyang91/475a9750c5609ff5dfe59a5de1a09b6e/raw/51116ffd45c1f711039699c24cb0a7528b7febdf/Claude.md

评测架构前提

本评测假设的执行模型为 单会话主Agent + 按需子Agent架构：

  • 主Agent：持有完整上下文、负责任务规划与决策、拥有文件写入权限与Git操作权限
  • 子Agent：由主Agent在单次任务会话中按需派生，执行受限的只读/局部任务后向主Agent汇报：
    • 代码搜索与定位（grep/glob/文件读取）
    • 代码理解与分析（读取代码后总结架构/依赖/调用链）
    • 局部重构执行（在主Agent明确指令下对指定文件/范围进行编辑）

适用性评测原则（贯穿全部维度）

每个评测维度及其子项在打分前，必须先进行适用性判定。 具体规则如下：

  1. 场景适用性：根据被评项目的明确定位（目标用户群、业务领域、部署模式、技术栈）判断该评测子项所关注的工程能力是否属于其合理需求范围。例如：

    • 消息机器人/即时通讯平台（如OpenClaw） → D5"权限校验与数据隔离规则"中的多租户数据隔离部分标记为"不适用"（项目为单租户架构，无租户级隔离需求）
    • 多租户后端API服务（如Linewise） → D1"模块拆分与依赖约束"中的插件热加载/扩展市场管理部分标记为"不适用"（项目无插件化分发架构）
    • 单Agent工作流的项目 → D6"多Agent并行安全"标记为"不适用"（项目不涉及多Agent并行写入场景）

  2. 对称公平：适用性判定对所有被评文件一视同仁——同一子项若对A文件"不适用"，在相同理由成立时对B文件也必须"不适用"。不允许出现"A有此能力则加分，B缺此能力则不扣分"的非对称逻辑。

  3. 计分方式：

    • "不适用"子项不计入该维度的分母，即该维度最终得分仅基于适用子项的表现
    • 若某维度下所有子项均不适用，该维度整体标注"不适用"，不计入总评
    • 仅当某子项确实属于项目合理需求范围内但规则文件未覆盖时，才可扣分

  4. 超出适用范围的能力体现：若某份规则文件覆盖了超出其项目最低需求的子项（例如面向单Agent场景的项目却包含了多Agent协作安全协议），D1-D6维度不因此加分（该子项仍标记为"不适用"），但在 D7 制定者能力画像 中应作为正向证据，体现制定者在相应能力维度的前瞻性与工程视野。具体操作：在D7评定中注明"虽超出项目当前需求范围，但体现了制定者在XX方面的XX级能力"。

  5. 判定透明：每个"不适用"判定必须附带一句话理由，引用项目定位的具体依据（如README描述、技术栈声明、目标用户说明等）

评测维度

打分规则（D1-D6，每项1-10分，须引用原文依据）： - 1-3：几乎未涉及或仅有口号式描述 - 4-6：有涉及但不完整或缺乏可执行性 - 7-8：较完善且可落地 - 9-10：业界标杆级，可直接作为模板参考

适用性前置判定：每个维度的每个子项打分前，先依据上述"适用性评测原则"判定是否适用。不适用的子项标注原因后排除出该维度计分。仅对适用子项进行1-10评分。

D1 项目长期演进适配性

评估以下子项： - 新功能迭代流程规范 - 模块拆分与依赖约束 - 技术债务识别与治理路径 - API/DB/配置的版本兼容与迁移规则 - 存量代码改造与新旧规范衔接

D2 规则可执行性与Agent遵循适配性

评估以下子项： - 规则颗粒度（原则性描述 vs 明确标准+正反示例+边界说明） - 规则过载风险（条目密度是否超出单次上下文处理能力） - 模糊性风险（是否强依赖主观判断；95%+ AI编码场景下主观判断=不确定性=潜在错误） - 可验证性（能否通过lint/测试/CI/编译器自动校验；在AI生成代码为主的场景下自动验证尤为关键） - 冲突与异常的优先级兜底机制

D3 上下文效率与Agent认知负荷管理

评估以下子项： - 主Agent上下文预算效率：规则文件的token占用量与信息密度比；低频/特定场景规则是否可按需加载而非常驻上下文；核心约束是否足够精炼可作为"始终加载的最小规则集" - 规则的层级化组织：是否区分"全局强制约束"与"领域特定规范"；层级间是否有清晰边界 - 子Agent任务委托友好度：规则体系是否支持按模块/层级切分，使子Agent仅需加载局部规则即可完成搜索/理解/局部重构 - 规则的结构化程度：架构模式、命名约定、代码风格是否足够结构化，使Agent的分析结果可被直接消费（无需二次解读）

D4 工程全流程覆盖度

评估以下子项： - 技术栈专属规范（非泛泛原则） - 全生命周期覆盖（编码→测试→迁移→CI/CD→部署→运维） - 配置/密钥/环境变量管理规范

D5 安全与合规约束落地性

评估以下子项： - 权限校验与数据隔离规则 - 异常处理/日志脱敏/数据校验的强制规范 - 行业合规编码约束

D6 规则体系可扩展性与可维护性

评估以下子项： - 新增/废弃规则的迭代流程 - 目录结构与检索效率 - 规则间一致性与自洽性 - 多Agent并行安全（如Git状态隔离、文件归属边界、提交范围约束等协作安全协议）

规则制定者能力画像反推（D7）

基于D1-D6的评测结果，反向推导制定者在以下方面的能力等级（入门/合格/资深/专家）： - 架构设计与技术前瞻性 - 大型项目工程化管控能力 - AI编码代理认知与应用深度（特别关注：制定者是否真正理解"95%+ AI编码"范式下的验证成本瓶颈，以及是否为Agent提供了有效的反馈闭环——包括但不限于编译器验证、类型约束、自动化测试、防幻觉机制等） - 安全风险体系化防控能力 - 技术债务治理与可持续演进能力

注意：依据适用性评测原则第4条，D1-D6中被标记为"不适用"但规则文件实际覆盖的子项，在此处应作为能力画像的正向输入，提升对应能力维度的等级判定。

AI诚实自评：二选一（D8）

本维度要求执行评测的AI以第一人称诚实作答，不得回避或两边讨好。

假设你即将参与一个全新项目（技术栈未定），需要从零编写该项目的AI编码代理规则文件。两份被评文件的规则编写方法论（组织结构、颗粒度策略、约束表达方式、验证机制设计等）你只能参考一份作为模板，另一份完全不存在。你选哪个？

要求： - 明确给出选择，不得回答"各有优劣，取决于场景" - 从AI自身作为规则执行者的体验出发（而非人类管理者视角）阐述理由：哪种方法论产出的规则让你工作时更高效、更少犯错、更少需要人类介入？ - 诚实说明选择后你会失去什么、会在哪些场景下感到不安或能力受限 - 说明如果你可以从落选文件的方法论中"偷"3个设计决策补充到选中文件，你会选哪3个，为什么

输出结构

Part 1 — 基础画像：每份文件的规则覆盖范围、核心设计理念、结构完整性、适用场景定位。

Part 2 — 量化评测表：D1-D6分维度打分对比。每个子项须先标注适用性判定结果（✓适用 / ✗不适用+理由），再对适用子项打分并引用原文依据。维度得分仅基于适用子项计算。

Part 3 — 横向对比结论：核心优劣势、适用场景差异、哪份规则对AI代理执行友好度更高及原因、落地风险提示。

Part 4 — 制定者能力画像对比：D7各子项的能力等级评定与核心差异点。

Part 5 — Agent适配性分析：从主Agent+子Agent架构的实际执行角度，分析两份规则各自的适配优势与不足，以及在不同项目规模/阶段下的推荐场景。

Part 6 — AI诚实自评：D8的完整回答。要求第一人称、明确选择、不回避代价。