企业官网建设流程全解析

Vibe Coding 个人成长指南——从AI初学者到独立完成项目的复盘

写这篇文章的目的，是想坦诚地复盘自己在 AI 编程项目中暴露的能力短板，以及通过实战和自学获得的真实提升。如果你也是一个「技术懂一点、业务懂一点，但两边都不够深」的半桶水开发者，这篇文章应该能给你一些参考。

一、开篇

1.1 技术半桶水：懂规范但没大项目经验

我的技术背景是这样的：

• 上学时学过编程，懂一些代码规范，知道什么是好的代码结构、什么是异常处理、什么是模块化
• 做过一些课程项目和小型个人项目，代码能跑起来，但没接触过真正的大型项目
• 了解一些技术概念，比如微服务、CI/CD、版本控制，但都是「知道有这个东西」，没有在实际项目中深度实践过
• 做过一个医疗设备上位机项目（C# WinForm + 串口通信），在那个项目里我也注重代码注释、异常处理、串口重试逻辑、渲染性能优化这些东西，但毕竟是单人维护的桌面软件，规模有限

简单说：我知道「应该怎么做」，但没有在复杂项目中验证过「怎么做才对」。代码规范我能背出来，但真到了要设计一个可扩展的架构、要做模块解耦、要做自动化测试的时候，我心里是没底的。

1.2 业务半桶水：懂流程和用户故事但没实际大业务

我的业务背景来自一段咨询公司的实习经历：

• 跟着顾问做过需求调研，参加过客户会议，写过会议纪要
• 学过画原型，做过员工预备入职、组织架构树这些功能的原型设计
• 学过写用户故事和用户旅程图，知道什么是冒烟测试、边界值测试、黑白盒测试
• 写过功能开发说明书，负责过人事模块的测试用例设计
• 做过 BPM 工作流搭建

听起来好像懂不少，但问题是：这些都是在「有人带着做」的场景下学到的。顾问搭好了原型框架，我在里面填按钮；甲方给了需求，我按照模板写说明书。我没有从零到一独立做过一个完整的业务分析，没有自己做过竞品分析，没有自己判断过「这个功能到底该不该做、该怎么做」。

我会写用户故事，但我写的用户故事是这样的：

作为用户，我希望能够登录系统，输出提示词，然后选择模板，然后选择比例大小然后点击生成按钮后，开始生成PPT。

比一句话详细一点，但本质上还是在描述「用户想要什么」，没有进入「页面上有什么元素、交互逻辑是什么、异常场景怎么处理」的层面。因为我没见过真正好的需求文档长什么样，也没有实际业务经验告诉我「一个功能背后有多少细节需要明确」。

1.3 半桶水做项目：两边同时翻车

就是在这样的背景下，我开始用 AI 做个人项目。当时的心态是：AI 这么强，我懂一点技术规范、懂一点业务流程，应该能搞定吧？

结果是：业务能力不足导致需求不清，技术能力不足导致代码质量差，两个问题还相互放大。

• 因为用户故事写得太简略，也没有写功能说明书，AI 生成的功能残缺不全，我不断补需求，AI 不断改，上下文越来越乱
• 因为不懂架构设计，我把技术选型全交给 AI，结果前端丑、模块耦合、没有复用
• 因为不懂工程化，我没有版本控制规范、没有质量门禁、没有自动化测试，AI 写完代码 AI 说没问题我就觉得没问题了于是我直接 push，直到运行的时候发现 bug，然后说了有这个 bug 让 AI 修，然后继续验证，也没有定位问题和查看 AI 是否真正解决问题的能力
• 因为不懂上下文管理，我一个 Agent 从头做到尾，对话越来越长，后期 AI 开始幻觉，改一个按钮都困难

这篇文章就是对这段经历的完整复盘——我踩了哪些坑、根因是哪个能力缺失、现在我会怎么做、以及通过这一切我获得了怎样的成长。

二、项目实战：能力缺失的集中暴露

我用 AI 做过几个项目，包括 Telegram 聊天机器人、微信公众号内容发布工作流、一个类似 PPT 编辑的 H5 工具网页。其中踩坑最多、暴露问题最集中的是那个 PPT 工具项目。下面从业务侧和技术侧分别复盘。

2.1 业务侧翻车：四个典型问题

问题一：用户故事太简略，也没有功能说明书

我一开始写的用户故事是这样的：

故事1：作为用户，我希望登录后能生成PPT。 故事2：作为管理员，我希望能看到用户访问和订单管理。

每个故事就一两句话，没有描述页面上有什么按钮、输入框是什么、点击后跳转到哪里、异常情况怎么处理、不同角色看到的内容有什么区别。

这里其实犯了两个错误：一是用户故事写得太简略，二是混淆了用户故事和功能说明书的区别——以为写了功能说明书就够了，用户故事简短描述即可。实际上，用户故事也就是需求，负责说清楚「用户想要什么、为什么」，而功能说明书需要在明确的需求或者特定场景才能完整描述「页面上有什么元素、交互逻辑是什么、异常场景怎么处理」，如果没有明确的用户故事或者需求。

结果是什么？AI 根据这两句话生成的原型和代码极其简略——登录页就一个用户名密码框，连「忘记密码」「注册」都没有；生成 PPT 的页面就一个按钮，点了之后直接跳结果页，没有模板选择、没有参数配置、没有加载提示。

我看到后不满意，就开始补需求：「这里加个模板选择」「那里加个加载动画」「报错要提示」。每补一次，AI 就改一次，改着改着上下文就乱了，AI 开始把之前加的功能又删掉，或者新功能和旧功能冲突。

根因：业务分析能力不足。既没有写好用户故事（太简略，定不了方向），也没有写功能说明书（以为用户故事就是全部，定不了细节）。两层都缺失，AI 只能靠猜。

问题二：没有做竞品分析，从零瞎想功能

做这个 PPT 工具之前，我完全没有去看市面上已有的产品是怎么做的。Gamma、Beautiful.ai 这些产品我都没认真体验过，就直接让 AI 从零开始设计。

结果是：AI 给我设计了一个「自研画布」方案，用户可以在画布上自由拖拽元素。听起来不错，但实际做出来问题一大堆——画布大小不对、元素重叠、排版混乱、生成的 PPT 就几个字挤在一起、颜色全是白色不可编辑。

后来我才去看了市面上的产品，发现主流方案根本不是自由画布，而是「模板驱动 + AI 生成内容 + 前端渲染」。用户不需要自己排版，AI 根据内容自动进行内容的规划、排版、风格，前端进行渲染，用户可以选择模板和主题。我之前的方案从根上就选错了方向。

发现这个问题后，我只能推翻之前的整个页面设计和功能逻辑，重新做。浪费了大量 Token，也浪费了大量时间。

根因：业务调研能力缺失。不知道做产品之前要先看市场上已有的解决方案，不知道要分析竞品的优势和劣势，不知道要从中找到差异化方向。我以为「我想到一个点子」就可以直接做，实际上没有调研的点子大概率是别人已经做过且做得更好的。

问题三：原型与开发完全脱节

我用 Stitch（一个原型设计工具）做了原型，然后把原型导出给 AI 让它开发。但我犯了一个低级错误：Stitch 直接导出的是一个压缩包，AI 的 Agent 根本无法识别压缩包里的内容。

我当时不知道，就把压缩包丢给 AI，说「按照这个原型开发」。AI 说「好的」，然后开始自己瞎写——因为它根本看不到原型长什么样。等我发现的时候，AI 写出来的东西和原型完全不一样，整个结构都错了。

后来我才知道应该给 AI 发原型的分享链接，而不是导出压缩包。但即使发了链接，因为我之前的用户故事太简略、也没有功能说明书，原型本身也很粗糙，开发出来的东西还是和预期有差距。

根因：业务交付能力不足。我不知道原型交付给开发时需要什么格式，不知道要确保开发方能正确读取设计稿，不知道要在开发前做原型评审和对齐。

问题四：需求不断喷涌，之前的没做好又开新的

做到一半的时候，我不断想到新功能：

• 「既然能生成 PPT，那是不是可以加个 AI 生图功能？」
• 「管理端是不是可以做模板管理？管理员编辑好模板，用户直接用？」
• 「提示词模板是不是可以做增删改查？」
• 「是不是可以做 AI PPT 解析？上传 PPT 自动提取内容？」

每个新想法我都让 AI 去做，结果就是：之前的功能还没完善，新功能又堆上去，每个功能都是「能用但不好用」的状态。代码越来越乱，bug 越来越多，上下文越来越长，项目逐渐变成了一个无法维护的屎山。

我当时陷入了一个困境：是先把之前的功能完善好，还是继续把基础功能搭出来再统一完善？因为没有项目管理经验，我不知道怎么排优先级、怎么做迭代规划，结果就是两边都没做好。

根因：需求管理和项目规划能力缺失。我不知道要做需求优先级排序，不知道要做迭代规划，不知道要控制需求范围，不知道「先完成再完美」的道理。

2.2 技术侧翻车：四个典型问题

问题一：技术选型全交给 AI，结果前端丑、架构乱

我自己没有架构设计经验，所以技术选型全交给 AI。AI 推荐什么我就用什么，结果：

• 前端丑：AI 对「美观」没有感知，它生成的页面布局不合理、配色辣眼睛、组件大小失调。比如我让它做一个「生成图片和 PPT 的按钮卡片」，它直接生成了一个占满整个横向空间的巨大卡片，非常不美观。
• 没有微服务/模块拆分：AI 没有主动做模块解耦，每个页面都是一个从头写到尾的 Vue 文件，从 top 到 footer 全写在一起，没有组件复用。改一个地方可能影响其他地方。
• 技术栈可能不合适：我后来才知道，做 PPT 类工具有更成熟的方案和库，但 AI 给我选的是最基础的自研方案，导致很多功能要从零造轮子。

根因：技术架构和选型能力不足。我不知道怎么做技术方案对比，不知道要评估不同方案的优缺点，不知道 AI 的技术建议需要人来判断和筛选，不能全信，另外，我把需求一句话丢给 AI 就开干，没有让 AI 提问澄清、没有头脑风暴，一轮对话就定了方向，AI 对需求的理解和我的预期本身就有偏差（这个问题在坑 11 详细展开）。

问题二：代码质量全靠 AI 自觉，结果处处是坑

AI 写完代码后，我没有做系统的代码审查，只是「跑起来能用就行」。结果代码里到处是问题：

• 没有路由守卫：用户可以直接通过 URL 跳转到任何子页面，不需要登录
• 没有异常处理：接口报错了页面就白屏，没有错误提示和降级方案
• 没有权限管理：普通用户和管理员看到的页面没有区分
• 没有状态提示：用户点击按钮后不知道是在加载还是卡住了
• 报错是英文：即使我说明要用中文，报错和提示还是英文
• 安全隐患：路由里直接显示数据库 ID（如/create/generate/result/38），可能导致信息泄露
• 没有响应式设计：在不同屏幕尺寸下布局错乱
• AI 自行其道：我描述得很仔细，但 AI 还是会在 Plan 里自己加东西，比如我只说「添加选中效果」，它加了个页面切换的滑动动画；我说「适配屏幕大小」，它生成了个占满全屏的大卡片

这些问题如果在传统开发中，会通过代码审查、测试、QA 来发现。但在我的个人项目里，这些环节全没有，AI 写完我就用，出了问题才发现。

根因：代码质量保障能力缺失。我不知道要做代码审查，不知道要写测试用例，不知道要做异常处理和安全检查，不知道要建立质量门禁。我以为「AI 写的代码应该没问题」，实际上 AI 的代码质量参差不齐，必须有人来把关，另外，AI 改完代码说「没问题」我就信了，没有多轮检查、多角度验证，很多 bug 都是后来用到才发现（这个问题在坑 11 详细展开）。

问题三：没有工程化流程，版本控制和自动化全靠手动

我的 Git 提交是这样的：

git add . git commit -m "更新" git push

commit message 就写「更新」「修复」「添加功能」，完全没有规范。也没有分支策略，直接在 main 分支上改。出了问题想回退，根本不知道哪个版本是好的。

重复操作全靠手动：

• 每次改完代码都要跟 AI 说「提交到 Git」
• 每次都要提醒 AI「更新文档」「加注释」
• 每次都要手动跑一下看看有没有报错
• 没有自动化测试，每次改完都要手动点一遍功能

这些重复操作不仅效率低，而且容易遗漏。有时候忘了提交，有时候忘了更新文档，有时候改完没测试就 push 了。

根因：工程化实践能力缺失。我不知道 Conventional Commits 规范，不知道分支策略，不知道可以用 Skill 封装重复操作，不知道可以用 Hook 做自动化质量门禁，不知道 CI/CD 是什么。

问题四：一个 Agent 从头做到尾，上下文污染严重

整个项目我就用一个 AI Agent，从需求分析到原型设计到前端开发到后端开发到测试，全是它一个人做。结果：

• 对话越来越长，上下文很快就满了（200K Token 看起来多，但一个项目做下来根本不够）
• 后期 AI 开始遗忘早期的决策，把已经删掉的代码又加回来
• 改一个简单的布局或文字，AI 要理解半天上下文，还经常改错
• 需求分析阶段的内容污染了开发阶段的上下文，AI 有时候会把需求文档里的内容当成代码来写

我当时还做了一件雪上加霜的事：我在 Agent 配置文件（agents.md）里写满了所有角色要做的事情——产品经理做什么、开发做什么、测试做什么、QA 做什么，全写在一个文件里。结果这个文件本身就很长，每次会话都要加载，反而让上下文更拥挤，输出质量还不如不加这个文件的时候。

根因：AI 协作模式认知缺失。我不知道要分 Agent、分角色，不知道要做上下文压缩，不知道要按模块拆分开发，不知道 Subagent 和多代理协作的概念。我以为 AI 就是一个全能助手，什么都能做，实际上单一 Agent 的能力和上下文都是有限的。

2.3 两边能力缺失如何相互放大

最糟糕的是，业务侧和技术侧的问题不是独立的，而是相互放大的：

业务能力不足 → 需求不清 → AI 自由发挥 → 代码质量差 ↓ ↑ 需求不断变更 → 上下文污染 → AI 改不动 → 只能不断补需求 ↓ ↑ 没有质量门禁 → bug 堆积 → 越改越乱 → 需求更难收敛

• 因为需求不清，AI 写的代码不符合预期，我不断补需求，AI 不断改，上下文越来越乱
• 因为上下文乱了，AI 改代码容易出错，bug 越来越多
• 因为没有质量门禁，bug 发现不了，越积越多
• 因为 bug 多，我更不敢大改，只能在现有基础上打补丁，代码越来越烂
• 因为代码烂，新功能更难加，我又想开新项目或者新功能来逃避

到最后，这个项目变成了一个「能用但完全无法维护」的状态。我不敢改代码，怕改出更多 bug；不敢加功能，怕上下文不够用；甚至不敢打开项目，因为一打开就想起那些没解决的问题。

这就是半桶水做 AI 项目的真实写照：业务能力不够导致方向跑偏，技术能力不够导致质量失控，两个问题螺旋下降，最后项目烂尾。

三、踩坑复盘：10 个具体的坑和解决方案

上面是宏观的问题分析，下面落到具体的坑。每个坑我都会按「当时怎么做→出了什么问题→根因是哪个能力缺失→现在怎么解决」的结构来写。

坑 1：没做竞品分析就开干

当时怎么做的：想到一个点子（做一个 PPT 编辑工具），直接让 AI 开始做，没有看市面上已有的产品。

出了什么问题：AI 推荐了自研画布方案，做出来排版混乱、功能残缺。后来看了 Gamma、Beautiful.ai 等产品才发现，主流方案是模板驱动 + AI 编排 + 前端渲染，根本不是自由画布。只能推翻重做，浪费大量 Token 和时间。

根因：业务调研能力缺失。不知道做产品前要先做竞品分析。

现在怎么解决：

1. 动手前必做竞品分析：至少体验 3 个同类产品，列出每个产品的核心功能、优势、劣势、定价模式
2. 做差异化定位：分析竞品没有覆盖的场景或用户痛点，找到自己的差异化方向
3. 参考但不抄袭：借鉴竞品的好设计，但要有自己的特色，不要照搬
4. 输出竞品分析文档：把分析结果写成文档，作为后续需求和设计的依据

具体操作模板：

竞品分析模板： 1. 竞品名称和网址 2. 核心功能列表（对比表） 3. 优势和劣势 4. 目标用户和定价 5. 我可以借鉴的设计 6. 我的差异化方向

坑 2：用户故事太简略

当时怎么做的：用户故事就写「作为用户，我希望能够登录系统，输出提示词，然后选择模板，然后选择比例大小然后点击生成按钮后，开始生成PPT」，比一句话详细一点，但本质上还是在描述用户想要什么。而且我以为写了用户故事就够了，不需要别的文档。

出了什么问题：AI 生成的功能残缺不全，没有忘记密码、没有加载提示、没有错误处理、没有权限区分。不断补需求，AI 不断改，上下文越来越乱。

根因：业务分析能力缺失。这里犯了两个错误——一是用户故事写得太简略（定不了方向），二是混淆了用户故事和功能说明书的区别，以为用户故事就是全部，功能说明书照着补充即可。结果两层都缺失，AI 只能靠猜。

先澄清一个概念：用户故事 ≠ 功能说明书

现在怎么解决：分两层写，各司其职

第一层：用户故事（简短，定方向）

故事：用户登录 作为未登录用户，我希望通过用户名和密码登录系统， 以便访问需要身份验证的功能。 验收标准： - 正确凭证可以登录成功 - 错误凭证有明确提示 - 未登录访问受保护页面自动跳转登录页

作用：让 AI 和人都快速理解"这个功能是干什么的、为谁做的、做到什么程度算完成"。保持简短，不陷入细节。

第二层：功能说明书（详细，定实现）

功能：用户登录页面 一、页面元素 1. 用户名输入框 - 位置：页面居中表单第一项 - 类型：文本输入 - 必填：是 - 支持格式：邮箱或手机号 - 占位符："请输入邮箱或手机号" 2. 密码输入框 - 位置：用户名输入框下方 - 类型：密码输入（掩码显示） - 必填：是 - 右侧有"显示/隐藏"切换按钮 3. "登录"按钮 - 位置：密码输入框下方 - 类型：主按钮（品牌色填充） - 表单未填完时禁用（灰色，不可点击） 4. "忘记密码"链接 - 位置：登录按钮右侧 - 点击跳转到密码找回页 5. "注册账号"链接 - 位置：登录按钮下方 - 点击跳转到注册页 二、交互流程 1. 用户输入用户名和密码 2. 点击"登录"按钮 3. 前端校验必填项（为空则按钮禁用，不发请求） 4. 调用 POST /api/auth/login 接口 5. 成功：保存 Token 到 localStorage，跳转首页 6. 失败：表单顶部显示错误提示，密码框清空 三、异常场景 1. 用户名或密码为空 → 登录按钮禁用，输入框下方红色提示 2. 账号或密码错误 → 提示"账号或密码错误"，密码框清空 3. 网络异常 → 提示"网络异常，请稍后重试" 4. 账号被禁用 → 提示"账号已被禁用，请联系管理员" 5. 连续失败 5 次 → 锁定账号 15 分钟，提示"尝试次数过多，请 15 分钟后再试" 四、权限与安全 1. 密码传输使用 HTTPS 2. Token 有效期 7 天，支持刷新 3. 登录页不缓存密码

作用：给 AI 提供精确的实现依据，减少 AI 的"自由发挥"，降低幻觉和遗漏。

两者的关系：

用户故事（为什么）→ 功能说明书（怎么做）→ AI 开发代码 ↓ ↓ 定方向，不纠结细节 定细节，确保不遗漏

在 AI 编程中，功能说明书比用户故事更重要——因为 AI 需要精确的指令才能生成符合预期的代码。用户故事帮你理清思路，功能说明书帮 AI 准确实现。我之前的问题是：既没有写好用户故事（太简略），也没有写功能说明书（以为用户故事就是全部），两层都缺失，AI 只能靠猜。

补充一个实用建议：你说的"看到什么内容、在什么地方、有什么功能、可以干什么"，这恰恰是功能说明书最核心的内容，也是 AI 编程中最需要的。不要因为它"不是标准用户故事"就觉得不对——它只是属于另一个文档类型。在实际项目中，功能说明书的价值远大于标准格式的用户故事。

坑 3：技术选型全交给 AI

当时怎么做的：自己不懂架构，AI 推荐什么技术栈就用什么。

出了什么问题：前端丑、没有模块拆分、技术栈可能不是最优解、造了很多不必要的轮子。

根因：技术选型和架构能力不足。不知道要做方案对比，不知道 AI 的建议需要人来判断。

现在怎么解决：

1. 至少对比 2-3 个技术方案：每个方案列出优缺点、学习成本、社区活跃度、适用场景
2. 按评估维度打分：比如开发效率、性能、可维护性、生态成熟度，加权后选总分最高的
3. 参考主流项目的技术栈：看看 GitHub 上同类项目用什么技术栈，为什么
4. 人来做最终决策：AI 提供选项和分析，人来拍板，不要把决策权完全交给 AI
5. 小步验证：技术选型后先做一个最小原型验证可行性，不要一上来就全量开发

坑 4：一个 Agent 从头做到尾

当时怎么做的：整个项目就一个 AI Agent，需求、设计、开发、测试全是它。

出了什么问题：上下文过长导致幻觉、改不动代码、不同阶段的内容相互污染、agents.md 写太长反而降低输出质量。

根因：AI 协作模式认知缺失。不知道要分角色、分 Agent、分模块。

现在怎么解决：

1. 按角色分 Agent：产品 Agent（需求分析）、开发 Agent（写代码）、测试 Agent（写测试）、质检 Agent（代码审查），各司其职
2. 按模块拆分开发：不要一个 Agent 做整个项目，每个功能模块开新对话或新 Agent
3. 及时压缩上下文：每完成一个功能或每 15-20 轮对话，执行/compact压缩
4. 角色定义简洁聚焦：agents.md 不要写满所有角色的职责，每个 Agent 只加载自己角色的定义
5. Subagent 并行处理：独立任务（如代码审查和测试）可以并行执行，提高效率

坑 5：不知道压缩上下文

当时怎么做的：一个对话从头聊到尾，从来没压缩过。

出了什么问题：对话到后期 AI 开始遗忘、幻觉，把删掉的代码又加回来，改一个按钮都困难。

根因：上下文管理能力缺失。不知道 AI 的上下文窗口有限，不知道要主动管理。

现在怎么解决：

1. 主动压缩：每 15-20 轮对话或完成一个功能后，执行/compact
2. 压缩前保存关键信息：把重要决策、技术选型、待办事项写到项目文档里，防止压缩后丢失
3. 压缩后验证：压缩后问 AI「复述当前项目进度和关键决策」，确认关键信息没丢
4. 开新对话：不同阶段（需求→设计→开发→测试）开新对话，依赖项目文档传递信息，而不是靠上下文
5. 控制单轮输出量：精准提问，不要让 AI 输出不必要的长篇大论

坑 6：Git 提交没有规范和门禁

当时怎么做的：git add . && git commit -m "更新" && git push，写完就 push，没有任何检查。

出了什么问题：commit message 混乱，无法追溯历史；改出 bug 也不知道，直接推到远程；想回退找不到哪个版本是好的。

根因：版本控制和工程化能力缺失。不知道提交规范、分支策略、质量门禁。

现在怎么解决：

1. Conventional Commits 规范：commit message 用feat: 添加登录功能、fix: 修复登录页样式错乱、refactor: 重构用户模块格式
2. 小步提交：每个小功能或每个 bug 修复单独 commit，不要攒一大堆一起提交
3. 分支策略：main 分支保持稳定，开发在 feature 分支，完成后合并
4. 提交前检查：commit 前跑 lint + 单元测试，通过才提交
5. Hook 质量门禁：用 Hook 拦截 git commit，自动跑检查，不通过不让提交
6. 写更新日志：每个版本写 CHANGELOG，记录新增功能、修复的 bug、破坏性变更

坑 7：重复操作每次手动说

当时怎么做的：每次改完代码都跟 AI 说「提交代码」「更新文档」「加注释」，每次都要重复一遍。

出了什么问题：效率极低，而且经常遗漏——有时候忘了让 AI 提交，有时候忘了更新文档，有时候忘了加注释。

根因：自动化意识缺失。不知道可以用 Skill 封装重复操作，用 Hook 自动触发。

现在怎么解决：

1. 自定义 Skill：把重复操作封装成斜杠命令，如/git-save（一键 add+commit+push）、/update-docs（更新项目文档）、/add-comments（给代码加注释）
2. Hook 自动触发：提交后自动更新文档、自动跑测试，不需要手动提醒
3. 写进角色定义：在 Agent 的角色定义里写明「每次修改代码后自动提交并更新文档」，让 AI 自觉执行
4. 模板化：常用的提示词、文档模板、测试模板保存下来，每次直接用

坑 8：代码质量全靠 AI 自觉

当时怎么做的：AI 写完代码，跑起来能用就行，没有做系统的代码审查和测试。

出了什么问题：没有路由守卫、没有异常处理、没有权限管理、报错英文、安全隐患、响应式缺失、AI 自行加功能。

根因：质量保障能力缺失。不知道要做代码审查、测试、安全检查。

现在怎么解决：

1. 代码审查清单：每次 AI 写完代码，按清单检查——路由守卫、异常处理、权限控制、输入校验、安全漏洞、响应式、中文提示
2. /code-review 命令：用 AI 的代码审查功能自动扫描，按 Critical/High/Medium/Low 分级
3. 冒烟测试用例：写一套核心功能的冒烟测试，每次改完跑一遍，确保没改出大问题
4. 安全检查：检查是否有硬编码密钥、SQL 注入、XSS、敏感信息泄露、路由 ID 暴露
5. AI 输出约束：在角色定义里明确要求「不要自行添加未要求的功能」「所有报错和提示用中文」「必须做异常处理」
6. 人工复核核心逻辑：AI 审查是辅助，核心业务逻辑必须人来复核

坑 9：原型与开发脱节

当时怎么做的：用 Stitch 做了原型，导出压缩包给 AI，AI 说「好的」然后自己瞎写。

出了什么问题：开发出来的东西和原型完全不一样，因为 AI 根本读不懂压缩包。

根因：交付协作能力缺失。不知道原型交付的正确格式，不知道要做开发前对齐。

现在怎么解决：

1. 用分享链接而不是压缩包：AI 可以通过链接访问原型页面，正确读取设计内容
2. 开发前做原型评审：把原型截图或链接给 AI，让它先描述「你理解这个页面有哪些元素、交互逻辑是什么」，确认理解一致再开发
3. 原型标注关键信息：在原型上标注尺寸、颜色、交互逻辑、特殊状态，减少 AI 的理解偏差
4. 组件级开发：不要让 AI 一次开发整个页面，按组件拆分，每个组件开发完确认后再继续

坑 10：性能和体验考虑不足

当时怎么做的：AI 怎么写就怎么用，没有考虑性能和用户体验。

出了什么问题：实时渲染导致频闪、系统变卡；页面渲染过快没有过渡效果；没有考虑目标设备（公立医院老旧电脑）的性能；加载时全屏白屏没有进度提示。

根因：性能优化和用户体验设计能力不足。不知道要考虑目标设备性能、渲染策略、加载体验。

现在怎么解决：

1. 目标设备调研：先了解用户用什么设备，性能如何，针对性优化
2. 渲染限流：不要实时渲染，限制渲染频率（如每秒 10 次），或只渲染可视区域
3. 分区渲染：复杂画面分区域渲染，只重绘变化的区域，不要全量重绘
4. 加载体验：用流式生成、进度条、骨架屏，不要让用户面对白屏等待
5. 过渡动画：页面切换、元素出现添加过渡动画，控制在 1-2 秒，根据元素数量调整
6. 性能监控：关注帧率、加载时间、内存占用，发现性能问题及时优化

坑 11：一轮对话就开干，盲目相信 AI 的输出

当时怎么做的：分两个阶段。

需求阶段：我把想法一句话丢给 AI，AI 说「好的，我明白了」，我就直接让它开始做。没有让 AI 提问澄清，没有和 AI 头脑风暴，没有让 AI 给出多个方案建议，一轮对话就定了方向。

验证阶段：AI 改完代码说「已经修复了」，我就信了，跑一下能打开页面就觉得没问题。没有多轮检查，没有从多个角度验证 AI 是否真的改对了、有没有引入新问题。

出了什么问题：

需求阶段的问题：AI 说「明白了」其实是「我猜你是这个意思」。因为没有多轮澄清，AI 对需求的理解和我的预期有偏差，做出来的东西功能残缺、逻辑不对。比如我以为「生成 PPT」包含模板选择、参数配置、加载提示，但 AI 理解的就是一个按钮点了跳结果页。如果一开始让 AI 提问、一起头脑风暴，这些偏差在动手前就能发现，不至于做完才推翻。

验证阶段的问题：AI 说「修复了」不代表真的修复了。有好几次，AI 改了 A 问题，结果把 B 功能搞坏了；或者 AI 只改了表面现象，根因没解决，换个场景又复现了。因为我盲目相信 AI 的输出，没有多轮验证，这些问题都是后来用户（或我自己）用到的时候才发现，那时候上下文已经很长了，修起来更麻烦。

根因：对 AI 的能力边界认知不足，盲目相信 AI 的输出。以为 AI 说「明白了」就是真明白了，以为 AI 说「修复了」就是真修复了。没有建立「多轮对话澄清需求 + 多轮检查验证结果」的交互习惯。

现在怎么解决：

需求阶段：多轮对话，让 AI 主动提问和头脑风暴

1. 第一轮：描述想法，让 AI 提问
   不要一轮就定需求。先把想法大致说一下，然后明确要求 AI：「请针对这个需求提出你不清楚的地方，向我提问」。AI 会从用户角色、功能边界、异常场景、技术约束等角度提问，你回答的过程就是在澄清需求。

2. 第二轮：和 AI 头脑风暴，让它给建议
   需求澄清后，要求 AI：「请给出 2-3 个实现方案，分析每个方案的优缺点和适用场景」。AI 会给出你没想到的角度，比如「这个功能可以用模板驱动，也可以用自由画布，两者各有优劣」。头脑风暴能帮你在动手前就想清楚方向，避免做到一半推翻。

3. 第三轮：确认需求，输出文档
   方案确定后，要求 AI：「请把我们讨论的需求整理成用户故事 + 功能说明书」。这时候输出的文档是经过多轮澄清和头脑风暴的，比你一开始一句话丢给 AI 要完整得多。

验证阶段：多轮检查，多角度验证，不盲目相信

1. AI 改完后，先让它自查
   不要 AI 说「改好了」就信。要求 AI：「请检查你刚才的修改，确认是否完整解决了问题，有没有影响其他功能，有没有引入新的 bug」。让 AI 自己先过一遍，很多低级问题它自查就能发现。

2. 多角度验证，不要只测一个场景
   至少从这几个角度验证：

   • 主流程：核心功能是否正常工作
   • 边界场景：空输入、超长输入、极端值是否处理
   • 异常场景：网络断开、接口报错、权限不足是否有提示
   • 回归测试：之前正常的功能有没有被改坏
   • 安全检查：有没有硬编码密钥、路由 ID 暴露、SQL 注入风险

3. 让 AI 写测试用例，自动跑
   要求 AI：「请为这个功能写冒烟测试用例，覆盖主流程和关键边界场景」。每次改完代码自动跑一遍测试，通过了才算真的改好了。不要只靠肉眼点一遍。

4. 不确定就追问，不要不好意思
   如果 AI 的修改你看不懂，或者你觉得可能有问题，直接问：「你这里为什么这么改？有没有考虑 XX 场景？」。AI 不会因为你追问就不耐烦，反而追问能帮你发现它没考虑到的问题。

一句话总结：需求阶段不要怕多聊，聊得越清楚，后面返工越少；验证阶段不要怕多查，查得越仔细，后面 bug 越少。AI 是工具不是权威，它的输出必须经过你的判断和验证。

四、自学与反思：能力的真实提升

项目烂尾之后，我没有放弃，而是开始系统自学。我学习了 Vibe Coding 的课程，从零开始学习 AI 编程的工程化方法。同时我也在反思自己之前的问题，把踩过的坑一个个对应到能力缺失上，然后针对性地补。

这段时间的学习和反思，让我的业务能力和技术能力都获得了真实的提升。下面分别说说。

4.1 业务能力的提升

提升一：从「写一句话用户故事」到「用户故事 + 功能说明书两层需求文档」

之前我写用户故事就一句话，而且以为用户故事就是全部，不需要别的文档。现在我知道要分两层写：先写用户故事（定方向，说清楚用户想要什么、为什么），再写功能说明书（定细节，说清楚页面上有什么元素、交互逻辑是什么、异常场景怎么处理）。

用户故事保持简短，让人和 AI 都快速理解功能的目的和范围；功能说明书写得详细，给 AI 提供精确的实现依据。两层配合，AI 拿到就能直接开发，不需要反复补需求。

提升二：从「从零瞎想」到「先做竞品分析」

之前我想到点子就直接做，现在我知道动手前必须先做竞品分析。我学会了体验同类产品、分析优缺点、找差异化方向。我明白了「不做竞品分析的产品大概率是在重复造轮子」。

提升三：从「需求喷涌」到「需求优先级管理」

之前我想到什么功能就加什么，现在我学会了用 MoSCoW 方法（Must have / Should have / Could have / Won’t have）给需求排优先级，先做核心功能，MVP 跑通后再迭代。我明白了「先完成再完美」的道理，也知道了控制需求范围的重要性。

提升四：从「原型交付压缩包」到「原型开发对齐」

之前我把原型压缩包丢给 AI，现在我知道要用分享链接，开发前要让 AI 先复述对原型的理解，确认一致再动手。我学会了原型标注、组件级开发、设计评审这些基本的协作流程。

4.2 技术能力的提升

提升一：从「一个 Agent 做到尾」到「多 Agent 分工协作」

之前我一个 Agent 从头做到尾，现在我学会了按角色分 Subagent——产品 Agent 做需求、开发 Agent 写代码、测试 Agent 写测试、质检 Agent 做审查。每个 Agent 有自己的角色定义和专属技能，上下文隔离不污染。我还学会了用 Subagent 并行处理独立任务，提高效率。

提升二：从「不知道压缩上下文」到「主动上下文管理」

之前我对话聊到尾也不压缩，现在我养成了习惯——每完成一个功能或每 15-20 轮对话就执行/compact。我还学会了压缩前保存关键信息到文档、压缩后验证、不同阶段开新对话。现在 AI 不再因为上下文过长而幻觉了，改代码也顺畅了。

提升三：从「commit message 写更新」到「工程化版本控制」

之前我的 commit message 就是「更新」，现在我用 Conventional Commits 规范，知道了 feat/fix/refactor/docs/chore 的区别。我学会了分支策略、小步提交、CHANGELOG 维护。更重要的是，我学会了用 Hook 做质量门禁——提交前自动跑 lint 和测试，不通过不让提交。

提升四：从「重复操作手动说」到「Skill + Hook 自动化」

之前每次都要跟 AI 说「提交代码」「更新文档」，现在我把这些封装成了 Skill——/git-save一键完成提交推送，/update-docs自动更新文档。我还用 Hook 实现了提交后自动更新文档、自动跑测试。重复操作不再需要手动提醒，效率大幅提升。

提升五：从「代码质量靠自觉」到「质量保障体系」

之前 AI 写完能用就行，现在我建立了质量保障体系——代码审查清单、/code-review自动扫描、冒烟测试用例、安全检查清单、AI 输出约束。我还学会了区分「AI 可以自动修复的问题」和「需要人工确认的问题」，既利用了自动化的效率，又保证了关键决策的人工可控。

提升六：从「一轮对话就开干」到「多轮澄清 + 多轮验证」

之前我把想法一句话丢给 AI 就开干，AI 说改好了就信了。现在我学会了需求阶段多轮对话——让 AI 提问澄清、头脑风暴、给出方案建议，动手前就把需求理清楚；验证阶段多轮检查——让 AI 自查、多角度验证（主流程/边界/异常/回归/安全）、写测试用例自动跑，不盲目相信 AI 的输出。多轮交互看似多花了时间，实际上大幅减少了返工和后期修 bug 的成本。

4.3 现在 vs 之前的能力对比

可以看到，提升是系统性的、全方位的。不是某一个点变强了，而是整个工程化思维和方法论建立起来了。尤其是需求文档这块，从「只有一句话用户故事」变成了「用户故事 + 功能说明书两层结构」，这是业务能力提升最核心的体现。

五、成长建议

如果你和我一样，也是技术懂一点、业务懂一点但两边都不够深的半桶水，下面是我给你的建议。

5.1 做中学，发现自己的不足

最可怕的不是能力不足，而是不知道自己能力不足。我之前就是这样——以为自己懂规范、懂流程，就能用 AI 搞定项目，结果被现实教做人。

承认能力不足，意味着：

• 做项目前要多调研、多学习，不要想当然
• 重要决策要多对比、多验证，不要拍脑袋
• 遇到问题要反思根因，不要怪 AI 不好用
• 持续学习，把每个项目都当成成长的机会

能力不足是新手很常见的一个问题，但是关键是有没有意识到自己的不足，以及有没有在行动上补。

5.2 怎么补业务能力

建议一：多体验产品，培养产品感

不要只盯着自己的项目，多去体验市面上的好产品。用的时候思考：

• 这个功能为什么这么设计？
• 用户的操作路径是什么？
• 异常场景是怎么处理的？
• 这个产品的核心价值是什么？
• 和竞品比，它的优势和劣势是什么？

产品感是用出来的，不是学出来的。体验的产品多了，你自然就知道「一个登录页应该有什么」「一个列表页应该怎么设计」。

建议二：学习用户故事和功能说明书的写法

用户故事和功能说明书是两种不同的文档，各司其职，都要学：

• 用户故事：学习 INVEST 原则（Independent / Negotiable / Valuable / Estimable / Small / Testable）、验收标准的 Given-When-Then 格式。用户故事负责说清楚「用户想要什么、为什么」，保持简短。
• 功能说明书：学习页面元素清单、交互流程图、异常场景枚举、权限与安全要求。功能说明书负责说清楚「系统应该怎么做」，写得详细。
• 用户旅程图（User Journey Map）：学习怎么画用户从接触产品到完成目标的完整路径，发现痛点和优化点。
• 需求优先级排序：学习 MoSCoW 方法、Kano 模型，学会控制需求范围。

这些方法不复杂，但能显著提升你的需求质量。尤其是功能说明书，在 AI 编程中比用户故事更实用——因为 AI 需要精确的指令才能生成符合预期的代码。

建议三：做项目前先做竞品分析

养成习惯：做任何项目前，先花 1-2 小时体验 3 个以上同类产品，写一份竞品分析文档。这 1-2 小时能帮你省掉后面几十小时的返工。

建议四：从小项目开始练手

不要一上来就做复杂的大项目。先做小功能、小工具，在小项目里练习需求分析、原型设计、用户故事和功能说明书写作。小项目成本低、迭代快，适合练手。等小项目能做好了，再逐步挑战大项目。

5.3 怎么补技术能力

建议一：学习工程化基础

不管用不用 AI，工程化基础都是开发者的基本功。重点学习：

• Git 版本控制（分支策略、提交规范、回退操作）
• 代码审查（审查维度、常见问题、工具使用）
• 测试基础（单元测试、集成测试、冒烟测试）
• CI/CD 概念（自动化构建、测试、部署）
• 代码规范（命名、注释、异常处理、安全编码）

这些东西不高深，但很多人（包括之前的我）都忽略了。AI 时代，代码生成变得容易，但工程化能力变得更重要——因为 AI 生成的代码质量参差不齐，必须靠工程化流程来保障。

建议二：学习 AI 编程的工程化方法

AI 编程不是「跟 AI 聊天就行」，它有自己的工程化方法论。重点学习：

• 上下文管理（/compact、分对话、分模块）
• 多 Agent 协作（角色定义、Subagent、并行处理）
• 自定义 Skill（封装重复操作）
• Hook 钩子（自动化质量门禁）
• 记忆系统（CLAUDE.md、Auto Memory）
• Token 优化（增量检查、影响面分析、Effort 分级）

这些是 AI 时代特有的工程化能力，传统开发经验里没有，需要专门学习。

建议三：读好代码，培养代码品味

多去 GitHub 上看优秀的开源项目代码，学习别人是怎么组织代码、怎么处理异常、怎么做模块拆分、怎么写注释的。代码品味是读出来的，看多了好代码，你自然就知道 AI 写的代码哪里不好、应该怎么改。

建议四：在项目中刻意练习

不要只学不练。每学一个新方法，就在下一个项目里刻意用起来。比如学了 Conventional Commits，下一个项目就严格按规范写 commit message；学了 Hook，下一个项目就配置提交前自动跑测试。刻意练习才能把知识变成能力。

5.4 AI 时代的成长路径

最后说说我对 AI 时代开发者成长路径的理解。

AI 降低了写代码的门槛，但提高了对「上游能力」和「下游能力」的要求：

• 上游能力：需求分析、产品设计、技术选型、架构设计——这些是「告诉 AI 做什么」的能力，AI 替不了你
• 下游能力：代码审查、测试验证、质量保障、性能优化、运维部署——这些是「验证 AI 做得对不对」的能力，AI 也替不了你

中间的「写代码」环节，AI 已经能做得很好了。所以半桶水的成长方向，不是去跟 AI 比谁代码写得快，而是补上游和下游的能力——学会清晰地定义问题、设计方案，学会严格地验证结果、保障质量。

这也是我这篇文章想传达的核心：AI 时代，半桶水不可怕，可怕的是不知道自己哪半桶水不够、也不去补。找到自己的短板，在项目中刻意练习，持续学习，每个人都能从半桶水变成满桶水。

六、总结

这篇文章是我对自己 AI 编程经历的完整复盘，核心内容可以总结为三句话：

第一，新手做 AI 项目，业务和技术两边会同时翻车。业务能力不足导致需求不清、方向跑偏（用户故事太简略、也没有功能说明书）；技术能力不足导致代码质量差、工程化缺失。两个问题还会相互放大，最后项目烂尾。

第二，踩坑不可怕，可怕的是不反思。我把项目中踩的 10 个坑逐一复盘，每个坑都找到了根因（哪个能力缺失），并给出了现在的解决方案。尤其是坑 2，我之前混淆了用户故事和功能说明书的区别，现在理清了——用户故事定方向，功能说明书定细节，两者配合才是完整的需求文档。这个复盘的过程本身就是成长。

第三，通过实战和自学，能力可以获得真实提升。学完 Vibe Coding 课程后，我在业务侧学会了竞品分析、用户故事 + 功能说明书两层需求文档、需求优先级管理；在技术侧学会了多 Agent 协作、上下文管理、工程化版本控制、Skill + Hook 自动化、质量保障体系、多轮澄清需求 + 多轮验证结果（不盲目相信 AI 输出）。这些不是纸上谈兵，是在项目中验证过的真实能力提升。

如果你也是一个Vibe Coding初学者，希望这篇文章能给你一些参考。不要怕自己能力不够，每个人都是从不够到够的。关键是：承认不足、找到短板、刻意练习、持续反思。

AI 时代，最好的成长方式就是——用 AI 做项目，在项目中暴露问题，通过学习和反思解决问题，然后用更好的能力做下一个项目。这是一个正向循环，也是我正在走的路。

与你共勉。

如果这篇文章对你有帮助，欢迎点赞、收藏、评论交流。你在 AI 编程中踩过什么坑？欢迎在评论区分享，我们一起成长。