一篇文章发五个平台:我用 TRAE Work 搭了条内容分发流水线,2 小时变 20 分钟
写完一篇技术文章,真正结束了吗?
以前我以为结束了。后来连续写了几篇文章才发现,正文只是第一关:掘金要 Markdown,其他平台可能要富文本;一个平台需要摘要,另一个平台需要导语;标题长度、代码块、图片链接、话题标签,各家规则都不一样。最麻烦的是,改完格式之后还要人工从头检查一遍,生怕某个代码块被吃掉,或者复制粘贴时多出一段奇怪的空行。
我最近用 TRAE Work 把这部分工作整理成了一条内容分发流水线:一份 Markdown 原稿,自动生成不同平台的发布版本,再统一做格式检查和发布前确认。
它没有把"写文章"变成按一个按钮就能发出去的黑盒,反而把最容易出错的重复劳动拆成了几个可以检查的小步骤。原来一篇文章从写完到适配多个平台,常常要花一两个小时;现在通常二十分钟左右就能完成初版,剩下的时间用来做人工复核。
这篇不讲 TRAE Work 的概念,也不展示一个看起来很厉害但无法复用的 Demo,直接记录我是怎么把它用在内容分发上的。
一、最耗时间的不是写,而是写完之后的"搬运"
一篇技术文章写完后,我通常要做下面这些事情:
- 删除不适合某个平台的开场白;
- 把标题改成更适合平台搜索的形式;
- 根据正文重新生成摘要;
- 检查代码块的语言标记;
- 处理图片和链接;
- 把 Markdown 转成目标平台支持的格式;
- 补充标签、话题和分类;
- 发布前重新通读一遍;
- 发布后确认文章不是空白或格式错乱。
这些事情单独看都不难,难的是它们重复出现,而且每次都容易漏掉其中一两步。
最初我用一个很长的 Prompt 让 AI 一次性处理全部内容。结果不太稳定:有时摘要写得不错,但把代码块改坏了;有时格式转换没问题,却把文章里原本的关键限制条件删掉了;还有一次,它生成了"适合发布"的版本,但没有明确告诉我哪些地方发生了变化。
后来我把任务改成了流水线,而不是一个大任务:
text
原始 Markdown
↓
结构检查
↓
内容拆分
↓
平台版本生成
↓
格式校验
↓
差异检查
↓
人工确认
↓
创建草稿/发布
这一步很关键。AI 负责处理重复工作,但每一步都有清晰的输入和输出,不让它在一个黑盒里自由发挥。
二、我先给 TRAE Work 定了三个角色
为了避免每次都重新解释任务,我没有只保存一条提示词,而是给这条流水线拆了三个角色。
角色一:编辑器
它只负责理解原稿,不负责改写事实。
编辑器需要输出:
- 文章标题;
- 文章摘要;
- 一级和二级标题;
- 代码块数量;
- 外部链接列表;
- 可能需要人工确认的内容。
它的边界很明确:只做结构化整理,不擅自补充技术结论。
角色二:平台适配器
它根据目标平台生成对应版本。
例如:
- 掘金版保留完整技术细节和 Markdown 代码块;
- 公众号版缩短开头,增加段落间距;
- 社区短文版只保留问题、方案和结果;
- 个人知识库版保留完整上下文和待验证事项。
平台适配器可以调整表达,但不能改变原稿的事实、代码逻辑和结论。如果确实需要删减,必须输出删减清单。
角色三:发布检查员
它不负责"把文章写得更漂亮",只负责找问题:
- 标题是否为空;
- 摘要是否与正文一致;
- 代码围栏是否成对;
- 链接是否缺少协议头;
- 是否出现连续空段落;
- 是否混入其他平台的标题或标签;
- 版本是否与原稿对应。
这三个角色分开之后,定位问题容易多了。以前看到结果不对,只知道"AI 没做好";现在能知道是结构提取、平台适配还是发布检查出了问题。
三、让它先生成"中间产物",不要直接生成最终稿
这条经验是我踩坑之后留下的。
如果直接让 TRAE Work 输出五个平台的最终文章,结果看起来很完整,但很难检查它到底改了什么。后来我要求它先生成一个中间产物,用结构化数据描述原稿:
json
{
"title": "原始标题",
"summary": "原始摘要",
"sections": [
{
"heading": "问题背景",
"purpose": "交代问题来源",
"content_range": "paragraph-1 to paragraph-3"
}
],
"code_blocks": 2,
"links": [
"https://docs.python.org/3/library/json.html"
],
"needs_review": [
"性能数据缺少测试环境说明"
]
}
这个中间产物有两个好处。
第一,后面的平台版本都基于同一份结构生成,不会出现每个平台各自理解一遍原文、最后内容越改越散的情况。
第二,人工审核有了明确入口。比如它标记"性能数据缺少测试环境说明",我就知道这里不能让 AI 自动润色过去,而要回到原稿补充信息。
四、平台适配时,我最看重的是"少改动"
很多人让 AI 做平台适配时,会要求它"重写得更吸引人"。这对营销文案可能有效,但对技术文章风险很高。
技术文章里,一个看似普通的词,可能决定结论是否成立。比如"默认开启"和"可以开启"、"支持"和"原生支持",含义并不一样。如果平台适配时为了顺口把这些词换掉,文章就可能变得不准确。
我的要求是:
先保留原文,再做平台必要的格式调整;除非明确要求,不重写技术结论。
具体来说,平台适配器只允许做四类修改:
- 调整标题和摘要的长度;
- 删除平台不支持的格式标记;
- 调整段落和代码块的展示形式;
- 根据平台要求补充标签,但不能凭空增加观点。
每次生成适配版时,还要输出一个简短的变更说明:
text
本次变更:
- 标题由 42 字缩短为 28 字
- 删除 1 个平台不支持的 HTML 标签
- 保留 2 个代码块
- 未修改技术结论
- 未删除外部链接
这份说明看起来很朴素,却比一段"已完成平台适配"有用得多。
五、格式检查比"写得漂亮"更重要
内容分发最容易翻车的地方,往往不是文章质量,而是格式。
我给发布检查员加了几条硬规则。
1. 代码块必须成对
python
open_fence = content.count("`" * 3)
if open_fence % 2 != 0:
raise ValueError("代码围栏数量不成对")
2. 链接必须是完整地址
相对路径、被截断的链接和复制时混入的标点,都要单独列出来,不允许静默修复。
3. 标题和摘要必须存在
有些平台允许正文为空白提交,有些平台会把摘要当作文章卡片内容。提交前必须检查标题、摘要和正文长度。
4. 版本必须带来源标识
我会给每个版本加上简单的元信息:原稿名称、生成时间、目标平台和内容版本号。这样后面发现问题时,可以知道是哪一版出了问题。
5. 发布前后都要回查
发布前检查的是"准备提交的内容",发布后检查的是"平台实际保存的内容"。两者不能互相替代。
尤其是外部平台的发布接口,偶尔会出现请求返回成功,但正文保存不完整的情况。没有回查,就很容易把一个空文章当成已发布。
六、我把"自动发布"改成了"自动准备,人工确认"
刚开始搭这条流水线时,我也想过让 TRAE Work 直接完成多平台发布。后来还是放弃了默认自动发布。
原因很现实:发布是外部动作,一旦标题、标签或正文版本错了,修复成本比少点一次确认高得多。
现在的流程是:
text
自动读取原稿
↓
自动生成平台版本
↓
自动做格式检查
↓
自动列出变更内容
↓
人工确认
↓
创建草稿
↓
回查草稿内容
↓
再次确认
↓
发布
如果只是生成本地版本,可以全自动;如果要创建草稿,我会让它停下来让我看标题、摘要、标签和正文长度;真正发布之前,再确认一次。
这不是不相信 AI,而是把自动化放在合适的位置:让它承担重复劳动,不让它替用户承担公开发布的最终责任。
七、这条流水线给我省下来的不只是时间
最直接的变化是时间。
以前从一篇文章到多个平台版本,通常要反复复制、粘贴、修改和检查。现在第一版生成大约需要几分钟,人工主要检查技术内容和平台差异。
但更重要的变化是,我终于知道每次发布前应该检查什么。
以前靠记忆:这家平台要摘要,那家平台要标签,某个平台不能放某种格式。现在这些规则变成了固定步骤,少依赖临场注意力。
对我来说,TRAE Work 最有价值的地方不是"帮我写了一篇文章",而是把文章写完之后那段容易疲惫、容易犯错、却不得不做的工作,整理成了一条可以重复执行的流程。
八、如果你也想搭,建议从一篇文章开始
不要一上来就做"全平台自动发布系统",很容易把问题做复杂。
可以先选一篇已经写完的文章,只做三件事:
- 让 TRAE Work 提取文章结构和链接;
- 生成一个目标平台版本;
- 输出格式检查结果和变更说明。
这三步跑通后,再逐渐加入其他平台、标签匹配、图片处理和草稿创建。
还有几个小建议:
- 原始稿和适配稿分开保存,不要覆盖原文;
- 每个版本带版本号,避免拿错文件;
- 发现事实不确定时,要求它标记,不要让它自行补全;
- 写入外部平台前先查重,避免重复创建;
- 发布后回查标题、正文和状态;
- 出错时保留现场,不要让脚本自动清理所有中间产物。
一篇文章发五个平台,难点从来不是"能不能复制过去",而是能不能在复制、改写和发布之间保留内容的一致性。
TRAE Work 帮我解决的,也不是把二十分钟变成零分钟,而是把原来混乱的一两个小时,变成了一条有输入、有输出、有检查点的二十分钟流程。
这才是我觉得它最适合普通人的地方:不是替你按下所有按钮,而是把那些容易忘、容易错、又不得不重复做的事情,变得清楚一点、稳定一点。
#TRAEWork #人工智能 #自动化 #内容创作 #掘金技术征文