把项目记录写成博客 我的写作 Skill

最近把青蟹大创里的 LightRAG、DPO 和微调过程整理成博客，我发现最容易重复的工作是：从一大段开发记录里找到真正有用的步骤，核对数字，再判断哪些坑值得写出来。

我把这个过程整理成一个小技能，叫 project-blog-writer，已公开在 GitHub 仓库。以后写项目博客，可以明确调用它，再提供对应代码、日志或会话。目标是减少每次重新说明写作要求的时间，保留实践文章该有的细节。

1 为什么把写作要求做成 Skill

给模型一句「写得专业一点」，很容易得到一篇看起来完整、却没有实际操作依据的文章。我的项目记录里，经常同时存在建议、尝试、失败和最后成功的版本，不先分清这些，文章就会把计划写成结果。

比如 DPO 小测生成了 9 个候选答案，但人工提交还没完成，就不能写成「已构建高质量偏好数据集」。青蟹微调跑完 381 步、验证损失下降，也不能直接说问答准确率提升了多少。

这个 skill 先要求找证据，再组织文章。数字要带日期和统计范围，项目自定义脚本要明确标出，不能把本地工具说成官方安装后就有的命令。

2 仓库里其实很简单

skills/project-blog-writer/
├── SKILL.md
├── agents/openai.yaml
└── references/publishing.md

SKILL.md 是主要流程：读取指定资料、提炼主线、写实用正文、检查后交付。agents/openai.yaml 提供中文显示名称和默认提示。只有用户要求发布时，才按需读取发布参考。

这种结构遵循技能的文件约定：名称和描述用于识别用途，正文给出步骤，附加资料按需读取。OpenAI 技能说明

它没有额外模型服务，也没有独立的网站后台。能读取哪些资料、能发布到哪里，取决于当前会话已有的工具和权限。

3 我希望它怎么写文章

一篇使用指南，要让读者知道在哪里操作、应看到什么结果；一篇排错记录，要交代现象、原因、改法和验证。结构跟主题走，不要求每篇都套一样的目录。

我更希望保留少量关键细节：为什么选择 2048 而不是 4096，为什么先固定检索证据再比较答案，为什么图像问答要逐图审核。这些能解释判断，比把每条命令和聊天记录全贴出来更有用。

口吻也尽量接近学生的项目笔记：可以写自己哪里理解错了、后来怎么验证，但不能凭空补一个跌宕起伏的故事。没有跑过的配置写成示例，准备做的评估写成下一步。

4 安装和调用

仓库 README 提供了 Windows 的复制命令。把 skills/project-blog-writer 整个目录放入用户的 ~/.codex/skills/，Windows 默认对应 %USERPROFILE%\.codex\skills\；已有同名目录时先比较内容，避免覆盖自己的修改。目录与调用方式参考 OpenAI 本地技能实践。

在能够识别该技能的会话中，可以这样说：

使用 $project-blog-writer，读取我的青蟹项目微调记录，
从 Easy Dataset 制作数据集开始写一篇实践博客。
保留有依据的样本数量、训练参数和验证结果，
说明哪些是实际完成的步骤，哪些是后续计划。

如果想发布，再明确提供目标网站或仓库。只要求撰写时，skill 交付正文；要求发布时，沿用现有 CMS 或项目发布方式，检查列表入口、图片、代码和实际地址。

5 我会怎样继续改它

第一版是指令型技能，已做文件结构校验，暂时没有独立脚本和系统效果评测。我不想一开始把它做成一整套复杂平台，而是用不同文章检验：资料不足时会不会编指标，写安装步骤时能否说清前提，发布以后能否真的打开页面。

下一步可以拿同一份项目记录，比较普通写作提示和这个 skill 的草稿，再人工检查事实、步骤和可读性。现在还没有这组对照结果，因此不写「效率提升多少」。

对我来说，值得固化的是自己的检查习惯：写清做过什么，保留有用的数字，让下一次回来看的人能够继续操作。欢迎从 project-blog-writer 下载并按自己的博客风格修改。