企业官网建设流程全解析

过去三个月，我做业余项目的方式发生了很彻底的变化。以前打开编辑器第一步是新建文件、手写 import，现在第一步是打开 AI 对话窗口，把脑子里的一句话需求扩写成一大段自然语言描述，然后看着代码像开了水龙头一样流出来。这就是很多人说的 vibe coding，一种以 AI 辅助编程为核心的工作方式。它不是一个软件，不存在“vibe coding 下载”这种说法，你需要的是像 Cursor、Copilot、Claude Code 这类 AI 编码工具，再配合一套适合自己的使用节奏。

这个概念最早是 Andrej Karpathy 在 2025 年初带火的，原话大意是：你不再逐行写代码，而是用自然语言描述需求，让 AI 生成代码，你负责运行、测试、反馈，遇到报错就把报错贴回去让它修，整个过程更像是在“跟着 vibe 走”。很多人一听就觉得这是偷懒、是外行的狂欢，但我实际用了三个月、断断续续做完七八个小项目之后，我的结论是：vibe coding 确实改变了写代码的方式，但真正用它提效的人，恰恰是那些编程基本功很扎实的人。

这篇文章我会把工具选型、需求拆解、完整实操流程、常见翻车场景和自己的一些心得全部摊开讲。想入坑的朋友可以直接照抄，已经在用的朋友也可以看看有没有自己没试过的思路。

1. vibe coding 到底在说什么

1.1 从“写代码”到“描述代码”的思维转变

传统编程的链路是：需求分析、设计数据结构、拆模块、写实现、自测、联调。每一步的决策都是由人做出，代码只是最终表达。vibe coding 的链路则完全不同：你把需求用自然语言描述出来，让 AI 生成第一版代码，然后运行、观察输出、把报错和期望一起反馈回去，AI 再改，循环往复，直到功能跑通。你不再是一个逐行敲代码的“打字员”，更像是一个拿着图纸的包工头，AI 是施工队，你负责把需求说清楚、验收成品、在不行的时候喊返工。

这里的核心转变是：判断力比书写能力重要得多。你不需要记住每一个 API 的拼写，但你需要能看懂 AI 写的代码是不是在瞎写；你不需要精通每一种数据结构，但你要能指出“这段逻辑在并发场景下会出问题”。说白了，vibe coding 降低了“把想法变成代码”的门槛，但没有降低“判断代码好坏”的门槛，甚至因为代码生成太快，对判断力的要求反而更高了。我见过不少朋友让 AI 生成了一大堆代码，跑起来看着没问题，结果一压测就崩，一审查就发现全是致命伤，这就是因为只用了 vibe，没带脑子。

1.2 哪些项目适合 vibe coding，哪些不适合

我个人的判断标准很简单：看这个项目的出错成本有多高，以及它是不是“可丢弃”的。适合 vibe coding 的项目包括：原型验证、内部小工具、脚本、一次性数据处理、数据可视化、demo 和练习项目。这些项目追求的是“赶紧跑起来看看效果”，即使代码写得不够好，损失也有限。

不适合的项目也很明确：高性能核心模块、涉及资金或用户隐私的逻辑、安全关键组件、大型遗留代码库的复杂改动。原因很简单，AI 生成的代码可以“跑通”，但不保证“跑得最优”，更不保证“安全”。它可能写出一个能用但复杂度爆炸的算法，可能忘记做边界检查，可能在数据库操作里埋下注入隐患。你让 AI 去改一个你已经维护了三年的老项目的核心链路，它很可能会把你不小心设计好的例外处理全部打乱。

我的建议是：把 vibe coding 用在“错了可以扔掉重来”的场景，把“出事故要担责任”的场景留给自己一行一行写。这不是不信任 AI，而是对生产环境保持最基本的敬畏。

2. 干活前先想清楚：我的 AI 辅助编程工作流

2.1 工具选型：Cursor、Copilot、Claude Code 到底怎么选

先说结论：没有最好的 AI 编程工具，只有最适合当前任务的工具。我这段时间的主力组合是 Cursor 负责小型原型和日常编辑，Claude Code 负责复杂点的一次性任务，GitHub Copilot 作为 IDE 里的补全兜底。三者的体验差异其实挺大，我给它们做了个简单对比：

选型逻辑不是参数越强越好，而是要看你和工具之间的“反馈循环”快不快。vibe coding 的本质是高频迭代：你提出需求、AI 生成、你验证、反馈、再生成。这个循环越快，你进入心流状态越深，效率也越高。所以我会优先选择那些打开快、上下文加载方便、报错粘贴回去就能直接处理的工具，而不是功能全但操作繁琐的大家伙。

另外补充一点，这些工具目前基本都是订阅制或者带免费额度的服务，需要联网使用，价格也不是固定的，大家以官方页面为准就好。我的建议是别一上来就买最贵的套餐，先用免费额度做一个完整的小项目，体会一下哪种交互方式最顺手，再决定要不要付费。

2.2 需求拆解：把一句话变成可执行的 prompt

很多人 vibe coding 翻车的起点不是 AI 太笨，而是 prompt 太模糊。“帮我写一个爬虫”这种需求，连人类开发者也只会回一句“你要爬哪个网站、要什么数据、要不要反爬处理”，AI 当然也只能给出一堆泛泛而谈的框架代码。vibe coding 里最重要的技能之一，就是把脑子里的一句话需求拆解成可执行的 prompt。

我常用的 prompt 模板大概是这样的：

角色：你是一位熟悉 Python 的资深工程师 任务：写一个命令行工具，把指定目录下所有 .md 文件批量转成 .html 输入：目录路径、HTML 模板文件路径 输出：同名 .html 文件，保留相对目录结构 约束：

• 只需要支持标题、列表、代码块、图片这些常用语法
• 图片路径要替换为相对 HTML 文件的路径
• 用标准库实现，不引入第三方依赖 验收：运行 python convert.py ./docs ./template.html 后，docs 下的每个 md 文件都生成对应 html

这里面有几个关键点值得展开说。第一，角色设定真的有用，AI 在“你是资深工程师”的情境下给出的代码风格和质量会明显不同。第二，输入输出要具体，最好把一个输入样例和一个期望输出样例直接贴进去，AI 对具体例子的理解准确度远高于抽象描述。第三，约束条件要显式声明，比如“用标准库”“不引入第三方依赖”，否则 AI 默认会用最热门的第三方库来解决问题，而这可能根本不是你想在环境里安装的。

2.3 上下文管理：AI 记不住全部，你得替它记

上下文窗口是 AI 编程工具最容易被忽视的瓶颈。一个工具再强，它的记忆也是有限的，聊到后面你会发现 AI 开始忘记最开始定的技术栈、忘记你已经改过的文件、甚至开始重复提出已经否定过的方案。这不是 AI 变笨了，而是它的上下文里塞了太多中间过程的废话。

我现在的做法是：每开一个新对话，第一件事就是贴一份“项目简报”。这份简报固定包含三部分：项目目标、技术栈和目录结构、当前正在处理的任务。哪怕只有几行字，也一定要写清楚，这比让 AI 自己读了半天文件再猜测意图要高效得多。如果项目里有必须遵守的规则，比如“所有时间用 UTC 存储”“所有接口都要写单元测试”，我会单独维护一个规则文件，然后在每次对话开始前明确告诉 AI 去读它。

还有一个容易被忽略的点：不要在一个对话里塞太多无关任务。AI 不是不会做，而是做多了之后状态会乱。与其勉强接着聊，不如开一个新会话把任务重新描述一遍，干净利落。

3. 实操过程：从零做一个内部小工具的全流程记录

3.1 需求与初始 prompt

光讲方法论没办法完全说明白，我拿最近做的一个真实项目来复盘。我团队里经常有人要把 Markdown 格式的文档转成公司统一风格的 HTML 页面，手动复制粘贴太痛苦，所以我决定写一个批量转换工具。这个项目不大不小，非常适合作为 vibe coding 的典型样本。

2.2 里那个“批量 md 转 html”的 prompt 模板，其实就是我一开始给这个项目写的初始 prompt，不是编出来的。接下来我要重点说的是“贴样例”这个环节：我从公司的文档库里挑了一个最典型的 .md 文件，把它的完整原文和对应的期望 HTML 片段一起放进了 prompt 里。AI 看到具体的文件内容之后，生成的第一版代码就立刻理解了图片路径替换和模板注入的需求，而不是抽象地猜测。实测下来，这个环节节省的返工时间远大于粘贴那几行字的时间。

3.2 生成、测试、改 bug 的循环

第一版代码生成之后，我没有急着跑，而是先把代码从头到尾读了一遍。这是 vibe coding 里我最坚持的习惯：AI 生成的代码，人必须看一遍。这一步能发现很多一眼就能看出的问题，比如命名混乱、明显的逻辑缺口、甚至根本没用上你给的模板参数。

看完代码后，我建了一个测试目录，放了三篇不同复杂度的 Markdown 样例，然后运行脚本。果然第一轮就翻车了：AI 用正则表达式判断 Markdown 的列表层级，遇到嵌套列表时缩进全乱了。我把出错的输入文件、实际输出和一个“期望正确输出”一起贴给 AI，它很快意识到正则方案不行，主动提出改用逐行状态机解析，第二版就解决了问题。这件事给我的启发是：如果需求本身包含复杂的文本结构，一开始就应该在 prompt 里要求 AI“先简单描述实现方案，再写代码”，让它在写之前想清楚，而不是先写出来再等 bug 找上门。

中途还有一个让我印象深刻的 bug：AI 在处理空目录时抛出了 FileNotFoundError。我之前完全没想到这个边界情况，但测试样例里正好包含了一个空目录。所以别嫌测试麻烦，vibe coding 的测试用例本身就是对 AI 产出最好的约束。

3.3 代码质量把关：让 AI 写测试和自查

项目跑通只是第一步，代码能不能留下、敢不敢丢给别人用，才是更重要的。我在功能完成后会让 AI 做三件事：生成 pytest 单元测试、做一轮 code review、列出一份“这份代码可能被什么场景搞挂”的风险清单。

让 AI 生成测试有一个陷阱：它会顺着实现来写断言，等于用同一套逻辑验证自己，bug 藏在实现里时测试也会跟着错。所以我的做法是，让 AI 先写测试，再写实现，或者写完测试后我手动改几个断言里的预期值，看测试是不是真的会红。至于 code review，我发现让 AI 以“一个不熟悉这个项目的工程师”的视角来审视代码，效果比让 AI 夸自己好得多。我甚至会故意让它列出“这段代码会被攻击的三种方式”，用它来倒逼自己补防护逻辑。这些步骤听起来繁琐，但真心建议不要省。

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

4.1 AI 改一处崩三处，代码越改越乱

这是 vibe coding 里最让血压升高的场景：第一次修改很成功，第二次也没问题，第三次开始 AI 为了修一个小 bug，把原来好好的逻辑连带改坏，然后你继续让它修，它又在坏代码上打补丁，越改越乱。根本原因是 AI 在多次迭代中逐渐丢失了全局结构，几个小 patch 之间互相打架。

我的解决办法是：连续两次修改不满意，就果断回滚到上一版干净代码，重新把目标描述一遍，让它换一种思路重写，而不是在烂代码上继续打补丁。必要的时候直接在对话里说“不要修改现有代码，重新给我一个完整的实现”，这句话在多数工具里都有效。现在我也习惯在关键节点用 git commit 给 AI 的产出打标记，每次有突破性进展就提交一次，这样回滚起来非常从容。

4.2 上下文窗口被塞满，AI 开始胡言乱语

另一个高频现象是：对话进行很久之后，AI 开始重复提建议、忘记已经确认过的决定、甚至输出到一半就截断。这就是上下文窗口撑满了的信号。遇到这种情况，别犹豫，立刻开新对话，把项目简报重新贴一遍，把当前文件和目标说清楚，然后继续。很多人觉得这是浪费时间，但实际上续着旧对话让它硬干活，花的时间只会更多。

我还会把技术决策记在一个外部文档里，比如“已确定用标准库实现”“图片路径替换逻辑已经完成”“已知问题：不支持表格语法”。每次重开对话时让 AI 先读这个文档，它的状态恢复速度会快很多。这个习惯本质上是在用外部存储帮 AI 扩容，效果非常明显。

4.3 无中生有的 API 和幻觉依赖

AI 编程工具最坑的一点是：它会在极度自信的情况下编出根本不存在的 API、包名或参数。比如某次它让我用某个第三方库的某个函数，我查文档发现这个函数根本不存在；还有一次它推荐了一个听起来很合理的包，PyPI 上搜了一圈根本没这玩意。这就是所谓的“AI 幻觉”，在一个讲求精确的领域里，杀伤力比报错大得多。

应对策略只有一句话：凡是 AI 给出的依赖名，先查官方文档；凡是 AI 调用的 API，先看签名。你不需要验证每一行代码，但每条引入的依赖、每个不认识的函数，都必须人工确认。我把 AI 想象成一个很有热情但容易记错的实习生，它写的东西我可以欣赏，但对外发布前我一定要亲自验一遍货。

5. 一些只有真正多跑几个项目才能有的体会

5.1 vibe coding 提高的是速度，不是质量

我最深的体会是：vibe coding 真正提高的是“从想法到可运行原型”的速度，而不是代码本身的质量。以前做一个内部小工具，从构思到能跑，至少大半天；现在基本半小时到一个小时就能把第一版跑起来，这个速度提升是实打实的，但它并不自动带来更好的架构、更健壮的代码和更少的安全隐患。代码质量依然靠人，AI 只是把“生成代码”这个环节加速了十倍，把“判断质量”的环节留给了你。

也是因为这个原因，我始终觉得编程基本功越扎实的人，用 AI 辅助编程的效率越高。你自己能看懂 AI 写的每一行代码，能在它跑偏的时候准确指出问题，能快速验证它的产出——这些能力决定了你是把 AI 当杠杆，还是被 AI 带着走。就像自动驾驶再先进，一个会开车、懂交规的司机使用它才谈得上省力，连方向盘都没摸过的人坐在驾驶位上只会更慌。

5.2 几个能立刻上手的实操习惯

最后分享几个我觉得最有用的习惯，都是实际验证过的小技巧。第一，给 AI 设定角色和身份，一句“你是一位资深的 Python 后端工程师”开头，产出的代码质量和风格确实会不同；第二，对于复杂任务，先让 AI 用三五句话说清楚打算怎么实现，再让它动手，这一步能拦下大量跑偏；第三，做完一个功能后让 AI 顺手写一份 README，在写 README 的过程中它常常能发现一些被忽略的边界条件；第四，重要节点一定 commit，AI 的产出也要纳入版本管理，这是我最庆幸早早就养成的习惯。

如果你现在还在观望，我的建议很直接：找一个不起眼的小项目，低预期地让它翻几次车，你自然会理解 vibe coding 到底改变了什么。这种工作方式不神话 AI，也不贬低手工编码，它就是给“想法快速落地”这件事多开了一扇门，至于进门之后能走多远，终究还是看你自己。