最近半年我面试了不少简历上写满大模型项目经验的候选人也在内部分享评审时看过大量AI应用Demo一个反复出现的画面让我很不踏实理论说得头头是道现场却交付不出一个能验收的应用。你问“RAG流程怎么设计”他能从文本切分讲到向量检索再讲到重排序你问“系统上线后首响延迟多少、召回率怎么标的、检索失败怎么兜底”他支支吾吾。这不是某个人的问题而是这个行业正在批量制造的一种八股文——背了很多理论却没有把理论变成可验收系统的能力。这篇文章我想认真聊聊这个问题聊聊为什么“背一百个理论不如交付一个能验收的应用”。大家先别急着反驳我并不是说理论不重要。没有Transformer就没有今天的大模型没有Attention机制就没有RAG的合理性。我想说的是理论是地图交付是走路。地图画得再漂亮腿脚不动到不了目的地。在AI应用开发、AI Agent、模型部署这些具体场景里真正卡住团队的往往不是概念不懂而是交付能力跟不上。这篇主要写给正在做AI应用开发的产品经理、研发工程师以及想入行AI编程的新人希望能帮大家把注意力从“背概念”拉回到“做交付”上。1. AI 八股文的病根理论正确不等于交付正确1.1 “术语复读机”制造了虚假熟悉感AI这行最近一年冒出了一套新八股简历上写“精通大模型提示词工程”“熟悉RAG检索增强生成”“主导过Agent系统开发”答辩时术语一个接一个往外蹦从“幻觉”到“上下文窗口”再到“多智能体协作”听起来非常专业。可只要追问一句“你负责的Agent系统Tool调用失败时的重试策略是什么评测集有多少条核心指标是多少”——会议室经常瞬间安静。这不是个别案例。我过去半年参与了50多个AI项目的评审和面试简历里提到“RAG”“Agent”“微调”等热词的比例超过八成但能明确说出自己应用验收指标比如回答准确率、首响延迟、召回率、兜底策略的不足两成。大量项目停留在“教程跑通”阶段照着LangChain的官方案例改一改用Streamlit套个界面就算“完成”了。这种虚假熟悉感非常害人因为它让从业者误以为自己掌握了AI工程能力实际上连最基本的工程约束都没碰过。1.2 理论正确与工程正确是两套逻辑为什么会出现这种八股文我自己的体会是理论语境和工程语境之间存在严重错位。理论告诉你“RAG可以缓解幻觉”但它不会告诉你知识库源文件可能是扫描版PDF解析出来是一堆乱码理论告诉你“向量检索能找相似内容”但它不会告诉你用户提问的表述和文档原文差异很大时Top5召回可能一条都用不上理论告诉你“大模型有强大推理能力”但它不会告诉你在业务系统里模型输出并不稳定你需要设计校验、回退和人工兜底。理论回答的是“能不能”工程回答的是“稳不稳、准不准、贵不贵、可不可维护”。很多技术讨论都停在第一层反复争论不同模型的Benchmark分数、不同框架的抽象设计却很少聊数据清洗怎么处理、评测集怎么构建、效果回归怎么做、延迟和成本怎么平衡。后面这几个问题才是决定一个AI应用能不能真正落地的关键也是“能验收”这三个字的真正含义。2. 能验收的应用才是检验AI能力的硬标准2.1 “Demo能跑”和“应用能验收”之间存在巨大鸿沟我相信不少人都见过这样的场景开发同学花两周做了一个AI应用Demo演示时效果惊艳完美回答了几个精心挑选的问题领导当场点头。结果一放开真实流量用户问法稍有变化系统就答非所问甚至直接报错。Demo和应用之间差的不是一个措辞而是一整套工程保障。我习惯用一个简单的标准来判断一个AI应用是否“可验收”它有没有明确的输入边界、输出形式、质量指标和运行环境。比如一个制度问答助手输入是员工的自然语言问题输出是带引用来源的回答质量指标是Top5召回率不低于85%、回答准确率不低于90%、首响延迟不超过3秒运行环境是内部服务器或云环境还要具备日志追踪、失败兜底、人工反馈通道。只要有一条说不清或做不到这个应用就没有真正交付。2.2 从“我知道”到“我交付过”需要跨过四个台阶结合这两年做AI应用、带团队、评审项目的经验我把AI工程能力分成四个台阶大家可以对照自测一下台阶能力表现典型输出第一台阶能跑通本地Demo能完成一次对话或生成第二台阶能验收达到可量化的质量指标有评测集和测试记录第三台阶能运维部署上线有监控、日志、告警、降级与回滚第四台阶能演进有数据回流、评测回归、版本迭代机制绝大多数“八股文型选手”停在第一台阶少数团队勉强够到第二台阶而AI Agent、AI编程这类热词真正产生价值的地方在第三和第四台阶。我见过不少团队用很复杂的Agent框架搭了一个华丽的系统最后被运维环节击穿——API Key过期没人管、模型调用成本暴涨没人预警、用户反馈没有收集入口。所以我在内部常说一句话先别管Agent还是Workflow先把一个应用的“验收底线”立住再谈更高级的架构。3. 一个反八股样本制度问答助手的验收式开发为了把上面的观点说得更具体我拆解一个我们实际做过的项目企业内部制度问答助手。它的目标是让员工用自然语言提问比如“年假可以分几次休完”“差旅费报销需要什么发票”系统基于制度文档库给出准确回答并且每条回答都附带引用来源。这个项目不算前沿但足够典型它几乎涵盖了AI应用开发里所有关键环节。3.1 先用验收标准倒推需求而不是先选模型这个项目启动时我们做的第一件事不是选大模型而是写验收标准。产品、研发、业务方一起开了一上午会把“什么叫做好用”拆成了四个可量化指标召回率在预置的200条测试问题上系统正确召回目标文档的比例不低于85%。回答准确率回答内容与制度原文一致且无编造由业务专家抽评准确率不低于90%。首响延迟接口从收到请求到返回完整回答P95不超过5秒。引用可追溯所有回答必须给出文档标题和原文段落链接引用缺失视为不合格。这四条一出来很多方向性讨论立刻有了结论。比如为什么不做多轮复杂对话因为验收指标里没有这一条初期做了反而分散精力为什么先不用复杂的Agent框架因为固定流程足够满足当前指标Agent带来的不确定性在验收阶段是负担。3.2 技术选型的克制向量库加固定RAG流程就够了这个项目的技术栈后来收敛到一个开源的Embedding模型做文本向量化一个内部部署的向量数据库做检索一个大模型做生成中间用固定的RAG流程串起来。最前面加了一个查询改写模块用于处理“年假有啥规定”和“我今年还能休几天年假”这类不同粒度的问题。这个选型在很多人看来可能太朴素了但我的经验是在AI应用里“够用且可控”远比“酷炫且不可控”重要。先说为什么需要查询改写。制度文档里的原文往往是“职工累计工作已满1年不满10年的年休假5天”而员工的实际问法是“我工作3年了有几天年假”两者的语义距离很远直接做向量检索会漏召回。我们在前面加了一层轻量改写先用大模型把口语化问题改写成标准查询同时提取关键实体工龄、假期类型再做检索。这个模块不复杂但把召回率从72%提升到了84%。再说不使用复杂Agent框架的原因。市面上很多Agent框架把编排、工具调用、记忆、多轮规划都打包好学习成本和排错成本都很高。在我们的场景里核心链路是“改写—检索—重排—生成”这条链路用几百行代码就能串起来出问题时也容易定位。等到场景复杂度真正上来了比如需要多工具协同、动态规划、用户多轮澄清时再引入Agent能力不迟。而且那时候你有评测集和监控日志在手上改造起来有据可依。3.3 理论没告诉你的三个落地坑这个项目做下来有三个坑我在绝大多数AI理论文章里都没见过但每一个都差点让项目延期。第一个坑是源文档解析。制度文档里有大量PDF其中一部分是扫描件还有大量表格和页眉页脚。直接解析后拿去切分会得到一堆乱码和残缺表格。我们最后用OCR加版面分析工具先把PDF转成带结构信息的内容再做清洗和分段。光这一项就花了两周。这个工作听起来没有一点技术含量但它决定了整个检索效果的上限。第二个坑是评测集的构建。很多团队先写功能后补评测这是完全反的。我们的做法是先整理200条真实问题覆盖高频场景和易错场景然后逐条标注对应的标准答案和来源文档。整个过程很费人力但评测集是整个项目的锚点后面无论换模型、调切分参数、改Prompt都跑一遍这200条用数据说话。没有评测集的时候优化完全是玄学有了评测集优化就从经验驱动变成数据驱动。第三个坑是幻觉控制的工程化手段。验收标准里“回答必须引用原文”这一条靠Prompt提示是做不到100%的。我们加了两个机制一是生成时把检索到的原文片段一起传给大模型并要求输出引用编号二是后置校验——如果回答里的关键信息在召回文档里找不到对应文本就把答案降级为“抱歉我没有在制度库中找到相关内容”。这个兜底机制比任何Prompt技巧都管用。3.4 验收不是一次性的它是一套持续动作项目交付当天我们给业务方做了一次现场验收现场提出20个新问题系统实时回答由业务专家判断对错。结果19个回答正确1个回答因为检索到相似但过时的制度版本而出现了偏差。当场我们就把这个问题记入评测集并在检索环节增加了版本过滤条件。这件事体现了“能验收”的真正含义验收不是一个终点动作而是一套持续的质量保障机制。上线后我们还接入了日志和反馈渠道每个回答下方有“有帮助/没帮助”按钮每周汇总一次失败Case并补充进评测集。第二个月我们的测试问题集从200条扩展到350条回答准确率和召回率都在这个过程中持续提升。这个闭环恰恰是很多理论博客不会写、但AI真实场景里最值钱的部分。4. 摆脱八股文真正值得投入的四个实践方向4.1 先写评测集再写功能如果你正在做一个AI应用我给的最实在的一条建议就是动手写第一行功能代码之前先花时间写评测集。哪怕一开始只有几十条也好过没有。评测集就是AI开发的单元测试它让你每次改动都有了一个客观的反馈信号。我在制度问答项目里吃过这个亏后来所有项目都先建评测集这个习惯帮我避开了无数“感觉效果好了实际效果却飘忽不定”的困境。评测集不用一开始就很完美关键是真实。可以从三类问题入手一是最高频的问题二是最容易答错的边界问题比如“请假超过三天需要谁审批”三是历史上真实出现的Bad Case。每次模型升级、框架变更、Prompt调整都全量跑一遍人工抽评变化点。长期来看这是投入产出比最高的AI工程投资。4.2 从固定流程到Agent走一条渐进路线AI Agent是今年最热的概念之一但我的看法可能跟很多人不同绝大多数业务场景起步阶段都应该用固定流程而不是Agent。固定流程的每一步都是确定性的改了哪个环节、影响哪条路径一目了然。当固定流程跑到瓶颈且瓶颈确实来自流程死板、缺乏决策弹性时才值得把特定环节替换成Agent化设计。具体来说可以先固定“改写—检索—重排—生成”这条主链路把每个环节做成独立模块并给每个模块配置日志和评测。然后观察哪一步最不灵活比如查询改写对长尾问题处理不好就可以把改写模块从“固定Prompt”升级成“带少量工具选择的Agent”让它自己决定改写还是直接检索。这种渐进式的Agent化既拥抱了热词背后的技术价值又不会被复杂框架绑架。4.3 把AI基础设施和可观测性当一等公民“AI infra”“模型部署”这两个方向最近热度很高这其实说明行业正在成熟。再强大的模型、再聪明的Agent跑在不可观测的基础设施上都无法长期稳定服务。我见过不少团队在演示时效果一流可对首响时间、Token成本、API失败率、上下文长度膨胀这些问题完全没有感知直到线上出故障才发现日志都没接。我的建议是AI应用从第一天就要有结构化日志记录每次请求的输入、检索结果、生成结果、延迟、Token用量性能监控重点关注P95延迟和成本趋势失败告警调用失败、空检索、连续降级等场景都要有告警反馈闭环用户侧的有用和无用反馈能回流到评测集。这套东西跟业务代码一样重要。很多博客爱讲“提示词工程有多精妙”却很少讲这些基础设施但恰恰是它们决定了AI应用能不能活得久。4.4 让AI编程回归“交付”本质今年“AI编程”也是个大热词各种提示词模板满天飞教你怎么让AI帮你写代码。我的观点是AI编程的本质不是背提示词而是利用AI加速从需求到可交付应用的路径。真正高效的AI编程是你已经清楚知道自己要交付什么、验收标准是什么然后用AI把重复性、机械性的编码工作快速完成。举个例子在制度问答项目中我们用AI辅助生成了大量数据清洗脚本和接口测试用例足足节省了将近一周的时间。但前提是我们自己很清楚清洗规则和测试预期是什么。如果对需求本身一知半解把希望完全寄托在AI生成上结果就是在不确定的地基上盖楼。所以AI编程和“能验收的应用”是互相成就的交付目标越清晰AI辅助效果越好AI辅助越快交付速度越快。5. 收尾把“能验收”变成肌肉记忆5.1 评审AI项目时我只认验收单最后再分享一点我在实际带项目过程中的体会。我现在评审一个AI项目基本不看PPT和架构图就要一张验收单上面写清楚三件事输入是什么输出是什么达到什么标准算通过。凡是能当场拿出这份单子并且数据齐全的团队项目大概率不会差凡是讲了半小时概念还说不清验收标准的哪怕名词用得多漂亮我都要打个问号。5.2 放下理论焦虑做一个小而真的应用这篇文章是“反对AI八股文”系列的第一篇核心就一条背一百个理论不如交付一个能验收的应用。这个系列后面我还会接着写聊一聊具体怎么拆解需求、怎么设计评测集、怎么在成本和效果之间做取舍。如果你正被海量AI概念和框架弄得焦虑我的建议很简单——放下那些论文和框架文档找一个具体而真实的小场景定一个可量化的验收指标把它交付出来。做完一个这样的应用比背一百个理论都管用。
背一百个理论不如交付一个能验收的AI应用
最近半年我面试了不少简历上写满大模型项目经验的候选人也在内部分享评审时看过大量AI应用Demo一个反复出现的画面让我很不踏实理论说得头头是道现场却交付不出一个能验收的应用。你问“RAG流程怎么设计”他能从文本切分讲到向量检索再讲到重排序你问“系统上线后首响延迟多少、召回率怎么标的、检索失败怎么兜底”他支支吾吾。这不是某个人的问题而是这个行业正在批量制造的一种八股文——背了很多理论却没有把理论变成可验收系统的能力。这篇文章我想认真聊聊这个问题聊聊为什么“背一百个理论不如交付一个能验收的应用”。大家先别急着反驳我并不是说理论不重要。没有Transformer就没有今天的大模型没有Attention机制就没有RAG的合理性。我想说的是理论是地图交付是走路。地图画得再漂亮腿脚不动到不了目的地。在AI应用开发、AI Agent、模型部署这些具体场景里真正卡住团队的往往不是概念不懂而是交付能力跟不上。这篇主要写给正在做AI应用开发的产品经理、研发工程师以及想入行AI编程的新人希望能帮大家把注意力从“背概念”拉回到“做交付”上。1. AI 八股文的病根理论正确不等于交付正确1.1 “术语复读机”制造了虚假熟悉感AI这行最近一年冒出了一套新八股简历上写“精通大模型提示词工程”“熟悉RAG检索增强生成”“主导过Agent系统开发”答辩时术语一个接一个往外蹦从“幻觉”到“上下文窗口”再到“多智能体协作”听起来非常专业。可只要追问一句“你负责的Agent系统Tool调用失败时的重试策略是什么评测集有多少条核心指标是多少”——会议室经常瞬间安静。这不是个别案例。我过去半年参与了50多个AI项目的评审和面试简历里提到“RAG”“Agent”“微调”等热词的比例超过八成但能明确说出自己应用验收指标比如回答准确率、首响延迟、召回率、兜底策略的不足两成。大量项目停留在“教程跑通”阶段照着LangChain的官方案例改一改用Streamlit套个界面就算“完成”了。这种虚假熟悉感非常害人因为它让从业者误以为自己掌握了AI工程能力实际上连最基本的工程约束都没碰过。1.2 理论正确与工程正确是两套逻辑为什么会出现这种八股文我自己的体会是理论语境和工程语境之间存在严重错位。理论告诉你“RAG可以缓解幻觉”但它不会告诉你知识库源文件可能是扫描版PDF解析出来是一堆乱码理论告诉你“向量检索能找相似内容”但它不会告诉你用户提问的表述和文档原文差异很大时Top5召回可能一条都用不上理论告诉你“大模型有强大推理能力”但它不会告诉你在业务系统里模型输出并不稳定你需要设计校验、回退和人工兜底。理论回答的是“能不能”工程回答的是“稳不稳、准不准、贵不贵、可不可维护”。很多技术讨论都停在第一层反复争论不同模型的Benchmark分数、不同框架的抽象设计却很少聊数据清洗怎么处理、评测集怎么构建、效果回归怎么做、延迟和成本怎么平衡。后面这几个问题才是决定一个AI应用能不能真正落地的关键也是“能验收”这三个字的真正含义。2. 能验收的应用才是检验AI能力的硬标准2.1 “Demo能跑”和“应用能验收”之间存在巨大鸿沟我相信不少人都见过这样的场景开发同学花两周做了一个AI应用Demo演示时效果惊艳完美回答了几个精心挑选的问题领导当场点头。结果一放开真实流量用户问法稍有变化系统就答非所问甚至直接报错。Demo和应用之间差的不是一个措辞而是一整套工程保障。我习惯用一个简单的标准来判断一个AI应用是否“可验收”它有没有明确的输入边界、输出形式、质量指标和运行环境。比如一个制度问答助手输入是员工的自然语言问题输出是带引用来源的回答质量指标是Top5召回率不低于85%、回答准确率不低于90%、首响延迟不超过3秒运行环境是内部服务器或云环境还要具备日志追踪、失败兜底、人工反馈通道。只要有一条说不清或做不到这个应用就没有真正交付。2.2 从“我知道”到“我交付过”需要跨过四个台阶结合这两年做AI应用、带团队、评审项目的经验我把AI工程能力分成四个台阶大家可以对照自测一下台阶能力表现典型输出第一台阶能跑通本地Demo能完成一次对话或生成第二台阶能验收达到可量化的质量指标有评测集和测试记录第三台阶能运维部署上线有监控、日志、告警、降级与回滚第四台阶能演进有数据回流、评测回归、版本迭代机制绝大多数“八股文型选手”停在第一台阶少数团队勉强够到第二台阶而AI Agent、AI编程这类热词真正产生价值的地方在第三和第四台阶。我见过不少团队用很复杂的Agent框架搭了一个华丽的系统最后被运维环节击穿——API Key过期没人管、模型调用成本暴涨没人预警、用户反馈没有收集入口。所以我在内部常说一句话先别管Agent还是Workflow先把一个应用的“验收底线”立住再谈更高级的架构。3. 一个反八股样本制度问答助手的验收式开发为了把上面的观点说得更具体我拆解一个我们实际做过的项目企业内部制度问答助手。它的目标是让员工用自然语言提问比如“年假可以分几次休完”“差旅费报销需要什么发票”系统基于制度文档库给出准确回答并且每条回答都附带引用来源。这个项目不算前沿但足够典型它几乎涵盖了AI应用开发里所有关键环节。3.1 先用验收标准倒推需求而不是先选模型这个项目启动时我们做的第一件事不是选大模型而是写验收标准。产品、研发、业务方一起开了一上午会把“什么叫做好用”拆成了四个可量化指标召回率在预置的200条测试问题上系统正确召回目标文档的比例不低于85%。回答准确率回答内容与制度原文一致且无编造由业务专家抽评准确率不低于90%。首响延迟接口从收到请求到返回完整回答P95不超过5秒。引用可追溯所有回答必须给出文档标题和原文段落链接引用缺失视为不合格。这四条一出来很多方向性讨论立刻有了结论。比如为什么不做多轮复杂对话因为验收指标里没有这一条初期做了反而分散精力为什么先不用复杂的Agent框架因为固定流程足够满足当前指标Agent带来的不确定性在验收阶段是负担。3.2 技术选型的克制向量库加固定RAG流程就够了这个项目的技术栈后来收敛到一个开源的Embedding模型做文本向量化一个内部部署的向量数据库做检索一个大模型做生成中间用固定的RAG流程串起来。最前面加了一个查询改写模块用于处理“年假有啥规定”和“我今年还能休几天年假”这类不同粒度的问题。这个选型在很多人看来可能太朴素了但我的经验是在AI应用里“够用且可控”远比“酷炫且不可控”重要。先说为什么需要查询改写。制度文档里的原文往往是“职工累计工作已满1年不满10年的年休假5天”而员工的实际问法是“我工作3年了有几天年假”两者的语义距离很远直接做向量检索会漏召回。我们在前面加了一层轻量改写先用大模型把口语化问题改写成标准查询同时提取关键实体工龄、假期类型再做检索。这个模块不复杂但把召回率从72%提升到了84%。再说不使用复杂Agent框架的原因。市面上很多Agent框架把编排、工具调用、记忆、多轮规划都打包好学习成本和排错成本都很高。在我们的场景里核心链路是“改写—检索—重排—生成”这条链路用几百行代码就能串起来出问题时也容易定位。等到场景复杂度真正上来了比如需要多工具协同、动态规划、用户多轮澄清时再引入Agent能力不迟。而且那时候你有评测集和监控日志在手上改造起来有据可依。3.3 理论没告诉你的三个落地坑这个项目做下来有三个坑我在绝大多数AI理论文章里都没见过但每一个都差点让项目延期。第一个坑是源文档解析。制度文档里有大量PDF其中一部分是扫描件还有大量表格和页眉页脚。直接解析后拿去切分会得到一堆乱码和残缺表格。我们最后用OCR加版面分析工具先把PDF转成带结构信息的内容再做清洗和分段。光这一项就花了两周。这个工作听起来没有一点技术含量但它决定了整个检索效果的上限。第二个坑是评测集的构建。很多团队先写功能后补评测这是完全反的。我们的做法是先整理200条真实问题覆盖高频场景和易错场景然后逐条标注对应的标准答案和来源文档。整个过程很费人力但评测集是整个项目的锚点后面无论换模型、调切分参数、改Prompt都跑一遍这200条用数据说话。没有评测集的时候优化完全是玄学有了评测集优化就从经验驱动变成数据驱动。第三个坑是幻觉控制的工程化手段。验收标准里“回答必须引用原文”这一条靠Prompt提示是做不到100%的。我们加了两个机制一是生成时把检索到的原文片段一起传给大模型并要求输出引用编号二是后置校验——如果回答里的关键信息在召回文档里找不到对应文本就把答案降级为“抱歉我没有在制度库中找到相关内容”。这个兜底机制比任何Prompt技巧都管用。3.4 验收不是一次性的它是一套持续动作项目交付当天我们给业务方做了一次现场验收现场提出20个新问题系统实时回答由业务专家判断对错。结果19个回答正确1个回答因为检索到相似但过时的制度版本而出现了偏差。当场我们就把这个问题记入评测集并在检索环节增加了版本过滤条件。这件事体现了“能验收”的真正含义验收不是一个终点动作而是一套持续的质量保障机制。上线后我们还接入了日志和反馈渠道每个回答下方有“有帮助/没帮助”按钮每周汇总一次失败Case并补充进评测集。第二个月我们的测试问题集从200条扩展到350条回答准确率和召回率都在这个过程中持续提升。这个闭环恰恰是很多理论博客不会写、但AI真实场景里最值钱的部分。4. 摆脱八股文真正值得投入的四个实践方向4.1 先写评测集再写功能如果你正在做一个AI应用我给的最实在的一条建议就是动手写第一行功能代码之前先花时间写评测集。哪怕一开始只有几十条也好过没有。评测集就是AI开发的单元测试它让你每次改动都有了一个客观的反馈信号。我在制度问答项目里吃过这个亏后来所有项目都先建评测集这个习惯帮我避开了无数“感觉效果好了实际效果却飘忽不定”的困境。评测集不用一开始就很完美关键是真实。可以从三类问题入手一是最高频的问题二是最容易答错的边界问题比如“请假超过三天需要谁审批”三是历史上真实出现的Bad Case。每次模型升级、框架变更、Prompt调整都全量跑一遍人工抽评变化点。长期来看这是投入产出比最高的AI工程投资。4.2 从固定流程到Agent走一条渐进路线AI Agent是今年最热的概念之一但我的看法可能跟很多人不同绝大多数业务场景起步阶段都应该用固定流程而不是Agent。固定流程的每一步都是确定性的改了哪个环节、影响哪条路径一目了然。当固定流程跑到瓶颈且瓶颈确实来自流程死板、缺乏决策弹性时才值得把特定环节替换成Agent化设计。具体来说可以先固定“改写—检索—重排—生成”这条主链路把每个环节做成独立模块并给每个模块配置日志和评测。然后观察哪一步最不灵活比如查询改写对长尾问题处理不好就可以把改写模块从“固定Prompt”升级成“带少量工具选择的Agent”让它自己决定改写还是直接检索。这种渐进式的Agent化既拥抱了热词背后的技术价值又不会被复杂框架绑架。4.3 把AI基础设施和可观测性当一等公民“AI infra”“模型部署”这两个方向最近热度很高这其实说明行业正在成熟。再强大的模型、再聪明的Agent跑在不可观测的基础设施上都无法长期稳定服务。我见过不少团队在演示时效果一流可对首响时间、Token成本、API失败率、上下文长度膨胀这些问题完全没有感知直到线上出故障才发现日志都没接。我的建议是AI应用从第一天就要有结构化日志记录每次请求的输入、检索结果、生成结果、延迟、Token用量性能监控重点关注P95延迟和成本趋势失败告警调用失败、空检索、连续降级等场景都要有告警反馈闭环用户侧的有用和无用反馈能回流到评测集。这套东西跟业务代码一样重要。很多博客爱讲“提示词工程有多精妙”却很少讲这些基础设施但恰恰是它们决定了AI应用能不能活得久。4.4 让AI编程回归“交付”本质今年“AI编程”也是个大热词各种提示词模板满天飞教你怎么让AI帮你写代码。我的观点是AI编程的本质不是背提示词而是利用AI加速从需求到可交付应用的路径。真正高效的AI编程是你已经清楚知道自己要交付什么、验收标准是什么然后用AI把重复性、机械性的编码工作快速完成。举个例子在制度问答项目中我们用AI辅助生成了大量数据清洗脚本和接口测试用例足足节省了将近一周的时间。但前提是我们自己很清楚清洗规则和测试预期是什么。如果对需求本身一知半解把希望完全寄托在AI生成上结果就是在不确定的地基上盖楼。所以AI编程和“能验收的应用”是互相成就的交付目标越清晰AI辅助效果越好AI辅助越快交付速度越快。5. 收尾把“能验收”变成肌肉记忆5.1 评审AI项目时我只认验收单最后再分享一点我在实际带项目过程中的体会。我现在评审一个AI项目基本不看PPT和架构图就要一张验收单上面写清楚三件事输入是什么输出是什么达到什么标准算通过。凡是能当场拿出这份单子并且数据齐全的团队项目大概率不会差凡是讲了半小时概念还说不清验收标准的哪怕名词用得多漂亮我都要打个问号。5.2 放下理论焦虑做一个小而真的应用这篇文章是“反对AI八股文”系列的第一篇核心就一条背一百个理论不如交付一个能验收的应用。这个系列后面我还会接着写聊一聊具体怎么拆解需求、怎么设计评测集、怎么在成本和效果之间做取舍。如果你正被海量AI概念和框架弄得焦虑我的建议很简单——放下那些论文和框架文档找一个具体而真实的小场景定一个可量化的验收指标把它交付出来。做完一个这样的应用比背一百个理论都管用。
