AI很快做出了原型,下一步先别急着开发

文 / 谭良才（Terence）

一个想法很快变成可以点击的页面，确实会让人兴奋。原来需要反复解释的流程，现在可以直接展示；原来停留在脑海里的需求，也有了一个可见的样子。

但原型出现得越快，我越觉得需要保留一个停顿：我们接下来准备验证什么？如果只是继续添加页面、按钮和视觉细节，可能很快就做出了一个完整外观，却仍然不知道它是否解决了真正的问题。

对企业业务系统来说，原型的价值不只是展示能力。它更应该帮助不同岗位把隐含的理解拿出来比较，让模糊的需求变成可以观察、可以提问的事情。开发之前的这一步，值得认真完成。

一、能演示一遍，与能被使用一遍不同

先设想一个假设场景。一家企业准备做内部报修工具，用AI快速生成了一个页面：员工填写问题，主管查看，维修人员接单，最后关闭。演示者按预设顺序点击，每一步都很顺畅。

可当一位真实使用者尝试时，他可能不知道该选择哪个设备，无法判断问题是否紧急，也不知道多个地点出现同类问题时应该提交一次还是多次。页面没有报错，工作却已经停下来了。

这说明，演示通常沿着作者熟悉的路径进行。作者知道按钮是什么意思，知道下一步应该输入什么，也会自然避开尚未考虑的情况。真实使用者没有这些隐藏知识，他面对的是当前任务和界面给出的信息。

因此，我更愿意让原型尽早接受一次无人提示的使用。给对方一个明确任务，让他尝试完成，观察哪里犹豫、哪里误解、哪里需要额外询问。不要急着替界面解释，否则就看不到设计到底缺少什么。

原型发现问题并不是失败。恰恰相反，如果一个便宜、容易修改的版本帮助我们发现了误解，它就已经创造了价值。真正浪费的是把发现问题推迟到开发和上线以后。

二、先写一个需要验证的判断

很多团队说要验证需求，实际上没有说明怎样才算验证。最后收集到的反馈是“挺好的”“可以再加一个功能”，既没有明确支持原方向，也没有揭示哪里需要改变。

可以先把想法写成一个具体判断。在假设的报修场景里，不是验证“大家需不需要一个系统”，而是验证“员工能否在没有现场协助的情况下，把足够的信息交给接单人员”。这个问题可以通过一次任务观察获得线索。

另一个判断可能是，接单人员能否依据提交内容决定下一步。如果每份报修都需要电话补问，问题可能在信息结构，而不是页面不够漂亮。若提交内容已经清楚，却无人处理，则需要看分工和工作机制。

不同判断需要不同原型。验证信息理解，可以用很简单的页面或纸面；验证角色切换，需要模拟前后岗位；验证外部系统条件，则可能需要技术核查。不要为了统一制作形式，把每一个问题都变成完整交互演示。

一次验证也不要承担太多目标。问题越多，观察越容易变得笼统。先弄清最可能影响项目成立的那一个假设，再决定下一步投入，比把所有细节同时展开更有方向。

三、选择会暴露差异的任务，而不是最容易通过的任务

如果只让参与者按说明填入标准答案，原型很容易获得好评。可企业日常工作并不总是资料齐全、角色清楚、情况单一。验证任务需要保留一些真实的复杂度。

例如，可以准备一个信息完整的常规报修，再准备一个设备名称不清楚的情况，一个已经提交但需要补充信息的情况。观察使用者如何理解，也观察接手人是否知道该如何继续。

不必一次穷尽所有异常，但应覆盖那些一旦处理不好就会改变流程的情况。重复提交、取消、转交、退回补充，往往比再增加一个统计页面更值得先验证。它们能帮助我们理解任务的生命周期。

参与者也需要适当差异。熟悉业务的负责人可以检查规则，一线使用者可以暴露实际操作问题，后来接手的人可以检验信息是否足够。只邀请提出需求的人验证，容易把他的理解当成所有人的理解。

如果暂时找不到真实使用者，可以先做内部模拟，但应诚实记录限制。模拟可以发现一部分问题，不能自动替代现场反馈。更不能因为几个同事觉得演示顺畅，就宣称用户已经验证了需求。

四、记录行为，比收集表态更有用

用户说喜欢一个设计，与实际愿意使用它之间，可能存在距离。人们也可能出于礼貌给出正面评价。因此，观察时可以更关注行为：他首先点击哪里，在哪一步返回，输入了什么，是否理解提交后的状态。

把观察与解释分开记录会更清楚。例如，“在设备选择处停留并询问名称”是观察；“用户不熟悉设备分类”是可能的解释。后者需要进一步确认，不能直接当成唯一原因。

反馈也可以围绕具体时刻追问。刚才为什么选择这里？你以为提交后会发生什么？如果现在没有人解释，你会怎样处理？这样的问题更容易接近使用者的理解，而不是让对方替我们设计产品。

当然，用户提出的功能建议也值得听。但建议背后的困难更重要。对方要求增加一个备注框，可能是现有分类无法表达情况；要求增加导出，可能是下游工作尚未被覆盖。先理解任务，再决定是否采用原建议。

验证记录不需要复杂到拖慢工作。能把任务、观察、问题和后续决定连起来即可。关键是保留依据，让团队知道修改是因为发现了什么，而不是因为谁在会议上表达得更有说服力。

五、原型不负责证明生产条件已经具备

一个原型可以模拟登录、审批或数据展示，却不代表真实权限、业务数据和外部连接已经实现。尤其在演示中使用虚构数据时，画面越完整，越容易让人高估系统已经完成的程度。

因此，应清楚标明哪些是可操作的演示，哪些使用模拟数据，哪些只是说明未来行为。不是要给每个按钮加技术注释，而是让评审者能够理解当前能验证什么、还不能验证什么。

在假设报修工具里，原型可以验证员工是否理解信息填写，也可以模拟主管如何查看；但真实通知能否送达、权限是否隔离、故障时数据如何保留，需要后续按具体技术方案验证。

这些问题不应全部推迟到最后。发现某项需求依赖尚未确认的外部条件，就应尽早列出来，决定先核查还是调整范围。否则，原型越做越精致，团队越不愿意承认关键前提仍然缺失。

对经营者来说，重要的是区分两类进展：我们更理解用户了，以及我们更接近可运行系统了。两者都值得投入，但不能用其中一类完成度替代另一类。原型通过，不等于项目已经具备上线条件。

六、把反馈转成取舍，而不是无限增加功能

验证之后，团队可能收集到很多问题。如果全部立即变成新增需求，原型会越来越重，项目范围也会不断扩大。反馈需要分类处理，而不是简单按提出顺序加入清单。

有些是理解问题，通过改表达和信息结构就能改善；有些是核心流程缺失，需要重新设计；有些属于特定情形，可以先明确边界；还有一些暂时没有足够依据，需要进一步观察。

这里应回到最初的验证目标。如果目标是让报修信息能够被接手，那么影响接手的缺口应优先处理。某个视觉偏好或远期统计功能，即使有价值，也未必属于当前验证必须解决的内容。

每一次修改最好说明要验证的新判断。比如调整设备选择方式以后，使用者是否更容易找到对象；增加补充资料状态以后，双方是否理解事情尚未结束。这样，迭代才是不断减少未知，而不是不断增加页面。

也要允许停止某个方向。若观察显示问题主要来自流程安排，而非缺少工具，就可以先改善工作方式。投入原型的意义，正是让企业在成本较低时拥有调整选择的机会，而不是逼自己必须把原型开发成产品。

七、给验证安排一个结束条件

原型容易修改，也容易让讨论没有终点。每个人都能提出一个新想法，团队于是不断调整，却始终无法判断是否可以进入下一阶段。验证开始时就说明结束条件，有助于避免这种情况。

结束条件不必是一个夸张的通过率。可以是关键角色能够理解并完成核心任务，主要分歧已经得到处理，仍未确认的技术条件已经列出，后续范围有明确边界。具体标准应与项目复杂度相符，而不是照搬其他团队的数字。

同时，要保留没有通过的发现。如果某类使用者仍然存在明显困难，不能因为大多数反馈正面，就把它从报告中删掉。可以决定暂时不覆盖这类场景，但需要把选择和影响说明白。未覆盖与已经解决，是不同的状态。

验证结果也应该包含限制。参与人数有限、任务经过简化、没有真实外部连接，都可能影响结论的适用范围。写清这些条件，不是让成果显得不够好，而是防止下一阶段误用它。

对于决定继续的方向，可以把仍有不确定的部分安排在较早阶段核查。不要先完成大量外围页面，再碰最关键的业务连接。原型已经帮助我们识别了未知，后续计划就应该利用这份认识，而不是重新回到按页面数量推进。

如果决定调整甚至停止，也应把得到的理解留下来。哪些问题被证实存在，哪些原先设想不成立，哪些条件以后变化了可以重新考虑。这些发现同样属于成果，不必因为没有立即进入开发，就把整个过程视为白做。

八、交给开发的，不应该只有截图

当方向经过一定验证，进入开发时，原型之外还需要保留关键规则。字段为什么存在，哪些条件触发状态变化，什么情况必须确认，哪些事情暂时不做，都是开发和后续验收需要的依据。

截图展示的是某个时刻的外观，不能独自表达所有变化。不同角色看到什么，提交失败怎样处理，数据修改以后影响哪里，需要用适合团队的方式补充清楚。没有这些说明，开发人员仍然要重新猜测。

用户反馈也值得一同交接。某个看似不寻常的设计，可能是因为现场确实存在特殊条件。知道来源，有助于后续人员在调整界面时保留真正重要的部分，而不是为了整齐又把问题改回来。

验收则应回到经过确认的任务。不是所有按钮能点就完成，而是相关角色能否用系统走完应该支持的工作。原型阶段形成的任务场景，可以成为后续检查的基础，并随需求确认逐步完善。

交接时还可以保留一份尚未验证的问题清单，并为每个问题写明影响范围。比如，审批人临时离岗由谁接替，历史记录是否允许修改，外部系统不可用时能否继续提交。没有答案的地方应明确标注，安排负责人和验证方式。这样，开发排期才不会把未知条件悄悄当成已经确认的需求，双方也更容易识别真正需要重新讨论的变化。

我喜欢AI让想法快速可见的能力。但对企业而言，更重要的是利用这种速度，更早让现实参与进来。原型越容易生成，我们越有条件先问清楚：这个方向值得继续吗，哪些地方已经理解，哪些还需要证据？

当这些问题得到认真回答，快速原型才不只是一次好看的展示，而是一次帮助企业减少误判的工作。

谭谈思考 · 与我交流

关于我｜一起交流

我是谭良才（Terence），联雅网络创始人。这里持续分享AI落地、企业数字化、商业实践与个人进化。

欢迎扫码添加我的个人微信，交流想法或业务需求。

添加时请注明来意。