基于灵犀的三次系统原型搭建实践的总结分享
Lv.2 潜力创作者
让价值可见，让客户可感——一个集成商的"原型销售法"实战复盘
一、写在前面：售前的困局
做了这么多年软件集成，我们最熟练的技能是做PPT：产品架构图越画越漂亮，功能清单越列越全，价值主张越写越高大上。但客户越看越麻木——因为那些"价值"是我们想卖的，不是客户想解决的问题。
2026年10月，前后一个月左右，我带着AI助手灵犀连续做了三次系统原型：某职业院校的合同管理平台、某园区企业的业财一体化系统、某医疗科技公司的共享管理应用平台。三次原型之后，又用一晚上的时间，给原型补上了"沟通语言"和"改动台账"。四步走完，"原型销售法"从一个概念变成了我们跑通的工作方式。这篇文章做个总结分享，也把踩过的坑一并交代。
先说"原型销售法"可能带来的三点变化：
回归客户问题：销售要一点点凿掉拈手自来的PPT技能、产品技能、所谓的规划技能，回归客户的问题本身，让客户不为冗余的"价值"买单。
可得、可见、可感：不管FDE热度如何，原型是让客户可得、可见、可感的存在，串起前端售前—中端销售—后端交付，打破"销售往高处卖、交付往低处做"的两段论。
小团队的价值出口：对小团队、小公司甚至个人，产品不再是通往客户的唯一道路，低成本解决问题的能力才是客户买单的理由。
下面按实战的顺序展开。
二、第一次：某职业院校合同管理平台——原型成了"需求确认语言"
这个项目从投标阶段就介入，中标后进入实施，正好赶上我们第一次把"实施方案"从Word搬进浏览器。
做法：把实施方案里的流程清单、表单、审批路线、权限管控、数据台账，做成一个单文件离线可交互的HTML原型——CSS/JS全内嵌，双击就能打开，可以投屏演示、可以直接发微信给客户。11个一级模块，首页门户、招标采购、合同起草、用印、变更、验收、纠纷……全部可点击、无死链，页面里的数据是仿真数据，但业务逻辑是真的：支出必须小于收入，供应商详情能一键穿透到关联合同、变更记录、验收记录。
迭代过程：第一版交付，打分只有2.9分；一次列出12条结构性意见，重构到4.1分；再一轮细节打磨，到4.9分。三轮达标。
最大收获：需求偏差的成本，从售后（变更、扯皮、验收难）前移到了售前（改HTML几乎零成本）。客户在页面上指认"流程应该是这样走的"，比在文档里批注"第3.2节不太对"精准一百倍。原型从"演示工具"变成了"需求确认语言"——这是商业逻辑里价值最大的一个转变。
三、第二次：某园区企业业财一体化——928行的范本和迭代纪律
这次是园区场景：招商、租赁、合同、收入、支出、运维，围绕"销项/进项/运维"三条业务线搭建业财一体化原型。这次体量不大，928行单文件，但沉淀下了后来所有原型都在用的方法论：
设计思路先行：先出"模块清单+页面结构+权限设计+视觉基调"，确认后再动手写代码，避免大返工；
仿真数据驱动：页面内容由JS数据对象+渲染函数生成，不写死在HTML里，改数据不用改页面；
迭代纪律：修改意见在原文件上迭代，不另存版本、不删客户已经认可的模块；
验证闭环：每轮修改后必做语法校验+无头浏览器截图自检，不带病交付。
踩过的坑也真实：楼层编号"A-1"和"A区1层"格式不统一，导致平面图一片空白、图例全是0；岗位切换时把菜单藏掉了，被纠正"权限差异要用权限拦截表达，不能藏菜单"。这些教训后来都固化成了规则。
四、第三次：某医疗科技公司共享管理平台——从"能看"到"敢交付"
第三次体量最大：四大共享应用（财务、供应链、行政人力、研发）+管理看板+集团化管控。前两次的方法论全部复用，但也暴露了新问题——原型规模一大，高频问题开始反复出现：
筛选条件选"全部"出不来数据（筛选逻辑写死了具体值）；
新增模块的色调跟全局色板不一致（色板没有一次定死，逐模块补丁覆盖）；
占比色块铺不满整行（flex收缩问题）；
页面末尾多了一个未闭合的</div>，把后面5个模块整个挤出了容器，页面上方一大片留白。
同样的错前两个原型也犯过，只是规模小没炸出来。这次我们把所有高频问题做了一次归因，固化成六项出厂自检铁律：筛选"全部"必须出全量数据、色板一次定死、占比布局用grid、表单控件显式设字号、交付前div配平校验、跨模块数据key归一化。配套还建了改动点清单销号机制——交付前先列"这次改了哪几条"，逐点对照销号，防止一笔带过。
这一步的意义：原型从"给客户看的东西"变成了我们自己有质量门的生产物。低成本，不等于低质量。
五、收口之夜：给原型装上"图纸语言"和"改动台账"
三次原型跑下来，质量门立住了，但还有一个别扭的地方没解决：沟通和改动全靠聊天记忆。客户（或者我们自己）说"那个按钮改一下""筛选那儿不对"，灵犀就得去猜是哪个"那个"；一轮改了八处，下一轮总有靠记忆没接住的。
10月20日晚上，我们用某医疗科技公司实施方案部分内容做了一次流程测试，把两件事跑通了：
第一件：术语标注双版本。 生成原型时，在每个模块、容器、表单控件上挂一个绝对定位的小角标——浅灰小字，像建筑图纸上的编号：D01编目标域，D03-2编域内元素，两级编号，挂在独立属性上不参与布局。从此沟通从"那个按钮"变成了"D03-2筛选栏改状态字段"，一句话定位，不用截图、不用描述半天。定稿后一键移除标注层，就是干干净净的对外发布版——标注版严禁发客户，发布版禁止带标注，同一个文件的两种形态，不是两套生成。
第二件：原型修改记录表。 原型结构定稿后，按目标域清单自动建一张修改台账（金山多维表），每一行对应一个页面元素：域编号、术语名称、页面位置、当前实现、是否要改、修改要求、确认状态。人只做判断——填"要不要改、怎么改"；灵犀维护状态流转：待修改→已修改→待确认→已关闭。没关闭的行，下一轮修改要求直接填进同一行累进留痕；每轮动手前，先扫全表未关闭行，不靠聊天记忆——这就是"没有漏网之鱼"的保证。确认关闭的行，还能批量汇总成正式的需求变更记录，直接和实施流程衔接。
这一晚的意义：前三次解决的是"让客户看见"，这一晚解决的是"让改动可管"。原型第一次有了图纸一样的精确语言，改动第一次有了和代码仓库一样的留痕闭环——而这些，全部是在多维表和一个HTML文件里完成的，没有多花一分钱。
六、四次实战后的四点总结
1. 原型改变的不只是演示，是责任对象。 讲解产品功能的价值在归零，稀缺的是听懂业务、定义问题、用原型跟客户对话的能力。我们对客户的使用价值负责，而不是对卖出去的产品负责。
2. 快速到80%容易，95%→99%是真正的战场。 原型再好也还是原型，生产化要过权限、并发、数据迁移、安全合规、私有化部署这些关口。这部分不会被AI消灭，反而是懂政企、懂本地化的服务商的利润护城河。
3. 原型能力本身不构成护城河。 人人都会用AI做原型的那天很快会来。真正的护城河是原型背后沉淀的行业本体、模板和流程资产——标注规则、自检铁律、修改台账，让第10个客户的成本降到第1个客户的一半以下。
4. 能力要长在公司身上，不能留在个人脑子里。 四次实战的每一条踩坑和规则，我们都进了知识库和技能资产。AI助手记住的不是聊天记录，而是可复用的工程纪律。
七、写在最后
一个月、三次原型、一个收口之夜、三个行业，客户每次都在自己业务的"页面"上确认需求，而不是在文档里想象系统；每一处改动都在台账里留痕，而不是消失在聊天记录里。原型让价值可见、让客户可感，也让一家小公司有了和大厂不一样的打法：不去证明产品多全，而是证明我懂你的问题，并且低成本地先做出来给你看。
低成本解决问题的能力，就是客户为我们买单的唯一理由。
