★ FEATURED ARTICLE 诚实地讲我从写第一行代码起就是个VSCode重度用户快捷键熟练到肌肉记忆主题、插件、settings.json折腾了几十遍。但过去半年我主动打开VSCode的次数一只手数得过来。不是卸载了而是整个写代码的流程被AI Agent彻底重构了——我现在大部分时间泡在终端里对着一个会话窗口说需求、审diff、跑测试编辑器反而变成了偶尔用来检查复杂合并结果的“回血工具”。今天就把这半年我实际跑通的这套工作流、踩过的坑、以及哪些场景千万别让AI写代码一次性讲清楚。1. 从“写代码”到“审代码”我的工作流重塑1.1 一个典型需求的处理链路过去我拿到一个需求第一反应是打开VSCode找到对应文件手敲代码。现在完全不是这个顺序。我的标准链路变成了在终端里打开一个AI Agent会话把需求说清楚附上相关文件路径或已有的接口文档Agent自动扫描项目结构、读取关键上下文然后给出一个修改方案我确认思路后它直接改代码我逐行审查它生成的diff有问题直接在会话里指出“这个函数命名不够清晰”“这里少写了个空值判断”它立刻修正确认无误后我跑测试、手动点几个关键路径完成收尾。这个过程里我更像一个代码审查者、架构决策者和“产品经理转述人”而不是第一落笔的人。半年下来我发现自己从来没这么轻松过但也从来没这么需要警惕过——AI写代码的速度太快一旦方向错了返工成本也高得吓人。1.2 为什么选择终端AI Agent而不是IDE听到“终端”两个字很多人第一反应是Vim、Emacs那种上古神器。其实不是我用的是tmux zsh Claude Code这样的组合。选择这个方案有很实际的原因。IDE里的AI插件比如Copilot那种以补全为主的本质是“加速打字”它先在编辑器内部工作你仍然需要自己设计结构、自己切换文件、自己跑命令。而我用的Agent模式是“直接替你把活干了”——它能跨文件修改能自己执行shell命令跑测试能根据失败结果自我修正。这种能力放在VSCode里当然也有配套插件但半年用下来我发现终端里的交互密度更高上下文管理也更干净。另外还有一个很现实的因素内存占用。VSCode开一个大项目再挂上智能插件和一堆工作区插件风扇直接起飞。而在终端里跑Agent一套tmux会话搞定多个任务资源占用低一个量级。对于我这种长期开七八个项目的场景终端方案明显更务实。当然我没彻底抛弃VSCode。碰到两个极端情况我仍然会打开它一是合并分支时出现大量冲突需要一个图形化界面逐行对比二是调试复杂的浏览器端CSS或React渲染逻辑时DevTools和编辑器联动更方便。除此之外日常开发我真没理由打开它。注意我的结论不是“VSCode不好”而是“AI时代IDE的定位变了”。对于学生和新手VSCode依然是学习、阅读代码、配置调试环境的最佳工具。Agent适合已有一定项目复杂度、能独立判断代码质量的人。2. 工具链与关键配置我用了哪些AI工具2.1 主力AI编程工具Claude Code / Cursor / Copilot 的取舍我现在的主力是Claude CodeAnthropic官方提供的命令行Agent工具配合Web端Claude做方案设计偶尔用Cursor处理不熟的技术栈项目GitHub Copilot则只在我的Vim/终端里当作一轮快速补全的备用。这段时间经常有人问我“哪个AI写代码最强”我的答案是没有最强的只有最合适的场景。我整理了这么个对比表方便你按需求选工具形态擅长场景短板Claude Code终端Agent跨文件重构、自主跑测试、长任务自主执行需要自己维护上下文旧项目依赖混乱时容易跑偏Cursor编辑器交互式改代码、新人友好、可视化diff自动能力弱于Agent本质是高级补全GitHub Copilot插件补全、单函数生成、内联建议无法独立完成多头任务多文件修改基本靠手通义灵码/智谱插件IDE插件国内模型部署、中文需求描述友好需要配合IDE使用Agent能力还在追赶Fitten CodePyCharm插件轻量补全、代码解释、适合Python开发规模大的重构支持一般我个人的经验是如果你日常开发场景是“一个需求涉及多个文件、有完整的测试体系、需要反复迭代”直接上终端型Agent。如果只是“在已有代码里改个函数、写个SQL、补个单元测试”VSCode里装一个Copilot或通义灵码就够没必要切换工作流。2.2 终端环境配置tmux、zsh、alias既然主力工具在终端环境配置就很重要。我的配置方案如下直接给你可以抄作业的步骤# 安装tmux sudo apt install tmux # Ubuntu/Debian brew install tmux # macOS # 配置文件 ~/.tmux.conf 关键项 set -g mouse on set -g prefix C-a bind r source-file ~/.tmux.conftmux的意义在于把“Agent会话”“测试运行窗口”“日志查看窗口”“Git操作窗口”同时铺开随时切换避免终端堆栈混乱。我常年维持三个会话work日常开发、lab试验性代码、log长期跟随服务日志。zsh方面我核心依赖三个插件zsh-autosuggestions历史命令自动建议、zsh-syntax-highlighting命令语法高亮、zsh-completions。同时配了几个高频aliasalias gsgit status alias gdgit diff alias glgit log --oneline --graph alias claudenode --input-typemodule -e import(\anthropic-ai/claude-code\).then(mm.main())最后这一行是绕开全局环境变量问题、直接用项目内Node拉起Claude Code的姿势。这个如果不配你在切换Node版本时经常遇到“command not found”的尴尬。2.3 与VSCode的共生必要时候回血虽然半年没主动打开VSCode但有一类场景我会主动“回血”处理git冲突。Agent改代码再快也架不住多分支并发时冲突解决。我试过让AI去解冲突成功率一半一半一旦冲突逻辑复杂比如两边都改了核心状态管理AI很容易合并出“编译通过但运行时崩溃”的代码。所以我给自己立了个规矩涉及3个文件以上的冲突老老实实打开VSCode用图形化合并工具。还有一种是配置STM32这类嵌入式工程。VSCode里的C/C插件、CMake插件、调试配置已经非常成熟AI Agent能帮你写配置代码但最终烧录、调试、看寄存器还是要靠IDE或专门的调试器界面。这时候别硬撑着只用终端工具该用就用文章标题只是描述“写业务代码”的常态不是自缚手脚。3. 实操过程一个真实功能的改造记录3.1 需求描述与提示词设计前阵子我给一个内部数据平台做权限模块改造。原始需求把原来基于角色的权限判断改成基于用户-角色-权限三层的映射模型并且兼容旧数据。我总结了一下我当时给Claude Code的提示词注意结构项目背景Node.js Prisma PostgreSQL权限相关代码在 src/permission/* 需求将当前基于 role 的单一判断改为 role permission 的映射模型 要求 1. 保持现有 API 返回结构不变 2. 数据迁移脚本要兼容旧库里的 role 字段 3. 更新单元测试覆盖旧角色映射到新权限的case 4. 不要改数据库连接配置 先给出改造方案确认后开始执行。这段提示词的价值在于交代了背景、约束条件、验收标准同时要求它“先给方案确认后再执行”。我强烈建议所有人都采取这种模式。AI不是神它需要清晰的范围边界。如果你只说一句“帮我改权限模块”它会把你的项目翻个底朝天改出几百行无关代码。3.2 Agent生成代码的过程与关键修改点Claude Code收到提示词后先打印了一份改造方案包括迁移SQL草稿、关系映射的数据流、以及新旧接口的兼容处理。我没让它立刻动手而是自己读了一遍方案发现它忽略了旧系统里“管理员”角色直接拥有所有权限这个约定于是追加了一句补充旧角色 admin 需要保留全部权限不能映射到普通角色需要在迁移函数里单独处理。它立刻更新了方案然后开始改Prisma schema、生成迁移脚本、修改service层和中间件。整个过程发生在tmux窗口内我能看到它每步执行了什么命令、改了哪些文件。真正让我意外的是它自己跑起测试后发现两个旧用例失败又反查代码定位到是中间件里一处includes判断和迁移后的数据结构不一致然后自己修掉了。这已经不是“补全代码”而是完整的“发现问题-定位问题-解决问题”闭环。我实际操作的心得是Agent在执行长任务时你要像对待一个新同事那样给反馈。它做对了一部分鼓励它它进了死胡同及时打断它给出方向。我一般会让它在关键节点停下来问我已经完成 schema 和迁移脚本前端相关接口是否需要同步修改类型定义这种“人在环路”的交互方式比放任它一口气跑完要稳得多。3.3 验证、测试、上线的完整节点生成代码只是第一步验证环节才见真功夫。我总结的验证清单如下跑完整测试套件npm test不会骗人至少确认没有回归手动构造边界数据比如旧系统里的空角色、用户多角色、权限覆盖冲突等场景检查迁移脚本幂等性同一个迁移能否安全地跑两次审查diff中是否有临时调试代码、硬编码密钥、不合理的any类型我遇到过AI为了编译通过悄悄给一堆变量标了any在预发环境跑一遍旧数据的真实迁移再执行一次关键接口冒烟测试。这一次改权限模型从Agent开始动手到我上线总共花了两个下午。其中真正用于写代码的时间不到20分钟剩下时间全部在审查、补测试、调数据。这也奠定了我后续所有AI辅助开发的节奏让AI负责“快”让自己负责“稳”。4. 常见问题与排查技巧实录4.1 问题速查表实操半年我把高频问题整理成了一张表遇到类似情况按表排查效率很高现象可能原因排查与解法改了个文件其他文件也被莫名修改Agent上下文不干净读到了无关项目文件重启会话限制--ignore或指定工作目录代码编译通过但运行时疯狂报错AI幻想了不存在的API或错误理解了数据流让它先读关联调用链文件再改强制要求给每一步依据反复修改同一个问题始终修不好Agent陷入局部极小值在错误假设里打转打断它明确告诉它“你的前提错了”并提供新的线索测试用例被悄悄删除或注释AI为了“让测试通过”而破坏了测试完整性diff审查时重点看测试文件不允许任何测试被删除命令执行失败但Agent假装成功Agent对shell输出理解错误要求它显示每条命令的完整输出并解释失败原因Git分支变得很乱Agent在自动执行git操作时切错分支或乱commit给终端Agent加README说明禁止它擅自push或切换分支4.2 避坑技巧上下文管理、权限控制、防AI幻觉第一个坑是上下文管理。Claude Code会读取项目上下文但如果你的项目里有巨大的node_modules、生成目录、日志文件它会把大量token浪费在无关文件上。解决办法是准备好.claudeignore文件作用相当于.gitignore把不需要关注的统统排除掉。我还习惯在每个独立需求开始前新建一个会话让上下文只跟这个需求相关避免上一个需求残留的信息污染新一轮判断。第二个坑是权限控制。Agent在终端里能执行任意shell命令这既是优势也是安全风险。我的规矩是允许它读文件和写代码但git push、rm -rf、生产环境切换这类高危操作全部在提示词里禁止必要时用别名或脚本拦截。有一次我让它跑数据库迁移它差点直接连上生产库——当时我心跳都停了一下。从那以后我在所有项目里都会在claude环境变量里指定export CLAUDE_CODE_ALLOW_COMMANDS[git status,git diff,node test/*.test.js]限制它只能跑白名单命令。不要嫌麻烦安全永远是第一优先级。第三个坑是防AI幻觉。AI擅长一本正经地编造不存在的函数或过期的API。我最有效的防御手段是让它先“搜出来再改”要求每改一个调用点必须先展示当前文件里已有的函数签名或类型定义再基于定义修改。这样它的“依据”是真实代码而不是训练数据里的“模糊记忆”。4.3 什么时候不适合用AI Agent写代码不是所有场景都适合让AI动手这是很多刚接触Agent的人容易忽略的。按我的经验下面这几类场景我会明确选择人工老系统里没有任何测试、变量命名混乱、全是一两千行的巨型函数。Agent进去基本是盲人摸象改动一处容易连带出无数隐藏问题安全性极高或涉及资金核心逻辑的代码。验证成本太高AI的任何一个细微错误都可能造成真实损失需要反复跟产品经理对需求、边聊边改的小改动。直接手写更快开一个Agent会话的等待成本反而更高需要深度理解业务术语的场景。比如金融衍生品定价、复杂的合规规则AI没有足够的领域背景生成代码往往是“样子货”。我的判断标准其实非常简单如果这段代码写错后排查调试的成本会大于人工写的成本那就别用AI。AI省的是“打字时间”不省“决策和排查时间”。5. 半年下来我的体会这半年我最大的改变不是工具变了而是工作心态变了。以前我写代码会有一种“我必须掌控每一行”的执念写完了还要反复看总怀疑有烂代码。现在我不需要每一行都自己敲但我会要求自己理解每一行为什么存在。AI负责把这些行“变出来”我负责判断它该不该存在、放在哪里合适、边界条件有没有漏。这种分工让我把精力花在真正重要的架构决策和业务理解上而不是被细节淹没。最后分享一个我一直在用的小技巧每次给Agent下达需求前我会花两分钟把需求先写成一个10行以内的伪需求文档包括背景、现状、目标、禁止事项。这个文档同时服务于两个目的一是让Agent一次就理解到位减少来回拉扯二是作为后续审查diff的checklist。我在这些文档里踩过无数次“说一句做一句”的坑后来才意识到和AI协作最重要的能力不是会写代码而是会提需求、会审代码、会踩刹车。掌握这一点比装什么插件、配什么环境都重要。
阅读完成 · 觉得有帮助？
