optim

name	optim
description	当用户要求优化、提速、降低启动时间/资源占用/输出体积，或报告脚本、配置、代码太慢、变慢、 卡顿、启动慢、内存占用高时使用。
metadata	{"openclaw":{"emoji":"⚡"}}

optim — 优化技能

执行前置

遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。

核心原则

1. 先测量，后优化：没有基准就没有优化；不测量就动手是臆断。
2. 主导项优先：先做复杂度与规模分析，识别主导项与可忽略项，只优化主导项。
3. 正确性优先：优化不得改变对外行为（输出、退出码、语义）；正确性 > 性能。
4. 最小改动：只改实测瓶颈所在处，遵循代码库既有约定；不做无依据的预先优化。
5. 验证闭环：每轮优化后先做正确性回归，再复测基准，量化对比。
6. 循环迭代至成功：一轮未达目标不停止——回到瓶颈分析，优化方案后再测， 循环直至成功或用户终止；每次迭代在终端摘要中说明。
7. 数据诚实：基准数字必须实测，绝不虚报收益。

触发时机

• 用户要求性能优化："优化"、"性能"、"提速"、"太慢"、"变慢"、"卡"、"启动慢"、 "降低内存"、"减少资源占用"、"优化脚本"、"优化配置加载"
• 用户要求改善资源占用：内存、磁盘、进程数、输出体积
• 用户要求"优化代码可读性/结构"但未提性能：先澄清目标（可维护性优化不属于本技能默认职责）
• 与其他技能配合：问题定位先 debug；优化后验证 → test；查看优化前后改动 → diff； 优化后打标 → tag；优化 skill 自身 → skill-creator

优化目标分类

目标	测量指标
执行速度	wall time、CPU time
启动速度	冷启动到可用时间（如 shell 配置加载）
资源占用	内存 RSS、磁盘占用、进程数
输出体积	终端输出/产物大小
可维护性	无性能目标，须用户明确要求后另行处理

工作流程

Step 1. 明确目标与约束

• 目标：优化什么（速度/内存/启动/…）、期望量级；
• 约束：不得改变对外行为（输出、退出码、别名、PATH 顺序）；兼容范围（机器、shell 版本）；
• 缺项先向用户提问（所有问题第一次交互一次性全部提出，用户一次回答，不逐次追问），不臆断。

Step 2. 测量基线（先测量）

# 秒级计时
/usr/bin/time -v <cmd>          # GNU time：含 RSS 等详情
time <cmd>                      # shell 内置

# 毫秒级计时（GNU date）
start=$(date +%s.%N); <cmd>; end=$(date +%s.%N)
echo "$start $end" | awk '{printf "%.3fs\n", $2-$1}'

• 测量 3–5 次取中位数，排除首跑缓存/后台干扰；
• 平台差异：macOS 无 date +%s.%N，用 date +%s 秒级或 perl 计时；
• 长任务/大代码库：profile（perf、strace -c 统计系统调用、gprof、py-spy）；
• 把测量命令与数据在终端摘要中说明。

Step 3. 分析瓶颈（识别主导项）

物理直觉 + 工程实证，按以下顺序排查：

1. 复杂度分析：找 O(n²) 循环、循环内重复计算、逐项线性扫描；
2. 调用开销：shell 中每次外部命令 = fork+exec；循环内调用外部命令是常见主导项；
3. IO 密集 vs CPU 密集：磁盘/网络 IO 通常远慢于计算，优先削减 IO；
4. 启动开销：shell 配置加载（source 大文件、启动即执行的命令、插件初始化）；
5. 隔离验证：注释/隔离嫌疑段对比测量，确认耗时显著变化（同 debug 的二分思想）。

Step 4. 制定方案（权衡取舍）

维度	权衡原则
正确性	优化不得改变语义，正确性优先
简洁性	优先简单正确的方案，不引入华而不实的设计
可维护性	复杂度上升必须由实测收益支撑
性能	只优化实测瓶颈，不做无依据优化

shell 常见优化手段（按性价比排序）：

1. 消除冗余：删死代码、重复执行、无谓赋值；
2. 减少外部命令：字符串处理用参数展开/内置 （${var#prefix}、${var%%suffix}、${var//a/b}）替代 sed/awk/grep 子进程； 循环内避免反复管道与 echo 子进程；
3. 批处理：整批读入（read、sort/uniq 替代循环内逐项 grep）；
4. 延迟加载：启动不做的事推迟到首次使用（lazy alias、按需 source、延迟 compinit）；
5. 缓存：结果缓存避免重复计算（注意缓存失效策略）；
6. 算法替换：排序查找替代线性扫描、hash/查表替代逐项比较。

Step 5. 实现（最小改动）

• 只改瓶颈处；遵循代码库约定与既有 API；
• 优化与功能改动分离；触及系统配置（PATH、rc 文件）前先说明意图；
• 改动后 bash -n <script> 语法检查。

Step 6. 复测验证（闭环）

1. 正确性回归：输出/行为与基线一致（diff 对比）；bash -n 通过；
2. 复测基准：同 Step 2 方法多次测量取中位数，与基线对比；
3. 收益不达预期 → 回到 Step 3 重新分析（循环尝试直至成功）；
4. 收益微小且复杂度代价大 → 向用户报告权衡，由用户决定取舍。

Step 7. 总结（结构化输出）

✓ 优化完成
  目标:   <优化目标>
  基准:   <1.24s → 0.83s, -33%, 3 次中位数>
  改动:   <文件:行号>  <改动说明>
  验证:   <正确性回归通过; bash -n 通过>
  权衡:   <付出的复杂度/可维护性代价，无则省略>

  遗留:   <未处理项/风险，无则省略>

错误处理

场景	处理
优化目标不明确	一次性列出全部候选（速度/内存/启动/可维护性）先提问，不逐次追问
无基准工具	time/date +%s.%N 手动多次计时取中位数
测量抖动大	增加测量次数、关闭后台干扰、取中位数而非均值
优化后行为变化	回退该改动、修正方案、重新回归验证
收益微小	报告权衡（复杂度 vs 收益），由用户决定取舍
无法量化收益	说明为定性优化（可读性/健壮性），不虚报数字
平台差异（macOS 无 date %N）	秒级或 perl 计时；避免 GNU-only 特性或提供回退
多次迭代未达目标	向用户报告进展与瓶颈结论，不无限循环
与修复/初始化需求混淆	bug → debug 技能；初始化 → init 技能

注意事项

• 以实测数据为准，不凭感觉优化；虚报基准数字是严重错误；