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 pushcommit 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 和时间。根因业务调研能力缺失。不知道做产品前要先做竞品分析。现在怎么解决动手前必做竞品分析至少体验 3 个同类产品列出每个产品的核心功能、优势、劣势、定价模式做差异化定位分析竞品没有覆盖的场景或用户痛点找到自己的差异化方向参考但不抄袭借鉴竞品的好设计但要有自己的特色不要照搬输出竞品分析文档把分析结果写成文档作为后续需求和设计的依据具体操作模板竞品分析模板 1. 竞品名称和网址 2. 核心功能列表对比表 3. 优势和劣势 4. 目标用户和定价 5. 我可以借鉴的设计 6. 我的差异化方向坑 2用户故事太简略当时怎么做的用户故事就写「作为用户我希望能够登录系统输出提示词然后选择模板然后选择比例大小然后点击生成按钮后开始生成PPT」比一句话详细一点但本质上还是在描述用户想要什么。而且我以为写了用户故事就够了不需要别的文档。出了什么问题AI 生成的功能残缺不全没有忘记密码、没有加载提示、没有错误处理、没有权限区分。不断补需求AI 不断改上下文越来越乱。根因业务分析能力缺失。这里犯了两个错误——一是用户故事写得太简略定不了方向二是混淆了用户故事和功能说明书的区别以为用户故事就是全部功能说明书照着补充即可。结果两层都缺失AI 只能靠猜。先澄清一个概念用户故事 ≠ 功能说明书维度用户故事User Story功能说明书Functional Spec核心视角用户视角我想要什么、为什么系统视角系统应该怎么做关注重点为什么价值/目的怎么做页面元素/交互逻辑/异常处理详细程度简短一两句话详细包含页面元素、字段、交互、异常典型格式“作为角色我想要功能以便价值”页面元素清单 交互流程 异常场景 验收标准给谁看产品、开发、测试都能快速看懂主要给开发和测试看现在怎么解决分两层写各司其职第一层用户故事简短定方向故事用户登录 作为未登录用户我希望通过用户名和密码登录系统 以便访问需要身份验证的功能。 验收标准 - 正确凭证可以登录成功 - 错误凭证有明确提示 - 未登录访问受保护页面自动跳转登录页作用让 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 的建议需要人来判断。现在怎么解决至少对比 2-3 个技术方案每个方案列出优缺点、学习成本、社区活跃度、适用场景按评估维度打分比如开发效率、性能、可维护性、生态成熟度加权后选总分最高的参考主流项目的技术栈看看 GitHub 上同类项目用什么技术栈为什么人来做最终决策AI 提供选项和分析人来拍板不要把决策权完全交给 AI小步验证技术选型后先做一个最小原型验证可行性不要一上来就全量开发坑 4一个 Agent 从头做到尾当时怎么做的整个项目就一个 AI Agent需求、设计、开发、测试全是它。出了什么问题上下文过长导致幻觉、改不动代码、不同阶段的内容相互污染、agents.md 写太长反而降低输出质量。根因AI 协作模式认知缺失。不知道要分角色、分 Agent、分模块。现在怎么解决按角色分 Agent产品 Agent需求分析、开发 Agent写代码、测试 Agent写测试、质检 Agent代码审查各司其职按模块拆分开发不要一个 Agent 做整个项目每个功能模块开新对话或新 Agent及时压缩上下文每完成一个功能或每 15-20 轮对话执行/compact压缩角色定义简洁聚焦agents.md 不要写满所有角色的职责每个 Agent 只加载自己角色的定义Subagent 并行处理独立任务如代码审查和测试可以并行执行提高效率坑 5不知道压缩上下文当时怎么做的一个对话从头聊到尾从来没压缩过。出了什么问题对话到后期 AI 开始遗忘、幻觉把删掉的代码又加回来改一个按钮都困难。根因上下文管理能力缺失。不知道 AI 的上下文窗口有限不知道要主动管理。现在怎么解决主动压缩每 15-20 轮对话或完成一个功能后执行/compact压缩前保存关键信息把重要决策、技术选型、待办事项写到项目文档里防止压缩后丢失压缩后验证压缩后问 AI「复述当前项目进度和关键决策」确认关键信息没丢开新对话不同阶段需求→设计→开发→测试开新对话依赖项目文档传递信息而不是靠上下文控制单轮输出量精准提问不要让 AI 输出不必要的长篇大论坑 6Git 提交没有规范和门禁当时怎么做的git add . git commit -m 更新 git push写完就 push没有任何检查。出了什么问题commit message 混乱无法追溯历史改出 bug 也不知道直接推到远程想回退找不到哪个版本是好的。根因版本控制和工程化能力缺失。不知道提交规范、分支策略、质量门禁。现在怎么解决Conventional Commits 规范commit message 用feat: 添加登录功能、fix: 修复登录页样式错乱、refactor: 重构用户模块格式小步提交每个小功能或每个 bug 修复单独 commit不要攒一大堆一起提交分支策略main 分支保持稳定开发在 feature 分支完成后合并提交前检查commit 前跑 lint 单元测试通过才提交Hook 质量门禁用 Hook 拦截 git commit自动跑检查不通过不让提交写更新日志每个版本写 CHANGELOG记录新增功能、修复的 bug、破坏性变更坑 7重复操作每次手动说当时怎么做的每次改完代码都跟 AI 说「提交代码」「更新文档」「加注释」每次都要重复一遍。出了什么问题效率极低而且经常遗漏——有时候忘了让 AI 提交有时候忘了更新文档有时候忘了加注释。根因自动化意识缺失。不知道可以用 Skill 封装重复操作用 Hook 自动触发。现在怎么解决自定义 Skill把重复操作封装成斜杠命令如/git-save一键 addcommitpush、/update-docs更新项目文档、/add-comments给代码加注释Hook 自动触发提交后自动更新文档、自动跑测试不需要手动提醒写进角色定义在 Agent 的角色定义里写明「每次修改代码后自动提交并更新文档」让 AI 自觉执行模板化常用的提示词、文档模板、测试模板保存下来每次直接用坑 8代码质量全靠 AI 自觉当时怎么做的AI 写完代码跑起来能用就行没有做系统的代码审查和测试。出了什么问题没有路由守卫、没有异常处理、没有权限管理、报错英文、安全隐患、响应式缺失、AI 自行加功能。根因质量保障能力缺失。不知道要做代码审查、测试、安全检查。现在怎么解决代码审查清单每次 AI 写完代码按清单检查——路由守卫、异常处理、权限控制、输入校验、安全漏洞、响应式、中文提示/code-review 命令用 AI 的代码审查功能自动扫描按 Critical/High/Medium/Low 分级冒烟测试用例写一套核心功能的冒烟测试每次改完跑一遍确保没改出大问题安全检查检查是否有硬编码密钥、SQL 注入、XSS、敏感信息泄露、路由 ID 暴露AI 输出约束在角色定义里明确要求「不要自行添加未要求的功能」「所有报错和提示用中文」「必须做异常处理」人工复核核心逻辑AI 审查是辅助核心业务逻辑必须人来复核坑 9原型与开发脱节当时怎么做的用 Stitch 做了原型导出压缩包给 AIAI 说「好的」然后自己瞎写。出了什么问题开发出来的东西和原型完全不一样因为 AI 根本读不懂压缩包。根因交付协作能力缺失。不知道原型交付的正确格式不知道要做开发前对齐。现在怎么解决用分享链接而不是压缩包AI 可以通过链接访问原型页面正确读取设计内容开发前做原型评审把原型截图或链接给 AI让它先描述「你理解这个页面有哪些元素、交互逻辑是什么」确认理解一致再开发原型标注关键信息在原型上标注尺寸、颜色、交互逻辑、特殊状态减少 AI 的理解偏差组件级开发不要让 AI 一次开发整个页面按组件拆分每个组件开发完确认后再继续坑 10性能和体验考虑不足当时怎么做的AI 怎么写就怎么用没有考虑性能和用户体验。出了什么问题实时渲染导致频闪、系统变卡页面渲染过快没有过渡效果没有考虑目标设备公立医院老旧电脑的性能加载时全屏白屏没有进度提示。根因性能优化和用户体验设计能力不足。不知道要考虑目标设备性能、渲染策略、加载体验。现在怎么解决目标设备调研先了解用户用什么设备性能如何针对性优化渲染限流不要实时渲染限制渲染频率如每秒 10 次或只渲染可视区域分区渲染复杂画面分区域渲染只重绘变化的区域不要全量重绘加载体验用流式生成、进度条、骨架屏不要让用户面对白屏等待过渡动画页面切换、元素出现添加过渡动画控制在 1-2 秒根据元素数量调整性能监控关注帧率、加载时间、内存占用发现性能问题及时优化坑 11一轮对话就开干盲目相信 AI 的输出当时怎么做的分两个阶段。需求阶段我把想法一句话丢给 AIAI 说「好的我明白了」我就直接让它开始做。没有让 AI 提问澄清没有和 AI 头脑风暴没有让 AI 给出多个方案建议一轮对话就定了方向。验证阶段AI 改完代码说「已经修复了」我就信了跑一下能打开页面就觉得没问题。没有多轮检查没有从多个角度验证 AI 是否真的改对了、有没有引入新问题。出了什么问题需求阶段的问题AI 说「明白了」其实是「我猜你是这个意思」。因为没有多轮澄清AI 对需求的理解和我的预期有偏差做出来的东西功能残缺、逻辑不对。比如我以为「生成 PPT」包含模板选择、参数配置、加载提示但 AI 理解的就是一个按钮点了跳结果页。如果一开始让 AI 提问、一起头脑风暴这些偏差在动手前就能发现不至于做完才推翻。验证阶段的问题AI 说「修复了」不代表真的修复了。有好几次AI 改了 A 问题结果把 B 功能搞坏了或者 AI 只改了表面现象根因没解决换个场景又复现了。因为我盲目相信 AI 的输出没有多轮验证这些问题都是后来用户或我自己用到的时候才发现那时候上下文已经很长了修起来更麻烦。根因对 AI 的能力边界认知不足盲目相信 AI 的输出。以为 AI 说「明白了」就是真明白了以为 AI 说「修复了」就是真修复了。没有建立「多轮对话澄清需求 多轮检查验证结果」的交互习惯。现在怎么解决需求阶段多轮对话让 AI 主动提问和头脑风暴第一轮描述想法让 AI 提问不要一轮就定需求。先把想法大致说一下然后明确要求 AI「请针对这个需求提出你不清楚的地方向我提问」。AI 会从用户角色、功能边界、异常场景、技术约束等角度提问你回答的过程就是在澄清需求。第二轮和 AI 头脑风暴让它给建议需求澄清后要求 AI「请给出 2-3 个实现方案分析每个方案的优缺点和适用场景」。AI 会给出你没想到的角度比如「这个功能可以用模板驱动也可以用自由画布两者各有优劣」。头脑风暴能帮你在动手前就想清楚方向避免做到一半推翻。第三轮确认需求输出文档方案确定后要求 AI「请把我们讨论的需求整理成用户故事 功能说明书」。这时候输出的文档是经过多轮澄清和头脑风暴的比你一开始一句话丢给 AI 要完整得多。验证阶段多轮检查多角度验证不盲目相信AI 改完后先让它自查不要 AI 说「改好了」就信。要求 AI「请检查你刚才的修改确认是否完整解决了问题有没有影响其他功能有没有引入新的 bug」。让 AI 自己先过一遍很多低级问题它自查就能发现。多角度验证不要只测一个场景至少从这几个角度验证主流程核心功能是否正常工作边界场景空输入、超长输入、极端值是否处理异常场景网络断开、接口报错、权限不足是否有提示回归测试之前正常的功能有没有被改坏安全检查有没有硬编码密钥、路由 ID 暴露、SQL 注入风险让 AI 写测试用例自动跑要求 AI「请为这个功能写冒烟测试用例覆盖主流程和关键边界场景」。每次改完代码自动跑一遍测试通过了才算真的改好了。不要只靠肉眼点一遍。不确定就追问不要不好意思如果 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 之前的能力对比维度之前半桶水现在提升后用户故事一句话如「登录→生成PPT」简短定方向含角色、功能、价值、验收标准功能说明书没有以为用户故事就是全部详细定实现含页面元素、交互流程、异常场景、安全要求竞品分析不做从零瞎想必做至少体验 3 个竞品找差异化需求管理想到什么加什么需求喷涌MoSCoW 优先级先 MVP 再迭代技术选型全交给 AI多方案对比人来决策小步验证Agent 协作一个 Agent 做到尾多 Agent 分工Subagent 并行上下文管理不压缩聊到尾主动压缩分阶段开新对话版本控制commit -m “更新”Conventional Commits分支策略CHANGELOG质量门禁没有写完就 pushHook 自动检查不通过不让提交重复操作每次手动说Skill 封装 Hook 自动触发代码审查不做能用就行审查清单 /code-review 冒烟测试性能优化不考虑目标设备调研渲染限流加载体验AI 交互方式一轮对话就开干AI说没问题就信需求阶段多轮澄清头脑风暴验证阶段多轮检查多角度验证可以看到提升是系统性的、全方位的。不是某一个点变强了而是整个工程化思维和方法论建立起来了。尤其是需求文档这块从「只有一句话用户故事」变成了「用户故事 功能说明书两层结构」这是业务能力提升最核心的体现。五、成长建议如果你和我一样也是技术懂一点、业务懂一点但两边都不够深的半桶水下面是我给你的建议。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 MemoryToken 优化增量检查、影响面分析、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 编程中踩过什么坑欢迎在评论区分享我们一起成长。 Vibe Coding 个人成长指南——从初学者到独立完成项目的复盘
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 pushcommit 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 和时间。根因业务调研能力缺失。不知道做产品前要先做竞品分析。现在怎么解决动手前必做竞品分析至少体验 3 个同类产品列出每个产品的核心功能、优势、劣势、定价模式做差异化定位分析竞品没有覆盖的场景或用户痛点找到自己的差异化方向参考但不抄袭借鉴竞品的好设计但要有自己的特色不要照搬输出竞品分析文档把分析结果写成文档作为后续需求和设计的依据具体操作模板竞品分析模板 1. 竞品名称和网址 2. 核心功能列表对比表 3. 优势和劣势 4. 目标用户和定价 5. 我可以借鉴的设计 6. 我的差异化方向坑 2用户故事太简略当时怎么做的用户故事就写「作为用户我希望能够登录系统输出提示词然后选择模板然后选择比例大小然后点击生成按钮后开始生成PPT」比一句话详细一点但本质上还是在描述用户想要什么。而且我以为写了用户故事就够了不需要别的文档。出了什么问题AI 生成的功能残缺不全没有忘记密码、没有加载提示、没有错误处理、没有权限区分。不断补需求AI 不断改上下文越来越乱。根因业务分析能力缺失。这里犯了两个错误——一是用户故事写得太简略定不了方向二是混淆了用户故事和功能说明书的区别以为用户故事就是全部功能说明书照着补充即可。结果两层都缺失AI 只能靠猜。先澄清一个概念用户故事 ≠ 功能说明书维度用户故事User Story功能说明书Functional Spec核心视角用户视角我想要什么、为什么系统视角系统应该怎么做关注重点为什么价值/目的怎么做页面元素/交互逻辑/异常处理详细程度简短一两句话详细包含页面元素、字段、交互、异常典型格式“作为角色我想要功能以便价值”页面元素清单 交互流程 异常场景 验收标准给谁看产品、开发、测试都能快速看懂主要给开发和测试看现在怎么解决分两层写各司其职第一层用户故事简短定方向故事用户登录 作为未登录用户我希望通过用户名和密码登录系统 以便访问需要身份验证的功能。 验收标准 - 正确凭证可以登录成功 - 错误凭证有明确提示 - 未登录访问受保护页面自动跳转登录页作用让 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 的建议需要人来判断。现在怎么解决至少对比 2-3 个技术方案每个方案列出优缺点、学习成本、社区活跃度、适用场景按评估维度打分比如开发效率、性能、可维护性、生态成熟度加权后选总分最高的参考主流项目的技术栈看看 GitHub 上同类项目用什么技术栈为什么人来做最终决策AI 提供选项和分析人来拍板不要把决策权完全交给 AI小步验证技术选型后先做一个最小原型验证可行性不要一上来就全量开发坑 4一个 Agent 从头做到尾当时怎么做的整个项目就一个 AI Agent需求、设计、开发、测试全是它。出了什么问题上下文过长导致幻觉、改不动代码、不同阶段的内容相互污染、agents.md 写太长反而降低输出质量。根因AI 协作模式认知缺失。不知道要分角色、分 Agent、分模块。现在怎么解决按角色分 Agent产品 Agent需求分析、开发 Agent写代码、测试 Agent写测试、质检 Agent代码审查各司其职按模块拆分开发不要一个 Agent 做整个项目每个功能模块开新对话或新 Agent及时压缩上下文每完成一个功能或每 15-20 轮对话执行/compact压缩角色定义简洁聚焦agents.md 不要写满所有角色的职责每个 Agent 只加载自己角色的定义Subagent 并行处理独立任务如代码审查和测试可以并行执行提高效率坑 5不知道压缩上下文当时怎么做的一个对话从头聊到尾从来没压缩过。出了什么问题对话到后期 AI 开始遗忘、幻觉把删掉的代码又加回来改一个按钮都困难。根因上下文管理能力缺失。不知道 AI 的上下文窗口有限不知道要主动管理。现在怎么解决主动压缩每 15-20 轮对话或完成一个功能后执行/compact压缩前保存关键信息把重要决策、技术选型、待办事项写到项目文档里防止压缩后丢失压缩后验证压缩后问 AI「复述当前项目进度和关键决策」确认关键信息没丢开新对话不同阶段需求→设计→开发→测试开新对话依赖项目文档传递信息而不是靠上下文控制单轮输出量精准提问不要让 AI 输出不必要的长篇大论坑 6Git 提交没有规范和门禁当时怎么做的git add . git commit -m 更新 git push写完就 push没有任何检查。出了什么问题commit message 混乱无法追溯历史改出 bug 也不知道直接推到远程想回退找不到哪个版本是好的。根因版本控制和工程化能力缺失。不知道提交规范、分支策略、质量门禁。现在怎么解决Conventional Commits 规范commit message 用feat: 添加登录功能、fix: 修复登录页样式错乱、refactor: 重构用户模块格式小步提交每个小功能或每个 bug 修复单独 commit不要攒一大堆一起提交分支策略main 分支保持稳定开发在 feature 分支完成后合并提交前检查commit 前跑 lint 单元测试通过才提交Hook 质量门禁用 Hook 拦截 git commit自动跑检查不通过不让提交写更新日志每个版本写 CHANGELOG记录新增功能、修复的 bug、破坏性变更坑 7重复操作每次手动说当时怎么做的每次改完代码都跟 AI 说「提交代码」「更新文档」「加注释」每次都要重复一遍。出了什么问题效率极低而且经常遗漏——有时候忘了让 AI 提交有时候忘了更新文档有时候忘了加注释。根因自动化意识缺失。不知道可以用 Skill 封装重复操作用 Hook 自动触发。现在怎么解决自定义 Skill把重复操作封装成斜杠命令如/git-save一键 addcommitpush、/update-docs更新项目文档、/add-comments给代码加注释Hook 自动触发提交后自动更新文档、自动跑测试不需要手动提醒写进角色定义在 Agent 的角色定义里写明「每次修改代码后自动提交并更新文档」让 AI 自觉执行模板化常用的提示词、文档模板、测试模板保存下来每次直接用坑 8代码质量全靠 AI 自觉当时怎么做的AI 写完代码跑起来能用就行没有做系统的代码审查和测试。出了什么问题没有路由守卫、没有异常处理、没有权限管理、报错英文、安全隐患、响应式缺失、AI 自行加功能。根因质量保障能力缺失。不知道要做代码审查、测试、安全检查。现在怎么解决代码审查清单每次 AI 写完代码按清单检查——路由守卫、异常处理、权限控制、输入校验、安全漏洞、响应式、中文提示/code-review 命令用 AI 的代码审查功能自动扫描按 Critical/High/Medium/Low 分级冒烟测试用例写一套核心功能的冒烟测试每次改完跑一遍确保没改出大问题安全检查检查是否有硬编码密钥、SQL 注入、XSS、敏感信息泄露、路由 ID 暴露AI 输出约束在角色定义里明确要求「不要自行添加未要求的功能」「所有报错和提示用中文」「必须做异常处理」人工复核核心逻辑AI 审查是辅助核心业务逻辑必须人来复核坑 9原型与开发脱节当时怎么做的用 Stitch 做了原型导出压缩包给 AIAI 说「好的」然后自己瞎写。出了什么问题开发出来的东西和原型完全不一样因为 AI 根本读不懂压缩包。根因交付协作能力缺失。不知道原型交付的正确格式不知道要做开发前对齐。现在怎么解决用分享链接而不是压缩包AI 可以通过链接访问原型页面正确读取设计内容开发前做原型评审把原型截图或链接给 AI让它先描述「你理解这个页面有哪些元素、交互逻辑是什么」确认理解一致再开发原型标注关键信息在原型上标注尺寸、颜色、交互逻辑、特殊状态减少 AI 的理解偏差组件级开发不要让 AI 一次开发整个页面按组件拆分每个组件开发完确认后再继续坑 10性能和体验考虑不足当时怎么做的AI 怎么写就怎么用没有考虑性能和用户体验。出了什么问题实时渲染导致频闪、系统变卡页面渲染过快没有过渡效果没有考虑目标设备公立医院老旧电脑的性能加载时全屏白屏没有进度提示。根因性能优化和用户体验设计能力不足。不知道要考虑目标设备性能、渲染策略、加载体验。现在怎么解决目标设备调研先了解用户用什么设备性能如何针对性优化渲染限流不要实时渲染限制渲染频率如每秒 10 次或只渲染可视区域分区渲染复杂画面分区域渲染只重绘变化的区域不要全量重绘加载体验用流式生成、进度条、骨架屏不要让用户面对白屏等待过渡动画页面切换、元素出现添加过渡动画控制在 1-2 秒根据元素数量调整性能监控关注帧率、加载时间、内存占用发现性能问题及时优化坑 11一轮对话就开干盲目相信 AI 的输出当时怎么做的分两个阶段。需求阶段我把想法一句话丢给 AIAI 说「好的我明白了」我就直接让它开始做。没有让 AI 提问澄清没有和 AI 头脑风暴没有让 AI 给出多个方案建议一轮对话就定了方向。验证阶段AI 改完代码说「已经修复了」我就信了跑一下能打开页面就觉得没问题。没有多轮检查没有从多个角度验证 AI 是否真的改对了、有没有引入新问题。出了什么问题需求阶段的问题AI 说「明白了」其实是「我猜你是这个意思」。因为没有多轮澄清AI 对需求的理解和我的预期有偏差做出来的东西功能残缺、逻辑不对。比如我以为「生成 PPT」包含模板选择、参数配置、加载提示但 AI 理解的就是一个按钮点了跳结果页。如果一开始让 AI 提问、一起头脑风暴这些偏差在动手前就能发现不至于做完才推翻。验证阶段的问题AI 说「修复了」不代表真的修复了。有好几次AI 改了 A 问题结果把 B 功能搞坏了或者 AI 只改了表面现象根因没解决换个场景又复现了。因为我盲目相信 AI 的输出没有多轮验证这些问题都是后来用户或我自己用到的时候才发现那时候上下文已经很长了修起来更麻烦。根因对 AI 的能力边界认知不足盲目相信 AI 的输出。以为 AI 说「明白了」就是真明白了以为 AI 说「修复了」就是真修复了。没有建立「多轮对话澄清需求 多轮检查验证结果」的交互习惯。现在怎么解决需求阶段多轮对话让 AI 主动提问和头脑风暴第一轮描述想法让 AI 提问不要一轮就定需求。先把想法大致说一下然后明确要求 AI「请针对这个需求提出你不清楚的地方向我提问」。AI 会从用户角色、功能边界、异常场景、技术约束等角度提问你回答的过程就是在澄清需求。第二轮和 AI 头脑风暴让它给建议需求澄清后要求 AI「请给出 2-3 个实现方案分析每个方案的优缺点和适用场景」。AI 会给出你没想到的角度比如「这个功能可以用模板驱动也可以用自由画布两者各有优劣」。头脑风暴能帮你在动手前就想清楚方向避免做到一半推翻。第三轮确认需求输出文档方案确定后要求 AI「请把我们讨论的需求整理成用户故事 功能说明书」。这时候输出的文档是经过多轮澄清和头脑风暴的比你一开始一句话丢给 AI 要完整得多。验证阶段多轮检查多角度验证不盲目相信AI 改完后先让它自查不要 AI 说「改好了」就信。要求 AI「请检查你刚才的修改确认是否完整解决了问题有没有影响其他功能有没有引入新的 bug」。让 AI 自己先过一遍很多低级问题它自查就能发现。多角度验证不要只测一个场景至少从这几个角度验证主流程核心功能是否正常工作边界场景空输入、超长输入、极端值是否处理异常场景网络断开、接口报错、权限不足是否有提示回归测试之前正常的功能有没有被改坏安全检查有没有硬编码密钥、路由 ID 暴露、SQL 注入风险让 AI 写测试用例自动跑要求 AI「请为这个功能写冒烟测试用例覆盖主流程和关键边界场景」。每次改完代码自动跑一遍测试通过了才算真的改好了。不要只靠肉眼点一遍。不确定就追问不要不好意思如果 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 之前的能力对比维度之前半桶水现在提升后用户故事一句话如「登录→生成PPT」简短定方向含角色、功能、价值、验收标准功能说明书没有以为用户故事就是全部详细定实现含页面元素、交互流程、异常场景、安全要求竞品分析不做从零瞎想必做至少体验 3 个竞品找差异化需求管理想到什么加什么需求喷涌MoSCoW 优先级先 MVP 再迭代技术选型全交给 AI多方案对比人来决策小步验证Agent 协作一个 Agent 做到尾多 Agent 分工Subagent 并行上下文管理不压缩聊到尾主动压缩分阶段开新对话版本控制commit -m “更新”Conventional Commits分支策略CHANGELOG质量门禁没有写完就 pushHook 自动检查不通过不让提交重复操作每次手动说Skill 封装 Hook 自动触发代码审查不做能用就行审查清单 /code-review 冒烟测试性能优化不考虑目标设备调研渲染限流加载体验AI 交互方式一轮对话就开干AI说没问题就信需求阶段多轮澄清头脑风暴验证阶段多轮检查多角度验证可以看到提升是系统性的、全方位的。不是某一个点变强了而是整个工程化思维和方法论建立起来了。尤其是需求文档这块从「只有一句话用户故事」变成了「用户故事 功能说明书两层结构」这是业务能力提升最核心的体现。五、成长建议如果你和我一样也是技术懂一点、业务懂一点但两边都不够深的半桶水下面是我给你的建议。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 MemoryToken 优化增量检查、影响面分析、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 编程中踩过什么坑欢迎在评论区分享我们一起成长。