OpenAI 又更新了 API 协议，这次把“禁止使用其输出训练竞争模型”的条款加粗标红了。这感觉就像你租了个铺面，房东突然说“你在这儿卖的面包，配方不能拿去隔壁街开店用”。行吧，大厂画地为牢是迟早的事，但这也让我更确信了 2016 年那会儿死磕爬虫时悟出的道理：你的核心逻辑，必须长在自己的服务器上。
2016年我搞SEO爬虫，最怕的就是目标网站改DOM结构。一改，我的正则和XPath就全废了，得通宵重写。后来学乖了，用更抽象的规则去匹配，把数据清洗逻辑和页面结构解耦。现在看大模型API，不就是一个超级豪华版的“DOM”吗？它今天给你返回JSON，明天可能就变成Protobuf；今天这个字段叫“content”，明天可能就叫“message”。你把业务逻辑全绑在它的输出格式上，它一哆嗦，你就得ICU。
所以 Flovico 现在给客户做自动化方案，第一条铁律就是：用大模型，但别信大模型。具体说，就是把大模型当做一个“模糊处理器”来用。比如客户要自动处理客服邮件，我们不会直接把邮件内容扔给 GPT 说“分类”。我们会先用自己的规则引擎（哪怕就是一堆 if-else）做第一道粗筛，把明确是投诉、询价、售后的分出来。只有那些模棱两可的、规则覆盖不到的，才交给 GPT，而且给它的指令是：“从以下三个类别中选一个，只输出类别编号。” 这样，GPT 的输出就被约束成了一个简单的数字或标签，我们的后续流程（转给哪个部门、触发什么模板）完全基于这个标签，而不是去解析它那可能夹杂着多余解释的文本。哪天 GPT 挂了，或者贵得用不起了，我换成一个本地部署的 7B 小模型，甚至换成一堆更精细的关键词规则，整个业务流的骨架还能立着。
这其实就是把“不确定性”封装在一个黑盒里，盒子的接口定义权在我手上。大厂喜欢推的“一站式解决方案”，本质是让你把整个身家都放在它的黑盒里，它给你提供从输入到输出的全套“魔法”。魔法很炫，直到它开始收高昂的魔法税，或者突然告诉你某些魔法不能用了。我们这种搞过交付的都知道，客户最后买的不是魔法，是确定性的结果。你能用魔法低成本实现这个结果，很好，但你必须准备好，当魔法失效时，用“体力活”也能把结果大致跑通。
最近在封装几个健身教练用的饮食分析工具，也是这个思路。市面上已经有现成的、能识别食物图片的 API 了，识别率可能 95%。但我不会让整个流程依赖它。我的流程是：用户上传图片 -> 本地模型先尝试识别（成本低）-> 如果置信度低于阈值，转人工标注队列（用 n8n 挂着，我自己或兼职看一眼）-> 最终结果入库。这样，那个 95% 准确的 API 就成了一个“加速器”，而不是“心脏”。心脏是我们自己设计的、混合了自动与人工的 workflow 逻辑。大厂的 API 再变，我这个 workflow 顶多是某个环节的速度变慢了点，不会猝死。
说到底，这是一种“防御性架构”。经历过 2020 年那种被团队和供应商绑死、动弹不得的状态后，我对“依赖”这个词过敏。技术依赖、平台依赖、甚至人的依赖，都是风险点。现在 AI 浪潮下，新的依赖陷阱包装得更精美了，喊的是“赋能”和“降本增效”。但骨子里没变：它想成为你的水电煤，然后慢慢涨价。我的策略就是，自己打井，自己发电，可能初期投入大点，但保证旱涝保收。OpenAI 越是这样明确划界，越是在提醒我们这些独立干活的人：别在别人的田里种你唯一的庄稼。你的逻辑，你的流程，你的数据流转方式，这才是你真正的田。
