现在用 AI 做一个项目，已经很快了。

你告诉它想做什么，它可以帮你搭目录、写代码、改 Bug，甚至顺手把测试也补上。可项目做完之后，经常会留下另一幅场面：README 还是初始化时的内容，新增的功能没有说明，git status 里堆着一长串文件，几个不相干的改动混在一起，也不知道该怎么提交。

代码能跑，但项目看起来还是很“野生”。

我最近做了两个 skill，专门处理这类事情：

  • good-readme：负责检查、创建和更新项目的 README。

  • Gitwork：负责在任务完成后安全地整理并提交 Git 变更。

做它们的原因其实很简单：我懒得弄。

每次功能写完，我都不想再回头整理文档，也不想自己检查改了哪些文件、哪些该提交、commit message 应该怎么写。所以我干脆把这两件事写成规则，交给 AI 在每次开发任务结束时自动收尾。

后来我发现，这两个 skill 对新手可能更有用。因为很多刚开始用 AI 做项目的人，并不是故意不规范，而是根本不知道 README 应该什么时候更新，也不知道 Git 除了“保存代码”之外，还需要管理改动边界、提交粒度和历史记录。

装上这两个 skill，相当于给 AI 补了两个默认动作：项目变了，先检查文档；任务做完，再整理提交。

从杂乱项目到代码、README 和 Git 提交整齐一致 fantuan-illustration-01.png 从杂乱项目到代码、README 和 Git 提交整齐一致 fantuan-illustration-01.png

good-readme：让文档跟着项目一起变

很多项目的 README 都有一个共同的问题：刚创建时写得很认真，后面就再也没有更新过。

项目已经加了新功能，README 还在介绍旧版本；启动命令变了，文档里的命令仍然跑不通；新增了环境变量、依赖或配置，使用者只能自己翻代码猜。对个人项目来说，这会让几周后的自己看不懂；对公开项目来说，别人打开仓库的第一分钟就可能被劝退。

good-readme 做的并不只是“让 AI 生成一份 README”。它更像一个任务结束前的文档门禁：只要本轮修改了代码、配置、资源、依赖、测试或其他项目文件，AI 就必须判断这次变化是否影响 README。

good-readme 根据项目证据判断是否更新 README fantuan-illustration-02.png good-readme 根据项目证据判断是否更新 README fantuan-illustration-02.png

最终只有三种结果：

  • 项目没有 README，就根据仓库里的真实内容创建一份；

  • 功能、安装方式、配置、命令或项目结构发生了变化，就同步更新；

  • 这次只是内部重构、格式调整等，不影响文档里的事实，就明确说明无需修改。

这里我很在意的一点是：它不能为了“完成任务”而机械改文档。README 里的内容要能从项目中找到依据，不能发明不存在的功能、命令和路线图。更新时也只改真正受影响的部分，不需要每次都把整篇重写一遍。

目前它还会把中文和英文放在同一个 README.md 里，通过顶部的语言入口切换，并检查两边的命令、链接、版本和功能状态是否一致。这样至少不会出现中文已经更新到新版本，英文还停留在半年前的情况。

Gitwork：替你把这次任务收干净

Git 对新手最不友好的地方，是它看起来只需要记住几条命令，真正麻烦的却是“应该提交什么”。

比如你让 AI 修一个登录 Bug，但工作区里本来还有自己没写完的页面；AI 运行测试时又生成了一些缓存和构建产物。如果它最后直接执行 git add .，这些东西很容易被一起塞进同一个 commit。提交虽然成功了，历史却变得很难读，甚至可能把环境文件、密钥或本地垃圾也传进去。

Gitwork 的重点不是自动执行 Git 命令，而是先弄清楚这次任务到底改了什么。

Gitwork 保护原有改动并只提交本次任务 fantuan-illustration-03.png Gitwork 保护原有改动并只提交本次任务 fantuan-illustration-03.png

它会在开始工作前记录仓库状态，保留用户原来已经暂存、未暂存和未跟踪的内容。任务完成并验证后，再对比前后的差异，只选择本次任务产生的文件或代码块进行提交。提交信息统一使用下面这种形式：

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

如果当前目录还没有 Git，它可以在确认项目边界后初始化仓库，并先检查 .gitignore，避免把依赖、缓存、构建产物、环境文件或异常的大文件放进版本历史。

但它也有意保留了一些限制：不会自动 push，不会跳过 Git hooks，不会修改已有提交，也不会在 merge、rebase 等未解决状态下强行创建新 commit。如果这次改动和用户原来的改动混在一起，无法安全拆开，它宁可不提交，也会把原因说清楚。

我觉得这才是 Git 自动化真正该有的样子。快当然重要，但不能为了省十秒钟，把仓库变成一个以后没人敢碰的黑盒。

两个 skill 连起来，才是一套完整的收尾流程

这两个 skill 单独使用都可以，但我更推荐一起装。

需求、开发验证、文档门禁与安全提交的完整工作流 fantuan-illustration-04.png 需求、开发验证、文档门禁与安全提交的完整工作流 fantuan-illustration-04.png

假设你对 AI 说：

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

AI 完成代码和验证之后，good-readme 会先判断新功能是否改变了使用方式、配置、依赖或项目结构。如果需要，就把对应说明同步进 README；如果不需要，也会给出不修改的理由。

文档检查完成后，Gitwork 再根据任务开始前的状态整理变更，排除本地生成物和无关修改，检查 diff，最后只提交这次头像上传功能相关的内容。

整个过程大致变成：

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

以前这些都要靠开发者自己记住。现在它们被写进 AI 的工作流里，不需要每次额外提醒一句“别忘了更新 README”和“记得帮我提交”。

怎么安装

两个仓库里都写了安装方法。最省事的方式，是直接把仓库地址发给 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 或做重构即可。符合触发条件时，它们会作为开发任务的收尾门禁被调用，不需要每次手动点名。当然，你也可以在提示词里明确写：

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

需要注意的是，它们不是脱离 AI 独立运行的后台程序，而是 Codex 在处理任务时遵循的工作规则。所以安装后要确认 skill 已经被加载，最终也应该看一眼 AI 报告的 README 结果、commit hash 和剩余未提交内容。

小白缺的往往不是能力，而是一套默认规范

会不会手写 README、会不会背 Git 命令，当然能体现一些经验。但在 AI 编程里，更重要的问题是：能不能让正确的事情稳定发生。

小白很难一开始就知道一个项目还缺哪些工程习惯。AI 虽然会写代码，如果提示词里没有要求，也经常完成主要功能就停下来。good-readme 和 Gitwork 做的事情并不神奇，它们只是把两个容易被忘掉的动作变成了默认流程——一个负责让项目说得清楚，一个负责让项目的变化留得明白。

如果你也经常用 AI 做小工具、Demo、个人项目或者开源项目，又懒得自己维护 README 和 Git，可以试试把这两个 skill 装上。它们不能替你决定项目应该做什么，但能让 AI 每次做完事情之后，顺手把项目收拾得更像一个长期可以维护的工程。