夜雨聆风
睡前给 AI 留一句话,醒来它已经替你改了一晚代码
晚上准备睡觉前，你打开终端，给 AI 留下一句话：
gnhf "reduce complexity of the codebase without changing functionality"
意思很简单：
帮我降低代码复杂度，但不要改变功能。
然后你关掉屏幕，去睡觉。
第二天醒来，它不是只给你回了一大段建议，也不是停在聊天窗口里等你继续追问。
它已经自己跑了几轮。
有些改动成功了，被自动提交成 Git commit。
有些尝试失败了，被自动回滚。
中间发生了什么，也被记进一份 notes 里。
你醒来看到的不是一坨乱七八糟的代码，而是一个分支、一串提交、一份记录。
这就是最近在开发者圈里被转起来的开源项目 gnhf。
全名叫 Good Night, Have Fun。
翻译得直白一点就是：晚安，玩得开心。
更像一句程序员睡前对 AI 说的话：
我去睡了，你继续干。
AI 写代码已经很强，但还没到让人放心睡觉
这两年，很多人对 AI 编程的感受其实很矛盾。
一方面，它确实越来越能写。
让 Claude Code 改一段逻辑，让 Codex 补一个测试，让 Copilot 解释一个函数，很多时候都能省下不少时间。
但另一方面，它又很难让人完全放心。
你让它改一个 bug，它可能顺手改出三个新问题。
你让它重构一个模块，它可能改到一半忘了最初目标。
你让它跑一个长任务，它可能中途遇到报错，然后停在那里等你来处理。
所以现在 AI 编程最大的问题，不一定是它不会写代码。
更大的问题是：
你不盯着它，它就很难稳定地连续干活。
这也是 gnhf 这个项目真正有意思的地方。
它不是又造了一个更聪明的大模型。
它做的是另一件事：
给现有的 AI Coding Agent 套上一层工作纪律。
每一轮只做一点。
做完要验证。
成功就提交。
失败就回滚。
发生了什么要记录下来。
连续失败不能无脑烧钱。
这听起来不像科幻，更像是在管一个有点聪明、但还需要制度约束的实习生。
gnhf 到底是什么？
简单说，gnhf 是一个命令行工具。
它自己不是模型，也不是新的聊天机器人。
它更像一个调度器，站在 Claude Code、Codex、Rovo Dev、OpenCode、GitHub Copilot CLI 这些工具外面，负责把一次任务拆成很多轮自动执行。
你给它一个目标，它就开始循环：
-
读取之前的 notes，看看前面几轮做过什么。
-
生成这一轮要交给 AI Agent 的提示词。
-
调用你配置好的 Agent 去干活。
-
Agent 做完后，返回结构化结果。
-
如果成功，gnhf 自动把改动提交到 Git。
-
如果失败，gnhf 自动回滚工作区。
-
把这一轮的总结和经验写进 notes。
-
继续下一轮，直到你手动停止，或达到迭代次数、token 上限、停止条件。
它的基本用法非常直接：
gnhf "reduce complexity of the codebase without changing functionality"
也可以加限制：
gnhf "reduce complexity of the codebase without changing functionality" \
--max-iterations 10 \
--max-tokens 5000000
这两个参数的意思也很好懂。
最多跑 10 轮。
最多消耗 500 万 token。
这就不是把 AI 放出去裸奔，而是给它划了一个围栏。
真正关键的，不是自动，而是可控
很多 AI 工具都会强调自动。
但自动本身并不稀奇。
真正难的是，自动之后还能不能检查、回滚、继续、复盘。
gnhf 比较值得写的地方，就在这几个设计上。
第一，每一轮只做一个小步
gnhf 给 Agent 的迭代提示词里，有一条很关键：
每一轮不是要完成整个目标，而是找到下一个最小、可验证、能推动目标前进的工作单元。
这句话很重要。
因为 AI 最容易出问题的地方，就是一上来想做太多。
它可能从一个小 bug 改到架构重构，从一个测试补全改到顺手调整接口。
人类开发者也会这样，但人类至少知道自己在冒险。
AI 很多时候并不知道。
所以 gnhf 先把任务切小，再一轮一轮推进。
这不是让 AI 更聪明，而是让 AI 更不容易乱跑。
第二，成功就自动提交
每一轮成功后，gnhf 会自动执行类似 git add -A 和 git commit 的动作。
提交信息会带上这一轮的摘要。
这意味着你第二天醒来，不是面对一个巨大的混合改动，而是一串可以审查的提交。
你可以看每一步改了什么。
可以 cherry-pick 某一轮。
也可以回滚某一次不满意的修改。
这对程序员很关键。
AI 写代码最怕的不是它写错，而是它把错混进一大堆改动里，让你不知道从哪开始拆。
把每一步变成 commit，等于给 AI 的行动留下脚印。
第三，失败就回滚
gnhf 的源码里，失败路径会调用 git reset --hard HEAD 和 git clean -fd。
也就是说，如果这一轮 Agent 自己报告失败，或者运行过程抛出错误，gnhf 会把工作区拉回上一轮安全状态。
这点比听起来更重要。
因为它不是让 AI 在你的代码库里一路试错、一路污染现场。
它允许 AI 试，但失败不能留下烂摊子。
这就是我觉得 gnhf 有价值的地方：
它不是在幻想 AI 永远正确，而是默认 AI 会失败，然后提前设计失败之后怎么办。
这比很多只会喊自动开发的项目靠谱得多。
第四，notes 让 AI 记得昨晚发生过什么
每一轮结束后，gnhf 会把摘要、关键改动、关键经验写进 .gnhf/runs/<runId>/notes.md。
下一轮开始时，Agent 会先读这份 notes。
这就像一个夜班交接本。
上一轮试过什么。
哪里成功了。
哪里失败了。
有什么发现值得下一轮注意。
AI 长任务最容易断片。
而 notes 的作用，就是让它至少有一条自己的工作记录线。
它不等于真正的人类长期记忆，但已经足够解决一个现实问题：
不要每一轮都像从零开始。
第五，连续失败会停，不会一直烧钱
gnhf 默认配置里，连续失败次数是 3。
也就是说，它不会在同一个错误上无限循环。
如果是 Agent 自己报告失败，它会立刻进入下一轮。
如果是更硬的 Agent 错误，它会指数退避，先等 1 分钟，再按倍数拉长等待。
这也是一个成熟工具该有的设计。
很多人第一次用 AI 自动化，最容易犯的错就是只想着让它跑起来，却没想过如果它一直失败怎么办。
对于 AI Agent 来说，停止条件和失败处理，不是锦上添花。
它们本来就是核心能力。
worktree 模式：让多个 AI 在不同分支里试错
gnhf 还有一个很适合开发者的功能，叫 --worktree。
它会基于 Git worktree 创建一个独立工作区。
这样你可以同时跑多个任务：
gnhf --worktree "implement feature X" &
gnhf --worktree "add tests for module Y" &
gnhf --worktree "refactor the API layer" &
每个任务都有自己的目录和分支，互不干扰。
如果某个 worktree 跑出了提交，它会被保留下来，方便你后面 review、merge 或 cherry-pick。
如果没有任何提交，退出时可以自动清理。
这里也要说清楚边界。
这不是 gnhf 自动召唤一群 AI 员工开会。
更准确的说法是：
你可以手动启动多个 gnhf 进程，让不同 Agent 或不同任务在隔离分支里并行尝试。
这个能力对独立开发者和小团队很有想象力。
白天你做判断。
晚上让几个方向分别跑。
第二天看哪个分支更值得留下。
AI 不一定一次成功，但它可以帮你扩大试错半径。
这个项目真正代表的变化
如果只把 gnhf 看成一个 GitHub 小工具，其实有点可惜。
它背后更大的变化是：
AI 正在从聊天框，变成后台执行进程。
过去我们使用 AI，大多是同步的。
你问一句，它答一句。
你让它改一次，它改一次。
你停下，它也停下。
但真正进入工作流以后，人不可能一直盯着 AI。
一个成熟的 AI 工具，必须能异步工作。
它要能接任务。
能自己跑一段。
能记录过程。
能在失败时回到安全状态。
能把结果交给人审查。
这就是 gnhf 有意思的地方。
它没有假装 AI 已经可以彻底替代程序员。
相反，它承认 AI 会犯错、会跑偏、会失败。
然后用 Git、notes、限制条件、回滚机制，把这些不稳定性关进一个工程流程里。
这才是 AI Agent 走向真实工作的关键。
不是让 AI 看起来更像人。
而是让 AI 的工作结果更像工程产物。
可追踪。
可回滚。
可审查。
可接着干。
别神化它，它还不是无人程序员
当然，gnhf 也不能被神化。
它不是一个你输入需求，第二天一定交付完整产品的魔法按钮。
它有很明确的前置条件。
你需要在 Git 仓库里运行。
普通模式要求工作区干净。
你需要本地已经安装并登录 Claude Code、Codex、OpenCode、Rovo Dev 或 GitHub Copilot CLI 这类工具。
它能自动提交，不代表提交一定正确。
它能失败回滚，不代表它理解所有业务风险。
它能多轮迭代，不代表它适合无人值守地改核心生产代码。
所以更稳妥的用法，是把它放在这些任务上：
-
补测试。
-
降低代码复杂度。
-
清理重复逻辑。
-
修小 bug。
-
做探索性分支。
-
尝试多个实现方案。
-
给老项目做渐进式整理。
这些任务有一个共同点：
可以拆小，可以验证，可以回滚，可以 review。
这正是 gnhf 适合的区域。
它不是替你做最终决策。
它是替你把一部分可以机械推进的尝试先跑起来。
以后会变贵的能力，不是会不会问 AI
我越来越觉得，未来使用 AI 的差距，不会只体现在谁更会写 prompt。
更大的差距，会体现在谁更会给 AI 设计工作边界。
给一个模糊问题，让 AI 自由发挥，这很容易。
但给它一个可以执行、可以验证、可以失败退出、可以交接复盘的任务，这就难很多。
gnhf 这类工具其实在提醒我们：
AI Agent 的下一阶段，不是让它像聊天机器人一样更会说话。
而是让它像一个后台工人一样，更守规矩。
它不需要每次都惊艳。
它需要每一轮都留下痕迹。
它不需要永远正确。
它需要失败时别把现场弄脏。
它不需要一次做完所有事。
它需要一小步一小步往前推。
这才是 AI 真正进入生产流程的样子。
最后
以前程序员熬夜，AI 陪聊。
现在开始有人反过来想：
人去睡觉，AI 上夜班。
但这件事真正让人兴奋的，不是 AI 能不能替你通宵干活。
而是我们终于开始认真设计一个问题：
如果 AI 会犯错，那怎样才能让它在可控范围内继续工作？
gnhf 给出的答案很工程化。
小步迭代。
自动提交。
失败回滚。
过程记录。
限制消耗。
人类审查。
这可能比任何一句 AI 替代程序员 都更接近现实。
因为真正改变工作的，往往不是那个最会聊天的 AI。
而是那个你关掉屏幕后，还能在后台默默提交代码的 AI。
如果你也想玩这个项目，评论区的置顶链接里看一看。
最近我还在组一个关于Image 2的学习分享群。
Image 2的横空出世已经彻底颠覆了图片领域真实和虚拟的界限，其实有很多很多的玩法可以落地实现。
如果你也对它感兴趣的话，可以在后台回复“Image”就可以看到入群的信息了