【第三讲】如何用AI写出有活人感的公众号文章?三个Skill就够了

用 AI 来写一篇文章，如今已经不是什么难事。真正让人犹豫的，往往是最后那一步：写出来的东西AI 味太重了，读几行就知道是 AI 写的，经常出现看不懂的词语和表达方式。

这一讲，我们把 FDE X 内部培训里的 Case One 从头拆了一遍。我们没有一上来就去造一个全自动的 Agent，而是先找到 AI 最容易做稳的那一小段，把它跑顺，再接上下一段。就这样一段一段往下跑，最后留下三个可以单独运行的 Skill，和一个把它们串起来的公众号文章 Agent。

有一条界线，我们从第一天就轻轻划下了：找材料、查格式、把稿子送进草稿箱，交给系统；但决定要不要发，还是交给人。

这个任务的终点是草稿箱里那一份等人过目的草稿。

SECTION / 01

先把任务的终点说清楚

动手之前，我们先把一件事说定：AI走到哪一步，才算做完。

很多时候输入给AI的材料很杂。有时是一个 Topic 和一句写作方向，有时是几条 AnyJob AI 的结果页链接——关键人雷达、图谱雷达；也有时候，是编辑随手补上的几句背景，和一个疑问：这块，你再往下看看。

相比之下，出口则要清晰得多，因为它要经得起验收。文章里的信息要查得到出处，中心问题要立得住，自己的判断也要敢于写下来。封面和正文图片要整齐，排版要合得上统一的标准，稿子建好之后还要回读一遍。只递来一段文字，或者只生成一个 HTML 文件，都不算走到终点——因为下一步的人没法接着做。

我们对“好”的说法也很朴素：接近专业商业媒体的阅读完成度。标题要把问题说出来，开头不必绕，正文里有人、有事、有关系，结尾留一个站得住的判断。内部沟通的时候，我们常拿晚点 LatePost当参照（一家做商业深度报道的媒体，业内公认质量标杆）：说的其实是信息密度、问题意识和编辑的完成度，而不是去模仿它的句子。

把标准写成一条条可以验收的东西，比说一句“文笔再好一点”要有用得多。前者能改，后者只能各自揣测。

于是这项工作被拆成三段。调研 Skill 去找人、找关系、找证据；写作 Skill 把材料组织成 HTML 文章；发布 Skill 负责图片、排版、账号配置、草稿创建和回读。

Case One 被拆成三个可单独测试的 Skills。每一段都有自己的输入、输出和验收，人最后在公众号草稿箱内审核。

SECTION / 02

首先，找到 AI 最容易做稳的那一步：写作

动手之前，我们先问了一个问题：这条链路里，哪一段 AI 最容易做稳。

答案是写作。它擅长把散落的资料理顺，写成结构清楚的文章，也能直接给出带图片和样式的 HTML。

于是第一版 Skill 做得非常克制，它只负责写作。输入是 Topic、AnyJob AI 的结果链接、我们已经想清楚的方向，以及几处待补的问题；输出只有一个排好版的 HTML。范围收窄之后，好处是出了问题知道去哪里找：资料漏了，去看输入；结构散了，去改写作流程；样式乱了，去改模板。

第一版很快就跑通了。跑通之后，新的问题随即浮上来：读起来有一股模型腔。它会反复解释同一个判断，习惯用抽象的词给普通的动作加码，也总爱在每一节的末尾补一个总结。

后来我们才想明白，模型腔多半不是文笔的问题，而是结构的问题——它在替一段没有想清楚的文字补情绪。所以修它的办法不是换词，而是回到证据和中心问题上去。

这一点不值得从零写一套规则。我们去 GitHub 这些开源社区走了一圈，看成熟的中文写作 Skill 是怎么写的：许可、结构、示例、适用范围，一一读过。星标可以帮我们初筛，但最后用不用，还是看试写和返工的结果。

SECTION / 03

除了去掉模型腔, 我们还需要定义编辑标准

一套通用的自然写作 Skill，能把套话删干净，却管不了编辑上的事。标题可能太平淡，开头可能迟迟不进入正题，材料已经不少，中心问题依然没有立起来。

我们便拿专业商业媒体的文章当尺子，一篇一篇地对。对的只有五件事：标题提出了什么问题，开头用的是哪个事实，人物为什么恰好在这一刻出现，证据怎样把下一段推出来，作者的判断落在了哪一句。

每对完一篇，我们只挑那些可以重复使用的规则放进主 Skill里。某篇文章的句式不会被留下，因为换一个题目就用不上了。能跨题目使用的编辑判断才会被记住：标题要接住全文最有价值的事实，开头前几段要让读者知道这篇文章准备回答什么，连续两段说的是同一个结论，就该合在一起。

我们自己的习惯也一点点加了进去。FDE X 的文章偏口语，段落要短，当术语第一次出现时要用一句人话解释清楚，案例和动作放在观点前面。分工上，通用的去模型腔 Skill 作为一个子 Skill，公众号文章 Skill 负责整篇的结构、事实、视觉与交付。

写作 Skill 的迭代路径。先完成文章，再做自然中文终审，随后用专业媒体的编辑标准检查标题、开头、证据和判断，最后把有效规则与样例写回下一版。

SECTION / 04

Skill不知道什么叫"写得好"，得拿样例给它看

如果只把要求写进 SKILL.md，模型每一次仍然要重新揣摩。

于是我们开始给它看东西——那些已经通过的 HTML、封面、流程图、图注和页尾。Example 在这里扮演的，是参照物的角色。

封面最明显。任它每一次自由发挥，颜色、字体、构图、信息层级都会飘，一眼就看得出不是同一个号发出来的。后来我们先把认可的版本挑出来，把尺寸、Logo 位置、标题区域、字体层级、留白和底部关键词都定下来。下一篇只需要替换期号、标题、副标题和一小块图形。

排版也是同样的道理。正文的字号、行高、字间距、段距、图片宽度、图注，都有固定值；流程图沿用同一套黑白网格与细线。一个通过的 HTML 会进 examples，一个失败的版本我们也留着——用来提醒后来的模型，哪些版式一旦放到手机上，就会变成一张报表。

Example 从来不是装饰，它把团队口中那几句“好看”“像我们”“可以交付”，变成了下一次运行可以照着做的、具体的对象。

“再好看一点”无法执行，团队需要能逐页对照的样例。

SECTION / 05

HTML一进公众号就乱？这正是"发布Skill"要解决的

事情到这里还没有结束。浏览器里看着一切正常，一放进公众号编辑器，就开始不一样了。

外部 CSS 会被过滤掉，本地图片路径会失效，稍微复杂一点的布局会散开，字体、缩进和段距也会被重新处理一遍。

我们接着读了一些开源方案，最后引入了 md2wechat。它做的是这样几件事：把内容转成公众号兼容的 HTML，上传正文图片和封面，生成草稿 payload，再调用接口把草稿建出来。它的公开仓库把资源打包、草稿推送和回检，串成了一条完整的流程。

这一段需要原生配置。AppID、AppSecret、IP 白名单、接口权限，缺一样，草稿就建不出来。密钥只能放在本机的私密配置或环境变量里，不能进可分享的 Skill。账号配置、样式标准和执行代码，我们也是分开保存的。

发布 Skill 的完成条件，比“接口返回成功”要严得多。正文图片要全部换成微信托管地址，封面要用永久素材 ID，提交的 HTML 要和校验过的文件完全一致。草稿建好之后还要回读一遍，核对文字、图片数量、标题、图注和固定页尾。

接口返回成功，只说明请求发出去了；回读能对上，才说明这一版稿子真的进了草稿箱。

从浏览器 HTML 到公众号草稿的交付链。正文冻结后再上传图片，生成微信安全 HTML 与 payload，创建草稿并回读，最后交给人审核。

SECTION / 06

写作和发布一串起来，问题马上就暴露了

写作 Skill 和发布 Skill 第一次串起来，最先出问题的是封面。文章进了草稿箱，封面却像从别人家账号里搬过来的。

之后还有一连串细碎的事。本地预览好好的，回读版的段距变了；某张图片被重复上传；标题超出了接口长度。

解决的办法很朴素，却有效。每一次返工，我们都把原因记下来：能用规则说清的，写进 Skill；能用程序确定性检查的，写进 scripts；视觉上的问题，用通过和失败的 examples 约束住。每改一处，都把文章、移动端预览、草稿创建和回读重新跑一遍。

版本号也是从这里开始有意义的。1.0 只会生成 HTML，1.2 加入了自然中文终审，1.3 把封面固定下来，到 2.0 才真正跑通图片上传、草稿创建和回读。版本号的后面，要跟着修改原因、旧案例的回归结果，以及已知的限制。

把 Skill 交给另一位同事之后，还要再测一次。他使用的模型可能不同，Harness 也可能不同。输入缺失时它会不会停下来，账号没有配好时它会不会明确报错，封面是否仍然守着样例，文章是否还保得住判断力——这些都是交付质量的一部分。

在自己的电脑上跑通，只说明首跑成功。换一个人、换一台机器仍然稳定，才勉强称得上企业级交付。

SECTION / 07

最难的一步，我们放到了最后：调研

前两段把写作和发布解决了，文章的调研深度却还没有保证。

我们希望 Agent 能用上 AnyJob AI 的关键人雷达、图谱雷达、组织架构分析和人物关系网，把一条新闻背后的团队、决策链与关系找出来。

第一步，是先教它如何使用网站。最有效的材料并不是文档，而是一组按顺序截下来的屏幕图：每一张图里标出用了哪个功能，为什么在这里点进去，输入了什么，结果出来之后又该如何判断下一步。

截图能把许多说不出口的操作讲清楚。浏览器从哪里打开，登录状态怎样确认，哪个按钮会消耗额度，任务卡住时该看哪里，结果页里哪一块还能继续往下挖人物关系。Skill 里也要写清权限与安全的边界：已经授权的普通操作不必反复打断，而登录、敏感设置与对外动作，仍然需要明确确认。

等 Agent 能够稳稳走完整个网站流程，我们就得到了一个网站使用 Skill。它解决的是“会不会用工具”，但还没有回答“调研是否足够”。

浏览器操作 Skill 要在真实环境里反复试跑，验收的是每一步是否稳定。

SECTION / 08

只会搜索人，离完成调研还很远

举个例子。假设今天要写 SpaceX 上市，你搜“SpaceX 上市相关人”，会得到几个熟悉的高管名字。名单没有错，可文章仍然缺东西——缺决策链，缺资本角色，缺真正在执行的人，也缺能够把这件事解释清楚的人。

所以调研 Skill 要先把题目翻译成几组问题。发生了什么，谁在推动，谁负责执行，组织怎样配合，外面还有谁能补充解释，哪些关系会改变我们对这件事的判断。

然后再挑选工具。事件类的题目，可以先跑事件图谱，再补上关键人搜索和一位核心人物的关系网；公司类的题目，从组织架构入手更合适，再看关键岗位和外部圈层；需要的时候，继续查人物背后的人，直到主要问题都能找到证据。

我们标准的一次运行，通常会排四到六个互不重复的调研任务，最后形成五到十个可以进入文章的人物候选。这些数字只是一道门槛，防止我们过早收工——如果新增的任务总是同一批名字，或者没有给文章添上新的东西，那就该停下来，整理已有的证据。

人物类、事件类、团队类的任务，各有各的 examples。调研目标也要写清楚：我们要的是一篇有洞察的文章，同时让读者看见 AnyJob AI 是怎样找到关键人和关系路径的。图谱给出的是线索，真正写进文章的事实，还要回到公司公告、论文、监管文件和可靠报道上去核一遍。

AnyJob AI 调研 Skill 的形成顺序。先用截图和真实操作学会网站，再按题目规划调研，核验证据，最后把人物、关系和来源交给写作 Skill。

SECTION / 09

三个 Skills 怎样组成一个公众号文章 Agent

走到这一步，三段能力就可以串起来了。第一个 Skill 用 AnyJob AI 完成调研，把人、关系、结果链接和公开来源保存下来；第二个 Skill 读这些材料，写出文章，完成自然中文终审，统一视觉；第三个 Skill 上传图片，生成微信安全 HTML，把文章送进草稿箱，再回读一遍。

每一段都保留着自己的输入、输出、日志和验收。调研不够，就退回调研 Skill，不在写作阶段勉强往名单里加人；文章没有洞察，就退回结构和证据，不靠排版把问题盖住；草稿样式出错，就退回发布 Skill，也不必重写正文。

Agent 要做的，是判断现在该用哪一个 Skill，发现哪一段没有通过，然后把任务退回到对应的位置。这样做还有一个好处：当某个子 Skill 升级时，另外两段不必跟着重写。

大 Skill 的价值来自组合，小 Skill 的价值来自它可以被单独检查、替换和升级。

公众号文章 Agent 的验收回路。任何一段未通过都回到对应 Skill 修复，正文冻结以后才进入上传，草稿回读通过以后再交给人。

SECTION / 10

这个案例留下了什么

回头看，我们做的事大致可以归成三步。

第一步，是先找到 AI 最容易稳定完成的那一小段工作。先把它跑通，再让真实的问题自己浮出来。不要一上来就在文档里构想一套完美的流程——那套流程写在纸上，永远是对的。

第二步，是把返工变成资产。通用的规则进主流程，业务知识进 references，确定性的动作进 scripts，通过和失败的成品进 examples，版本与回归结果进 release 记录。每一次走过的弯路，都该留下一点东西，而不是被下一次弯路盖过去。

第三步，是把人放在需要判断、也需要负责的位置上。编辑判断文章有没有洞察，账号负责人决定发还是不发，安全配置由有权限的人来维护。AI 可以把整条路走得更短、更快、更稳，而责任这件事，仍然有清楚的归属。

从 Topic 到草稿箱，听起来只是在写一篇文章。真的拆开看，里面装着调研、写作、设计、接口、权限、测试、版本，以及人工审核。企业级 Skill 的完成度，就藏在这些平日里最容易被跳过的小地方。

资料与出处

[1] Agent Skills 官方概览与规范。Skill 由 SKILL.md 和按需加入的 scripts、references、assets 等资源组成，强调可复用、可审计与按需加载。

[2] md2wechat 开源仓库。仓库公开说明了 Markdown 或 HTML 转换、资源打包、草稿箱推送与回检流程，采用 MIT License。

[3] FDE X Skill-Driven FDE 内部培训资料。本文的 Case One、三段 Skill 拆分、开源 Skill 修改和人工确认边界据此展开。

[4] 本文中 AnyJob AI 的使用流程、调研目标、写作标准和版本迭代来自 FDE X 的实际工作方法与本次口述材料。

[5] sarah b 与 Compagnons 的团队协作照片来自 Unsplash。