Marco Liu1. 从一篇稿子到发布上线：技术博主被低估的时间黑洞
先还原一个我自己的真实场景。上个月我写了一篇关于 MySQL 8.0 安装配置的踩坑记录，本地 Typora 里改了三遍，截图裁了五张，自认为内容已经打磨到位了。结果从打开 CSDN 编辑器到真正点下"发布文章"，我花了将近四十分钟。不是文章本身有问题，而是整个发布流程里塞满了琐碎动作：重新粘贴 Markdown、调整渲染错乱的代码块、给图片一张张传图床、填标签、选分类、勾选"原文链接"和"声明原创"，最后再填一次摘要。这些操作没有任何技术含量，但每一秒都在消耗耐心。
我相信大多数技术博主都有类似经历。CSDN 作为国内技术人最常用的内容分发平台之一，其编辑器能力本身并不差，问题在于它与我们日常使用的本地写作工具链是完全割裂的。你写 Markdown 用 Typora、VS Code、Obsidian，管理代码工程用 Git，处理远程环境用 SSH，但到了发布这一步，一切都要退回手工操作。这种割裂感对一个习惯自动化的人来说，非常难受。
我当时的第一个念头是去找现成的发布工具。结果搜了一圈，CSDN 官方提供的同步助手只支持从特定平台导入，不支持通用 Markdown 流程；第三方方案要么年久失修，要么需要在浏览器里装插件，依然绕不开人工确认。于是我开始考虑自己动手，做一个真正"智能"的发布助手——不是简单的格式转换工具，而是一个能理解文章内容、能做出发布决策、能自动处理格式与元信息的 AI 智能体。
这篇文章会完整复盘这个项目的设计与实现过程。内容包括整体架构选择、智能体提示词设计、浏览器自动化发布管线的搭建、登录态与风控问题的处理思路，以及一套可用于验收智能体效果的数据集设计方法。如果你也在用 AI 构建自己的写作或发布工作流，或者你想了解一个真实的智能体项目如何从零落地，这篇文章应该能给你一些参考。我默认你有基本的 Python 基础，知道什么是 API、什么是浏览器开发者工具，但不需要你预先掌握任何智能体框架。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 发布流程的断点拆解：到底哪些环节值得交给智能体
动手写代码之前，我先把"发布一篇文章"这件事拆成了最小的动作序列，然后再逐个判断：这个动作适合用规则脚本解决，适合用大模型判断，还是根本应该保留人工操作。这一步非常关键，因为它决定了整个系统的复杂度和可靠性。
2.1 从本地文件到线上页面，中间隔着七道工序
拆下来大概是这样的链路：读取本地 Markdown 文件，解析标题与正文结构，处理图片资源（要么转图床、要么以 Base64 嵌入），转换或校正格式以匹配 CSDN 的 Markdown 方言，生成标签与分类建议，填写摘要，最后在编辑器中完成内容写入并点击发布。这还不算登录态维护、验证码应对、草稿保存等基建性问题。
其中"格式校正"是我最早想自动化、也是最初低估了难度的环节。CSDN 的 Markdown 渲染基于一套自定义规范，和 GitHub Flavored Markdown 有不少细微差异。举几个实际例子：CSDN 的代码块语言标识支持 python、bash 这类常见值，但个别冷门语言标识会渲染失败，直接变成纯文本；CSDN 对 Markdown 表格的列宽支持有问题，过宽的表格在移动端会被截断；还有 CSDN 编辑器对 LaTeX 公式的解析需要特定的 $$ 包裹方式，与 Typora 的自动识别行为不完全一致。这些差异如果靠人工一遍遍粘贴、预览、修正，效率极低，但完全靠规则脚本处理又不够灵活，因为不同文章的格式问题千差万别。
2.2 "规则脚本不够用，纯人工又太蠢"：智能体介入的边界
这里就体现出大模型的价值了。格式校正本质上是一个"按目标平台的方言规范改写文本"的任务，它没有唯一标准答案，需要根据上下文判断，这正是大语言模型擅长的事情。但要让大模型在这条流水线上干活，不能只是简单地把文章丢给它然后说"帮我修正格式"，而是必须把任务拆细，让它每一步都清楚自己在做什么、需要输出什么格式的结果。
我当时把整条流水线分成了三类动作。第一类是确定性动作，比如读取文件、上传图片、在编辑器里填入内容，这类动作用 Python 代码就能完成，不需要任何智能判断。第二类是判断性动作，比如给文章匹配标签、决定是否勾选"声明原创"、判断摘要是否吸引了读者，这类动作需要一定的语义理解能力，交给大模型来处理最合适。第三类是兜底性动作，比如验证码弹窗、账号异常提醒、编辑器出现未预期的弹窗，这类动作一旦出现，我不希望脚本自作主张去处理，而是应该立即暂停并通知我人工介入。
2.3 技术选型的横向对比：浏览器自动化并非唯一解
确定了大方向之后，我在技术方案上做了一次对比。摆在面前的主要有三条路。第一条是爬虫方案，直接模拟 HTTP 请求调用 CSDN 内部的接口完成发布，这是最"轻"的做法，速度快、不依赖浏览器环境，但缺点也明显：CSDN 的接口参数复杂且经常变动，一旦变更，整个方案的维护成本就很高，而且模拟请求的方式很容易触发平台的风控机制。第二条是官方 API 方案，如果平台提供正规的内容发布接口，那是首选，但 CSDN 的开放平台主要面向企业级应用，个人博客发布的相关接口一直没有稳定对外开放，这条路在当时走不通。第三条是浏览器自动化方案，用 Playwright 或 Selenium 驱动一个真实的浏览器，像人一样操作编辑器页面完成发布。这套方案最接近人工操作，风控特征最自然，而且不依赖内部接口，页面改版时只需要调整少量选择器。
我最终选择了 Playwright 驱动的浏览器自动化方案，理由有三点。第一，它复用了 CSDN 官方编辑器的全部能力，包括 Markdown 渲染、图片上传、标签选择、封面设置，不需要我自己维护一套格式转换逻辑。第二，浏览器的动作轨迹更接近真人操作，配合适当的延时策略，触发风控的概率远低于模拟 HTTP 请求。第三，Playwright 对登录态的管理比较友好，可以保存上下文存储状态，避免每次运行都重新扫码登录。至于这套方案的缺点，后面会单独聊，主要是环境依赖重、运行速度较慢，以及遇到复杂验证码时必须降级为人工处理。
3. 智能体的"大脑"设计：提示词、工具调用与内容决策链
如果说浏览器自动化管线是整个项目的手脚，那智能体的规划与决策能力就是它的大脑。这一章我想重点聊聊我是怎么设计大脑的，包括提示词的结构、工具调用的方式，以及"什么情况下该让模型做决定"的判断逻辑。
3.1 提示词的核心不是告诉模型"做什么"，而是"按什么标准做"
一开始我踩过一个典型的新手误区：把提示词写成了操作说明书，比如"请你读取这个文件，然后修改格式，最后输出结果"。这种写法非常笼统，模型不知道你的质量标准是什么，输出的结果自然不稳定。我后来的做法是把提示词拆成三层。
第一层是角色与目标的设定，告诉模型它现在是一个"CSDN 技术博客的资深编辑"，目标是把一篇本地草稿变成一篇符合平台规范、对读者友好的发布稿。第二层是流程与约束，明确要求模型按顺序执行几个子任务，每个子任务的输出都有明确的格式要求。第三层也是最重要的，是标准与样例，我会在提示词里直接列出三五条 CSDN 平台特有的格式规范，比如代码块的语言标识要使用平台支持的范围、表格宽度不得超过多少、嵌套列表的缩进规则，再附上几个"修改前 vs 修改后"的示例。
这里有个很关键的经验：大模型对"标准"的遵循程度，与标准呈现的"具体程度"成正比。如果你只说"请修正格式"，它只会做最浅层的修正；如果你说"检查代码块的语言标识是否属于 YAML、JSON、Python、Bash 等平台支持的值，不支持的请自动移除或替换为 text"，它的修正就会精准得多。标准的颗粒度，决定了智能体的专业度。
我用的是类似 Coze 或 Dify 这类智能体编排平台来承载这些提示词逻辑，再把中间的处理步骤包装成一个自定义工具供智能体调用。这么做的好处是，后续想调整个别环节