关于AI创新战略的几点记录
过去两年参与了三个 AI 项目落地：企业级知识库问答、代码辅助工具、内容生成平台。几条经验来自实际数据和账单，不是战略 PPT。
第一件事：技术选型不是越强越好
2024年初做知识库问答系统的时候，团队里吵了一周：用GPT-4还是用本地部署的开源模型？技术主管坚持用GPT-4，理由是"性能是最好的护城河"；产品经理坚持本地模型，理由是"数据安全和成本控制"。
吵到最后，我们做了一个简单但不浪漫的决定：先上最便宜的GPT-3.5-turbo，跑一个月看看。
一个月后的数据很直接：
- 用户满意度：GPT-4 87%，GPT-3.5 79%，差8个百分点
- 调用成本：GPT-4 是 GPT-3.5 的12倍
- 响应速度：GPT-4 平均3.2秒，GPT-3.5 平均1.1秒
有意思的是，用户投诉最多的是"回答太慢"和"突然断开"，很少嫌不够聪明。8 个百分点的质量差在非关键场景还能忍，2 倍延迟和 12 倍成本会直接决定产品能不能活。
AI 产品选型，先把延迟和成本算清楚，再谈模型有多聪明。 除非你在做基础设施，大多数场景里成本和性能比"最先进"更硬。
后来我们采用了混合方案：复杂问题路由到GPT-4，简单问题用GPT-3.5，再配合RAG做上下文增强。实际效果差不多，但成本降到了纯GPT-4方案的30%。
第二件事：场景选择要够窄
代码辅助工具的项目走得比较坎坷。最初的想法很大：做"全栈代码助手"，支持前后端、数据库、运维脚本，还想加代码review功能。听起来很美，但第一个原型就暴雷了。
我们找了5个开发试用，反馈出奇一致：
- “智能补全在写业务逻辑时经常给出无关建议”
- “代码review太激进，把我原本正常的代码风格全改了”
- “和IDE本身的补全冲突，反而慢了”
问题出在场景太宽。一个工具想覆盖太多场景，最后每个场景都做不好。
后来我们把目标收窄到一件事：只做API接口的mock数据生成和测试用例辅助。场景很具体，痛点很明确，用户的期望值也比较合理。
调整后的版本，3个参与测试的开发说"开始有点用了"。不是那种颠覆性的好用，但能在日常开发里偶尔省点时间，不至于太烦。
场景要窄到用户说得清痛点。 全栈代码助手做不动，收窄到 API mock 和测试用例辅助，三个试用开发才说"开始有点用了"。
第三件事：产品落地要比你想的晚
内容生成平台是个典型的"看起来容易，做起来难"项目。技术本身不复杂：调用GPT-4的API，加一点prompt工程，再接个简单的web界面。两周就能做出一个MVP。
但真的要产品化的时候，问题就来了：
- 用户期望值被ChatGPT拉得太高，任何低于GPT-4的效果都是"不行"
- 成本控制困难：一个账号如果天天用，一个月API费用能到几十美元
- 质量控制：用户要的是"稳定的可用性"，不是"偶尔的惊艳"
我们尝试了几种方案：
- 按量付费：用户抱怨"不知道花了多少钱"
- 包月制：成本风险全在运营方
- 基础功能免费+高级付费：复杂度直接翻倍
最后选择了一个很务实的路线：企业内部使用，按部门分摊成本，重点不是商业化而是提效。这不是最激动人心的结果，但至少产品活下来了。
这给了我一个很朴素的判断：从AI技术到产品，中间还有很多"脏活累活"。成本控制、用户预期管理、商业模式设计，这些看似与技术无关的事情，往往决定产品能不能活。
第四件事：团队配置要实际
这些项目里的团队配置，我也踩了不少坑。
最早的AI团队配置比较"理想化"：
- 2个算法工程师（研究模型和prompt）
- 3个后端开发（做API和系统集成）
- 1个前端开发（做界面）
- 1个产品经理
看起来很合理，但实际跑起来发现两个问题：
- 算法工程师和产品需求脱节：他们关注的是"模型准确率提升了多少"，而不是"用户是不是真的用得上"
- 后端开发被AI细节牵扯太多：原本只需要写业务逻辑，现在还要研究RAG、向量检索、prompt优化这些，既不擅长也不情愿
后来调整成：
- 1个算法工程师（专注核心模型优化）
- 2个"AI工程师"（既懂模型也能写业务代码，负责把AI能力接入系统）
- 2个后端开发（专注业务逻辑和传统开发工作）
- 1个产品经理（懂一点技术但更懂用户场景）
这个配置的关键是"AI工程师"这个角色：他们不是传统的算法工程师，也不是传统的软件工程师，而是中间层——既知道AI能做什么、怎么做，也知道怎么把AI能力包装成用户能用的产品功能。
这不是什么创新的组织架构，就是踩坑后的实际选择。但挺有效的。
第五件事：ROI计算要诚实
最后说说钱的事。做AI项目，成本很容易被低估，收益很容易被高估。
知识库问答系统的成本结构大概是这样：
- API调用成本：每月$2000-3000
- 向量数据库：每月$800
- 基础设施（服务器、存储）：每月$500
- 人力成本：2个全职工程师+0.5个算法工程师
收益方面，我们做了个简单的计算：
- 以前用户找信息平均耗时15分钟/次
- 现在通过问答系统平均耗时3分钟/次
- 每月问答次数约8000次
- 节省时间：(15-3)/60 * 8000 = 1600小时
如果按人力成本$50/小时算，每月节省$80,000。这个数字看起来很漂亮，但它有几个前提：
- 用户真的愿意用问答系统（实际使用率只有预期的一半）
- 系统真的稳定（早期宕机率比预期高）
- 用户找的信息真的有价值（很多时候找的是无关信息）
最后算出来，真实的ROI大概在18-24个月才能回本。不是不能做，但需要把预期调低一点。
AI项目的ROI计算，不能按"理想状态"算，要按"现实情况"算。用户使用率、系统稳定性、内容质量，这些变量都会影响最终效果。
几个实际的判断
做完这些项目，我有一些比较实际的判断：
不要迷信"最先进的模型"。除非你是做基础研究，否则大多数场景下，够用的模型+好的产品设计，比最先进的模型+差的产品设计更有价值。
场景要窄。宁可在一个具体场景里做得足够好，也不要试图覆盖太多场景。用户不会因为你的工具"什么都能干一点"而付钱，但会因为它"把某一件事干得特别好"而留下。
成本是硬约束。不要先假设成本能接受，再想办法赚钱。要把成本当成产品设计的第一性约束，从一开始就围绕它做决策。
团队配置要务实。不要为了"看起来专业"而堆砌各种头衔。根据真实需求配置角色，特别是"AI工程师"这种中间层角色，往往是连接技术产品和用户场景的关键。
ROI计算要诚实。不要用理想状态下的数据骗自己。用户不会按你的理想预期使用产品，系统不会按你的理想预期稳定运行。
最后说一句
三个项目下来，ROI 诚实算大概 18–24 个月回本；混合路由把 API 成本压到纯 GPT-4 方案的 30%。
上面几条都很具体，也都很局限：知识库、代码辅助、内容生成，换行业结论可能全变。至少都是看过账单和投诉工单之后写的。
参考
版权声明: 本文首发于 指尖魔法屋-关于AI创新战略的几点记录（https://blog.thinkmoon.cn/post/999-ai-innovation-strategy-practice-technology-to-value/） 转载或引用必须申明原指尖魔法屋来源及源地址！
评论
使用 GitHub 账号登录后即可留言，支持 Markdown。