一个月里我边做项目边攒下来一批值得反复看的东西有文章、有工具、也有自己踩出来的思路。这期的核心其实是三个关键词LLM 评估、AI 副项目、用户友好的数据表格。这三个词看起来是三个方向实际上背后是一条线——都在解决“AI 应用怎么从能跑到好用”的问题。先说判断。LLM 评估是我长期建议团队里每个人都去碰一下的方向理由很简单你不评估就不知道自己改的系统是变好了还是变差了。AI 副项目则是练手性价比最高的方式工作里的项目不一定能让你完整走一遍从建模到评估到上线的闭环副项目可以。数据表格看着不起眼但用户每天的体感有一半来自这种“基础设施”国内外很多产品就差在表格这一层上。这篇文章我会按“评估方法”“副项目怎么做”“表格怎么改”“其他值得读的方向”四条线展开。每条线都有我实际跑过的记录也有能直接抄作业的配置和清单。你如果看完能挑一个方向动手试这文章就算没白写。1. LLM 评估从“感觉变好了”到“确实变好了”1.1 为什么这个事比想象中重要我见过太多项目死在“效果不知道好不好”的模糊状态里。系统上线前几个人拿十几条样例跑一轮凭感觉说“还行”上线以后用户反馈变了又找不到是哪一轮改动引起的。整个迭代过程就像闭着眼睛开车全凭运气。LLM 应用最麻烦的地方在于输出不确定。同样是一个问题温度、模型版本、甚至单词拼写多一个空格结果都能有差异。没有评估所有的“优化”都无从谈起。你让大模型加了一个 system prompt 指令到底有没有用加了之后命中了多少损失了多少这些问题只有用评估集跑一遍才能回答。评估的重要性不在于“量化”本身而在于它能让你把一次次的直觉判断变成可对比的版本记录。评估的底层逻辑和写单元测试一样把期望行为显式化每次改动跑一遍防止回归。我经常跟朋友说LLM 评估就是“给提示词写的单元测试”只是断言方式更灵活而已。1.2 三个层次任务级、模型级、系统级做评估的第一步是分清评估对象不然指标会打架。我自己习惯分成三层来看。任务级评估针对的是单个输出。比如摘要够不够准确、抽取的字段对不对、分类结果是否合理。这一层对应的是模型的输入输出本身是最基础的粒度。模型级评估则带着上游信息看检索回来的文档里到底有没有答案、指令本身有没有歧义、模型在什么错误路径上反复犯错。这一层往往能暴露数据问题而非模型能力问题。系统级评估是站在用户视角把一个完整交互流程当作整体来看。用户问了一个问题系统经过了改写、检索、重排、生成最后给出的答案用户能不能直接用中间任何一环的噪声都可能被下游放大。我自己实际跑的案例里有一个文档问答系统模型本身能力没问题但检索环节召回了两篇矛盾文档导致每次生成都是“信息混合体”。任务级指标上看不出问题只有系统级评估才能抓出来。1.3 指标怎么选不要只盯准确率我一开始也犯过只盯准确率的毛病后来发现这个指标太钝了。对于分类任务可以用准确率、精确率、召回率但生成类任务要看的维度多得多。现在实践中比较常用的一组维度是相关性回答是否切题、忠实度是否忠于引用或给定材料、完整性覆盖了用户问题的几个方面、流畅性表达是否自然通顺、可读性用户能不能直接复制使用。其中忠实度是特别需要单独盯的因为 LLM 幻觉最致命的表现就是“输出很流畅但内容不对”。另一件值得做的事情是记录“翻转率”flip rate。同一份输入在不同模型版本间跑输出从对变成错的比例。我习惯在每次模型或提示词改动后把同一组评估集重新跑一遍统计翻转率。翻转率低说明这次改动是稳定的翻转率高就要特别小心。这比单纯看平均分变化更能体现改动的真实影响。相关性和忠实度应分开标注不要混成一个“质量分”同一评估集至少跑 3 次观察不稳定输入指标报告里永远带上当次模型版本号和评估集版本号1.4 评估工具链怎么落地而不是停留在文档里聊完指标落到执行上。我的评估方案一直很朴素一个评估集 一个 runner 一个报告。评估集是 JSONL 文件每行一条输入输出对和期望结果或检查规则runner 可以是几十行 Python也可以是现成的框架报告负责把每次跑完的对比结果汇总出来。核心不在于工具多高级而在于每次改动都能一键重跑。LLM 作为裁判LLM-as-judge是目前比较实用的自动评估方案。用一个更强的模型输出评分用另一个模型或同样的模型做交叉打分取平均或多数表决。这里的关键是“裁判”本身也要被评估。我实际用的方法是准备一组人工标注过的样例跑完自动评估后对比人工和模型的打分一致性低于 70% 就说明裁判模型不合格需要换参或换模型。# 伪代码示意一个最简评估 runner for case in eval_set: response llm.generate(case[input]) judge llm.judge(response, case.get(expected)) record(case[id], response, judge) report()不需要一上来就整复杂平台。先跑起来再逐步加维度。真正让评估跑出价值的不是平台的功能数量而是你有没有一套固定的评估集。2. AI 副项目练手价值远大于完成度2.1 副项目到底能练什么很多朋友问我业余时间做 AI 项目应该选什么方向我觉得答案不取决于“什么方向最火”而取决于“什么方向能补齐你现在工作里的短板”。工作里可能为了赶进度跳过一部分节省时间的关键工作副项目是补这块最短板的绝佳机会。如果日常工作偏业务调用不太深入模型细节那么副项目适合选“从零训一个小模型”或者“自己搭一个 RAG 全流程”。原因是这类项目能逼着你把数据清洗、索引构建、评估、调优整个链路走完。如果日常工作已经在写 prompt副项目可以选“把同一个场景的工具做成一个完整的小产品”侧重工程化和用户体验。我自己的个人项目经验是副项目最重要的产出不是一个漂亮的 demo而是一套可以复用的模板和踩坑记录。做过一个自动摘要工具代码部分其实两天就写完了后面两周全在应付各种边缘 case——千字以上的长文怎么分段、专业术语怎么保留、用户粘贴的文档里有表格怎么处理。这套处理逻辑后来直接搬到了正式项目里省了非常多时间。2.2 选项目的三个原则给副项目筛选方向时我建议遵守三个原则边界清晰、可量化、可增量交付。边界清晰指需求范围不能无限扩散。比如“做一个 AI 文档助手”就太模糊了不如“只处理 PDF 格式的合同输出条款摘要和风险点提醒”。范围收得越窄完成概率越高。可量化指项目有明确的完成标志。比如“对 20 份真实合同样本摘要的忠实度人工评审达到 90% 以上”比“效果尽量好”可执行得多。可增量交付是最容易被忽略的。副项目最怕的是做两个月还拿不出一个能用的东西。我习惯把一个完整的副项目拆成 3 个版本V1 能用命令行跑通一个完整流程、V2 好用增加交互界面和错误提示、V3 能在小范围真实使用接上真实数据加上评估和日志。每个版本都是独立可交付的不会因为中途放弃而颗粒无收。2.3 从一到一副项目复盘的价值比起从零到一更值得做的是“从一到一”——把一个已知可用的流程在不同场景里再复制一遍。比如你在正式工作里做过一个检索增强生成系统副项目不妨换个垂直领域再做一次重点体会不同数据形态对系统的要求变化。这种复刻式副项目的学习效率非常高因为省去了大量入门探索时间可以直接研究“换场景之后哪里变了”。我做第二个 RAG 系统时的体会是换到医学资料类文档后最大的变化不在模型而在检索策略——医学资料的术语密度高、同义词多简单的向量检索经常带回无关内容。这个发现直接让我理解了“RAG 的瓶颈很多时候在检索环节”这句话的真实含义。副项目也可以是对工作里一个糟糕方案的修正。比如工作中发现某个环节因为交付压力只能直线解决问题副项目可以再花时间构造一个合理的方案并验证效果。这种“修正型副项目”的回报特别高一方面你有真实数据另一方面验证结果随时可以反哺工作。3. 用户友好的数据表格别让用户“看数据”让用户“找信息”3.1 表格难在哪里我总觉得表格是产品体验里被严重低估的组件。它看起来简单无非是行列和单元格但实际使用中用户的瓶颈从来不在于“看不看得见”而在于“找不找得到”。一个有几百行几十列的数据表格如果只是把数据堆上去用户浏览时完全靠硬找那这个表格就是不合格的。用户真正想要的是表格能回答他心里的问题哪些单子异常哪些指标在下降哪个项目的状态需要跟进表格的任务不是展示数据而是帮助用户完成“定位”这个过程。我实际参与过的项目里数据表格被用户骂得最多的点主要是列太多看不到自己关心的字段、数字列没有对齐难以比较、状态信息只靠颜色区分导致色弱用户无法使用、没有默认排序导致每次进来都要手动点一遍。这些问题的一一对应解法其实很成熟只是很多团队没意识到“表格也是需要设计的”。3.2 列与行的取舍逻辑设计表格的第一步是决定哪些列值得展示。我推荐的流程是先列全再按用户任务排序最后裁剪。先把你觉得相关的字段全列出来然后回到用户的任务场景按“找信息的关键路径”给列排序最关键的 5 到 7 列留在默认视图剩下的收入“自定义列”或展开详情里。关于列宽“自适应”不一定是好事。文本类的列需要留足空间数字类的列要尽量压缩并对齐。数字列右对齐 千分位分隔符是一个几乎不会被拒绝的要求而且能大幅提升比较效率。日期列用相对时间加绝对时间的写法比如“3 天前2025-10-02”比单独一个日期更直观。行的问题更多出在密集度上。行高太矮整张表在用眼搜索时扫起来很费劲行高太高一屏看不到几条数据又得频繁滚动。我自己的经验是默认行高控制在 32 到 40 像素之间关键场景允许用户切换“紧凑模式”。还有一条重要原则鼠标悬浮一定要有整行高亮这个看起来微不足道的交互能显著减少视觉串行。3.3 排序、筛选和搜索的配合“用户友好”很大程度体现在用户能不能用最少的点击找到数据。默认排序一定要有。我见过太多的表格默认按数据库主键排序展示出来的完全随机感让用户没法形成“上次看到这里”的位置记忆。按时间倒序是最常见的默认选择有明确业务优先级的场景比如异常在前则按业务逻辑排。筛选和搜索的关系也值得说。筛选适合字段值有限的维度比如状态、来源、负责人搜索适合内容型字段比如标题、编号、描述文本。两者并不互斥实操中可以做成搜索框负责跨所有文本字段的检索筛选面板负责结构化的字段过滤二者叠加生效。一个容易出问题的细节是筛选后结果的计数反馈。用户筛选完不知道还剩多少条、离目标还差多少体验会打折扣。在表格顶部显示“筛选后 1,234 / 共 2,000 条”这种轻量反馈成本极低价值却很大。另一个细节是筛选条件默认要保留在 URL 或持久化存储里用户刷新页面后筛选状态还在这属于“不用用户开口就能加分的体验”。3.4 落地实现中的性能与交互平衡前端实现表格时最大的坑是“为了性能牺牲交互”和“为了交互牺牲性能”两头塌方。超过几千行数据直接用传统一次性渲染就会出现卡顿和样式错乱。好的表格在处理大数据时通常带虚拟滚动只渲染可视区域内的行。但用了虚拟滚动之后像“全选所有行”这种操作就需要定义清楚是选中当前可视行还是选中所有数据行。这个决策不做数据一超过一屏就会出现状态混乱。列冻结也是高频需求。用户要经常对照前两列名称、编号横向滚动查看后面的状态列这时候就需要冻结前几列。注意冻结列数量过多会吃掉大量可视宽度一般不建议冻结超过 2 列。复杂程度需要区分。几十行数据不要上重型复杂组件原生表格加少量事件绑定就够了。几万行数据则更推荐用成熟组件库配合虚拟滚动。这里的原则是“用最轻的方案满足当前场景”不要为了未来的不确定需求提前上重工具。提示表格性能的终极优化不在前端渲染而在数据量本身。能从后端少返回 10 列数据前端少做 10 列的渲染工作。接口层面支持按需字段、筛选字段和排序字段比前端施展各种优化手段要有效得多。3.5 空状态与边缘场景的处理表格好不好用一部分体现在数据满的时候另一部分体现在数据不足的时候。空状态是特别容易被忽略的细节。很多产品数据为空时直接显示一张空白表格用户根本不知道接下来该做什么。好的空状态应该包含三样东西说明当前为什么没有数据、提供一个重新查询的动作、给出一个调整筛选条件的建议。比如“当前筛选条件下没有符合的记录尝试清除筛选条件”。加载状态也要讲究。首次加载用骨架屏加载期间不要整表闪动导致视觉跳动。失败状态一定要给出可操作的重试按钮不要只显示一行“数据加载失败”就不管了。这部分细节不需要高深技术但能直接影响用户对产品整体质量的判断。4. 十月必读的其他方向挑几个有价值的说4.1 结构化输出与工具调用这个方向我个人实测收益最大的是让 LLM 输出严格符合 JSON Schema 的能力。之前花太多时间在“解析模型输出为合法 JSON”的容错代码上引入结构化输出后代码量大为降低。结构化输出解决的不只是格式化问题更是“稳定连接”的问题。让输出严格符合结构后续代码才能真正把它当作程序里的一个数据对象处理而不是永远做防御式解析。建议所有做 LLM 应用的人都了解一下尽早开始使用。这个方向的学习材料大多是工具文档加示例 demo动起手来比较快。4.2 小模型本地部署的性价比大模型接口虽方便但敏感场景和成本压力让不少人开始重新审视小模型本地部署这条路。今年这个方向的进展很明显小模型的工具能力和指令遵循能力大幅提升很多日常场景已经够用。我实测下来的经验是与其纠结单模型的能力上限不如把任务拆小让每个子任务选择合适的模型。摘要、抽取、分类这类任务用小模型本地跑复杂推理才调用更重的模型。这样做的好处不只是省成本还有响应速度的提升和数据安全感的增强。代价是要维护多套模型的部署和调度对工程能力有一定要求。4.3 语义缓存一个不该现在才知道的概念做 LLM 应用的人都该了解一下语义缓存。原理是通过向量相似度判断用户“新问题”是否和之前某个问题语义相近如果相近就直接复用之前的回答不再调用模型。这个机制最直接的价值是降成本和降延迟。实际业务中用户问的问题是呈长尾分布的头部高频问题的命中率其实相当可观技术类问答场景的缓存命中率普遍很高。但要注意语义缓存只能用于不介意“时效性”的回答比如知识库问答、产品说明、常见问题解答。涉及价格、库存、实时数据变动的场景不适合直接用缓存答案。我之前在一个可实时变动的业务场景简单应用它结果用户看到几天前的答案差点闹出问题教训深刻。4.4 可观测性LLM 应用的追踪和回归测试模型调用的可观测性也是这一阶段的必读主题。之前排查问题靠直觉花费大量时间。引入追踪后一次完整问答从用户输入到检索、到模型调用、到最终输出的每一步都看得见排错和调优的时间和之前相比显著缩短。做 LLM 应用需要一个最基本的追踪方案记录每次调用用了哪个模型版本、输入了什么、输出了什么、tokens 是多少、耗时是多少、是哪个用户发起的。有了这些原始记录所有上层分析才能开展。如果不想自建也可以用现成的可观测性工具但要确保日志里带上完整的上下文 id这是你以后回溯问题时最宝贵的锚点。4.5 阅读和学习的方法带着问题读别只收藏聊到读书方法我们回到“十月必读”这个话题。信息获取从来不是问题问题在于消化和落地。我的习惯是任何一篇文章读之前先想清楚“我看完能从里面拿走什么可以直接用”。这个问题一般围绕当前在做的事情提出效果比漫无目的的阅读好得多。读到有用的部分不要只做摘抄而是立刻落到自己的环境里测试一遍。我读技术文章时往往跳到可执行的示例代码段直接复制进自己的项目测试一次记录结果。只有这一步完成了这篇文章才算是你的。收藏夹里的文章再精彩不经过这一步永远只是“收藏过”不是“读过”。5. 结尾给月读清单划一个落地的标准每次做月度盘点我习惯最后给自己定一条“接下来一周能动手做什么”的标准。这份清单也不例外——评估方法对应的是给现有项目加一个最简评估脚本副项目对应的是挑一个工作里绕不过去的短板去练一遍数据表格对应的是把自己产品里最常被投诉的那张表按上面的思路重新改一版。我个人在实际操作中最大的体会是这三个主题其实串在一条主线上——判断一个 AI 应用有没有真的变好靠的是评估有没有真的用好靠的是副项目的复刻式练习用户有没有觉得体验好最具体的体现之一就是那张每天都要看的表格。十月剩下的时间不多挑一个最让你手痒的方向动手跑一版记录下前后对比这比把这份清单从头到尾看完更值得。