WebView到AI产品，最值得掌握的3个核心能力——从自己产品里总结的能力地图

前面写「WebView 在 AI 时代的三个被低估的价值」那篇文章，有个读者留言问：你一个写 WebView 的，怎么就开始做 AI 产品了？中间补了哪些东西？ 这个问题让我想起 5 月份刚开始做 TLDR Scholar 的时候。那时候我以为前端转 AI 最大的门槛是「学不会 Python」，后来发现自己完全想偏了。Python 可以边写边学，真正卡住我的是另外三件事。

我的背景是 WebView 开发，做了十来年。从离线包到 Hybrid 架构到性能监控，WebView 相关的坑基本踩完了。去年底开始转 AI 产品开发，到现在做了 3 个产品（TLDR Scholar + 两个内部工具），不是大厂专业 AI 团队的路线，更像「一个人从 0 到 1 做 AI 产品」那种路子。回头看，前端转 AI 最值得补的不是某个语言或框架，而是 3 个能力------恰好都是 WebView 前端经验能复用、但需要换个角度用的能力。

一、Prompt 评估能力------别信感觉，信基线

先说第一个。这个是我踩坑最多的方向。最开始写 prompt，我的思路是「写得越详细越好」。系统提示词写到 800 字，把各种边界情况都列上，觉得这样 AI 肯定能理解。结果跑出来效果时好时坏------有时候很准，有时候完全跑偏。翻车实录那篇文章里提到的幻觉问题，本质也是评估方式出了问题。

后来我做了个事：给每个 prompt 建了一个基线测试集。 大概 200 条测试样本，覆盖正常的输入、边界输入、容易混淆的输入。每次改 prompt，跑一遍这个测试集，记录准确率和问题类型分布。

// prompt 基线评估脚本（简化版）
const testCases = [
  { input: 'Attention Is All You Need', expected: 'transformer' },
  { input: 'ResNet 152 layers deep learning', expected: 'cnn' },
  { input: 'GNN recommendation system 2024', expected: 'gnn' },
  // ... 约 200 条
]

async function evaluatePrompt(promptTemplate) {
  let correct = 0
  const errors = []
  for (const tc of testCases.slice(0, 20)) { // 快速评估用子集
    const result = await callLLM(promptTemplate, tc.input)
    const isCorrect = result.includes(tc.expected)
    if (isCorrect) correct++
    else errors.push({ case: tc, got: result })
  }
  return { accuracy: correct / 20, errorSamples: errors }
}

// 实际跑出来的一版结果
{ accuracy: 0.85, errorSamples: [
  { case: 'GNN recommendation system 2024', got: '该论文主要研究图神经网络......' },
  { case: 'few-shot learning meta-learning', got: '本文提出了一种新的小样本学习方法......' }
]}

85% 看着还行，但错的那 15% 往往就是用户真正在意的 case。这个习惯对我来说完全是新东西。WebView 开发里，功能对不对看 UI 渲染结果就行------按钮在不在、布局崩没崩，肉眼可见。但 AI 产品的「对不对」没有明确的视觉信号，必须用数据测。我的经验是：不做基线评估的 prompt 优化，都是撞大运。 你感觉「这版好多了」不一定对，跑 200 条测试集看到准确率从 62% 涨到 74%，才叫真的好了。

这个能力对前端开发者来说有个优势------写脚本、跑自动化测试是基本功。把 prompt 评估做成自动化测试套件，持续集成到开发流程里，就相当于把「AI 输出的不确定性」纳入了工程化管理。

二、数据链路调试能力------出错不一定在前端

第二个能力，是我最意外的发现。做 WebView 这么多年，遇到线上问题我的排查路径是：白屏 → 看网络请求 → 看 JS 异常 → 看渲染链路。99% 的问题能在前端层面定位。但 AI 产品不一样。用户反馈「摘要太差了」，可能的原因有：

可能原因	排查方向	我遇到的比例
Prompt 写得有问题	检查 prompt 模板，看测试集准确率	~40%
输入内容超出模型窗口	检查分段策略和 token 计数	~25%
模型 API 不稳定	检查 API 响应时间 + 错误率	~20%
前端渲染/展示问题	检查 JS 执行 + DOM 渲染	~15%

花最多时间排查的是「看起来正常但效果不对」的问题。最典型的 case：有段时间用户反馈长论文的摘要质量下降得厉害，我排查了两天，从前端代码看到 API 调用日志，最后发现是分段策略的 chunk overlap 参数设小了------相邻段落的重叠区域不够，导致跨段的关键信息被截断。

这个问题的排查路径是：

1. 前端日志看到摘要输出正常（没报错）

2. API 日志看到完整输入（没超长）

3. 对比分段前后的文本，发现段落被截断的位置漏了关键信息

4. 定位到 chunk overlap 参数

   前端展示正常 → API返回正常 → 分段策略有问题 → chunk overlap 参数

这一步在前端开发里很少需要做------前端只负责展示数据，数据质量是后端的事。但 AI 产品里，「数据质量」是整个产品的事。前端开发者在排查问题时，需要把排查链路往后延伸到 LLM API 的输入输出、分段策略、模型行为。这个能力的核心是：建立起从用户看到的结果 → 模型输出 → 模型输入 → prompt → 数据处理的完整排查链路。 每层都能快速确认「这层没问题」或者「问题在这层」。WebView 开发者已经有排查 UI 问题的经验（看 DOM、看网络、看日志），把排查范围往后扩一层，覆盖到 LLM 这一层就行了。

三、评估驱动开发------AI 产品没有肉眼可见的「完成」

第三个能力，是我做第二第三个产品时才真正理解的。WebView 开发里，一个功能做没做完，标准很明确：UI 跟设计稿一致、交互流程走通、没有报错。QA 测试用例跑一遍，通过了就是做完了。AI 产品没有这个「做完了」的状态。一个功能的完成度，取决于你的评估标准。

之前写「我的 AI 产品 Prompt 迭代了 20+ 版」那篇文章时，我提过一个数据：7 版 prompt 迭代，每版在 200 篇论文的测试集上跑 A/B 测试，用户满意度从 62% 爬到了 89%，持续了三周才稳定。这个过程中，最耗时的不是改 prompt，而是改评估标准。

第一版评估标准是「分类准确率 ≥ 80%」，后来发现用户不满意的不是分类错了，而是分类对了但摘要写得太笼统。于是加了「摘要信息密度」这个评估维度。后来又发现用户真正在意的是「能不能帮我判断这篇论文值不值得读」，于是又加了「决策可用性」维度。

这个过程就是「评估驱动开发」（Eval-Driven Development）：

1. 定义一个评估指标（准确率/满意度/信息密度）
2. 跑测试集拿到基线
3. 做改动（改 prompt/策略/参数）
4. 重新评估，看指标变化
5. 发现指标覆盖不到的盲区 → 加新指标 → 回到 1

// 评估维度的演进过程
V1: 分类准确率 ≥ 80%                  → 用户说"分类对了但摘要没用"
V2: + 摘要信息密度（含关键方法/结果/局限） → 用户说"知道了但不想读"
V3: + 决策可用性（能不能判断读不读）      → 用户说"靠谱，省时间"

这个思维方式对前端开发者来说是反直觉的。前端追求的是「代码正确 → UI 正确」的确定链条，AI 产品追求的是「模型输出 → 用户满意度」的统计链条。前端转 AI，不是换技术栈，而是换评估体系。 不再问「这个功能做完了吗」，而是问「这个功能怎么才算好，我怎么知道它变好了」。

什么时候这些能力不够？

说了三个能力，也得说说边界。Prompt 评估能力能解决 80% 的 prompt 质量问题，但遇到需要 RLHF 或者 fine-tuning 的场景，手工测试集就不够了------需要用户行为数据反馈闭环。数据链路调试能力解决的是"AI 产品为什么效果不好"的问题，但如果问题是「模型本身能力不够」（比如 3.8B 的小模型处理复杂推理），这个能力帮不了你，需要换模型或换架构。评估驱动开发在 MVP 阶段效率很高，但当产品进入规模化阶段，需要更系统的评估体系（离线评估 + 在线评估 + 用户满意度跟踪），一个人的手动测试只能覆盖一部分。

总结

回头看读者那个问题，我觉得前端转 AI 最需要补的不是 Python、不是 PyTorch、不是机器学习理论。是把「感觉」变成「基线」的本事 ------准确率是多少不是猜的，是跑 200 条测出来的。是把排查链路从浏览器窗口延伸到 LLM 的本事 ------出了问题别只看前端，往后看到模型层。是用评估标准代替「做完了」这个判断的本事------AI 产品没有终态，只有「在当前标准下够不够好」。这三个能力，WebView 前端都有基础------自动化测试、链路排查、工程化思维------只是需要换个方向用。不是重学，是复用。

---