上一篇结尾留了一个问题：想法太多、证据太少的时候怎么办。FDE 的工作日常里，这种处境比比皆是。有人说"让 AI 自动核对采购申请，能省掉一半往返"，有人说"先做知识问答更安全"，每个人都举得出一两个理由，但谁都没有证据。开三次评审会，意见还是意见。

这种僵局有个共同的特征：各方争论的都是判断，而不是事实。判断无法说服判断，只有证据能。而证据不会从讨论中自己长出来，得有人去制造它——用一次真实运行、一批能区分对错的输入、一份如实记录的失败。

打破僵局的手段只有一个：把其中一个判断变成可以证伪的实验，亲手做掉。这就是最小原型要干的事。它和演示用的 Demo 长得有点像，但目的完全相反——Demo 的任务是让想法看起来成立，原型的任务是尽快发现想法在哪个地方不成立。前者挑好看的输入，后者专挑会让它出错的输入。两者的外观相似，恰恰是很多"原型"做废了的原因：做着做着，目标从"验证"滑向了"展示"。

FDE 做原型有一个区别于工程师的重点：重点不在"做出来"，而在亲手修改、观察行为、理解限制、调整判断。把代码交给 AI 生成很容易，生成完能不能解释它为什么这样判断、边界在哪里，才是 FDE 能力的证明。

这篇文章用一个贯穿的教学案例讲完整过程：澄川制造想验证"AI 用途核验能不能减少采购申请的不必要往返"，用最小原型跑出了答案，也跑出了意料之外的失败。案例中所有数据均为教学设定。

原型应该先回答哪个不确定问题

动手之前最常见的错误，是把"做一个小系统"当成了原型的目标。

于是范围越滚越大：申请单要接审批流，核验要接物料目录，最好还能发通知——两周过去，最初那个不确定的问题反而没人回答了。范围膨胀的根源往往不是需求变化，而是心里没有一根"这个原型到底要回答什么"的准绳；没有准绳，任何新增的功能都显得"顺手就做一下"。

正确的起点是另一个问题：目前最大的不确定是什么，哪个假设一旦被推翻，整个方案就要重新谈。澄川的场景里，采购专员最痛的环节不是系统功能少，而是申请单反复被打回——"用途没写清楚""金额对不上""附件缺图样"，一单平均往返两三趟，专员的下午有一半耗在改单和催单上。团队的设想是：AI 在提交前自动核对，把不合格的单子拦下来，往返就能减少。

这个设想拆开，其实是两个假设。

第一个假设不成立，后面谈什么都白搭——所以第一轮原型只验证假设一。

这里有个容易被忽略的配套动作：同时写下非目标。澄川的原型明确不验证这些事——不验证 AI 能不能自动填写用途（那是另一个假设）；不验证和正式采购系统打通后的权限与回写（那是上线准备，第19篇再谈）；不验证业务量上来之后的成本。非目标不是偷懒，而是防止评审时有人拿"你这个没接真系统"来质疑一个本就不打算回答这个问题的实验。原型每项实现都要对应一个验证问题，问题清单之外的实现，都是浪费。

假设写出来了，下一步是把它变成可以判对错的预期。这是商业分析里的验收标准思路：标准要能衡量、能测试，表述为通过或不通过，而不是"效果良好"。"AI 核验准确率挺高的"不是验收标准，"十二单合成输入中，每一单进入的分支与先写预期一致"才是。

澄川的原型预期写成这样：准备三类合成输入——

（申请单注明用途、金额、物料编码、附件齐全），

（用途一栏为空或只写了"急用"），

（用途是常规储备补货，按现行规则可以放行但要走另一条分支）。对每一类，先写下系统应该进入的分支：资料完整进"待确认"（交给核验员最后确认），用途缺失进"待补充"（直接退回填写人并说明缺什么），储备用途进"快速放行"。三类各四单，共十二单，全是合成数据。

三类输入的挑选不是随机的，每一类对应一个真实风险。资料完整类防"误拦"——合格的单子被错拦，和漏拦一样会摧毁用户信任；用途缺失类防"漏拦"——这是拦截功能存在的理由；储备用途类防"一刀切"——同样是"可提交"，常规储备补货按现行规则走快速通道，如果系统只会一种判断，就是把规则简化错了地方。三类合起来，压住的正是假设一的两个失败方向：该拦的没拦住，不该拦的拦了，或者拦对了但分到错误的处置路径上。

"先写预期"这四个字看起来多余，其实是最关键的一步。如果先跑后写，人很容易对着实际结果反推"这个结果好像也合理"——这叫事后合理化，是原型验证里最常见的自欺。先写下来，预期和实际之间的每一次不一致都无处遁形，而这恰恰是你花钱买（时间买）的信息。

预期还要写到具体行为层，不能停在"能判断"。比如用途缺失这一类，合格的判断不只是"识别出缺用途"，还要产出退回理由里写明缺的是哪一项、提示语指向申请单而不是别的单。写得越具体，失败时定位越快——这和第13篇讲检索诊断时"期望依据写得越具体，失败时越容易分类"是同一个道理。

最后，这十二单不是随手编的。它们覆盖了当前流程里真实出现过的三种形态（教学场景按合成数据处理），而且和后面复测要用的题分开——调试用的样本和验收用的评测要分开，这个纪律在第13篇讲过，在原型上同样成立。

还有一个动作能救回很多返工：预期写完后，拿给核验员确认一遍。他是最了解现行打回规则的人，如果你把"储备用途进快速放行"写反了，或者把某类本该人工判断的情形写进了自动放行，他在预期阶段就能指出来——改一行字的成本，和改完代码再回头的成本，差了不止一个数量级。预期是写给系统看的，更是写给人确认的。

澄川的原型只有一层壳：读入一份合成申请单，提取几个关键字段（用途、金额、物料编码、附件标记），按规则判断进哪个分支，输出分支名称和理由。没有界面，没有审批流，不连接任何正式采购动作——在隔离环境里跑，替代了哪些真实连接、留下了哪些缺口，实验记录里都写明。隔离环境不是偷懒的借口，早期原型本就可以替代部分真实连接；要守住的是"替代与缺口要说清"，不能给纸面方案贴上"已运行"的标签。

"最小"的标准是：去掉任何一部分，假设一就测不了；留下来的每一部分，都在回答假设一。提取字段是为了判断资料齐不齐，分支规则是为了判断该不该拦，输出理由是为了让业务人员能核对。其他一切——登录、界面、通知——这一版都不在。可以用一个反问自检：这个功能如果删掉，我能不能照样回答假设一？能，就删掉。

有了 AI 辅助，这层壳的搭建成本已经很低。让模型生成提取和判断的代码，或者直接在 Agent 平台上配一个工作流，都是可行的路径。但这里有

AI 生成的代码不能免去解释和测试。你要能逐段说出这段逻辑在干什么、输入输出是什么、出错时表现如何；说不出，这段代码在你的实验里就不算数。

因为原型的产出物从来不是代码，而是你对假设的判断。反过来说，AI 辅助改变的是搭建速度，不是验证标准——这正是 FDE 能把原型当成日常工作手段的原因：实现门槛降下来了，判断门槛没有。

第一遍跑下来，十二单里十一单符合预期——除了一个刺眼的结果：一单"用途缺失"的申请，被放进了"待确认"而不是"待补充"。

这就是原型最值钱的时刻。先别急着改。把这个失败完整地留下来：输入原文、模型提取出的字段、进入的分支、输出的理由，全部存档。回头看提取结果，原因浮出水面：判断逻辑里"用途"字段绑定错了位置——它取的不是申请单上的用途栏，而是单据备注里供应商附言的字段，那一栏恰好有文字，于是系统认为"用途已填写"。一个字段映射错误，真实场景里足够让打回流程形同虚设：所有缺用途的单子只要备注栏有字，都会被当成资料齐全放行。

这个发现还纠正了一个隐含假设。团队原以为风险主要在"AI 读不懂用途描述"，结果第一个暴露的失败是更基础的工程问题——字段取错位置。

原型验证的价值就在这里：它回答的不只是你想问的问题，还包括你没来得及问的问题。

顺带说一句这个失败为什么没有发生在更晚。如果在真实流程里上线，缺用途的单子带着备注栏的供应商附言一路放行，可能要等到某次审计或某次超预算采购才被发现，那时排查的是"哪一步把人骗过去了"，成本完全不同。原型用一单的代价，换掉了生产环境里可能上百单的代价——这就是"尽早让想法出错"的朴素算术。

修正映射之后，先跑原来的十二单确认全部通过，再追加反例：备注栏同样有字、用途栏依然为空的新单，确认它进"待补充"。正常路径和异常路径都要过——只演示正常输入，无法支持任何关键假设，这个道理在原型上比在任何地方都硬。

很多团队做原型，演示时只放成功截图。对 FDE 来说，失败记录才是资产。理由很实际：成功截图只能说明"那一刻它工作过"，失败记录才能说明"它在哪里不工作、我们为此改了什么、改完是否真的好"。

前者经不起追问，后者经得起复盘。澄川这轮实验留下的东西，按实验记录的字段排开是这样的：

表里每一栏都有它的用处，少一栏，证据链就断一环。"条件"写明实验环境的边界，防止有人拿生产标准来审一个隔离实验；"本人改动"区分哪些是你做的、哪些是 AI 生成后你确认过的，这是能力核查的依据；"版本"让修订可回放；"局限"主动声明没验证什么，把"跑通了"和"能用了"隔离开。最要紧的是"下一判断"——它让每轮实验都有明确的去向，而不是做完就停在原地。

最后一行值得展开。原型通过自己写的样本之后，下一步不是宣布成功，而是请一位没有参与搭建的同事来操作。给他一个真实形态的输入，不告诉他预期，看他能不能从系统输出的理由里读懂"这单为什么被拦、拦到哪里"。他读懂了，分支理由才具备业务可解释性；他读不懂，说明理由的写法还停留在实现者视角——比如输出"字段校验未通过"，实现者知道是缺用途，业务人员只会一头雾水。这一步暴露的剩余未知，如实写进记录。自己搭的东西自己永远觉得清楚，这是所有实现者的盲区，唯一的解药是换人。

修订也不是改完就完。每改一处，都要回归既有样本——修正字段映射那次，如果顺手动了别的判断条件，就必须重跑全部十二单，确认正常路径没有被改坏。版本之间的差异要能回放：第二轮的配置和第一轮差在哪，为什么改，改了之后哪些样本的结果变了。这也是能力展示的一部分——本人贡献、版本、失败与限制都可查，才叫作品；只有成功截图的，只能叫宣传。第08篇讲人机分工时说过"把判断变成可检查的对象"，实验记录就是把原型的整个验证过程变成可检查的对象。

原型跑完，结论不是"成了"或"没成"二选一，而是三选一：继续、缩小、停止。

三个选项的难度不一样——"继续"容易说，"缩小"需要承认范围画大了，"停止"需要承认方向错了。后两个决定之所以难做，是因为它们否定的是人而不是数据；而实验记录的价值恰恰在于，让这两个决定可以用证据说话，而不是用面子说话。

澄川这一轮的判断是"有条件继续"：假设一在小样本上成立，但局限写得清清楚楚——十二单合成输入不代表真实分布，误拦率没测过，真实员工会不会绕过拦截没观察过，和生产系统的集成更是完全没碰。所以"继续"的下一步不是上线，而是扩大样本、引入真实历史申请单做回放，以及观察小范围试用。原型跑通不等于生产就绪，这句话要写在评审材料的第一行，防止"跑通了"被口口相传成"可以上了"。

"缩小"适用于假设部分成立的情况：比如 AI 对用途缺失识别可靠、对金额核对不可靠，那就把范围缩到只做用途核验，金额继续走原规则。"停止"同样是一个合格的结论——如果假设一被证伪，实验的价值恰恰是让你在为错误方向投入更多之前停下来。三个决定都成立的前提是证据充分，而证据就是前面那张实验记录。

还有一种常见的不合格结局要单独点名：实验做完了，记录没留下，三个月后换了一拨人，对着同一个想法重新争论一遍。原型的成本是一次性的，记录的复利是长期的——哪一个更值钱，取决于你把记录留成了什么样子。

迁移练习留给你：把场景换成报价单缺图样，或者客服查询某份资料但无权限，用同样的流程走一遍——写出假设与非目标、三类输入的先写预期、搭最小路径、然后交上来的东西是一条失败记录、修订依据和复测结果，而不是一张成功截图。

下一篇讲评估：原型通过之后，怎样区分"局部合格"和"整套可用"——十二个分类任务里十一个对了，那一单错了，这套东西到底算不算合格？

FDE怎样用最小原型验证想法

副总裁

人工智能

职业发展

测试

FDE原型验证的核心在于通过最小可行实验将争论转化为可证伪的假设，优先测试最大不确定性，明确非目标与验收标准，并保留完整失败记录。成功标准不是代码运行，而是获得对业务判断的证据支持，决定继续、缩小或停止。

数据处理

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

FDE怎样用最小原型验证想法

FDE怎样用最小原型验证想法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐