AI 辅助编码的最后一公里
前言
在过去的三个月内，我一直在深度使用AI辅助开发，在这个过程中，我注意到了一个非常有趣的现象：尽管许多工程师都表示自己在使用AI时生产力明显提升，但我们日常使用的软件却并没有明显变好。到底发生了什么？
开发者是如何使用AI的？
我观察到，团队在使用AI时，通常会呈现出以下两种模式：
- 启动者模式
- 迭代者模式
这两种模式都在帮助工程师（甚至非技术用户），在从想法产生到代码实现的过程中，减少了大量思考和操作成本。
启动者模式：从零到MVP
像v0、bolt等图片转代码以及Cursor、Windsurf这一类的AI工具，都在彻底改变开发者启动新项目的工作方式，使用这种模式，通常会：
- 以一个想法开始，描述出你想要实现的功能
- 使用AI工具生成代码
- 在数小时或者数天内，完成一个可以运行的MVP版本
- 专注于快速验证和迭代
成果常常令人惊叹，在AI工具的加持下，只需要花很短时间，就可以把一个想法变成可以运行的Web应用。虽然它可能存在一些问题，但已经可以作为最初的MVP版本，进行快速验证和迭代。
在利用AI工具启动项目的实践过程中，我注意到了社区里面的几位佼佼者：
- AI进化论-花生 —— AppStore付费榜Top1「小猫补光灯」app开发者
- 非技术人员，通过Cursor，开发了「小猫补光灯」app，并成为了AppStore付费榜Top1应用
- 特点：产品Sense，AI native coder，懂得社区运营，通过会议、分享等为自己造势；
- 劣势：没有技术背景，无法解决项目中遇到的复杂问题，仅仅借助AI工具很难完成复杂项目
迭代者模式：日常开发
第二种模式是使用Cursor、Windsurf等AI工具，辅助日常开发工作。和启动者模式相比，这种模式并不那么令人兴奋，但可能更具实用性。使用这种模式，通常会：
- 用AI完成代码补全和建议
- 利用AI工具进行代码重构
- 生成代码注释、测试或文档
- 利用AI工具进行代码评审
- ...
在日常工作中，我使用迭代者模式居多，在实际使用Cursor上手体验的过程中，我发现：
- 存在一个难点 —— 如何用自然语言准确描述你的代码调整诉求，以获得AI的准确响应
AI速度的隐形成本
当你看着一位资深工程师使用 Cursor 或 Copilot 等 AI 工具时，会觉得非常神奇。他们能在短短几分钟内搭起完整的功能结构，还包括测试和文档。但如果你仔细观察，就会发现他们实际上在不停地：
- 将生成的代码重构为更小、更专注的模块
- 补充 AI 漏掉的边界情况
- 加强类型定义和接口设计
- 质疑架构决策
- 添加健全的错误处理
换言之，他们是在用自己多年积累的工程经验，对 AI 的输出进行塑造和约束。AI 加快了他们的实现过程，但真正让代码可维护的是他们的专业知识。 初级工程师往往会忽视这些关键步骤。他们更容易接受 AI 的输出，导致我称之为*“纸牌屋代码”*的现象 —— 看起来完整，但在实际场景下一碰就倒。
知识悖论
我所发现的最耐人寻味的一点在于：AI 工具对有经验的开发者帮助更大，而不是对新手更大。这似乎跟我们期待的相反 —— 难道 AI 不应该让编程更加民主化吗？
事实上，AI 就像你团队里一个非常热情的初级开发者。他们可以很快写出代码，但需要持续的监督和纠正。你对开发了解得越深，就越能更好地引导 AI。
这就产生了我所说的“知识悖论”：
- 资深开发者使用 AI 来加速他们“已经知道怎么做”的事情
- 初级开发者试图用 AI 来“学会如何做”
- 二者结果大相径庭
我见过的资深开发者会：
- 快速做出他们心中已有把握的原型
- 让 AI 生成初步实现，然后进行精炼
- 探索已知问题的不同解决方案
- 自动化各种常规编码任务
而初级开发者往往会：
- 接受不正确或已过时的解决方案
- 忽视关键的安全和性能考量
- 调试 AI 生成的代码时感到困难
- 构建出脆弱而自己并不真正理解的系统
70% 问题：AI 的学习曲线悖论
最近我看到一条推文，完美诠释了我在实践中观察到的现象：非专业工程师在使用 AI 进行编码时，会很快实现 70% 的功能，但余下的 30% 却陷入痛苦的“边际收益递减”之中。
作为一个非专业工程师，以下是我对使用AI编程的真实感受： 它能帮你完成70%的工作，但最后30%令人非常沮丧。每前进一步，就会因为新的bug和问题而后退两步。 如果我知道代码是如何运作的，也许我自己就能修复这些问题。但由于我不懂，我开始怀疑自己是否真的学到了什么。
这个“70% 问题”揭示了当前 AI 辅助开发的一个关键点。最初的进展令人惊叹——你描述你想要的功能，工具（如 v0 或 Bolt）就能生成一个看上去相当不错的原型。但接下来，问题就会开始出现。
接下来通常会出现一个很典型的循环：
- 你想修复一个小 Bug
- AI 给出一个看似合理的修改建议
- 结果这个修改又引发了其他问题
- 你再让 AI 修复新问题
- 于是又产生更多问题
- 如此反复循环
对于非专业工程师来说，这种循环尤其痛苦，因为他们缺少必要的心智模型来理解到底哪里出了问题。当一名有经验的开发者遇到 Bug 时，他们会基于自己多年的模式识别来推测可能的原因和解决方案。但如果你没有这种背景，那就只能像打地鼠一样，不停敲击那些自己并不了解的“冒出来的错误”。
持续的学习悖论
更深层的麻烦在于：AI 工具能为你“代劳”很多复杂的事情，这恰恰使得非专业工程师更难真正学到软件开发的本质。当代码在你眼前“凭空出现”，而你并不理解它背后的原理时：
- 你不会培养调试技能
- 你会错过学习基本模式的机会
- 你无法对架构决策进行推理
- 你也难以维护和升级这些代码
这就造成了一种依赖——你只能不断求助于 AI 来修复问题，而不是掌握亲自解决它们的能力。
知识鸿沟
我见到最成功的非专业工程师，会采用一种“混合式”的方法：
- 用 AI 进行快速原型
- 花时间去理解生成代码的工作原理
- 在使用 AI 的同时学习基本的编程概念
- 一步步打好知识基础
- 把 AI 视为学习工具，而不仅仅是“代码生成器”
但这需要耐心和投入——而这恰恰与很多人使用 AI 工具时所期待的“省时省力”背道而驰。
对未来的启示
这个“70% 问题”说明，当前的 AI 编码工具更适合被视为：
- 对资深开发者而言，用来加速原型的工具
- 对想认真学习开发的人而言，用来辅助学习的工具
- 用于快速验证想法的 MVP 生成器
但它们还远不能成为“所有人都能轻松做出成熟软件”的神奇方案。最后那“至关重要的 30%”——让软件真正具备生产力、可维护性、健壮性——依然需要真正的工程知识。
好消息是：随着工具的进步，这个差距有望逐步缩小。但在当下，最务实的做法还是把 AI 当作加速学习的手段，而不是用来完全替代你对软件开发本质的理解。
实际可行的做法：一些成功的模式
在观察了数十个团队之后，我发现以下做法行之有效：
- “AI 初稿”模式
- 让 AI 生成一个基础实现
- 由人工对代码进行模块化审查和重构
- 加入完备的错误处理
- 编写充分的测试
- 补充并记录关键的技术决策
- “持续对话”模式
- 针对每个独立任务都开启一个新的 AI 对话
- 保持上下文精简、集中
- 频繁地审查和提交变更
- 建立紧凑的反馈循环
- “信任但要验证”模式
- 用 AI 做初始代码生成
- 对关键路径进行人工审查
- 编写自动化测试，以覆盖各种边界情况
- 定期进行安全审计
展望未来：AI 的真正潜力是什么？
尽管面临这些挑战，我对 AI 在软件开发中的作用依然保持乐观。关键在于我们要明白 AI 真正擅长什么：
1. 加速我们已经知道的东西
AI 在帮助我们实现已知的模式时非常出色，就像拥有一个永不疲倦、打字飞快的结对程序员。
2. 探索新的可能性
AI 让我们可以快速构建原型并探索不同思路，就像在一个实验沙盒里可以极速测试各种概念。
3. 自动化常规任务
AI 大幅减少我们在样板代码和常规任务上花费的时间，让我们可以更专注于那些真正有意思的问题。
这对你意味着什么？
如果你正准备开始使用 AI 辅助开发，我的建议是：
- 从小处着手
- 让 AI 先处理独立且定义清晰的小任务
- 审查 AI 生成的每一行代码
- 再逐步扩展到更大规模的功能
- 保持模块化
- 把所有东西拆分成小而专注的文件
- 为各组件设定清晰的接口
- 在模块边界处做好文档
- 相信你的经验
- 用 AI 来加速，而不是替代你的判断
- 对那些“感觉不对劲”的生成代码保持质疑
- 坚守你的工程规范与标准