关于 writing-assistant
面向中文文章写作的 skill，提供构思引导与审校打磨两种模式。通过逐题提问、分章节审校和等待确认，帮助作者保留对内容与修改的决定权。
主要功能
- 01构思与审校双模式
- 02按文章类型提供构思框架
- 03逐个问题引导写作
- 04六步文章审校流程
- 05按章节提出修改建议
- 06检查 Markdown 格式
适用场景
- 01从零构思游记或 TIL
- 02逐步整理通用文章草稿
- 03按章节检查已有中文文章
- 04运行 Markdown 格式检查
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/writing-assistant确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/chinese-style.mdpersonal-style.mdsource-verification.mdstructure-review.mdwriting-frameworks.md详细介绍
来自项目 README写作助手
写作助手，两种模式：构思引导（从零开始写）和审校打磨（改已有文章）。
前置条件
| 工具 | 类型 | 必需 | 安装方式 |
|---|---|---|---|
| markdownlint-cli2 | CLI | 否 | npx markdownlint-cli2，无需安装，用于审校步骤 6 |
| markdown-lint | skill | 否 | 可选，由独立的 developer-workflows plugin 提供 |
加载 skill 时不要主动检查这些工具。命令因缺少工具而失败时，再逐步引导完成安装和配置。
模式选择
| 用户意图 | 模式 | 章节 |
|---|---|---|
| 「不知道写什么」「帮我构思」「写游记」「记录 TIL」「写点什么」 | 构思 | 构思模式 |
| 「帮我改文章」「检查一下」「润色」「校对一下」「看看文章」 | 审校 | 审校模式 |
意图不明确时，先询问用户。
构思模式
帮助用户在不知道写什么或如何写下去时，通过启发式提问引导写作。
核心原则
| 原则 | 说明 |
|---|---|
| 一次一个问题 | 先设计问题清单，再逐个提问 |
| 确认后继续 | 用户思考 → 写作 → 修改 → 确认 → 下一个问题 |
| 启发而非代写 | 用问题激发思考，不替用户决定内容方向 |
文章类型判断
| 用户意图 | 类型 | 框架 |
|---|---|---|
| 「写游记」「记录旅行」 | 游记 | 出发 → 过程 → 回望 |
| 「记录 TIL」「今天学到」 | TIL | 背景 → 过程 → 方案 → 收获 |
| 「写点什么」「帮我构思」 | 通用文章 | 触发点 → 观点 → 展开 → 收束 |
流程
判断文章类型 → 列出引导问题 → 逐个提问 → 用户回答 → 确认 → 下一题 → 整理成文
提问节奏
Claude: "Why did you want to visit this place?"
User: [writes answer]
Claude: [confirm/follow-up] -> "OK, next question: what was the first thing you saw when you arrived?"
写作框架
每种类型都有对应的文章结构和引导问题。完整内容见 writing-frameworks.md。
草稿完成后，建议切换到审校模式。
审校模式
文章审校，提供 6 步审校流程，帮助打磨中文文章。
核心原则
| 原则 | 说明 |
|---|---|
| 先讨论再修改 | 提出修改建议供用户选择，不直接改动 |
| 按章节审校 | 以 Markdown 标题为检查点，每次处理 1～2 个章节 |
| 启发而非决定 | 用问题引导内容，不替用户作决定 |
六步审校流程
1. 结构 → 2. 读者语境 → 3. 语言 → 4. 来源核验 → 5. 风格 → 6. Markdown 格式
步骤 1：结构诊断
目标：确保结构清晰、主题集中。
- 拆分段落并识别主题。
- 提出 2～3 种重组方案，先讨论再修改。
- 将删除的内容移入独立的
material.md文件。
步骤 2：读者语境检查
核心问题：「读者会在这里感到困惑吗？」
| 问题 | 表现 | 处理方式 |
|---|---|---|
| 背景假设 | 使用术语或缩写但没有解释 | 补充说明或脚注 |
| 自我指涉 | 使用「就像那个……」但不解释 | 改成具体描述 |
| 逻辑跳跃 | 从 A 直接跳到 C | 补充过渡说明 |
| 情绪缺少铺垫 | 使用「实在太……」但没有上下文 | 先补充背景 |
| 信息缺口 | 默认读者知道前因后果 | 简要补充背景 |
步骤 3：语言规范
参考余光中的《怎样改进英式中文？》：
| 问题 | 示例 |
|---|---|
| 抽象名词作主语 | 差：收入的减少改变了生活 → 好：他因为收入减少而改变生活 |
| 冗长表达 | 差：基于这个原因 → 好：因此 |
| 弱动词 | 差：作出贡献 → 好：贡献 |
| 介词堆叠 | 减少连接词的过度使用 |
| 滥用被动语态 | 差：问题被解决了 → 好：问题解决了 |
参见 chinese-style.md。
步骤 4：来源核验
来源优先级：政府官方来源 > 权威媒体 > 行业媒体 > 尽量避免个人博客。
节奏：核验一条 → 讨论 → 写入一条 → 确认 → 下一条。
步骤 5：风格一致性
按个人写作风格检查：
| 检查项 | 说明 |
|---|---|
| 标志性表达 | 「怎么说呢」「其实」「有点……」 |
| 语气 | 自嘲式开头、括号内评论 |
| 量化 | 使用具体数字增强说服力 |
| 克制加粗 | 每个标题章节最多加粗 3 处 |
避免：
- 「不是 X……而是 Y……」句式，AI 痕迹明显。
- 使用引号包装的「幽默」比喻。
- 以 Emoji 或编号列表开篇。
- 频繁使用破折号。
- 使用
---水平分隔线；改用标题或数字自然过渡。
步骤 6：Markdown 格式
npx markdownlint-cli2 article.md # Check
npx markdownlint-cli2 --fix article.md # Auto-fix
额外人工检查：
- 标题层级合理，H2 到 H3 之间不跳级。
- 列表格式一致，统一使用
-或*。 - 代码块带有语言标签。
审校节奏
1. 读取当前章节。
2. 按六个步骤检查。
3. 提出建议，不直接修改。
4. 等待用户确认。
5. 确认后进入下一章节。
关键规则：每个章节审校后都要等待用户确认。
写作风格速查
| 要素 | 要求 |
|---|---|
| 语言 | 口语化，像与朋友交谈 |
| 段落 | 每段只表达一个主题 |
| 加粗 | 只用于重要转折和观点，每节最多 3 处 |
| 数据 | 融入经历叙述，详细来源放入脚注 |
| 诚实 | 承认信息缺口，标记未完成内容，保留思考过程 |
详细参考
- writing-frameworks.md：游记、TIL 和通用文章的构思框架
- chinese-style.md：中文语言规范
- structure-review.md：结构诊断和读者语境
- source-verification.md：来源核验和脚注
- personal-style.md：个人风格指南
评论
支持 Markdown