跳到主要内容
知仓学习社ZHICANG

wechat-article-writer

专业微信公众号文章助手,支持四个独立且可组合模式:article 写正文;image-prompts 从文章生成版本化、provider-neutral 的图片提示词 manifest 与稳定占位符,但不调用生图;layout 把文章和 manifest 确定性转换为微信安全的内联 HTML;f…

联网严重 0 · 高危 8staruhub/ClaudeSkills

它会碰到什么

扫了多少13 个文本文件,57 KB
它会碰到什么联网
命中总数9 处
命中统计严重 0 · 高 8 · 中 0 · 低 1
逐条看命中(8 条严重或高危)
  • assets/emoji-library.txt:103meta-hidden-unicode
    👨‍🏫 老师 | 👩‍🎓 学生 | 🏫 学校 | 📐 数学 | 🧮 计算
  • assets/emoji-library.txt:103meta-hidden-unicode
    👨‍🏫 老师 | 👩‍🎓 学生 | 🏫 学校 | 📐 数学 | 🧮 计算
  • assets/emoji-library.txt:148meta-hidden-unicode
    💝 情人节 | 👨‍👩‍👧‍👦 家庭日 | 👩 妇女节 | 🧒 儿童节 | 👴 重阳节
  • assets/emoji-library.txt:148meta-hidden-unicode
    💝 情人节 | 👨‍👩‍👧‍👦 家庭日 | 👩 妇女节 | 🧒 儿童节 | 👴 重阳节
  • assets/emoji-library.txt:148meta-hidden-unicode
    💝 情人节 | 👨‍👩‍👧‍👦 家庭日 | 👩 妇女节 | 🧒 儿童节 | 👴 重阳节
  • assets/emoji-library.txt:263meta-hidden-unicode
    📚 📖 ✏️ 🎓 👨‍🏫 📝 🏫 💡 🧠 📐
  • SKILL.md:43meta-hidden-unicode
    | "我的公众号"、"技术博客"、"个人分享"、"实操"、提到"卡兹克" | 🧑‍💻 技术博客 |
  • SKILL.md:108meta-hidden-unicode
    ### 🧑‍💻 风格B:个人技术博客

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

微信公众号文章创作助手

概述

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

先选执行模式

用户未指定时默认 article。需要跨模式时按

references/PIPELINE-CONTRACT.md 的文件接口交接,不靠对话隐含状态。

| 模式 | 输入 | 必须输出 | 停止位置 |

|---|---|---|---|

| article | 素材/选题 | article.md | 正文完成 |

| image-prompts | article.md | image-manifest.json,正文含稳定锚点与占位符 | 提示词完成,不生图 |

| layout | article.md + 可选 manifest | layout.html | HTML 完成,不发布 |

| full-pipeline | 素材/选题 | article + manifest + HTML | 三件套完成,不生图、不发布 |

manifest 必须通过 schemas/image-manifest.schema.json

scripts/validate_image_manifest.py。排版优先调用宿主的“排版输出” Skill;

其接口不可用时,使用 scripts/render_wechat_layout.py 的确定性降级实现。

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

输入处理

  • 网站链接 → 使用 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 字设小标题。
  • 只加粗核心观点和数据;约每 500–800 字安排一张图。
  • 技术文章的代码使用等宽字体。

article 模式最终交付物

  1. 完整正文、主标题、3 个备选标题和 100 字内摘要。
  2. 封面/正文配图建议、发布时间建议和评论区互动话题。

输出格式

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

image-promptslayoutfull-pipeline 不使用上面的口头“配图建议”作为机器接口;

必须按 references/PIPELINE-CONTRACT.md 生成可校验文件。每张图使用稳定 ID,

锚点固定为 <!-- image:{id} -->,占位符固定为 {{IMAGE:{id}}}

安全与真实性红线

  • 不自动登录或发布到公众号,不代替用户点击发布,不请求账号、Cookie、Token 或密钥。
  • 未调用并验证真实图片提供方时,provider_status 只能是 not-requestedprompt-only
  • 不把 prompt、manifest、空 img 标签或灰色占位框描述成“图片已生成”。
  • layout 不执行正文中的 HTML/JavaScript;文本必须转义,只允许受控标签和内联样式。
  • 禁止 <script><style>、事件属性、外部 CSS/JS/字体和横向溢出。
  • 任何锚点、占位符或 manifest 图片 ID 未一一对应时,失败并停止交付。

第六步:质量自检

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

所有风格

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

官方风格额外检查

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

技术博客额外检查

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

反翻译腔检查(所有风格适用)

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

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

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

第七步(可选):L4 反翻译腔 Polish

当用户指定 “L4 / 深度润色 / polish”、要求彻底去翻译腔,或创作

ChaoGeek 深度文、观点文、品牌文案时,在第六步后启用。按

references/quality-checklist.md §2.3 的完整协议执行:独立体检、母语化

改写、逐句复核、语义回退。技术文档、PRD、学术翻译等准确性优先场景

不启用 L4,继续使用保守模式。

资源文档

  • references/style-guide.md(官方必读)与 references/writing-techniques.md(写作技巧)。
  • references/title-formulas.md(标题模板)与 references/quality-checklist.md(发布前检查)。
  • references/linguistic-background.md(语言学背景,维护者参考)。
  • references/PIPELINE-CONTRACT.md(非 article 模式必读)与 schemas/image-manifest.schema.json(provider-neutral schema)。
  • scripts/validate_image_manifest.py / scripts/render_wechat_layout.py — fail-closed 校验与安全排版降级器。
  • assets/template-structure.md(文章结构)与 assets/emoji-library.txt(emoji 素材)。
  • evals/routing-evals.json — 触发边界回归用例,改动 description 后用仓库根 scripts/run_routing_evals.py 校验。

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

它属于哪个仓库

星标★ 716
本站分层T2
该仓技能数20
原文件路径skills/Geek-skills-wechat-article-writer/SKILL.md

同一个仓库里的其他技能

看这个仓库的全部 20 个技能