Vibecoding

一、引言 你可能有过这样的经历：明明已经详细描述了需求，AI 却返回了一段与期望相去甚远的代码；或者 AI 生成的代码虽然基本符合功能要求，却总是缺少关键细节，需要反复修改才能使用。有的时候还修改不对，最终需要推倒重来。其实可能不是 AI 能力有问题，更可能的是使用方法不对。本文会从 PM 的视角出发，分析为什么会出现这种情况，并提供实用的解决方案，帮助你更有效地利用 AI 进行原型开发与验证。 二、为什么 AI 会“乱写” 2.1 AI 不理解你的需求 AI 不会读心术。虽然它功能强大，但依然依赖于你提供的需求描述来理解任务。当 PM 使用过于宽泛或含糊的描述时，AI 会基于自己的“理解”填补细节空白。比如，当你说“帮我做一个登录页面”时，AI 必须自行假设：需要哪些表单字段？实现什么样的校验逻辑？页面设计风格是什么？这些自行假设的细节很可能与你实际期望的大相径庭，导致生成的代码与你的真实需求不符。 2.2 视角差异 PM 习惯从用户体验和业务价值角度思考，而 RD 则从技术实现和代码结构出发。这种思维方式的差异导致：PM 更关注“做什么”而忽略“怎么做”，倾向于使用业务术语而非技术术语，描述问题的方式往往从结果出发，而非从实现路径出发。 以下是一个典型的思维差异示例： PM 思维：“我需要一个能展示用户购买历史的页面，可以按月筛选，并显示消费总额。” RD 思维：“需要实现一个用户订单历史组件，使用 Redux 管理状态，通过 GraphQL 查询按月分组的订单数据，实现过滤逻辑，计算每月总额并在 UI 中展示汇总数据。” AI 生成优质代码需要明确的技术约束和参数，这恰恰是 PM 的技能盲区。当缺乏这些关键技术参数时，AI 往往会生成“看似正确”但在技术实现上存在深层次问题的代码：代码可能能够运行，但缺乏可扩展性和可维护性；可能没有考虑性能优化和边界情况处理；可能使用过时或不适合项目长期发展的技术方案。 2.3 上下文缺失 AI 对项目的了解仅限于你明确告诉它的内容。它无法自行查看你的整个代码库（Agent 除外），理解你公司的设计规范，知道你团队的编码约定，或了解你产品的历史背景。 这种上下文缺失导致 AI 生成的代码虽然功能上可能正确，但可能不符合项目的技术标准和风格规范。对 PM 来说这个问题尤其棘手，因为可能不完全了解所有技术标准和规范细节，难以识别出这些不符合项目要求的地方，导致后续集成时出现各种兼容性问题。 这三个因素相互影响，导致开发 Prototype 时的困境。理解这些根本原因后，我们就能有针对性地解决“AI 乱写”问题。接下来，我们将探讨具体的解决方法。 三、解决 AI 乱写的方法 在解决方案之前，我们已经理解了为什么 AI 会“乱写”——主要源于三个核心问题：需求不明确、视角差异，以及上下文缺失。现在，我们可以针对性地解决这些问题。 3.1 提示词优化 假期刚好在用 Cursor 克隆一个项目，需要修改配置文件，我已经沟通且修改了一些比如 Supabase 的内容，我不知道 Redis 是不是也要修改，这时候发生了下面的对话。 我 Add to Chat 了对应的代码，并说：“env 文件里的我需要处理吗？”想表达的意思是我还需不需要修改 Redis 啊？ Cursor 没明白<处理>其实是我要问是不是<修改>，因为之前上下文的交互，我会天然以为他能理解，结果并没有，最后是我做了澄清，然后解决了问题。 这个小插曲其实很能说明问题 —— 不是 AI 能力不行，而是我没有“说人话”。AI 不像人类同事，没法通过经验和语境猜测我们真正的意图。当 PM 提供模糊需求时，AI 只能自行填补空白，结果往往偏离我们的预期。那么，如何让 AI 更好地理解我们的意图呢？答案是结构化需求描述。因为结构化的描述可以给到更多的需求信息，也限制了 AI 的“胡乱补全”，这里有两种实用方法： 方法一：结构化模板 想让 AI 帮你写好代码，最好用结构化模板来描述需求。这样做有两个好处：一是逼着我们把脑子里模糊的想法变成具体的细节，二是帮助我们不仅说明“要做什么”，还要说明“怎么做”。用这种方式提供的明确指导大大减少了 AI 需要自行猜测的空间，也就一定程度上避免了 AI “乱写”的问题。下面是一个实用的模板，你可以直接套用： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 【需求背景】 - 业务目标：这个功能要解决啥实际问题 - 用户痛点：用户现在遇到什么困难 - 成功指标：怎么判断这个功能做得好 【功能需求】 - 核心功能：具体要做哪些事，越详细越好 - 用户流程：用户会怎么用这个功能，步骤是啥 - 交互反馈：各种操作后会有什么反应，比如成功/失败提示 - 边界场景：异常情况怎么处理，比如网络错误、数据为空 【技术参数】 - 技术栈：用什么框架和库 - 数据模型：需要存储什么数据，结构是怎样的 - 集成点：跟哪些系统对接 - 参考实现：有没有类似的已有功能可以参考 【验收标准】 - 功能验收：具体测试哪些点 - 性能要求：速度要求，比如加载时间 - 兼容性：支持哪些设备和浏览器 比如当我们要做一个登录页面的时候，使用不同提示词描述的效果👇 提示词 结果 普通提示词 做一个登录页面 结构化提示词 展开查看 【需求背景】 业务目标：提高用户账户安全性并简化登录流程 用户痛点：现有登录流程繁琐，缺乏安全性提示，用户经常忘记密码 成功指标：登录成功率提升15%，密码重置请求减少30% 【功能需求】 核心功能： 邮箱/用户名输入字段 密码输入与实时强度检测 “记住我”选项保存登录状态 忘记密码重置流程 第三方账号快速登录选项 用户流程： 用户访问登录页面 输入邮箱/用户名和密码 可选勾选“记住我” 点击登录按钮 系统验证凭据并反馈结果 交互反馈： 输入框即时验证格式，显示错误提示 密码强度实时可视化展示 登录按钮点击后显示加载状态 验证失败时显示具体错误信息和解决建议 成功登录后重定向到首页 边界场景： 用户多次登录失败时的账户保护机制 不同设备同时登录的会话管理 登录超时处理 浏览器自动填充兼容性 【技术参数】 技术栈：React 18 函数组件，TypeScript 组件库：Material UI 表单组件 状态管理：Formik 处理表单状态 验证库：Yup 实现表单验证 认证方案：JWT 认证，支持刷新令牌 数据模型： User: { id, email, username, passwordHash, lastLogin } Session: { id, userId, token, expiresAt, device } 集成点： 认证 API：/api/auth/login, /api/auth/refresh 第三方登录：Google OAuth, Facebook Connect 参考实现： 现有注册页面组件结构 设计系统的表单交互规范 【验收标准】 功能验收： 所有表单字段验证正确工作 密码强度检测准确 “记住我”功能在浏览器关闭后依然生效 第三方登录成功将用户重定向到首页 性能要求： 页面加载时间 < 1.5 秒 登录处理响应时间 < 1 秒 兼容性： 支持 Chrome、Firefox、Safari、Edge 最新两个版本 响应式设计，适配移动端和桌面端 支持键盘导航和屏幕阅读器 可以直接体验或查看代码，其实仅仅从前端展示的样子就能看出来优劣了。以及不要一句话描述需求，你的同事都猜不出来你要的是啥，更何况是没有上下文的AI。 方法二：让 AI 帮你写需求（套娃法） 上面的模板虽然好用，但对不太懂技术的 PM 来说填起来可能有点吃力。特别是“技术参数”那块，可能完全不知道该写什么。这时，我们可以走个捷径：把最初的粗略想法告诉高级 AI 模型（比如 Claude 3.7），让它帮你转换成结构化需求！ 具体怎么操作： 先把你的原始想法写下来 用下面这个提示词让 AI 帮你转换 检查一下 AI 生成的结构化需求，做些必要的调整 把这个结构化需求用于 AI Coding 转换提示词： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 你是拥有10年全栈开发经验的资深技术架构师，擅长将产品需求转化为精确的技术规格。 请将以下业务需求转换为结构化的技术需求文档，遵循以下格式： 1. 【需求背景】- 包含业务目标、用户痛点和成功指标 2. 【功能需求】- 详细的功能点列表、用户操作流程、交互反馈规则和边界场景处理 3. 【技术参数】- 推荐合适的技术栈、数据模型设计、与现有系统的集成点，以及可参考的现有实现 4. 【验收标准】- 具体的功能测试点、性能要求和兼容性标准 在转化过程中请： - 分解模糊的业务需求为明确的技术任务 - 添加开发者需要但PM可能忽略的技术细节 - 识别并补充潜在的边界场景 - 使用业内最佳实践推荐适合的实现方案 - 保持语言简洁明了，每个要点用1-2句话表达 以下是需求： <粘贴你的原始需求> 可以拿一个真实的 case 来试试。 详细内容 结果 最初的想法 做一个用户可以管理自己订阅的页面，可以看到当前状态，进行续订和升级操作。 AI转换后 转换后提示词 用户订阅管理技术需求文档 【需求背景】 业务目标：提供一个集中式界面，让用户便捷地管理其所有订阅服务，提高订阅转化率和续订率。 用户痛点：用户难以追踪多个订阅的状态、到期时间，无法方便地进行续订或升级，导致非主动流失。 成功指标：订阅续订率提升15%，套餐升级转化率达到8%，用户订阅管理相关的客服咨询减少30%。 【功能需求】 订阅总览 以卡片或列表形式展示用户当前所有订阅，包括订阅名称、类型、价格、状态(有效/即将到期/已过期)、到期日期 允许用户筛选和排序订阅(按状态、到期日期、价格等) 提供订阅消费总额统计和每月/年支出预估 订阅详情 点击单个订阅可查看详细信息，包括订阅历史、账单记录、自动续费状态 展示该订阅可用的所有权益和使用情况 显示当前套餐与其他套餐的对比信息 操作功能 续订流程：点击续订按钮→选择续订周期→确认支付方式→完成付款→展示成功状态和新到期日 升级流程：点击升级→展示可升级套餐对比→选择目标套餐→显示差价→确认→完成付款 自动续订管理：开启/关闭自动续订，设置提前提醒时间(默认7天) 订阅取消预约：允许用户提前设置到期不续，但保留随时反悔的选项 边界场景处理 处理降级请求时提供挽留策略(优惠券/折扣/免费延期等) 支持处理订阅支付失败/订阅恢复的状态通知和操作引导 针对即将到期(7/3/1 天)的订阅发送状态提醒和续订建议 订阅权益变更时的通知机制和处理方案 【技术参数】 技术栈推荐 前端：React/Vue 框架，配合 Redux/Vuex 状态管理 后端：REST API 架构，Node.js/Spring Boot 实现 数据库：主数据 MySQL，缓存 Redis，考虑分表存储历史订阅数据 支付集成：Stripe/PayPal API 用于处理续订和升级支付 数据模型设计 用户订阅表(UserSubscription)： - id: UUID - userId: 外键关联用户 - planId: 外键关联订阅计划 - status: ENUM(active, expiring, expired, cancelled, payment_failed) - startDate: TIMESTAMP - endDate: TIMESTAMP - autoRenew: BOOLEAN - paymentMethod: VARCHAR - lastBillingDate: TIMESTAMP - nextBillingDate: TIMESTAMP - reminderDays: INT 订阅计划表(SubscriptionPlan)： - id: UUID - name: VARCHAR - description: TEXT - price: DECIMAL - billingCycle: ENUM(monthly, quarterly, yearly) - features: JSON/TEXT - rank: INT (用于比较套餐层级) 订阅历史表(SubscriptionHistory)： - id: UUID - subscriptionId: 外键关联UserSubscription - action: ENUM(created, renewed, upgraded, downgraded, cancelled) - fromPlanId: UUID - toPlanId: UUID - timestamp: TIMESTAMP - amount: DECIMAL - transactionId: VARCHAR 集成点 用户系统：获取用户信息和认证状态 支付系统：处理续订/升级交易，查询交易历史 通知系统：发送订阅状态提醒和操作确认 权限系统：验证用户对特定订阅的操作权限 分析系统：埋点跟踪用户行为和转化率 【验收标准】 功能测试点 所有订阅状态正确显示，且实时同步支付系统变更 续订流程可完整执行，支持多种支付方式 升级/降级能正确计算价格差异并完成套餐切换 自动续订设置成功后实际按设定执行 提醒通知按用户设置的时间准确推送 性能要求 订阅页面首屏加载时间 < 1.5 秒 订阅列表渲染 (10+ 项) 时间 < 500 ms 支付操作响应时间 < 3 秒 系统需支持每秒 100 次的订阅状态查询 兼容性标准 支持主流浏览器最新两个版本 (Chrome, Safari, Firefox, Edge) 响应式设计，兼容桌面及移动设备 (最小支持 320px 宽度) 支持 iOS 14+ 和 Android 8.0+ 适配暗黑模式和高对比度视觉模式 符合 WCAG 2.1 AA 级无障碍标准 是不是感觉瞬间清晰了很多？原本模糊的需求被展开成了全面的规格说明，涵盖了 AI 需要的细节。 ...