让 AI 写一篇技术文章，给出主题通常就能得到初稿。难的是接下来的修改。
有时例子太空，需要补上具体场景；有时结论很明确，理由却没有展开；有时只是想润色一段文字，结果连原来的技术约束都被改掉了。换一个主题，又得重新解释一遍：面向谁写、怎样组织内容、哪些东西要保留、哪些经历不能编造。
这些要求如果只留在对话里，很难继续维护。更合适的做法，是把经常重复的部分整理成文件，让下一次写作直接沿用，再根据真实修改逐步调整。
personal-writing 就是这样一个中文技术写作 Skill。它覆盖主题写作、草稿润色、文章配图和风格校准，目标是让写作要求可以复用，也可以被检查和修改。
先把任务说清楚，再让规则发挥作用
一篇教程、一篇工具介绍和一篇技术观点文章，需要的组织方式不同。
教程需要交代操作条件、步骤和验证结果。工具介绍需要说明它解决什么问题，适合什么场景，有哪些限制。观点文章则要让判断、理由和例子连起来。如果把它们都套进同一组小标题，形式可能整齐，读者却不容易找到真正需要的信息。
personal-writing 会先根据请求判断任务，再选择相应的写法。它的主要能力可以分成四类：
| 任务 | 需要提供什么 | 交付什么 |
|---|---|---|
| 主题写作 | 主题、读者、素材和篇幅要求 | 一篇 Markdown 文章 |
| 草稿润色 | 原稿和希望解决的问题 | 完整改写稿，或按要求修改原文件 |
| 文章配图 | 正文、配图目标和资源目录 | 经过检查的图片及图文稿 |
| 风格校准 | 初稿、修改稿或亲笔样本 | 有依据的风格规则和表达示例 |
普通写作不会自动添加图片，也不会顺手更新你的风格规则。只想要建议、只想规划配图，或者希望直接改文件，都可以在请求里说清楚。
例如，写一篇新文章可以这样开始：
$personal-writing
写一篇关于“程序员为什么需要理解业务指标”的技术博客。
读者是有两年工作经验的开发者，约1500字。
用一个具体场景展开，给出日常工作中可以练习的方法。已有草稿时，修改目标越具体，越容易判断结果是否符合预期：
$personal-writing
润色 docs/article.md。
保留原意、代码和链接，减少重复表达，把论证不清楚的地方讲清楚。
直接修改这个文件。这里的区别很实际。“写得更好”没有检查对象，而“保留代码，补上这一段的因果解释”可以直接对照修改结果。
把执行流程和表达习惯分开
这个项目的目录很小，主要维护对象是规则和例子：
personal-writing/
├── SKILL.md
├── agents/
│ └── openai.yaml
└── references/
├── style-guide.md
├── examples.md
├── article-images.md
└── calibration-draft.mdSKILL.md 定义如何选择任务、如何执行，以及什么情况下算完成。style-guide.md 管用词、句式、结构和语气。examples.md 用短例子说明规则怎样进入具体表达。配图的细节放在 article-images.md，需要配图时再读取；练习稿用于后续校准。
这样拆分，是因为执行要求和表达习惯的变化方式不同。
“润色时保留代码和原意”是执行要求。“关键判断用短句，随后用完整段落解释”是表达习惯。想调整后者，修改风格指南就够了，不必重写整个工作流程。
当前默认规则强调直接表达、完整解释、具体场景和适用条件。它们可以帮助第一版起步，但还不能代表使用者的稳定个人风格。没有个人样本时可以先写；有了修改稿，再逐步校准。
规则也需要留出文章类型的空间。短评删掉小标题可能更自然，操作教程仍然需要清楚的步骤。一个场景里有效的修改，不能自动变成所有文章都要遵守的要求。
配图要解释内容，也要真正进入文章
技术文章里，有些信息画出来会更容易理解：文件之间的关系、多步操作的顺序，或者一次修改如何进入下一轮写作。
配图前先判断它要解释什么。单纯增加装饰，未必值得插入一张图；能帮助读者理解复杂关系的图，才有明确作用。
personal-writing 的配图流程会记录插入位置、图片目的、形式、文件名、提示词和完成状态。生成或绘制之后，还要检查画面，再保存到文章能够引用的资源目录，最后插入 Markdown。
$personal-writing
给 docs/article.md 配图并插入 Markdown。
优先解释抽象关系和主要流程，使用浅色背景与克制配色。
图片保存到 docs/article-images/。这一步有两个容易混淆的地方。
首先，写好了提示词，还没有生成图片。其次，图片文件存在，也不意味着网站已经能显示它。文件需要进入实际发布的资源目录，引用路径要正确，正文中的位置也要对应它解释的内容。
图片形式由用途决定。照片和概念插画需要实际可用的位图生图工具；有精确箭头、层级和中文标签的流程图，可以用 SVG 或 Mermaid 绘制。本篇使用的是可编辑的 SVG 图解，头图另导出为 PNG，便于博客展示与分享。
仓库本身没有模型或 API 服务。位图生成依赖当前环境中可用的 imagegen 技能与工具；安装写作 Skill，并不会自动获得生图能力。工具不可用时，应保留配图计划与提示词，明确哪些图片没有完成。
让修改稿成为下一篇文章的依据
风格校准最有价值的输入，是一篇文章具体改了什么。
假设初稿里有一句：“这项优化显著提升了系统性能。”修改时，你把它改成：“先记录接口响应时间，再用相同请求比较优化前后的结果。”这次变化可能反映了两件事：原来的效果判断没有证据；表达上更倾向于先说清检查动作。
两者需要分开处理。前者是事实与论证问题，后者才可能成为可复用的表达偏好。如果把事实更正全部记成风格要求，规则会越来越杂，后续写作也更容易偏离主题。
可以用这样的请求启动比较：
$personal-writing
比较 drafts/original.md 和 drafts/revised.md。
区分事实更正、内容调整和表达偏好。
为每项风格发现给出修改前后例子、适用场景和证据强度。
把有依据的发现更新到这个 Skill 的风格指南和典型示例。一次修改说明的是一次选择。明确表达的偏好可以直接采用；多篇独立样本里反复出现的选择，才更适合整理为稳定规则。更新后换一个主题再写，看看规则是否仍然有用。
个人经历也遵循同样的依据要求。“我建议”可以表达立场，“我做过”“我测试过”则需要真实材料。为了让文章自然，不能补上一段从未发生的经历，也不能把建议写成已经验证的结果。
从安装和一篇短文开始
在支持 Skills 的 Codex 环境里，可以把整个仓库克隆到用户级 Skills 目录。项目本身没有需要额外安装的 npm、pnpm 或 Python 依赖：
mkdir -p "$HOME/.agents/skills"
git clone https://github.com/moxiaonai/personal-writing.git \
"$HOME/.agents/skills/personal-writing"如果这个路径已经存在，先确认它是仓库、普通目录还是符号链接，保留已有校准内容后再处理。安装后在新对话中调用 $personal-writing；如果客户端尚未发现，重启后再检查。
通过 Git 克隆安装的版本可以这样更新：
git -C "$HOME/.agents/skills/personal-writing" pull --ff-only已经修改过规则时，更新前先检查本地差异。私人原稿和工作资料可以留在仓库外；公开分享时，保留抽象规则和无敏感信息的简短例子即可。.gitignore 能帮助排除本地文件，但不能代替内容检查。
开始使用时，不必先完善所有规则。选一个熟悉的主题，生成一篇短文，亲自修改最不满意的段落，再比较前后的变化。一次明确的修改，比追加十条笼统的“写得自然一点”更容易继续维护。
personal-writing 要积累的，就是这些具体选择：哪些解释需要展开，哪些事实需要核实，哪些表达适合当前读者，以及怎样确认文章已经完成。让它们进入下一次写作，Skill 才开始发挥持续的作用。
项目地址：github.com/moxiaonai/personal-writing。完整规则与使用说明都在仓库中，可以按自己的写作需求调整。