用 AI Native 的方式开发 AI Native 的产品

最近工作中，有一个对比特别强烈：

一方面，我带着一个很小的团队，在用 AI Native 的方式，开发一个 AI Native 的 Agent 产品，感觉效率非常高，整个过程也给人巨大的成就感，有时候甚至会沉浸其中忘了时间。

另一方面，上周给研发团队做 AI 提效的分享交流时，我发现，在我们开发并维护了十多年的这个体量巨大的项目中，AI 提效的效果并不理想，最多也就是起到了更好的代码补全作用，或者帮忙完成一些非常小的工具函数。

这种强烈的对比让我一直在思考：如何在不同场景下更好地发挥 AI 的作用？而周末参加一次交流活动，听了唐春林同学的分享后，很有启发。

结合自己最近的思考和实践，我想把关于 Vibe Coding 的一些想法整理出来，与大家分享。

PART01

Vibe Coding 的核心是什么？

我的核心观点是：Vibe Coding 的核心是重构整个软件开发生命周期的全流程。

很多人对 Vibe Coding 的理解停留在“用 AI 写代码”这个层面，认为只要在 IDE 里装个 Copilot、用上 Claude Code 或者 Cursor，就算是在做 Vibe Coding 了。这种理解过于狭隘。

真正的 Vibe Coding，不仅仅是在编码环节引入 AI，而是要从需求分析、架构设计、代码实现、测试验证到运维监控，整个软件开发生命周期都要为 AI 协作而重新设计。换句话说，不是把 AI 当作一个更高效的“打字员”，而是把 AI 视作一个非常优秀、非常勤奋的团队成员，围绕如何让这个成员发挥最大价值来重构整个工作流程。

PART02

三类开发任务的不同策略

结合我自己的实践以及春林的分享，我觉得不同类型的开发任务可以采用不同的 AI 协作策略。

第一类：小型 Demo 的开发

对于小型 Demo 的开发，核心是速度。

用 Lovable 或者 Google AI Studio 这类工具，能够在极短的时间内完成一个可以点击、有基本交互逻辑的 Demo。我自己也经常用这种方式快速验证一些产品想法，有时候一个小时就能做出一个可交互的原型。

但是，需要警惕这种速度带来的“虚荣感”。能快速开发出一个 Demo，和真正解决用户问题之间，还有很大的距离。Demo 可能看起来很炫酷，但离真正要上线运营还有巨大的差距。

在这类任务中，人类与 AI 的协作分工应该是：AI 核心负责调研、开发和表达，人类核心负责决策和选择。两者一起快速尝试、快速犯错、快速迭代。

不管 AI 的能力多强，人类的“审美”依然是必不可少的。这里说的审美，不仅仅是视觉层面的美丑判断，更是一种对“好”的感知能力：什么样的商业模式是能赚钱的，什么样的交互体验是流畅的，什么样的产品逻辑是自洽的，什么样的技术方案是优雅的。这种审美背后，是多年积累的行业认知、用户洞察和技术判断力。AI 可以快速生成十个方案，但选出那个“对”的方案，依然需要人来做。

第二类：存量成熟项目的维护

这是我在实践中发现的 AI 提效最难的场景。

我们的主产品有十多年的积累，几百万行代码。在这种规模的项目上，AI 能发挥的作用确实比较有限。原因也很简单：大部分成熟项目都缺乏基本的文档，代码的上下文分散在不同的模块、不同的历史版本中，AI 很难理解全局，自然也就很难在有一定上下文跨度的开发上有太大的效率提升。

对于这类项目，我建议换个思路：从直接提高代码产出效率，转向提高整个项目的可维护性。具体可以从以下几个方向入手：

• 局部改造与文档化：让 AI 帮忙补充和更新技术文档，推导并可视化系统架构，排查静态代码隐患。这些工作本身不直接产出新功能，但能够为后续的开发打好基础，也是过去人类程序员抵触做的。
• Code Review 辅助：让 AI 对 PR 做基础评估，标记异常的开发模式和潜在风险，人类 Reviewer 则聚焦在架构决策与业务逻辑层面。这种分工能够显著提升 Code Review 的效率和质量。
• 周边系统的开发：让 AI 在已有代码外围，负责一些相对独立的系统和模块的开发，比如日志分析系统、监控告警系统、运维工具等。这些系统既能间接提升已有代码的质量，又因为相对独立，AI 能够发挥更大的价值。

第三类：AI Native 项目的开发

这是我最近投入精力最多的领域，也是 Vibe Coding 能够发挥最大价值的场景。

对于 AI Native 的项目，核心思路是：把 AI 视作一个非常优秀、非常勤奋的员工，基于这个假设，我们就有必要重构整个软件开发流程，让它对 AI 友好。

具体来说，有以下几个要点：

软件工程的基本流程依然要遵守

Vibe Coding 不是放弃软件工程，而是在 AI 协作的背景下重新诠释软件工程。需求评审、技术方案设计、代码审查、测试验证、上线发布，这些基本流程依然不能省略。很多人觉得有了 AI 写代码很快，就可以跳过设计直接开干，结果往往是返工更多、效率更低。AI 提升的是每个环节的执行效率，但不能替代环节本身的必要性。

文档驱动开发

在传统的开发模式中，文档往往是事后补充的，甚至经常被省略。但在 AI Native 的开发中，文档变成了核心资产。

我们的实践是：在开始写代码之前，按照完整的流程准备好各类文档。从商业模式设计开始，明确要解决什么问题、为谁创造价值；然后是 Use Case 文档，梳理用户的核心使用场景；接着是产品设计文档，定义产品的整体形态和交互逻辑；再到产品规格需求说明书，细化每个功能点的具体要求；最后是技术设计文档，确定技术方案和实现路径。这些文档不仅是给人看的，也是给 AI 看的。AI 基于这些文档理解需求背景和技术约束，才能生成高质量的代码。

同时，每个代码模块都要有清晰的 README，说明模块的职责、对外接口、依赖关系。这些信息让 AI 在做跨模块修改时，能够更好地理解上下文。

Markdown 是我们选择的一种对 AI 和对人类都非常友好的文档格式，也在我们的项目中广泛使用。

采用增量开发

AI 目前的能力，更擅长完成边界清晰、范围可控的任务。所以在开发过程中，应该尽可能把大任务拆解成小任务，每次只让 AI 完成一小块功能，验证通过后再继续下一步。

这种增量开发的方式，一方面能够及时发现和纠正 AI 的错误，另一方面也更符合 AI 的能力特点，能够让 AI 在每个小任务上都表现得足够好。

技术选型也要 AI 友好

在技术选型时，需要考虑 AI 对这些技术的理解程度。一般来说，越主流、文档越丰富、社区越活跃的技术，AI 的理解就越好。

举个例子，如果在 Python 和某个小众语言之间选择，优先选 Python；如果在 React 和某个新兴框架之间选择，优先选 React。这不是说新技术不好，而是在 AI 协作的场景下，AI 对主流技术的理解更深，能够给出更好的建议和代码。

PART03

一些实践中的感悟

在最近几个月的实践中，我还有一些其他的感悟，一并分享给大家。

人机协作的节奏很重要

和 AI 协作，不是把需求扔给 AI 就完事了。好的协作需要找到合适的节奏：什么时候应该让 AI 先探索，什么时候应该人类来决策，什么时候需要人机一起讨论。

我自己的经验是，在方向不明确的时候，让 AI 先做调研，给出几个方案供选择；在方向明确之后，给 AI 清晰的指令，让它高效执行；在遇到复杂问题的时候，和 AI 一起讨论，利用它的知识储备来补充自己的思考盲区。

接受 AI 的局限性

AI 不是万能的。它有时候会犯一些低级错误，有时候会生成看起来正确但实际有问题的代码，有时候会对复杂业务逻辑理解不到位。

接受这些局限性，建立合理的预期，反而能够更好地与 AI 协作。不要期待 AI 每次都给出完美的答案，而是把 AI 当作一个能力很强但偶尔会犯错的同事，做好验证和纠错的准备。

持续投资于 AI 友好的基础设施

要让 AI 持续发挥价值，需要在 AI 友好的基础设施上持续投资。这包括：

• 保持文档的更新和完整；
• 建立清晰的代码规范和项目结构；
• 完善自动化测试，让 AI 的改动能够被快速验证；
• 构建好的 CLAUDE.md 或类似的 AI 上下文文件。

这些投资短期看可能不产生直接价值，但长期来看，它们是 AI 能够持续高效协作的基础。

苏格拉底式的提问而不是指令式的命令

这个观点也是来自于春林的总结。

在与 AI 的协作中，采用苏格拉底式的提问方式，往往比指令式的命令效果更好。

举个例子，与其说“给我写一个用户登录功能”，不如问“实现用户登录功能有哪些常见的方案？各自的优缺点是什么？考虑到我们的场景，你推荐哪种方案？”前者只能得到一个固定的答案，后者则能触发 AI 主动进行深度思考，把它的知识储备充分调动起来。

这种提问方式还有一个好处：AI 在回答过程中可能会提出一些你没想到的角度和风险点，帮助你完善自己的思考。某种意义上，这不只是在用 AI 写代码，而是在用 AI 做技术咨询。

PART04

写在最后

回到开头提到的那个对比：为什么在 AI Native 项目中 AI 提效明显，而在存量项目中效果不佳？

本质上，这不是 AI 能力的问题，而是开发流程与 AI 协作方式匹配度的问题。存量项目的开发流程是为人类设计的，自然对 AI 不友好；而 AI Native 项目从一开始就考虑了 AI 协作，自然能够发挥 AI 的最大价值。

所以，Vibe Coding 的核心不在于用了什么 AI 工具，而在于是否愿意为 AI 协作而重构开发流程。这需要思维方式的转变，也需要在实践中不断摸索和优化。

对于想要尝试 Vibe Coding 的朋友，我的建议是：从一个新项目开始，不要在存量项目上硬推。在新项目中建立 AI 友好的开发规范和流程，积累经验之后，再逐步将好的实践推广到其他项目中。

以上是我个人的一些思考和实践总结，一家之言，仅供参考。欢迎大家扫码进群交流讨论。