做传统软件，我们卖的是确定性。需求明确、功能确定、测试通过、验收合格，项目结束。

做智能体，我们卖的是概率性。同一个问题问三次，可能得到三个不同的答案。这不是bug，是大模型的本质。

1.1 幻觉不是敌人，是需要管理的特性

大模型会"一本正经地胡说八道"，这在业内叫幻觉（Hallucination）。很多技术团队一上来就想"消灭幻觉"，结果发现根本做不到。

正确的思路是管理幻觉：承认它存在，但通过各种手段降低它的影响。就像开车不可能完全避免颠簸，但可以通过减震系统让乘坐更舒适。

1.2 验收标准要从"对不对"变成"好不好用"

传统软件的验收是"对或错"：测试用例通过就是对的，不通过就是错的。

智能体的验收是"多好或多坏"：人工介入率从30%降到10%，这就是成功；用户找答案的时间从5分钟降到30秒，这就是价值。

核心转变：从"功能实现"转向"效果达成"，从"交付即结束"转向"交付才开始"。

既然智能体项目需要持续优化，那怎么签合同？怎么收款？客户能接受吗？

我们的经验是：把项目拆成三期，每期都有明确的效果指标和收款节点。

2.1 第一期：探索期（2-4周）——先证明"这事能成"

目标不是做出完美的产品，而是快速验证可行性，建立效果基线。

交付物：一个能跑起来的MVP（最小可用产品）

效果指标：准确率60%以上（别嫌低，先让甲方看到希望）

核心工作：收集bad case，搞清楚问题出在哪

2.2 第二期：优化期（4-8周）——让效果"肉眼可见"

这是项目最关键的阶段，也是赋能交付的核心期。

交付物：优化后的版本 + 完整的知识库

效果指标：准确率提升到80%+，核心场景可用

核心工作：

• 优化Prompt，让模型更"听话"

• 扩充知识库，覆盖更多业务场景

•开始培养甲方的"AI管理员"

2.3 第三期：规模化期（持续）——让甲方"自己玩起来"

这时候，乙方的工作重心从"做"转向"教"。

交付物：生产级版本 + 运维体系 + 培训文档

效果指标：人工介入率降到10%以下，甲方能独立运营

核心工作：甲方内部团队能独立迭代优化

很多乙方团队有个误区：项目做完了，交付上线了，就可以撤了。

但对智能体项目来说，交付只是开始。如果甲方自己不会运营、不会优化，半年后这个项目就会"烂尾"。

所以，项目中后期的核心任务不是"做"，而是"赋能"——培养甲方内部的人，让他们能持续和业务方协作迭代。

3.1 培养甲方的"AI管理员"

每个智能体项目都需要一个"AI管理员"——不一定是技术大牛，但要懂业务、有耐心、愿意学习。

这个人从项目第二期就开始参与：

•一起看bad case：为什么这个问题回答错了？是知识库缺失还是prompt问题？

•一起优化知识库：怎么写知识条目能让模型更容易理解？

•一起调整prompt：怎么表达能让模型输出更稳定？

通过"手把手"的实战教学，让甲方的人真正理解智能体的运作逻辑，而不是只会"点点按钮"。

3.2 建立"业务-技术"协作机制

智能体要真正好用，必须懂业务。但乙方团队不可能比甲方更懂业务，所以必须让甲方内部的人成为"桥梁"。

我们建议甲方组建一个"AI协作小组"：

•业务代表（1-2人）：来自一线业务部门，懂用户痛点，能提出优化建议

•AI管理员（1人）：负责技术对接，能把业务需求转化为优化动作

•乙方顾问（按需）：提供技术指导，解决复杂问题

这个小组每周开一次会：业务方反馈这周用户遇到了什么问题，AI管理员分析是什么原因，大家一起讨论怎么优化。

关键心法：乙方不要"包办一切"，而要"教会甲方"。甲方的人懂业务、有动力，他们才是持续优化的主力军。

智能体项目最怕的是"上线即巅峰"——刚上线的时候效果最好，之后越来越差，最后没人用了。

要避免这种情况，必须建立持续迭代的机制。

4.1 Bad Case驱动优化

智能体回答错了不可怕，可怕的是不知道错在哪、不知道怎么改。

建立bad case收集-分析-解决的闭环：

1.收集：用户反馈、客服记录、日志分析，多渠道收集问题

2.分类：是知识缺失？理解偏差？还是模型"幻觉"？

3.归因：问题的根本原因是什么？

4.解决：补充知识、调整prompt、优化流程

5.验证：同样的输入，现在回答对了吗？

4.2 知识库的持续维护

智能体的知识库就像花园，需要定期浇水、修剪、除虫。

甲方的AI管理员需要定期：

•补充新知识：业务变化了，知识库也要更新

•删除过时内容：避免模型学到"老黄历"

•优化表达方式：同样的知识，换个说法模型可能理解得更好

4.3 模型升级适配

大模型更新很快，今天用的模型，三个月后可能就有新版本了。

甲方的AI管理员需要关注：

• 新版本有什么改进？

• 升级后需要重新测试哪些场景？

• prompt需要调整吗？

培养甲方内部人员，说起来容易做起来难。很多甲方的人会觉得："这是你们乙方的事，凭什么让我学？"

所以，赋能交付的核心是"让甲方愿意学、学得会"。

5.1 降低学习门槛

不要把甲方的人当成程序员来培养，要给他们"傻瓜式"的工具：

•可视化知识库管理：点点鼠标就能添加、修改知识条目

•模板化prompt：提供常用场景的prompt模板，改改参数就能用

•一键测试工具：改了知识或prompt，一键测试效果

5.2 让甲方看到"成就感"

人只有看到成果，才有动力继续学。

每次优化后，让甲方的人亲眼看到效果提升：

• "你看，这个问题之前回答错了，现在对了！"

• "这周人工介入率又降了5%，你们的优化有效果！"

5.3 建立"内部专家"的荣誉感

让甲方的AI管理员成为公司里的"AI专家"：

• 在公司内部分享会上介绍智能体项目

• 让业务部门的人有问题就找TA

• 在优化成果中署名，让TA有成就感

做智能体项目，最难的不是技术，而是思维方式的转变。

从"消除bug"到"管理幻觉"，从"功能实现"到"效果达成"，从"交付即结束"到"交付才开始"——这些转变说起来容易，做起来需要整个团队的认知升级。

而项目赋能交付，是智能体项目成功的关键。乙方不要想着"一锤子买卖"，而要真心实意地教会甲方，让他们能自己玩起来。

只有这样，智能体项目才能真正落地、持续产生价值，而不是成为又一个"烂尾工程"。

如果你正在做智能体项目，或者准备转型做智能体项目，希望这篇文章对你有帮助。

欢迎留言交流你的经验和困惑，我们一起探索智能体时代的交付之道。