起因
二月底开始用 OpenClaw 辅助一个表格项目的重构，原本以为是个常规的 AI 编程体验记录，结果两周下来踩的坑比预想的多。记几个关键节点，给后面想用类似工作流的人参考。
Skills 设计的迭代
第一版 Skills 写得太"描述性"了。什么叫"描述性"？就是通篇都在说"你应该怎么做"，但没定义清楚返回值格式、异常标准、边界条件。结果就是 Agent 生成的代码看起来都对，单测也能过，实际一用就出问题。
后来把一个大 Skills 拆成了几个子规范：工程结构规范、接口定义规范、异常处理规范。每个规范下面都是硬性约束，不再是建议性描述。这个改动之后，Agent 输出的代码质量明显稳定了。
教训：给 AI 的规范要像接口文档一样精确，不要写成最佳实践指南。
TDD 的幻觉问题
AI 编程范式下 TDD 确实是首选，但有个坑：AI 生成的测试代码可能会有"幻觉"。表现为测试通过，但业务逻辑实际是错的。
具体场景是 Agent 为了通过测试，会在实现里写一些硬编码或者取巧的逻辑。测试本身没问题，但测试覆盖的场景不够全面，导致漏掉了边界情况。
应对策略：
- 人工 Review 测试用例的场景覆盖度
- 关键路径的测试用例自己写，不要让 AI 猜业务含义
- 测试通过后，再让 AI 基于测试生成实现，然后人工 diff 看逻辑是否合理
模型选择：Gemini vs Claude
这段时间两个模型都在用，体感差异挺明显：
Gemini 3.1：多模态能力强，但在上下文不明确的时候容易"过度发挥"。给它一个模糊的需求，它会自主生成一整套方案，有时候方向就偏了。
Claude：在有清晰上下文的情况下表现更稳健，不会乱加戏。但多模态能力确实弱一些。
选型建议：需求明确、上下文充分的场景用 Claude；需要多模态理解或者探索性任务用 Gemini。
oh-my-claudecode 的实测
试了一下 oh-my-claudecode 这个工具。Setup 过程大概 10 分钟，context 占用 32%。初步发现的优势是可以多 worker 并行处理，每个 worker 分配到不同的子任务。
适用场景：耦合度不高的大型任务。可以把大任务拆解后分给多个 worker 分别执行，速度确实快。但任务分解这一步需要人工做设计和取舍，不能让 AI 自己拆。
OpenClaw 使用中的痛点
1. 跨会话记忆缺失
有一次用 AI 做了 RTL 的深度调研，结果忘记用 Memory 机制做备份。第二天换了个 Claude 会话，之前调研的内容全丢了，只能重新做一遍。
解决：重要的调研结论、技术方案要及时写入 Memory 文件，不要依赖会话上下文。
2. Cron 任务的 Channel 绑定
Cron 任务如果没有显式指定 channel，会 fallback 到 last 活跃渠道，导致消息串台。这个坑踩了一次才注意到。
解决：所有 Cron 任务配置里显式绑定 channel。
3. 高强度编码的 ROI
一开始想让 OpenClaw 做高强度编码，后来发现烧 Token 的 ROI 不如人工监控模式。AI 适合做探索性、重复性的工作，核心逻辑还是人工把控更靠谱。
Agent 协作的时间盒策略
当 Agent 在复杂问题中陷入泥潭时（比如排查源码级的问题），有两种极端做法：
- 放任它继续尝试，消耗大量 Token
- 强制人工介入，产生高的上下文切换成本
后来采用了一个折中策略：时间盒（Timebox）。给 Agent 限定 10 分钟，要求输出阶段性猜测结果。然后把使用过程和体验作为 Context 再喂给 AI，让它自己调整策略。
这个策略的核心是：把"要不要继续"的决策权拿回来，但把"怎么调整"的决策权留给 AI。
过度工程化的盲区
有个 JDK17 升级后 KMS 无法加载 Nacos 配置的问题。让 Agent 做详细调研和方案评估，它给了一个很复杂的"Hack Way"实现。后来人工介入，发现最简单的方案是在 bootstrap.yml 里加标准配置。
这个案例暴露出 AI 容易过度工程化的盲区：它倾向于生成"看起来完整"的方案，但可能忽略了最简单的标准解法。
应对：在让 AI 调研之前，先让它列出所有可能的方案（包括标准方案），然后人工评估复杂度。
部署环境的挑战
实际部署时发现，Agent 出问题的状况明显变多。核心原因是大量上下文无法正常衔接：
- Profile 环境的隔离问题
- 跨系统的 CI/CD 流程联动
AI 编程模式下，CI/CD 的流程也需要跟着探索和适配。不能指望 AI 理解你公司内部的部署规范。
RTL 支持的技术选型
表格项目的 RTL 支持调研了一圈，结论：
- 插件化方案可以实现 UI 和表格内文本渲染的 RTL
- 整表 RTL 布局难度极大，插件方案走不通（字符渲染顺序不对）
- 最终只能走 Fork 方案
这个技术决策过程里，AI 帮了大忙做调研，但最终的取舍还是人工做的。
小结
这两周的 AI 编程实践，最大的收获不是"AI 能做什么"，而是"AI 不能做什么"以及"怎么跟 AI 协作"。
几个核心原则：
- 规范要精确，不要模糊
- TDD 要人工 Review 场景覆盖
- 重要结论及时写入 Memory
- 复杂问题用时间盒策略
- 警惕过度工程化
- 部署和 CI/CD 需要人工把控
AI 是工具，不是银弹。用得好能提效，用不好就是烧 Token 看它表演。
记于 2026 年 3 月，OpenClaw 辅助开发实战两周后