OpenClaw 的使用收获、感想、启发与对测试工作的思考

1. 先说结论

如果只用几句话总结这段时间对 OpenClaw 的感受，我会这样说：

OpenClaw 真正有价值的地方，不只是“能接 Telegram、能调模型、能装 skill、能做点自动化”，而是它逼着人去重新思考一件事：AI 到底应该以什么身份进入工作流。

在浅层使用里，它看起来像一个会查资料、会写文档、会打开浏览器的工具；但在持续折腾之后会发现，它更像一个可以被塑形、被调教、被治理、被分工的工作空间。再往后走一步，真正有价值的甚至不是某个具体功能，而是借助 OpenClaw 这套文件规则、角色协作和工作流机制，把一套适合编码工程、适合团队协作、适合知识沉淀的方法抽象出来。

如果回到测试工作本身，这段折腾带来的最大启发也不是“测试能不能全交给 AI”，而是：AI 已经开始重写开发上游的生产方式，而测试作为下游，必须重新定义自己的承接、审查、评估与策略调整方式。

---

2. 对模型的认知变化：技能 + 灵魂

这次使用 OpenClaw 带来的一个很深的变化，是对模型身份的重新理解。

以前更容易把模型看成工具：

• 会写点代码
• 会查点资料
• 会生成点文案
• 会回答问题

但在 OpenClaw 这套机制下，模型越来越不像一个“调用即用的函数”，而更像一个具备两层结构的协作对象：

1. 客观技能：它会什么、不会什么、能不能做事
2. 内在灵魂：它的角色、风格、边界、工作方式、默认姿态

所以，模型不是冷冰冰的工具，而更像：

• 同事
• 助理
• 搭档
• 某种长期合作的“伴侣型”工作对象

这也是为什么后来会给它起名：莫菲 Murph。

起名这件事表面上是个小动作，实际上背后是一种工作关系的变化。它意味着：

• 不再只把 AI 当作一次性调用对象
• 而是开始把它当作一个需要持续协同、持续训练、持续调整边界的角色

这对后续的规则设计、记忆治理、skill 规划、Team 模式，其实都有很深影响。

---

3. 为什么会越来越依赖 OpenClaw

客观说，自己本来常用的工具并不少(这些工具不仅仅只是编码使用) ，比如：

• Codex
• Antigravity
• OpenCode

但目前确实已经逐步对 OpenClaw 形成比较强的依赖 (也在承接部分编码工作)。

这种依赖不是单纯“迁移成本高”，而是几个因素叠加后的结果。

3.1 可玩性高，开源系统天然值得折腾

开源系统最大的魅力不只是免费，而是它允许你不断折腾：

• 能改
• 能试
• 能接插件
• 能调规则
• 能搭自己的工作空间

这对喜欢折腾 AI Agent 的人来说，几乎天然有吸引力。

3.2 skill 已成型，投入使用后不想迁移

一旦 skill 不再只是 demo，而是真正进入日常工作流，它就会产生粘性。

因为 skill 本质上沉淀的是：

• 你的规则
• 你的用法
• 你的表达偏好
• 你的工作方式

这时候迁移不只是“换个工具”，而是要迁移一整套被调教过的工作习惯。

3.3 喜欢 Telegram 对话窗口

这点其实非常现实。

相比在 IDE 里一板一眼地和 AI 互动，Telegram 的对话窗口更轻、更自然，也更适合碎片化触发任务。IDE 往往容易让交互显得机械、枯燥，而 Telegram 更像和一个在线搭档随时说一句话，让他去做事。

3.4 它够热、够新、够值得研究

OpenClaw 本身就处在 AI Agent 这波浪潮里比较有代表性的前沿位置。再加上背后很多思路、协议、规范，和 Anthropic 推动的一些行业标准、工作流方式高度相关，所以它不只是个工具，也是一个很好的研究样本。

3.5 它刚好卡在自己的研究方向上

AI Agent、AI 编程、模型评测、自动化工作流，这些本来就是长期关注的方向。OpenClaw 在这个交叉点上，天然就更容易成为主阵地。

---

4. 一个越来越明确的判断：能用代码实现的，就尽量不用 skill

这次折腾里，越来越清晰的一个结论是：

skill 不是万能药。

在特定场景和垂直业务里，如果一个能力完全可以通过脚本、代码、现有技术栈稳定实现，那么优先用代码往往更稳、更可靠、也更便宜。

这背后的原因很简单

方案	优点	缺点
脚本 / 代码	稳定、可测试、可复跑、低成本	缺少对话式灵活性
skill	表达灵活、规则编排强、适合对话入口	成本更高、稳定性依赖模型、边界更难控

所以最合理的边界应该是：

更适合 skill 的场景

• 对话式整理
• 风格控制
• 规则编排
• 结构化输出
• 跨步骤工作流组织

更适合脚本 / 代码的场景

• 可确定的批处理
• 规则很死的流程
• 高频稳定执行任务
• 垂直业务中的核心逻辑
• 对可靠性、免费性、可复测要求极高的任务

这个判断很重要，因为它能防止“什么都往 AI skill 上堆”，最后反而把系统做虚。

---

5. Markdown 已经变成默认表达介质

另一个很明显的变化是：随着和 AI 打交道越来越多，Markdown 已经逐渐成为内容表达的默认介质。

原因并不复杂，但非常扎实：

• 纯粹
• 简洁
• 格式统一
• 轻量
• 易共享
• 模型友好

当规则、记忆、日志、技术文档、产出物、自动化结果都越来越多时，Markdown 几乎是最自然的共同语言。

所以后来很多东西都会自然而然地收束到 Markdown：

• 规则文件
• 技术文档
• 记忆文件
• .learnings/
• 技术总结
• 周报与日报
• 输出型 skill 的交付结果

从这个角度看，Markdown 不是单纯的格式选择，而更像 AI 工作流里的“通用接口层”。

---

6. 知识怎么沉淀：对话过程本身就是高价值资产

这次折腾里，还有一个很深的体会是：

真正有价值的不只是配置结果，而是和 AI 一起把事情做成的过程。

因为在每个阶段的配置、调优、安装、排障过程中，往往都要进行很多轮对话。你开一个头，不停调整姿势、方向、目标；AI 去执行、去试错、去整理、去落地。这个过程中天然会产生很多技术价值：

• 有思考
• 有方案
• 有先后执行顺序
• 有原因
• 有边界
• 有 todo
• 有取舍

这类内容，如果只停留在聊天记录里，其实是浪费。因为它们已经具备成为：

• 技术文档
• 工作流总结
• 规则文件
• skill 草稿
• 团队经验沉淀

的条件。

也正是因为这个认知，后来才专门做了一个 skill：

• tech-doc-organizer

它的目的不是“把聊天记录排版一下”，而是：

根据当前任务对话记录，整理成可复用的技术文档。

这一步意义很大。因为从这里开始，对话不再只是过程，而是正式进入产出链路。

---

7. 两个后续方向：系统级别与应用级别

随着折腾深入，后续路线其实已经越来越清楚，主要会分成两条主线。

7.1 系统级别：继续深挖 OpenClaw

这条线更偏底层能力和框架优化，包括：

• 系统调优
• 规则收敛
• 插件 / 外挂
• 技能治理
• 记忆系统设计
• 浏览器能力与调度能力拓展

这条线的目标不是做一个更花哨的工具，而是把 OpenClaw 打磨成一个更稳、更省、更可扩展的工作空间。

7.2 应用级别：回到真实业务与产出

另一条线更偏业务承接和实际产出，例如：

• skill 沉淀
• 示例产出
• 可复用工作空间模板
• 开发 → 测试的衔接
• 测试辅助工具
• SOP 建立

这一条线更关心的是：

这套东西最后怎么服务真实工作，而不是只停在技术折腾本身。

这两条线必须同时存在。只做系统优化，会陷入“工具迷恋”；只做应用输出，又容易失去底层掌控力。

---

8. 一个很重要的再判断：真正有价值的不是初级控制，而是架构思维迁移

如果只看表层，OpenClaw 能做的事情很容易被理解成：

• 查点数据
• 建个文档
• 打开浏览器爬点内容
• 做些简单控制操作

这些当然有用，但它们其实都还停留在相对初级的阶段。

真正更有价值的地方在于：

在把本地 OpenClaw 调到一个相对理想状态后，开始做架构思维迁移。

也就是说，不再只想着“这个工具能不能替我点个按钮”，而是开始想：

• 这套文件规则机制能不能变成公共项目
• 这套角色协作能不能复用到编码工程里
• 这套工作空间设计能不能抽象成一套框架
• 这套思维能不能迁移到别的 AI coding / vibe-coding 场景里

这一步的价值，远高于单次操作自动化。

反过来说

很多初级电脑控制操作，本来就不一定需要 OpenClaw。

对于技术团队、垂直领域、定制化业务来说，很多能力原本就可以通过：

• 现有技术栈
• 传统脚本
• 自动化框架

稳定实现，而且免费、低成本、可控。

所以 OpenClaw 的真正价值，并不在于“替代已有成熟方案做简单事”，而在于：

• 给低门槛用户降低自动化使用门槛
• 给非技术人员提供原本难以触达的能力
• 给技术团队提供一套可进一步抽象、迁移、演化的工作空间思路

也正因为这样，非技术人员和其他部门使用 OpenClaw 完成一些偏自动化流程时，会更容易感到兴奋——因为这些能力在过去是有门槛的，而现在被大幅拉低了。

---

9. OpenClaw 带来的启发：它能做什么，不能做什么

这部分如果不说清楚，后面的测试思考就容易跑偏。

9.1 它能做的：日常辅助、代码工程调度、思维迁移

日常工作辅助

OpenClaw 很适合做一些高频但结构化的日常工作辅助，例如：

• 需求分析
• 工时评估
• 文档生成
• 用例二次评审
• 测试脚本与工具生成
• 测试数据分析

这类任务通常特点是：

• 需要一定思考
• 需要一定表达
• 有一定结构化输出要求
• 但不要求百分百确定性执行

代码工程方向

它也很适合做代码工程中的主 Agent / 调度员：

• 规划 agent
• 需求解析 agent
• 编码 agent
• 文档 agent
• 审查 agent

再去协同现有 IDE 或代码工具链。

思维迁移

更有价值的，是把 OpenClaw 的思维方式迁移到别的项目里，例如 vibe-coding 场景。这种迁移不一定依赖 OpenClaw 本身，却可能借鉴它的：

• 文件规则机制
• Agent 分工方法
• 记忆与复盘层设计
• 对话式任务治理方式

---

9.2 它不能做的：替代完整测试自动化体系

这是一个必须说清楚的边界。

目前来看，OpenClaw 这类工具并不适合替代完整的测试自动化体系，尤其是你真正关注的那两层核心能力。

自动化测试至少有三层

层级	说明	关键词
第一层	操作自动化：点击、输入、等待、滚动、上传	action
第二层	验证自动化：断言什么算对、什么算错、如何等待、如何重试、如何避免时序竞争	think
第三层	质量自动化：测哪些、为什么测、怎么测、失败属于谁、是否阻断发布、如何沉淀为下一轮知识	think

OpenClaw 的强项在哪里

OpenClaw 主要强在：

• 第一层：操作自动化
• 稍微能碰到一点第二层

但离第三层还很远。

而真正的测试工作价值，恰恰主要集中在：

• 第二层：验证策略
• 第三层：质量判断与责任边界

再加上费用成本和维护成本，现阶段对于：

• 项目测试
• UI 自动化
• API 自动化

这类事情，仍然更倾向于使用成熟自动化框架来实现。

这是非常理性的边界判断。

---

10. 对测试工作的进一步思考

这次折腾 OpenClaw，最后最值得延展的，不是“测试能不能用 OpenClaw 代替”，而是它如何倒逼测试工作重新定位自己。

10.1 AI 代码产出正在提效，但也在制造新的测试问题

AI 编码带来的直接变化是：

• 写得更快了
• 产出规模更大了
• 辅助生成能力增强了

但这并不意味着测试工作减少，反而会带来新的挑战：

• 测试覆盖怎么跟上
• 代码质量怎么审查
• 未知问题怎么发现
• 后续维护成本怎么评估

换句话说，AI 解决的是生产速度问题，但测试面对的是：

速度上来以后，质量和可维护性怎么兜住。

10.2 AI 在测试方向的全面应用还远未成熟

一个必须承认的现实是：

• AI 在测试方向的全面应用比例仍然不高
• 可靠性和准确性依旧是关键顾虑

所以现在不能高估它，也不能完全忽视它。更合理的定位是：

AI 是增强器，不是替代品。

AI 更擅长：

• 提速
• 扩规模
• 辅助生成
• 辅助整理
• 辅助分析

而测试工程师真正负责的是：

• 判断
• 策略
• 责任
• 风险控制
• 质量结论

这两者不是一个层次上的职责。

10.3 影子 AI 与数据风险问题不能回避

AI 进入工作流后，还有一个现实问题：

• 员工使用未经授权的 AI 工具
• 数据泄露风险
• 信息污染
• 不可控的产出来源

这类“影子 AI”问题会越来越常见。

所以测试工作后面除了传统质量问题，也会更频繁地面对：

• AI 使用边界
• 数据安全
• 工具授权合规
• 输出可信度

这些新型风险。

10.4 测试范围可能需要重新切分

未来测试工作范围可能不再只盯业务功能测试，而会出现更明确的分层：

• 原有业务测试
• AI 项目测试
• AI 代码质量测试

这意味着测试职责本身可能会扩张。

不只是测功能对不对，还要看：

• AI 生成的代码是否可靠
• AI 产出的策略是否合理
• AI 辅助流程是否造成新的系统性风险

---

11. 现阶段更值得探索的方向

如果把这些思考落实到当前阶段，最值得探索的，不是“让 AI 直接接管测试”，而是先把测试和开发之间的新衔接关系看明白。

11.1 先熟悉开发团队的 AI 辅助编程现状

测试作为下游，必须先知道上游发生了什么。

需要熟悉的内容包括：

• 开发团队现在怎么用 AI 辅助编程
• 用了什么策略和方案
• 产出物长什么样
• 工程结构有没有变化
• AI 生成代码占比是多少
• 哪些模块最容易出现 AI 生成痕迹

这是后面承接测试工作的基础。

11.2 测试要做好“承载和衔接”

如果开发上游已经开始大量使用 AI，测试就不能还用原来的假设去接。

而应该开始做：

• 对 AI 产出代码的审视
• 综合评估
• Bug 类型归类
• 问题趋势分析
• 基于趋势调整测试策略和侧重点

换句话说，测试不只是“验收代码”，而开始变成“评估一套新的上游生产方式是否健康”。

11.3 回到真正主线：开发 → 测试的衔接 + 辅助工具 + SOP

这也是最值得继续做下去的方向：

• 开发到测试的衔接机制
• 测试辅助工具
• 测试 SOP
• AI 产出代码的审查框架
• Bug 类型与趋势归因
• 测试策略动态调整

这条线比单纯追求“让 OpenClaw 去点页面、跑脚本”要有价值得多。

---

12. 下一步值得分享的内容

基于目前已经形成的积累，后面最值得分享的几个主题已经比较清楚：

主题	价值
OpenClaw Team 模式配置 + 示例	展示多 Agent 协作的实际形态
Self-Improving Agent 使用示例	讲清怎么记、怎么用、什么时候用
代码工程工作空间使用示例	展示 OpenClaw 思维如何进入编码工程

这些分享如果继续做下去，实际上已经不只是“工具教程”，而是在逐步形成一套对外可解释的方法论。

---

13. 最后的结论

回头看，OpenClaw 带来的最大收获，并不是某几个具体能力，而是它提供了一个足够开放、足够可塑、足够接近真实工作流的环境，让人有机会重新理解：

• AI 应该以什么身份进入工作
• 什么该交给 skill，什么该交给代码
• 知识该怎么沉淀
• 工作空间该怎么治理
• 多 Agent 协作该怎么设计
• 测试工作又该如何面对 AI 改写了的上游开发方式

如果只停留在“会查数据、会开浏览器、会生成文档”，那还只是初级阶段。真正更有价值的，是已经开始把 OpenClaw 的规则机制、架构思维、工作流设计迁移到公共项目、迁移到编码工程、迁移到测试承接与 SOP 建设里。

所以这段时间最大的变化，不是“多学会了一个工具”，而是逐渐形成了一个更清晰的判断：

AI 工具真正的价值，不在于替人点按钮，而在于帮助人重构工作方式。

而对测试来说，这个判断尤其重要。因为未来要面对的，不只是 AI 能帮忙做什么，而是：

当开发上游已经被 AI 改写之后，测试该如何重新定义自己的位置、职责与方法。

这才是 OpenClaw 折腾之后，真正留下来的更大问题，也是更有价值的问题。

---

爆款标题备选

1. OpenClaw 折腾之后，我对 AI、测试和工作方式有了哪些新判断？
2. 不只是工具：OpenClaw 带给我的收获、启发，以及对测试工作的再思考
3. 从折腾 OpenClaw 到重新理解测试：AI 时代下游团队该怎么看自己？
4. AI 工具真正改变的不是按钮操作，而是工作方式：一份 OpenClaw 使用反思
5. 当开发被 AI 改写后，测试怎么办？从 OpenClaw 使用谈几点真实感受

推荐标签

#OpenClaw #AIAgent #Testing #EngineeringPractice #KnowledgeManagement #TechnicalWriting #AI自动化