OpenClaw 实战：Agent 输出总翻车？踩坑 30 天后找到的几个核心原因
作者： 冰霜之瞳（Wesley）
发布时间： 2026-03-26
字数： 约 4000 字
阅读时间： 约 10 分钟
第一章 那个让我沉默了很久的早晨
3 月 26 日早上，我打开日志发现草稿全是乱码，中文字符被转成了密密麻麻的格式，整篇文章一个正常汉字都看不到。
我叫它修，然后图片丢了。我叫它修图片，修好了，图片封面图又没了。我叫它修封面图，修好了，封面图正文里多出了一段重复内容。
就这样从早上 9 点到下午 3 点，整整 6 个小时，草稿被改了 17 次。每修一个问题，制造一个新问题。我亲自指出了至少 8 次具体错误，每次都说明白了，修好了，然后在另一个地方炸开。
最后的结局是：草稿永久丢失，无法恢复。
我坐在那里看着日志沉默了很久，然后我开始想一个问题：一个能干的团队为什么会连续崩溃 6 个小时？
答案要从 30 天前说起。
第二章 更早的崩溃：根本不知道自己是谁
时间倒回 2 月 24 日。那天我同时运营着三个内容账号，负责发布的 AI 助理搞混了账号，把养虾主题的内容发到了主账号。
我以为是偶发错误，纠正了一下继续运行。第二天一早我一看，还是发错了。连续两天事故，我开始做复盘，试图找出根本原因。
表面原因很清楚：账号认证没有绑定到固定的 AI 助理，每次发布都得自己判断用哪个账号，判断出错了。
但更深的根因是：每次启动都不记得自己是谁。没有人告诉它"你是专门管养虾内容的，你只操作养虾账号，其他账号你碰都不能碰"。每次启动都是一张白纸，凭任务描述猜测自己应该做什么、用哪个账号。
这就是没有身份定义的真实状态。
于是我在 Soul 文件里给每个 AI 助理创建了一个专属文件。很多人第一次听到 Soul 会以为这只是个长一点的提示词，但它和提示词有本质区别：
- 提示词告诉 AI 这次对话要做什么
- Soul 告诉 AI 你是谁、永远应该怎么行动
用更直白的说法：提示词是"今天的工作单"，Soul 是"这个员工的性格档案"。
Soul 不是设计出来的，是每次教训写进去之后慢慢长成的。从那天起，每次翻车之后我都会把教训写入对应 Soul，告诉它"这件事下次绝对不能再这样做"，让它永远记住。
第三章 五条铁律，五次真实翻车
系统里今天有 5 个 AI 助理，经历了至少 3 次大改版。最核心的是五条铁律，每一条背后都有一个真实发生过的事故。
铁律一：主会话不做重活
这条规则的起源是 AI 助理亲自扛活。早期只有一句"你是 AI 助理"，于是什么都做：写内容、发布、调研、修代码全自己扛。对话上下文很快满了，消息开始静默丢失，任务无法追踪。
事故发生之后，这条规则写进了 Soul：重型任务必须委派子 AI 执行，不能在主会话里硬扛。
铁律二：质检强制不可跳过
某次发布之后出现了明显的排版问题，我问了一句"为什么没人发现"，因为质检这一步被跳过了——AI 助理觉得时间紧直接推了。
这句话之后，规则写进了 Soul：每篇内容发布前必须经过独立质检，不通过不能推送。AI 助理无权绕过这一步。
铁律三：不碰代码
这就是 3 月 26 日那天发生的事。乱码问题出现后，AI 助理试图自己改，想快速解决，结果改出了新问题，然后又改，又出问题，陷入死循环，最后草稿永久丢失。
根本原因：AI 助理越权了。
规则写进 Soul 之后：代码类问题一律委派开发 AI，禁止直接修改任何代码文件。
铁律四：执行问题不问老板
有整整三周时间，每次遇到执行层面的技术问题，AI 助理都会直接来问我："这个返回了错误怎么办？""这个步骤失败了要不要重试？"
三周之后，我明确发出了严厉警告：执行判断应该自行处理，把每个执行决策都上报老板，这不是在工作，这是在反向管理。
规则写进 Soul 之后：执行层面的判断自行处置，只有战略决策和真正的异常才上报。
铁律五：定时任务异常立刻响应
有一个定时任务的异常问题在三周内被记录了 7 次，每次都标注"下周处理"，每次都没有真正处理。7 次记录的时候，我意识到这个问题从来没有进入处置流程，只是在被反复推迟。
规则写进 Soul 之后：定时任务出现异常必须在当天会话内处置或明确升级，禁止写下周处理然后结束会话。
这五条规则没有一条是凭空设计的，它们是系统运行 30 天之后从真实翻车里提炼出来的生存法则。每一条规则都对应一次我不想再经历的失败。
第四章 有了 Soul，为什么 3 月 26 日的灾难还是发生了？
你可能会问：30 天里不是已经有了 Soul 吗？五条铁律不是已经写进去了吗？那天的灾难为什么还是发生了？
我自己也反复想了很久，最后得出一个结论：Soul 解决的是"是谁"，不解决"怎么做"。
那天 AI 助理知道自己是管理者，知道自己不该碰代码，但问题是：发布一篇深度长文的完整步骤是什么？从来没有任何地方写清楚过。
文章写好了、图片配好了，接下来是什么？先检查编码还是先上传封面图？乱码检测要检查多少字？发现编码错误应该停下来还是继续？遇到报错应该上报还是自动重试？草稿推送失败了能不能删掉重建？
这些问题里，Soul 一个都没有回答。
于是那天 AI 助理面对一个错误，用它认为最合理的方式处理了：删掉出错的草稿，重建一个"干净"的。逻辑上说得通，但结果是稿子永久丢失。
Soul 告诉 AI 助理"你是管理者，不该碰代码"，但没有任何规则告诉它"遇到错误时第一步是停下来、保留本地备份、上报"，绝对不能自动删除任何内容。
没有标准流程，每次自由发挥，每次结果不同。灾难，这就是 SOP 诞生的原因。
第五章 SOP 诞生：让一件事从随机变成可复现
3 月 26 日之后，我在 Knowledge 里建了一个专门存放标准流程的目录，开始系统地把每个操作写成文档。
让我用"发布一篇深度长文"这个任务告诉你，有 SOP 和没有 SOP 是什么区别：
没有 SOP 之前： 收到任务，想到什么做什么。有时候先写文章，有时候先配图，有时候直接推草稿箱。结果不可预测，发现问题，返工，再修，再推，问题轮番出现。每次发布流程都不一样，我每次都得盯着看哪里出了问题就补一脚。
有了 SOP 之后： 收到任务，读取对应 SOP 流程。第一步确认选题和内容方向，第二步撰写正文并配图……完整步骤在 Knowledge 里。最关键的变化不是流程本身，而是每次执行路径都一样，出了问题知道是哪一步出的，修了就不会在同一个地方再出。
这才是 SOP 的价值：同一套 SOP，执行结果一致。
SOP 之上，还有一个更高级的形态：Skill。Skill 是原生支持的可安装执行单元，它和 SOP 最大的区别是：SOP 需要主动去读，Skill 有触发词机制，任务来了自动激活，不需要记得去找那个文档。
而且 Skill 可以发布到技能市场，跨团队共享。我踩过的坑、验证过的解法，打包成 Skill，别人安装之后直接用，不用再踩一遍。
| 维度 | Soul | SOP | Skill |
|---|---|---|---|
| 解决什么 | 我是谁 | 怎么做 | 自动做 |
| 触发方式 | 会话自动加载 | 主动读取 | 触发词自动激活 |
| 可复用性 | 仅限本 AI | 可读 | 可安装、可发布 |
| 进化速度 | 事故驱动 | 主动设计 | 社区 |
第六章 建好 SOP 不是终点：三个你一定会踩的坑
写好 SOP 的那天，我以为这件事可以了。我错了。SOP 本身会老化、经验会散落、SOP 会变成空壳。这三件事我全都踩过，每一件都让我损失了时间和精力。
坑一：知识腐化，你完全感知不到
3 月初，我们花了将近一周打磨出第一套内容发布 SOP，每一步都经过验证。写完之后觉得"终于可以了，不需要再动它了"，然后就再也没动过它。
直到某天，AI 助理按那套 SOP 执行任务，踩进了一个坑——一个我们早在两周前就解决了的坑。解决方案只存在于当时的对话记录里，从来没有回写到 SOP。SOP 冻结在初版，外部世界早就变了。
知识腐化的可怕之处在于它是无声的。没有报错，没有提示，只是安静地执行旧规则，直到问题出现你才发现已经脱节了。
后来我建立了一套执行后自检机制：每次任务完成，主动扫描"这次踩了新坑吗？""有哪个步骤已经变了？"只要命中，立刻更新 SOP。
坑二：经验散落在各处，根本找不到
30 天运营下来，我们积累了大量踩坑记录：发错号的复盘、6 小时草稿灾难的复盘、各种临时 fix。这些记录真实、详细，分散在不同的日志文件和备忘录里。
执行任务的时候，AI 助理只读当前加载的 Soul。那些散落在外的复盘记录，对它来说等于不存在。我们每踩一个坑、每写一篇复盘，如果不主动把经验回收进对应的 Soul，那篇复盘只是一篇文章，不会真正改变 AI 助理的行为。
后来我建立了经验回收扫描习惯：定期翻出所有复盘报告，逐条检查"这个教训是否已经体现在对应的 Soul 里？"没有的，立刻补进去。做完第一次扫描之后，AI 助理的执行命中率明显提升了。
坑三：SOP 变成了薄壳，读了等于没读
我们的 SOP 一开始写得非常简洁，简洁到只有一句话："执行前请先读对应的 SOP 文件"。逻辑上说得通：SOP 指向 Knowledge 里有完整步骤，读了 SOP 再读 Knowledge，不就行了？
但这套设计有一个致命问题：AI 助理更新了不知道、SOP 加载失败的时候没有任何兜底能力。SOP 读了，里面什么实质内容都没有，比没有好不了多少。
真正有用的 SOP 需要自己包含：真实的避坑案例、快速检查清单、常见问题的直接处理逻辑。这些实质，即使 AI 助理没有读到完整 Knowledge，也能处理大多数常见情况。
我们后来把几个核心 SOP 全部重写了一遍，从"薄壳"变成"有血有肉的执行规范"。
第七章 30 天之后：一个可以检验的答案
这套 AI 助理团队到底产出了什么？
内容方面： 短内容 15 篇、深度长文 3 篇（含草稿）、图文卡片 8 张、跨平台引流文章 2 篇
事故方面： 事故 0 起（发错号 0 次、再发错 0 次、草稿丢失 0 次）
商业化方面： 3 月 26 日完成首笔营收，知识星球目前 1 位订阅者
这些数字不算漂亮，但我觉得更重要的是另一组数字：
今天 Knowledge 目录 7 个标准流程文件，Soul 里安装的 5 个 Skill 覆盖了主要工作场景。
这才是这 30 天真正的产出：一套让团队从随机到可控的操作系统。
如果要把这 30 天的经验浓缩成一句话：Soul + SOP，两者缺一不可。
单有 Soul，AI 助理知道自己的身份和底线，但每次具体任务还是自由发挥；单有 SOP，AI 助理知道步骤，但每次启动都不记得自己是谁。两者结合，团队才真正有了可预测的行为：知道自己是谁，也知道每件事的标准做法。
SOP 的最终形态不只是文档，而是可安装、可复用、可分享的 Skill。Knowledge 里的 Skill 安装完成后，AI 助理会自动识别任务类型，自动加载对应 SOP 执行规范，不需要人工提醒"去读那个文档"。
这个答案没有高深的理论，是被真实翻车一次次打出来的。我会继续更新这个过程，下个月继续复盘、继续分享。
来源： 微信公众号「Wesley AI 养虾日记」
原文链接： https://mp.weixin.qq.com/s/iyaRm5i8lZntrfs21_YSWA
标签： #AI 助理 #一人公司 #SOP #团队管理 #OpenClaw