将 AI 生成的块放入您的工作系统
请提供您希望翻译的正文内容，我才能为您进行简体中文翻译。
Part 1: 为什么 Vibe Coding 会崩溃
Last month, I spent an afternoon building a URL shortener with Claude.
第一条提示运行得非常顺利。代码出现了。测试通过了。我感觉自己像个巫师。
到了第五条提示，情况变得奇怪。AI 添加了我没有要求的功能，数据库模式被改了两次，而且它记不住 API 端点应该是什么。
到第十条提示时，我已经不再写代码——我在和一台忘记了二十分钟前对话内容的机器进行谈判。
这不是 AI 的失败，而是方法的失败。
大多数人使用 AI 的方式和使用搜索引擎相同：我们提出请求，得到答案，然后继续前进。这对食谱和琐事有效，但对构建软件****无效。
为什么？因为 AI 有一个隐藏的限制——不是技术限制，而是结构性限制。一旦看见它，就再也看不见它了。
在本系列中，我将：
- 向你展示这个限制。
- 向你展示一个简单的规避方法。
解决方案不是更好的提示，而是对工作方式的不同思考。
如果问题从来就不是 AI 本身呢？
1.1 模式：它开始得如此顺利
你一定有这种体验。所有用 AI 构建非平凡项目的人都有这种体验。
- 启动一个新项目，使用 Claude、GPT 或 Copilot。
- 前几次交互感觉像魔法。
Prompt: “Build me a URL shortener API.”- 代码出现。
- 它能运行。
- 你欣喜若狂。
Prompt: “Now add analytics so I can see how many times each short link was clicked.”- AI 加上了分析功能。仍然能运行。两项功能完成。
Prompt: “Add user accounts so people can manage their own links.”- AI 加入了用户账户，但现在开始出问题。
- 第 1 项功能的数据库模式不再完全匹配。
- 第 3 项的认证逻辑与第 2 项的分析查询冲突。
- AI 试图修复，却引入了回归。
上下文窗口被填满，AI 失去对早期决策的追踪，你不再是写代码——而是用键盘驱赶一群猫。
这就是**“vibe coding”**：随意提示 AI 生成代码，期望它们能够自洽。它适用于小脚本和演示，但在真实项目中会因自身重量而崩塌。
为什么？
1.2 你可能已经注意到但从未命名的隐藏限制
简单实验
| 任务 | 描述 | 预期 AI 输出 | 质量 |
|---|---|---|---|
| A（小且聚焦） | 编写一个 Python 函数，接受 URL 字符串并返回 True（如果是有效 URL）或 False（否则）。处理缺少协议、非法字符、域名格式错误等边缘情况。 | 干净、正确、带有良好注释的函数，几秒钟内完成。 | 优秀 |
| B（大且模糊） | 构建一个完整的 URL 缩短服务，包含网页界面、REST API、用户账户、点击分析和数据库。使用 Python。 | 能够运行的东西，但认证部分可能与分析不兼容，数据库模式可能不一致，等等。 | 差 – 中等 |
相同的 AI、相同的模型、相同的能力——唯一的区别是任务的规模和范围。
LLM 具有上下文窗口：一次性能够在工作记忆中保持的信息量上限。
- 小而自包含的问题能够舒适地停留在该窗口内。
- 大型系统设计会溢出窗口：模型忘记早期决策、自相矛盾，产生脆弱的代码。
但还有更深层的洞见。
1.3 改变一切的新设计方法
AI 不像系统架构师那样思考。它不会维护一个包含所有相互关联和权衡的完整项目心理模型。
AI 的思考方式
- “给定输入 X，产生输出 Y。”
- “验证这个字符串。”
- “查询那个数据库表。”
- “格式化这个响应。”
AI 自然不理解的内容
（此处保持原文未翻译的内容，后续将在 Part 2 中继续）
Source: …
- URL 验证器应如何与密钥生成器协同工作。
- 存储管理器应在分析日志记录之前还是之后调用。
- 当重定向处理程序找不到密钥时会发生什么。
这些都是 集成关注点，而不是 AI 的强项。
当开发者在大型任务上遇到 AI 的局限时，通常会：
- 放弃 – “AI 还不适合真实项目。”
- 继续硬逼 – “让我写一个更长、更详细的提示。”
这两种做法都错失了关键。
正确的回应
不要让 AI 构建整个系统。让 AI 构建 函数。你把这些函数连接成系统。
1.4 这能解锁什么
| 角色 | AI | 人类 |
|---|---|---|
| 任务 | 编写优秀的 URL 验证器、密钥生成器、存储管理器、重定向处理程序等（每个都是 功能块）。 | 定义块，指定它们的连接方式，验证连接是否有效。 |
| 范围 | 小而独立的单元，具有明确的输入、明确的输出且没有隐藏依赖。 | 系统级别的架构与集成。 |
| 结果 | 为每个块提供高质量、可测试的代码。 | 通过这些块构建出连贯、可维护的系统。 |
Vibe Coding（前） vs. Functional‑Block Design（后）
| 方面 | Vibe Coding | Functional‑Block Design |
|---|---|---|
| 提示大小 | 为整个系统准备一个巨大的提示 | 为每个块准备多个小提示 |
| 上下文处理 | AI 丢失上下文，产生自相矛盾 | 每个块的上下文都很小且聚焦 |
| 集成方式 | 偶然、脆弱 | 明确且经过设计 |
| 调试难度 | 难以判断是哪个块出错 | 每个块都可以单独测试 |
| 变更方式 | 需要重新生成大段代码 | 只修改一个块，其他保持不变 |
1.5 第 2 部分和第 3 部分的内容预告
在 第 2 部分 我们将介绍 功能块设计 (Functional Block Design, FBD)——一种简单、可重复的方法论，将上述洞见付诸实践。你将学习：
- 如何将系统拆解为功能块。
- 如何编写 块规范（供人类阅读的描述和供 AI 使用的提示）。
- 如何将这些块编排成一个可运行的应用程序。
第 3 部分 将深入探讨测试、版本管理以及块式方法的扩展，展示在项目规模扩大时如何保持 AI 输出的可靠性。
敬请期待！
I) 如何从提示生成代码
如何将所有内容存储在一个 .py 文件中
在第 3 部分，我们将构建完整的 URL 缩短器——所有六个块，集成成一个可运行的系统。
通过本系列的学习，您将拥有一种可重复的方法，将 AI 生成的代码转化为真正协同工作的系统。
再也不用驱赶猫了。
