二八规则，也适用于 AI 编程了。
所有变因中，最重要的仅有 20%，虽然剩余的 80% 占了多数
最近，几乎每天在 Product Hunt （国外新品发布网站）上都会蹦出个 AI 快速构建应用的工具。我已经花了几十刀在 AI 编程工具 Cursor 上了，于是立马去最有名的 Bolt.new 试了一下，由于缺少耐心，指令相对敷衍，让 Bolt 给我写个笔记软件，结果，只生成了一个空白页面……
虽然我想说，如果希望 AI 生成一个立马可用的东西，大概率和中奖很类似，指令越明确，中奖概率越高，但这不是基于 Bolt 的例子，而是基于每天高频率地用 AI 润色文本、维护网站、修改浏览器插件、创建自动化脚本，以及我真的在写一个笔记工具的玩具……得来的偏见。
我们看到的大部分 AI 是以对话形式存在的，这是因为，聊天形式的使用下限极低，会说话打字就行，几乎每个人都可用，这也是最其有意义的地方。
我们通过模糊的自然语言指令与 AI 对话，来完成应用的构建，甚至像很多夸大的数据那样，可以完成 80%（我觉得几乎不太可能），成功消除了能与不能的边界，还缩短了时间，从一定程度上，这也就是，我觉得我行了，但这只是完成了毛坯房，真正的挑战在于如何将粗糙的 “毛坯房” 打磨成精细的 “产品”，这 20% 的工作，考验的是所有工具的精细化修改能力以及发送指令的人对实现机制的持续理解。
此外，这种复杂度是不可避免的，可能源于产品需求本身，或是在项目迭代过程中逐渐显现，例如增加新功能或维护代码。在这种复杂度的背景下，80% 的完成度显得更加不重要。
回到关键性的本质，从纯代码编程到 AI 编程，到底发生了什么变化？
在 AI 编程以前，所有的精细化编辑是代码形式完成的，现在只是换了方式，基于鼠标（或手指）操作和自然语言指令，但所需要的条件是相通的，既要工具从交互上实现等同于代码的指哪打哪，也需要发送指令的人基于对项目的认知，输出合理且精准的自然语言需求。而之前一切以代码为中心的构建产品的设计，也需要改为以 AI 为中心的构建产品的设计，重新思考。
这里面会有很多有趣的点，甚至机会。
精准的视觉化操作
最近，我尝试用 Cursor 调整博客的 CSS 布局，结果发现自己像个拿着设计图却语言不通的业主。我明明能看到 AI 生成的网页效果，却不知道该怎么告诉它：“把左边栏变窄些，但别挤到头像。”
要实现精细化编辑，就得跳出对话框，用更直观的视觉操作来完成大部分调整。目前在 Cursor 里，如果想让 AI 移动多个元素，首先遇到的问题就是：我该怎么称呼它们？现在的办法是，先让 AI 告诉我这些元素的名字，建立一个对应关系，再描述我的诉求。这还不算完，语言、习俗、甚至行话的差异，都可能导致沟通障碍。少了这个"起名字"的步骤，AI 很容易改错地方。
当然，也可以截图沟通。但这就像两个语言不通的人，需要借助 AI 助手来翻译一样。看着挺美，实际用起来却很不顺畅。我们真正需要的，是去掉中间环节，直接在最终效果上标记和批注，实现"所见即所得"的修改。
最近，Lovable 和 Bolt 等 AI 构建应用工具，都在尝试将代码编辑可视化，就像 Figma 那样，直接编辑选中的元素。不过，如何把选择和指令精准地关联起来，还需要更多的设计探索，比如，如何像在 Figma 里那样完成设计稿的创建和修订。
多模态沟通：让一切素材成为 AI 的指令
最近遇到一个重要挑战：如何让 AI 准确理解 Figma 设计稿并完成基础构建？关于这个问题，目前存在三种探索方向：
第一种思路是直接从设计稿生成代码，虽然已有不少工具尝试，但普遍只能实现约 80% 的完成度。第二种思路主张将设计稿转换为自然语言指令，虽然测试案例尚不充足，但潜力值得期待。第三种思路则寄希望于未来 AI 能原生理解设计稿文件格式。
我倾向于第二种方案，因为它能更好地融入现有 AI 工具的工作流——既可利用对话上下文，也能结合具体指令进行开发，后续还能通过可视化操作进行精细调整。值得注意的是，这种思路还能扩展到 PRD 文档、交互说明、参考网站、视频动效等辅助材料，不过每个类型的素材都需要专门的解析适配。
另外，在 Cursor 等现有工具中，很多对话的操作也缺少自然语言对话的直观性。例如执行"请将这个图片插入文章末尾"这类简单指令时，用户仍需手动将文件放入代码仓库指定位置，再通过路径指引 AI 定位。这种操作断层，也还需要很长一段路来演进。
自然语言的双向生成
回归本质，编程代码并不是机器可以直接理解的语言，它需要通过编译器或解释器进行转换。如果使用 AI 编程的人主要依赖自然语言进行操作，那么占据 70% 显示空间的代码文件就不再需要像以前那样展示，而是可以用自然语言来呈现一切。这种方式将使得 AI 执行的工作更具备被评审的可能性，比如代码变更、日志记录、Diff 比较等。
在代码评审场景下，用自然语言描述代码变更，让非技术人员也能参与评审。在错误日志分析场景下，用自然语言呈现错误信息，让普通人也可以看懂。最近的 Chrome 也推出了这个功能，基于控制台的日志来用自然语言解释发生的事情。
原来的流程是：编程语言 → 机器语言
现在的流程是：自然语言 → 编程语言 → 机器语言
未来的流程则可能是：自然语言 ←→ 编程语言 → 机器语言
健壮的精细化修改
代码的编写过程更像是撰写一本书，由于 AI 上下文的限制，需要拆分成小模块来逐章完成，而不是一蹴而就。与书籍不同的是，代码中的许多逻辑是相互耦合，互相影响的，每一次的修改都可能引发连锁反应，引入预料之外的 Bug。
AI 的黑盒生成机制也使得代码的修改充满了不确定性，常常出现"改完西边，改东边"的情况。最近我在 YouTube 上看到一位博主分享了基于 PDCA（计划-执行-检查-行动）概念的测试方法，这让我对自动化测试的重要性有了更深刻的理解。
为了确保代码的健康持续发展，我们需要更多的自动化测试来覆盖之前实现的功能。这样，每一步的改动都能更加稳健，降低潜在的风险，确保系统的整体稳定性。
如"自然语言的双向生成"提到的，在 AI 编程中，自动化测试的编写、执行、检查和输出也应与传统方法有所不同，以自然语言的方式呈现这一切，确保每个环节都能被清晰理解和有效执行。
不过，我现在还没有解决的另一个问题是，如何让 AI 进行有效自检，并自我修正，我觉得它们总是表演"正确"，很无奈。
缺少持续的新手导航
目前，与 AI 的协作可以比作 L3 级别的自动驾驶，意味着我们仍需保持一定的控制和干预
就如最开始的 20% 中提到，AI 的执行离不开人的指令。然而，随着代码的不断堆砌，如果用户对其中的机制理解停滞不前，他们可能会不知道如何进行正确的迭代。就像公司的 CEO，虽然可以不关心代码的实现，但需要对产品的机制有清晰的了解，以便做出明智的迭代策略。
这也就赋予了 AI 引导用户的责任，AI 不仅要完成代码的修改，还要帮助用户持续保持对项目实现的控制。
不过，AI 在打破知识壁垒方面已经很出色。现在，除了减少编程语法学习的负担，它还应在日常任务的每一个阶段中分散引导，逐步帮助用户加深对整个项目的理解，这一切都基于对用户编程水平的判断。就像开车时的导航系统，当新手司机刚考完驾照上路时，导航会提供更为细致和琐碎的提示；一旦熟悉了，就可以切换为普通模式，甚至极简模式。
现在，在每次代码修改时，我会先让 AI 审核我的方案，并基于当前的代码实现解释即将进行的修改，方便我的理解。完成后，AI 还会输出修改清单，告知相关的变更。此外，项目的初始以及后续大的变动，我也会手动更新 README 文件。README 文件不仅是代码仓库的说明书，也是代码的地图导航之一，但这个过程不应完全依赖用户手动进行。
与 AI 的人机协作：一个持续探索的旅程
不过，尽管现在有这样那样的不足，我仍然感激 AI 带来的变革，它使得像我这样没有编程基础的普通人也能参与到编程的世界中，在 AI 完全接手之前，我先拿它当一个会犯错的 AI 助手，而不是不切实际的奢望。
现在，我已经能泰然自若地面对每天向我道歉几十次的 AI 了，让我们调整策略重新再来，妈的。
另外，这篇文章是先在 Obsidian 里写完的初稿，然后直接在 Cursor 里打开，让 AI 评审给出修改建议，然后我再根据建议进行修改，最后在 Cursor 里打磨成最终的版本，强烈推荐这个搭配。详见《最好的本地 AI 笔记软件：Obsidian + Cursor》 。
