Day 3: 给 Clawdbot 瘦身：为什么单一职责原则在 AI 时代更重要？
标题备选
- 给 Clawdbot 瘦身：为什么单一职责原则在 AI 时代更重要？
- 拒绝"巨石 Prompt"：用微链架构 (Micro-Chain) 重构你的 AI 工作流
- 为什么你的 Agent 越聪明越容易出错？拆解它！
正文内容
在软件工程中，有一条黄金法则叫 SRP (Single Responsibility Principle)，单一职责原则。 意思是：一个模块应该只做一件事，并把它做好。
然而，到了 AI Agent 时代，大家好像突然把这事儿忘了。
我看过很多人的 Clawdbot Prompt，一写就是几百行，试图用一个 Prompt 解决世界和平：
"你需要打开这个网页，如果有弹窗就关掉，然后找到价格，如果价格低于 100 就截图，然后把截图转成文字，最后整理成表格发到我的邮箱，哦对了，邮件标题要包含今天的日期..."
这就是典型的**"巨石 Prompt" (Monolithic Prompt)**。
"巨石 Prompt" 的三宗罪
- 调试地狱： 整个流程跑失败了，是因为网页没打开？还是价格识别错了？还是邮件服务器挂了？你很难通过一个总的报错信息定位问题。
- 注意力涣散： LLM 的上下文窗口虽然大了，但注意力机制（Attention）依然有限。当你要求它同时关注"关弹窗"、"比价格"和"发邮件"时，它在每一个子任务上的表现都会下降。这就像让你一边骑独轮车一边抛球一边背圆周率。
- 牵一发而动全身： 你想改一下邮件标题的格式，结果改完发现它突然不会关弹窗了。因为你的指令改动影响了模型对上下文的整体理解。
解决方案：微链架构 (Micro-Chain Architecture)
把那个巨大的任务，拆解成一串小任务。每个小任务是一个独立的 Agent 或步骤，通过定义好的接口（Interface）传递数据。
步骤 1：抓取器 (The Scraper)
- 职责： 只管把网页内容弄下来，清洗成干净的 Markdown 或 JSON。不分析，不判断。
- Prompt 示例：
"访问此 URL，提取所有商品信息。忽略侧边栏和广告。只返回纯 JSON 数据。"
- 输出：
raw_data.json
步骤 2：分析器 (The Analyst)
- 职责： 拿到数据，执行业务逻辑（筛选、计算）。
- Prompt 示例：
"读取 raw_data.json。筛选出价格低于 100 的条目。计算平均折扣率。返回筛选后的列表。"
- 输出：
filtered_data.json
步骤 3：执行器 (The Actor)
- 职责： 发送通知、写数据库。
- Prompt 示例：
"读取 filtered_data.json。给 admin@company.com 发一封邮件。这是邮件模板..."
架构对比图
Before: 线性赌博
[ 抓取 + 分析 + 发送 ] -> 成功率 80%
(任何一个环节出错 = 全部重来，Token 钱白花)
After: 模块化流水线
[抓取 Agent] --(JSON)--> [分析 Agent] --(JSON)--> [发送 Agent]
为什么这样做更稳定？
- 容错隔离： 如果邮件服务挂了，你的抓取数据还在。你只需要单独重试"发送"这一步，不需要重新去爬一遍网站。
- 专注度提升： 在"分析"阶段，LLM 不需要关心 HTML 标签的噪音，只专注于数据本身，幻觉率大幅降低。
- 可测试性： 你可以单独拿 10 条数据测试"分析器"，调试 Prompt 直到满意，而不用每次都去真实访问网页（慢且费钱）。
实战建议
检查你现在手头的 Clawdbot 任务。 如果你的 Prompt 包含 "然后" (and then) 这个词超过两次，大概率你应该拆分它了。
拆分标准： 如果某一步可以单独重试而不影响其他步骤，它就应该是一个独立的模块。
明天，我们聊聊在这样的架构下，如何追踪每一个步骤的状态——因为当任务被拆散后，如果还没有日志，你就真的瞎了。
标签：#系统架构 #PromptEngineering #Clawdbot #AI开发 #单一职责