这段时间的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项目，我建议你第一件事不是去注册模型接口，也不是去研究提示词，而是拉上业务方，花一上午时间把那个“六问清单”过一遍。把你听懂的东西写下来，发给对方确认，签字画押。等这份确认过的需求文档压在桌上——再打开代码编辑器。你会发现后面的路，比你想的顺畅得多。
