AI 应用定制开发：当通用工具贴不上业务流程时

写在前面 定制开发是所有方案里最贵的一条路。这篇文章有一半篇幅在讲"什么时候不该走这条路"——因为我们见过太多本可以用现成方案解决、却被做成定制项目的需求。

一、先判断值不值得定制

在讨论怎么做之前，先回答一个问题：现成的工具为什么不行？

常见回答与我们的判断：

定制的价值来自贴合度，而贴合度的价值只有在流程足够高频、足够核心时才划得来。

定制项目的隐性成本

除了显性的开发费用，定制项目还有几笔容易被忽略的支出：

• 内部配合的时间成本：业务方需要派专人对接需求、提供数据、参与测试。这个人的时间也是成本。
• 变更的连锁成本：业务规则变一次，可能需要改系统、改提示词、改测试用例。如果是通用产品，规则变更通常只需要改配置。
• 技术债务的积累：定制系统迭代几次以后，最早的设计假设可能已经过时但没人敢动。解决这个问题需要持续的架构维护投入。

二、需求诊断：从"你想要什么"到"你的问题是什么"

我们接项目的第一步不是听需求清单，而是搞清楚三件事：

1. 现在这件事是怎么做的？ 谁做、花多长时间、卡在哪。我们通常会跟实际做事的人（而不是提需求的管理者）聊——他们说的才是最真实的瓶颈。
2. 数据在哪？ 在哪个系统里、什么格式、质量如何、谁有权限。
3. 怎么算做成了？ 用什么指标验收，谁来判断。

第三个问题最容易被跳过，也最容易导致项目做完了双方对结果的理解不一致。验收标准要在动工前写下来。

关于第二点，需要提前泼一盆冷水：很多 AI 项目最终卡在数据质量上，而不是模型能力上。 字段含义不清、历史数据混乱、关键信息只存在于某个人的经验里——这些问题不会因为引入 AI 而消失。

数据现状的快速诊断

在数据层面，可以用四句问话快速判断一个项目的落地难度：

• "这个数据一般在哪个系统里？" → 知道在哪个系统里说明数据是可定位的
• "最近一个月有在更新吗？" → 没有维护的数据就是死数据
• "同一个指标，不同部门口径一致吗？" → 口径不一致意味着 AI 的输出会引发争议
• "如果需要取这些数据，接口能调通吗？" → 调不通意味着需要额外的系统改造

三、常见的定制形态

业务系统 AI 助手

嵌入到 CRM、ERP、OA 中，让员工用自然语言完成查询和操作。核心难点是与既有权限体系的对接。

一个典型场景：销售问"我名下本月到期的合同有哪些"，AI 需要先识别当前用户 → 查该用户的客户列表 → 查这些客户的活跃合同 → 过滤出本月到期的 → 按紧急程度排序。每一步都依赖现有系统的权限和接口。

数据查询与分析助手

通过 Text2SQL 让业务人员直接用自然语言问数据。这块的关键不在模型，而在于：

• 数据表的字段和口径能不能被准确描述给模型。模型不知道"销售额"在你的系统里叫 total_amount 还是 revenue，需要你在元数据里做映射。
• 生成的 SQL 是否需要人工确认后再执行。在涉及写操作（如修改记录）时，确认环节不可或缺。
• 指标口径是否统一。"销售额"在财务和销售部门可能是两个数——这个分歧在引入 AI 之前就存在，AI 只是把它放大了。

Text2SQL 落地的一个实用建议：先做只读查询，等稳定运行三个月后再考虑开放写操作。 只读查询出错最多是看到错误数据，写操作出错是真金白银的损失。

领域知识助手

针对特定行业的专业问答，通常需要结合行业语料对模型做适配。法律行业的法条引用格式、医疗行业的诊断逻辑、金融行业的术语体系——这些都不是通用模型能直接胜任的。

流程自动化应用

把某个具体的业务流程端到端自动化，通常涉及多个系统的打通。比如"合同审批→盖章申请→归档"这条链路，AI 不是替换某一步，而是把整条链路串联起来。

四、模型微调：什么时候真的需要

微调不是万能药，也不是第一选择。我们的判断顺序是：

1. 先试提示词工程 —— 成本最低，能解决相当一部分问题
2. 再试 RAG      —— 知识类问题基本靠它，且知识可随时更新
3. 最后才考虑微调 —— 当模型需要学会一种"表达方式"或"判断标准"时

微调擅长的是让模型掌握风格、格式和领域判断习惯，不擅长往模型里"灌知识"——知识应该放在知识库里，因为它会变。

微调的实际成本还包括：

• 标注数据准备——通常是最大的一块投入。需要领域专家把"理想的输出长什么样"标注出来，数量可能达到几百到几千条。
• 评测集建立——没有评测集的微调等于盲调，你不知道是改好了还是改坏了。
• 后续验证成本——基座模型每次升级，都需要在新版本上重新验证微调效果。厂商每半年发一个新版本，就意味着每半年要做一轮回归测试。

五、POC 阶段应该验证什么

POC 的目的不是做一个漂亮的演示，而是用最小成本验证最大风险。我们建议 POC 集中验证三件事：

1. 效果能不能达标：用真实的、有代表性的数据（包括困难样本），不要只挑好做的。困难样本才是区分方案好坏的试金石。
2. 数据能不能拿到：接口通不通、权限批不批得下来、数据质量够不够。这一条经常比技术问题更难——一个接口审批流程走两周是常态。
3. 成本能不能接受：按预估的使用量算清楚推理成本和运维成本。这包括了模型调用的 token 费用、服务器费用、以及运维人力。

POC 通过的标准要在 POC 开始前定好。 否则结束时双方会对着一个"看起来还行"的结果争论要不要继续。一个可用的标准示例："在 50 个真实测试样例中，准确率达到 85% 以上，且错误案例中没有系统性偏差。"

六、交付之后

定制项目最怕的是"交付即失联"。我们建议在合同阶段就写清楚：

• 源代码和文档的交付范围——哪些是我们维护、哪些移交给你们
• 保修期和响应时效——问题分级和对应的响应时间
• 后续迭代的合作方式——是按人天结算还是按需求报价
• 企业方需要具备的运维能力，以及我们提供的培训

七、典型交付流程

需求诊断  →  架构设计与方案确认  →  POC 验证
   →  开发与系统联调  →  试点运行  →  上线
   →  运维交接与持续优化

八、我们的实践基础

上述方法论不是纸上谈兵——我们自己的产品「辣椒AI」就是一套完整的多服务系统：网关、用户端、管理端、核心 API、文档处理中台、工具沙箱、以及关系库/向量库/图数据库/对象存储的组合。踩过的坑、做过的取舍，都变成了交付企业项目时的判断依据。

如果你有一个说不清楚该用现成工具还是定制开发的需求，欢迎联系我们。我们不介意在评估后告诉你"这个不用定制"。