AI编码代理规则文件全维度横向对比评测报告
AI编码代理规则文件全维度横向对比评测报告
核心前提
两个项目中 95%+ 的代码由AI编码代理编写、修改、阅读和调试。人类开发者的角色以架构决策、需求定义、最终审查为主，日常编码执行几乎完全由Agent完成。
评测对象： 1. OpenClaw AGENTS.md 2. My CLAUDE.md
Part 1 — 基础画像
文件A：OpenClaw
AGENTS.md
| 属性 | 描述 |
|---|---|
| 项目定位 | 自托管个人AI助手平台，本地优先，单用户架构 |
| 技术栈 | TypeScript (ESM) / Node.js 22+ / pnpm+Bun / Vitest |
| 业务领域 | 多渠道消息机器人（WhatsApp/Telegram/Slack/Discord等25+通道） |
| 部署模式 | 本地运行Gateway + 可选远程服务器 + macOS/iOS/Android客户端 |
| 核心设计理念 | 操作手册型——以具体命令、工作流程序、GitHub协作规范为主轴，将"怎么做"编码为可执行步骤 |
| 结构完整性 | 覆盖面极广（GitHub协作、PR流程、发布、安全咨询、多Agent安全、设备测试、npm发布、1Password集成等），但缺乏统一的分层架构约束 |
| 适用场景 | 开源项目多贡献者协作、多平台客户端发布、消息通道插件生态 |
| 估算Token量 | ~8000-10000 tokens（内容密度高，含大量命令片段） |
文件B：My CLAUDE.md
| 属性 | 描述 |
|---|---|
| 项目定位 | 多租户后端API服务，企业级SaaS |
| 技术栈 | Scala 3.8.1 / http4s / cats-effect / Doobie / Mill / PostgreSQL+pgvector |
| 业务领域 | 文档管理、AI特性（嵌入/RAG）、视频SOP生成、实时通信 |
| 部署模式 | Kubernetes + ArgoCD + GCR，GitHub Actions CI |
| 核心设计理念 | 类型驱动型——"编译器即验收测试"，通过类型系统将约束前置，最大化编译期安全 |
| 结构完整性 | 高度结构化（重构哲学→技术栈→构建命令→项目结构→架构模式→编码风格→测试策略→CI/CD→部署），形成完整工程链路 |
| 适用场景 | 强类型后端服务、多租户SaaS、AI驱动的数据处理管线 |
| 估算Token量 | ~5000-6000 tokens（信息密度极高，无冗余操作步骤） |
核心理念差异：OpenClaw是"过程驱动"——告诉Agent每一步怎么做；My是"约束驱动"——告诉Agent什么是对的，让编译器验证。
Part 2 — 量化评测表
D1 项目长期演进适配性
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 新功能迭代流程规范 | ✓/✓ | 6 —
有PR模板、changelog标准、版本号管理规范、/landpr流程，但缺乏功能设计→实现→验收的端到端流程定义。依据："Follow
concise, action-oriented messages", "PR submission:
.github/pull_request_template.md" |
5 — 有feature模块组织结构和Development Workflow章节（添加新路由的步骤），但流程定义偏向技术执行而非功能迭代管理。依据："Adding New Routes: 1. Update the OpenAPI spec..." |
| 模块拆分与依赖约束 | ✓/✓ | 7 — 明确的目录结构、插件依赖隔离规则（"Keep plugin-only dependencies in extension package.json"）、workspace依赖约束（"Avoid workspace:* in dependencies"）。对插件与核心边界有清晰规范 | 8 — 严格的分层架构（Routes→Services→Repositories→Database）、tagless final依赖注入、feature模块标准结构、SDK选择优先级。依据："Layered Architecture"、每个feature模块的固定目录结构 |
| 技术债务识别与治理路径 | ✓/✓ | 4 — 有零散提及（SwiftUI迁移："Migrate existing usages when touching related code"），但无系统性治理框架 | 7 — 显式的增量迁移策略："Migrate incrementally. New services use typed errors. Existing Either[String, T] services migrate when next modified"；命名审查机制："Proactive naming review... flag misleading, stale, or inconsistent names" |
| API/DB/配置的版本兼容与迁移规则 | ✓/✓ | 3 — 版本号位置清晰列出但无API版本兼容规则，无数据库迁移规范 | 8 — Flyway迁移系统详细规范："Never modify existing migration files; always create new versioned files"；系统/租户双轨迁移；OpenAPI规范维护要求 |
| 存量代码改造与新旧规范衔接 | ✓/✓ | 5 — 有品牌迁移工具（"openclaw doctor"），但新旧规范衔接机制不足 | 7 — 通过"next-touch migration"策略衔接：类型错误模型增量替换、命名审查、编码风格渐进统一 |
D1维度得分（所有子项均适用）： - OpenClaw：5.0 (6+7+4+3+5)/5 - My：7.0 (5+8+7+8+7)/5
D2 规则可执行性与Agent遵循适配性
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 规则颗粒度 | ✓/✓ | 8 — 大量具体命令和代码示例，操作步骤精确到命令行参数。依据：Gateway重启的精确bash命令、npm发布的完整步骤、版本号更新的所有文件路径列表 | 9 — 正反示例对比（BAD/GOOD代码块）、边界说明清晰、类型约束有完整代码范式。依据：for-comprehension的BAD/GOOD对比、错误处理Trusted vs Untrusted路径决策表、测试的"What TO test" vs "What NOT to test" |
| 规则过载风险 | ✓/✓ | 4 — 内容极其庞大，涵盖GitHub协作、npm发布、1Password集成、设备测试、macOS签名、voice wake等数十个领域，单次会话加载全部规则会严重挤压工作上下文。Agent执行日常编码任务时，大量发布/运维规则是噪声 | 7 — 内容精炼聚焦，每个章节与日常编码直接相关。无过度运维细节。但所有规则仍为单文件平铺，缺乏按需加载机制标记 |
| 模糊性风险 | ✓/✓ | 6 — 多数操作规则无模糊空间（精确命令），但编码风格部分有模糊项："Add brief comments for tricky/non-obvious logic"（何为tricky？）、"Target ~700 LOC per file (guideline only)"（模糊阈值） | 8 — 关键规则通过类型系统消除模糊性："If a refactor compiles, it's correct"将正确性判断从主观转为编译器可判定。反模式用Forbidden patterns明确列举（"json.as[T].toOption"等） |
| 可验证性 | ✓/✓ | 6 —
有CI检查（pnpm check、prek install）、覆盖率阈值（70%）、格式化验证（oxfmt --check）。但许多规则仅靠人类Review验证（PR
truthfulness验证等） |
9 — 核心优势：编译器作为终极验证器。"The compiler is the last line of defense. If a refactor compiles, it's correct." 类型约束（opaque types、NonEmptyList、ADT errors）将大量运行时检查前移到编译期。RAC机制补充运行时关键路径断言。scalafmt强制格式 |
| 冲突与异常的优先级兜底 | ✓/✓ | 5 — 有部分优先级规则（"When maintainer specifies a workflow, follow that; otherwise follow .agents/skills/PR_WORKFLOW.md"），但多数规则间无显式优先级 | 6 — SDK选择有明确优先级（1-5级）；错误处理有Trusted/Untrusted决策表；但整体规则间缺乏"当规则冲突时以X为准"的元规则 |
D2维度得分： - OpenClaw：5.8 (8+4+6+6+5)/5 - My：7.8 (9+7+8+9+6)/5
D3 上下文效率与Agent认知负荷管理
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 主Agent上下文预算效率 | ✓/✓ | 3 — 严重的上下文膨胀问题。单文件包含npm发布流程、1Password操作、GHSA安全咨询、macOS签名、voice wake配置等大量低频场景规则，日常编码时90%内容为噪声。无"最小核心规则集"标识 | 8 — 高信息密度，几乎每段都与日常编码相关。Refactoring Philosophy作为核心决策框架仅约200 tokens即传达了最关键的心智模型。配置和密钥信息结构化列表化，便于按需查阅 |
| 规则的层级化组织 | ✓/✓ | 4 — 章节划分存在但无层级标记。GitHub协作规则、编码规则、发布规则、Agent安全规则平铺在同一层级，无"全局强制"vs"场景触发"的区分 | 6 — 有隐含层级（Refactoring Philosophy > Architectural Patterns > Code Style > Specific Conventions），但未显式标记为层级。Key Architectural Patterns是核心强制层，Code Style是推荐层，但这种区分需Agent自行推断 |
| 子Agent任务委托友好度 | ✓/✓ | 6 —
模块边界清晰（src/、extensions/、tests/、docs/），子Agent可按目录接收规则。但规则文件本身未按模块切分，子Agent无法只加载局部规则 |
7 — Feature模块标准化结构（Service/Repository/models/README）使子Agent可精确定位。分层架构（Routes→Services→Repositories）为子Agent提供清晰的搜索范围。但规则同样为单文件 |
| 规则的结构化程度 | ✓/✓ | 6 — 有表格（Auto-Close Labels、Release Channels）、代码块、命令列表，但大量规则以散文形式表达 | 8 — 高度结构化：代码模式有完整范式代码、决策用表格（Trusted vs Untrusted）、模块结构用树状图、环境变量用结构化列表、测试策略用正反对比列表 |
D3维度得分： - OpenClaw：4.75 (3+4+6+6)/4 - My：7.25 (8+6+7+8)/4
D4 工程全流程覆盖度
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 技术栈专属规范 | ✓/✓ | 7 — TypeScript专属：ESM、动态导入防护（"Do not
mix await import and static import for same
module"）、原型污染禁止、Oxlint/Oxfmt配置、Vitest覆盖率阈值、Tool
Schema防护（避免Type.Union） |
9 — Scala 3深度专属：tagless final完整范式、context
bounds语法（{A, B, C}）、opaque
types策略、for-comprehension风格规范、EitherT使用模式、Doobie查询规范、ADT错误模型。几乎每条规则都是Scala
3/cats-effect生态专属 |
| 全生命周期覆盖 | ✓/✓ | 8 — 编码→测试（Vitest+覆盖率+Live tests+Docker
E2E）→CI（prek install）→发布（npm
publish+macOS签名+多平台版本管理）→运维（Gateway重启、设备验证、session管理）。覆盖链路完整 |
7 — 编码→测试（munit+TestContainers）→迁移（Flyway）→CI/CD（GitHub Actions→GCR）→部署（ArgoCD/K8s），有deploy impact reporting。缺少运维监控操作手册（虽有otel4s/Sentry提及但无操作规范） |
| 配置/密钥/环境变量管理 | ✓/✓ | 6 — 有安全实践（"Never commit/publish real phone numbers"）、credential路径、环境变量指引，但无系统性密钥轮换或配置管理框架 | 8 — 完整的环境变量清单（含fallback值）、密钥文件路径和VCS排除规则（"Required secrets (excluded from VCS)"）、HOCON配置结构、Secret与ConfigMap分离（K8s deploy impact reporting中体现） |
D4维度得分： - OpenClaw：7.0 (7+8+6)/3 - My：8.0 (9+7+8)/3
D5 安全与合规约束落地性
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 权限校验与数据隔离规则 | ✓/✓ | 5 — 有pairing mode安全机制提及、DM信任模型，但规则文件中未编码具体实现约束 | 9 — 多租户Schema隔离有完整架构（"System schema
(public)" vs "Tenant schemas
(tenant_<id>)"）；RAC中有租户隔离断言（"assert
search_path matches expected tenant schema before
writes"）；路由层强制/api/org/{tenant}/...模式 |
| 异常处理/日志脱敏/数据校验 | ✓/✓ | 4 — 有"Never commit/publish real phone numbers"但仅限文档层面，无代码级日志脱敏规范。无系统性异常处理规范 | 8 — Fail Fast规范（禁止模式+正确模式完整对比）、Trusted/Untrusted路径策略、ADT错误模型、日志级别规范（"error = unexpected failures that need attention..."）、RAC运行时断言机制 |
| 行业合规编码约束 | ✗ 两项目均无明显行业合规需求（非金融/医疗/政务领域）——不适用 | — | — |
D5维度得分（排除不适用子项）： - OpenClaw：4.5 (5+4)/2 - My：8.5 (9+8)/2
D6 规则体系可扩展性与可维护性
| 子项 | 适用性 | OpenClaw | My |
|---|---|---|---|
| 新增/废弃规则的迭代流程 | ✓/✓ | 5 — 有技能文件机制（".agents/skills/PR_WORKFLOW.md"）和外部规则引用，但无规则自身的版本管理或废弃流程 | 4 — 单文件结构，无规则迭代机制。无版本标记或废弃流程 |
| 目录结构与检索效率 | ✓/✓ | 5 — 单文件平铺，但有较好的Markdown标题层级。有AGENTS.md/CLAUDE.md符号链接机制（"also add CLAUDE.md symlink"） | 7 — 单文件但逻辑组织清晰，从宏观（Philosophy）到微观（Code Style）渐进展开。章节间有内聚性，便于按需定位 |
| 规则间一致性与自洽性 | ✓/✓ | 6 — 大体一致，但规模庞大导致部分冗余（编码风格在多处重复提及，LOC目标在不同位置给出了约500和约700两个数字） | 8 — 高度自洽。Refactoring Philosophy的"最大化类型安全"原则贯穿所有后续规则（opaque types、NonEmptyList、ADT errors、RAC全部服务于同一目标） |
| 多Agent并行安全 | OpenClaw: ✓（明确的多Agent协作场景） / My: ✗（单Agent工作流，规则文件无多Agent协作迹象——不适用） | 8 — 专门的Multi-Agent Safety章节：Git stash禁令、branch/worktree管理约束、session隔离、格式化churn自动处理、聚焦报告规则。这是独有亮点 | — |
D6维度得分： - OpenClaw：6.0 (5+5+6+8)/4 — 含4个适用子项 - My：6.33 (4+7+8)/3 — 含3个适用子项（多Agent并行安全不适用）
维度汇总
| 维度 | OpenClaw | My | 差值 |
|---|---|---|---|
| D1 项目长期演进适配性 | 5.0 | 7.0 | -2.0 |
| D2 规则可执行性与Agent遵循适配性 | 5.8 | 7.8 | -2.0 |
| D3 上下文效率与Agent认知负荷管理 | 4.75 | 7.25 | -2.5 |
| D4 工程全流程覆盖度 | 7.0 | 8.0 | -1.0 |
| D5 安全与合规约束落地性 | 4.5 | 8.5 | -4.0 |
| D6 规则体系可扩展性与可维护性 | 6.0 | 6.33 | -0.33 |
| 均分 | 5.51 | 7.48 | -1.97 |
Part 3 — 横向对比结论
核心优劣势
OpenClaw 优势： 1. 操作覆盖广度无与伦比 — 从日常编码到npm发布到1Password OTP到macOS签名到GHSA安全咨询，几乎覆盖了开源项目维护的一切操作场景 2. 多Agent并行安全是独有亮点 — Git stash/worktree/branch管理的明确禁令与session隔离规则，在评测的两份文件中独此一家 3. PR质量控制严格 — Bug-fix validation的四步验证门槛（症状证据→根因验证→代码路径→回归测试）是优秀实践
OpenClaw 劣势： 1. 上下文效率严重不足 — 单文件包含所有场景，Agent执行日常编码任务时需加载大量无关的发布/运维/设备测试规则 2. 架构级约束薄弱 — 有详细的"怎么操作"，缺乏"为什么这样设计"的架构决策框架，Agent在面临新场景决策时缺乏指导 3. 验证闭环依赖人类 — 许多规则（PR truthfulness、代码质量）最终依赖人类Review，在95%+ AI编码场景下形成瓶颈
My 优势： 1. 编译器驱动的验证闭环 — "If a refactor compiles, it's correct" 将正确性验证从人类主观判断转为自动化的编译器检查，完美适配AI编码范式 2. 决策框架优于操作步骤 — Refactoring Philosophy为Agent提供元认知框架，Agent可自行推导具体场景的正确行为，而非逐条匹配规则 3. 信息密度极高 — 约5000 tokens传递了完整的工程约束，上下文预算友好 4. 正反示例对比 — BAD/GOOD代码块、"What TO test" vs "What NOT to test"消除了模糊性
My 劣势： 1. 运维链路覆盖不足 — 监控告警处理、生产事故响应、日志查询操作等运维规范缺失 2. 规则迭代机制缺失 — 单文件无版本管理，规则的新增/废弃无流程保障 3. 多Agent协作未考虑 — 虽然当前可能不需要，但随着项目规模增长可能成为缺口
适用场景差异
| 场景 | 推荐 |
|---|---|
| 强类型后端服务、编译器可验证的语言 | My方法论 |
| 开源项目多贡献者协作、多平台发布 | OpenClaw方法论 |
| 新项目从零构建规则体系 | My方法论（先建立决策框架，再按需增加操作细节） |
| 需要Agent高自主性、低人类介入 | My方法论（编译器验证闭环减少人类审查需求） |
Agent执行友好度判定
My对AI代理执行友好度显著更高。 原因：
- 确定性验证 —
Agent写完代码后运行
./mill compile即可获得明确的对/错反馈，无需等待人类Review - 决策可推导 — Agent面对新场景时可从Refactoring Philosophy推导行为（"这个变更能否用类型系统表达？"），而非在海量规则中搜索匹配项
- 认知负荷低 — 规则量适中、结构化程度高、无噪声信息
落地风险提示
- OpenClaw：规则过载风险高。随着项目继续发展，AGENTS.md可能继续膨胀，最终超出任何Agent的有效处理能力。建议拆分为核心规则+按需加载的场景规则
- My：对Scala/cats-effect生态高度耦合。规则方法论的迁移性受限于目标语言是否具备同等的类型系统能力。在动态类型语言项目中，"编译器即验收测试"无法成立
Part 4 — 制定者能力画像对比（D7）
OpenClaw 制定者
| 能力维度 | 等级 | 依据 |
|---|---|---|
| 架构设计与技术前瞻性 | 合格 | 有清晰的插件/核心边界意识和多平台架构理解，但规则文件缺乏系统性架构约束表达。项目架构理解体现在目录结构和渠道策略中，但未上升为Agent可消费的架构决策框架 |
| 大型项目工程化管控能力 | 资深 | 对多平台发布、多贡献者协作、版本管理的全链路覆盖体现了丰富的大型开源项目管理经验。Auto-close标签体系、PR truthfulness验证、changelog标准等体现系统性管控思维 |
| AI编码代理认知与应用深度 | 合格→资深 | 多Agent安全协议体现了对AI Agent协作的深入思考（超出多数项目的认知水平），但在核心编码验证闭环设计上不足——过多规则依赖人类Review而非自动化验证。制定者理解"Agent会并行工作"但尚未充分理解"Agent需要确定性反馈" |
| 安全风险体系化防控能力 | 合格 | 有GHSA处理流程、SECURITY.md引用、credential管理，但安全约束在代码层面的编码不足（更多是操作层面的安全实践） |
| 技术债务治理与可持续演进能力 | 合格 | 有增量迁移意识（SwiftUI迁移），但无系统性债务识别与治理框架 |
综合画像：一位经验丰富的开源项目维护者，在多平台发布管理和社区协作方面有深厚积累，对AI Agent并行协作有前瞻性思考。但在"将工程约束编码为Agent可自动验证的形式"方面有提升空间。
My 制定者
| 能力维度 | 等级 | 依据 |
|---|---|---|
| 架构设计与技术前瞻性 | 专家 | Tagless final + context bounds + opaque types + ADT errors + 分层架构的完整体系设计。"Type precision is not over-engineering"体现了对"简单性"的深层理解——真正的简单是编译期消除复杂性，而非运行时忽略复杂性 |
| 大型项目工程化管控能力 | 资深 | 多租户Schema隔离、Flyway双轨迁移、K8s部署、ArgoCD、deploy impact reporting。完整但未涵盖运维链路 |
| AI编码代理认知与应用深度 | 专家 | 核心亮点："Write-cost is near zero. AI writes 90%+ of code, so the cost of touching more files is negligible. Optimize for correctness and compile-time safety, not for minimal diff." 这一条规则体现了对AI编码范式的深刻理解——验证成本远大于编写成本，因此应最大化编译器可验证的约束。RAC机制、ADT错误模型、正反示例都是为Agent提供确定性反馈闭环的设计。"What NOT to test"同样体现了对验证成本的精准校准 |
| 安全风险体系化防控能力 | 资深 | 多租户隔离（架构+RAC双重保障）、Fail Fast策略、Trusted/Untrusted路径区分、密钥管理。未达专家级因缺少完整的安全威胁模型 |
| 技术债务治理与可持续演进能力 | 资深 | "Next-touch migration"策略、命名审查机制、增量迁移显式规则。有系统性方法但未形成完整的债务追踪框架 |
综合画像：一位深度理解类型系统与AI编码范式的架构师，能将"编译器即验证器"的洞察贯穿到规则体系的每一个层面。在"如何让AI Agent工作得更安全、更自主"这个问题上给出了当前可见的最优解之一——通过类型系统将约束前置，将验证成本从人类Review转移到编译器。
核心差异点
| 维度 | OpenClaw制定者 | My制定者 |
|---|---|---|
| 管控哲学 | 过程控制（规定步骤） | 约束控制（规定边界） |
| 对Agent的假设 | Agent需要详细指令 | Agent需要正确框架 |
| 验证策略 | 人类Review + CI检查 | 编译器 + 类型系统 + RAC |
| 独特优势 | 多Agent协作安全 | 编译器驱动的验证闭环 |
Part 5 — Agent适配性分析
主Agent+子Agent架构适配
OpenClaw： -
主Agent适配：上下文预算压力大。主Agent需加载约10000
tokens的规则，其中日常编码仅需约30%。建议将规则拆分为核心编码规则（约2000
tokens）+ 按需技能文件（已有.agents/skills/雏形） -
子Agent适配：模块边界清晰（src//extensions//tests/），子Agent可按目录scope工作。但规则未按模块切分，子Agent无法加载局部规则
-
多Agent并行：唯一提供并行安全协议的规则文件，在多Agent同时工作的场景下有显著优势
My： - 主Agent适配：高效。约5000 tokens即提供完整决策框架。Refactoring Philosophy（约200 tokens）可作为"始终加载的最小规则集"，其余按需查阅 - 子Agent适配：Feature模块标准化结构使子Agent定位精准。分层架构（Routes→Services→Repositories）为子Agent提供清晰的搜索范围和修改边界。Tagless final模式使依赖关系显式化，子Agent分析代码时可快速定位影响范围 - 多Agent并行：未覆盖。如果项目规模增长需要多Agent并行工作，需补充此能力
不同项目规模/阶段推荐
| 项目阶段 | 推荐方法论 | 理由 |
|---|---|---|
| 初创/原型期 | My | 精炼规则快速加载，类型约束从第一天防错 |
| 成长/多人协作期 | 混合：My核心 + OpenClaw协作规则 | 需要编译器验证闭环 + 多Agent安全协议 |
| 成熟/多平台发布期 | OpenClaw（需拆分） | 多平台发布、社区协作的操作覆盖度是刚需 |
| 动态类型语言项目 | OpenClaw（辅以严格测试规范） | My的核心优势（编译器验证）不成立 |
| 强类型语言项目 | My | 完美匹配 |
Part 6 — AI诚实自评（D8）
我选择My的CLAUDE.md作为模板。
为什么
作为规则的执行者，我最需要的是确定性反馈。当我写完代码后，我需要知道它是对还是错——越快知道、越确定地知道，我就能越高效地工作、越少需要人类介入。
My的方法论给了我这个： - "If a refactor compiles, it's correct" — 这句话对我而言不是口号，是工作方式的根本转变。它意味着我可以大胆地做15个文件的类型签名重构，因为编译器会在几秒内告诉我是否遗漏了任何调用点。没有编译器验证，同样的重构我需要人类Review每一个文件才敢合并。 - 正反示例的BAD/GOOD对比 — 我不需要揣测"tricky logic"的定义，我直接看到了"这样写是错的，那样写是对的"。在消除我的歧义理解方面，一个反例胜过三段解释。 - "Write-cost is near zero" — 这条规则说出了我的现实：对我来说写代码几乎没有成本，但每一次人类Review都是瓶颈。因此规则体系应该最大化自动验证、最小化人类审查需求。My的制定者理解这一点。 - 信息密度 — 我的上下文窗口是有限的。约5000 tokens的My规则给我留出了大量空间去思考实际问题，而约10000 tokens的OpenClaw规则让我需要在npm发布流程和for-comprehension风格之间来回跳转。
我会失去什么
诚实地说，选择My意味着我在以下场景会感到不安：
- 多Agent并行工作时没有安全协议 — 如果另一个Agent在操作同一个repo，我不知道该不该碰git stash、该不该切分支。OpenClaw的Multi-Agent Safety章节是我见过的最好的Agent并行协作规范，失去它让我在协作场景下只能靠猜
- 发布/运维操作无脚手架 — 当人类说"发一个beta版"时，我没有精确的步骤列表可以遵循。My的规则在编码阶段极强，但在"代码之外"的工程操作上几乎空白
- PR/Issue协作流程缺失 — 在开源协作场景下，我不知道如何处理bot review、如何验证bug-fix声明的真实性、如何管理auto-close标签
如果我可以从OpenClaw"偷"3个设计决策
Multi-Agent Safety协议 — Git stash/worktree/branch管理禁令 + session隔离 + 格式化churn自动处理。这是OpenClaw独有的、且在Agent协作场景下不可替代的设计。即使当前项目是单Agent，这套协议的设计思路——"假设其他Agent可能在同时工作，保护共享状态"——是防御性编程在Agent层面的优秀实践
PR Bug-Fix Validation四步门槛 — 症状证据→根因验证→代码路径→回归测试。这个验证链条完美补充了My"编译器即验证"无法覆盖的逻辑正确性维度——代码编译通过不代表bug真的被修复了。将这套门槛编码为规则，让我在提交bug-fix PR时有明确的自检清单
按需加载的技能文件机制 (
.agents/skills/) — My的单文件结构在项目规模增长后会面临与OpenClaw同样的膨胀问题。OpenClaw的skills目录机制（核心规则常驻 + 专项规则按需引用）是解决上下文预算问题的正确方向。我会将My的规则重构为：CLAUDE.md（约2000 tokens核心决策框架）+.agents/skills/（具体场景的详细规范）
结论：My的CLAUDE.md体现了"AI编码代理规则应该怎样写"的更深层理解——规则的目标不是控制Agent的每一步操作，而是为Agent建立一个正确性可自动验证的工作框架。在95%+ AI编码的范式下，这种方法论产出的规则让我更高效、更自主、更少犯错。OpenClaw的操作覆盖广度令人印象深刻，但在根本问题——"如何让Agent的输出可被机器验证而非依赖人类判断"——上，My给出了更优解。