写作与内容创作

Claude Code 名字里带 Code，但它并不是只能写代码。它能读你的代码、看你已有的文风、按你要求的语气产出内容。

如果你是个技术人，日常里除了代码，还有另一批文字工作。README、API 文档、迁移指南、博客、技术分享稿、视频脚本、面向国际化的翻译。这些文字工作看起来轻，但真做起来时间成本一点不比写代码低。Claude Code 恰好能覆盖这些场景，而且因为它能读源码，它写出来的文档往往比你直接给一个纯语言模型让它写要准确得多。

场景一：写文档

假设你有一个 CLI 工具，功能齐全但完全没有 README。传统做法是你自己翻 src/cli.ts，把所有子命令抄一遍，再写用法示例。让 Claude Code 干。

> 帮我写 README.md：
> 1. 读 src/cli.ts 和 src/commands/ 目录，把所有子命令和参数列出来
> 2. 结构包括：项目一句话介绍、安装、快速开始、命令详解、配置文件、常见问题
> 3. 每个命令给一个真实场景的用法示例，不要写 foo bar 这种占位
> 4. 语气参考 https://github.com/vercel/turbo 的 README，简洁但不冷
> 5. 不写 emoji，不用 badge shield，先出内容

Claude Code 会先把命令目录扫一遍，把每个 .command() 定义提取出来，然后按你指定的结构写。因为它能读到真实的参数名和默认值，不会出现文档里的命令跟代码不一致的情况。

API 文档也是类似的思路。让它读一份 Express 或 FastAPI 的路由文件，输出 OpenAPI 3.1 的 YAML。让它读 SDK 的类型定义，输出 markdown 版本的方法参考。让它扫一份 migration，输出一份人类可读的迁移指南。

让它顺手加检查

文档最容易过时。让 Claude Code 在写 README 的同时加一个 scripts/check-readme-sync.ts，用来在 CI 里检测 CLI 帮助文本和 README 有没有对齐。这个思路可以推广到所有从代码生成的文档。

场景二：写博客和技术教程

你手上就在读的这套教程，就是让 Claude Code 参与写的。方法很简单，先在 CLAUDE.md 里写清楚语气和边界。

markdown

## 写作规范

- 目标读者：有基础编程经验的中文开发者
- 语气：像同事之间讨论，不要客气废话
- 结构：每章开头一段介绍问题，中间举一个真实场景，结尾给经验
- 长度：单页 1500 到 2000 字，不要写成大段口水
- 术语：技术名词英文原文，前后加空格，例如 React、TypeScript
- 禁止：emoji、感叹号泛滥、"值得一提的是"这种填充句
- 例子：贴代码用 fenced code，标语言，注释用中文

有了这份规范之后，你写 prompt 就非常简单。

> 写一篇讲 useEffect 依赖数组常见坑的博客，遵循 CLAUDE.md 里的写作规范。
> 结构：现象、原因、四种典型踩坑场景、解决方案对照表。
> 每个场景配一段简短代码示例。目标读者是有 React 基础的开发者。

它会自动按你的规范产出内容。写完之后你可以让它自评，检查一下有没有违反规范。

> 对照 CLAUDE.md 的写作规范，检查刚才那篇博客有没有踩雷，列出所有违反项

这一步的价值不在于它挑出问题的能力有多强，而在于它逼你把自己的写作规范显式写下来。写出来的规范之后可以用在所有博客上，越用越准。

场景三：视频脚本和播客大纲

技术 UP 主写脚本最难的是控制节奏。观众的注意力就那么几秒，任何啰嗦都会被划走。让 Claude Code 帮你压缩。

> 我要做一期 8 分钟的短视频，主题是"为什么你的 Claude Code 上下文越来越差"。
> 请写一版分镜脚本，结构如下：
> - 0 到 15 秒：钩子，直击痛点
> - 15 到 90 秒：用一个具体案例展示问题
> - 90 到 300 秒：讲清楚三个根本原因
> - 300 到 420 秒：给三个可以立即执行的动作
> - 420 到 480 秒：结尾行动召唤
> 每一段给出旁白、画面描述、屏幕录制内容。语气口语化，避免书面语。

它给出的初稿一般还需要你手改，但结构和节奏它能帮你搭好。播客大纲思路相同，只是把画面替换成对话主题和讨论问题列表。

场景四：技术文档中英互译

技术翻译的核心难点是术语一致性。同一个 word 在整篇文档里不能一会儿翻成 A 一会儿翻成 B。让 Claude Code 建一份术语表再翻译。

> 帮我翻译 docs/en 目录下所有 md 文件到 docs/zh。步骤：
> 1. 先扫一遍所有英文文档，抽取技术术语，输出 docs/glossary.md，
>    格式是英文术语、中文翻译、说明
> 2. 术语原则：能保留英文的保留英文（React、useState、middleware 等），
>    有约定俗成中文翻译的用中文（例如 dependency injection 翻成依赖注入）
> 3. 翻译时严格按照 glossary.md 里的对照关系
> 4. 保留原文的 markdown 结构、代码块、链接，不要动
> 5. 翻译语气参考项目里已有的 docs/zh/intro.md

有了术语表这一步再翻译，一致性会显著提升。glossary.md 会成为一份长期资产，后续新增文档翻译时直接复用即可。

反向从中文翻到英文思路完全一样。一个小 trick 是让它每翻一段先用英文简要复述一遍原文的核心含义，确认理解没问题再翻译。这样比直译更能保留原文的技术意图。

用 CLAUDE.md 锁定你的语气

写作场景里 CLAUDE.md 的价值被放大得最明显。因为写代码有客观标准，写作没有，你的语气偏好只能靠显式规范传递。

推荐在 CLAUDE.md 里放三件东西。

写作原则清单，就是上面那种硬红线。每一条越具体越好，例如"不用值得一提的是这类填充句"就比"语言要简洁"有用。
样本段落，从你过去写得好的博客里挑两三段贴进来。Claude Code 会主动模仿这些样本的句式和节奏，效果比抽象规则更立竿见影。
禁用词汇表，把你讨厌的 AI 味词汇列出来，例如"深入浅出"、"探索"、"共同学习"、"让我们一起"。它会在生成时主动绕开。

样本段落的威力

只给两段真实样本，比写一整页抽象规则更能改变输出风格。人类的写作特征太复杂，规则很难穷举，但样本会带出你的完整语感。

一点提醒

写作场景里最容易踩的坑是让 Claude Code 一口气写太长。它非常擅长把简单话说得很饱满，你若不设字数上限，很容易收到一份"看起来很有道理但没啥营养"的稿子。养成 prompt 里必写字数上限的习惯，一般来说单节 800 到 1500 字最好。

另一个坑是完全不改就发。Claude Code 是一个非常出色的初稿助手，但初稿不等于终稿。至少通读一遍，把不像你说话的句子改回自己的语气。读者最终能感受到那些细节，那也是内容的价值所在。

写作与内容创作 ​

场景一：写文档 ​

场景二：写博客和技术教程 ​

场景三：视频脚本和播客大纲 ​

场景四：技术文档中英互译 ​

用 CLAUDE.md 锁定你的语气 ​