核心用法
OpenClaw Self-Improve 是一套面向 OpenClaw 生态的证据驱动型自改进工作流，专为需要可度量、可回滚、可审计的系统性优化场景设计。用户通过命令行脚本（init-improvement-run.sh、validate-improvement-run.sh、export-improvement-run-json.py）启动改进循环，覆盖审计、提案、实施三种模式。
标准流程六步走：
1. Preflight — 确认模式、目标、成功标准与代码库路径
2. Baseline — 捕获当前性能/可靠性/成本指标与 Git 状态
3. Hypotheses — 提出 1-3 条假设，按影响/风险排序
4. Approval Package — 生成 proposal.md，明确修改范围、验证门、回滚方案，必须等待用户显式批准
5. Implement — 仅执行已批准的修改，保持补丁最小化
6. Validate & Report — 运行预定义验证门，对比基线，输出 outcome.md 与 JSON 供 CI 消费
关键产出：run-info.md、baseline.md、hypotheses.md、proposal.md、validation.md、outcome.md，以及可选的 run-info.json/summary.json。
显著优点
- 度量优先：强制要求可量化的成功标准（如"网关启动时间降低 30%"），杜绝主观"感觉更快了"
- 审批门禁：
approved-implementation模式确保任何行为变更须经用户显式确认，防止自主循环失控 - 回滚就绪：每个提案包含回滚计划，验证失败时立即提供恢复步骤
- 自动化友好：JSON 导出与
--require-json验证 flag，天然适配 CI/CD 流水线 - 风险分级：
audit-only/proposal-only/approved-implementation三档模式，让用户按需控制暴露面
潜在缺点与局限
- 启动成本：需预先定义指标、约束、验证门，轻量优化显得笨重
- 工具链依赖：要求 bash/git/python3 及特定脚本位于 PATH 或
scripts/目录，环境不齐则阻塞 - OpenClaw 专属：目录结构、playbook 引用、输出契约均假设 OpenClaw 代码库，泛化能力有限
- 人工瓶颈：审批环节依赖用户响应，异步/自动化场景可能卡顿
- 无内置 A/B：仅支持前后对比，不具备多分支并行实验能力
适合人群
- OpenClaw 维护者需系统性优化性能、可靠性、成本
- 团队需向 stakeholders 展示"我们做了什么、效果如何"的审计链条
- 希望在 CI 中嵌入可复现改进循环的 DevOps/Platform 工程师
- 不适合：追求快速单点修复、或非 OpenClaw 代码库的通用优化场景
常规风险
- 流程惯性：过度追求流程完整，可能让小修复变成大工程
- 基线漂移：若基线测量时环境不稳定（如 CI 负载波动），后续对比失准
- 验证门设计缺陷：用户自定义的
validation-gate若覆盖不足，可能漏检回归 - 权限边界：技能明确禁止自动修改凭证/生产配置，但用户误配 scope 仍可能越界
- JSON 契约变更：自动化依赖的 JSON 输出若随版本演进，下游解析可能断裂