shield_lock
JinDaGe
← Back to skills
extension
Category: Marketing & GrowthNo API key required

通用公众号写作风格规范

通用公众号写作风格规范。帮助内容创作者生成去AI味、事实严谨的写作内容，检查和修正夸张表达、虚假统计、伪经验腔调，确保分析拆到机制层、建议可直接执行。

personAuthor: sunny31221hubOpenAPI
downloadDownload package

通用公众号写作风格规范

安装位置要求（重要）

本技能只安装到项目级，不要安装到全局目录（~/.claude/skills/、~/.agents/skills/ 等）：

  • 多数工具（Codex、Kimi Code、Cursor 等）：解压到项目根目录的 .agents/skills/writing-style/（Agent Skills 开放标准 universal 目录，工具自动发现）
  • Claude Code：解压到项目根目录的 .claude/skills/writing-style/

安装方式：从技能中心页面下载 zip 解压到上述项目目录；或安装 content-system-setup 技能后运行 python3 scripts/setup.py --install-skills，自动下载安装全部配套技能（项目级）。

写文章前必读：内容定位（第一步，不可跳过）

每次写文章/视频脚本前，第一步先读内容定位，再谈选题与写法：

  1. 若使用 content-system-setup 搭建的内容创作系统，读 AI第二大脑_内容创作系统/00_个人背景/定位总览.md（账号服务谁、内容支柱是什么、红线在哪）；同时过一遍 00_个人背景/创作者档案.md（我是谁、在场场景、素材边界）。其他项目按项目约定路径读取。
  2. 固定话术：内容创作系统的 00_个人背景/文章固定话术.md 维护 IP 介绍和引流话术（其他项目按项目约定），文章中间和末尾按该文档添加，原文引用、不即兴改写；话术变化时以该文件当前内容为准。
  3. 硬约束：
    • 内容主线由账号定位文档决定；选题与调研方向围绕：这个工具有什么用 / 能用在哪些场景 / 怎么用 / 用起来跟别的工具有什么不同 / 我们能拿它做什么。
    • 不是新闻科技自媒体：不写新闻播报、商业解读、涨价八卦类内容；热点可以写，但必须落到「对读者的实际用法」上。
    • 拟定的选题/角度与内容定位冲突时，先向创作者确认方向，不沿旧稿方向继续写。

改稿前必读：先读校对记录

改稿/校对前，先读校对/决策记录（内容创作系统：00_个人背景/校对记录/，其他项目按项目约定）：

  • 创作者否决过的修改：不再提出
  • 创作者采纳过的修改：保持，不改回去 改稿完成后，把创作者本次的修改（否决/采纳）追加进校对记录。

适用场景

  • 写微信公众号文章、小红书文章
  • 写商业分析、行业观察、劝退/反常识类中文文章
  • 写任何面向经营者、从业者、创业者的新媒体内容

不适用场景

  • 纯技术文档、代码注释
  • 对外正式商务公文

文章工作区命名（写公众号文章 / 视频脚本时）

每篇内容在项目约定的内容工作区下的独立文件夹中独占一个目录，文件夹名为三位编号 + 连字符 + 选题名，例如 011-ClaudeCode项目实战指南/。适用目录（按项目约定）：

  • 公众号文章目录
  • 视频文案与口播脚本目录

编号规则：

  1. 三位数字，从 001 开始递增：001-、002-、……、010-、011-
  2. 各目录独立计数：新内容编号 = 所在目录下最大编号 + 1（先 ls 查看现有文件夹确认最大编号，再创建新文件夹）
  3. 该文件夹下所有产出物都放在此文件夹内，选题条目文件（如 T0001-xxx.md）也一并放入
  4. 工作目录内按序列分文件夹、全部 vN 递增排列：
    • 初稿序列：<选题名>-AI初稿-vN.md（v1 起递增；禁止「对标结构版」「终版」等后缀命名，完全按顺序）
    • 成稿序列：成稿vN.md（v1 起递增，见「稿子版本管理」）
    • 排版文件：排版/ 子文件夹，排版输入-vN.md + 排版-vN.html（N 各自递增）
    • 小红书文件：小红书/ 子文件夹，小红书导入版-vN.md + 小红书发布文案-vN.md（N 各自递增）
    • 配图：配图/ 子文件夹
  5. 一个选题一个文件夹，不跨目录

此规则同时记录在项目的流程文档中，两处保持一致。

稿子版本管理（修改稿件时）

修改已有稿件时，永远生成新版本文件，绝不覆盖原稿：

  1. 原稿（如 成稿v1.md）保持原样，一个字都不改
  2. 修改产物写成新版本文件：成稿v2.md → 成稿v3.md → 成稿v4.md……版本号递增
  3. 新版本号 = 所在目录下最大版本号 + 1（先 ls 查看现有文件确认最大版本号，再创建新文件）
  4. 每个版本独立成文件，保留全部历史，可随时回退、对比
  5. 仅当用户明确说"覆盖原稿 / 替换成这个版本"时，才允许原地修改原稿文件
  6. 命名只用「成稿vN」递增：不写「最终发布稿」「终稿」「定稿」这类名称——没人知道哪篇是最终，永远往下排。类似「AI初稿」「素材包」等流程产物按流程名保留，不参与成稿版本计数

版本文件全部保留在同一工作目录内，与选题原文、素材放一起。用户对版本有评价时，先弄清评价针对哪个版本，只改目标版本或新建版本，不动其他版本。

写作素材：调用观点卡片

写文章/脚本前，先到项目的内容素材库匹配与选题相关的观点卡片，作为观点与素材来源（内容创作系统：AI第二大脑_内容创作系统/02_内容素材/思想卡片/，其他项目按项目约定）。

匹配方法（只读卡片头，不用读全文）：

  1. 读 _INDEX.md 拿到全部卡片清单（编号、主题、摘要）
  2. 对每张候选卡片，读文件头部 YAML 卡片头（frontmatter），按三个维度匹配：
    • pillars（内容支柱）：选题落在哪个支柱 → 优先支柱匹配的卡片
    • topics / keywords（适配选题 / 关键词）：与当前选题描述重合度
    • audience（目标读者）：与文章目标读者一致
  3. 选出相关卡片后，读正文「核心观点」「工具」作为素材；卡片间的交叉引用（如「见卡片 001」）按需一并读取

引用规范：

  • 卡片核心观点是创作者本人的观点，可放心作为第一人称素材；但卡片头或正文标注了「打比方 / 非真实经历」的内容（如餐饮举例），不能写成创作者的真实客户经历
  • 卡片「更新记录」里的来源标注（口播/对话）在成稿时不引用
  • 与选题无关的卡片不强行使用；素材不足时明确告诉用户"卡片库里没有相关观点"

卡片库由配套的 thought-card 技能维护：一张卡片 = 一个观点，同一观点的后续增量会合并进已有卡片。

写作素材：调用创作者背景卡片

写文章/脚本前，还要到项目个人背景库匹配创作者真实经历素材（第一人称"我在场"的来源）（内容创作系统：00_个人背景/背景卡片/，其他项目按项目约定）。

匹配方法：

  1. 读 README.md 的卡片清单表，按「触发主题」与当前选题比对
  2. 命中 → 读卡片全文，取「事实」段作为第一人称素材、「观点」段作为立场依据
  3. 未命中任何卡片 → 不强行塞素材，宁可没有第一人称，不编造

边界（红线）：

  • 卡片「不适用」字段命中的选题 → 不读不写该素材
  • 卡片「使用边界」❌ 项 → 不得越过（金额量级、客户名、产品形态等以卡片「可写程度」为准）
  • 「观点」段重写为自己的话，不复用原句
  • 与创作者档案的素材边界规则一致：范围之外的一律不得以第一人称编造

写作素材：验证状态（写稿时逐条标注）

每个进入文章的论据、案例、数据，写稿时都要过一遍验证状态：

  • 已验证（创作者亲自操作过 / 亲身体验过 / 有真实来源）→ 正常使用
  • 未验证（听说的、二手转述的、还没亲自试过的）→ 不许直接写成定论，标注「⚠️ 待验证」，等创作者试完再定稿
  • 涉及企业 / 团队内容：没有拿到真实反馈之前，一律保持「⚠️ 待验证」
  • 高风险内容（含数据 / 企业名 / 人名 / 未证实观点）→ 标「⚠️ 待验证」，改稿时重点核查

定稿前必须处理所有「⚠️ 待验证」：创作者验证后转正，或者删除 / 弱化表述。带着待验证标就交稿 = 没定稿。

硬规则（必须遵守）

0. 先搭框架再落笔

商业文章先解决逻辑问题，再解决表达问题。拿到素材（案例、数据、引文）之后，不要直接开始写。先做五步：

第一步：压缩中心思想。 用一句话说清：这篇文章的对象是谁、核心判断是什么、读者看完能带走什么。

第二步：列出重要观点。 把文章要传递的判断列出来（3-5个），每个观点一句话。不要列"结构"（开头、中间、结尾），要列"判断"。

第三步：画出因果关系链。 观点之间的逻辑关系是什么？哪个是因、哪个是果？哪个是核心判断、哪个是支撑论据？哪个是例证、哪个是推论？把这条链画清楚。

第四步：逐段匹配。 每一段落的案例/论证，是否真正支撑了它对应的观点？案例放在这里，逻辑是否自洽？如果案例论证的是另一个观点，要么换案例，要么调整它所在的位置。

第五步：写完后自检。 开头的核心观点和第一个案例之间，逻辑是否自洽？有没有同一信息换说法重复两遍的段落？有就删一遍。

禁止：

  • 拿到一个案例就直接塞进文章，不管它论证了什么
  • 让观点去迁就案例（案例好但逻辑不对，就换案例，不要改观点去凑案例）
  • 用大词、模型、情绪词掩盖因果没想清楚
  • 写完后删一轮：只删重复信息的句子。语气、节奏、亲近感是句子的功能，不是冗余，不删

商业文章写作手艺规则见 references/business-writing-craft.md

1. 禁用夸张戏剧化表达

  • ❌ 词表对照："灾难的开始" / "致命的" / "毁灭性的" / "注定失败"（完整表见 references/banned-patterns.md 第一节；表里没有的词不自行扩大）
  • ✅ 用平实的因果描述写实际影响，不搬固定句式

2. 禁用伪经验开场

不要让 AI 假装有阅历。

  • ❌ "我见过太多人……" / "我遇到过太多案例……"
  • ✅ 要么用具体案例，要么不用这种引入

3. 禁用虚假统计

没有来源的数据不用。

  • ❌ "99% 的人目的是年薪百万"
  • ✅ 不确定的规模用模糊描述，不编具体数字
  • ✅ 必须用数字时注明来源；拿不到来源就不用数字

4. 不贬损目标读者

文章的读者是谁，就不能骂谁。

  • 失败 ≠ 人品有问题 ≠ 认知低
  • 很多时候是业态本身有结构性问题，不是人的问题
  • 贬损词表对照：韭菜 / 被收割 / 打鸡血 / 认知低（词表见 article-style-checker），出现即改

5. 分析拆到机制层

每个结论背后至少拆出 3 个具体作用机制，否则就是空话。

  • ❌ "村咖不赚钱，因为市场需求和产品不匹配"
  • ✅ 拆成：人口基数、季节性、座位数天花板、产品单一、消费场景缺失等具体原因

6. ~~用刻画代替宣告~~（已删除：被过度执行成"不能直接说感受和愿望"，抑制了真实情绪表达）

7. 封装一个可带走的判断工具

文章不能只让读者当下觉得"有道理"，还要让读者明天能用。

  • 把复杂推理压成一个朴素、可复用的判断维度或行动顺序
  • 概念必须来自现场问题，不能为了金句硬造词
  • 不复用外部文章里的原案例、原比喻、原概念命名

8. 结尾不用强行互动

结尾可以收束到具体判断、问题，也可以是自然的祝愿和号召。不用「评论区扣 1」「私信领取」「关注我」等强行互动话术。

9. 专业名词翻译成人话

遇到专业名词或连续列举多个工具能力时，先翻译成读者面对的实际问题，再用大白话解释；确有必要保留专业名词时，紧接一句说明它对读者意味着什么。

9a. 技术概念与事实准确

涉及技术概念、工具、术语时，先自查再落笔：

  • 概念定义与从属关系：工具与其所属类别不能错误并列（如「Claude Code + Harness」——Claude Code 本身就是 Harness 的一种，Harness 是上位类，两者不是同级）；上位/下位、包含/被包含关系写错即技术事实错误
  • 工具与产品名：名字写全写对（Claude Code、Cursor、DeepSeek 等），不张冠李戴、不写错别字；「XX 是 Harness」这类定性判断要准确
  • 技术逻辑：不写违背基本技术常识的组合（如把模型与工具、协议与产品错误混为一谈）
  • 拿不准就问：自己不确认的技术定性，宁可去掉或查证，不硬写

此类错误定级 P0，成稿检查时逐条核对（article-style-checker 快检第 5 类）。

10. 小标题不带数字编号

正文小节标题用纯文字，不带「一、」「二、」或「1.」「2.」编号——公众号排版模板会自动生成小节编号，源稿带编号会造成「01 一、」双重编号。

11. 材料不够就写短，不硬凑字数

动笔前先数材料。计划写到 1200 字以上的长稿，先逐条列出至少 5 件具体材料（创作者亲历、真实案例、可核数据、原话、具体动作与数字），并且这 5 件能串成一条实际过程。列不出 5 件，就先别写长稿：

  1. 有公开材料可查 → 先查，查完重新数
  2. 依赖创作者个人体验 → 追问创作者，一次最多 3 个问题
  3. 研究后仍不够 → 缩小题目，写 600 字左右的短稿，宁可明显短于目标字数

创作者只给了几条抽象想法（如「输入更方便」「能保留状态」）却要求长文时，先找真实材料，找不到就问，不让问就写短。不许用假例子、重复解释、把用途/意义/风险各写一遍的方式凑字数。

12. 讲完就停

写到事情已经讲完就停，不在末段重新摘要全文，不用大词硬升华。首尾呼应可以用，呼应开头的情感、号召、例子是自然的收尾；禁的是空喊时代意义。

详细禁用词对照表见 references/banned-patterns.md

风格要点

  1. 从"我在场"出发——交代为什么有资格说这件事，落到具体时间、场景、身份
  2. 先想清楚核心判断——对象、判断、读者收益要明确；但开头可以直接分享动机和过程，像跟朋友讲一件事，不用第一句就给结论
  3. 语气直接，允许粗粝感——像一个做过项目的人坐下来讲真话
  4. 翻译"认知问题"为"经营问题"——少讲抽象大词，多讲现场意味着什么
  5. 用刻画代替宣告——用动作、数字、对比、成本、后果推出判断
  6. 封装可复用工具——让读者带走一个判断维度、行动顺序或风险模型
  7. 建议能直接拿去试——给读者一个低风险的动作路径
  8. 多保留：第一人称场景、具体金额数字、经营调整过程、轻微口语
  9. 少一点：过度工整的长段总结、咨询腔。空泛升华、硬造金句的感受判断归创作者定稿时拍板，AI 不执行
  10. 说出来的话，不是写出来的话——句子允许长、允许口头语（其实/但是/吧）、允许自然铺陈，让读者感觉你坐在对面讲。大声念一遍，不像真人说话就改。详见 references/author-style.md 第 11 节
  11. 标题用完整句，不用关键词堆砌——小标题有动词、有宾语，像一句完整的话，不用"时间、地点、活动、卖点"式名词罗列。详见 references/author-style.md 第 12 节
  12. 写自己的东西要展开，人味优先于密度——介绍自己的系统、经历、观点时，用展开式："这里放我的人生经历、我的价值观、我的理想、我的愿景……所有我的个人背景信息都放在这里。"❌不用浓缩式："个人背景目录，AI 每次开工先读。"浓缩句是机器味，展开句是说话

详细风格规则与示例见 references/author-style.md

案例使用规范

  • 案例只是"其中一种情况"，明确说"这只是其中一种适合的人的样子"
  • 不把头部案例作为"所以你也能做到"的证据
  • 提头部案例时注明条件限制，不让读者产生不切实际的期待

政治与敏感话题

  • 不提政府、不提政绩、不提地方执政相关内容
  • 不做宏观政策判断
  • 聚焦商业逻辑、从业者选择、业态本身

写作前自检清单

写完后逐项检查，全部通过再交稿：

  1. 这篇文章的读者是谁？我有没有冒犯他们？
  2. 核心判断能不能用一句话说清？对象、判断、读者收益是否明确？
  3. 引用的数据有来源吗？
  4. 案例是"其中一种情况"还是"唯一答案"？
  5. 因果分析拆到机制层了吗？（至少 3 个具体原因）
  6. 有没有"灾难"、"致命"、"99%"、"太多人"这类禁用词？
  7. 有没有给读者一个能带走、能复用的判断工具？
  8. 读者看完后能不能立刻知道下一步该做什么？
  9. 是否误用了外部文章的原案例、原比喻、原概念或原句？如有，替换为自己的判断标准和现场材料。
  10. 有没有"几乎一样""绕不过去""根子"这类模糊对比收束、宿命宣告、土词硬造的表述？（完整对照表见 references/banned-patterns.md 第七节）
  11. 文章里的论据、案例、数据，有没有没验证过的？未验证的是否都标了「⚠️ 待验证」？
  12. 技术概念/术语/从属关系有没有错？（如把工具与其所属类别并列、工具名张冠李戴——见硬规则 9a）
  13. 每一段能不能指出它靠哪件材料站住？有没有哪段像模型在完成写作任务（说得比材料大、凭空举例）？

感受层面的判断归创作者

语言特征归 AI，感受归创作者。 AI 执行语言层面的规则（禁用词表、数据来源、句式结构、重复信息）；以下感受判断 AI 不执行、不做结论：

  • 这句话有没有感染力、读起来干不干
  • 这句号召算"硬造金句"还是真实兴奋
  • 开头留不留人、读者会不会想看下去

终稿前创作者通读，感受层面的取舍由创作者拍板。AI 交稿时不再评价"读感"，只报告语言层面的检查结果。

使用方式

手动调用：

/writing-style [文章类型] [目标读者]

参数说明：

  • 文章类型（可选）：劝退型 / 避坑型 / 对比型 / 行业观察 / 其他
  • 目标读者（可选）：经营者 / 从业者 / 创业者 / 其他

AI 自动触发： 当用户要求写作公众号、新媒体内容时，自动加载此风格规范，严格按此规范写作。

改稿协作回路（创作者给示范段落时）

创作者改稿时如果直接发来一段「应该长这样」的示范文字（例：「第 15 行，你应该这样说——」+ 示范段落），按此流程处理：

  1. 照着改：按示范段落的语言风格、节奏、转折方式重写目标内容——不是只修字词，是整段学它的说话方式
  2. 默认不提炼：示范段落用于当场学风格，不自行提炼成规则入库；提炼规则必须经创作者明确确认才写进本文件
  3. 改完必查：修改完成后按下方「写完后 / 改完后必须做」派 article-style-checker 复查

风格规范是活文档：每篇文章都可能更新它，更新后复查一遍有没有把话说死、说绝对。

小红书发布文案与话题词规则

生成终稿后，顺便在终稿下方生成「小红书正文描述 + 话题词」，正文 ≤1000 字、提炼要点、口语化，放在成稿同目录（如 <NNN-选题名>-小红书发布文案.md）。

话题词（tag）三原则：

  1. 只选和账号方向、内容直接相关的，不蹭无关热词——一个精准的长尾词，比三个不相关的大词更有用
  2. 数量 10 个；前 5 个权重最高，优先放核心词
  3. 搭配结构：
    • 1-2 个核心主标（账号方向的词，如 #AI工具测评）
    • 2-3 个垂直长尾词（更具体的，如 #AI写小红书文案）
    • 1 个时效/场景词（如 #2026自媒体入门）

格式：#+空格+标签关键词。

⚠️ 写完后 / 改完后必须做

每篇文章写完成稿后，或对已有文章做了实质性修改后，必须派 article-style-checker 做逐条合规检查（含技术事实错误检查：概念从属、术语、工具名），根据报告修复违规项。此步骤不可跳过。

简要流程：写完成稿（或修改完成） → 先跑机械检查脚本 python3 scripts/check_prose.py <成稿路径>（技能目录下），「需要修改」硬报错清零；「需要人工判断」项对照报告逐条过（口语冒号、语境词是否保留由创作者拍板） → 派 article-style-checker 检查 → 按报告逐条修复（修复时逐项对照报告清单，修复完成即自查确认）→ 交稿。不再单独派第二轮复查；创作者明确要求复查时才复查。

触发条件：

  • 新写一篇文章
  • 修改文章开头、结构、段落
  • 调整论点、论据、案例
  • 用户对文章内容提出修改意见后执行了修改

仅修改错别字、标点符号等微调可跳过。