从“再优化一下”开始，AI 项目就很难结束了
做 AI 项目越久，我越觉得，自己以前对“现场实施”这件事的理解可能有点过于理想化。
我以前一直觉得，现场实施应该是一件很明确的事情。
公司总部先提供一套基础可用的产品。这里的“可用”不代表一定多先进，也不要求什么能力都做到行业顶尖，但至少核心功能得是完整的、稳定的、经过验证的。
知识库能不能用，文件解析能不能跑，通用问答到底适合什么场景，Agent 能做到什么程度，这些东西总部自己应该先心里有数。
然后销售和售前基于这些已经验证过的能力去谈项目。
客户有需求，可以定制，可以适配，也可以在现有能力上做一定程度的扩展，但前提应该是：这个东西公司知道怎么做，技术上验证过，也知道最后怎么验收。
而不是销售为了把单子签下来，先把能力吹出去。
“这个可以。”
“那个也能做。”
“AI 很智能的。”
最后合同签完，项目进场，真正开始做的时候才发现：
这个产品其实根本没有这个能力。
这个需求以前也没人做过。
这个所谓的“标准能力”只是 Demo 跑通过。
甚至连最后做到什么程度算完成，都没人知道。
然后现场就开始了真正意义上的擦屁股。
我以前理解的现场，应该更多负责部署、系统对接、小功能定制和环境适配。
比如客户那边有一套内部系统，需要接接口；或者他们的文件格式比较特殊，需要做一点解析适配；再或者某些场景的 Prompt、检索策略需要根据业务稍微调一下。
这些我觉得都很正常。
因为现场最接近客户，本来就应该承担最后一公里的工作。
甚至现场发现产品有问题，我也觉得正常。
比如知识库召回有问题、PDF 解析效果不好、模型回答某一类问题经常出错。
现场收集日志、收集 Case、分析原因，然后反馈给总部。
总部研发再根据这些真实问题改产品，发一个新的版本回来，现场继续验证。
如果来回几轮以后，效果达到合同里提前约定好的标准，那项目就结束。
我原来一直以为，正常的 AI 项目应该是这么推进的。
后来才发现，现实可以完全反过来。
最开始基线产品本身就不好用。
合同里的能力，也不一定真的经过技术团队验证。
很多时候就是销售为了签单，先答应下来。
等真正进场以后，现场才第一次认真思考：
这个东西到底该怎么做？
于是现场开发慢慢就不再是“实施”。
你开始做产品设计。
做技术选型。
补底层能力。
和客户梳理需求。
甚至帮客户想，他真正需要的东西到底是什么。
有时候挺荒谬的。
客户自己也不知道自己想要什么。
他只是觉得：
这个不行。
那个不好用。
这个怎么不够智能？
你能不能像某某产品一样？
于是你做一版。
客户用了两天，说这里还差一点。
你再改。
然后客户又发现另外一个场景满足不了。
继续改。
慢慢地你就会发现，这种需求其实是没有终点的。
尤其是 AI 项目。
传统软件至少很多东西比较明确。
一个按钮有没有。
一个流程能不能走通。
一个接口有没有返回。
这些都比较容易定义。
但 AI 不一样。
“回答得好不好”，本身就是一个很模糊的事情。
同一句回答，在一个人看来可能已经够用了，另一个人可能觉得完全不行。
知识库也一样。
到底什么叫知识库效果好？
是不是每个问题都能找到正确答案？
那碰到文档本身没有答案怎么办？
碰到问题表达模糊怎么办？
碰到需要跨文档推理怎么办？
碰到用户上传文件以后，又希望系统自动结合知识库怎么办？
再往下，就会一路走到 Agent、Memory、规划、工具调用、多轮任务。
这时候“效果问题”和“功能问题”的边界其实已经开始消失了。
客户说：
“这个问题为什么回答不了？”
技术上可能不是模型回答错了。
而是这个问题本来就需要系统先查文件，再查知识库，再做一次推理。
那到底算“效果不好”，还是“缺一个多步规划功能”？
很难说。
而一旦项目一开始没有明确的验收标准，后面就会非常危险。
客户只需要说一句：
“这个效果我们不能接受。”
乙方就会继续退。
因为项目要验收。
现场想撤。
领导也想把项目关掉。
于是原来不属于当前范围的东西，也开始往里加。
本来只做固定工作流。
后来变成自主规划。
本来只是知识库。
后来要加记忆。
本来只支持文本。
后来图片、表格、扫描件也全都要。
最后每一个问题看起来好像都合理。
但所有合理的问题加在一起，就是一个没有边界的系统。
所以现在我越来越觉得，一个真正好的 AI 项目，最重要的可能根本不是用了什么模型，也不是用了什么框架。
而是这个项目有没有边界。
总部知不知道自己的产品到底能做到什么。
销售知不知道什么东西不能乱承诺。
客户知不知道最后应该用什么标准判断项目完成。
项目中途如果需求变化了，有没有人敢说：
“这个已经不是优化了，这是一个新的能力，需要重新评估。”
我幻想中的优质项目，其实也没有那么完美。
产品可以有 Bug。
知识库效果也可以不好。
客户当然也可以改需求。
AI 本身也一定会存在大量不可控的问题。
这些我都能接受。
我不能接受的是，所有这些不确定性最后全部变成：
“现场你想办法解决一下。”
真正健康的状态应该是：
客户提供真实业务问题。
现场负责理解和定位。
总部负责产品和技术方案。
大家一起用真实 Case 验证。
哪些做到了，哪些没做到，原因是什么，都说清楚。
达到双方提前约定的标准以后，就验收。
剩下的需求进入下一阶段。
而不是一个项目永远处于：
“再优化一下。”
“再改一点。”
“这个应该也能支持吧？”
这种状态里。
我以前以为现场实施的价值，是连接产品和客户。
现在越来越觉得，一个不成熟的公司里，现场实施更像是一块缓冲垫。
销售吹出去的能力，它来补。
产品没做完的能力，它来补。
项目管理没挡住的需求，它来补。
客户模糊的想法，它也得想办法落地。
最后所有人的风险，都一路传递到现场。
然后现场的人开始怀疑：
是不是自己能力不够？
是不是自己还应该再多做一点？
但后来想想，其实很多时候根本不是技术问题。
只是这个项目从一开始，就没有设计好应该怎么结束。
所以如果以后再让我判断一个 AI 公司或者 AI 项目靠不靠谱，我可能不会先问：
“你们用什么模型？”
“你们 Agent 做得怎么样？”
我反而更想问：
合同里的能力是谁评审的？
项目验收标准是谁定的？
客户中途加需求怎么办？
总部和现场的边界是什么？
如果线上效果不好，是现场自己改，还是总部有人负责？
因为技术差一点，其实还能慢慢补。
但如果公司从销售到交付都没有边界意识，那现场最后一定会变成无底洞。
我现在所谓“理想中的 AI 项目”，说到底其实也没什么特别高的要求。
我只是希望：
产品不一定完美，但至少能用。
需求不一定不变，但变了有人管。
客户可以不满意，但得说清楚哪里不满意。
现场可以解决问题，但不用替整个公司兜底。
而项目最重要的一点是——
大家都知道，做到什么程度以后，这件事就算结束了。
#项目现场
