卡神写在前面：一个人干全流程，迟早出岔子
早些时候我把写文章、配图、发布全交给一个智能体一把梭。刚开始觉得省事，后来连续翻车：有一篇正文里混进了别的选题的案例，有一篇发布后才发现字数不够被我自己定的标准卡掉，还有一篇封面带了不该有的字。问题不在智能体笨，而在于”写、审、发”三件事塞给同一个角色，它既当运动员又当裁判，自己写的错自己看不出来。
这篇讲怎么把活拆开：一个负责写、一个负责审、一个负责发。各管一段之后，整个流水线反而更稳、更快。下面都是我在 kas2.com 上发 34 篇、跑每日自动发文这条真实链路里摸出来的。
一、单智能体为什么到顶了
单智能体处理”一段式”任务很顺：你让它写一段文案、跑个脚本、查个数据，它干得漂亮。但一旦任务变成”写→检查→改→发布→回写记录”这种长链路，单智能体就会暴露三个瓶颈。
第一是上下文越长越容易飘。一篇长文写到后半截，它可能已经忘了开头定的风格和数字，前后对不上。第二是没有独立审查视角。它刚写错一句，转头自己”检查”时往往顺着原思路自检，发现不了逻辑漏洞。第三是出错没有缓冲。写完直接发布，一旦有错就直接对外了，撤回成本比写的时候高得多。
我踩过最典型的坑是：有次让它”写一篇并直接发布到分类137″，它把另一篇待发选题的提纲也揉了进去，发布出去才发现串了内容。从那以后我定下规矩——写完不能直接发，必须过一道独立检查。
二、角色怎么拆：写、审、发三段
拆法很简单，按”责任”而不是按”功能”分。我把一条内容流水线拆成三个角色：
- 写手（Writer）：只管把文章写出来。输入是选题和大纲，输出是草稿。它不用管发布、不用管配图合不合格，专注把内容写扎实、数字写对。
- 审校（Reviewer）：只管挑错。它拿写手的草稿，按固定清单核——字数够不够 1500、案例有没有串、数字有没有前后矛盾、封面图有没有违规文字、链接是不是占位。它不写新内容，只判”能发 / 打回”。
- 发布（Publisher）：只管把审过的稿子发出去并回写记录。它不修改内容，只执行发布脚本、做 HTTP 自检、把 Post ID 写回队列。
关键是这三段互相独立、不共享”我要让它一次搞定”的心态。写手知道后面有人审，反而写得更放得开；审校知道这是最后一关，检查得比作者本人还较真；发布知道内容已审过，执行时只需盯技术成功率。
三、写-审-发流水线长什么样
落到我们真实的日常是这样一条线：
- 取任务：每天定时从 content_queue.md 读状态为待写的选题，按顺序取最多 5 个。
- 写手出稿：每篇生成正文 HTML + 用文生图做封面（蓝青+橙、活力、无文字），封面裁掉底部 50px 去水印。
- 审校过堂：逐篇核对五件事——中文字数 ≥1500、案例真实不串、数字前后一致、封面无”图片由AI生成”等违规字样、链接非占位。
- 发布执行：组装清单 → 构建 articles_agent.json → SSH 上传并执行 publish_agent.php 发到分类 137（不加二维码）→ 逐篇 HTTP 自检。
- 回写：把 Post ID 写回队列，本篇状态从待写变成已发。
这条线跑下来，单篇出错率明显比”一个角色一把梭”低。因为审校那一步专挑刺，很多我自己写的时候意识不到的毛病（比如某段案例其实该属于另一篇）会在那儿被拦下。
四、各管一段为什么更稳
核心原因就一句：检查者不能是写作者本人。人自己写的东西会有”路径依赖”——你刚写下”孟加拉 25500BDT”，自检时脑子会自动补成”对，就是 25500″，很难质疑它。但换成另一个角色（哪怕是同一个智能体的另一段 Prompt），它没参与写作，会老老实实拿数据去核对。
我在财务建模那次体会最深：ECOHUB 参数里”利率 1.36、押金 5%、佣金 350″，ECOLINK 是”利率 1.72、押金 0%、佣金 800″。如果让写模型的同一个角色去核，它容易顺着写的时候的印象走。后来我让一个独立角色做”跨表交叉验证”——把两份参数摆一起比表头、比公式引用、比最终 ROI——它当场揪出我把 ECOLINK 的佣金错填成 350 的问题。这一道独立审查，直接避免了对客报错价。
五、实际怎么搭：别想复杂
你不用一上来就上”多智能体框架”。我们用的是最朴素的方式：同一个工具，不同阶段的 Prompt 当不同角色用。
- 写阶段：给它”你是写手，只输出正文和封面，不发布”的明确约束。
- 审阶段：给它”你是审校，拿以下清单逐条打勾，只输出问题列表和’通过/打回’结论”的约束，并且不把写作上下文带进去（重新开一段，只喂草稿）。
- 发阶段：给它”你是发布执行，按脚本发到分类 137，发完做 HTTP 自检，回写 ID”的约束。
如果工具支持真正的多智能体编排（比如分角色子代理、任务交接），那就把这三段配成独立 agent，写手产出交审校、审校通过交发布。本质不变：交接点就是检查点。每段只对自己的那段负责，段与段之间用”产物 + 检查结论”传递，而不是”我顺便把后面的也做了”。
六、什么情况值得拆，什么情况别拆
不是所有活都该拆。一句话判断：一次性的、出错了能立刻改的小活，单智能体一把梭最高效；重复跑的、对外发布的、出错代价高的长链路，必须拆。
- 值得拆：每天自动发文、财务模型对外报价、BD 对外话术定稿、服务器变更——这些要么高频、要么出错难收场。
- 别拆：临时查个资料、改个文案错别字、跑个一次性统计——拆了反而增加步骤和等待。
我们每日自动发 5 篇的 automation 就是典型”值得拆”：它每天跑、对外可见、出错就是发错内容，所以严格分了取数→写→审→发→回写五段。而偶尔我让它临时算个指标，就直接一把梭了。
结尾
多智能体协作的本质不是”用更多 AI”，而是”把责任切开”。一个写、一个审、一个发，每段只对自己的产出负责，段与段之间的交接就是天然的质检点。这套打法在我们 34 篇发文、每日自动发布、财务建模对外报价上都验证过——它不会让你写得更快，但会让你发得更稳、更少翻车。
下一篇我聊”数据交叉验证”：为什么就算它算的账，我也坚持再核一遍，以及那套”跨表比表头、比公式、比 ROI”的具体做法。关注卡神，咱们把重复劳动交给机器，把判断留给自己。
