publish-article

发布文章

写文章只是简单的一半。这项技能涵盖另一半，它决定了发布页面能否带来流量、引用或链接价值：标题如何选定、署名归属、配图、外链，以及你预期的内容是否确实正确呈现。

下面的每条规则都有发布前可执行的检查。没有检查的规则就会被跳过，所以请执行这些检查。

模式

• 内容模式（默认） — 发布原创文章。不涉及反向链接。
• 反向链接模式 — 同上，另外为目标页面添加一个预先规划好的关键词链接。
• 提供文案模式 — 用户提供完成稿供你发布。请参阅下文“提供的文案不可更改”；此规则优先于写作指导，但不影响验证。

第 1 道关卡 — 写作前衡量标题关键词

这是最能决定页面是否值得发布的决策，却往往是在起草时凭直觉做出的。写下第一个字之前，先列出此表：

候选核心短语	月搜索量	难度	是否属于目标主题的相关领域？

搜索量要实际衡量，不能凭空假设。 从文章自身发现中创造的短语（“1.3% 旁白差距”“交付问题”）天生搜索量为零——没人会搜索一个自己从未见过的新造词。聪明但无依据的标题是这里最常见的失败模式，而非偶尔失手。

胜出的短语必须属于你实际竞争的主题领域。 这是更隐蔽的问题，而且即使搜索量检查完全通过也仍会存在。假设你要链接到一个幻灯片产品，那么 ai training video generator（每月 250 次）在搜索量上胜过 ai training slides（每月 0 次），但它仍是错误选择：它会让文章针对视频需求获得排名，而目标产品卖的是幻灯片，在这个选择看似最优化的关键时刻削弱主题信号。应从正确的领域中选择支持度最高的短语，而不是选择邻近领域里数字更大的短语。

关键词工具会严重低估 AI 和长尾关键词的搜索量——不要把 0 理解为“没有需求”。 工具可能会将某个短语报告为 0，但你自己的 Search Console 显示该短语在排名第 1 时带来了点击。如果搜索控制台数据与关键词工具不一致，以搜索控制台为准；工具的作用只是帮你比较候选词的排名。

对于保留旧 slug 重定向的 CMS，发布后修正这件事成本很低——应及时修改，而不是将错就错。URL 一经收录或引用，修正窗口就会关闭。

第 2 道关卡 — 规划锚文本和主题（反向链接模式，写作前）

反向链接的价值取决于锚文本，也取决于文章内容是否与目标页面主题相同。两者都要提前决定并明确写出，绝不能在起草时临时发挥：

网站	文章角度	锚文本	锚文本类型

先查看指向目标页面的现有锚文本。 新锚文本要根据现有分布来选择，不能孤立地看。

• 每个锚文本都要包含目标关键词或明显的变体。 品牌词或泛化锚文本（here、this tool、单独的品牌名）几乎无法为你正在争取的关键词传递价值。只有在关键词锚文本到位后，才使用一个这样的锚文本。
• 变换表面形式——精确匹配、复数形式、品牌词＋精确匹配、部分匹配。在所有位置重复同一个锚文本，是付费链接最明显的特征。
• 文章主题必须与目标页面主题一致。 从一篇电动自行车文章链接到教育视频页面，无论锚文本多好，价值都近乎为零。
• 每篇文章只链接到目标页面一次。 第二个链接不会增加价值，反而显得刻意。
• 对锚文本同样应用第 1 道关卡的两条规则。AI training presentation maker 看起来像关键词，但没人会这么搜索；AI training presentation 才是有实际搜索需求的短语。

原创研究（仅限原创内容）

新闻稿、公司博客文章或通讯社报道只是线索，不是文章。补充读者无法通过打开原始来源获得的信息：

• 阅读原始来源，以及至少两个提供不同事实的独立一手来源。转载和通讯社稿件的联合发布版本只算一个来源。
• 至少提出一项原创发现，方法可以是计算、比较、排序或追踪随时间发生的变化。在结果旁注明分母、时间段和方法，以便他人复现。
• 对于包含数据的报道，加入一个表格和一张图表：表格展示精确数值，图表揭示规律。可比较类别使用条形图，只有真实时间序列才使用折线图。不要把两个数据点硬凑成装饰性图表，也不要为满足这一规则而编造数字。如果某个主题确实没有可比较的数据，就提供结构化对比表，并说明图表为何会造成误导。
• 图表是补充性编辑素材，应嵌入正文，并配有描述性替代文本和可见的来源／方法说明；绝不能用作封面图片。

发布前，请列出：使用的来源、原创发现、表格行数、图表类型、字数。如果草稿主要是对公告的改写，应继续研究，而不是发布。

默认情况下，用户提供的文案不可更改

当用户提供文章、草稿、标题或段落并要求发布时，这些文字是已获批准的文案，而不是写作简报。未经明确许可，绝不要改写。

• 保留用户提供的标题、论点、切入角度、示例、结论、语气、顺序和确定程度。不要用更稳妥或更常见的论点替换用户的论述。
• 编辑指令仅授权所要求的修改方向。“写得更肯定一些”意味着强化已有论点，并不意味着可以改变论点。
• 仍须核实事实。如果核实发现的问题一旦更正就会实质性改变用户提供的说法，应明确指出具体问题和拟议修改，并在发布前征得许可。绝不要悄悄换成另一种说法。
• 未获改写许可时，只能进行不改变原文措辞的发布形式调整：Markdown 格式、转义、平台语法、放置所要求的图片。
• 发布前，将最终文案与用户提供的文案进行差异比对。每项实质性修改都必须对应当前请求中的明确指令。若没有对应指令，就停止并询问。

质量标准——每篇已发布文章都必须满足

1. 标题

• 最多约 60 个字符，以适配 SERP <title>。不要使用带破折号副标题的多分句标题；精简到一个核心卖点。
• 标题中要包含用户搜索的实体——专有名词胜过巧妙措辞。 人们会搜索姓名、产品和公司，而非概念。Demis Hassabis steps down, Jeff Dean leaves Google 优于 Who runs Google AI now?，因为前者包含两个姓名和公司名，都是可直接搜索的词。
• 判断标准是“有人会输入这个词搜索吗”，而不是“标题里有没有专有名词”。 用错专有名词和没有专有名词一样无效。先写出读者实际会搜索的 2-3 个词组，再检查标题是否包含这些词。实践中有两种常见错误：
  • 标题写了来源，而不是主题。 The Information Drew Dario Amodei as a Prophet 虽有两个专有名词，却错过了搜索词 Anthropic IPO。报道来源应写在署名栏里，绝不要放进标题。
  • 把字符预算花在语气上。 一个俏皮的收尾若占用了 statue、cast、review、price 或 specs 这些词的位置，就会失去搜索量最高的词。删掉俏皮话，保留名词。
• 只能有一个 H1。标题就是页面的 H1，因此正文不得以自己的 # 标题开头，也不得重复标题（正文标题应降为 H2 或更低级别）。

2. 作者

必须署名真实作者，不能使用 CMS 默认作者、“Staff”或空值回退。作者记录须包含姓名和简介，最好还有头像。如有需要，请创建作者记录，而不是使用回退值。切勿捏造资历或专业知识。

3. 图片

• 来源顺序：优先使用公有领域照片，其次才是 AI 生成图片。 生成图片前，先在 Wikimedia Commons 搜索实际主题；只有文件许可为 Public domain 或 CC0 时才可使用——绝不使用 CC BY、CC BY-SA 或任何附带他人条款的许可，即便署名在技术上已满足其要求。使用 Commons API（list=search&srnamespace=6，随后使用 prop=imageinfo&iiprop=extmetadata，并通过 LicenseShortName 筛选），同时提供真实的 User-Agent，否则会收到 403 错误。在文章末尾用斜体行注明公有领域封面图片的来源。
• 主题是某个真实、具体的物体或地点时，优先使用真实照片。 对真实存在的事物进行 AI 渲染会凭空捏造其外观，相当于用图片包装虚构内容。如果找不到主题的免费照片，使用公有领域的场景照片也好过凭空生成主题照片。
• 采用横向构图，且不要在图片中嵌入文字——OG 图片尺寸约为 1200x630。标题应放在页面上，而不是图片中。如果比例不合适，请裁剪或重新生成。
• 追求真实感，而非“AI 感”。 采用编辑类摄影风格；避免过度渲染的光鲜美感和杂糅隐喻（一个物体变成另一个物体）。纯科学主题才使用概念性图片；商业、政策和产品类文章应采用真实场景。
• OG 图片 URL 必须可访问——curl -I 返回 200，使用绝对 https:// URL，而非占位符。
• 每篇文章的图片都必须不同。 批量处理时，断言 distinct(images) == count(articles)。省略该字段并由平台生成图片，也好过使用重复图片。

4. 外部来源链接——正文中至少两个

• 在文字中提及来源不算。请添加链接。 读者核查论点时必须能一键访问来源；未添加链接的来源不计数。
• 若存在主要文件，请链接该文件（申报文件、数据集、发布公告、案卷、法院命令）；否则链接报道该事件的新闻稿件。使用描述性锚文本，绝不使用“这里”。
• 发布前断言：grep -c '](http' <body> 的结果必须 ≥ 2。在一次对十篇新发布文章的审查中，有六篇在文字中提到了来源，却一个链接都没添加——爬虫正确地报告了零个外部链接。

5. 篇幅——发布前按词数衡量

• 服务类或解释类文章至少约 1,000 词，并检查目标查询的实时 SERP：如果排名靠前的结果有 1,500 词以上，篇幅也要与之匹配。500 词的页面无法在 1,500 词页面的竞争中胜出，无论写得多好。
• 断言 len(body.split())，而非 len(body)。 字符数无法确保达到词数门槛。
• 篇幅必须来自实质内容——回答真实问题的章节、具体细节、数字、专有名词和失败模式。凑字数比篇幅短更糟糕。
• 输出每篇文章的词数，让篇幅不足的文章显而易见，而不是被平均值掩盖。

嵌入 X 帖子

如果报道的来源或配图是 X 帖子，请嵌入该帖子，而不是复制图片：图片依据作者的平台许可提供，署名信息已内置，也不会产生版权风险。

嵌入前必须同时满足以下四项：

1. 帖子是公开的。
2. 发帖者是实际权利持有人——绝不要嵌入他人转发的图片。这是唯一会导致出版商被起诉的情况。
3. 使用官方嵌入标记——绝不要使用截图或下载的副本。
4. 该帖子是报道的来源或主题，而不是装饰。

<blockquote class="twitter-tweet" data-dnt="true"><p lang="en" dir="ltr">FULL TWEET TEXT
HERE</p>&mdash; Author Name (@handle) <a
href="https://twitter.com/handle/status/TWEET_ID">Month D, YYYY</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

• 务必包含真实的推文文本——如果帖子被删除，备用内容应是带链接的可读引文，而不是空框。
• 深色背景的网站要添加 data-theme="dark"。 默认嵌入会显示白色卡片，在深色页面上格外刺眼。
• 将其放在讨论该帖子的段落之后。绝不能用作封面图／OG 图。

也要阅读回复，并将其中的观点用作评论。 从回复中发掘解读——关于帖子含义的推测、持怀疑态度的另一种解读、领域专家补充的背景信息——而不是互动数。选取两到三条，融入评论部分，注明观点来自回复者，在措辞鲜明处引用短语，并结合帖子本身的说法权衡这些观点。玩笑式回复只能用作一次点缀，绝不能作为分析。如果回复里只有玩笑，就用一句话说明——这种空缺本身就是一项发现。

写出值得引用的内容

能够获得的引用，是唯一会不断累积的反向链接。这一结论来自对十几家出版物进行的全网反向链接审计：每一条自然获得的链接，都指向一个最便于查证某一条具体事实的页面。首页和综述文章都没有获得链接。

1. 某个概念刚有名称时，就在当周写好解读文章，赶在权威页面出现之前。当天新闻带不来引用；定义性页面则能持续数月获得引用。
2. 标题＝人们实际会输入的原样问题。 该审计中引荐流量最高的页面是 what-does-yann-lecuns-world-model-mean-explained——标题里的名称就发挥了大半作用。没有专有名词的问题，不会是任何人实际输入的查询。
3. 每篇文章给出一个原创数字，只陈述一次，并写成便于摘引的句子。 不要分散在整段文字中。寻找可引用统计数据的作者需要能一眼摘取单个分句。
4. 每篇文章给出一个值得引用的判断。 用一句话给出类别结论，让记者可以连同出处完整引用。一个 DR 82 的媒体引用了“据评测，这是机器人泳池撇渣器品类的一次进化”——一句话同时提供了他们的定位和出处。
5. 在能持续积累价值的地方发布。 发布具体且有量化内容的站点能获得引用；发布泛泛的地区性填充内容的站点则一无所获。所有发布平台都应达到同一标准。
6. 绝不更改 URL 而不做重定向。 路径变更而没有重定向，会悄无声息地毁掉所有已获得的链接。一次 /posts/ → /articles/ 迁移导致五条 DR 49 的 dofollow 引用指向 404，直到添加重定向才恢复。修改 slug 时，必须在同一次变更中发布重定向。
7. 耐心是结构性的。 一篇 5 月发布的文章，在 10 周后于 7 月未经推动便被转载。页面依靠持续被收录、可查找来获得引用，因此 URL 稳定性和索引健康度胜过任何发布日推广。

发布机制（无论使用哪种 CMS）

请查阅目标平台自己的 API 文档或仓库规范，不要想当然。以下两种失败情况几乎普遍存在，值得明确检查：

• 创建请求可能会忽略状态字段，导致内容仍为草稿。 请通过回读确认，不要只相信 201 响应——草稿在正式网站上会显示为 404；在使用 ISR 的网站上，这个 404 随后会在页面的重新验证时间窗口内缓存，即使你之后发布了内容也一样。
• “允许缺少元数据”的变通方案不符合上述标准。 它通常会回退到默认作者和自动生成的封面图片。对重要的发布位置，绝不要使用这种方案。

对于基于代码的目标，请阅读仓库说明，按照现有模式做最小改动，并通过该仓库自身的工作流发布。不要仅仅为了一个页面就添加内容系统。

验证——检查已发布页面，而非载荷

1. 已发布 URL 返回 200。
2. 获取渲染后的 HTML 并确认：标题就是页面的 H1，且没有在正文中重复；显示的是真实作者署名；封面图片文件名确实存在。封面缺失时，页面仍可能返回 200，但图片会悄然消失。
3. 将渲染后的标题重新对照 Gate 1 检查。 这一步本质上是机械检查——是否成功渲染、是否只有一个 H1——很容易放过一个毫无排名潜力的标题。请说明它针对哪些搜索词。任何会将旧 slug 重定向到新 slug 的 CMS，都可以免费修正标题。
4. 在反向链接模式下，确认目标 URL 和锚文本均存在，并且链接是 dofollow。 检查渲染后的 rel，绝不要检查 Markdown。 许多 CMS 和网站模板默认会给外链添加 rel="nofollow"；如果发布的链接是 nofollow，就无法传递排名价值，而这正是交付的全部目的，且发布流程中没有任何提示。 来源引用仍应使用 nofollow——只有指定目标链接可以例外。
5. 使用 ISR 缓存的页面不会立即更新。 编辑后马上检查 rel，读到的仍是旧内容，看起来就像修改失败了。请触发重新验证或等待缓存窗口结束，然后再次检查。
6. 任何影响布局的改动都要用无头浏览器截图。确认所有表格和图表在桌面端和移动端宽度下都清晰可读，标签易于辨认，且没有水平溢出。
7. 报告：目标 URL、作者、封面、锚文本 + 目标（反向链接模式）、发布方式，以及资源 ID 或提交记录。

只有标题、作者和图片在渲染后的页面上均符合标准时，才能宣布完成。

API 要求

没有强制要求。根据目标平台和各项检查的需要，可以选择以下 API：

用途	常见来源
关键词搜索量和难度（Gate 1）	Ahrefs、Semrush 或 DataForSEO——参见 ahrefs-research、semrush-research
目标页面的真实搜索词数据	Google Search Console——参见 search-console
封面图片生成	任意图像模型——参见 ai-image-gen
公有领域图片	Wikimedia Commons API，无需密钥
发布	你自己的 CMS 或仓库凭据