write-blog

撰写博客文章

你正在帮助一位贡献者为项目网站撰写博客文章。标准如下：文章读起来像真人写的，能在一个尚无其他文章占据的搜索关键词集群中获得排名，并且能正确集成到网站，且构建通过。

文章中的技术说明和操作说明应使用 ASD-STE100 简明技术英语（STE）。句子要简短、直接，术语要一致，操作要明确。如果可以查阅 STE 词典，则应采用技术词汇的认可含义。不要使用习语、俚语、比喻或可能导致技术术语含义不清的同义词替换。保留代码、命令、标识符、产品名称和引文原文。文章可以表达个人观点，也可以提供具体示例，但清晰度优先于节奏或修饰。未经核对当前版本的 ASD-STE100 和词典，不要声称文章严格符合 STE 标准。

创建此技能的目的是让每位贡献者使用相同的写作风格，选择互不重叠的主题，并通过相同的反 AI 套话检查，无论他们是否了解项目的写作规则。

导致文章被拒的唯一规则

绝不使用 em dash（—）或 en dash（–）。 项目的写作风格禁止使用这些符号。请改用句号、逗号、“所以”或“因为”，也可以使用括号。草稿中只要出现一个破折号，就会直接不合格。请使用扫描器：在完成草稿前，对草稿运行 bash check.sh <file>（位于此技能的文件夹中）。

工作流程

请按以下顺序执行。不要跳过角度检查或去 AI 套话处理。

1. 先阅读事实依据

动笔前，请先阅读现有内容，以便匹配写作风格并避免关键词蚕食：

• 网站的文章注册表或索引。 阅读所有已发布文章的列表，不论它是注册表文件、内容集合、CMS 列表，还是博客源目录中的 frontmatter。这是所有已发布文章及其所占据角度的最新记录。阅读每篇文章的 slug、标题、描述和标签集。
• 阅读一到两篇完整的已发布文章（正文来源），熟悉写作风格。
• 阅读 reference/angles.md（位于此技能文件夹中），了解如何选择不冲突的角度，以及哪些主题尚未涉及。
• 阅读 reference/voice.md，了解项目的写作风格和反 AI 检查清单。该文件内容独立完整。
• 阅读 reference/craft.md，了解写作技巧：能吸引点击的开篇、文章主线结构，以及各阶段应采用的创意写作技能。
• 阅读 reference/seo.md，了解页面内关键词放置、内链、机器可读 SEO 的验证，以及文章发布后的推广流程，该流程有助于获取首批反向链接。

2. 选择角度并提交提案

每篇文章都必须占据一个独特的搜索关键词集群。两篇文章若争夺相同的关键词，就会互相蚕食流量。请根据文章索引和 reference/angles.md，选择一个尚未被已发布文章占据的角度，然后先用一行文字向贡献者提交提案，再开始起草：列出工作标题、一句话论点，以及目标关键词短语（3 到 5 个）。获得确认后，再撰写正文。如果对方提供的主题与现有文章冲突，请指出这一点，并提出相邻但不同的角度。

3. 大纲

好文章有主线，而不是一份清单。起草大纲前先阅读 reference/craft.md；开篇和 H2 主线决定了 80% 的文章能否完成并获得排名。结构如下：

• 开篇（描述 + 引言）要点明读者遇到的具体问题。不要写“AI Agent 正在改变协作方式”。可以写：“两个 Agent 可以整天讨论一项改动。要逐字节地移交改动本身，则是另一回事。”
• 设 4-7 个章节，每个章节都要提出一个观点，并用项目中的真实代码、真实命令或真实数据佐证。阅读项目的实际源码和文档，并准确引用。编造的 API 比不写代码更糟。
• 加入“这不是什么”或坦诚说明局限性的部分。语气可以稍带反叛，并承认哪些内容暂未涵盖。坦诚才能让文章读起来不像营销文案。
• 结尾要呼应核心论点，不要用“总之，未来一片光明”之类的泛泛总结。以读者能采取或核实的具体行动收尾。

4. 撰写初稿

先用纯 Markdown 撰写正文，保存在博客的源目录中（即事实来源）。写作时遵循 reference/voice.md、reference/craft.md 和上述 STE 指南。保持诚恳、具体，并以项目的真实代码为依据。明确表达一个观点，并用证据支撑。如果你的环境中提供了 /direct-response-copy，请用它优化标题、描述和结尾 CTA（仅限这三个部分，不要处理正文）。

5. 润色（必须）

对初稿进行润色处理：如果你的环境中提供了 /humanizer，请用它处理初稿。如果没有，请自行按照 reference/voice.md 中的清单进行处理。然后进行 STE 检查。检查句子长度、主语和动作是否清晰、技术术语是否一致、适用时是否使用了批准的词义，以及有意保留的例外。删去：夸大重要性、宣传性形容词、三段式表达、“-ing”结尾的分析、否定式平行结构（“不是 X，而是 Y”）、同义词轮换、模棱两可的措辞，以及所有破折号。润色标题、描述和 CTA 时，也可以使用 /direct-response-copy（如果有）。

然后运行 bash check.sh <draft-file>，并修复它标出的问题。

6. 将文章接入网站

遵循 reference/wiring.md。简而言之：在博客使用的索引或注册表中登记文章，按博客格式添加正文，确保 SEO 相关位置（站点地图、RSS、OG/Twitter 卡片、JSON-LD）都包含新文章，添加封面图片，然后构建网站。关键词布局（标题/描述/首个 H2/标签）、内链数量和锚文本规则，请遵循 reference/seo.md。从主题最相关的现有文章添加一条指向本文的反向链接。

7. 完成前进行验证

网站必须成功构建。然后对文章进行冒烟测试：确认文章页面、封面图片、博客索引、站点地图和 RSS 订阅源均可加载，并且都包含新文章。查看文章页面的源代码，确认实际输出了含正确值的 meta description、OG/Twitter 标签和 BlogPosting JSON-LD（reference/seo.md 列出了检查项）。最后对 Markdown 文件重新运行 bash check.sh。完成这些检查后，文章本身才算完成。

8. 分发（这是获得关注的关键）

一篇正确的文章如果没有导入链接，就无法获得排名。发布后，先建立第一批信号：如果你的环境中提供了 /x-tweet，请用它围绕文章的核心观点生成一条讲解该观点并链接到文章的帖子串；从相关文档链接到文章；并在人们已经提出相关问题的地方，回答文章所解决的实际问题。请参阅 reference/seo.md 中的分发闭环。始终链接到正式生产环境中的规范 URL（<your-site-url>/blog/<slug>），绝不要链接到预发布或预览环境的主机。

规范

• 切勿杜撰项目 API、标志或数字。阅读源内容并据此引用。
• 切勿为了显得“专业”而削弱品牌语气。具体且略带反常规的表达，始终胜过 polished 且泛泛而谈的表达。
• 技术和说明性文字使用 STE。若比喻或修饰性措辞会降低技术清晰度，就不要使用。
• 不要发布主题角度与已发布文章重叠的帖子。改换主题角度。
• 封面可以是 SVG 或栅格图像。与网站的品牌配色保持一致。如果做不出好的封面，就重用现有封面，不要发布难看的封面。

关于此技能自身文件的说明

扫描器会标记 SKILL.md 和 reference/ 文件，因为其中提到了被禁字符 (—) (–)，并将 → 用作教学符号。这是预期行为。扫描器针对的是博客草稿和渲染后的帖子正文，而不是此技能的文档。