从“凭感觉写代码”到项目崩溃，中间只隔了一个功能迭代。

很多人把这种模式称为 Vibe Coding，其实就是典型的“提示词 → 生成 → 运行 → 报错 → 再次提示”的死循环。在项目规模很小的时候，这种工作流简直是神级体验，以前需要写一周的 Demo，现在一个晚上就能跑起来，感觉就像身边坐了个 24 小时待命的高级工程师。

但问题在于，当你试图把这个原型变成一个真正的产品时，噩梦就开始了。

一个典型的崩溃场景是这样的：你让 AI 改一个按钮的颜色，结果它顺便把导航栏给改了；你让它修复导航栏，结果登录鉴权突然失效了；等你把鉴权修好，发现页面一半的样式全丢了。这时候你的聊天记录已经不像在写代码，更像是在跟 AI 吵架。

深挖原因，其实是因为我们太依赖“感觉”而忽略了架构。很多人的 Prompt 简单到只有一句 Build me a project management app，没有任何需求文档，没有技术约束，更没有架构设计。在这种情况下，AI 只能在概率分布中随机猜测你的意图。随着对话上下文（Context）越来越长，AI 开始出现严重的遗忘或产生幻觉，在修 A Bug 的同时引入 B Bug。

为了解决这个问题，我开始尝试把传统的 SDLC（软件开发生命周期）强行引入到 AI 工作流中。不要直接写代码，而是先定义 Specs（规格说明书）。

一个比较有效的实操流程是：

一、定义需求文档：在启动项目前，先用一个独立的 Markdown 文件记录所有功能点、用户路径和边界条件。
二、设计技术架构：明确规定使用什么状态管理、什么样的文件夹结构、API 的定义规范。
三、分步实施：将大功能拆解成极小的原子任务，每次只让 AI 处理一个具体的文件或函数，而不是让它一次性生成整个页面。

比如在定义组件时，我会给 AI 一个严格的约束模板：

## Component Spec: UserProfile
- Responsibility: Display user basic info and handle avatar upload.
- Constraints: 
  - Must use Tailwind CSS for styling.
  - No inline styles allowed.
  - Use Zod for input validation.
- API Dependency: GET /api/user/profile

这种从“凭感觉”转向“定规格”的转变，虽然在起步阶段慢了一点，但能极大地减少后期由于上下文漂移导致的重构成本。对于想要从入门到进阶的 AI 开发者来说，学会写 Specs 远比学会写 Prompt 更重要。