用 Claude Code 做 SDD：我如何把微信公众号内容生产拆成一个可实时调用的工作流

type

Post

status

Published

date

Mar 24, 2026

slug

summary

用 Claude Code 做 SDD：我如何把微信公众号内容生产拆成一个可实时调用的工作流

为什么我会做这个项目

我一直对“AI 能不能真正进入业务流程”这件事很感兴趣。相比单点地调用模型生成一段文本，我更关注另一层问题：当需求变成一个可重复、可协作、可追踪的内容生产过程时，应该如何把它拆成稳定的工作流，并让不同入口都能调用它。

基于这个出发点，我做了一个以微信公众号内容生产为核心场景的工作流项目。这个项目不是去追求“自动发布”或“全自动写稿”，而是聚焦在更可控、也更贴近实际协作的范围内：把选题输入、自动调研、资料评估、模板整合、正文生成、AI 配图、图片上传、草稿保存，整理成一条能够稳定产出公众号草稿的链路。

对我来说，这个项目不只是一个“AI 写稿”的 demo，更像一次相对完整的 AI 产品实践：我既关注最终生成什么，也关注这条链路为什么这样设计、如何被约束，以及未来如何接入IM工具。

这个项目想解决的，不只是“生成”，而是“稳定”

很多 AI 内容项目第一眼看都很像：输入一个主题，输出一篇文章。但真正落到可用场景里，难点往往不在于模型能不能写，而在于链路是否稳定、职责是否清晰、失败是否可定位。

我在梳理这条公众号内容生产工作流时，重点解决的是三个问题：

把内容生产拆成明确阶段，而不是一段模糊的大 prompt

让工作流有单一入口、单一主链路和单一结果，降低维护成本

把“可实时调用”作为后续扩展方向，而不是把系统做成一次性的本地脚本

也正因为这样，这个项目天然适合用 SDD（spec-driven development） 的方式推进。相比先写再改，我更倾向于先把目标链路、节点职责、失败边界和实施范围写清楚，再进入具体配置和改造。

我是怎么使用 Claude Code 加 SDD 来推进这个项目的

在这个项目里，我借助Claude Code 加 Superpowers skill从设计文档到测试一步步完成。

在仓库里，我先明确写下公众号工作流的设计草稿文档，列出了工作流主要流程：

输入主题/要求 → 自动调研 → 资料评估 → 模板整合 → 正文生成 → AI 配图 → 图片上传 → HTML 格式化 → 保存公众号草稿

随后，借助superpowesr中的脑暴命令，使得claude code引用我设计草稿，一步步完善具体节点的功能，在这过程中，借助SDD中的规范性，大模型会不断追问细节并逐渐完善设计文档，直到它对设计文档无歧义时，并会调用subagent进行审稿，同时通知我判断是否执行。

在与Claude Code协作中，对我帮助最大的地方有以下：

1. 帮我从已有工程材料中抽取结构事实

当项目里已经有多份设计文档、计划文档、工作流约束时，Claude Code 很适合做“结构化阅读”和“要点提炼”。这对于工作流类项目尤其重要，因为很多时候真正难的不是写出一个节点，而是确认：

哪些是当前主链路

哪些能力应该保留

哪些分支其实应该被收敛

哪些失败策略必须在设计阶段就锁死

2. 帮我把模糊想法写成可执行规格

比如“图片生成需要更稳定”这种说法其实很空。真正能指导后续实施的，是把它写成：

严格串行

顺序字段保留

非最后一张等待 5 秒，避免RPM限制

最终由单一节点装配文章

不允许图片失败后继续保存草稿

Claude Code 很适合把这种口头层面的意图，推进成一份更清晰的设计说明。

阶段一：围绕 n8n，把公众号内容生产拆成一条可落地的工作流

这个项目的第一阶段，是围绕 n8n 来设计和收敛公众号内容生产链路。

我把它理解为一个典型的 workflow 问题，而不是单纯的 prompt 问题。因为核心挑战不在于“某一步能否生成”，而在于每一步如何衔接、如何约束、如何失败即停。

第一阶段的主链路

在实现过程中，我最在意的是每个节点的职责边界。例如：

自动调研 负责收集写作背景与素材，不承担后续风格判断

资料评估 负责去噪、筛选、归纳，输出可写作素材

模板整合 负责把题材与模板收敛成统一结构

正文生成 只保留单一生成策略，避免多版本竞争

图片链路 必须作为正式步骤参与，而不是可选附加项

草稿保存 是最终落点，不承担前序失败补偿

阶段一补充：我如何用 Google Stitch 把工作流 MVP 转成可演示的产品原型

在把 n8n 工作流收敛清楚之后，我没有直接停留在“节点可运行”的状态，而是进一步把它往用户可理解、可演示的产品形态推进。这里我使用了 Google Stitch 来快速生成桌面端 Web 原型，再根据实际工作流去调整信息架构和页面分工。

这样做的原因很直接：n8n 更适合验证流程能否跑通，但它并不是最终用户使用产品时的界面。对于一个面向内容生产的 AI 产品来说，用户更关心的是“如何发起任务、如何查看调研结果、如何编辑大纲和文章、如何确认发布状态”，而不是底层节点之间如何连线。

因此，我在原型阶段没有把产品做成“工作流编辑器”，而是把它抽象成一个更接近真实使用场景的 AI 内容工作台。它的核心页面包括：

任务创建页：输入选题、风格、目标读者等基础要求

调研工作区：查看自动调研结果、资料来源和可写作素材

大纲与正文编辑页：确认文章结构、修改正文内容

配图与发布页：查看 AI 生成图片、完成草稿预览和公众号保存

对我来说，使用 Google Stitch 的价值不在于“快速出一个好看的页面”，而在于它让我更快地验证一件事：如果把 n8n 作为 workflow 底座，这条链路在产品层面应该如何被用户理解和操作。

这一步也让我更明确地区分了两层问题：

workflow 层 关注能力编排、状态推进和失败控制

product 层 关注用户入口、信息呈现和交互路径

我觉得这对 AI 产品实习生这个岗位尤其重要。因为很多 AI 项目容易停留在“能跑起来”的 demo 阶段，但真正往前走一步，需要把工作流能力翻译成用户可理解的产品原型。对我来说，Google Stitch 在这个项目里起到的，就是这样一个从 MVP 到原型表达的加速作用。

原型展示视频链接（https://watch.wave.video/mIUrLhYDxtUHyYQ5）

阶段二：把 n8n 作为能力底座，接入 OpenClaw，通过IM入口调用

如果说第一阶段解决的是“内容生产链路如何被定义”，那第二阶段我关注的是“这条链路如何被调用”。

通过ClawHub中的n8n skill可以将 n8n 接入 OpenClaw，这意味着可以通过 QQ、飞书等 IM 工具，把原本偏后台的工作流，变成可以被实时触发的能力入口。

为什么我会关注 IM 入口

因为在很多团队场景里，用户不会愿意专门进入一套复杂后台去发起任务。更自然的方式，往往是在已有沟通工具里直接发起调用。通过IMgon，工作流就从“后台存在的一条链路”，变成“前台可调用的一项能力”。

得益于爆火的Openclaw，现在人们可以通过IM工具接入Openclaw，有了一个24小时在线的小助手。

我觉得这也是我对 AI 产品形态的一点理解：入口很重要。很多能力不是做不出来，而是没有被放进用户已经习惯的操作环境里。

在我看来，通过openclaw也能实现生成一篇文章配上精美的图片并生成到公众号，但是由于openclaw这类产品本质上是个黑盒，一报错只能从堆积如山的日志中试图找出问题。而n8n这类的工作流编排刚好解决了这类问题，具有完整的评估以及记录流程，同时工作流中的agent节点也可以实现内容编写，图片生成这类创意性任务。

结尾

如果让我用一句话概括这个项目，我会说：

我在做的，不是“让 AI 自动发一篇文章”，而是把内容生产这件事，拆成一条可以被定义、被约束、被实时调用的工作流。

这也是我理解中的 AI 产品工作：不是只会调模型，也不是只会画流程图，而是能够在真实场景里，把模型能力、工作流编排和用户入口组织成一个能持续演进的系统。