面试官问我“前端要不要懂 AI”？我更关心另一件事

面试只是引子。真正值得聊的是：过去两年，前端到底发生了什么变化，我们在其中扮演的角色是否已经和以往不同？

一次面谈后的思考

去年有一次面试，开场第一句是：“你在项目里怎么用 AI？”我当时没直接讲工具，而是把话题拐到“体验”和“交付”。我说：比起技术名词，我更在意用户能不能在产品里顺手把事做完，以及我们能不能把复杂能力做得可靠、可解释、还能复用。

对方笑了笑，说“继续”。从那以后，我开始把一些想法做成可落地的东西，不去追“是不是用了某个模型”，而是回答“这件事到底有没有更好地被解决”。

这两年最明显的变化

交付速度变快了：大家都希望更快验证一个想法，功能更像“模块拼装”而不是“大工程”。
用户期待变高了：不仅要看到结果，还要知道结果从哪里来，是否可靠，能不能一键用到自己的流程里。
前端角色在外扩：不只是把页面做漂亮，而是把能力编排成好用的体验，保证稳定、解释清楚、可复用。

一个具体的故事：从“搜索框”到“可解释的答案”

我们做过一个内部知识库的改造，原本就是普通搜索。后来同事提出：能不能直接问问题，拿到简明答案，还能看到引用来源，并且一键把结果插到现有流程里（比如填写审批单的理由）。

我们没有先谈技术细节，而是把用户路径画出来：

输入问题 → 先检索出相关片段，做高亮；
在旁边给出一个简明答案，但必须显示引用来源；
允许一键插入到业务流程（比如表单里某个字段）；
如果答案不靠谱或超时，回退到检索结果，让用户自己判断。

这套路径的关键点不是“多聪明”，而是“可解释”和“有兜底”。

我们最后怎么落地

把复杂能力藏在简单组件里：一个“答案区”、一个“引用区”和一个“插入到流程”的按钮。
对失败、超时、异常做兜底：不要让用户卡在一个转圈里，随时给出备选路径。
做审计和日志：结果从哪里来、用了哪个模板、是否失败，都能追溯。

下面这段小代码，展示了我们在体验层做的“可靠性兜底”。它不追求“酷炫”，只关注用户能不能得到一个可用结果：

// getAnswer.ts —— 简单的答案获取与兜底
// 思路：优先尝试生成答案；失败或超时则回退到检索结果；始终返回可解释的内容

type Source = { title: string; url: string; snippet: string };

type AnswerResult =
  | { type: 'answer'; content: string; sources: Source[] }
  | { type: 'search'; items: Source[] };

const TIMEOUT = 3000;

export async function getAnswer(query: string): Promise<AnswerResult> {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), TIMEOUT);

  try {
    const res = await fetch(`/api/answer?q=${encodeURIComponent(query)}`,
      { signal: ctrl.signal });
    const data = await res.json();

    // 没有来源就不算“答案”，直接回退到检索
    if (!Array.isArray(data.sources) || data.sources.length === 0) {
      return { type: 'search', items: await search(query) };
    }

    return { type: 'answer', content: data.content, sources: data.sources };
  } catch (e) {
    // 超时或失败，直接给检索结果，让用户自己判断
    return { type: 'search', items: await search(query) };
  } finally {
    clearTimeout(timer);
  }
}

async function search(query: string): Promise<Source[]> {
  const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
  return await res.json();
}

这段代码不是“技术亮点”，只是把可靠性做进了体验里：答案必须带来源，没有来源就不算“答案”；失败就回到检索，不让用户空等。

为什么要把“可解释”当成体验的一部分

我们发现，大家对“结果对不对”非常敏感。如果只给一个“看上去像对的”答案，最后还是要自己去确认来源。与其这样，不如一开始就把来源和可信度做成界面的一部分，让用户可以快速复核。

另外，任何新能力都需要被团队复用。我们做了三件很朴素的事：

把“答案区”“引用区”“插入按钮”做成组件，文档写清楚怎么接。
把提示模板版本化，谁改了、效果怎样，有记录。
做了个简单的看板，统计延迟、失败率、使用次数，方便复盘。

它们听起来不酷，但能让事情更稳定、更长久地跑下去。

未来会怎样？

我个人的判断是：

近期：很多团队会把“搜索、答案、解释”这类能力做成组件库，接入像写表单一样简单。
中期：能力会被平台化，交付物从“页面”升级为“能力 + 体验”的组合；前端更像“编排者”。
更远一点：用户对“可解释”会提出更高要求，结果不仅要快，还要能追溯、可度量、能被讨论和改进。

不管时间线怎么走，有几件事应该是稳定的：

工程化的地基仍然重要：模块化、测试、性能、稳定性从来不是过时话题。
抽象和编排能力会更重要：把模糊需求转成流程与数据契约，才有复用和协作。
体验里的“兜底”要成为常识：给用户可替代路径，比“炫技”的体验更有价值。

写在最后

我并不觉得“危机”是一个坏词。它提醒我们——别把自己困在工具名词里，去关心“事情到底有没有被更好地解决”。当我们把复杂能力做成人人可用的体验，角色自然就会改变。

如果你也在做类似的事情，欢迎分享你的做法：哪些环节最难、哪一步最值得投入、你如何解释结果的可靠性。我们可以在这些朴素的问题里，慢慢找到新的边界。

面试官问我“前端要不要懂 AI”？我更关心另一件事 ​

一次面谈后的思考 ​

这两年最明显的变化 ​

一个具体的故事：从“搜索框”到“可解释的答案” ​

我们最后怎么落地 ​

为什么要把“可解释”当成体验的一部分 ​

未来会怎样？ ​

写在最后 ​