反本本主义：AI应用开发与Agent搭建的工程实践指南

1. 从“本本主义”说起AI 开发里最隐蔽的坑“本本主义”这个词最早是讲做事只认书本条文、不顾实际情况。放到今天的 AI 开发里它换了一身更时髦的衣服只认论文、只认框架文档、只认别人博客里的“最佳实践”却不去看自己手里的数据长什么样、业务到底卡在哪、用户真正要的是什么。我见过太多团队一上来就讨论要不要上 RAG、要不要接 Agent、要不要搞多智能体协作结果连最基础的“模型输出格式不稳定”都没解决项目拖了三个月还在调 Prompt。AI 开发这个领域表面上看是技术活实际上更像是一门“在不确定中找确定”的手艺。模型是黑盒数据是脏的需求是飘的算力是有限的。你如果拿一本教科书式的思维去套基本都会翻车。我写这篇东西不是要否定理论和方法论而是想把我这几年在 AI 应用开发、Agent 搭建、大模型落地过程中踩过的坑、总结出来的“反本本主义”经验系统地讲清楚。适合谁看适合正在做 AI 应用开发、AI Agent 开发、AI 测试开发或者正准备从传统开发转向 AI 开发的工程师和产品同学。不管你是刚入门还是已经带团队这里面的思路和实操细节应该都能让你少走一些弯路。核心观点先摆出来AI 开发不是“先学完再做”而是“边做边学、以做为主”。理论是地图但地图不等于地形。真正决定项目成败的往往不是你知道多少种架构而是你能不能快速验证一个最小闭环、能不能在脏数据里找到可用信号、能不能把不确定的模型行为约束到可接受的范围内。2. 为什么 AI 开发特别容易陷入本本主义2.1 信息过载带来的“方法论焦虑”AI 这个领域信息更新速度极快。今天出一个新框架明天出一个新范式后天又有人喊“某某已死”。打开任何一个技术社区满屏都是“AI Native 研发范式”“Agent 最佳实践”“大模型应用开发学习路线”。这种信息密度会让人产生一种错觉我必须先把这些都搞懂才能开始做。但实际情况是这些内容里 80% 是营销包装15% 是特定场景下的经验只有 5% 是真正通用的底层逻辑。你如果按“学习路线”从头学到尾等你学完你学的东西可能已经过时了。更关键的是很多知识只有在动手做的过程中才会真正内化。你看十篇讲 RAG 的文章不如自己搭一个最小检索问答跑一遍因为只有跑起来你才会遇到“切块大小怎么定”“向量模型选哪个”“召回不准怎么办”这些真实问题。我个人的做法是先定一个最小可验证目标然后倒推需要学什么。比如我要做一个“根据用户问题从产品文档里找答案”的功能那我需要的就是一个能读文档的解析器、一个向量化方案、一个检索逻辑、一个能拼 Prompt 的调用链。其他的什么多路召回、重排序、查询改写先不管。等最小闭环跑通了再根据实际效果决定要不要加。2.2 论文思维与工程思维的错位学术论文追求的是“在特定数据集上刷到最高分”工程追求的是“在真实场景下稳定可用”。这两者的目标函数根本不一样。论文里可以假设数据是干净的、标注是准确的、评测指标是明确的工程里你面对的是用户随手输入的错别字、格式混乱的 PDF、前后矛盾的对话历史、以及老板明天就要看 demo 的压力。我见过一个团队严格按照某篇论文的方法做了一套多轮对话系统在公开数据集上指标很好看但一上线就崩。原因很简单论文里的对话历史是人工构造的而真实用户的对话是跳跃的、省略的、带情绪的。用户说“那个东西再便宜点”系统根本不知道“那个东西”指什么。这就是典型的用论文思维做工程忽略了真实场景的复杂性。反本本主义的做法是把论文当灵感来源不当施工图纸。看到一篇好论文先问自己三个问题它的假设在我的场景里成立吗它的方法我能用现有资源复现吗它的收益值得我投入的成本吗三个问题有一个答不上来就先放一放。2.3 框架崇拜与“一键式”幻觉现在很多 AI 开发框架都宣传“几行代码搞定一个 Agent”“拖拽式搭建智能体”。这当然降低了门槛但也制造了一种幻觉好像 AI 开发就是调 API、拼组件。实际上框架帮你处理的是“标准情况”而真实项目里全是“非标准情况”。模型突然返回空结果怎么办工具调用超时怎么办用户输入触发了安全策略怎么办这些框架文档里往往一笔带过但却是你每天都要面对的。我的经验是可以用框架但必须理解框架替你做了什么。至少要知道它的核心流程、关键参数、失败模式。否则一旦出问题你连排查的方向都没有。比如用某个 Agent 框架时我习惯先把它的执行链路打日志看清楚每一步的输入输出这样出问题时能快速定位是模型的问题、工具的问题、还是编排逻辑的问题。3. 反本本主义的 AI 开发核心原则3.1 原则一先跑通最小闭环再谈优化这是我最想强调的一条。很多项目失败不是因为技术不够先进而是因为一开始就想做“完整版”。完整版意味着你要同时处理数据清洗、模型选型、Prompt 设计、工具集成、前端展示、权限管理……任何一个环节卡住整个项目就停摆。正确的做法是用最短路径跑通一个端到端的最小闭环。比如你要做一个 AI 客服最小闭环可以是用户输入问题 → 直接调模型 → 返回答案。先不管知识库、不管多轮、不管兜底。跑通之后你至少知道模型能不能用、响应速度能不能接受、成本大概多少。然后在这个基础上一步步加检索、加历史、加审核。我自己的习惯是任何新项目第一周只做一件事让数据从输入流到输出中间哪怕全是硬编码都行。这个闭环跑通了心里就有底了后面所有的优化都是在这个骨架上长肉。3.2 原则二用真实数据驱动决策而不是用直觉AI 开发里最容易犯的错就是凭直觉调参。觉得温度调低一点会更稳定觉得切块大一点会保留更多上下文觉得换个更大的模型效果会更好。这些直觉有时候对有时候错但你如果不做对比实验永远不知道。我的做法是建一个最小评测集每次改动都跑一遍。这个评测集不需要很大二三十条真实用户问题就够。关键是要覆盖典型场景和边界情况。比如做文档问答评测集里要有直接能查到答案的、需要跨段落推理的、文档里根本没有答案的、问题本身有歧义的。每次改 Prompt、换模型、调参数都拿这个集子跑一遍看准确率、看响应时间、看成本。数据说话比拍脑袋靠谱得多。这里有个细节评测集的答案不要只标“对/错”最好标出“错在哪里”。是检索没召回是模型理解错了还是答案格式不对这样你才知道下一步该优化哪个环节。3.3 原则三把不确定性当作设计输入而不是异常传统软件开发里我们习惯“输入确定 → 处理确定 → 输出确定”。AI 开发里这个链条中间那环是概率性的。同样的输入模型可能给出不同的输出。这不是 bug是特性。你不能指望它像传统函数一样稳定但你可以通过设计来管理这种不确定性。具体怎么做几个实用手段结构化输出约束让模型按 JSON 格式返回方便程序解析多路投票同一个问题跑三次取多数一致的结果置信度过滤让模型自己评估答案可靠性低于阈值就转人工兜底策略模型答不上来时有预设的回复。这些手段不能消除不确定性但能把不确定性控制在可接受的范围内。我特别想说的是不要试图用 Prompt 去“根治”模型的不稳定。你写再多“你必须”“你一定要”模型该飘还是飘。真正有效的是在系统层面做约束把模型的输出当作一个“需要校验的输入”来处理。3.4 原则四迭代速度比单次质量更重要AI 项目的质量不是一次做出来的是迭代出来的。你第一版的 Prompt 可能只有 60 分但如果你能一天迭代三次一周后就能到 85 分。反过来如果你花两周憋一个“完美方案”上线后发现方向错了损失更大。所以我在团队里推行的做法是缩短反馈周期。能今天上线的就不拖到明天能小范围试的就不要全量推。每次迭代只改一个变量改完立刻看数据。这样你才能建立起“改动 → 效果”的因果认知。如果一次改五个地方效果好了你不知道是哪个起作用效果差了也不知道该回退哪个。4. 实操一个反本本主义的 AI 应用开发流程4.1 第一步把需求翻译成可验证的问题很多 AI 项目的需求描述是模糊的“做一个智能助手”“提升用户体验”“实现自动化”。这种描述没法直接开发。你需要把它翻译成可验证的问题用户会在什么场景下使用输入大概长什么样期望的输出是什么格式成功的标准是什么举个例子“做一个 AI 旅游助手”这个需求翻译之后可能是用户输入“帮我规划一个三天的北京行程”系统输出一个包含景点、交通、餐饮建议的结构化行程要求景点不重复、每天不超过三个、总预算在两千以内。这样你才知道要做什么、怎么测。这一步最容易被跳过但恰恰最重要。我见过太多项目做到一半发现大家对“做好”的定义不一样返工成本极高。4.2 第二步用最笨的方法先跑通需求明确后不要急着选框架、搭架构。先用最笨的方法跑通直接调模型 API把输入拼成 Prompt把输出打印出来。看看模型能不能理解任务、输出质量如何、有没有明显的坑。这个阶段我通常只写几十行代码甚至直接在 Playground 里试。目的是快速建立对模型能力的直觉。比如你会发现模型对格式要求很敏感你不明确说“用 JSON 返回”它就会给你一段散文你说了 JSON它有时候还会加个“好的以下是结果”的前缀。这些细节只有亲手试过才知道。4.3 第三步识别瓶颈逐个击破最小闭环跑通后你会看到明显的瓶颈。可能是模型知识不够需要 RAG可能是输出格式不稳需要结构化约束可能是多轮对话记不住上下文需要历史管理可能是响应太慢需要流式输出或缓存。这时候再针对性地引入技术方案。注意是“针对性”不是“全面性”。哪个环节弱就补哪个不要一次性把所有高级技术都堆上去。每加一个组件都要问它解决了什么问题带来了什么新问题成本增加了多少4.4 第四步建立评测与监控上线不是终点是起点。你需要一套机制来持续观察系统表现用户满意度、答案准确率、响应时间、异常率。这些数据会告诉你下一步该优化什么。评测集要持续更新把线上发现的 bad case 加进去。监控要能定位问题最好能追溯到具体的请求链路。我习惯在关键节点打日志用户输入、检索结果、模型输出、最终返回。这样出问题时能快速复现和排查。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定怎么办这是最高频的问题。你要求 JSON它给你 Markdown你要求简洁它给你长篇大论。排查思路先看 Prompt 里有没有明确的格式示例最好给一个完整的输入输出样例再看温度参数是不是太高结构化任务建议调到 0 到 0.3如果还不行就在代码层面做后处理用正则提取关键字段提取失败就重试或走兜底。我实测下来给样例比给规则更有效。你写“请用 JSON 格式返回”不如直接写“输入xxx输出{name: xxx, age: 20}”。模型对示例的模仿能力很强。5.2 检索召回不准怎么调RAG 场景里召回不准通常有三个原因切块太大或太小、向量模型不适合中文、查询和文档的语义空间不匹配。排查顺序先看切块一般中文文档 300 到 500 字一块比较合适太大噪音多太小上下文断再看向量模型中文场景建议用专门的中文模型或 multilingual 模型最后看查询用户的问题往往很短可以先用模型做一次查询改写再拿去检索。还有个容易被忽略的点文档预处理。PDF 里的表格、页眉页脚、乱码如果不清理会严重干扰检索。我一般会先做一轮清洗把明显无意义的字符去掉。5.3 Agent 工具调用失败怎么排查Agent 调工具失败常见原因有工具描述不清楚模型不知道什么时候该调参数格式不对模型传的参数和工具要求的不匹配工具本身超时或报错但 Agent 没有正确处理。排查时先把 Agent 的完整执行链路打出来看模型决定调哪个工具、传了什么参数、工具返回了什么。大部分问题出在工具描述上。我的经验是工具描述要写得像给新人看的文档这个工具是干什么的、什么时候用、参数是什么格式、返回什么。越具体模型调用越准。5.4 常见问题速查表问题现象可能原因排查方向解决手段输出格式乱Prompt 缺示例、温度高检查 Prompt 和温度参数加示例、降温度、后处理检索不准切块不当、向量模型不匹配检查切块大小和模型调整切块、换模型、查询改写工具调用失败工具描述不清、参数不匹配打印执行链路完善描述、加参数校验响应太慢模型太大、无缓存、串行调用看耗时分布换小模型、加缓存、并行化多轮丢上下文历史管理不当检查历史拼接逻辑限制轮数、做摘要压缩成本过高模型选型不当、重复调用统计 token 消耗换模型、加缓存、批处理5.5 几个独家避坑技巧第一不要在生产环境直接用最新模型。新模型往往有未知的坑先在小流量上试稳定了再切。第二Prompt 要版本管理。每次改动都记录出问题能回滚。第三给模型留退路。设计 Prompt 时就想好“如果模型答不上来怎么办”预设兜底话术。第四不要迷信大模型。很多任务小模型加好的 Prompt 就能做成本低、速度快。第五日志要打全。AI 系统的问题往往难以复现日志是你唯一的线索。6. 工具选型与团队协作的反本本主义6.1 工具选型适合的比先进的更重要AI 开发工具链更新极快今天流行的框架明天可能就没人维护了。选型时不要只看 star 数和技术先进性要看社区是否活跃、文档是否完整、出问题能不能找到人问、是否容易替换。我倾向于选那些“薄封装”的工具它们不会把你锁死出问题也容易排查。比如做 Agent 开发有的框架封装得很重你只需要配置几个组件就能跑但一旦行为不符合预期你很难干预。有的框架比较轻你需要自己写编排逻辑但每一步都可控。我一般选后者因为 AI 系统的不确定性太高可控性比开发效率更重要。6.2 团队协作打破“算法”和“工程”的墙AI 项目最容易出现的问题是算法和工程脱节。算法同学调出一个模型工程同学不知道怎么集成工程同学搭好服务算法同学发现线上数据和训练数据分布不一样。反本本主义的做法是让算法和工程坐在一起从第一天就共同定义接口和数据格式。我推行的做法是算法同学要能跑通工程的部署流程工程同学要能看懂算法的评测报告。大家用同一套评测集、同一套日志、同一套指标。这样出了问题不会互相甩锅而是一起看数据、找原因。6.3 学习路线以项目为纲缺什么补什么最后说说学习。网上有很多“AI 应用开发学习路线”从数学基础到深度学习到到大模型到到应用开发列了几十个知识点。如果你按这个学两年都学不完。我的建议是以项目为纲缺什么补什么。你想做 RAG就去学检索和向量你想做 Agent就去学工具调用和编排你想做微调就去学数据构造和训练。学的时候带着问题学效率比系统学习高得多。而且AI 这个领域很多知识是“用进废退”的。你学了一个技术如果三个月不用基本就忘了。所以不要囤积知识要用的时候再学学了立刻用。7. 我个人的几点体会做 AI 开发这几年我最大的体会是这个领域没有标准答案只有适合当前场景的答案。别人的最佳实践到你这里可能就是最差实践。所以不要迷信任何权威包括我上面说的这些。你要做的是理解背后的逻辑然后根据自己的数据、场景、资源去调整。第二个体会是快速失败比缓慢成功更有价值。一个方案不行早点知道早点换方向。最怕的是在一个错误的方向上投入太多舍不得放弃。AI 项目的不确定性很高试错是常态关键是要控制试错成本。第三个体会是保持手感比积累知识更重要。AI 开发很像手艺活你需要持续动手才能保持对模型行为的敏感度。我即使不做新项目也会定期拿一些新模型、新工具来试看看它们能做什么、不能做什么。这种手感是看文章看不来的。最后分享一个小技巧每次遇到模型输出不符合预期先不要改 Prompt先问自己“如果我是模型看到这个输入我会怎么理解”。很多时候问题不在模型而在你的输入本身就有歧义。把输入改清楚比在 Prompt 里加十句“你必须”都管用。这个思路其实也是反本本主义的精髓不要从规则出发要从实际情况出发。