先把话说清楚：氛围编程本身没问题，问题出在你身上。
你听说可以跟AI对话就能写出软件，于是觉得自己是魔法师。打开AI，用一句话描述你的想法，然后期待奇迹降临。结果呢？代码一塌糊涂，界面颜色乱飞，页面跳转失灵，应用勉强能跑但随时崩溃。
然后你怪AI不行。
真相是：AI产生幻觉不是因为它坏了，而是因为你什么都没给它。没有结构，没有清晰度，没有基础。AI是翻译器，把你的意图转化成代码。但如果你的意图本身就是一团浆糊，代码自然也是浆糊。
修复方法不是更好的提示词，而是更好的理解。
一旦你真正知道自己在构建什么，提示词就变得简单了。
+ 文档先行，代码在后
这是所有人都搞错的地方。你打开Cursor，开始聊天，让AI立刻写代码。没有计划，没有参考，没有真相来源。这就是为什么你的项目在写了几个文件后就崩溃。
正确的系统是：先写文档，再写代码。永远如此。
在写任何一行代码之前，你应该先写好项目的规范文档。清晰、具体、没有歧义地描述你要构建什么。
为什么？因为AI编码工具能力很强但确定性很低。它们在没有结构性护栏的情况下执行任务。缺乏锁定的约束和权威文档会导致AI臆造需求、擅自做架构决策、写出解决你从未提出的问题的代码。
失败模式不是编码能力不足，而是纪律和上下文保持的缺失。
+ 六份核心文档
在动手写代码之前，你需要准备这些：
PRD.md是产品需求文档，完整规格说明。你在构建什么，为谁构建，有哪些功能，什么在范围内，什么明确排除在外。这是你的契约。AI读完就知道“完成”对你意味着什么。
APP_FLOW.md记录每个页面和用户导航路径。什么触发每个流程，成功时发生什么，错误时发生什么。这防止AI猜测用户如何在你的应用中移动。
TECH_STACK.md锁定每个包、依赖、API和工具的精确版本。当AI看到“用React”，它可能选任何版本。当它看到“Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3”，它就会精确构建你指定的东西。
FRONTEND_GUIDELINES.md是你的完整设计系统。字体、精确十六进制色值的调色板、间距比例、布局规则、组件样式、响应式断点。AI为它创建的每个组件参考这份文档。
BACKEND_STRUCTURE.md定义数据库模式，每个表、列、类型和关系。认证逻辑、API端点契约、存储规则和边缘情况。
IMPLEMENTATION_PLAN.md是逐步构建序列。不是“构建应用”，而是：步骤1.1初始化项目，步骤1.2安装依赖，步骤2.1按前端指南构建导航栏组件。步骤越多，AI猜测越少。
+ 两个会话文件
CLAUDE.md是AI每次会话自动首先读取的文件。它包含每个AI会话必须遵循的规则、约束、模式和上下文。把它想象成AI针对你特定项目的操作手册。
progress.txt是所有人都忽略的文件。它追踪已完成、进行中和下一步的内容。每次完成功能就更新它，每次开始新会话AI就先读取它获取上下文记忆。没有它，每个新会话都从零上下文开始。
AI在会话之间没有记忆。当你关闭终端、打开新终端或开始新聊天，一切都消失了。progress.txt是你的外部记忆，是会话之间的桥梁。
+ 审问系统
在写文档之前，让AI把你的想法撕碎。
这是改变一切的提示词：“在写任何代码之前，在规划模式下无休止地审问我的想法。不要假设任何事情。问问题直到没有假设剩下。”
AI在你的清晰度结束的地方产生幻觉。所以如果你延伸你的清晰度，你就迫使AI在开始构建之前找到你思维中的漏洞。
+ 理解核心概念
组件是可复用的界面片段。按钮是组件，导航栏是组件，产品卡片是组件。当你说“给我建一个落地页”，AI必须决定创建什么组件。如果你不指定，它就猜测。
更好的提示词：“构建一个落地页，包含这些组件：导航栏、英雄区、功能网格三张卡片、推荐轮播、行动召唤区、页脚。”
状态是会变化的数据。当你点击按钮有事情发生，状态改变了。当你的按钮什么都不做，通常是状态问题。点击发生了，但没有东西告诉应用更新。
响应式意味着你的网站在所有屏幕尺寸上都能工作。移动优先意味着你先为最小屏幕设计，然后为更大屏幕添加复杂性。这不是偏好，是策略。
+ 工具链
Cursor是你的代码编辑器，有四种模式：Ask模式只读，用于理解代码；Plan模式用于在编码前架构；Agent模式是主力，自主写代码、编辑文件、运行命令；Debug模式用于顽固的bug。
Claude用于重度思考：审问想法、写六份核心文档、规划架构。
Kimi K2.5是前端实现的专家。你可以给它截图或设计稿，它生成紧密匹配视觉的功能性前端代码。
Codex是你的调试器和终结者。在文件和架构构建完成后使用它。当结构就位但东西在崩溃时，让它找到你遗漏的bug。
多工具工作流：Claude做思考，Cursor或Claude Code或Kimi K2.5做构建，Codex做调试和收尾。
+ 迭代是常态
每个人的第一个输出很少是对的。这没关系。
好的迭代：“产品网格在桌面端显示4列但我需要3列。卡片图片被拉伸了，应该是object-cover。数据获取时没有加载状态。”
坏的迭代：“看起来不对，修一下。”
具体。永远具体。
+ 发布前检查
在手机上能用吗？实际在手机上打开它。在不同浏览器能用吗？没有数据时会发生什么，空状态处理了吗？错误数据呢？慢网络呢？快速点击能打破它吗？
不要在回答这些问题之前发布。你的用户会找到你遗漏的每一个bug。
+ 完整系统总结
构建前：运行审问提示词，回答每个问题，生成六份核心文档，写CLAUDE.md，创建progress.txt，收集UI截图参考，初始化git。
构建中：AI每次会话先读CLAUDE.md和progress.txt，用Ask和Plan模式架构，用Agent模式实现，小块工作，给出引用文档的具体提示词，每个功能后提交git并更新progress.txt。
发布前：检查移动端、错误状态、空状态，验证秘钥隐藏，端到端测试主用户流程。
氛围编程不是黑魔法。它是细致的规划、系统、文档、词汇和迭代。你审问你的想法，写你的文档，设置持久化和自我改进，为每个阶段使用正确的工具，用具体术语描述工作，追踪会话间的进度，提交代码，然后发布。
AI现在做所有的打字。你做所有的思考。
现在你没有任何借口了。去构建点什么吧。
x.com/kloss_xyz/status/2018097344345223455
热门跟贴