企业官网建设流程全解析

"上半年翻开发开记录时，我自己都愣了一会儿：最后一次主动打开 VSCode，已经是五个多月前的事了。不是换了别的编辑器，也不是转行了，而是过去半年里，绝大多数“写代码”的动作，都被 AI 拿走了。最初我对 AI 写代码是很抗拒的，总觉得它只能补个片段、凑个函数，离真正能干活还差得远。但等到我认真把 AI Agent 当作主力开发搭档之后，传统 IDE 的使用频率突然就降了下来。这篇东西就是想聊聊：这段时间我的工作流到底发生了什么变化，AI 写代码解决了什么问题，哪些坑我替你踩过了，以及为什么我说“半年没打开 VSCode”并不意味着编辑器没有用了。"

1. 为什么我半年没打开 VSCode：工作流的迁移真相

1.1 我不是抛弃了编辑器，而是换了个“驾驶舱”

很多朋友看到标题，第一反应是“你直接躺平了吗？”。其实不是。我依然每天看代码、调问题、改逻辑，只是大部分时间不再是“我手动敲代码”，而是“我告诉 AI 做什么，然后审它做出来的结果”。

这种感觉很像从手动挡换成了带辅助驾驶的车：油门刹车还在你脚下，但巡航、变道、跟车这些重复操作，系统帮你接过去了。你需要做的，是盯着路况、判断什么时候接管。我把代码编辑的重心从“一个字一个字敲”变成了“一段话一段话描述需求”，VSCode 那个界面自然就很少打开了。

严格来说，我并没有删掉 VSCode，它还在硬盘里，偶尔还会用。但半年下来，我的常用开发环境变成了“终端 + AI 客户端 + 浏览器”，绝大多数操作在命令行里用 AI Agent 完成。VSCode 的启动频率从每天十几次，掉到了一个月两三次。

1.2 触发我迁移的几个真实原因

我认真复盘过，自己是从什么时候开始不用 VSCode 的。不是因为哪家 AI 工具宣传得猛，而是几个特别实际的问题让我不得不变。

第一个原因是重复劳动太多了。我大部分工作不是发明新算法，而是写接口、配参数、调格式、补单元测试。这类活儿用传统的“人肉敲代码”方式效率极低，尤其是一个接口从 Controller 写到 Service 再写到 DAO，每个文件结构都差不多，差别就是字段名和业务逻辑。AI 对这种模式化任务极其擅长，我只要把表结构或者需求文档丢给它，它能把整套模板代码一次铺开。

第二个原因是 VSCode 的维护成本让我心累。你有过“配置环境配了一下午，代码一行没写”的经历吗？我之前就经常这样。比如 VSCode 写 C 没有代码提示，十有八九是没装 C/C++ 扩展或者 includePath 没配；Python 环境换个解释器，插件就闹情绪；再来个 STM32 开发环境，光调试器配置就能让人崩溃。这些事在传统的 IDE 里都是隐性时间成本，而 AI 恰恰能帮你快速定位配置问题、生成配置文件，甚至直接在命令里把所有步骤跑完。

第三个原因是我接手老项目时被坑了一次。有次接手一个年代久远的 C++ 仓库，VSCode 打开之后全是红波浪线，代码跳转完全失效。我折腾了半天，最后把整个构建流程和头文件关系交给 AI 梳理，它给我整理出清晰的依赖关系，还顺带生成了正确的c_cpp_properties.json。那一刻我很清楚地意识到：原来我花时间解决的问题，根本不是业务问题，而是工具链问题。把这个环节交给 AI，省下来的精力可以用在真正重要的东西上。

2. AI 写代码的核心能力拆解：从补全到 Agent

2.1 三层能力：行级补全、对话生成、自主执行

现在很多人一说“AI 写代码”，想到的还是最早那种“光标后面跟着灰色提示代码”的补全工具。那只是第一层能力，而且说实话，它并没有从根本上改变开发方式。真正改变工作方式的，是后面两层。

我这个分层，是自己实际用了半年之后总结出来的：

• 第一层：行级补全。你在 VSCode 里装个 AI 插件，它根据你当前的上下文预测下一段代码。这个能力适合手写代码时的加速，但本质上还是“人在主导，AI 帮忙接话”。
• 第二层：对话生成。你可以直接描述需求，AI 返回一段完整代码或一个方案。它解决了“从需求到代码”的翻译问题，但还是需要你手动复制、粘贴、保存。
• 第三层：Agent 自主执行。这个差别很大。AI 不仅生成代码，还能自己改文件、跑构建命令、执行测试，失败了它会读报错、定位问题、继续修复，直到任务完成。人只需要在关键节点做决策和验收。

2.2 为什么 Agent 比补全插件更改变工作方式

补全插件提升的是“打字速度”，Agent 提升的是“完成任务的速度”。举个例子：让我写一个“用户注册接口”，补全插件能帮我写个函数签名、补几个参数，但后续的控制器逻辑、参数校验、数据库操作、异常处理、单元测试，全都得我自己一步步来。

Agent 不是这样。我只要把需求说清楚，它会自己找项目里现有的风格，新建对应的文件，把注册逻辑补全，还会跑一遍现有测试，甚至主动发现“这个接口没有防重复提交”然后提醒我。这种体验的改变是巨大的：我从“执行者”变成了“验收员”。

但这里必须泼一盆冷水。Agent 只适合定义清楚的任务，任务边界没画好就会翻车。你把一个大仓库甩给它说“帮我优化一下”，它可能热情地改了几十个文件，最后把你代码风格全带偏了。所以后面我总结了一套提示词和规则设置的方法，把 Agent 的能力关在笼子里用。

3. 我的 AI 编程工作流与提示词工程实战

3.1 给 AI 设定规则：一个可复用的 System Prompt 模板

很多人用 AI 写代码，上来就一句“帮我写个登录模块”，然后抱怨结果不好。问题不在于 AI 能力不够，而在于你给的上下文太少、约束太松。我自己现在不管用哪个工具，第一件事都是先给它立规矩。

下面这个模板，我几乎每周都会用到，你可以直接抄走：

你是一名资深后端工程师，负责维护我这个 Python 代码仓库。 工作约束： 1. 优先使用项目已有依赖，不要随意引入新库；如必须新增，请先说明理由。 2. 代码风格与项目现有模块保持一致，不要擅自重构无关代码。 3. 改动前，先列出你计划修改的文件清单和实现思路，等我确认后再动手。 4. 每完成一个任务，必须运行测试命令，并贴出结果。 5. 注释使用中文，提交信息遵循 Conventional Commits 格式。

这个模板看起来简单，但它把角色、边界、流程、验收标准全都定死了。AI 就不再是“即兴发挥”，而是按你的规则执行。有人觉得“AI 写代码不需要提示词工程”，那是没吃过“它给你改了一大片无关代码”的亏。

3.2 提示词工程的四个关键技巧

我踩了无数次坑之后，总结出四个最管用的技巧，分享给想用 AI 写代码的人。

第一，任务拆分，一次只做一件事。不要试图让 AI 一口气完成一个大型功能。把需求拆成“建表脚本”“写数据模型”“写查询接口”“写单元测试”四步，每一步单独扔给它，成功率远高于一次塞一个大需求。

第二，给足上下文。AI 不知道你的项目结构，你不能只给一句话。要告诉它文件路径、相关函数名、报错信息，甚至贴一段现有代码。上下文越充分，生成结果越贴合实际。

第三，先要方案，再要代码。我现在的习惯是，让 AI 先给我列实现思路，关键取舍讲清楚，我确认没问题之后，才让它写具体代码。这样能提前把方向跑偏的问题扼杀在摇篮里。

第四，明确验收标准。告诉它“写完之后跑一下测试，保证全通过”比说“写一个功能”有用得多。AI 会自己循环尝试，直到测试通过为止。

我最开始用 AI 写代码的时候，提示词就是一句话：“帮我写个用户列表接口”。结果它给了我一个独立脚本，里面用的是requests直接请求第三方 API，完全没接我项目的数据库。第二次我贴上了路由文件、模型文件和相关依赖，它生成的代码基本能直接用。差别就这么大。

3.3 多 AI 协作与工具选型

还有一个很多人没试过的玩法：让多个 AI 互相配合。我现在写一个稍微复杂的模块时，会用一个模型负责生成初版代码，另一个模型负责代码审查，专门挑毛病。

为什么要这么干？因为不同模型训练数据、优化方向不一样。有的生成能力强，但有时候过于自信，会“一本正经地胡说八道”；有的思考链路长，适合做 review 和问题定位。把这两类组合起来，质量会明显比单模型高。我常跟朋友说：写代码的人写错，审代码的人抓住，这个模式跟人类团队协作其实是一个道理。

至于工具选型，我不太愿意做“谁最强”的绝对排名，因为不同场景差异太大。但我可以把市面上主流方案按场景分一下类，方便你对号入座：

我自己的选择是“终端型 Agent 主力 + 另一个模型做 review”。这套组合跑了半年，稳定性够用。但我不建议新手一上来就跟我一样，可以从 IDE 内嵌 AI 插件开始，跑通再进阶。

4. 实操：从 VSCode 迁移到 AI 工作流的完整步骤

4.1 第一步：先盘一下你的仓库

如果你也想试着把工作流迁到 AI 上，不要急着让 AI 干活，先整理仓库。AI 对你的项目一无所知，你需要给它一张“地图”。

我现在的每个项目里都会放一个AGENTS.md文件，里面写清楚：项目是干什么的、目录结构是什么、入口文件在哪、构建命令和测试命令是什么、代码风格有什么要求。这个文件不写给人类同事看，就写给 AI 看，但它带来的收益远超你想象。

比如我的一个 Python 服务项目，AGENTS.md开头是这样的：

# AGENTS.md 这是一个 FastAPI 服务，提供用户和订单两类接口。 - 代码入口：app/main.py - 路由文件：app/routes/ 按资源拆分 - 数据库：SQLAlchemy 2.x + PostgreSQL - 测试命令：pytest tests/ -v - 代码风格：black + isort，保持函数纯逻辑，不写冗余注释

有了这个文件，AI 每次动手前都会先读它，相当于你给新成员发了一本入职手册。之后让它写代码，出错的概率会低非常多。

4.2 第二步：让 AI 做一次“小范围重构”

接下来，用一个真实小案例演示完整流程。我最近把一个老的配置读取模块重构过，原本是一堆手写的if/else分支读取不同配置项，既不安全也不好扩展。

我的提示词大概是这样的：

这个项目里有app/config.py，现在读取配置的方式是裸露的字典加 if/else。请重构为 dataclass 加类型校验，保持对外函数名不变，最后跑一下pytest tests/test_config.py -v，确保所有测试通过。改动文件范围限定在app/config.py和对应测试文件，不要碰其他模块。

AI 返回了一个方案：用dataclass定义AppConfig，写load_from_dict做类型转换和缺失值检查，用functools.lru_cache做全局缓存。我觉得方向没问题，让它执行。执行过程中它自己发现有个测试断言的是老结构，顺手把测试改成了新接口，跑了两轮，全绿。

这件事放在以前，我自己写至少得小半天。AI 大概五六分钟就完成了，而且它还主动补了缺失字段的默认值，考虑得比我还周全。这就是一个很典型的“AI 写代码”的正确姿势：小范围、有边界、有验收标准。

4.3 第三步：从 AI 输出到代码合入的检查清单

AI 把代码写完了，不代表可以闭眼合入。我给自己定了一个检查清单，每次 AI 跑完任务都要过一遍：

• 改动范围是否符合预期？我给了“只改这两个文件”的限制，AI 如果私自改了第三个文件，立刻回退重来。
• 依赖是否新增了？如果版本文件里多了几个之前没有的库，必须让 AI 解释理由。
• 测试是不是真测试？有些 AI 生成的测试只有“跑了一遍没报错”，断言写得稀烂，等于没测。我会扫一眼断言是否覆盖核心逻辑。
• 提交信息是不是清晰？AI 生成的提交信息经常是“refactor config module”，太笼统，我会让它按规范重写，写清楚改动原因。

这套清单我打印在自己的笔记里，实战中救了我很多次。尤其是“测试是不是真测试”这一条，AI 特别容易“自说自话”，跑通就认为自己任务完成了，实际上只是把测试写得很弱。

你在传统 VSCode 里清理删除分支，要右键、找分支、点删除，有时候分支多了还容易误删。现在我在命令行里直接跟 Agent 说“把已经合并到主分支的本地分支都清理掉”，它会把git branch --merged列出来，逐个确认再删。这就是工作流迁移的质感：原来图形界面里反复点的操作，现在一句话就解决了。

4.4 第四步：训练自己“看得懂 AI 代码”的基本功

说了这么多 AI 的好处，有一个底线我一直没放松：基础能力不能丢。

AI 生成代码的速度越快，代码审阅的能力就越值钱。你可以不会手写每一行，但你得能看懂它为什么这么写，知道哪里可能藏雷。我见过不少新手，把 AI 当万能 API，不管报什么错都把锅甩给 AI，结果项目越改越乱。真正有效的姿势是：AI 负责产出，你负责把关，两头都不能少。

我自己的做法是，每周还是会花一点时间刷算法题、读开源源码，维持对代码的敏感度。半年下来，我的“手写代码”量少了，但“读代码”的能力加强了，综合产出反而更高。

5. 常见问题与排查技巧实录

5.1 AI 生成代码的翻车现场速查表

我用 AI 写代码半年，翻车次数两只手数不过来。下面是我整理的高频问题对照表，你遇到了可以直接照着排查：

最坑的是第一种。有次它给我生成一个用retry库重试 HTTP 请求的代码，我一看版本文件里多了一个我没听过的库，去查才发现这个库好几年前就不再维护了。从那以后，我加了一条规则：要引入新依赖，必须先把理由说清楚，而且我会让另一个模型同步审查一遍。

5.2 VSCode 那些高频问题，我替你重查了一遍

你可能会好奇：既然我半年没打开 VSCode，为什么对它还这么熟？因为之前用得太多了，那些搜索记录到现在还在热搜里挂着。趁这次机会，我把几个高频问题顺带整理一下，你如果还在用 VSCode，直接抄答案。

VSCode 写 C 没有代码提示，多半是没装 C/C++ 扩展，或者编译器路径没识别到。最简单的方法是用扩展生成c_cpp_properties.json，把includePath指到正确的头文件目录。

VSCode 配置 Python 环境，先确认你在命令面板里选了正确的解释器，再确认pylint或pyright插件启用。环境变量别乱配，用.env文件管理最省心。

VSCode 汉化，装上“中文（简体）语言包”插件，然后在命令面板里搜 “Configure Display Language”，选zh-cn重启即可。

没有编辑过的文件会自动关闭，这个是我以前最烦的默认行为。在设置里搜workbench.editor.closeEmptyGroups，关掉它就能避免那些“空标签页自动消失”的问题。

黄色高亮占好几行，一般是 lint 或类型检查的波浪线，它把整行都标黄了，看起来很脏。你可以调整问题面板，或者安装类似 Error Lens 的插件，把错误信息压缩到行尾显示，代码区会干净很多。

这些配置不是说我不会，而是这套东西的维护成本太高了。每次换机器、换项目、换编译器，都要重新折腾一遍。现在我把这些精力省下来，留给真正需要思考的业务逻辑。

5.3 我踩过的坑清单

除了上面那张表，还有几个教训，值得单独拿出来说，因为它们不是“技术问题”，而是“使用姿势问题”。

第一个教训：不要把生产分支直接交给 AI 改。有次我图省事，让 Agent 直接在main分支上重构一个支付状态机，结果它中途改崩了，还提交了好几个中间状态。从那以后，所有 AI 相关改动都先切 feature 分支，跑完全部测试再合入，绝不偷懒。

第二个教训：别让 AI 在“没有规则”的状态下自由发挥。一开始我没写AGENTS.md，AI 改代码时用了完全不同的命名风格，把驼峰改成下划线，我 review 的时候差点没认出来。后来我花了一个下午把所有项目的AGENTS.md补齐，世界清净了。

第三个教训：AI 不是搜索引擎。有些问题它回答得非常自信，但答案可能是错的。尤其是“这个 API 的某个参数怎么传”这种时效性很强的问题，还是要去查官方文档。AI 写业务代码我很放心，但涉及底层 API 的最新签名，我习惯让它把官方文档链接一起贴出来，我再核实。

6. 什么场景我会重新打开 VSCode

6.1 嵌入式开发与底层调试

我必须承认，AI 写代码并不是万能的，至少在我最熟悉的嵌入式领域，VSCode 依然有一席之地。比如 STM32 开发环境，涉及交叉编译链、J-Link 调试、寄存器查看、内存窗口，这些传统 IDE 的能力，Agent 很难完全替代。

不是不能生成代码，而是调试过程的“临场感”很重要。当程序跑飞了，你要看寄存器、看调用栈、看外设状态，这些操作在编辑器里做比在命令行里做高效得多。我上个月就重新打开过 VSCode，配了一次 STM32 的调试环境，用 J-Link 单步跟踪一个 RTC 初始化问题。这种场景，我不会强行让 AI 来扛。

6.2 深度 review：大段 diff 还是需要 IDE 视图

AI 改完代码之后，我总是要自己在编辑器里看一遍最终的 diff。命令行里看 diff 虽然也可以，但复杂改动时图形化的对比视图明显更清楚，能快速看到哪一行被改了、哪里的缩进乱了、哪个函数被挪走了。

所以我的工作流不是“永远不开 VSCode”，而是“AI 输出阶段不开，人工审阅阶段开一下”。审阅完没问题，我再回到终端继续下一个任务。它对我来说就像验货台，而不是生产线。

6.3 什么时候我宁可不让 AI 写

最后说一个更重要的判断标准：涉及钱、安全和并发的地方，我宁可自己手写。

支付回调、库存扣减、分布式锁、幂等控制——这些场景一旦出错，后果不是“改个 bug”能弥补的。AI 写这类代码，我总是不敢直接信任，哪怕它逻辑看起来没问题，我也要自己一行一行抠。不是因为 AI 一定出错，而是这些代码的验收标准不只是“测试通过”，还需要考虑竞态、数据一致性、异常恢复等边界条件，这些恰恰是 AI 最容易被训练数据掩盖的盲区。

所以我的原则很简单：普通业务代码大胆放权，核心底层逻辑牢牢握住。这不是对 AI 的不信任，而是对工程质量的基本敬畏。

我自己这半年最大的体会是：工具链的重心从“编辑器”变成了“对话”，但该有的代码能力一点都没消失，反而更重要了。AI 写得越快，你需要判断的地方就越多。那些以为“AI 写代码之后程序员就躺赢”的人，大概率会在项目越来越乱的时候被现实教育。

如果你也想试试这条路，我的建议是别想着一步到位。先挑一个你熟悉的小项目，写一份AGENTS.md，找个顺手的 AI 工具，让它帮你完成一次带测试的小范围重构。完整跑通一次之后，你会自然体会到“让 AI 干活、你来做验收”到底是一种什么感觉。到那时候，VSCode 多久打开一次，就只是个数字问题了。