AI 应用先要写清楚的,不是代码

一个产品经理用 AI 做出原型，不稀奇。真正稀奇的是，产品团队知道哪些部分可以让模型自由生成，哪些部分必须被固定在护栏里。

配图：AI 应用不是从“让模型写代码”开始，而是从划清探索区和可靠区开始。

AI 让“做出一个东西”变便宜之后，产品经理更重要的工作，是判断什么值得做，以及什么不能交给随机生成。

先问“该不该做”，再问“能不能做”

Product Talk 最近介绍了 Aha! Builder 的产品过程。这个产品面向产品经理，让他们从概念、原型一路走到可运行的应用。

最有价值的部分，不是“几分钟生成一个应用”这句听起来很快的承诺，而是他们没有跳过产品发现。

团队把过程拆成五个阶段：从一个想法开始，做纸面原型，再做概念验证，进入早期体验，最后才是正式发布。

这条路径并不新鲜，却在 AI 时代变得更重要。因为生成原型太容易了，真正稀缺的反而是判断：这个问题是否值得解决？用户是否真的需要？哪些反馈说明方向不对，而不是只需要换一个按钮？

如果一个团队一上来就让 Agent 生成完整产品，速度可能很快，但它也会更快地把未经验证的假设固化成代码。

AI 降低了实现成本，也降低了试错成本。产品流程不能因此消失，反而应该更早出现。

让 AI 探索，让系统负责不出错

Aha! Builder 的另一个启发，是把“可以变化的部分”和“不能随便变化的部分”分开。

界面、布局、原型和某些应用逻辑，可以交给多阶段、多 Agent 的流水线反复探索。模型在这些地方的价值，就是快速生成多个可能性，让产品团队更早看到一个想法在真实交互里是什么样子。

但认证、单点登录、数据库、个人信息处理等部分，不应该每次都让模型自由发挥。它们更适合由确定性的组件、固定的接口和明确的测试来托住。

这不是对模型不信任，而是对不同类型的问题采用不同的工程方法：

• 探索性问题，需要速度、变化和多个方案；
• 可靠性问题，需要边界、约束和可复现的结果；
• 高风险问题，需要明确的责任人和人工确认。

把三类问题都丢给同一个 Agent，表面上流程很统一，实际上责任边界完全消失了。

原型能跑，不代表架构能撑住

这次案例还暴露了一个很现实的产品陷阱：原型阶段能用的基础设施，不一定适合规模化。

Aha! Builder 的第一版采用容器化的 Ruby on Rails 基础设施。它可以帮助团队较快地做出早期版本，但随着使用规模增加，这种方式在资源和运行效率上变得浪费。后来团队改成单实例、多租户的架构，并使用 V8 isolates 来隔离不同应用的运行环境。

这个取舍说明，AI 产品的工程难点不只是生成速度，还包括生成之后如何运行、隔离、升级和复用。

“能不能在几分钟内生成”是演示问题；“生成一万个应用时，成本、数据边界和故障半径是否仍然可控”才是产品问题。

同样的道理也适用于企业内部的 Agent。一个工作流在三个人手里跑通，不等于它已经具备团队级的权限、审计、数据隔离和恢复能力。

产品经理的角色正在往上移动

当产品经理可以直接做出可交互原型，产品和工程之间的交接会变得更短，但不会消失。

产品经理需要更早承担几类判断：

第一，定义问题，而不是只描述功能。 说清楚用户要完成什么任务、当前哪里最痛，而不是先列十个页面。

第二，定义可以接受的结果。 一个 Agent 生成的功能怎样算完成？速度、准确性、可解释性和失败处理，哪些是硬指标？

第三，划出确定性边界。 哪些地方可以让模型试错，哪些地方必须调用固定能力，哪些动作必须由人确认？

第四，准备真实评估。 原型好看不代表可用，演示成功不代表稳定。产品经理要参与建立测试任务、失败样例和验收标准。

这意味着，产品经理不一定要亲自写完所有代码，但必须越来越懂系统如何工作、哪里会失控、怎样证明它没有失控。

给正在做 AI 应用的团队一张小表

开始下一个 AI 项目前，可以先把四列写出来：

1. 允许模型探索什么：界面、文案、原型还是低风险流程；
2. 必须固定什么：认证、数据存储、关键业务规则和外部接口；
3. 用什么证明它可用：真实任务、失败样例、评估集和人工复核；
4. 出问题谁来接手：停止条件、回滚方式和责任人。

这张表比一开始写一份很长的提示词更有用。因为提示词解决的是“模型怎么做”，而边界解决的是“哪些事根本不该让模型自行决定”。

AI 应用的竞争，最终不会只属于能最快生成页面的团队，也会属于最早把产品判断、工程护栏和用户反馈接成闭环的团队。

代码会越来越容易生成，但值得生成什么、什么必须稳定，仍然需要有人说清楚。

参考资料

• Product Talk，《Creating Aha! Builder: Concept to Code, No Engineers Required》：https://www.producttalk.org/creating-aha-builder-concept-to-code-no-engineers-required/^[1]

引用链接