AI编程实战：先做MVP再写代码的正确开发姿势

在AI编程的实战场景中，一个反直觉的经验正在被越来越多的开发者验证：真正的高手不是急着让AI写代码，而是先把80%的时间花在需求沟通和方案敲定上。B站UP主whosper在其「Cola编程实战开发」系列的第二集中，以一个真实工厂的CAD图纸自动化需求为案例，展示了如何用Cola配合Claude Code完成从需求到MVP的完整前期开发流程。

本文基于该实战视频，梳理其中关于MVP优先、模型配比、工具分工的核心方法论，这些经验对任何想用AI做真实项目的开发者都有实际的借鉴价值。

为什么AI编程要先做MVP

视频作者提出了一个关键观点：在大型开发中，与AI沟通的时间应该占到整个项目的80%。这与很多人对AI编程的想象截然相反——大家往往以为AI编程就是一句提示词生成一堆代码，但真实的工业级开发远非如此。

作者对比了两种场景：简单案例的提示词可能不超过30个字，而真正的大型开发中，AI生成的开发计划「可能已经有上万字」，读起来「像在读一本书」。正因如此，他甚至延伸出一个观点：AI时代的核心能力之一是速读能力，如果一个人一年连一本书都读不完，后期在使用AI时可能会遇到瓶颈。

所谓MVP（Minimum Viable Product，最小可行产品），就是在做一个复杂系统之前，先跑一个「最小可行化」的小样品。MVP的概念最早由Eric Ries在《精益创业》（The Lean Startup）中系统化提出，核心思想是用最小的资源投入来验证核心假设。在传统软件开发中，瀑布模型（Waterfall Model）要求在编码前完成全部需求分析、系统设计和详细设计，这种线性流程虽然逻辑严谨，但往往导致大量返工——因为直到产品交付时才能发现需求理解的偏差。敏捷开发方法论对此进行了修正，而MVP则进一步将「快速验证」推向极致：构建一个仅包含核心功能的原型，通过真实用户反馈来指导后续迭代，避免在错误的方向上过度投入。在AI编程场景下，MVP的意义被进一步放大——由于大语言模型生成代码的不确定性较高（可能出现逻辑错误、API误用、架构不合理等问题），提前用一个最小原型验证核心技术路径的可行性，比一开始就追求功能完善更为关键。如果核心路径走不通，越早发现损失越小。

以这个CAD项目为例，MVP的目标被明确定义为：输入DWG图纸、选择企业规划包、系统自动输出优化后的图纸，同时提供「机器可读的JSON」和「人工可读的对比图」。对于无法确定的项目，系统「不会自动处理」，而是交给人工判断。这种边界清晰的目标设定，正是MVP方法论的精髓——不是做一个什么都能干的系统，而是明确定义什么做、什么不做。

这里值得补充的是，DWG是AutoCAD的原生文件格式，由Autodesk开发并长期维护，是工业设计、建筑、制造等领域最广泛使用的CAD文件格式之一。DWG文件内部以二进制方式存储了图形实体（线段、圆弧、多段线、样条曲线）、图层信息、标注尺寸、块引用（Block Reference）、外部参照（Xref）等复杂数据结构。与之对应的DXF（Drawing Exchange Format）是AutoCAD的文本交换格式，虽然可读性更好，但在工业实践中DWG仍是主流交付格式。对DWG文件进行程序化解析和修改，通常需要借助Open Design Alliance（ODA）提供的开源Teigha库（现更名为ODA SDK），或者Autodesk官方的ObjectARX SDK和.NET API。Python生态中，ezdxf库可以处理DXF格式，而处理DWG则通常需要先进行格式转换或调用ODA的转换工具。

AI介入CAD自动化的难点不在于「看懂」图纸的视觉内容，而在于理解图纸中各图形实体之间的拓扑关系和工程语义——例如一条线段究竟代表墙体、管道还是标注引线，需要结合图层命名规则（如「WALL」层、「PIPE」层）、线型定义（实线、虚线、点划线）、颜色编码以及上下文空间关系综合判断。不同企业甚至不同绘图员的图层命名习惯可能完全不同，这使得通用化的CAD自动解析成为一个极具挑战性的工程问题。这也是为什么这个项目需要如此细致的前期方案设计，而不能指望AI「看一眼图纸就能处理」。

蓝图与落地：先改计划再写代码

作者在实战中反复强调一个操作方法：把开发计划当作蓝图来精心打磨。他直言，如果一上来就让AI输出一个「宏伟的架构系统」，反而会脱离实际需求。

视频中出现了一个典型的迭代场景：AI最初根据少量图纸生成了一份冗长的开发计划，包含了DWG解析器、渲染器、规则校验、Agent职责划分等复杂的架构设计。但作者敏锐地意识到，问题的根源在于给AI的案例太少了。于是他补充了更多的前后图纸对比案例，让AI基于更丰富的样本重新理解「优化模式」，并明确要求：

我现在不是需要做一个宏伟的蓝图，我们现在需要做一个可行性的计划。

这个纠偏动作很有代表性，也揭示了大语言模型（LLM）的一个典型行为模式。LLM在预训练阶段接触了大量开源项目的架构文档、技术博客、设计模式教程和系统设计面试题，这些训练材料天然倾向于展示完善的、生产级的系统设计方案。当用户给出的需求描述较为模糊、缺乏具体约束时，模型的注意力机制（Attention Mechanism）会从训练数据的概率分布中召回那些「看起来专业」的复杂架构方案——包括微服务拆分、消息队列、事件驱动架构、多层抽象、依赖注入等设计模式。这并非模型「理解」了需求后做出的工程判断，而是基于条件概率的文本续写特性所致：在「为XX系统设计架构」这类上下文条件下，训练数据中的高频模式就是复杂的企业级方案。因此，通过提供更多具体案例（few-shot prompting）来锚定输出风格和复杂度级别，或者在提示词中明确限定系统规模（「这是一个单机运行的命令行工具」「不需要分布式架构」），是纠正过度设计的有效手段。本质上，这是在缩小模型的输出概率空间，让它更倾向于生成与实际约束匹配的方案。

作者的经验是：把80%的时间用于反复修改这份计划文件，才能为后期的代码落地打好基础。AI在信息不足时容易「过度设计」，而通过补充真实案例、明确表达意图，可以把AI从空想的架构师拉回到务实的工程师角色。

模型配比：AI编程省钱的实战智慧

一个容易被忽视但极其实用的细节是模型配比策略。作者指出，如果全程使用高级模型开发，「会非常费钱」。

要理解这一点，需要先了解AI API的计费逻辑。Token是大语言模型处理文本的基本计量单位，模型并不直接理解字符或单词，而是将输入文本通过分词器（Tokenizer）切分为token序列后进行处理。不同模型使用不同的分词算法（如BPE——Byte Pair Encoding），导致同一段文本被不同模型切分后的token数量可能有所差异。一般而言，一个英文单词对应1-2个token，一个中文字符对应1-3个token，而代码文本由于包含大量缩进、括号和特殊符号，token密度通常高于自然语言文本。API调用的费用按输入token（prompt tokens）和输出token（completion tokens）分别计价，且输出token的单价通常高于输入token，因为输出阶段需要模型进行自回归推理（autoregressive inference），计算成本更高。不同等级模型的单价差异巨大：以当前的市场价格为参考，顶级推理模型（如Claude Sonnet 4、GPT-4o）的输出token价格约为轻量模型（如Claude Haiku、GPT-4o-mini）的5-15倍。在一个完整的AI编程项目中，方案设计阶段虽然交互轮次多，但每轮的上下文窗口相对可控，总token消耗有限；而代码生成和调试阶段则可能产生大量token消耗，因为每次修改都需要将项目上下文（包括已有代码文件、错误日志、需求描述等）重新传入模型的上下文窗口，形成累积效应。

作者的做法是分阶段使用不同模型：在方案设计、蓝图敲定阶段，调用能力更强的模型来保证输出质量；而在后期执行落地、代码编写阶段，则切换到成本更低的模型（视频中提到约30%的场景可用低配模型）。这种「贵的用在刀刃上」的配比思路，本质上是在输出质量和成本之间寻找帕累托最优（Pareto Optimal）——即在不显著降低关键环节输出质量的前提下，最大限度地降低总成本。将高质量推理能力集中投入到决策影响最大的环节（架构设计、方案选型），而在相对机械的执行环节（按照已确定方案编写代码、格式调整、简单调试）使用经济型模型，是一种理性的资源分配策略。对于需要长期投入的项目来说，这是控制成本的关键。

对于个人开发者和小团队而言，这条经验尤其值得参考——AI编程的成本往往不在单次调用，而在于反复迭代累积的token消耗。一个持续数周的项目，如果全程使用顶级模型，API费用可能轻松达到数百乃至上千美元。合理分配模型等级，能让有限的预算撑更久。

双工具分工：Cola搭框架Warp日常用

在工具选择上，作者采用了一套「双软件」协作策略，这也是本集实战的一大看点。

他使用的开发工具Cola内置了Codex和Claude Code两种模型，负责前期的框架搭建——包括基础架构、脚本等核心部分。Cola是一款面向AI编程场景的集成开发环境（IDE），核心特点是内置了多种大语言模型的编程接口，支持开发者在同一工作流中切换不同的AI后端（如OpenAI的Codex系列和Anthropic的Claude系列），并提供项目级的上下文管理能力——即自动将项目的文件结构、代码依赖关系、配置信息等作为上下文传入模型，使AI能够基于项目全局进行代码生成和修改，而非仅针对单个文件片段。Claude Code则是Anthropic推出的面向终端的编程智能体（Coding Agent），与传统的聊天式AI助手不同，它能够直接在命令行环境中读取项目目录结构、浏览和编辑源代码文件、执行shell命令并分析输出结果、安装依赖包、运行测试等，具备较强的上下文理解和多步推理能力。Claude Code的设计理念是让AI像一个真正的开发者一样在终端中工作，而非仅仅在对话框中返回代码片段。

而在框架搭建完成后，日常使用则交给办公向的AI工具（Warp），因为「它是办公用的，开发软件的能力稍微逊色一些，但处理已经开发好的框架还是有能力的」。Warp是一款由Warp公司开发的现代化终端工具，基于Rust构建，提供了比传统终端（如macOS的Terminal、Windows的CMD）更丰富的交互体验，包括命令分组（Blocks）、智能补全、AI命令搜索等功能。其内置的AI辅助功能主要面向日常开发和运维操作场景，如解释错误信息、生成Shell命令、调试配置文件等，定位上更偏向「让日常终端操作更高效」，而非「从零构建复杂系统」。

这三类工具分别对应了AI编程工作流中的不同层次：Cola提供项目级的AI编排和多模型调度能力，Claude Code提供深度的代码生成和多步推理能力，Warp则提供轻量级的AI辅助命令行操作。理解这种工具分层，有助于开发者根据不同阶段的需求选择最合适的工具，而非试图用一个工具解决所有问题。

这个分工逻辑的本质是：用专业工具做重活，用轻量工具做日常。前期开发需要强大的代码生成和架构能力，而后期使用只需要调用已经跑通的程序包，对工具的要求就低很多。这种搭配既保证了开发质量，又降低了日常使用的门槛和成本。

值得一提的是，作者也澄清了一个常见误区：现在的AI Agent对各种格式（图纸、PPT、图片）的识别能力已经相当强，「你扔进去它基本上都能看懂」。这得益于多模态大模型（Multimodal LLM）的快速发展。以GPT-4V（GPT-4 with Vision）、Claude 3.5 Sonnet的视觉能力为代表，现代多模态模型采用了视觉编码器（Vision Encoder，通常基于ViT——Vision Transformer架构）与语言模型的融合架构，能够将图像分割为若干图像块（patches），通过编码器将其转化为与文本token处于同一语义空间的向量表示，从而实现对图片中文字、图表、流程图、工程图纸的理解和描述。

但需要注意的是，「看懂」和「精确解析」之间仍存在本质差距——多模态模型对图纸的理解是基于视觉特征的语义推断（「这看起来像一个管道连接」），而非基于文件格式的精确数据提取（「这条线段位于图层PIPE-MAIN，起点坐标为(120.5, 340.2)，终点坐标为(220.3, 340.2)，线型为CONTINUOUS」）。对于需要精确修改图纸中特定尺寸标注、调整图层属性、移动图形实体坐标位置的场景，视觉理解是远远不够的，仍然需要结合专业的文件解析库（如ezdxf、ODA SDK）进行结构化的数据读写操作。因此，这类AI编程项目的价值不在于让AI「看懂」文件，而在于让它能够系统化、批量化地处理这些文件所对应的业务问题——将人类工程师的判断逻辑编码为可执行的规则，再由程序批量应用到海量图纸上。

界面是最后一步：先验证能不能跑

作者用一个生动的比喻解释了为什么MVP阶段不需要图形界面。

他把软件开发比作造汽车：「我们先要去验证这个四个轮子加一个板是不是能跑」，解决了核心功能之后，才会需要「车壳子、车门」。而界面就相当于汽车的外壳——它是给消费者的，而不是给开发者自己的。

因此在MVP阶段，这个CAD工具就是一个没有图形界面的脚本：输入图纸，输出处理后的图纸到指定位置即可。它解决的是「功能能不能实现」的核心问题，而非「好不好用」的体验问题。只有当MVP跑通、核心逻辑被验证之后，才有必要投入精力去做界面。

这种「先内核后外壳」的开发顺序，能让开发者避免在功能尚未验证时就陷入界面细节的泥潭，是工程实践中非常成熟的思路。这一原则在AI编程场景中尤为重要，原因有二：其一，AI生成前端界面代码的能力虽然已经相当可观（尤其在React、Vue等主流框架的组件生成上），但前端代码与后端逻辑紧密耦合——如果后端的数据结构、API接口、处理流程频繁变动，前端代码也需要反复重写，每次重写都意味着大量的token消耗（需要将变更后的后端代码和前端代码一起传入模型上下文）和调试时间。其二，界面开发往往会引入「需求发散」的风险：一旦看到了可视化的界面，利益相关者很容易提出各种交互细节的修改要求（按钮位置、颜色方案、动画效果），这些修改虽然对用户体验有价值，但在核心功能尚未稳定时属于过早优化。先用命令行脚本或Jupyter Notebook验证核心处理流程，确认输入输出的数据格式和业务逻辑稳定后再构建界面，是成本和效率的双重最优解。

写在最后

这集实战的价值不在于最终跑通了多复杂的系统——事实上作者坦言「离真正能交给工厂用还有距离」，但它清晰地展示了AI时代大型开发的正确姿势：

沟通重于编码，计划重于代码，验证重于完善。 无论是MVP优先的开发思路、模型配比的成本意识，还是双工具分工与界面延后的工程判断，这些方法论都指向同一个核心——AI编程真正考验的不是写代码的速度，而是需求拆解、方案设计和成本控制的综合能力。

对于想用AI做真实项目的人来说，与其追问「AI能不能写出这段代码」，不如先问自己「我是否把需求想清楚了」。这或许才是这集实战最值得带走的启示。