01 | 先戳破幻想：问题不在AI，在你
氛围编程（Ambient Programming）——听起来很酷，像魔法。你以为对着AI说几句话，它就能自动写出一个完整、健壮、可上线的产品。
于是你打开Cursor或Claude，输入：“帮我做个任务管理App，要好看点。”
然后你期待着，像等待魔术师从帽子里抽出兔子。
结果呢？
代码散落在几个文件里，样式混乱，按钮点了没反应，数据存不进数据库，页面在手机上完全错位。
你试了几次，每次新开的会话都像失忆一样，要从头解释。最后你得出结论：“AI也就那样，根本写不了真实项目。”
但真相是：AI产生幻觉，不是因为它笨，而是因为你给它的输入本身就是一团模糊的臆想。
AI是一个极其强大的“意图翻译器”，它能将清晰、结构化的指令转化为代码。但如果你递给它的是一张潦草的草图，却期待它输出一幅工程蓝图，那翻车简直是必然。
真正要修复的，不是寻找更牛的提示词，而是先让你自己彻底想清楚：你到底要构建什么？
一旦你心里有了清晰、具体、无歧义的设计，对AI的指令就会变得异常简单。
下面这套系统，就是帮你从“想法一团浆糊”走到“产品清晰交付”的完整路线图。
02 | 第一步（也是所有人错的第一步）：文档先行，代码在后
绝大多数人用AI写代码的流程是这样的：
打开编辑器 → 开始和AI对话 → 直接让它写代码。
没有路线图，没有规格书，没有设计稿。
这就像让一支施工队直接开工，却从不给他们建筑图纸。结局只能是盖到一半全塌了。
正确的系统是反过来的：先写文档，再写代码。永远如此。
为什么？
因为当前的AI编码工具（Claude Code、Cursor、ChatGPT等）能力极强，但确定性很低。它们在没有“结构化护栏”的情况下，会自行臆测需求、擅自做技术决策、甚至写出解决你从未提出过的“问题”的代码。
它们缺的不是编码能力，而是纪律和上下文。
所以，在你写第一行代码之前，请先准备好以下六份核心文档。
它们是你和AI之间的“法律契约”，也是项目不跑偏的根基。
03 | 六份核心文档：你和AI的“施工蓝图”
1. PRD.md（产品需求文档）
这是项目的宪法。用清晰、无歧义的语言写明：
你在为谁构建（目标用户）
你要解决什么问题（核心需求）
具体有哪些功能（功能清单，最好分优先级）
什么在范围之内，什么明确排除（防止Scope Creep）
“完成”对你意味着什么（验收标准）
AI读完这份文档，才会真正理解“Done”的定义。
2. APP_FLOW.md（应用流程文档）
用文字或图表描述每一个用户旅程：
从打开应用到完成核心任务，会经过哪些页面？
每个页面上有什么操作？（点击、输入、跳转）
操作成功时，发生什么？（跳转？提示？）
操作失败时，又怎么处理？（错误提示？状态保留？）
这份文档能彻底防止AI胡乱猜测你的产品交互逻辑。
3. TECH_STACK.md（技术栈锁定文档）
AI对“用最新版本”有执念，但这可能带来兼容性问题。你必须锁定一切：
- 框架：Next.js 14.1.0 - 语言：TypeScript 5.3.3 - UI库：shadcn/ui (基于Tailwind CSS) - 数据库：Supabase (PostgreSQL) - 认证：NextAuth.js v4.24 - 包管理器：pnpm 8.15.0
越精确，AI构建的环境就越一致，越可复现。
4. FRONTEND_GUIDELINES.md（前端设计指南）
这是你的可视化圣经。包括：
字体：家族、大小、行高、字重
颜色：主色、辅助色、背景色、文字色，全部使用十六进制或CSS变量明确定义
间距：使用的一致间距比例（如4px基准）
组件规范：按钮、输入框、卡片等的标准样式
响应式断点：在哪些屏幕宽度下布局如何变化
AI会参照这份文档绘制每一个像素，确保视觉统一。
5. BACKEND_STRUCTURE.md（后端结构文档）
定义数据与逻辑的骨架：
数据库模式：每个表、列、数据类型、索引和表间关系
API端点：URL、方法（GET/POST等）、请求体格式、响应体格式、可能的错误码
业务逻辑：关键的认证、授权、数据验证和计算规则
第三方服务：如何集成，API密钥如何管理
6. IMPLEMENTATION_PLAN.md（实施计划文档）
把宏大的“构建一个应用”拆解成原子任务：
阶段1：项目初始化 1.1 用`create-next-app`创建项目，严格按TECH_STACK.md配置 1.2 安装并初始化版本控制（git） 1.3 按FRONTEND_GUIDELINES.md配置Tailwind和基础样式 阶段2：核心功能——任务管理 2.1 在Supabase中创建`tasks`表（依BACKEND_STRUCTURE.md） 2.2 实现任务创建API端点 2.3 按APP_FLOW.md构建任务创建页面组件 ...
04 | 两个会话文件：解决AI的“健忘症”
AI在会话之间没有记忆。新开一个聊天，它就“失忆”了。
你需要为它建立外部记忆系统。
1. CLAUDE.md（AI会话宪法）
这是AI每次开始新会话时必须首先自动读取的文件。它包含：
本项目必须遵守的所有规则和约束
文档索引（指向上述六份核心文档的位置）
代码风格指南（如命名约定、文件组织方式）
本次会话的特定目标
把它想象成AI针对你本项目的专属操作手册。
2. progress.txt（进度追踪文件）
这是最被忽视但最关键的文件。它记录：
已完成的功能（带commit hash）
进行中的任务
下一步待办
每完成一个功能，就更新这个文件。
每次开始新会话，AI第一件事就是读取CLAUDE.md和progress.txt，瞬间获得完整上下文，无缝衔接上次的工作。
这是连接AI碎片化会话的桥梁，是克服其“健忘症”的唯一解药。
05 | “审问系统”：在动工前，让AI撕碎你的模糊想法
在你开始写任何文档之前，先运行这个改变游戏的提示词：
“在写任何代码或文档之前，请进入‘规划与审问模式’。不要假设任何事情。针对我的项目想法，无休止地向我提问，直到我的思维中没有任何模糊、矛盾或遗漏之处。你的目标是暴露我所有未想清楚的假设。”
AI在你清晰度终结的地方开始产生幻觉。
所以，你要主动延伸你的清晰度边界，迫使AI在动工之前，就帮你找出所有思维漏洞：
“用户注册时需要邮箱验证吗？”
“任务支持设置截止时间吗？时区怎么处理？”
“数据需要离线缓存吗？”
“如果用户同时从两个设备登录，状态如何同步？”
这个过程可能持续几轮，但每一轮问答都在夯实项目的地基，避免后续代价高昂的返工。
06 | 掌握核心概念：用AI的语言与它沟通
要让AI准确执行，你需要使用它理解的精确词汇：
组件：UI的可复用构建块。不要说“做个好看的首页”，而要说“构建一个首页，包含以下组件：导航栏（带Logo和用户菜单）、英雄区（大标题+行动按钮）、三列功能卡片区、客户评价轮播、页脚（链接与版权信息）。”
状态：应用中会变化的数据。按钮点了没反应？通常是状态没更新。要明确告诉AI：“点击‘提交’按钮后，应将表单数据存入状态变量formData，并触发handleSubmit函数。”
响应式与移动优先：不是可选项，是必选项。指令应明确：“采用移动优先设计，首先构建移动端布局（<768px），然后使用md:和lg:前缀的Tailwind类分别适配平板和桌面端。”
07 | 构建工具链：让合适的AI做擅长的事
不要指望一个AI解决所有问题。建立多智能体工作流：
Claude 3.5 Sonnet（思考与规划）
用途：进行深度思考，运行“审问系统”，撰写六份核心文档，规划整体架构。
指令示例：“根据我们刚才的Q&A，起草一份完整的PRD.md。”
Cursor（主力构建） 或 Claude Code（自主编码）
用途：在清晰的文档指导下，进行实际的代码编写、文件编辑和命令执行。
指令示例：“请参照FRONTEND_GUIDELINES.md和IMPLEMENTATION_PLAN.md的阶段2.3，构建任务列表组件。”
Kimi Chat（K2.5 前端专家）
用途：特别擅长前端实现。可以给它截图或Figma设计稿，它生成高度还原视觉的前端代码。
指令示例：“这是设计稿截图，请生成匹配的、功能完整的React组件代码。”
Codex 或 GPT-4（调试与收尾）
用途：当代码结构已就位但存在顽固Bug时，用它进行深度调试和代码优化。
指令示例：“应用在提交表单时出现500错误。这是相关API和前端代码，请定位根本原因并提供修复方案。”
工作流总结：让Claude做大脑（规划），Cursor/Claude Code做双手（构建），Kimi做视觉专家（还原UI），Codex做医生（调试）。
08 | 迭代是常态：如何给出有效的反馈
AI的第一版输出很少是完美的。这很正常。关键在于你如何反馈。
坏的迭代：“感觉不对，改一下。” “颜色不好看。”
（AI完全不知道你想要什么。）
好的迭代：
“产品网格在桌面端目前是4列，但根据设计稿，应该是3列。请调整Tailwind的grid-cols-4为grid-cols-3。”
“卡片内的图片被拉伸了，请将object-fit属性改为cover以保持比例。”
“数据加载时，界面是空白的。请添加一个加载状态（旋转指示器），并在FRONTEND_GUIDELINES.md的‘加载状态’部分定义其样式。”
永远具体，永远引用你之前建立的文档（PRD、设计指南等）作为依据。
09 | 发布前终极检查清单
在你说“完成”之前，请亲手进行这些测试：
真机测试：在iPhone和安卓手机上实际打开你的应用。点按、滑动、输入。
跨浏览器测试：在Chrome、Firefox、Safari上分别运行。
边缘情况测试：
空状态：没有数据时，界面显示什么？
错误状态：网络失败、API返回错误时，用户看到什么？
极限操作：快速连续点击按钮、在输入时疯狂切换标签页。
慢速网络：在浏览器开发者工具中模拟3G网络，看加载体验。
安全自查：API密钥、敏感信息是否已放入环境变量，没有硬编码在代码里？
核心用户流程端到端测试：从打开应用到完成核心任务（如创建并发布一个任务），整个流程是否畅通无阻？
不要替你未来的用户发现这些Bug。
10 | 完整系统总结：从想法到上线的路线图
构建前（思考阶段）：
运行“审问提示词”，与AI一起澄清所有模糊点。
基于问答，撰写六份核心文档（PRD, APP_FLOW, TECH_STACK…）。
创建CLAUDE.md（会话宪法）和初始的progress.txt。
收集所有UI参考截图或设计稿。
初始化Git仓库。
构建中（执行阶段）：
每个新会话，指令AI先读CLAUDE.md和progress.txt。
使用Cursor的“Plan模式”或Claude进行模块级架构。
使用“Agent模式”或Claude Code进行具体实现，指令需引用相关文档（“根据FRONTEND_GUIDELINES.md构建XX组件”）。
小块工作，频繁提交：完成一个小功能就git commit，并立即更新progress.txt。
遇到问题，用“Ask模式”或调试工具定位，而非盲目重写。
发布前（质检阶段）：
运行【第09部分】的终极检查清单。
修复所有发现的Bug，更新相应文档。
构建生产版本，进行最终部署。
结语：氛围编程的真谛
氛围编程不是黑魔法。
它是细致的规划、严谨的系统、清晰的文档、精确的词汇和耐心的迭代。
你负责所有深度的思考（审问想法、撰写文档、设计系统、规划流程），而AI负责所有重复的劳作（将你的清晰构思转化为代码）。
AI现在做所有的“打字”，你做所有的“思考”。