最近卡帕西（Andrej Karpathy）说了一句话，在开发者圈子里传得挺广：编程正在从“写文件”变成“管龙虾”。我第一次看到这个比喻的时候愣了一下，细想之后觉得它比大多数分析文章都靠谱。你现在但凡用AI写代码，多少会有那种感觉——你做的事情已经不太像“写代码”，更像在盯着一堆自动产出代码的“活物”，确保它们别把项目拆了、别把依赖打乱、别在凌晨三点给你提交一个“自信满满”的PR。

这篇文章就围绕这句话展开：卡帕西为什么这么说，IDE在这种转变里到底会不会凉，以及一个普通程序员要怎么把工作流从“写文件”切到“管龙虾”。我不是想聊什么宏大趋势，而是想把我自己切换过程中的真实操作、踩的坑、还有调整后的日常流程都摆出来。不管你用的是Cursor、Trae这类带Agent模式的IDE，还是只用过GitHub Copilot，这篇文章应该都能给你一些能直接用的东西。

1. 卡帕西这句话到底在说什么

1.1 “写文件”时代的底层逻辑

要理解这句话，得先回头看传统编程到底在干嘛。过去二十年，程序员的日常工作本质上是一个“文本生产”过程：你有一个想法，拆解成逻辑，然后把逻辑写成一系列文本文件，交给编译器或解释器去执行。IDE的一切设计都是围绕这个核心展开的——语法高亮让你看得清楚，自动补全让你少打几个字，调试器让你在某个断点停下来查看变量，版本管理让你知道哪个文件被谁改过。

“写文件”这个描述听起来很朴素，但它准确抓住了重点：代码的载体是文件，程序员的产出是文件内容，而质量取决于你写的每一行是否正确。哪怕是一个非常熟练的程序员，一天有效产出也就是几百行到上千行代码，大部分时间其实花在了思考“这里为什么要这么写”“那里会不会有边界问题”上。文件在这里不只是存储单元，它同时是思考的载体、协作的单位、审查的粒度。

所以以前我们聊“编程能力”，本质上聊的是“把想法精确转换成文本”的能力。谁的文件写得清楚、结构好、边界处理完备，谁就是高手。IDE的进化史，也是为了让这个“写文件”的过程更顺畅——从Vim到VS Code，核心都是编辑器体验的优化。

1.2 “管龙虾”是个什么比喻

卡帕西说的“管龙虾”，我第一次看以为是个玩笑，后来发现这是个很精准的比喻。龙虾这种生物有个特点：它是活的，有自己的意志，会到处乱爬，你把它放缸里它不一定按你画的路线走，还会互相攻击。养过龙虾的人都知道，你没法“写”一只龙虾，你只能“管”它——投喂、观察、纠正方向、及时隔离出问题的那只。

AI编程代理就是这个德行。你给它一个任务，它在自己的环境里跑，调一堆工具，读一堆文件，最后给你产出一段代码或者一个补丁。过程里它可能突然去改了一个你没让它动的文件，可能用了一个“看起来很合理”但其实有坑的写法，可能在一个小问题上反复横跳浪费大量token。你没法像以前那样每一行都自己写、自己控制，你只能像养龙虾一样：给清楚目标，提供环境，持续观察，在它跑偏的时候拉回来，在它产出垃圾的时候丢弃。

这个比喻的妙处在于，它把编程里那种“控制感”的消失表达得很准确。以前写文件，每一行都是你敲的，你知道为什么在；现在管龙虾，代码可能不是你的“亲儿子”，你只是引导了一个黑盒子产出了这堆代码。你变成了监护人，而不是作者。

1.3 从作者到管理者的角色位移

把“写文件”和“管龙虾”放在一起，卡帕西其实在说一个很现实的事情：程序员的核心工作正在从“生产代码”迁移到“管理生产代码的过程”。

以前，代码量直接等于工作量，你写的行数越多，说明干得越多。现在情况变了，AI帮你把“写”的环节吃掉了很大一部分，剩下的工作变成了：把需求想清楚、把任务拆成AI能执行的小块、判断AI产出的质量、在多个代理并行工作时协调它们、以及承担最后的所有权责任。

这就导致一个很多人没意识到的结果：编程的瓶颈从“打字速度”变成了“判断力和表达力”。你能不能把脑子里的模糊需求说成一句AI能精确执行的自然语言指令？你能不能在一堆看似合理的Diff里快速找出掩藏的问题？你能不能判断某个重构方向对不对？这些能力以前也有用，但现在它们直接决定了你的产出质量。

说白了，以前我们是“写”软件，现在我们是“管”软件的生产过程。思维方式必须变，不变的人会非常别扭。

2. 为什么说IDE不会凉，但要换个用法

2.1 IDE死不了的原因

标题里那句“IDE不会凉”也是卡帕西说的。很多人一听AI编程就觉得以后不用IDE了，打开个对话框直接说需求就行。这个想法太天真了，至少现阶段完全不是这么回事。

IDE死不了，最根本的原因是人类需要一个“看得见代码”的地方。AI产出的代码再智能，最终要落回一个代码库，而人类要对这个代码库负责。你审查AI写的代码的时候，需要一个能显示Diff、能跳转到定义、能看运行时状态的地方。纯聊天框做不到这些，或者做得非常笨拙。

另外一个更实际的原因：你没法通过聊天框看到整个项目的面貌。IDE的价值不只是编辑，它还是一个“可视化信息中枢”——文件树、调用关系、运行状态、git历史、lint结果、测试报告，这些信息在对话式的界面里很难组织。你问AI十次都说不清楚的问题，在IDE里一秒钟就看到了。

所以结论很直接：IDE不是被取代，而是它的重心在移动。以前IDE是“写文件”的操作台，以后IDE是“管龙虾”的观赏缸和指挥中心。

2.2 IDE正在从编辑器变成指挥台

那么“换个用法”具体指什么？我自己用下来的体会是，IDE的角色正在从一个“文本编辑器”变成一个“AI代理的指挥台”。

以前的IDE界面是围绕光标组织的：你的输入焦点在某个文件、某个位置。现在的AI IDE，界面焦点正在分散到多个面板：中间是代码和Diff视图，侧边是对话上下文，底部是代理执行的日志，顶部是任务列表。你不再是盯着一行代码改，而是盯着几个同时运行的任务，看它们各自在干什么、改了哪些文件、有没有互相踩脚。

这个转变在操作习惯上的体现非常明显。以前我打开IDE是准备“写代码”，现在我打开IDE是准备“安排事情”——把任务拆开，派给不同的上下文，然后盯着它们执行。有时候我整个上午没有手动写一行代码，但做的事情比之前写几百行代码还要累，因为你在持续做判断、纠正、协调。

还有一点很有意思：IDE变成指挥台之后，它的“可信任度”反而更重要了。以前编辑器写错了顶多是个语法错误，现在一个错误指令可能让AI代理把不该改的文件改一遍。所以IDE里越来越重要的是：哪些文件被改了、改了什么、能不能回滚（checkpoint）。这些功能以前是辅助，现在成了核心。

2.3 现在各家AI IDE在往哪个方向做

各家工具的方向，实际上都在验证“指挥台”这个判断。Cursor走的路子是深度侵入编辑器，把Agent嵌进传统的IDE体验里，让你感觉“还是IDE，但多了个超级助手”。Trae这类国内工具在重交互体验，把任务模式和对话放在很显眼的位置。还有Codex这类偏命令行的工具，跟你直接说“别用IDE了，用终端管代理”，但它本质上还是一个“管理界面”，只是形态是终端。

这些方向不同，但核心都指向一件事：AI产出的代码需要一个人类可控的审查和管理界面。有的界面强调Diff审查，有的强调多代理调度，有的强调用对话回溯状态。不管叫什么名字，它们都在往“指挥台”这个方向上走。

MCP（Model Context Protocol）的流行也是一个信号。IDE里的AI不再只是看着当前文件瞎猜，而是能通过协议去读数据库、调接口、跑命令、操作外部工具。这时候IDE更像一个总控台，把所有工具都接到AI面前。谁接得好、展示得好，谁就有机会成为下一代主入口。

3. 切换到“管龙虾”模式的具体实操

3.1 新工作流的核心四步

说了一堆趋势，回到我自己实际的工作流。我现在日常用AI写代码，基本上遵循四个步骤：写清楚意图、拆成可执行任务、派发给代理、审查验收。

第一，写清楚意图。这一步最容易被忽视，但恰恰是质量的分水岭。我见过太多人上来就说“帮我写一个文件上传功能”，结果AI写出来的东西跟他想要的差十万八千里。不是AI笨，是你没说清楚。我现在会花十分钟把意图写成一段“伪需求文档”，包含目标、边界、输入输出示例、验收标准。

第二，拆任务。一个大的功能拆成几个小任务，每个任务只做一件事。比如“文件上传”可以拆成“前端组件”“后端接口”“存储封装”“错误处理”四块。每个任务都足够独立，AI做的时候不用频繁跨文件猜测。

第三，派发。在小块任务里，我会明确告诉代理：项目目录结构是什么、相关的现有代码在哪、不要动哪些文件、完成后给出什么产出。这些信息看起来啰嗦，但能有效把“龙虾”圈在缸里。

第四，审查验收。这一步的核心是跑测试和看Diff，而不是读每一行代码。我先看测试过没过，再看改动的文件清单有没有超出范围，最后抽查关键逻辑。

这套流程听上去简单，但它解决的是“管龙虾”的核心矛盾——给了AI自由度，但又没有失控。

3.2 怎么把任务拆给AI代理

把任务拆给AI代理是有技巧的，不是随便说一句“帮我写个接口”就行。我经过大量实验，现在固定用这种格式：

• 目标：做什么，做成什么样算成功
• 现状：相关代码在哪些文件里，依赖哪些库
• 限制：不要改哪些文件，不要引入新的依赖
• 验收：跑什么命令、满足什么条件就算通过

比如我要加一个批量重命名工具，我会这样写：

目标：新增一个Python脚本，用于批量重命名指定目录下的文件，规则是把文件名里的空格替换成下划线。 现状：项目根目录在/workspace，脚本要放在tools/rename_files.py，项目里已经有argparse依赖。 限制：不要改动其他任何文件，不要新增依赖，不要用pathlib之外的文件遍历方式。 验收：运行python tools/rename_files.py --dir /tmp/test-dir --dry-run时不实际修改文件，只打印将要执行的改名；去掉--dry-run后再执行一次，确认文件名被修改。

这个格式看起来死板，但它把一个模糊的任务变成了一个可验收的小项目。AI拿到之后几乎不需要猜，产出的结果通常一次性就能通过验收。

我还发现一个细节：让AI先给方案再动手，比直接让它写代码好得多。我会在任务最后加一句“先简单描述你的实现思路，确认没问题再开始写”。这样能在早期拦截掉很多跑偏的尝试，省下大量返工时间。

3.3 审代码的重点从“语法”变成“意图”

以前审代码，重点看逻辑和语法——循环边界对不对、有没有空指针、缩进规不规范。现在AI写的代码基本不会犯语法错误，常见的坑变成了“意图没理解对”。

我审AI代码的时候，习惯先看Diff的“改动范围”，再看“关键分支”，最后才看“实现细节”。改动范围能暴露很多问题：比如我让它只改一个文件，它却顺手“优化”了另一个文件；或者我让它加一个字段，它把整个配置文件的格式都重构了一遍。这些超出范围的改动，哪怕看起来合理，也容易引入风险。

关键分支指的是那些跟需求直接相关的代码路径。我会问自己：它理解的目标是我写的那句话吗？比如我要“替换空格”，它是不是也把制表符替换了？我要“批量重命名”，它是不是只在当前目录下递归处理了？这些细节，AI经常自信地做错，人类要负责兜底。

还有一个我自己的习惯：要求AI在提交前自己先跑一遍测试，并把测试结果贴回来。AI如果跑了测试，能把很多低级错误挡在提交之前。现在很多AI IDE内置了这个能力，你要做的就是把“跑测试”写进自动流程。

3.4 一个完整的小案例：用AI IDE做一个小工具

举个我自己上个月做的实际例子，方便你感受完整流程。

当时我需要写一个工具：从一堆Markdown文件里提取所有标题，生成一个目录文件。这个任务不大不小，自己写五六百行，用AI代劳我大概花了20分钟。

第一步，我把需求写清楚：输入是一个目录，输出是一个docs/TOC.md文件，内容是按目录层级组织的标题列表，同级标题按出现顺序排列。限制是只处理.md文件，不递归处理子目录，不修改原文件。

第二步，我把它拆成两小块：第一块是“扫描解析”，从文件里提取标题和层级；第二块是“生成目录”，把解析结果格式化写盘。每一块都单独开了一个会话，让AI分别实现。

第三步，审查。我发现第一个AI生成的解析逻辑里，把“###”和“##”的层级顺序搞反了——它按字符串长度排序了，而实际上“#”的数量越多层级越深。这个错误看一眼输出就能发现。我在反馈里给它说明“#号越多层级越深”，它立刻修正了。

第四步，让AI跑了一个测试用例：在临时目录里造了三个文件，运行工具，检查输出的TOC.md内容是否符合预期。等它把测试结果贴出来，我再人肉看了一眼输出格式，确认没问题才收工。

整个过程里，我自己写过的代码大概是零行。但拆任务、写需求、审结果这三件事，占了绝大部分时间。这就是“管龙虾”的真实状态——你干的活儿从打渔变成了养殖，看似不碰水，但每一只虾的存活你都得负责。

4. 我从“写文件”切换到“管龙虾”踩过的坑

4.1 翻车现场一：AI写了个“自信满满”的错代码

先说我踩得最狠的一个坑。有一次我让AI实现一个URL解析函数，要求是“把URL里的query参数解析成字典”。AI很快就给了一版，用了urllib.parse.parse_qs。代码看起来没有任何问题，跑起来也正常。但我后来在一个边界场景里发现，当URL里出现重复的query键时，parse_qs返回的是列表而不是字符串，跟我的预期不一致。

问题出在哪？我给的指令不够精确——“字典”到底是“键到字符串”还是“键到列表”？AI默认选了标准库的默认行为。这个错不是AI蠢，是我需求没定义清楚。它给了我一版“自信满满”但不符合业务预期的代码，而如果我没有在验收标准里写明“重复键取最后一个”，这个问题会在上线后炸。

教训很简单：给AI的任务，验收标准必须包含边界条件。我会在需求里明确写上“当输入包含重复参数时，后出现的值覆盖先出现的值”这种句子。这不是废话，这是把模糊意图变成可执行约束。

4.2 翻车现场二：同时开一堆代理，场面失控

第二个坑是我自己作出来的。有一次我图省事，在一个大功能里同时开了四个代理会话：一个写前端组件，一个写后端接口，一个写数据库迁移，一个写测试。我以为互不干涉，结果它们全都跑去看同一个“用户实体定义文件”，然后各自按自己的理解改了它。等我发现的时候，那个文件已经被改了四个版本，每个版本都破坏了另一个人依赖的字段。

这个事故的核心问题不是“代理太多”，而是我没有划分好代理之间的边界。前端组件依赖后端接口的返回结构，后端接口依赖数据库字段，这四个代理之间存在隐式的依赖关系，而我假装它们没有。整个过程很像水族箱里放了太多龙虾——每个都很能干，但放在一起就开始互相咬。

现在的做法是：同一时刻最多并行两个边缘互不依赖的代理，或者干脆串行。如果一个任务可以被拆成完全不碰同一文件的几个部分，才值得并行。否则就让它们排好队，一次处理一个。

4.3 翻车现场三：上下文胖到跑不动

第三个坑特别典型——上下文膨胀。有一次我在一个会话里连续跟AI交流了很多轮：先讨论了方案，又让它改了两版代码，然后又让它加了一个功能，再让它排查一个报错。到后面，它的回复越来越慢，偶尔还会忘记最开始的项目背景，甚至出现“重复建议我已经拒绝过的方案”这种诡异行为。

原因很明显：对话窗口装不下整个“思考史”，而AI还在努力从中找线索。以前写文件没有这个问题，因为你不需要带着几十轮对话上下文去打代码；现在管龙虾，每只“龙虾”的状态都在对话里，你必须自己去维护它的记忆边界。

我现在有三条原则：第一，一个会话只做一件事，做完立刻开新会话；第二，新会话开头用一小段话把项目背景和角色重新交代清楚，哪怕看起来重复；第三，如果任务比较复杂，我会把“需求和验收标准”单独写成一个项目内的文档，让AI每次直接从文件里读，而不是从对话历史里猜。

4.4 什么任务适合交给AI，什么不适合

踩了这么多坑之后，我给自己总结了一张任务分发表，不是什么高深理论，就是实操下来的感受：

这个表格的核心逻辑是：AI适合做“有明确验收标准”的事，不适合做“需要人来定义验收标准”的事。样板代码的验收标准明摆着——就是你给它的输入输出；核心架构决策的验收标准往往要到很后面才浮现，这种只能人来做。

一个小观察：很多人说“AI写代码没有灵魂”，我反而觉得不是AI没灵魂，很多人是把自己该做的判断任务也甩给AI了。你让AI决定“这个模块为什么要有这个接口”，它当然只能编一个看起来合理的理由。判断、取舍、定边界这种事情，暂时还是人自己的活。

5. 一点真心话和最后的小技巧

写了这么多，最后分享点个人体会。我刚开始用AI编程那阵子特别焦虑，总觉得“我是不是要被替代了”“IDE是不是要完蛋了”。真正切到“管龙虾”模式之后，我发现焦虑被一种新的忙碌取代了：你要操心的事更多了，但这些事确实更像“人干的活”——理解需求、定义边界、判断质量、承担风险。从这个角度说，卡帕西那句话反而让人安心：编程没有消失，只是换了一种形态，IDE没有凉，只是换了一个用法。

我最后想留给大家的小技巧，也是我目前一直在用的：把每一段交给AI的任务都写成一张“可验收的卡片”。卡片上写清楚目标、边界、验收命令，不需要多正式，几行字就行。别懒，这步省不了。它省下来的是你后面反复纠偏、重新解释、收拾烂摊子的时间，这一来一回，节省的时间起码是好几倍。

这个内容其实还能继续往深挖，比如多代理之间怎么协调、怎么设计一个适合AI维护的代码库结构、checkpoint回滚的时机怎么把握，这些我后续应该还会单独写。如果你也正在从“写文件”往“管龙虾”过渡，欢迎在评论区聊聊你遇到的翻车现场，我对那些“AI把项目搞得一团糟”的故事特别感兴趣。