wechat-tech-article

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

WeChat Tech Article

Overview

结构化地完成一篇微信公众号技术文章，从选题到定稿。遵循

blogs/wechat

的规范与既有文章风格。

Structuredly complete a technical article for WeChat Official Accounts, from topic selection to finalization. Follow the specifications and existing article style of

blogs/wechat

Hard Gates (必须满足)

Hard Gates (Mandatory Requirements)

风格来源（强制）：写作前必须读取：
- ```
blogs/wechat/README.md
```
  （目录/命名/发布节奏）
- ```
skills/wechat-tech-article/references/style-guide.md
```
  （你的固定文风与结构套路）

目录命名：

posts/YYYY/YYYY-MM-DD-<kebab-case-english-slug>/

文件命名：目录名与 .md 文件名完全一致
Slug 规则：只用英文（不用拼音）、用
```
-
```
分隔、尽量简短
引用路径：文章内引用本地文件使用相对路径
```
./
```
结构硬门槛（强制）：
- 第一行必须是
```
# 标题
```
- 标题后 10-15 行内必须出现：入口链接（GitHub/下载/在线体验其一）+ 一句加粗
```
**tagline**
```
- 文章正文只用
```
#
```
  /
```
##
```
  标题（禁止使用
```
###
```
  及更深层级）
可复现优先（强制）：至少 2 个可复制代码块（bash/yaml/toml/json 任选），并配解释

Style Source (Mandatory): Must read the following before writing:
- ```
blogs/wechat/README.md
```
  (directory/naming/publishing rhythm)
- ```
skills/wechat-tech-article/references/style-guide.md
```
  (your fixed writing style and structure framework)

Directory Naming:

posts/YYYY/YYYY-MM-DD-<kebab-case-english-slug>/

File Naming: The directory name must be exactly the same as the .md file name
Slug Rules: Use only English (no Pinyin), separate with
```
-
```
, keep it as concise as possible
Reference Path: Use relative path
```
./
```
when referencing local files in the article
Structure Hard Gates (Mandatory):
- The first line must be
```
# Title
```
- Within 10-15 lines after the title, there must be: an entry link (one of GitHub/download/online experience) + a bolded
```
**tagline**
```
- Only use
```
#
```
  /
```
##
```
  for headings in the article body (prohibit using
```
###
```
  and deeper levels)
Reproducibility First (Mandatory): Include at least 2 copyable code blocks (choose from bash/yaml/toml/json), with accompanying explanations

Workflow (四阶段)

Workflow (Four Phases)

阶段 1: 选题与定位 (Topic & Positioning)

Phase 1: Topic & Positioning

输入：用户给出的主题/想法

执行：

问清楚：
- 这篇文章解决读者的什么问题？
- 目标读者是谁？（开发者、DevOps、技术管理者？）
- 你的独特视角是什么？（别人没写过的、你自己的经验）
根据主题生成 3 个候选 slug，让用户选择
选择文章模式（只影响内容组织，不影响你的“排版签名”）：
- 模式 A：开源项目/工具发布（公众号型：钩子强、入口早给、可复现步骤多）
- 模式 B：技术科普/架构深挖（技术博客型：层级清晰、定义问题、拆解机制）
创建文章目录和 .md 文件骨架
生成标题候选（见下方「标题工坊」），用户拍板后再进入大纲阶段

输出：

posts/YYYY/YYYY-MM-DD-<slug>/
└── YYYY-MM-DD-<slug>.md  # 含基础骨架

骨架模板：

markdown

undefined

Input: Topic/idea provided by the user

Execution:

Clarify the following:
- What problem does this article solve for readers?
- Who is the target audience? (Developers, DevOps, technical managers?)
- What is your unique perspective? (Content no one else has written, your own experience)
Generate 3 candidate slugs based on the topic for the user to choose from
Select the article mode (only affects content organization, not your "typesetting signature"):
- Mode A: Open source project/tool release (official account style: strong hook, early entry link, many reproducible steps)
- Mode B: Technical popularization/architecture deep dive (technical blog style: clear hierarchy, problem definition, mechanism breakdown)
Create the article directory and .md file skeleton
Generate title candidates (see "Title Workshop" below), proceed to the outline phase only after the user confirms the title

Output:

posts/YYYY/YYYY-MM-DD-<slug>/
└── YYYY-MM-DD-<slug>.md  # Contains basic skeleton

Skeleton Template:

markdown

undefined

[标题：一句话说明价值]

[Title: One-sentence value statement]

[副标题：情景化描述/问题引入]

[Subtitle: Scenario description/problem introduction]

前言

Preface

[为什么写这篇、谁应该读]

[Why write this article, who should read it]

[核心章节 1]

[Core Chapter 1]

[小节 1]

[Section 1]

[小节 2]

[Section 2]

[小节 N]

[Section N]

[核心章节 2]

[Core Chapter 2]

[核心章节 N]

[Core Chapter N]

结语

Conclusion

[总结 + 行动建议]

undefined

[Summary + action suggestions]

undefined

标题工坊 (爆款但不虚)

Title Workshop (Viral but Authentic)

目标：生成“像你写的”标题：强钩子、直击场景、可落地；避免夸大其词。

强制要求（标题 hard gate）：

不能承诺无法证明的收益（例如“效率暴涨 10 倍”除非你有基准/数据）
标题至少包含以下两项：对象/工具 + 场景/痛点 + 收益/结果 + 悬念（任取其二以上）

生成规则（按你常用钩子风格优先）：

反问/反差：例如“不会吧？你还在……？”
“我做了/我开源了……”：适合模式 A
迁移/替换：例如“这个开源插件帮助我从 A 迁移到 B”
顺手/工作流：例如“我把 X 做成了一个顺手的 CLI”

输出格式：

生成 8 个标题候选，按类型分组（痛点/数字/结果/悬念/清单/反常识任选）
每个标题附 1 行备注：适合读者 + 主打收益点
给出 Top 2 推荐 + 推荐理由（具体性/可信度/读者匹配）

Goal: Generate titles "like you write": strong hook, scenario-focused, actionable; avoid overstatement.

Mandatory Title Requirements:

Cannot promise unprovable benefits (e.g., "10x efficiency boost" unless you have benchmarks/data)
The title must include at least two of the following: object/tool + scenario/pain point + benefit/result + suspense (choose any two or more)

Generation Rules (prioritize your commonly used hook styles):

Rhetorical question/contrast: e.g., "No way? You're still doing...?"
"I built/I open-sourced...": Suitable for Mode A
Migration/replacement: e.g., "This open-source plugin helped me migrate from A to B"
Workflow/convenience: e.g., "I turned X into a handy CLI"

Output Format:

Generate 8 title candidates, grouped by type (choose from pain point/number/result/suspense/list/counterintuitive)
Each title is accompanied by 1 line of note: suitable audience + core benefit
Provide Top 2 recommendations + reasons (specificity/credibility/audience matching)

阶段 2: 大纲与素材 (Outline & Research)

Phase 2: Outline & Research

执行：

细化大纲（每章节 3-5 个要点）
标记需要研究的内容（数据、引用、案例），并优先近期信息（当月/当季）；过期资料必须标注“可能过时”
并行收集信息来源（官方文档 / 权威博客 / 社区讨论），避免单一来源偏差
标记需要准备的素材（代码片段、截图、示意图）
如果需要生成图片，按环境能力选择：
- 如支持生成图片工具：生成并保存到文章目录（同级或
```
assets/
```
  ）
- 否则：列出“需要的图清单”并说明每张图证明什么

大纲格式：

markdown

undefined

Execution:

Refine the outline (3-5 key points per chapter)
Mark content that requires research (data, references, cases), prioritize recent information (current month/quarter); outdated materials must be labeled "may be outdated"
Collect information sources in parallel (official documentation / authoritative blogs / community discussions) to avoid single-source bias
Mark materials that need preparation (code snippets, screenshots, diagrams)
If image generation is needed, choose based on environment capabilities:
- If image generation tools are supported: Generate and save to the article directory (same level or
```
assets/
```
  )
- Otherwise: List a "required image checklist" and explain what each image demonstrates/proves

Outline Format:

markdown

undefined

[章节标题]

[Chapter Title]

要点 A
要点 B [需要数据支撑]
要点 C [需要代码示例]
[可能需要示意图]


**素材清单**（同目录下创建）：

posts/YYYY/YYYY-MM-DD-<slug>/ ├── YYYY-MM-DD-<slug>.md ├── outline.md # 详细大纲 ├── research.md # 研究素材 └── assets/ # 图片等资源（可选；也可直接同级放置）

undefined

Key Point A
Key Point B [requires data support]
Key Point C [requires code example]
[may require diagram]


**Material Checklist** (create in the same directory):

posts/YYYY/YYYY-MM-DD-<slug>/ ├── YYYY-MM-DD-<slug>.md ├── outline.md # Detailed outline ├── research.md # Research materials └── assets/ # Images and other resources (optional; can also be placed at the same level)

undefined

阶段 3: 逐节写作 (Section-by-Section Writing)

Phase 3: Section-by-Section Writing

原则：

一次只写一个章节
写完一节后暂停，等待用户反馈
用户确认后再写下一节

写作检查点（每节完成后自问）：

是否有具体例子/代码/数据支撑？
是否避免了空洞的套话？
是否符合用户的写作风格？
引用本地资源是否使用了相对路径？

Hook 优化（开头段特别关注）：

用数据/故事/问题开头，不要用"今天我们来聊聊 X"
前三句决定读者是否继续

Principles:

Write only one section at a time
Pause after completing a section and wait for user feedback
Proceed to the next section only after user confirmation

Writing Checkpoints (ask yourself after completing each section):

Is there specific examples/code/data to support it?
Have empty clichés been avoided?
Does it match the user's writing style?
Are relative paths used for referencing local resources?

Hook Optimization (pay special attention to the opening paragraph):

Start with data/story/questions, not "Today we're going to talk about X"
The first three sentences determine whether readers will continue reading

阶段 4: 定稿与发布准备 (Finalization)

Phase 4: Finalization & Publishing Preparation

检查清单：

标题：是否一眼明白价值？
副标题：是否引起好奇？
长度：公众号建议 2000-4000 字
配图：是否有封面图？
代码块：是否语法高亮正确？
链接：是否都可点击？
排版签名：短段落（3-4 行）、加粗关键词、代码块前后留白

发布建议（基于 README.md）：

时区：北京时间（CST / Asia/Shanghai）
公众号：周二 21:30；备选周三/周四 21:30；加餐（可选）周日 21:00（长文长尾）
朋友圈导流：推文发布后 10–20 分钟

输出：

✅ 文章定稿：posts/YYYY/YYYY-MM-DD-<slug>/YYYY-MM-DD-<slug>.md
📊 字数统计：[N] 字
📅 建议发布：[日期 时间]

Checklist:

Title: Is the value clear at a glance?
Subtitle: Does it arouse curiosity?
Length: 2000-4000 words is recommended for official accounts
Images: Is there a cover image?
Code blocks: Is syntax highlighting correct?
Links: Are all links clickable?
Typesetting signature: Short paragraphs (3-4 lines), bold keywords, white space before and after code blocks

Publishing Recommendations (based on README.md):

Time zone: Beijing Time (CST / Asia/Shanghai)
Official account: 21:30 on Tuesday; alternative: 21:30 on Wednesday/Thursday; extra (optional): 21:00 on Sunday (long-tail for long articles)
Moments diversion: 10–20 minutes after the article is published

Output:

✅ Finalized article: posts/YYYY/YYYY-MM-DD-<slug>/YYYY-MM-DD-<slug>.md
📊 Word count: [N] words
📅 Recommended publishing time: [Date Time]

禁止事项

Prohibited Items

禁止：一口气写完全文再给用户看
禁止：使用拼音做 slug
禁止：使用绝对路径引用本地文件
禁止：跳过大纲阶段直接写正文
禁止：使用"今天我们来聊聊"等套话开头
禁止：把图片当装饰（每张图出现前后必须解释它展示/证明什么）

Prohibited: Write the entire article at once before showing it to the user
Prohibited: Use Pinyin for slugs
Prohibited: Use absolute paths to reference local files
Prohibited: Skip the outline phase and directly write the body
Prohibited: Use clichéd openings like "Today we're going to talk about"
Prohibited: Use images as decoration (each image must be explained before and after to show what it demonstrates/proves)

风格指南

Style Guide

默认强制遵循：

skills/wechat-tech-article/references/style-guide.md

。

以下为“速记版”风格指纹（帮助快速自检，不取代原文）：

开门见山：前言直接说"我遇到了什么问题 → 如何解决"
结构清晰：多用小标题、列表、表格
代码配文字：代码块后必须有解释
观点鲜明：不怕说"这样不好"、"我认为"
结尾行动化：给读者 1-2-3 步可执行建议

Mandatory default compliance:

skills/wechat-tech-article/references/style-guide.md

The following is a "quick reference" style fingerprint (helps with quick self-check, does not replace the original document):

Get straight to the point: The preface directly states "What problem I encountered → How I solved it"
Clear structure: Use more subheadings, lists, tables
Code with explanations: Must include explanations after code blocks
Clear viewpoints: Don't be afraid to say "This is not good", "I think"
Actionable conclusion: Give readers 1-2-3 executable suggestions

模板与长文规范

Template & Long Article Specifications

如需可复制模板（模式 A/模式 B），优先参考：

skills/wechat-tech-article/references/style-guide.md

。

如需“快速开写”的精简可复制模板：

skills/wechat-tech-article/references/templates.md

。

如需“风格速查表”（默认强制风格的浓缩版）：

skills/wechat-tech-article/references/style-cheatsheet.md

。

For copyable templates (Mode A/Mode B), prioritize reference to:

skills/wechat-tech-article/references/style-guide.md

For a streamlined copyable template for "quick writing":

skills/wechat-tech-article/references/templates.md

For a "style cheat sheet" (condensed version of the mandatory default style):

skills/wechat-tech-article/references/style-cheatsheet.md