快速回答
AI 编程本身没有毁掉心流，毁掉心流的是默认工作流：一次丢出巨型任务、多项目并行、在等待中反复切换上下文。解法是用更小更技术化的任务粒度、等待时留在同一个问题里、输出后趁上下文新鲜及时审阅——把 AI 当快进的结对程序员，而不是甩手掌柜。
·
93 阅读
·
AI 编程 心流
AI 编程正在偷走开发者的「心流」——以及如何把它找回来
当 AI 能几秒写完代码，为什么很多开发者反而失去了编程的乐趣？问题不在 AI 本身，而在大多数人默认的工作流——巨型 prompt、多项目并行、漫长的等待，亲手拆掉了产生心流的紧密反馈环。这篇文章拆解手动编码与 AI 编码工作流的本质差异，并给出四个可落地的修复方法：更小的任务粒度、更技术化的措辞、留在问题里、及时审阅。
关键词：AI 编程 / Agent 工作流 / 心流 / 结对编程 / 开发者体验
打开 YouTube、X 或者任何技术社区，你会看到一种奇特的撕裂：一边是铺天盖地的 AI 编程内容，一边是铺天盖地"AI 让我不再热爱写代码"的抱怨。
这不是又一个反 AI 的论调。AI 本身没有错，错的是大多数人默认使用 AI 的方式——那个方式亲手拆掉了让我们爱上编程的东西：心流。
什么是心流，为什么它对程序员如此重要
心流是那种完全沉浸的状态：你清楚地知道自己在构建什么，代码自然地流淌，每个小问题都顺理成章地引出下一个。你不会想看手机、不会切项目，甚至感觉不到时间流逝。你只是在构建。
对很多开发者来说，这是编程最让人上瘾的部分。
而过去一两年里，如果你体验过 agentic coding，可能已经发现：那种感觉消失了。这不该怪 AI，而该怪我们默认的工作流——它和手动编码的节奏完全不同。
手动编码工作流：一个紧密的反馈环
手动编码时，你从想法开始，层层拆解：MVP 计划 → 功能清单 → 规格 → 第一个功能。
然后你思考这个功能：涉及什么技术？需要哪些文件？数据如何流转？点击按钮会发生什么？
接着你开始写代码：创建组件、添加路由、写函数、建数据库模型。写到可以测试的程度，运行它——现在你得到了反馈。可能跑通了，可能报错，可能"技术上正确但不是我想要的"。于是你观察、调整、再运行。
这个循环在一个功能里可能重复几十上百次。关键在于：它是一个紧密的回路——你持续地行动、观察、响应，大脑几乎没有空转等待的时间。每一步自然衔接下一步，循环越快，动量越强，最终把你推进心流。
更不用说最后的奖赏：你为一个难题挣扎良久，最终让它跑起来。问题越难，那一刻越美好——因为你不仅看到了结果，还亲历了通往结果的每一个决定和突破。
常见 AI 工作流：反复离开的机会
计划阶段其实差不多——用 AI 时你甚至应该规划得更多，因为你是在委托别人实现你的想法。
真正的分岔发生在执行阶段：
- 你想好第一个功能，把任务丢给 agent……然后等待。
- 你不会干坐着盯屏幕。你去看邮件、刷 X，或者——如果你用的是 Codex、Claude Code 这类桌面工具——直接再开一个 tab，进入另一个项目，又丢一个 prompt。
- 现实中的 AI 工作流于是变成：项目 A 跑着 → 切去项目 B → 切去项目 C → 收到通知 A 完成了 → 跳回去，努力回忆这个项目在做什么、你让它做什么、你预期结果是什么 → 审阅所有改动 → 理解 agent 替你做过的决定 → 验证是否真的能用、有没有弄坏别的 → 或许它还误解了部分需求 → 再补一个 prompt → 又进入等待 → 切回 B……
而当你审阅 A 的时候，C 也完成了。通知从四面八方涌来，每一个都要求你把一个不同的项目重新加载进大脑。
一开始，在它烧干你之前，这种感觉像拥有超能力：过去要几个月才能做出来的东西，现在几天甚至几小时就出来了，还能同时跑三四个 agent，做五倍十倍的工作量。
但很快你会意识到几件事：
第一，它会耗尽你。 手动编码时你可能花两小时死磕一个难题；在这种 AI 工作流里，你花同样的两小时，在反复忘记和回忆五个不同的问题。你做了更多的事，却从未真正沉浸在任何一件里——这是一种完全不同、同样昂贵的脑力消耗。
第二，你开始失去"所有权"感。 高层面上你当然不是什么都没做——你有想法、做了计划、指挥 agent、定义了最终结果。但任务越大，你和构建过程中的那些细小决定就越脱节。而如果你一次索要巨型功能、甚至一次性生成整个项目，你得到的通常不只是失去心流，而是一团乱麻。
问题本质：反馈环断了
手动编码每几秒就给大脑一个可以回应的东西；AI 编码则反复给大脑离开的机会。
把"等待"和"巨型 prompt + 多项目并行"叠加，你会同时失去两样东西：连续性（不停在不同问题间跳转）和所有权（大部分决定都不再经过你）。
所以，想让专注和满足感回来，我们需要一个同时恢复这两者的工作流。没有完美的系统，但方向应该是这样的：
1. 缩小任务粒度
与其让 agent 一次性构建整套认证系统，不如：
- 让它先创建 User 模型 → 你审阅
- 再让它加一个注册端点 → 审阅、运行、测试、确保你理解每一行
- 确认无误，再进入下一个检查点
你依然享受 AI 带来的速度，但你始终参与塑造功能的每个决定。
注意这里的措辞：不是"帮我做个登录"，而是"创建 User 模型""添加注册端点"——更技术化的语言让你和代码绑得更紧。这也是为什么基本功仍然重要：一个纯 vibe coder 甚至不知道 User 模型或端点是什么。请用开发者语言和它对话。
有人会说：既然 agent 能一次做完整个功能，为什么还要拆成五个小任务、逐个审阅？
因为目标不永远是"最短时间产出最多代码"。目标是做出好东西、理解你做了什么、不让自己和过程彻底脱节。
2. 等待期间，留在问题里
agent 工作时，不要离开项目。可做的事很多：阅读周边代码（你本来就该读）、思考下一个决定、准备一个测试、对照计划确认当前任务仍然契合。
具体做什么不重要，保持上下文才重要。等 A 的时候，让你的大脑留在 A。
3. 及时审阅，别让任务堆积
输出一完成就立刻审阅：运行代码、看 diff、做调整、启动下一个小循环——趁上下文还热乎。
不要让复杂的 agent 任务像收件箱一样堆积起来留到"晚点"处理。同理，你大概率也不需要同时跑五个不相关的项目。
并行 agent 当然有用——尤其是处理同一项目的相关部分、或不需要你持续输入的任务时。但请分清并行工作和碎片化注意力：电脑能同时想十件事，你的大脑不能——至少无法高效地做。别高估自己。
4. 把 AI 当"快进的结对程序员"，而不是隔壁屋的承包商
你依然是司机。agent 承担大量实现工作，但你要在场——为决定、为反馈、为沿途每一个小胜利。
这样的产出会比"开十个 tab、一次性生成十个功能"少吗？很可能。但原始产出不等于进展。感觉行业里 80% 的人——尤其是那些大公司里做决策的管理者——不理解这一点。他们让东西产出得更快，但很多时候质量更差，同时把开发者和项目本身割裂开，让他们的工作体验变得糟糕。
结语：AI 不背锅，工作流背锅
我每天都在用 AI，不是劝你不用——而是劝你用得更少、更小、更技术化。
手动编码给我们的那种满足感，AI 化的工作流未必能 100% 复刻，但它可以比"一次性生成一堆代码"好得多，而且你对产品的理解会贴近得多——随时可以跳进去手动改一个功能，因为你知道一切都在哪里。
抗拒"让它自己跑完"的诱惑吧——正是那个诱惑让你痛苦、让你开始讨厌编程。让自己留在真正重要的决定里，让 AI 去写代码，但别让它把你自己从过程中删除。
试着用小检查点、待在同一个问题里、趁上下文新鲜时审阅。找到属于你自己的节奏——那种既快、又不失去心流与所有权的节奏。
*Mixtint 是专注 AI 原生开发的团队。我们构建 AI 友好型数字体验与智能体系统——包括让开发者真正用得顺手的 AI 工作流。*