企业官网建设流程全解析

一个月里我边做项目边攒下来一批值得反复看的东西，有文章、有工具、也有自己踩出来的思路。这期的核心其实是三个关键词：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 应用有没有真的变好，靠的是评估；有没有真的用好，靠的是副项目的复刻式练习；用户有没有觉得体验好，最具体的体现之一就是那张每天都要看的表格。十月剩下的时间不多，挑一个最让你手痒的方向，动手跑一版，记录下前后对比，这比把这份清单从头到尾看完更值得。