停止让 AI ‘构建你的应用’

Source: Dev.to

“让 AI 为你构建应用” 的问题

很多人直接从代码开始。他们打开聊天窗口，倾倒一个半成品的想法，然后请求一个 MVP。模型很快返回文件夹、组件、路由，甚至可能还有认证。短短几分钟看起来像是有进展。

但现实会击垮你：

• 应用没有明确的形态。
• 功能边界模糊。
• 技术栈的选择是偶然的。
• 每一次后续提示都会微妙地改变项目。

到第三或第四轮时，你已经不再是“构建”，而是在与一台不断为你做假设的机器进行谈判。

更可靠的工作流

对我而言，效果更好、虽然不那么炫目的工作流是：

在让 AI 接触任何代码之前，我每次都强制执行同样的顺序：

1. 研究想法

• 定义 产品的目标用户。
• 明确 版本 1 必须实现的功能。
• 确认 哪些可以后置。
• 选择与 速度、成本或可维护性 相匹配的技术栈。

2. 写下计划

记录产品定义、约束条件和高层架构。这把模糊的想法转化为具体目标，并为 AI 提供清晰的边界。

3. 将工作拆分为阶段

有了扎实的计划，AI 可以逐块生成代码，专注于当前阶段，而不是漂移到随机功能上。

4. 审核输出

你仍然需要审查 AI 生成的内容，但现在审查的是 基于计划的实现，而不是试图解读一团混乱的代码库。

为什么有效

最小化上下文衰减

AI 会话往往会忘记早期的决定，重新引入已删除的元素，忽视更大的项目上下文。通过把重要的思考写进项目文档，你可以：

• 在切换工具或重新开启会话时不丢失上下文。
• 在模型的短期上下文之外保持持久记忆。

文档胜过对话

聊天看起来很高效，因为它很快，但真正让项目不至于变成烂摊子的，是 文档、约束和明确指令。

对初学者的好处

新手常把生成的代码量误认为是进度。一个充满文件的仓库看起来像是进展，却可能只是“带有更好营销的自动补全”。一个简单的结构——研究、范围、设计，然后把构建工作分块交给 AI——可以防止这种幻觉。

结论

如果你在用 AI 开发副项目，让机器继承 你的思考，而不是让它替你提供思考。这样虽然不够炫目，但结果往往是你下周仍能继续使用的东西。