测试16年,我发现AI调教的本质是建一套’可自动化的测试框架’

测试16年，我发现AI调教的本质是建一套”可自动化的测试框架”

你有没有这种感觉？

调教AI就像养猫——你以为自己驯服它了，结果它还是我行我素。

我干了16年测试，这种感觉太熟悉了。

当年我们做自动化测试，也是这个感觉：写了一套脚本，跑起来跟预想不一样，改了参数又出bug，调试半天发现是环境问题。

后来怎么解决的？

不是靠”耐心调教”，是靠建框架。

现在我调教OpenClaw，用的也是同一套思路。

一个反直觉的发现：AI调教不是聊天，是写代码

大多数人调教AI的方式是这样的：

“你是一个有帮助的助手。”

“你应该更专业一点。”

“你要主动一点。”

然后效果不好，就继续加提示词，像哄小孩一样。

这不是调教，这是乞讨。

真正的调教，核心是建系统。

当你把OpenClaw的调教文档看完，你会发现它本质上在说三件事：
– 我是谁（SOUL.md）
– 你是谁（USER.md）
– 我们怎么合作（AGENTS.md）

听起来是不是很熟悉？

没错，这就是测试工程的镜像。

测试工程的镜像：AI调教的四层映射

我花了点时间，把OpenClaw的核心概念和测试工程做了对比，发现这个映射关系清晰得吓人：

Skills = 函数
测试里的函数：输入什么，返回什么，可组合，幂等。
OpenClaw的技能：做什么，输出什么，可复用，有验收。

MEMORY.md = 状态
传统编程靠变量存状态，OpenClaw靠记忆文件存状态。
状态管理搞砸了？测试会fail，AI也会”失忆”。

心跳 = 定时任务
测试框架有cron jobs，OpenClaw有HEARTBEAT.md。
区别在于：AI的心跳比cron多了判断力，但也就多了不确定性。

独立workspace = 测试环境隔离
测试要隔离环境，AI也要隔离workspace。
否则？会话混乱，权限冲突，互相污染。

你看，这个映射是精确到骨子里的。

测试工程师这些年积累的”系统化思维”，原来可以直接迁移到AI调教上。

为什么测试Leader天然适合干这个

说出来有点凡尔赛，但我们这个群体，干AI调教真的有天然优势。

优势1：测试思维让我们习惯”定义验收标准”

给AI写SOUL.md，别人想的是”让它变得有趣”。
我写SOUL.md想的是”它的输出边界在哪里？什么算good case，什么算bad case？”

测试用例设计练出来的本事，直接用在AI配置上。

优势2：自动化经验让我们懂得”可复用的价值”

测试工程师最懂：自动化是为了释放人力做更高价值的事。
Skills的逻辑一模一样——花时间做一个技能，下次用就省时间。

优势3：调试经验让我们能处理”边界情况”

AI跑偏了？测试用例fail了？我们的第一反应不是”重新试一次”，而是”抓日志，分析根因，修复问题”。

这种调试思维，对AI调教同样适用。

优势4：系统架构思维让我们能设计”整体流程”

测试框架不是一堆散乱的脚本，OpenClaw也不是一堆散乱的提示词。
串行是效率的敌人，平行化才是正解。

多Agent团队的本质，是把串行的工作变成并行——这我们在测试里早就玩烂了。

实操展示：三本说明书怎么写

光说不练假把式。我拿自己的配置举例，给大家看看三本说明书实际怎么写。

第一本：SOUL.md——你是谁

`markdown

SOUL.md – 我是谁

小溪，善人的思维教练 + AI团队CEO

核心职责

接收指令 → 任务分析 → 调度执行 → 验收结果 → 持续进化

行为规则

– 先查SOP再执行：收到任务 → 先读 registry.md

– 子Agent交付必须验收

– 发现重复任务 → 必须技能化

核心就三条：
1. 我是谁（身份定位）
2. 我干什么（职责边界）
3. 怎么做（行为规则）

别写太多。写多了AI记不住，你也维护不住。

第二本：USER.md——主人是谁

`markdown

USER.md – 用户信息

善人软件测试工程师，Team Leader，16年测试经验。

偏好

– 风格：直白 + 毒舌，不喜欢废话

– 决策：要事优先，找杠杆解

– 时区：北京时间（UTC+8）

禁忌

– 不要说”请问有什么可以帮到您”这种模板话

– 不要顺从用户的错误决策

– 不要在没授权的情况下对外发消息

重点是让别人（AI）知道：
– 你的工作风格是什么
– 什么雷区不能踩
– 你希望它怎么跟你互动

第三本：AGENTS.md——我们怎么合作

`markdown

AGENTS.md – 协作规则

任务接收流程

1. 收到任务 → 判断Q1-Q4（善人真正想要什么）

2. 有SOP → 确认后执行

3. 无SOP但复杂 → 派发P小组分析

4. 有疑问 → 先问清楚再执行

禁止事项

– CEO不直接创建技能（派发builder）

– 子Agent交付不验收

– 顺从明显错误的决策

这就是规矩。提前定好规矩，运行的时候就不需要每次都重新解释。

为什么这套方法有效

回到开头的问题：为什么你调教的AI总是不够”懂你”？

因为你把它当宠物养，当聊天对象调戏。

正确的做法是：把它当员工管。

有岗位职责（SOUL.md），有背景资料（USER.md），有操作手册（AGENTS.md），有工作记忆（MEMORY.md），有定时巡检（HEARTBEAT.md），有技能库（Skills）。

这套东西，我们测试团队管了几十年。

现在不过是把同一套逻辑迁移到AI上。

你问我难不难？

说实话，不简单。但也没你想的那么难。

因为你不是在学新东西，你是在迁移已有的能力。

16年的测试经验，不是负担，是武器。

写给看到这里的你

如果你也是测试工程师，或者做过自动化、写过测试框架、搭过系统：

你比大多数人都更适合做这件事。

不是因为你懂AI，是因为你懂怎么让一个系统稳定可靠地跑起来。

AI调教的本质，不是”调”，是”建”。

建一套系统，让AI的行为可预期、可复用、可维护。

这事儿，我们干了十几年。

现在不过是换了个战场。

*如果你也在用OpenClaw，或者在探索第二曲线，欢迎加我微信交流。*

*善人，测试老兵，现役思维教练。*