在 dev.to 上刷到 Brad Traversy 的一篇：《Traditional Coding vs Agentic Coding: The Flow State Problem》，九月二十号发的，原先挂在 traversymedia 上。看到 flow state 四个字我差点划走——这题被讲烂了，无非写代码爽、等 agent 不爽，我自己都写过类似的话。
划之前顺手拉了一下评论区，然后一蹲四十分钟。
被钉住的是这么一条留言：交完棒之后再回到代码里的成本，跟 diff 有多大关系不大，跟你"在场外替它放行了多少个决定"关系更大。所以，与其让 agent 停在交付物上，不如让它停在决策点上。
这话比原文的框架利落。原文的主张其实不差：把任务切小，小到你能真正审得动，别一上来就要一整套登录认证，先要 user model，再要注册端点。方向对。但"小"是个手感词，你觉得小我觉得大，两个人标准能差三倍。而"停在决策点"是可操作的：它把"这一刀切哪儿"换成了"切完之后，这里有没有一个需要我做判断的地方"。没有判断的地方，让 agent 一路跑过去；有判断的地方，它必须停下来等我。审查的颗粒度绑在判断的密度上，不绑在行数上。
这句不是原文写的，是评论区一个人补的。我这篇想聊的其实就是他这句话，Traversy 那篇算引子。
原文里我自己认下的是三个东西。
一个是注意力的归属。他写得很直白，大意是：我更希望自己决定什么时候去看后台跑完的活，而不是每条完成通知替我决定。桌面 agent 工具让你能同时开好几个项目，结果是人被扯散，来回重建上下文。这句我服。不是 agent 慢，是它的节奏变成了你的节奏。
另一个是交出去的"块"有多大。他举的例很具体：一次要一个完整的认证功能，回来就是 user model、校验、错误处理、session 管理、接口行为糊成的一个大 diff。这时候你对这块东西没有 ownership，也谈不上理解——不是你审不审的问题，是这条功能的因果链里已经没有你了。再往极端走就是 one-shot 整个应用，跑出来挺像样，代码库你不认识。
第三个是积压。这个我最有共鸣：agent 的任务不审就堆着，堆着的每一坨最后都得有人去理解、去验证，欠的债一分不少，只是延期了。
评论区另外两条也值一提。一条说每次交棒都是一次信任决策，agent 跑的时候人挂在旁边看，等于顺手做了一次便宜的安全审查——有没有可疑依赖、可疑的网络调用、可疑指令，这些东西事后看 diff 是看不太出来的。这条可以留着。另一条说，审查跟写代码是两种不同的心智模式，审查更累，因为你审计的不是自己产出的推理，是别人的；所以最好把"需要判断的审查"和"能自动化的检查"拆开，lint 和测试能挡的别拿人眼去扛。这条我觉得在实操上最容易被忽略。
然后是项目。
Traversy 没停在写文章，他自己做了个东西：AI Blueprint，一个开源的 AI 编程工作流框架。它给 agent 一套结构——一次一个 feature，规格、项目上下文、已完成的历史，全都放在代码旁边、人能直接读的文件里。网站上讲整套流程，仓库里是源码和安装说明。仓库名就叫 AI Blueprint，GitHub 上搜他的名字也能顺到。他自己也说，不必非得照他这套配。
这里我得先声明：这东西我没装。网站和 README 扫了一遍，没跑过，所以下面全是"扫出来的印象"，不是上手体验，别当评测看。就我扫到的，AI Blueprint 想干的其实就一件事——把上面那条"停在决策点"从一句口头原则变成一个文件结构。规格先写在那儿，上下文摆在那儿，做完的落进历史，agent 每次开工前有个能读的地方，你回头也有个能对账的东西。思路不新鲜，新鲜的是有人把"检查点"这个词落成了具体的目录和具体几个文件。
原文里还有一块我没想清楚的：他承认这套流程给不了他手写代码那种满足感，但比"交一大坨回来在一堆改动里翻"好得多。这话挺诚实的。产出上去了、做这件事的爽感下来了，这笔账怎么记，各人不一样，我给不了答案。他给的实验方案倒是可以抄：先别纠结要不要用 agent，改交棒的粒度，挑一个你真能审的检查点，agent 跑的时候你留在项目里——读周边代码、想边界情况、准备测试、拿任务对一遍计划——它一停就马上跑一遍行为、看一遍 diff，检查它有没有解决你要它解决的问题、有没有顺手改了不相干的文件、跟你现有的代码风格搭不搭、以及你还能不能手动接着改。
流程说得很对，落到具体项目就有个坑：feature 该切多大，本身是要吵半天的事。他的回答是"取决于项目和你对这个模块的熟悉度，关键是挑一个能被有意义地审查的检查点"。等于没说，但也确实没有更好的答案。所以又绕回去——拿决策点当刻度，比拿行数当刻度靠谱。
还有一点我觉得被低估了。原文说基础功仍然重要，因为你得看得懂 model、route、endpoint、component、数据流，才问得出有用的问题，也才看得出来它哪儿做错了。这话大家都会点头。但我现在更倾向于把重点放在后半句：不是"你还得会写"，是"你得有能力判断哪里错了"。前者靠手感，手搓练出来的；后者靠结构感，读别人的 diff 也能练。这俩不互相替代。这句我可能说偏了，先放这儿。
候选池里还压着一个同方向、做法更轻的，纯靠约定，不接管任务队列，等我把 AI Blueprint 真装一遍再决定要不要一起讲。你要是现在就手痒，别急着抄他那套现成的文件结构，先照"停在决策点上"这一条改自己的用法，一周就能摸出差别。能不能打，还是自己上手跑一圈最准。