Dify 装进别人的老系统里：不自己造产品，靠给旧软件加 AI 功能接单

大部分人做 AI 产品的顺序是反的：先做出一个东西，再满世界找用户。真做了才发现，难点从来不在技术，而是没人愿意为你的新工具改掉用了十年的习惯。

换个方向试试：不去找用户，去找那些已经握着用户的软件。每个行业里都有几套用了七八年的内部系统——进销存、工单、教务、仓储、报修。界面老旧，但每天有人在填。它缺的不是重构，而是一个很小的能力：把粘贴进来的乱文字变成规整字段，把一堆工单自动归成几类，用一句话查出上个月的数据，或者生成一段可以直接改的回复草稿。你把这个能力做出来嵌进去，收一笔开发费，再加一点月度维护，就是一门能活下去的生意。工具链上，Dify 这类可视化编排、支持私有化部署的平台加上一层薄薄的适配代码，通常就够了。

为什么「加装」比「重做」更容易成单

• 客户本来就有维护费、信息化这类预算科目，不需要说服老板「上一个新系统」。
• 需求是「一个按钮」，当场能演示，验收标准写得清楚。
• 只读加人工确认，不碰核心数据的写入，安全边界好谈。
• 你的对手往往是「没人做」，而不是某家同行。

哪几个功能最容易先落地

• 自然语言查数据：接他们的报表库，问一句出一张表，全程只读。
• 文本转结构化：把一段聊天记录、邮件或 PDF 文字自动填进表单字段，人工确认后再提交。
• 相似内容归并：工单、差评、客户留言自动分到几个类别，输出一张清单。
• 草稿生成：通知、邮件、内部资料问答，只出草稿，发送按钮始终在客户手里。

一上来别做自动写入和自动决策。医疗、金融等受监管场景，尽量只做检索与草稿，具体合规边界请咨询专业人士，涉及客户数据要签清楚数据处理约定，注意个人信息保护。

报价与交付上的三个提醒

• 按功能一口价，别按调用量报；月度维护费从第二个月起收，用来覆盖模型和接口的变动。
• Demo 用客户真实数据的脱敏样本，别用你自己编的例子，对方一眼就能看出真假。
• 不承诺准确率、不承诺省几个人。约定「人工确认后生效」，把验收动作写清楚，比如某个表格的填写时间由谁自己测。

谁适合先试，第一步做什么

能读懂别人代码的后端或全栈，一两个人就够；只会写提示词会比较吃力，因为你得改他们的界面和接口。第一步不用写代码：回想你待过的行业里，哪套系统你当年天天用、听说现在还在用。找一个还在里面的熟人，只问一句——这份表每天谁在填，填多久？有人抱怨的地方，就是那个能插进去的按钮。