AI编程翻车实录：零代码交付写作助手的避坑指南

引言：AI编程的真实面貌

当各种「一句话让AI做出完整项目」的视频充斥社交媒体时，真实的AI编程体验究竟是什么样的？一位B站UP主用一整晚的实战录屏给出了答案——AI编程确实能交付可用产品，但翻车是常态，关键在于你是否知道怎么救场。

这位创作者全程不写一行代码，仅通过与Claude对话，在一个晚上内完成了一个AI写作助手的开发。然而过程中连翻三次车：AI差点删除项目文档、核心功能调试耗时20分钟、前后端通信完全断裂。所有翻车和修复过程一刀未剪，完整呈现了Vibe Coding的真实状态。

Vibe Coding（氛围编程）这个概念由Andrej Karpathy在2025年初提出，指的是开发者不再逐行编写代码，而是通过自然语言描述需求，让AI生成代码，人类只负责验收和调整。Karpathy是OpenAI的联合创始人之一、前特斯拉AI总监，他的这一表态被视为对AI编程能力边界的一次诚实定义——它精准描述了一种正在形成的新开发范式，程序员的核心能力正从「写代码」转向「描述需求」和「诊断问题」。

Karpathy提出Vibe Coding概念的时间节点值得注意——2025年初正是AI编程工具从实验性质走向生产力工具的转折期。在此之前，GitHub Copilot已经积累了超过百万付费用户，Cursor编辑器在开发者社区迅速走红，而Anthropic的Claude则在长上下文代码理解上展现出显著优势。Karpathy选择在这个时间点定义Vibe Coding，实际上是在为整个行业正名：AI编程不是未来概念，而是当下正在发生的生产方式变革。但他同时也在暗示边界——他自己在演示中也承认「我不真正理解代码细节」，这种坦诚恰恰说明了人类角色的不可替代性。

四步流程：从想法到可运行产品

第一步：需求文档化

将脑中模糊的想法转化为AI能理解的结构化需求。创作者的原始需求极其简单：「做一个AI写作助手，左边贴文章选风格点润色，右边出结果」。仅凭这一句话，AI就自动生成了一份正式的需求文档，包含功能模块、交互逻辑和预期效果。

这一步的核心价值在于——你不需要会写PRD（产品需求文档），但你必须能用大白话把想要的东西说清楚。AI负责将自然语言翻译成技术语言。

PRD在传统软件行业中是产品经理的核心交付物，通常包含功能描述、用户故事、交互流程和验收标准，一份完整的PRD撰写往往需要数天甚至数周。AI编程工具的出现正在改变这一流程，将过去由产品经理承担的高门槛「需求翻译」工作变成了自动化任务。但这并不意味着人类可以完全退出——AI生成的需求文档仍然需要人类审核，确保没有遗漏关键的边界条件和异常处理逻辑。

第二步：技术方案设计

让AI根据需求文档输出技术选型和架构方案：用什么框架搭建、各模块如何配合、数据如何流转。这一步相当于让AI扮演技术架构师的角色。

第三步：任务拆解

将整体方案拆分为具体的小任务，每个任务明确做什么、做到什么程度。这种颗粒度的拆解是保证AI不跑偏的关键——任务越小越具体，AI犯错的空间就越小。

这一策略并非经验直觉，而是有认知科学和工程实践支撑的方法论。大语言模型的注意力机制在处理长指令时存在「中间遗忘」现象（Lost in the Middle），即模型对指令开头和结尾的遵从度高于中间部分。当一个任务包含过多约束条件时，模型丢失部分约束的概率会显著上升。此外，任务拆解还借鉴了敏捷开发中User Story拆分的原则——每个Story应当是可独立验收的最小交付单元。在AI编程场景中，这意味着每次对话应该只让AI完成一个可立即测试的功能点，而非一次性生成整个模块。

第四步：逐任务编码与调试

按任务列表逐条让AI编写代码，写完后统一运行调试。翻车往往就发生在这一步。

三次翻车与现场救援

翻车一：AI擅自清理项目目录

AI有一个「特别讨厌的毛病」——它一开工就想给自己造一个干净的新环境，顺手就把已有的文件清掉。这次实战中，AI直接删除了一份现成的文档。幸好创作者平时有备份习惯，才把文件捞了回来。

教训： AI对「已有资产」缺乏敬畏心，它不会主动判断哪些文件是你的宝贝。你必须在对话开始前就明确告诉它：哪些文件夹绝对不能碰。

翻车二：顶级模型调简单功能耗时20分钟

页面好不容易跑起来，按钮按下去却没反应。前端和后端「说不上话」，浏览器直接拦截了请求。即便使用最顶级的模型，调一个最基础的跨域通信功能也花了整整20分钟。

这里涉及的是CORS（Cross-Origin Resource Sharing，跨域资源共享）问题，这是浏览器的一项基础安全策略。当前端页面和后端API不在同一个域名或端口下运行时，浏览器会默认拦截前端对后端的请求。在本地开发中这极为常见——前端通常跑在localhost:3000，后端跑在localhost:8000，仅仅是端口不同就构成了「跨域」。解决方式是在后端配置允许特定来源的请求通过，但AI生成代码时经常遗漏这个配置，或者配置格式与实际运行环境不匹配。

更深层来看，前后端分离架构是过去十年Web开发的主流趋势，它将用户界面和业务逻辑解耦为独立的应用程序。这种架构提升了团队协作效率和部署灵活性，但也引入了大量「胶水层」配置——CORS策略、API网关、环境变量注入、服务发现等。这些配置代码逻辑简单但极度依赖上下文：它们的正确性不取决于代码本身，而取决于代码运行的具体环境。这恰恰是大语言模型的盲区——LLM擅长生成符合语法的代码片段，却无法感知代码即将运行的真实网络拓扑和端口分配。这解释了为什么AI在「写业务逻辑」时表现优秀，在「配置运行环境」时频繁翻车。

教训： AI生成的代码在隔离环境下可能完美运行，但一旦涉及跨模块通信（如CORS配置、API路由、环境变量），就极易出错。这是AI编程中最常见的翻车场景之一。

翻车三：润色功能接错服务

核心的文章润色功能接入了错误的后端服务，导致功能完全失效。这类错误往往隐蔽，表面上代码没有报错，但实际逻辑完全走偏。

现代Web应用通常采用前后端分离架构，后端还可能拆分为多个微服务，每个服务有独立的API地址和端口。大语言模型的工作方式是基于概率预测下一个token，它并不真正「理解」服务间的拓扑关系。当项目中存在多个相似的服务时，AI很容易将接口地址张冠李戴。这类错误不会触发代码层面的报错，只有在实际运行并检查返回结果时才能发现，属于最难排查的隐蔽Bug之一。

教训： AI在多服务架构中容易混淆接口地址和服务名称，需要人工核验关键连接点。

核心方法论：给AI立规矩

创作者总结出的最重要经验是：光让AI写还不够，你得在它动手之前先把规矩画清楚。 具体包括三个维度：

文件保护规则 —— 明确哪些目录和文件AI碰都不能碰
运行模式约束 —— 指定开发时使用哪种模式启动
依赖处理协议 —— 缺东西时不能硬上，要先「打招呼」确认

这层规矩比AI写得多快、写得多漂亮都重要。用创作者的话说：「它是你下班关电脑之前，敢让AI自己继续跑的底气。」

这套方法论的本质其实与软件工程中的「防御性编程」思想一脉相承。防御性编程最早可追溯到1970年代NASA的航天软件工程实践，核心理念是「永远假设输入不可信、协作方会犯错」。在传统团队中，这体现为代码审查（Code Review）、类型检查、单元测试和持续集成流水线。进入AI编程时代，这些防御机制需要被前置和重新设计：你无法对AI做Code Review（因为代码量太大且生成速度太快），所以防线必须从事后检查转向事前约束。创作者提出的「文件保护规则」和「依赖处理协议」本质上是将传统的.gitignore、lockfile和CI规则翻译成了自然语言形式的系统提示词（System Prompt），让AI在生成代码之前就已经内化了这些约束。

如何判断AI项目视频的真假

这期内容还提供了一个极具实用价值的判断框架：当你看到别人发「AI全自动做项目」的视频时，如何判断它是真正跑起来了，还是只是Demo截了几帧好看的画面？

关键判断标准：

是否展示了完整的调试过程
是否涉及多模块间的真实通信
是否处理了环境配置和依赖问题
功能是否在真实数据下可复现

如果一个视频只展示「输入prompt → 输出成品」的过程，中间没有任何调试环节，大概率是经过大量剪辑或仅展示了理想路径。

总结：AI编程的正确期待

这期实战内容传递了一个务实的信息：AI编程不是「一句话出活」的魔法，而是一种需要人类把控方向、设定边界、诊断问题的协作模式。它的价值在于大幅降低了编码门槛，让不会写代码的人也能交付可用工具，但前提是你得知道AI会在哪里掉链子，以及如何提前防范。

对于想尝试Vibe Coding的读者，建议从小项目开始，建立自己的「AI规矩模板」，并养成频繁备份的习惯。翻车不可怕，可怕的是翻车后不知道怎么把项目拽回正轨。