这段时间的AI项目做得多了反而越来越确认一件事真正让项目死掉的从来不是模型不够强、代码写不出来而是那些看起来“跟技术无关”的东西。我说的AI项目不是实验室里调参跑分的那种而是真刀真枪给业务方落地的系统。从需求沟通、数据梳理、流程确认到提示词调优、交付验收、上线运维一圈跑下来你会发现技术反而是一路绿灯的部分——模型能力不够就换思路报错了就改代码这些都是看得见摸得着的问题有解。真正让你卡在原地动弹不得的往往是需求方只说了一句“我想要个AI”然后就没有然后了是业务团队默认AI什么都知道是上线前没人说得清楚“什么样算做得好”。这篇文章不写模型原理也不给一行代码。我把这段时间踩过的坑、复盘过的项目、跟不同角色拉扯出来的经验按照项目推进的顺序梳理一遍。你会发现一个反直觉的事实AI项目能不能成在你动手调第一个接口之前就已经决定了七八成。1. 项目一开始就走进死胡同需求定义才是第一块绊脚石1.1 大多数AI项目不是“不会做”而是“说不清做什么”我接手过不少做到一半停摆的项目复盘下来发现一个共性启动时大家都默认“对方理解我的意思”。举一个很典型的例子。某团队的负责人跟我说要做一套“AI客服”。我问他这个AI客服是要完全替代人工还是辅助人工客户从哪个渠道进来问题范围有没有边界答不上来。再问如果AI答错了怎么办是需要人工兜底还是直接展示答案就好他愣了一会儿说这个还没想过。这不是少数现象而是大量AI项目的常态。业务方脑海里的“AI”是一团模糊的期待它应该能听懂人话、应该很聪明、应该能处理复杂情况。但落到项目层面连最基础的“输入输出边界”都没定技术团队就开始写代码了。等demo做出来业务方说不对我要的不是这个技术团队说你要的你说清楚啊。项目就在这种拉扯里耗到失去耐心。我把这类问题归类为“需求模糊三件套”输入不明确系统到底要读哪些数据数据从哪来、多久更新一次、谁负责维护输出不明确AI生成的结果是给人看的还是给系统用的答错了算事故还是算正常率内的波动边界不明确AI的能力上限在哪兜底机制是什么哪些情况必须转到人工这三个问题每一个都跟模型选型无关、跟prompt写法无关但每一个都能让项目进度归零。技术团队再厉害也猜不出业务方脑子里那张没画出来的流程图。1.2 六问快速验收需求跳过这个环节多半要返工我后来养成了强迫症般的习惯不管业务方多急正式动手前必须拉着业务方把下面六个问题过一遍。过完这六个问题项目能不能推进、风险在哪、谁该负责什么基本就有数了。谁用这个系统是内部员工还是客户他们的操作水平怎么样现状流程里最痛的是哪一步你要AI解决的是效率问题还是效果问题输入是什么谁提供如果数据拿不到有什么Plan B输出是什么用户拿到这个输出之后要做什么动作错了怎么办哪些错误可以接受比如摘要漏了一句话哪些绝对不能忍比如客服回复了错误承诺如果AI能力不够退路是什么是人工兜底还是换更简单的任务范围这六个问题问完通常会诞生两个结果。好的结果是双方终于对齐了彼此的理解项目范围从“做一套AI”收窄到“做一个工单分类助手”或者“做一份合同风险标注”。这样的项目哪怕技术含量一般也能顺利落地。坏的结果是业务方回答不上来——但这恰恰是好事因为总比你demo都做完了才发现基础需求不对要强。我见过太多项目团队上来就冲技术方案结果在需求这关偷的懒后面统统加倍还回来。改prompt是小事改数据链路是中等事改整个交互设计就是伤筋动骨的事。而这三样没一样是模型本身引起的。2. 模型选型与技术实现真正动手时反而很快2.1 模型能力都够用选型先看成本与交互方式聊一个经常被高估的环节模型选型。很多团队在选模型这事上特别焦虑今天听说A模型写代码强明天听说B模型推理好恨不得每个任务都用最强模型。但实际上绝大多数业务场景下主流模型的能力已经足够支撑了。真正拉开差距的不是那百分之几的准确率而是你有没有把任务定义清楚、把数据准备好、把输出校验做好。我自己的选型逻辑很简单按顺序回答下面几件事任务需要多长的上下文如果要把整本合同喂进去那长上下文是硬指标。对延迟的忍受度如何客服场景里用户等不了十秒钟调用大模型的成本就要让位于响应速度。数据能不能出域涉及核心生产数据的私有化部署或者自建模型是底线直接在公网调用就出局了。成本能不能覆盖每天几十万次调用跟每天几千次调用单位成本差一个量级选型方案完全不一样。这些问题也都不是性能问题是工程约束和商业约束。把约束条件列出来可选范围就缩得很小了。剩下的事情——调参数、写prompt、做评测——全是熟练工的活通宵加个班就能干出来。2.2 一个下午跑通原型的真实经历我说个具体的例子。有一天业务方扔过来一个需求每周要读五十篇行业报告整理成摘要和关键数据点。之前是两个人做一周累得不行还经常遗漏。我来之后整个原型搭建只花了一个下午。思路非常朴素PDF解析成文本按章节切分然后用模型的接口做分段摘要最后用一段汇总逻辑把所有分段摘要合并成一份完整报告。中间涉及的提示词并不复杂核心就两点明确告诉模型输出结构要求它每条摘要都标注对应的章节来源。跑通之后业务方看demo当场就确认了需求。之后一个月的时间主要花在什么上是处理各种格式奇怪的PDF、是让解析器兼容扫描件、是把输出格式跟内部系统对齐。这些工作没有一个是“训练模型”或者“研究算法”全是工程上和需求上的脏活。这个例子最能说明问题AI能力本身已经商品化了落后的生产流程、没有规范的数据、模糊的输出口径才是消耗你时间的黑洞。你以为你在做AI项目实际上你大部分时间在做数据清洗和业务梳理。2.3 技术中真正的坑在于“外部依赖”而非AI本身当然我不是说技术环节完全没有坑。技术上有一种很隐蔽的坑跟AI没有丝毫关系但足以让项目延期三个月——外部依赖。我做过的项目里出现过这些状况业务系统的API文档过期了对接文档里写的字段跟实际返回结构对不上排查了整整两天。数据权限没有打通算法那边已经把模型训练好了结果发现生产数据根本不能出业务部门。第三方审核流程要求所有对外生成的文本过一遍合规检查这一关让整个自动化流程的实时性大打折扣。这一类问题共同的特点是它们不可控而且往往在项目排期的时候没人想到。模型跑不动可以换模型prompt效果差可以迭代prompt但外部系统改不了接口、合规部门不给放权限、数据负责人调不出人手这些才是让你干着急却使不上劲的卡点。我的应对方式是极度的“依赖前置”正式开工前把项目涉及的所有外部依赖列一张清单标清楚“谁提供、什么时候提供、如果延期了有什么预案”。没有这张清单后期被外部节奏拖死的概率非常高。3. 提示词与工作流稳定输出的秘密藏在流程里3.1 提示词不是玄学是业务规则的转写说一个可能有点得罪人的观点市面上一半的“提示词工程课程”讲的东西都能压缩成三句话——写清楚背景、写清楚输入、写清楚输出格式。我早期也迷信过“黄金提示词”好像只要找到某个神奇的措辞模型输出质量就能突飞猛进。后来实测下来发现提示词写得再花哨不如把任务边界定义清楚。模型根本不在乎你是不是用了“让我们一步步思考”这种话术它在乎的是你到底要什么样的输出。直接给个我现在常用的模板你可以拿去改## 任务 你是一个[角色]。你的任务是在[输入内容]中提取[目标信息]。 ## 输入 输入内容 ## 要求 1. 只提取与[目标]相关的信息忽略无关内容。 2. 输出使用[JSON/表格/纯文本]格式。 3. 如果输入中没有相关信息输出“无”不要自行推断。 4. 每条输出必须附带对应的原文出处便于人工核验。 ## 示例 输入... 输出... ## 请按上述要求处理以下输入发现没有这个模板里没有一句“魔法咒语”全是业务流程里需要的约束提取什么、忽略什么、格式是什么、出错怎么办。与其说你在写提示词不如说你在把业务方脑子里的规则翻译成模型能听懂的话。提示词反复调整的本质也不是“调模型”而是把业务方自己都没想清楚的规则一步步逼问出来。3.2 上下文管理你在跟AI开会不是在跟它聊天跟大模型协作还有一个很容易踩的坑把对话当聊天。你连续对话了一百轮模型就把前面的内容都“记住”了——但这个“记住”是会衰减的而且一旦夹带了错误信息后面生成的内容会跟着一起跑偏。我在项目里被这个问题坑过一次。有个文本润色的场景模型在对话前段回答偏了方向我以为是prompt写得不好调了十几次都没用最后发现是上下文窗口里堆了一大堆历史消息模型被早期几轮对话带偏了。从那以后我定了一条规矩一个任务一个会话。会话结束就清空不让历史消息污染下一次调用。更长篇的任务则需要设计“工作流”而不是指望模型一口气做完。拿写行业报告举例我不让模型直接“写一份完整报告”而是拆成五个步骤从原始资料中提取关键事实形成要点列表。按报告大纲给要点分类。逐章节生成内容每章独立对话。人工审阅后把修改意见反馈进对应章节。最后统一汇总成终稿。每一步的输出都是下一步的输入中间随时能插入人工检查。这套流程听起来很朴素但它的价值在于你永远知道模型在哪一步出了错而不是等一份五十页的报告生成完才发现方向全错了。3.3 评价口径先行没有打标就没有优化提示词和工作流都只是手段真正让项目进入正循环的是你怎么定义“好”。很多AI项目在没有明确评价标准的情况下就上线了。结果就是每次跟业务方开会对方都能挑出几个毛病但又给不出系统性的修改意见。技术团队也委屈因为不知道按什么优先级去改。最后项目变成了一场漫长的扯皮。要破解这个僵局最好的办法是上线前就建立一套“人工评估集”。具体做法是从真实业务数据里抽五十到一百条样本覆盖常见情况、边界情况、易错情况。团队和业务方坐在一起逐条把标准答案定出来。对是逐条写花时间但极其值。每次改动提示词或调整模型都拿这批样本回归一遍。这个评估集的价值怎么强调都不过分。它把“这个summary不好”这种没法落地的抱怨变成了“这批样本里有八条答案跑偏了集中在数字准确性上”这种可以定位、可以修复的具体问题。而且建立评估集这个动作本身就是一次需求对齐——业务方在打分的过程中才会真正意识到AI的能力边界在哪里知道哪些期待是不现实的。4. 跨部门协作与预期管理AI项目的隐藏杀手4.1 老板要的是“魔法”交付的是“算力即服务”的日常在这个行业里待久了你会发现很多AI项目立项时的预期就是错的。某个项目启动会上销售拍着胸脯说这套系统能“全自动处理所有咨询不需要人工介入”老板听着开心当场拍板。等项目做到验收阶段技术团队拼死拼活实现了80%的自动处理率剩下20%必须人工兜底。老板一看说这不行说好了全自动的。项目被判为“失败”。你说这项目技术上成功吗成功率80%已经是很不容易的成果了。但预期管理失败项目就失败。这个锅不在技术团队而在最早把那句“全自动”说出口的销售。后来我做项目养成一个习惯所有对外沟通口径都必须经过技术团队确认。销售跟客户承诺了什么白纸黑字写出来如果写出来的东西技术做不到当场就指出。宁可前期跟销售吵一架也不要等项目交付的时候跟客户吵一架。预期管理的原则很简单也很残酷永远让预期低到你能超额完成而不是高到你拼命也够不着。AI项目尤甚因为“AI能做到什么程度”这件事外行几乎没有任何体感你承诺的每一个“全自动”都会被理解成“永远不用人管”。4.2 业务方觉得“AI应该什么都知道”但AI其实只知道它读到的东西跨部门协作里最常见的冲突来自业务方对AI知识来源的误解。我做过一个内部知识库问答的项目。业务方头头是道地以为系统上线之后员工问什么它都能答包括那些写在同事邮件里、存在个人电脑里、从没进过知识库的经验。结果系统上线第一天就被吐槽“这也不知道那也不知道还不如问老同事。”这就是典型的“AI不知道它不知道什么”。模型的训练数据不可能包含你公司的内部制度你部署的知识库索引里有什么它就只能答什么。你以为你在做一个AI项目实际上你在做的是一个知识库治理项目——你得先把散落各处的文档收集起来、清洗干净、打上标签、建好权限AI只是最后那层问答界面。我给出一个务实的三件套清单准备做知识库问答项目的人可以直接抄知识来源清单明确哪些文档必须收录哪些不用谁负责定期更新。权限映射表哪些内容谁能看AI回答时如何处理权限边界。兜底话术知识库里找不到答案时系统应该怎么答是道歉、是转人工、还是给一个模糊的引导。这三件事情都做完了知识库问答的项目才真正有启动基础。任何一件缺了后面上线时都会被业务方用“AI怎么这个都不知道”一句话打回原形。4.3 协作转起来的关键让业务方自己完成一次闭环跨部门协作卡住的时候我通常不是开更多的会而是邀请业务方一起做一次“真实任务演练”。什么叫真实任务演练就是拉一个会议室让业务方从自己的日常任务里挑一件事当着技术团队的面用现在的系统demo跑一遍。业务方亲手输入数据、亲眼看到输出结果、自己判断这个结果能不能用。为什么这个方法有效因为一旦业务方亲手操作大量的隐性需求就暴露出来了。他会发现原来输入数据的格式这么麻烦原来生成的结果还需要人工校对原来整个流程比想象中要复杂得多。这个过程比十次会议都管用——从“你们技术怎么做得这么差”变成“原来我不了解这里面的细节”。我印象最深的一次业务方全程参与完演练之后当场把原本极其复杂的需求砍掉了一半。她说“我原来以为AI能一步到位现在看能把第一步做好就不错了。”项目范围缩小交付质量反而大幅提升。这就是预期管理的终极形态让相关方在真实体验中自己调整预期而不是靠你去解释。5. 打磨与交付离用户期望差的那一公里不是模型能力5.1 从“结果对”到“体验对”中间隔着一整套工程细节做了几个完整交付项目之后我最大的感受是模型给出的答案“内容正确”离用户觉得“好用”中间还隔着一大段距离。举几个交付阶段经常被忽略的细节生成速度模型思考五秒钟给出完美答案和两秒钟给出基本可用答案用户体感天差地别。五个项目里至少有三个要求我必须对流式输出也就是让用户看到字一个一个蹦出来。哪怕总等待时间没变这种“正在输出”的状态本身就压住了用户的焦躁感。错误状态直接报错“服务异常”是最差的设计。稍好一点的设计是给用户一个兜底话术告诉他“我正在联系人工处理”。更好的设计是你从一开始就在架构里埋好人工接管开关——AI答不上来的场景自动转给人工用户在不知不觉间丝滑切换。加载提示没有提示的等待是焦虑有进度反馈的等待是安心。一个看似不起眼的loading图标往往决定了用户第一次使用的好感度。这些细节没有一样跟模型选择有关也没有一样跟prompt技巧有关。它们是工程经验是产品素养是你在项目交付阶段最应该花时间的地方。5.2 观测成为刚需AI项目尤其要留指标的余地如果说传统软件项目是“上线就完成”AI项目就是“上线才开始”。原因很直接模型的行为不是你写的代码你没法保证它在生产环境里的每一次表现都跟测试时一致。所以观测指标必须在设计阶段就留好位置。我做AI项目的时候不管业务方要不要都会先铺这几类日志成本日志每次调用的token数、单次成本、日均消耗。没有这个数据模型上线后成本失控你连预警都来不及。延迟日志调用耗时分布、P95延迟。业务方说“系统变慢了”的时候你至少能用数据定位是网络问题、模型问题还是并发问题。质量抽检人工评估集的分数走势、用户反馈的标星比例。这个指标最软但最能反映真实体验。异常兜底率系统转人工的比例。这个数字如果突然飙升通常不是系统坏了就是业务数据出了变化。这些日志不需要一开始做得特别花哨但必须留接口。很多项目上线半年之后业务方跑过来说“感觉最近生成质量下降了”你手上连一个数据点都没有就只能凭感觉猜。AI项目的运维本质上是靠数据驱动而不是靠感觉驱动。5.3 上线只是起点模型更新和提示词改动都需要版本意识最后一个项目收尾时最容易被忽略的坑AI系统的持续维护。传统软件开发里代码是有版本管理的但到了AI项目很多团队的提示词是在对话里直接改的模型版本也是说来就来换一个接口就换一个接口。时间一长生产环境的模型从哪个版本换到了哪个版本提示词从哪一版迭代到了哪一版没人说得清。这带来的影响是一旦线上效果出现波动你连“是什么变化导致的”都定位不了。可能是模型厂商静默更新了底座可能是你的提示词被某位同事顺手改了一句话也有可能是业务数据分布变了。没有版本记录排查只能靠猜。我的建议是三个“必须”所有调用必须带模型版本号方便日志回溯。所有提示词改动必须走统一的发布流程改动前保存快照。所有输出必须记录当时的模型和提示词版本存在日志里。这套机制不需要特别复杂的平台支撑一张电子表格加一点日志埋点就够了。但有了它线上出问题的时候你能在十分钟内定位到改了什么而不是在钉钉群里翻聊天记录找“谁动过提示词”。最后再分享一点个人体会这段时间跑了这么多AI项目我最深的体会是AI项目本质上是一场关于“共识”的工程。你跟模型之间的共识靠prompt对齐你跟业务方之间的共识靠需求评审对齐你跟协作部门之间的共识靠流程和预期管理对齐。共识对齐了模型能力反而不是瓶颈随便用哪个模型都能把事干成。共识没对齐哪怕用最强模型也只会生成出业务方不想要、技术团队不甘心的废品。所以你现在要做一个AI项目我建议你第一件事不是去注册模型接口也不是去研究提示词而是拉上业务方花一上午时间把那个“六问清单”过一遍。把你听懂的东西写下来发给对方确认签字画押。等这份确认过的需求文档压在桌上——再打开代码编辑器。你会发现后面的路比你想的顺畅得多。