我交付了两个 AI 项目,但最后卖的不是软件

我交付了两个 AI 项目，但最后卖的不是软件

这两个项目是我这一个多月刚交付出去的。一个是工作台，一个是标书智能体。

推的时候我很顺。跟客户讲的是AI标书分析、目录自动生成、格式规范对齐，这些词说出来，对方是懂的。

中途出过一次问题。准确率不行，漏项，客户退回老办法了。

后来我想明白一件事：客户要的从来不是我这个软件有多强，而是这个东西做出来之后，他公司承受得起它的不精准。

客户比我想象的难伺候

这家是某中型制造企业，做省内采购平台上的标。

他们对这个东西的要求极其细致。不是"能帮我写标书"，而是"这个标能不能投"。

我在推的时候，其实一直在讲模型能力——上下文怎么处理、harness怎么建、模型怎么选控。但模型没什么可选的，现在基本上都是1M上下文起步的线上模型了。小企业没有条件做本地部署，也没有条件用小模型，所以只能走线上API。

这个我讲得挺顺。

但客户真正卡我的不是模型，是准确率。

具体说，就是废标条件和应答条款。

一个标书大概有多少个维度：商务标准、废标条件、应答时间、技术方案类、格式标准类、目录类。每一项都要写明白，不能含混。

一个文员做错了怎么办？做错了她自己知道。或者她干得时间长了，自己就知道这些问题怎么处理了。甚至不需要老板、不需要企业运营管理员过度操心。

这就是文员的水平。

我当时以为我把这个水平做出来了，交付就完事了。

准确率不行，是怎么不行法

标书写了 19 项要求，我的系统识别出17项，检查单就从这17项来。

那漏掉的 2 项，可能是非标项，也可能是参与门槛。

如果没有写，这标投都不用投，门都进不去。

所以问题不是"这个标能不能读"——能读。问题是检查单能不能列全。列不全，后面全是风险。

它不在炫技的地方，它在最要命的细节上。

客户退回老办法之后，我重新想了一遍：客户不是要一个AI，是要一个他知道哪儿可能出错、但不会漏掉关键项的东西。

后来我改成了这样

我现在这套交付，最后落到一个东西上：一张对照检查表。

不是让 AI 直接给答案，是让AI把"该看哪些点"列出来，然后人对照着一条一条过。

流程是这样的：
·软件先把原始标书要求的细致项识别出来，出对照检查表
·文员或汇总员二次审查
·群里报备，主管人员还有一层审批，逐个审完说"这个标可以准备发了"
·必须人过一遍，才能封包

这里头的逻辑是：AI负责不漏项，人负责判断对错。

我想卖的和最后交付的，不是一回事

我一开始想交付的是"AI能写标书"。

最后交付的是"一张不该漏项的检查表"。

一个干了三年招投标的文员，她脑子里是有套东西的。这套东西不写在任何制度文件里，是她一天天踩坑踩出来的。

她可能自己都说不全，但她知道哪儿最容易出事。

我想做的其实是把这套东西显性化——把它变成一张能逐项打勾的表，让新人也能照着过一遍。

而 AI 在这件事里的角色，不是替她判断，是帮她把该看的都列出来。

现在软件产出的，大概是"一个普通招投标文员的平常水平"。这个水平也有错，所以还是得人审，但审的人不用再从零开始想"哪儿要留意"，照着表过就行。

中小企业要的不是“AI一体化”

我一开始特别想做"AI一体化"。

后来发现，中小企业要的完全不是这个。

它要的是：有没有一些工具，能批量处理我每天重复干的事，让我少操点心，然后稳定给我一个结果。

这个结果必须是我公司承受得起它的不精准的。

说得再直白一点：用好的模型去交付有误差，用一般的模型去交付也有误差，GPT它自己也有降智的时候。这个基准你在定制软件的时候必须考虑清楚。

所以这两个项目交付下来，我最大的收获不是技术上，是交付思路上。

我以前接项目，习惯先讲我能做什么。这次我改过来了——先跟客户搞清楚，哪些环节他承受不了错，哪些环节他可以过。

这个不是技术问题，是销售和交付的起点问题。

但它得由做技术的人问出来。你去问"你这套流程里，哪一步错一次你就得返工重做"，比你去讲"我们的harness架构如何如何"有用得多。

而且客户会给你真实答案，因为他自己心里那本账很清楚。

这次两个项目交付完，我下一步具体往哪走，方向清楚但节奏没定。

工作台那块还在迭代，标书智能体还得看几个月的实际跑下来效果。

会不会有更细的场景（比如售后、维修记录、别的文档处理）能复用这套"识别+对照检查表"的逻辑，我也还在看。

这个不着急，慢慢来。

如果您也想要标书智能体 欢迎关注我留言