企业官网建设流程全解析

诚实地讲，我从写第一行代码起就是个VSCode重度用户，快捷键熟练到肌肉记忆，主题、插件、settings.json折腾了几十遍。但过去半年，我主动打开VSCode的次数一只手数得过来。不是卸载了，而是整个写代码的流程被AI Agent彻底重构了——我现在大部分时间泡在终端里，对着一个会话窗口说需求、审diff、跑测试，编辑器反而变成了偶尔用来检查复杂合并结果的“回血工具”。今天就把这半年我实际跑通的这套工作流、踩过的坑、以及哪些场景千万别让AI写代码，一次性讲清楚。

1. 从“写代码”到“审代码”：我的工作流重塑

1.1 一个典型需求的处理链路

过去我拿到一个需求，第一反应是打开VSCode，找到对应文件，手敲代码。现在完全不是这个顺序。我的标准链路变成了：

1. 在终端里打开一个AI Agent会话，把需求说清楚，附上相关文件路径或已有的接口文档；
2. Agent自动扫描项目结构、读取关键上下文，然后给出一个修改方案；我确认思路后它直接改代码；
3. 我逐行审查它生成的diff，有问题直接在会话里指出“这个函数命名不够清晰”“这里少写了个空值判断”，它立刻修正；
4. 确认无误后我跑测试、手动点几个关键路径，完成收尾。

这个过程里，我更像一个代码审查者、架构决策者和“产品经理转述人”，而不是第一落笔的人。半年下来，我发现自己从来没这么轻松过，但也从来没这么需要警惕过——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 Code（Anthropic官方提供的命令行Agent工具），配合Web端Claude做方案设计；偶尔用Cursor处理不熟的技术栈项目；GitHub Copilot则只在我的Vim/终端里当作一轮快速补全的备用。

这段时间经常有人问我“哪个AI写代码最强”，我的答案是：没有最强的，只有最合适的场景。我整理了这么个对比表，方便你按需求选：

我个人的经验是：如果你日常开发场景是“一个需求涉及多个文件、有完整的测试体系、需要反复迭代”，直接上终端型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.conf

tmux的意义在于把“Agent会话”“测试运行窗口”“日志查看窗口”“Git操作窗口”同时铺开，随时切换，避免终端堆栈混乱。我常年维持三个会话：work（日常开发）、lab（试验性代码）、log（长期跟随服务日志）。

zsh方面，我核心依赖三个插件：zsh-autosuggestions（历史命令自动建议）、zsh-syntax-highlighting（命令语法高亮）、zsh-completions。同时配了几个高频alias：

alias gs='git status' alias gd='git diff' alias gl='git log --oneline --graph' alias claude="node --input-type=module -e 'import(\"@anthropic-ai/claude-code\").then(m=>m.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 问题速查表

实操半年，我把高频问题整理成了一张表，遇到类似情况按表排查效率很高：

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协作最重要的能力不是会写代码，而是会提需求、会审代码、会踩刹车。掌握这一点，比装什么插件、配什么环境都重要。