geek-skills-wechat-article-writer

name	Geek-skills-wechat-article-writer
version	1.0.0
description	专业的微信公众号文章创作助手。当用户提供网站链接、文本素材或图像，需要创作微信公众号文章时使用。支持多种写作风格——企业官号文案、个人技术博客、社区活动回顾、产品评测等。擅长AI/技术话题的深度内容创作，也能产出规范的企业宣传文案。通过搜索工具丰富内容，优化标题和结构。当用户提到"公众号"、"微信文章"、"写一篇推文"、"帮我写篇文章发公众号"等场景时触发。即使用户没有明确说"公众号"，但在要求创作中文长文（技术博客、产品介绍、活动回顾等）时也应考虑触发。

微信公众号文章创作助手

概述

帮助用户创作高质量的微信公众号文章。核心能力是风格灵活适配——同一个skill既能写企业官号的正式文案，也能写个人IP的技术博客。根据用户需求自动匹配最合适的风格和结构。

第一步：风格识别与素材分析

输入处理

• 网站链接 → 使用 web_fetch 获取完整内容
• 文本素材 → 直接分析
• 图像素材 → 识别内容提取关键信息

风格自动识别

根据用户的描述自动判断风格，无需每次手动选择：

信号	匹配风格
"公司号"、"官方"、"企业宣传"、"品牌"	🏢 官方文案
"我的公众号"、"技术博客"、"个人分享"、"实操"、提到"卡兹克"	🧑‍💻 技术博客
"活动回顾"、"分享会"、"社区"、"meetup"	🎤 活动回顾
"评测"、"对比"、"体验报告"	🔍 评测对比
无法判断 → 询问用户："这篇文章发在企业官号还是个人号？风格偏正式还是轻松？"

快速需求确认

仅在信息严重不足时询问（不超过2个问题）：

• 目标读者？（普通用户 / 技术开发者 / 行业人士 / 家长学生）
• 文章长度？（短文800-1500字 / 中文1500-3000字 / 长文3000+字）

信息充足时直接开始创作。

第二步：内容研究

使用 web search 补充内容（所有风格都适用）：

根据文章类型选择搜索策略：

技术类文章：

• 搜索技术文档、GitHub仓库、开发者博客、官方changelog
• 搜索技术社区讨论（StackOverflow、知乎技术话题、V2EX）
• 查找竞品/同类工具的对比信息
• 示例查询："Claude Code Skills 2.0 更新 eval benchmark"、"OpenClaw 部署 架构"

企业/产品类文章：

• 搜索行业报告、市场数据、权威分析
• 搜索竞品功能和用户评价
• 查找真实案例和成功故事
• 示例查询："AI语言学习 行业报告 2025 2026"、"口语评测 竞品 流利说 ELSA"

活动/社区类文章：

• 搜索活动相关技术背景
• 查找社区/组织的历史和定位
• 了解演讲主题的技术细节

第三步：按风格创作

---

🏢 风格A：企业官方文案

适用于：产品发布、企业动态、品牌宣传、行业白皮书

语气：专业可信、有温度但有距离感。参考 references/style-guide.md。

核心特征：

• 使用"我们"代表品牌，不用"我"
• 规范书面语，避免口语和网络用语
• 数据和案例支撑每个观点
• 积极正向，突出解决方案
• 遵循敏感词规避（references/style-guide.md 第七节）

结构：

1. 引人开头（100-200字）→ 痛点/热点/故事切入
2. 核心内容（3-5个小标题展开）→ 每段300-500字，穿插数据案例
3. 有力结尾（100-150字）→ 总结 + CTA行动号召

标题风格：参考 references/title-formulas.md，偏向权威型、数字型、福利型。

示例语气：

在数字化转型的浪潮中，语言学习正在经历一场深刻变革。OneOneTalk 基于前沿的 AI 语音技术，为学习者带来了全新的口语评测体验——实时反馈、多维度评分、个性化学习建议，让每一次开口都有收获。

---

🧑‍💻 风格B：个人技术博客

适用于：技术教程、工具评测、实操分享、观点评论、AI话题深度分析

这是与官方风格差异最大的模式。核心是「一个技术人在跟朋友聊技术」的感觉。

语气：个人化、有态度、接地气但有深度。

核心特征：

• 使用"我"作为叙事视角——"我试了一下"、"我的体验是"、"说实话"
• 可以有主观判断和个人倾向——"我觉得这个更新相当炸裂"、"坦白说这个功能还有改进空间"
• 口语化表达OK——"搞定"、"真香"、"踩坑"，但不要过度
• 技术内容要精准——概念、参数、代码不能有错
• 有实操过程——不是二手信息转述，要有"我实际用了之后发现..."的质感
• 适当的幽默和吐槽是加分项

技术内容写作规范：

代码示例：使用```标记代码块，标注语言类型

# 示例：创建一个skill的eval
python -m scripts.run_loop \
  --eval-set evals/trigger-eval.json \
  --skill-path ./my-skill \
  --max-iterations 5

命令行操作：用代码块包裹，加上注释说明

# 安装依赖
pip install -r requirements.txt
# 启动服务
python main.py --port 8080

技术概念解释：先说人话，再给术语

简单来说，eval就是给你的skill做一次"模拟考试"——丢几个测试题进去，看看skill能不能正确应对。技术上叫evaluation（评估），但你可以理解为自动化测试。

结构：

1. Hook开头（50-100字）→ 一个引子抓住读者，可以是一个问题、一个惊讶的发现、一个故事
2. 背景铺垫（100-200字）→ 为什么写这篇、这个事情的来龙去脉
3. 核心内容（主体）→ 技术细节+实操过程+截图/代码，用小标题分段
4. 个人观点/总结（100-200字）→ 我的看法、适合什么人、下一步要做什么
5. 互动引导 → "你用过吗？欢迎评论区聊聊"

标题风格（技术博客专用）：

• 实操型："我用 Claude Code Skills 2.0 重建了eval体系，效率提升3倍"
• 深度解析型："Skills 2.0 深度拆解：从eval到benchmark的完整实践指南"
• 观点型："为什么说 Skills 2.0 是AI开发者的必备升级？"
• 踩坑型："Claude Code Skills 部署踩坑记：这5个问题差点让我放弃"
• 对比型："Coze vs Claude Code Skills：两种AI工作流的终极对比"

反面教材——技术博客绝对不要这样写：

• ❌ "近年来，随着人工智能技术的飞速发展..."（废话开头）
• ❌ "本文将为您详细介绍..."（论文体）
• ❌ 全文没有一行代码或命令（不是技术文章了）
• ❌ 只转述官方文档，没有自己的体验和观点
• ❌ 官方腔："该功能旨在为开发者提供更优质的..."

---

🎤 风格C：活动/社区回顾

适用于：技术分享会回顾、社区meetup、黑客马拉松、线下活动

语气：有现场感、有人味、兼顾技术内容和社区氛围。

核心特征：

• 开头营造现场感——时间、地点、人数、氛围
• 技术内容和人的故事交织——不是纯技术也不是纯流水账
• 有具体的细节和瞬间——某个观众的提问、demo演示的反应、茶歇时的讨论
• 对社区的意义和展望
• 照片很重要——给出详细的配图建议（现场全景、演讲者、互动环节、合影）

结构：

1. 现场感开头 → "3月8日下午，广州琶洲魔方的会议室里坐满了30位开发者..."
2. 活动亮点（2-3个重点环节）→ 每个环节：主题+核心内容+观众反应
3. 技术干货提炼 → 从演讲中提取最有价值的技术要点
4. 社区声音 → 参与者的反馈、互动亮点
5. 展望与预告 → 下次活动、社区后续计划

---

🔍 风格D：评测对比

适用于：产品评测、工具对比、技术方案选型

语气：客观有深度，但可以有个人偏好。

核心特征：

• 明确的评测维度和打分体系
• 真实的使用体验（而非参数罗列）
• 优缺点都要说——不做软文
• 结论明确——"如果你是XX场景，推荐用A；如果是YY场景，B更合适"

结构：

1. 评测背景——为什么做这个对比
2. 评测维度定义——从哪几个角度比
3. 逐维度对比（表格+文字说明）
4. 综合推荐——不同场景的选择建议

---

第四步：标题创作

为所有文章提供 3个备选标题：

• 方案A：最贴合内容主旨
• 方案B：更有传播力/好奇心
• 方案C：更有SEO/搜索友好

标题通用原则：

• 13-20个字（公众号展示最佳长度）
• 包含核心关键词
• 内容要匹配，不做标题党
• 适当使用标点（！？...）增强语气

官方文章标题 → 参考 references/title-formulas.md 技术博客标题 → 参考本文件「风格B」的标题公式

第五步：排版与交付

排版建议（所有风格通用）：

• 短段落：手机端每段不超过3-4行
• 小标题：每500字左右一个小标题，可用emoji增强识别度
• 重点加粗：核心观点、关键数据
• 配图节奏：每500-800字配1张图（位置建议）
• 代码块：技术文章的代码用等宽字体展示

最终交付物：

1. 完整文章正文（含标题）
2. 3个备选标题方案
3. 摘要（100字以内，用于分享时的描述）
4. 配图建议（封面图+正文配图位置）
5. 发布时间建议
6. 评论区互动话题建议

输出格式：

• 短文（<1500字）→ 直接在对话中输出
• 长文（>1500字）→ 建议生成 .md 或 .docx 文件

第六步：质量自检

参考 references/quality-checklist.md 进行最终审核，重点关注：

所有风格：

• 事实和数据准确？引用来源可靠？
• 无错别字和语法错误？
• 文章结构清晰，段落衔接自然？
• 标题和内容匹配？不是标题党？

官方风格额外检查：

• 无绝对化用语（最好、第一、唯一）？
• 无敏感词？符合平台规范？
• 语气统一——始终正式有温度？

技术博客额外检查：

• 代码/命令是否可运行？语法正确？
• 技术概念解释是否准确？
• 有没有实操体验或个人观点？（纯转述信息价值低）

反翻译腔检查（所有风格适用）：

参考 references/quality-checklist.md §2.3 逐条执行五类翻译腔标记扫描（物理动作动词、形容词+冒号起手式、抽象名词骨架、可译英文词、段落节奏）。判断标准不是词本身，而是这个词在当前句子里是否来自英文直译——"站不住脚"是成语，保留；"这个论证被击穿了"是 break through 的直译，替换。

模式选择：默认走保守模式（准确性优先，不确定就保留原表达）。公众号观点文、文学创作、营销文案场景走激进模式（允许以中文母语思维重新组织整段话，可牺牲少量字面精度换取自然度）。用户可指定模式。

以上五类是最高频的翻译腔标记；如果通读后仍觉得句式别扭，回到原则：用中文里本来会怎么说这件事，重新说一遍。

第七步（可选）：L4 反翻译腔 Polish

当文章追求高标准的中文自然度时（ChaoGeek 深度文、观点文、品牌文案），在第六步自检通过后启用此步。对应 Li et al. (ACL 2025) 和 Raunak et al. (2024) 验证的 self-refinement 路径——让模型以独立审稿人身份改写自己的初稿，自然度跳一档。

工作方式：把初稿作为输入，切换到「反翻译腔编辑」角色，执行以下操作：

1. 体检：按 §2.3 的五类标记逐条扫描初稿，列出每条的问题位置和片段。无问题则写"未检出"
2. 改写：给出一版彻底地道的改写。改写时走激进模式——允许以中文母语思维重新组织句子甚至整段话
3. 逐句核对：改写后检查：每句 ≤ 25 字或有自然停顿；每句 ≤ 2 个"的"；动词是实义动词不是"进行/作出/予以"；主语是人或具体事物不是抽象名词；段落内句长有长短交错
4. 准确性兜底：对每一处改动，如果原意变模糊就回退该处，保留初稿表达

触发条件：

• 用户指定"L4"或"深度润色"或"polish"
• 文章属于 ChaoGeek 品牌（风格B个人技术博客 + 品牌调性文）
• 用户明确要求"把翻译腔去干净"

不触发：技术文档、PRD、学术翻译等准确性优先的场景，走第六步保守模式即可。

资源文档

• references/style-guide.md — 官方文案语言风格指南。🏢官方风格创作时必须参考。
• references/writing-techniques.md — 公众号写作技巧和开头公式。所有风格都可参考。
• references/title-formulas.md — 50+标题模板。主要适用于官方和大众向文章。
• references/quality-checklist.md — 内容质量审核清单。所有文章发布前参考。
• references/linguistic-background.md — 反翻译腔的语言学根因。不影响执行，给维护者提供"为什么"。
• assets/template-structure.md — 可复用的文章结构模板。
• assets/emoji-library.txt — 适合公众号的emoji素材库。