我是刘沛呈。雅德士在国内风电叶片检测领域算技术领先的一家,日常要发公众号—— 我用 OpenClaw 接入 DeepSeek 搭了套多 Agent 系统,把老板每天近一天的人工整理, 压到 30 分钟选题与审核。
小德工作流在雅德士公众号生产线已稳定运行数月,以下是从历史日志中提取的关键数据。
沛呈不是科班出身,但他能从一个真实业务问题出发,自己摸索出整套技术方案并坚持迭代到稳定能用——这份独立做事的能力,放在小公司或者创业团队都很需要。
我们是一家做风电叶片检测的小公司,公众号一直靠我自己抽时间打理。沛呈来了之后,花了几周时间设计了一套用 AI 多 Agent 协同跑的内容工作流——从搜国际前沿资讯,到筛选,到改写排版,再到推到草稿箱,基本不需要我动手。我每天大约 30 分钟选题和审核就能完成过去要接近一天的工作。
更重要的是,产出的文章专业度比我自己写得高。最近一篇关于风电检测的文章,有华能集团云南分公司的负责人主动打电话来咨询业务合作——这种来自大型央企的主动询盘,是我们公司这几年从来没有过的。
沛呈不是科班出身,但他能从一个真实业务问题出发,自己摸索出整套技术方案并坚持迭代到稳定能用,这份独立做事的能力,放在小公司或者创业团队都很需要。
以下是这套工作流要解决的真实业务问题——谁在用、为什么需要、原本怎么做、瓶颈在哪。
2003 年成立,前身为中丹合资企业,专注风电技术服务 22 年。FMCW + OFDR 双技术平台,多项国家发明专利。
原工作流由老板(刘杰)一人完成:搜索国际资讯 → 翻译筛选 → 改写排版 → 推送草稿。
核心判断:内容生产可分解为三个相对独立的环节,每个环节都能用 LLM + 工具调用替代人工。
系统替代手动搜索、筛选、改写、排版四个环节;老板只需在飞书群完成选题确认与终审两步。
信息源、时效、方向配比、Mode B 规则、写作风格、平台兼容——
六类业务约束分别由对应的 skill 文件、评分函数和后处理 check 实现,
确保系统每日稳定输出。
悬停任意卡片查看完整实现。
tavily 搜出来的每条 URL 按 6 层金字塔分级——L1 同行评议 / L2 行业期刊 / L3 国际工业媒体 / L4 制造商官方 / L5 学位论文 / L6 其他可验证。每天的资讯里国际源占比不低于 50%。黑名单覆盖百度百科、个人博客、电商页面、聚合转载。
researcher 工作空间的 scoring.md 通过关键词加权对每条结果打分;URL 域名匹配白/黑名单。mode_a_radar skill 在 evaluate 阶段剔除 L6 之外的可疑源。
Mode A 资讯优先 3 天内、最多 7 天;Mode B OA 论文优先 6 个月内、最多 12 个月;超出窗口的素材在 evaluate 阶段剔除。
search query 自动附加日期 filter;evaluate.md 给过期项扣减 freshness_score;最终 select 阶段一票否决超期项。
资讯方向分布与雅德士业务重心对齐——故障诊断 40%、叶片检测 25%、运维优化 20%、政策市场 15%。
researcher 在拆 query 时按比例分散关键词;evaluate 阶段统计 4 类计数;select 时强制按配比筛选,缺失方向触发补搜。
标题原文直译;OVERVIEW 客观;5 个 PART 只做 summarize + 翻译;结构对应原章节;KEY POINTS 客观;编者讨论顶部声明立场;编者讨论必须基于原文;严禁输出原文之外的任何内容。
writer 工作空间内独立 MODE_B_RULES.md 文件,写作前强制加载;输出后通过 verify 步骤反查每段对应原文位置。
营销词黑名单——震惊 / 重磅 / 革命性 / 突破 / 颠覆 / 领跑 / 重新定义;保持专业克制语气;所有需要主观判断的位置以 placeholder 保留,不代替决策。
MODE_A_RULES.md / MODE_B_RULES.md 固化风格规则;writer 后处理执行 banned_word check;待决策位置输出 [PENDING_OWNER_DECISION] 占位符。
微信公众号 HTML 不支持外部 CSS 与部分标签,style 必须内联;DeepSeek API 仅对白名单 IP 开放,经 VPN 调用不可用;DeepSeek 单次输出超过 8K 会被截断;飞书消息存在长度限制。
writer_task.md 内嵌微信兼容标签白名单;超长输出分块生成并拼接;服务器通过专线接入,不使用 VPN;飞书消息按段拆发。
系统由三个对称的 agent 工作空间(xiaode / researcher / writer)、飞书 Bot trigger、外部模型与搜索 API 组成。所有 agent skill 以 Markdown 文件形式持久化,可独立调试与版本管理。
@小德 跑 mode a 触发,小德接单。
每个决策都对应具体的取舍场景与技术理由,以下是项目中影响最大的五项。
OpenClaw 是类 Claude Code 的 file-based agent 框架,skill 直接是 Markdown 文件,可独立编辑、diff、版本控制。LangChain 的 prompt template 与 chain 结构在多 agent 场景下调试成本高,迭代速度慢。.md 即 skill 的设计也便于交付给非工程角色协同维护。
中文风电技术文献处理上 DeepSeek 表现充分,单 token 成本约为 GPT-4 的 1/20,适合每日跑批的高频调用。国内 IP 白名单稳定不需 VPN,与雅德士服务器网络环境兼容。Mode B 论文速读对长上下文的需求由 V4 的 128K ctx 满足。
xiaode 主调度、researcher 负责搜索评分、writer 负责生成排版。每个 workspace 有独立 skill 集与上下文,故障隔离清晰。某个环节出错可单独重跑而不影响整体。三者通过文件交换(JSON)通信,无内存依赖。
display_no 取代原 rank 字段v2.4 引入。原 rank 字段允许跳跃(1, 3, 7...),大模型在多轮对话中容易混淆"第几条"。改用 display_no 强制 1-N 连续,并配合 display-map.json 反查 rank,既保证人机沟通的稳定性,又保留原始评分顺序。
writer_task.md微信公众号编辑器对外部 CSS、特定标签、attribute 都有限制,普通 HTML 推送进去渲染会变形或丢内容。在 writer 的 skill 文件里硬编码兼容白名单(允许的标签集 + style 必须 inline),以及若干已验证的兼容写法模板。writer 输出严格按这些约束生成,绕过运行时校验,直接保证草稿箱可渲染。
以下是从真实生产环境记录的 6 个关键步骤截图——从飞书 trigger 到公众号草稿箱推送,完整链路可追溯。
小德每日产出两种成品类型——Mode A 行业日报(每天 10 条精选)与 Mode B 论文速览(OA 期刊深度解读)。两套模板的排版规则均刻在 writer 工作空间的 RULES.md 文件中,严格按约束 D-F 执行。
10 条精选,Editor's Note 提要 + 4 类方向配比 + 来源等级 L1-L6 标注。当日发布字数约 2,800,完整守约束 A-E。
OA 期刊深度解读,Title 原文直译 + Overview + 5 PARTS + Editor's Discussion + Key Points。8 条硬规则严格执行,0 编造。
每次迭代对应一个真实业务问题或技术瓶颈。以下是项目从原型到当前生产版本的演进路径。
最初的单 agent 实现,直接在终端跑搜索 + 改写。验证了 LLM + Tavily 组合可行,但人工 trigger 与无状态运行无法满足每日跑批需求。
将搜索-评估和改写-排版拆为两个独立 workspace。引入 scoring.md 与 evaluate.md 评分函数,为后续多约束工程化奠定基础。
新增 xiaode 主调度 workspace。老板通过飞书群 @小德 触发任务,所有交互在飞书完成,trigger 路径与原工作习惯一致。
在 Mode A 日报基础上新增 Mode B,专门处理 OA 论文深度解读。引入 8 条硬规则约束输出结构,严禁输出原文之外的任何内容。
display_no 取代 rank原 rank 字段允许跳跃,大模型多轮对话中数字漂移导致选题确认错位。改为 1-N 连续编号 + display-map.json 反查机制,稳定性显著提升。
将写作约束从 prompt 中抽出,固化为独立 MODE_A_RULES.md / MODE_B_RULES.md 文件。writer 必先加载,后处理 banned_word check。该版本运行至今,各项指标稳定。
每个坑都对应过实际的生产事故,以下记录问题表现、根因定位与最终修复方案。
部署初期所有 DeepSeek API 调用全部 401,排查覆盖了 token、签名、payload 格式,均无异常。最终发现服务器挂着 VPN,出口 IP 不在 DeepSeek 白名单内。修复:服务器通过专线接入,不使用 VPN。
网络 / 部署
Mode B 论文速读 5 个 PART 一次性输出,经常在 PART 4 中段被截。改为分段生成 + 显式拼接,每个 PART 独立 chat call,context 中传上一段输出做衔接。
模型 / 输出
早期版本中,模型偶尔会输出"看起来很合理"但实际不存在的 URL(如某期刊文章页)。仅靠 prompt"严禁编造"无效。修复:writer 输出后强制对每条 URL 做 HEAD 请求验证,失败项打回重写。
幻觉 / 验证
资讯卡片 25 条一次性推送时,频繁触发飞书 API 单条消息长度上限。修复:小德按段拆发,每段不超过 10 条,卡片之间加视觉分隔。
平台 / API
OpenClaw 2026.4.24 在 Windows 下报 Received protocol 'c:' ESM 模块加载错误 (左图,auto-restart 反复 7/10);同期飞书插件 API 多通道(feishu_chat / feishu_doc / send_as_bot)频繁返回 400 (右图,疑似 token 失效)。临时方案:回退 OpenClaw 4.2 + 改用 deepseek-chat 路由绕过 V4-Pro reasoning_content 不兼容;飞书发送失败时改走"消息回复"通道——既然 trigger 是飞书消息进来的,出口也走同一通道兜底。
以下是项目过程中得到的方法论判断,适用于 LLM 应用工程的真实落地场景。
让一个真实业务跑稳的关键,不是把 prompt 写得多精巧,而是把业务规则变成可验证的文件——skill.md、scoring 函数、后处理 check。Prompt 是表达,约束是工程。
v1.0 单 agent 先跑通,再逐步拆分;先解决 80% 高频问题,再优化长尾。这种节奏比一次性设计完整架构推进得更快,也更容易在真实运行中发现关键瓶颈。
LLM 对"听起来合理但实际不存在的内容"零抵抗力,尤其是 URL、数据、引用。仅靠"严禁编造"指令无效。必须在系统层做强制验证——HEAD 请求、域名白名单、对照原文反查——否则幻觉一定会进入生产。
AI 生成内容越像越要小心。涉及商业判断、对外口径、决策权属的位置,系统不应替业务方决策,而应输出 [PENDING_OWNER_DECISION] 占位让真人填。这条边界对建立信任至关重要。
微信 HTML 限制、模型 API 截断、IP 白名单、飞书消息长度——这些"工程基础设施"问题占据项目约 30% 时间。规划时必须把它们计入主路径,而不是当作可选的优化项。