三个 AI Demo 之后，我对小型原型的理解

为什么我开始做这三个 Demo

最开始做这三个 Demo，是想验证一个具体问题：AI 能不能在某些特定场景下，把模糊输入变成结构化输出。

三个 Demo 分别是：

它们都很小，功能都很单一，但每个都在试图回答一个具体问题。

这个 Demo 验证的是：当需求方只说一句”我想要一个管理系统”时，AI 能不能自动拆解出需要澄清的问题。

结果是：可以，但有限。AI 能识别出”系统”这个词太模糊，能生成”你指的是什么类型的系统”这类澄清问题，但它无法判断这个需求背后的业务优先级。边界识别能力还不够。

这个 Demo 验证的是：从客户沟通记录中，AI 能不能提取出 PO 号、交期、标签这些业务要素。

结果是：要素提取本身不难，难的是判断哪些信息缺失了、哪些信息可能有风险。AI 可以列出”这里没有提到交期”，但它无法判断这个缺失是否致命。

这个 Demo 验证的是：在中文高压社交场景中，AI 能不能生成既有分寸又有态度的回应。

结果是：可以生成多种风格的回复，但”分寸感”这件事很难量化。有时候生成的回复太礼貌，显得没态度；有时候太直接，显得冒犯。边界控制还在摸索中。

做完这三个 Demo，我对”原型”的看法有了一些变化。

以前会觉得 Demo 太粗糙，拿不出手。但做完之后发现，如果一个 Demo 能回答”这个方向值不值得继续做”，它就完成了自己的使命，不需要更多。

三个 Demo 的功能都很单一，但正因为边界清楚，每个都能给出明确的结论——可以做，但有哪些限制。相反，有时候我试图做一个”更完整”的 Demo，加了几个功能，反而说不清楚在验证什么。

有一个判断我现在会做：一个 AI Demo，至少要能说清楚输入是什么、输出是什么、失败时给什么提示，以及有没有接入真实模型。如果这几件事说不清楚，它更可能只是一个 UI 原型，而不是一个有验证价值的东西。

我在做这三个 Demo 的过程中，发现几个常见错误：

把 Mock 当成真实能力。 一开始我用 Mock 数据测试，结果看起来很好。但接入真实 API 后，发现返回的数据结构和预期不一样，很多逻辑要重写。

功能边界模糊。 有一次我让 Agent 实现”需求澄清”功能，它顺手加了一个”自动生成项目计划”的功能。功能看起来多了，但核心问题反而没验证清楚。

没有 fallback。 有一次 AI 模型返回了空结果，页面直接报错，用户看到的是一个白屏。后来我学会了在每一步都加 fallback 提示。

过度包装 UI。 有一段时间我花很多时间调样式，让页面看起来更像”产品”。但后来发现，样式再好看，如果核心功能不扎实，Demo 还是只是一个空壳。

现在评估一个 Demo 是否合格，主要看三件事：边界是否清楚（能不能一句话说清楚它解决什么问题）、失败时是否有提示（用户看到的是什么，而不只是控制台报错）、以及有没有接入真实模型。

Mock 可以用于早期验证，但接入真实 API 之后往往会发现新问题。企业需求澄清 Agent 在接入真实 API 后，我发现底部的示例文案和真实输出格式不一致，需要同步修正——这类问题在 Mock 阶段完全看不出来。

还有一条是部署到线上。本地截图说服力不够，部署好的 Demo 才能被人实际用到，也才能发现真实场景下的问题。

主要是两块：交接文档和验收标准需要更结构化，目前还比较随意，每次下一个 Agent 接手时都要重新理解项目；fallback 策略需要统一，每个 Demo 现在各有一套逻辑，容易遗漏。

记录过程判断这件事，我也想做得更完整——不只记录结果，也记录为什么做这个选择、当时放弃了什么。这篇文章本身算是一次尝试。