一次 AI-Native 研发的尝试：快速但稳定地从想法走到产品

我一直在探索一件事：怎么快速的同时更稳定地把脑海里的想法变成一个真正上线的产品。

现在，做出一个能运行的产品已经比以前容易很多。Lovable、Replit 这类 Vibe Coding 产品，可以让不熟悉工程的人通过对话生成并发布应用；Claude Code、Codex 这类 Coding Agent，则给了开发者更大的自由度，可以直接进入代码库完成复杂任务。

但我想解决的问题不只是「快」。

我希望从一个还很模糊的想法开始，和 AI 一起想清楚它解决什么问题、第一版应该验证什么、用户怎样使用它、代码为什么这样组织，最后把它真正上线。更重要的是，做出来的东西需要稳定地接近我的预期。这里的「稳定」不是每次得到一样的答案，而是产品不会随着对话变长、阶段推进和代码增多，慢慢变成一个我不理解、也不想要的东西。

过去几次产品实践里，我一直没有找到完全适合自己的协作方式。于是我做了一次新的尝试：把自己从想法到产品的思考过程，写成一套可以被 Coding Agent 调用的 AI Engineering Skills，再用它完成一次完整的产品研发。

这篇文章想分享的不是怎样写 Skills，而是我目前怎样理解 AI-Native 研发，以及我具体设计了怎样的人机协作过程。

现在的工具，和我的需求还有一点距离

不同 AI 开发工具解决的问题并不一样。

Lovable、Replit 更适合希望快速得到应用的非技术用户。它们把产品生成、基础设施和发布整合在一起，大幅降低了做软件的门槛。Claude Code、Codex 面向开发者，允许人直接接触代码、工具和环境，能处理更开放也更复杂的任务。

我的需求刚好落在两者之间：我既希望 AI 深度参与产品定义和体验设计，又希望自己始终理解并控制工程实现。

在过去的尝试中，我经常遇到这些情况：

• 早期很快得到一份 BRD 或 PRD，但用户、场景和问题仍然很宽泛。
• MVP 看起来功能齐全，却没有说清楚第一版究竟要验证什么。
• 页面能用，架构也能跑，但交互、视觉和技术选择并不符合我的偏好。
• 迭代到后面，前面已经确认的判断逐渐丢失，Agent 开始根据眼前的代码局部修改。
• 代码生成得很快，但我没有建立对领域边界、调用关系和数据流的完整理解，遇到问题时仍然需要让 AI 在代码里猜。

这些工具并没有做错什么。它们只是提供了更通用的交互方式，而我想要的是一套带有个人判断的研发过程：知道什么时候应该发散，什么时候必须收敛；哪些问题可以交给 AI 研究，哪些决定需要我确认；一个产品判断怎样一直传递到 UX、架构和代码里。

我目前设计的研发过程

我把一次从零到一的产品创建，拆成了几个相互关联的部分：

模糊想法
  → BRD
  → MVP PRD
  → Domain Model ↔ UX
  → Architecture
  → Implementation
  → 上线后的验证

这看起来很像传统的产品研发流程，但实际执行方式并不是逐项填写文档，再把文档交给下一个角色。

这些阶段是几组相互关联的决策。每个阶段只处理当下真正影响产品的问题，确认的结论会保存在同一份产品 Context 中，成为后续阶段的输入。如果 UX 或实现暴露了新的矛盾，也可以重新打开前面的决定。没有相关问题时，一个阶段可以很轻，甚至不需要单独展开。

整套设计还有一个贯穿始终的限制：只为最小但有用的第一版做决定，不为想象中的规模、复用和未来产品线提前设计。

下面是我对几个阶段的具体设计。

BRD：先确认到底在解决什么问题

一个想法刚出现时，脑海里经常已经带着某种方案。比如「做一个能搜索市场需求的产品」，听起来已经很具体，但这里的搜索只是功能，并没有说明谁为什么需要它。

所以我把 BRD 压缩成四个问题：

1. 用户是谁？产品具体服务哪些人或组织？
2. 用户在什么场景下遇到什么困难？
3. 产品提供什么价值，它与已有选择有什么不同？
4. 第一批用户从哪里来，预期的获取成本大致是高、中还是低？

问题很普通，我真正花时间设计的是它们怎样被回答。

AI 首先从我的原始表达里提取已经明确的部分，只追问那些会影响当前判断的信息。用户和痛点还不具体时，不急着讨论产品功能和差异化。

前两个问题明确后，AI 再围绕这群用户和这个痛点做市场研究：现在有哪些直接或间接的解决方式，它们分别服务谁、提供什么价值，用户认可什么、抱怨什么，还有哪些需求没有被满足。

这里我刻意限制 AI 只呈现市场证据，不替我排列方向，也不直接给出「你应该做什么」。差异化仍然需要我结合自己的经验、兴趣和能力来选择。AI 可以帮助我看得更全，但不能代替我决定想做一个什么产品。

最后得到的 BRD 也不会很长。它只记录这四个问题当前的答案，以及哪些判断仍然是假设。它的用途不是证明项目值得立项，而是让后面的每个决定都能回到同一个起点。

MVP PRD：找到第一版真正要验证的东西

问题明确之后，AI 很擅长继续展开功能。搜索、推荐、账户、历史记录、自动生成、分享，通常很快就能得到一份看起来完整的列表。

但对我来说，MVP 最难的部分恰好是停止展开。

所以进入 MVP PRD 时，我不让 AI 直接生成文档，而是先回答另外四个问题：

1. 这个产品有哪些特有的概念、模型和术语？
2. MVP 明确实现哪些功能？
3. MVP 明确不实现哪些功能？
4. 上线后最少收集什么数据，才能验证产品的核心价值和获客假设？

只要核心答案仍然模糊，AI 就不能自行补完一份 PRD。尤其是第二和第三个问题，需要我明确做出取舍。

范围确认后，每个纳入 MVP 的功能才会被继续展开：谁在什么情况下触发它，主流程是什么，用户最终能看到什么，等待、失败和边界状态怎样处理。这些描述需要足够支持后续设计和实现，但不会提前混入 API、数据库和框架选择。

验证也不是在文档最后放几个 PV、UV。每一个信号都需要对应一个假设，写清楚可以观察的行为、数据从哪里来、观察多久，以及看到什么结果时应该怎样理解。这样上线才不是流程的终点，而是开始获得证据的时刻。

从产品定义一直走到体验和代码

BRD 和 MVP PRD 之后，我还加入了 Domain Model、UX 和 Architecture。它们不是为了把文档做得更全，而是为了减少产品定义进入实现后发生的损耗。

Domain Model：先统一产品里的语言

Domain Model 在这里不是数据库表设计，而是产品的共同语义。

它只描述那些真正影响产品行为的概念、关系、状态和约束。例如，什么是一份报告，报告和产品是什么关系，哪些内容是事实，哪些内容是推导出来的结论，什么状态可以改变，什么规则必须一直成立。

这一层让我和 AI 在讨论前端、后端和算法时使用同一套语言。如果一个概念在产品行为里还没有被想清楚，就不会直接用一张表或一个字段把模糊掩盖过去。

UX：把价值获取过程具体画出来

UX 阶段主要围绕四个问题展开：

1. 用户从哪里进入，他此刻想完成什么？
2. 从入口到真正获得价值，最清楚、最短的路径是什么？
3. 每个关键时刻，用户需要看到、理解、决定或操作什么？
4. 当路径被打断时，等待、空白、错误、拒绝和恢复应该怎样表现？

UX 只能在已经确认的 MVP 范围里工作。如果设计过程中突然需要一个新功能，就要先回到产品层判断它是否真的属于 MVP，而不是悄悄把范围扩进去。

我会在这个阶段具体参与页面层级、信息密度、交互状态和视觉方向的选择。AI 可以生成大量方案，但我需要持续说明自己喜欢什么、为什么喜欢，以及这个选择是否服务于产品的核心价值。

Architecture：只记录会影响产品的技术决定

我以前让 Agent 做架构设计时，很容易得到一份面面俱到的方案：完整目录、服务拆分、通信方式、部署组件和未来扩展都被提前写好。

现在我只让它关注那些会直接改变 MVP 体验或交付风险的问题，例如响应时间、结果质量、失败恢复、数据一致性、隐私、第三方服务、运行成本，以及某项能力是否真的需要成为独立进程。

普通的 Web 到 API 再到数据库的请求不需要写进架构文档。一个能力默认留在 API 内部，除非它确实需要独立启动、停止、部署或运行。架构设计的目标不是显得完整，而是让少数真正重要的技术选择有清楚的产品原因。

数据库也遵循类似原则：从已确认的产品行为和领域规则出发，只保留请求结束或应用重启后仍然必须存在的事实。没有明确需求时，不提前添加通用元数据、历史记录、软删除、扩展结构和索引。

一次实际的人机协作是什么样的

实际使用时，这套过程不是 Agent 独自从头跑到尾。

我先说出一个可能很模糊的想法。AI 从里面找出已经成立的判断，以及当前缺少哪些会改变方向的信息。我补充自己的经历和偏好，需要外部证据的部分由 AI 继续研究。

BRD 对齐后，结论会被保存下来。进入 MVP 阶段，AI 可以帮助我展开可能的产品形态，但我需要明确决定哪些功能进入第一版、哪些不做，以及上线后用什么判断它是否有价值。

接下来，Domain Model、UX 和 Architecture 都会读取之前确认的内容。发现冲突时，AI 需要把冲突暴露出来，我们再回到相应的产品问题，而不是让它默默选择一个能继续编码的答案。

因此到了实现阶段，Agent 面对的不再是一句「帮我做一个某某产品」，而是一组彼此关联的判断。前端页面知道自己服务哪条用户路径，后端契约来自明确的领域概念，算法能力也有具体的产品质量要求。上线之后，再回到 MVP PRD 中预先写下的信号解释结果。

整个过程中我仍然要频繁介入。变化在于，我不再把大部分时间花在追着 AI 修改局部实现，而是更多地参与那些会决定产品走向的问题。等进入编码时，很多返工已经在产品讨论里被提前消化了。

这只是我目前的一次尝试，做到现在我对AI-Native研发更加困惑

这套设计离答案还很远。

它可能在某些产品上太重，也可能因为约束太多，压掉 Agent 本来有价值的发散。BRD、MVP、UX 和架构之间应该怎样连接，不同阶段应该保留多少 Human in the Loop，我现在都没有确定答案。Skills 只是我目前承载这次实验的技术形式，也会随着下一次实践继续变化。

更让我困惑的是，AI-Native 研发显然不应该只解决「一个人怎样更高效地做产品」。

我看到很多公司的做法，是用 AI 把原来的「业务需求 / 用户反馈 → 产品运营 → 研发 → 测试」串起来。每个环节都有 Agent 帮忙总结、生成和执行，但每个环节通常仍然需要一位负责人接住结果，再把它传给下一个人。工具变快了，人类组织里最慢的部分之一——信息在角色和部门之间的传递——却还留在原处。

这让我想到工厂电气化早期的一段历史。19 世纪的工厂通常由一台蒸汽机或水轮机提供集中动力，再通过贯穿厂房的传动轴、皮带和滑轮驱动机器。最初引入电力时，一些工厂只是用电动机替换原来的动力机，内部的传动方式基本没有变化。能源变了，原系统里的摩擦损耗、布局限制和联动停机仍然存在。

后来真正释放电力价值的，是 group drive 和 unit drive：先让一组机器由一台电机驱动，再逐步让单台机器拥有独立动力。机器不必继续围绕传动轴排列，可以按生产过程重新组织；局部设备也可以独立启停。电力带来的收益因此不只来自电动机本身，还来自厂房布局、工作流和生产组织的变化。经济史研究也把工厂电气化与资本深化、组织变化和长期生产率提升联系在一起（NBER, 2024 revision；Paul David, 1990）。

这个类比让我怀疑：如果 AI 只是替换每个旧环节里的执行者，再沿着原来的组织结构传递信息，我们可能还停留在「用电动机带动旧传动轴」的阶段。未来的 AI-Native 研发，也许需要重新设计的不只是每个岗位怎样使用 AI，而是需求、证据、决策和实现之间为什么还要沿着今天的路径流动。

坦率地说，这也是我有些沮丧的地方。我这次的实践，让一个人从想法走到产品时可以更高效，也能保留相对稳定的质量；但它依赖我持续参与关键判断，经不起团队规模和产品复杂度继续扩张。它证明了一种个人协作方式，却没有回答新的研发组织应该长什么样。

我现在只能先把这个问题留下来。下一篇文章，我会具体写第一次用这套方式完成的产品 Product Radar：它怎样从一个模糊想法经历两次收敛，并在五个晚上10个小时左右走到上线。