企业官网建设流程全解析

在AI应用开发的面试场上，有一个问题几乎是无差别攻击：“你做过什么项目？其中踩过什么坑？”

我干这行五年多，现在也经常坐在面试官的位置上，前前后后聊过上百个做AI应用方向的候选人。说句实话，面试官问“你踩过什么坑”，真不是想听你诉苦，也不是单纯想听你讲个段子。这个问题表面上问的是过去，实际上是在模拟你未来上线后遇到问题时的表现。尤其在AI应用开发这个行业，大模型本身充满不确定性，坑是必然的，人与人的差距不在会不会踩坑，而在踩完之后能不能把坑变成自己的地图。

这篇文章我就站在面试官的角度，把这个问题背后的意图拆开给你看，同时结合我自己在实际项目中踩过的几个真实案例，聊聊怎么在面试里把“踩坑经历”讲成真正的加分项。

1. 面试官这句“灵魂拷问”，究竟在探测什么？

1.1 表面问过去，实际问未来

很多人以为面试官问“踩过什么坑”是在验证项目真实性，其实这只是最浅的一层。更深层的东西，是你的归因逻辑和工程思维。举个例子，两个候选人都说“我做过RAG问答系统，遇到过召回不准的问题”。一个人是这么说的：

“后来我把embedding模型换成了bge-m3，效果就好了。”

另一个人是这么说的：

“我先把问题拆成子问题看哪些case召回失败，发现是长文档的切片把段落切断了，导致向量匹配到错误的片段。然后我改了切片策略，加了重叠窗口，再对召回结果做了rerank，最终在评测集上Top1命中率从62%提高到了88%。”

如果你是面试官，你会觉得谁更像一个能做AI应用的人？第一个人可能也是真的处理过问题，但他只有一个“动作”，没有“决策”。他不知道为什么要换模型，也不知道换了之后发生了什么、还能不能更好。面试官问踩坑经历，就是想看看你遇到模糊问题时的思考习惯：你会怎么定义问题，怎么假设根因，怎么验证，怎么量化结果。

一个大模型应用项目的生命周期里，代码出错、接口报错、依赖崩溃都不可怕，因为这些是传统软件工程早就解决的问题。真正让人头疼的是那种“没有报错但效果就是不对”的情况。面对这种问题，能不能冷静地把模糊变为清晰，才是AI应用开发的核心竞争力。这句话，我面试的时候经常在心里默念。

1.2 大模型应用的四大不确定性，让“踩坑能力”成为工程硬实力

传统开发里，你写了return 1 + 1，不管跑多少次结果都是2。但AI应用开发完全不是这样。哪怕一模一样的输入，温度参数设为0.7，模型每次回答都可能不一样。这种随机性只是第一个坑。

第二个坑是外部依赖的黑盒化。很多人用别人的模型API，底层模型版本更新了，文档只说“性能提升”，但实际行为可能已经翻天覆地。你上周测好的prompt，这周可能就因为模型升级而失效了，而你连报错都看不到。

第三个坑是效果评估困难。传统程序的正确性是布尔值，AI应用却是一段对话、一段摘要、一次工具调用。你说它好，它真的好；你说它差，是哪里差？边界在哪？没有现成的断言。

第四个坑是成本失控。一次Agent任务可能调用十几次模型，每个环节都在烧token。代码没崩，账单先崩了，这种坑在传统开发里几乎不存在。

这四个不确定性叠加在一起，就决定了AI应用开发不能用“代码正确就行”的思路来交付。面试官问“你踩过什么坑”，其实是在探测你能否接受并驾驭这种不确定性。你说你只会按教程搭一个Demo，那是不算数的。你得让面试官相信，你能在充满不确定性的环境里把系统稳定地跑起来。

1.3 我当面试官时最不想听的两种回答

这些年我听到过太多无效回答了。第一种是“甩锅型”：“这个模型太笨了，我调了很久都不行，后来换了一个大模型就好了。”如果你把根因归结为“模型笨”，那面试官会立刻意识到，你遇到类似问题时可能会花大量时间在玄学调参上，而不是系统排查。第二种是“背题型”：把网上最常见的“幻觉、上下文超长、JSON解析失败”背一遍，但问到具体场景就卡壳。这种回答没有任何信息量，一听就是没有真正做过。

我真正想听到的，是一个具体的故事：现象是什么、怀疑了哪几个方向、怎么排除的、最后怎么证明根因、上线后怎么避免它再次发生。故事里可以有失败，但必须有一条清晰的思考线。单纯讲自己“吃苦耐劳”没有用，AI应用开发不缺熬夜的人，缺的是能把经验转化为方法论的人。

2. 我踩过的那些真实案例：从现象一路追到根因

2.1 案例一：线上对话效果突然变差，谁也没改代码

有一段时间我在做一个知识型AI问答产品，主打文档问答，用户问一句，助手返回答案。我们的prompt经过了好几轮优化，线上效果已经稳定了一个多月。结果某天早上，业务方突然跑过来跟我说：“机器人是不是傻了？同一个问题，昨天回答还有引用，今天就开始胡说了。”

我第一反应是有人改了prompt，查了一下git提交记录，没有；又去查线上配置，没变。这也很正常，很多系统问题第一时间要排除“自己改坏”的可能。

然后我去翻调用日志，发现同一个问题在凌晨前后的输出风格明显不一样。凌晨之前，回答都很克制，会说“根据文档，可能…”；凌晨之后，语气突然变得很笃定，甚至开始编造未出现在文档里的数据。更诡异的是，输入输出token数量分布没变。后来我对比了同一个请求的返回字段，发现模型版本号变了。原来是底层模型厂商在一夜之间完成了一次灰度升级，我们这边没有任何感知。

这个坑的关键在于：你以为你控制了一切，其实model provider的升级、降级、平替全在你控制之外。从那以后，我在所有关键prompt里都要固定可用的模型版本号，如果API不支持，至少要加一个线上每日回归集，每天用20条典型问题跑一遍，输出结果变了就告警。千万不能等到用户投诉才被动去查。

2.2 案例二：RAG检索到了“正确”内容，却生成了一本正经的错误

第二个坑更隐蔽，它发生在RAG项目上。当时我们给内部客服团队做了一个政策问答系统，知识库里存了几百份制度文档。上线前我拿测试集跑了一遍，召回率看着不错，Top1基本都能命中相关文档，可等到人工试用时，很多回答呈现出“一本正经的胡说八道”。

举个例子，用户问“报销差旅费需要提前几天申请”，系统检索到了一份《差旅管理制度》，看起来完全相关。可模型回答里却说“需要提前3天申请”，而文档里写的其实是“紧急出差可事后补单”。为什么？我打开prompt后发现，我们把检索到的文档原封不动拼进上下文，但没有任何段落边界标记，模型根本分不清哪些是用户输入、哪些是参考资料，更别提区分文档里的多个条款了。

更麻烦的是，文档切片按长度硬切，把一个完整的制度条目从中间截断。系统检索到的其实是“半句话”，模型只能靠猜去补全语义。找到这两个问题后，我把切分逻辑改成了按标题和段落层级切，并加了重叠窗口；prompt里也明确用<reference>标签包住检索内容，要求模型只能基于标签内的信息回答，并且必须附上来源段落编号。

这一轮改动之后，引用冲突率从31%降到了9%。这个案例给我的经验是：RAG的成败八成在检索管线的数据质量，只有两成在模型推理能力上。很多团队一上来就调prompt，连检索出来的东西是不是人话都没看，这是本末倒置。

2.3 案例三：Agent调用工具来回打转，token先我一步烧完

第三个案例，是我做一个Agent智能体应用时踩过的。当时用语言模型驱动一个客服助手，它需要调用订单查询、物流查询、退款申请三个工具。模拟测试阶段，我发现一个问题：Agent在查询物流失败后，会反复调用同一个工具，参数几乎一样，每次拿到报错后又重新尝试，一连转了七八轮才停下来。

一开始我觉得是模型不够聪明，后来一查日志才发现，工具返回的错误信息太抽象了——只有一个error_code，没有任何解释。Agent读不懂错误码，不知道自己是“权限不足”还是“订单不存在”，只能盲目重试。我的prompt里又没限制最大迭代次数，于是一次会话烧掉了几十万token，成本直接爆表。

这个坑的本质是“失控”。Agent和自我迭代是双刃剑，给它的自由度太大，它就会在边界外横冲直撞。修复时我做了三件事。一是给Agent加了一个最大步数限制，默认5步，超过就自动收敛并转人工；二是在工具返回里写清楚错误类型、可执行建议，比如“订单号格式错误，请重新获取”而不是只有一行看不懂的编码；三是在对话上下文中加入一条系统提示：“如果上一步工具调用失败，不要重试，直接向用户解释原因。”

改完之后，单次会话平均token从4.2万降到了1.1万，成功率翻了近一倍。这个坑让我意识到，AI应用开发里成本控制不是财务问题，是一个实打实的工程问题。你的Agent再聪明，也必须有刹车系统。

3. 把踩坑经验变成可复用的排查方法论

3.1 复现优先：先锁现象，再猜根因

踩坑踩多了以后，我养成一个习惯：问题一出现，第一反应不是改代码，而是先把现场存下来。什么叫“现场”？就是当时的输入、输出、prompt版本、模型版本、温度参数、上下文长度、时间戳，甚至包括用户IP和trace_id。等你把这些信息记录完整了，再开始排查。

具体操作上，我通常是构造一个最小复现脚本，固定所有参数，把一个可疑case跑上十次。如果十次里只有两次有问题，那可能是随机性波动；如果每次都有问题，并且结果一致，那多半和prompt或上下文有关。如果复现不出来，我就怀疑是不是依赖了某个外部状态，比如向量库里的数据更新了、模型端偷偷换了版本。

排查时我会用二分法：先关掉最近的改动，再逐步加回来。很多人一上来就怀疑embedding不好、prompt不行，结果绕了半天发现是测试环境连错了数据库。这种冤枉路走一次就够长了。

记住一个原则：能稳定复现的坑才是真正的坑，不能稳定复现的坑，先别动代码，先想办法让它稳定复现。

3.2 全链路观测：让每次调用都有迹可循

大模型应用是个多级黑盒：外部模型是黑盒，向量检索可能是黑盒，工具服务也可能是黑盒。要让“踩坑”从玄学变成科学，就得从第一天开始做全链路观测。

我自己的做法是：每个线上请求都给一个request_id，日志里必须包含完整的prompt版本、模型版本、输入输出token数、推理耗时、工具调用序列、检索返回结果ID和后处理状态。哪怕是prompt里的一个小小换行，也要有版本hash记录。这样一旦线上出问题，我能直接拉出那个请求的完整链路，而不是拿着用户的一句“回答不对”干瞪眼。

工具选型上，基础日志用好并行的方案，可观测性平台可以选开源的Langfuse等，也可以自己写。如果你用扣子这类Agent开发平台搭智能体，同样需要在业务流程上设计日志上报点，不然你连Agent到底调用了哪个工具都看不清楚。

很多候选人跟我说他没条件上这么好的监控。我的观点是：你可以没有平台，但你至少要在代码里留一个“现场保护机制”。因为面试官问“你踩过什么坑”时，如果你能直接说“我通过trace_id把问题复现出来了”，这句话的含金量比背十篇文章都高。

3.3 评测集与回归测试：用数据代替“我觉得”

踩坑后的第三件事，也是最容易被忽略的一件事，是把坑变成评测用例。这里的“评测集”不是随便找几十个问题，而是把你历史上所有出过问题的case都收集起来，形成一份“易碎品清单”。每次改prompt、换模型、调切片参数之前，都要拿这些case跑一遍。

我建过一个名为“regen_bugs”的测试集，里面存着大约80个真实case，包括常见幻觉、拒答、绕圈、输出超长、引用错误等。每次改动后，我会让新旧版本同时对每个case跑一次，再人工打分，对比指标。这样做最大的好处是：避免“修好了A问题，却破坏了B问题”的经典回归。

指标也不用搞得很复杂。我常用四个：答案准确性、引用覆盖率、工具调用成功率、无效步数占比。其中“引用覆盖率”对RAG特别重要，它反映模型有没有用到检索出的内容；“无效步数占比”对Agent很重要，它反映模型有没有在空转。每次上线前把这些数字贴到发布说明里，效果好不好一目了然。这也是面试时很有说服力的论据。

3.4 从单个case到通用解法，让经验不再孤立

每一个坑刚发生时，我总觉得它是孤例，但复盘多了会发现它们背后隐藏着共性。比如“模型突然变笨”和“Agent逻辑混乱”，本质上都是缺少稳定性机制；“RAG答案矛盾”和“工具反复试错”，本质上都是信息边界不清晰，模型不知道哪些可信、哪些不可信。

所以我每记一个case，都会顺手总结一句“以后在设计层怎么避免”的话。比如说：

• 凡是涉及外部依赖的，都要有版本锁定和回归告警；
• 凡是给模型拼接内容的，都要明确划分来源边界；
• 凡是有循环行为的，都要给一个最大步数和预算护栏；
• 凡是改动效果的，都要有数据对比而不是“感觉”。

这个总结过程很像是给未来的自己写备忘。做多了之后，很多问题不需要从头排查，看一眼现象就能猜到是哪一类坑。这种“一眼定位”的能力，恰恰是面试官真正想从“踩坑问题”里听到的东西。

4. 面试时怎么把“坑”讲成加分项

4.1 一个很好用的STARR模型：背景、任务、行动、结果、复盘

很多人讲项目时都是流水账：“我做了A、B、C，后来出问题了，我换了D。”这不行，信息太扁。我习惯用一套叫STARR的叙事结构：

• S（Situation）：一句话说清业务场景和规模；
• T（Task）：说清你要解决的问题是什么，为什么它重要；
• A（Action）：详细讲排查过程，特别强调你想到过哪些假设、怎么排除的；
• R（Result）：给出可量化的结果，包括效果指标和成本指标；
• R（Review）：说清楚如果再给你一次机会，哪里会做得跟之前不一样。

举个例子，完整地说：

“我们做一个文档问答系统，知识库有20万份PDF。我上线后发现用户问政策条款时，模型经常答得和原文矛盾。我先用trace_id抽了100个失败case，对比检索结果和生成结果，发现其中60%是因为切片把一个段落从中间截断了。我把方案改成按章节加语义段落切分，并加了一个重叠窗口，再对召回的Top10做rerank。上线后引用冲突率从28%降到9%，准确率提升了约13%。复盘时我觉得最大的问题是当时太相信embedding的通用能力，没有先做检索质量的可视化，不然可以提前两周发现问题。”

这段话里没有一个技术名词你听不懂，但它完整地呈现了一个工程师的能力闭环。面试官听这段时会觉得：这个人是真的在解决问题，而不是在复述教程。

4.2 哪些内容必须量化：延迟、成本、准确率、恢复时间

面试官也是人，听故事听多了会疲劳。你讲“效果变好了”其实没什么感觉，但你说“回答延迟从6秒降到2.1秒，单次会话成本从1.5元降到0.4元”时，数字会自动帮你建立可靠性。

具体量化的维度我一般抓四个：

• 影响范围：这个坑影响了多少用户、多少请求、多少业务链路；
• 排查耗时：从发现到定位根因用了多久，中间踩过哪些岔路；
• 成本变化：token消耗、调用量、API费用，修完后降了多少；
• 效果收益：准确率、召回率、用户满意度、工单量这些业务指标的变化。

比如“Agent死循环”那个案例，我在面试里会讲：“之前每次会话平均消耗4.2万token，收不住。加了步数限制和错误码标准化之后，单次会话降到1.1万token，工具调用成功率从52%升到94%，光成本每个月就省下两万多块。”这种话一出来，面试官很难不把你的简历标记为“值得重点跟进”。

还有一个小技巧：讲“恢复时间”也很加分。比如说“我们用了40分钟定位到是模型版本升级导致，而不是花了两天”。这体现了你的habits和debug节奏。

4.3 哪些话说了反而扣分

有正能量就有雷区。我列几个最扣分的说法，大家可以对照一下自己有没有踩过。

第一句是“这个模型太蠢了，我也没办法。”把责任推给模型或平台，面试官只会觉得你缺少owner精神。大模型确实会犯蠢，但工程师的价值就是接住它的蠢，定义它的边界，而不是指望它完美。

第二句是“后来我把温度从0.6调到0.2就好了。”如果这是你唯一的解决方案，面试官会担心你的水平停留在试参数阶段。温度变化可能是有效的，但你得说清楚为什么有效、影响面有多大、有没有副作用。

第三句是“我没遇到过什么坑。”这基本等于告诉面试官你没做过真实项目。一个认真上线过的AI应用，没有坑是不可能的，除非你只是照着官方示例改了改标题。

第四句是“我们通过人工抽检发现效果不错。”没有衡量体系，说明系统没有闭环。哪怕是一套简单的评测集，也比“感觉不错”强得多。

最后想说，面试官问“你踩过什么坑”，真的是一个信号，而不是刁难。它释放的信号是：我知道你一定会踩坑，我只想看清你踩完之后变成了什么样子。在AI应用开发这个领域，坑不是敌人的伏击，而是一张地图上的等高线。每踩一次，你就多画出一条线来，从此你对不确定性的掌控就多一分。

我自己至今还保留着一个习惯：每踩一个坑，就在笔记里写一份几十行的复盘，记下现象、根因、修复方案和防止复发的机制。这个note已经积累了快两百个case。每次要面试前，我把它翻一遍，比刷面试题有用得多。如果你正走在AI应用开发的路上，建议你也从现在开始建一个这样的case库。等下次有人问你“你踩过什么坑”，你会笑着感谢当初那些坑教会你的东西。