前段时间 GitHub 把 gh stack 放出来做公开预览，我点开看了一眼。第一反应不是"终于"，是"这活儿我手动干过三次，每次都 force-push 到天亮"。
手动维护 stack 那种渡劫体验，试过的都懂。你改底下那层，上面每一层都得 rebase 一遍，推一次，弹一次冲突，再来一遍。推到后来你已经不记得自己在修哪一层了，只记得这是场持久战。所以我对"自动化 rebase"这种承诺的期待值一直是负数。
【结果它真把 rebase 自动化了，灯光打我脸】
遇到冲突它直接停下，把所有分支恢复到你动手之前的状态，不给你留一个半 rebase 的烂摊子。就这一条，比我手动折腾时对自己的仁慈多了。
铺垫到这儿，说点我真正想说的。
这工具的技术卖点一句话说完：每层改动切在自己分支里，一层一个 PR，底层动了上层自动跟着走，最后整摞一次合进去。叠煎饼，盘子是 trunk，每张饼指着下面那张。
不新鲜。stacked PR 这概念比我工作年限还长，手动搞的人一直有，只是没人撑得住那个维护成本。
它戳中我的是另一件事。
你有没有发现，这一年"把 diff 切小"这件事的性质变了。
以前你切小 diff，是为了让 reviewer 心情好。你 lead 在 code review 里反复问"这行改动是必须的吗"，问得你开始怀疑人生，于是你学会了把顺手改的 lint、顺手拆的函数、顺手补的测试都拆出去单开一个 PR。这习惯是被人管出来的，不是觉悟出来的。
现在呢——GitHub 自己的文档都在讲，大 PR 难读，会形成瓶颈，尤其当 AI 帮你快速生成一大堆改动的时候。
翻译一下：AI 让写代码变快了，审查就成了新的瓶颈。以前一周堆一个大 diff，现在一个下午就能堆出来。工具没给你减压，它把压力平移到了"谁来看这些代码"那一端。
所以你现在切小 diff，不再是为了让 lead 心情好。
是为了让读代码的那个东西，能读进去。
说到"那个东西"，提一嘴 agent skill。
gh skill install github/gh-stack，装完 AI 能自己建栈、把每个关注点放进自己那层、commit 到正确的层、把上面几层 rebase 掉、submit 整条链。你基本只负责描述分几层，然后看它输出。
听起来像请了个能自己干活的同事。我一装完就在 Claude 里用，然后——
每次还得提醒它去用它。得说"用 /gh-stack 这个 skill"，它才想起来。你请了个助理，每天上班第一句是"记得上班"。
更关键的是另一条：层怎么切，AI 定不了。
官方教程写得很清楚，stack 的形状归用户，agent 提方案，你来判断这个边界是不是真的对应依赖关系。这是它唯一不敢替你做主的地方——它不知道你这坨代码为什么长这样，哪一段是历史包袱没拆，哪一段是上个季度那个临时需求留下的。这些信息在你脑子里，不在它的上下文里。
我的判断：切分是整条流程里最后一块不能外包的活儿。rebase 可以外包，commit message 可以外包，review 甚至可以外包，但"这堆东西该切成几份"不行。你切错了，AI 会非常配合地把错误执行得很干净。
再讲一个我很共鸣的自我矛盾。
有人被单位按"每个 PR 涉及多少文件"打分，于是养成了习惯：顺手把工作流的小修、lint 的修复，塞进已经开着的那个分支。反正都开了，顺手嘛。最后 PR 标题写着"修复登录超时"，点进去十七个文件，六个是格式化。
你是不是也这样。
stacking 在这儿帮了个实际的忙：那些"顺手"单独占一层，主 PR 干净了，顺手的东西也没丢，整条链一起发。工具没让你变自律，它只是给了顺手党一个体面的收纳盒。
换个场景立刻变味。那位作者做个人作品集网站，审她 PR 的不是 lead，是 AI。她在工作里要求自己小块小块来，到个人项目里直接跟 AI 说"把整个站重写一遍吧"。
最后五个 PR，每一个还是太大。
我看到这段笑了一会儿，太真实了。给人审的时候你会怕，给 AI 审的时候你不怕——AI 不翻白眼，不在评论区问你"这个改动跟本 PR 有关系吗"，它只会默默把整个 diff 读完，然后给你一份非常认真、非常工整、看起来什么都审到了的 review。
这才是最该警惕的地方。
人读大 diff 会漏看，因为他困了、烦了、上下文超了。AI 读大 diff 也会漏看，原因不是它累了，是它不累。它不会告诉你"这段我没读完"，它会给你一份完整、自信、条条在理的报告，漏掉的地方和人类困到凌晨三点时漏掉的地方，一模一样。
你失去了那个"我可能没看全"的信号。
所以 stacking 这类东西的存在感，在 AI 写码、AI 审码的时代反而变强。不是因为技术新，是因为读代码那一方不管是谁，都有一个共同的物理限制：一次能真实读进去的量是有限的。人有限制是因为会累，AI 有限制是因为它不会说自己不累。
gh stack 说到底只做了一件事：让每个 diff 小到能被认认真真读一遍。
它没解决新问题。它只是承认了一件事——在 feature 和 diff 之间，diff 才是那个值得被当作最小单位的对象。功能可以叠，改动不能糊。
（友情提示：以上关于层数的所有建议，都建立在你记得每一层是干嘛的这个前提上。忘了的话，gh stack view 会显示得很清楚——同时也显示得很清楚，你上周到底干了什么 🫠）