现在用 AI 帮着写代码，确实越来越顺手了。

给个大概的想法，它几分钟就能搭出框架、补齐测试，页面也能直接跑起来。不过很多时候，真正的麻烦反而是功能写完之后才冒出来的：

README 往往还是刚创建项目时的默认模板，启动命令换了也没人更新；随手跑一下 git status，里面堆满了新增功能、临时调试文件、还没写完的代码和测试生成物。要是图省事直接来一句 git add . && git commit -m "fix"，后面的提交历史很快就会乱成一团，回过头查问题会很费劲。

代码能跑了，我却还得回头对文档、检查 Git 改动，再想一条提交说明。这些事不难，就是每次都要做，很容易拖着不管。我做这两个 skill，也是想省掉这份重复劳动：既然代码是让 AI 帮忙写的，收尾也一并交给它。

good-readme：改了项目，也看看文档

很多小项目的 README 都有类似的问题：刚建仓库时写得挺认真，后面加着加着功能，就再也没人去管它了。

新功能早就加上了，文档里还在讲老版本；启动方式改了，文档里贴的命令拷下来根本跑不通；要是加了新的配置项或依赖，别人就只能自己去翻代码猜。哪怕是自己做着玩的小项目，过两周回来看也容易犯迷糊；要是公开分享给别人，大家试一下跑不通大概率也就直接关掉了。

good-readme 做的事很直接：AI 改完项目，先别急着结束，回头看一眼 README。无论动的是代码、配置、依赖、测试还是资源文件，都要判断一下，文档里的说明还对不对得上。

检查下来通常就是三种情况：

  • 如果仓库里还没有 README，就根据项目现有的实际内容整理一份出来；

  • 功能、安装步骤、配置、启动命令或目录结构变了，就更新对应的说明；

  • 要是这次只是内部改改格式、做点不影响使用方式的重构，它就会明确说明不需要修改文档。

我不希望它每次都为了交差改几行文档。改了启动命令，就把新命令写进去；只是调整内部代码，没影响使用，说明无需修改就够了。README 里写到的功能和命令要有依据，也不能替项目编一份还不存在的路线图。

它还会把中英文放在同一个 README.md 里，在顶部提供语言入口。两边的命令、链接、版本和功能状态都要对得上，免得读中文版能运行，换成英文版却照着旧说明折腾半天。

Gitwork：这次到底该提交什么

对刚接触 Git 的朋友来说，难点往往不是记不住那几条常用命令，而是容易搞不清楚“这次到底该提交什么”。

比如你让 AI 修一个登录问题，但本地其实还有你自己没写完的页面草稿，AI 跑测试时又生成了一堆临时缓存。要是最后图省事直接一股脑 git add .，这些杂七杂八的文件就全被混进了一个提交里。提交虽然成功了，但历史记录变得很杂乱，甚至可能不小心把本地环境变量或敏感信息也打包带进去了。

所以我给 Gitwork 定的第一条要求，就是先分清哪些改动属于这次任务。

它会在动手前记下仓库状态。你原来已经暂存的、改了一半还没暂存的，以及新建但尚未被 Git 跟踪的文件，都要保留。等这次任务做完、验证通过，再对照前后的差异，挑出本次修改的文件或代码片段，检查 diff 后提交。提交说明也要让人看得懂，比如：

feat: 添加批量导出功能
fix: 修复登录状态丢失问题
docs: 更新安装与使用说明

项目还没用上 Git 的话，它可以在确认项目范围后初始化仓库，并先检查 .gitignore。依赖、缓存、构建产物、环境文件和异常大文件，都不该未经检查就进入版本历史。

有些动作我不让它自动做：push 到远端、跳过 Git hooks、修改已有提交。遇到没处理完的 merge 或 rebase，它也不能硬提交。至于这次改动和你之前的工作混在一起、实在分不开的情况，就先不提交，把原因讲清楚。

我希望过几周再翻到一条提交时，还能知道当时改了什么。为了省几秒钟把不相干的东西全塞进去，后面找问题反而更费时间。

两个一起用会怎样

两个 skill 可以分开用。不过，如果文档更新完却漏进了提交，收尾还是差了一步，所以我更推荐一起装。

比如，你给 AI 提了这样一个需求：

给这个项目增加用户头像上传功能。

代码写完也验证过之后，good-readme 会先看一下新功能有没有改变用法、配置、依赖或目录结构。如果需要更新文档，就顺手同步到 README；要是确实不需要动，也会简单说明原因。

然后轮到 Gitwork。它对照任务开始前的状态，把头像上传相关的代码和刚更新的文档挑出来，排除测试生成物和无关修改，检查差异后再提交。

把顺序画出来，就是这样：

提出需求
  ↓
AI 修改项目并完成验证
  ↓
good-readme 检查文档是否需要同步
  ↓
Gitwork 隔离并提交本次任务变更
  ↓
得到代码、文档和 Git 历史一致的项目状态

这也是我把两个步骤写成 skill 的原因。每次提需求，都要再补一句“记得更新文档、只提交这次的改动”，很容易忘。把要求固定下来，至少不用从头交代一遍。

怎么安装

两个仓库里都写了安装方法。用 Codex 的话，可以直接把下面这段话发给它，让它通过 skill-installer 安装。装好后重启 Codex，再确认新 skill 已经加载。

安装 good-readme：

请使用 skill-installer 从下面的仓库安装 good-readme，
安装完成后检查 SKILL.md、agents、references 和 scripts 是否完整，并提醒我重启 Codex：
https://github.com/Niall-Young/good-readme

安装 Gitwork：

请使用 skill-installer 从下面的地址安装 gitwork，并在完成后提醒我重启 Codex：
https://github.com/Niall-Young/Gitwork/tree/main/gitwork

之后照常让 Codex 写功能、修 Bug 或做重构就行。符合触发条件时，它会按 skill 的要求收尾，不必每次点名。你也可以把要求写得更明确一些：

完成后使用 good-readme 检查项目文档，再使用 Gitwork 只提交本次任务的改动。

这里要说明一下：skill 是 Codex 做任务时遵循的规则，并不是装好后就一直在后台运行的程序。它仍然需要由 AI 读取和执行，不能把“已经安装”当成“每次一定做到了”。

装好以后，看一次收尾结果

刚开始用，可以先看一次完整的收尾结果：这次 README 改了哪里，为什么改；提交说明写了什么，留下了哪些未提交的内容。不用把所有 Git 命令背下来，也能先看懂 AI 做了哪些事。

如果它说无需更新文档，看看理由是否说得通。如果它没有提交，也先看原因。尤其是项目里还放着自己没写完的代码时，能保留那些改动，比得到一条“提交成功”的回复更重要。

这两个 skill 想替我省下的，就是每次写完功能后这点重复的整理工作。文档跟得上，提交能看懂，下次再打开项目时，就少一点猜测。