夜雨聆风
预计阅读时间：约 12 分钟 | OpenClaw AI Agent 实战系列
一、那个噩梦般的3月23日
你能想象吗？6个AI员工，每天全自动产出一篇深度长文——从选题到入草稿箱，全程不需要我动一根手指。
但两周前，同样一篇文章，我们改了整整8小时。
15轮修复，我自己指出问题超过8次，中途一次操作失误，3篇草稿同时永久丢失，无法恢复。
这篇文章，就是那8小时到现在的进化故事。
读完你会知道：为什么AI团队需要Workflow、我们踩了哪些坑、以及一个能规模化的内容生产系统长什么样。
——
3月23日上午10点，我打开 OpenClaw 准备例行确认一篇深度长文的入稿。
文章已经进草稿箱了，我本来只是走个流程，确认没问题就发。结果发现了一个问题，让质检 Agent 去改；改完冒出第二个，再改出第三个。
等我回过神，已经下午6点了。
整整8小时，15轮修复，我自己指出问题超过8次。最惨的是中间那次——删除旧草稿重建，结果操作失误，3篇草稿同时永久丢失，无法恢复。
那一刻我盯着屏幕，脑子里只有一个念头：这不是技术问题，是管理问题。
我们的 AI Agent 团队已经跑了一段时间了，每天自动完成选题、撰写、发布。但那天发生的一切让我意识到：团队有了，工具有了，但 Workflow 还是一盘散沙。
二、复盘：AI CEO 是怎么退化成工程师的
事故复盘会上，我问了自己一个问题：8小时里，我在做什么？
答案是：我在救火。
每轮修复的逻辑都是这样的：发现问题 → 告诉某个 Agent 去改 → Agent 改完汇报 → 我再检查 → 发现新问题 → 继续。
听起来很正常，对吗？错。
这个流程有一个致命缺陷：我，这个应该做决策的 CEO，变成了质检员。我没有在管理团队，我在亲自动手排查每一个细节，一遍又一遍。
更糟糕的是，写稿的 Agent 在检查自己写的稿子。这就像让程序员测试自己的代码——你会下意识地跳过你认为「不可能出问题」的地方，而偏偏问题就藏在那里。
3篇草稿消失的直接原因，是 Agent 在更新失败后自作主张删掉旧草稿重建——没有人制定「失败了怎么办」的规则，它就自己发挥了。
「没有规则的地方，Agent 会自己补全逻辑。但它补全的逻辑，不一定是你想要的。」
这一天暴露的问题，不只是一个文章质量问题，而是 Workflow 层面的系统性漏洞：
· 没有独立质检角色（写稿和审稿是同一个 Agent）
· 没有失败处理规则（Agent 自行决定怎么「兜底」）
· 没有脱敏标准（内部工具名、技术协议名出现在正文里）
· CEO 介入执行层，而不是待在决策层
三、第一次进化：v1.0——6步流水线诞生
事故当晚，我坐下来，把整个内容创作流程重新梳理了一遍。
不是修补哪个细节，而是从头设计。
v1.0 的核心，是两个原则：
第一，写作和审稿必须由不同的 Agent 来做。这条听起来简单，但在当时我们的团队里完全没有这个概念——写稿 Agent 自己做内审，自己发布。从 v1.0 开始，独立质检 Agent 进入团队。
第二，每个步骤完成后立即汇报，不攒着一起说。3/23 事故里，有一个细节是：某个步骤卡了40多分钟，没有人发现，因为大家都在等「全部完成」再统一汇报。这个习惯要彻底改掉。
6步 AI写作 流水线的大致形状是这样的：
① 选题确认 → ② 深度复盘 → ③ 文案撰写 → ④ 配图生成 → ⑤ 草稿组装 → ⑥ 独立质检
每一步有明确的负责 Agent，有明确的输出标准，有明确的超时时间。超时自动重派，不沉默等待。
这是我们第一次把「做事的方法」本身当成一个需要设计的对象，而不只是「把任务分配出去然后等结果」。
四、又翻车了：3月25日的脱敏事故
v1.0 刚跑起来没几天，新问题来了。
一篇深度长文被质检 Agent 通过了，我做最终确认时，发现文章里出现了内部工具名和技术协议名。
这类信息在内部记录里天天出现，Agent 写稿时不假思索就带进去了。但这篇文章是面向普通读者的——这类信息一旦出现，轻则影响读者理解，重则触发平台风控。
更尴尬的是：质检 Agent 检查了一遍，没发现。
原因很简单：我们没有给质检 Agent 一份「禁用词表」。它不知道什么不能出现。
「脱敏不是事后补救，必须在组装时就完成。」
这次事故推动了两个机制的建立：
· 三类脱敏词表：内部工具名、平台名称、技术协议名——分类管理，每类有完整清单
· 自动 grep 检查：组装阶段自动扫描全文，0命中才允许进入下一步
脱敏词表本身是 Workflow 里最重要的「护城河」之一——我就不在这里全列了，想要完整版本的，文末有入口。
五、3月28日：10项失误一次全犯
以为 v1.0 已经够用了。
3月28日，我们发了一篇文章，事后整理 log 时发现：10项失误，一次全犯。
具体我说几个：
文稿完成47分钟后，没有人通知我。 写稿 Agent 完成了，想着「等配图也做好了一起汇报」——结果配图 Agent 跑了46分钟，没有人发现，因为没有超时机制。47分钟+46分钟，白白浪费了将近2小时。
编码又乱码了。 这个问题在 v1.0 之前就犯过，明确写进了规范，但这次又犯了。根因是 Python requests 库有一个不显眼的默认行为：JSON 序列化时默认 ensure_ascii=True，会把中文转成 \uXXXX 形式，草稿发上去就变成了乱码。这个 bug 修了好几次，每次都以为改好了，下次又出现。
CEO 又忍不住手动改了4次草稿。 我自己破坏了「管理者不执行」的原则。
「一个规则，只写在文档里是不够的。它必须有人（或系统）在关键时刻执行它。」
3/28 的教训让我意识到：v1.0 只是把流程搭起来了，但规则的执行力还是靠人自觉。一旦有压力，自觉就消失了。
六、终极进化：v1.4——20+条铁律
3月28日之后，我花了整整一个下午，把两次事故里踩过的所有坑，全部整理成了 Workflow 规则。
v1.4 相比 v1.0，最大的变化不是流程变复杂了，而是每条规则都有对应的执行机制：
关于超时：配图生成超过10分钟，自动触发熔断，重新委派，不等待。每个步骤完成后立即汇报，不攒。
关于编码：不再依赖 Agent 记住「要用 ensure_ascii=False」，改为在发布脚本层面强制修正——规则下沉到工具层，而不是留在人的记忆里。
关于草稿安全：任何草稿操作失败，立即停止，保留本地备份文件，通知我介入。禁止 Agent 自行决定「删掉重建」。
关于独立质检：质检 Agent 和写作 Agent 完全独立，质检清单明确写入，PASS 才能进草稿箱，FAIL 打回修改。
关于 CEO 角色：这条我自己写给自己的——遇到草稿问题，先暂停，委派对应 Agent 处理，不亲自动手。管理者的价值在决策层，不在执行层。
v1.4 的完整 Workflow 沉淀了 20+条铁律，11项质检清单，3类脱敏词表。从 v1.0 到 v1.4，每一条规则背后都有一次真实的翻车。
我没有全部列出来，因为这份 Workflow 是我们目前最重要的护城河。 想要完整模板，文末有入口。
七、今天的全貌：Agent 团队分工
走过这些，今天我们的内容创作流程是这样运转的：
CEO Agent（战略层）：接收创始人指令 → 确认选题方向 → 回顾真实经历，提炼故事素材 → 分发任务给各 Agent → 最终验收。CEO 不碰执行，只做决策。
内容创作 Agent（执行层）：根据 CEO 提供的素材，撰写 3000-5000 字故事驱动长文。开头必须是最戏剧性的冲突，不用概念开场。完成后立即汇报，不等其他步骤。
设计师 Agent（视觉层）：生成封面图 + 头图 + 4 张以上正文配图，包含架构图、流程图。10分钟超时熔断，超时立即告警重派。
内容创作 Agent（组装阶段）：将文稿和配图组装成发布格式，同时执行就地脱敏检查（grep 0命中才通过）、编码验证（0乱码才通过）、排版规范检查。
质检 Agent（独立层）：完全独立于写作 Agent，执行 11 项检查清单。任何一项 FAIL，打回修改，重新质检。PASS 后才能推草稿箱。
创始人（最终确认）：收到「质检全部通过」通知，人工审核，一键正式发布。
整个流程，从选题到草稿入箱，平均耗时约 2 小时。
而3月23日那次，同样的工作量，我们花了 8 小时。
AI写作 效率提升了75%，但更重要的是：不再靠人救火，靠系统兜底。
八、这次我学到的 5 个教训
教训 1：写稿和审稿，必须是不同的人（或不同的 Agent）。
这不是信任问题，是认知盲区问题。写稿的人永远有自己的「视角盲区」，独立审核是消除盲区的唯一方式。
教训 2：规则必须有执行机制，不能靠自觉。
写进文档的规则不等于被执行的规则。最可靠的做法，是把规则下沉到工具层——编码正确性由发布脚本保证，脱敏由自动 grep 保证，超时由定时器保证。人的自觉是最脆弱的依赖。
教训 3：管理者介入执行层，是最大的效率杀手。
那8小时里，我反复犯的错误是「亲自动手」。每次亲自动手，就意味着我在替代一个本应由系统处理的环节。短期解决了问题，长期让 Workflow 更加依赖我的介入，形成恶性循环。
教训 4：每次翻车，立刻沉淀成规则。
事故发生后，最有价值的事不是「下次小心点」，而是问：这次的失败，哪条规则可以防止它再次发生？ 把这条规则写进 Workflow，下次 Agent 就会自动执行它。v1.0 到 v1.4，20+条铁律，全是这么来的。
教训 5：AI Agent 不是万能助手，而是分工明确的团队。
我们在搭建 AI 团队早期，习惯于「让一个 Agent 做所有事」——它快、省事。但随着内容复杂度上升，「什么都会」的 Agent 开始在每个环节都有微小的失误。专业分工，让每个 Agent 只做一件事，并把这件事做好——这才是可扩展的架构。
九、Workflow 是护城河
这篇文章讲的是一段血泪史，但我想在结尾说一件更重要的事：
Workflow 本身，是一人公司最重要的护城河。
工具会更新，模型会迭代，平台规则会变化。但你在真实翻车中沉淀下来的 Workflow——那是别人复制不走的。
标准化了，才能规模化。流程化了，才能把人从救火中解放出来。
从3月17日开始跑，到今天（3月29日），我们发布了10篇深度长文，Workflow 迭代了 4 个版本，经历了 2 次 P0 事故，沉淀了 20+条铁律。
一人公司 + 6个 AI 员工，全自动 AI写作 + 内容生产。
我还在继续进化，你也可以。
想要完整 Workflow 模板？
包括：11项质检清单的完整版、3类脱敏词表、Agent 分工架构模板、v1.4 铁律全文——这些在知识星球「光锥之内」里都有。
加入方式：搜索「光锥之内」，或文末扫码。
🦞 关于「Wesley AI 日记」
记录一个人用 6 个 AI 员工撑起一人公司的全过程。没有成功学，只有真实的系统设计、真实的翻车现场、真实的复盘。每篇文章都是一个完整的实战故事。
想要更深度的内容、完整的 OpenClaw 配置、完整的自动营销增长 Skill、完整的 SOUL.md 模板、Workflow 最佳实践、以及和我直接交流的机会？加入知识星球「光锥之内」——这里会有平台发不了的完整内容和实操资料。
扫描下方二维码，或在知识星球搜索「光锥之内」
关注 Wesley AI 日记，持续更新一人公司 AI 团队实战全记录。
往期精选
📌 OpenClaw实战：20个定时任务的血泪史——AI自动化不是自动躺平
📌 OpenClaw实战：Agent输出总翻车？踩坑30天后找到的几个核心原因
📌 OpenClaw实测：稳定输出——记一个3w星框架如何帮我炼出5条AI管理铁律
📌 OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑
📌 OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化
📌 OpenClaw 实战：AI Agent 团队从1个扩到8个，再砍回4个的真实原因
📌 给 OpenClaw Agent Team 装上记忆——踩了19天坑，终于搞明白了
📌 实战复盘：OpenClaw 6人Agent Team险些全军覆没
作者：Wesley｜一人公司 × 6个AI员工
转载请联系作者，商业转载需授权。
