企业官网建设流程全解析

见过太多这样的情况了：一个项目组说要做 AI，PPT 里全是路线图，讨论群里全是论文链接，模型原理也能讲得头头是道，但三个月过去，你问他“现在哪个页面能给用户点开用”，他沉默了。

我并不是反对学理论。Transformer 的注意力机制、RAG 的检索链路、Agent 的工具调用，这些都需要懂。但 AI 这个领域现在最大的问题不是大家懂得太少，而是做得太少。背一百个理论，不如交付一个能验收的应用。这篇是一个系列的开篇，我想围绕“AI 应用开发”和“验收”这两个关键词，把这件事掰开揉碎讲清楚：什么叫能验收的应用，怎么把它做出来，怎么证明它真的过了验收，以及我在实操里踩过的那些坑。

这篇文章适合几类人看：正在学 AI、简历上却一个项目经历都写不出来的同学；在传统软件团队里想引入 AI，却被“技术选型”卡住的朋友；以及那些带过项目、最怕“智能功能”做出来没人用、没法验收的管理者。

1. 为什么“背一百个理论”不如“交付一个能验收的应用”

1.1 面试场上的“理论派”和工位上的“交付派”

先讲一个我在面试里经常见到的场景。候选人简历写得很漂亮：“熟悉 Transformer 原理，了解 RAG 检索增强生成，对大模型微调有实践经验。”我一听，基础应该不错。于是我请他现场做一个很简单的题：我这里有一个 CSV 文件，里面是 500 条用户反馈，你帮我做一个脚本，按情感倾向分个类，再用一个简单的接口把它暴露出来。

结果很有意思。理论问他都能答上来，注意力机制的公式也能默写。但一碰实际操作，他先卡在 pandas 读取中文编码上，然后在调用大模型 API 时不知道如何处理返回结果，最后连一个最简单的 Web 框架都起不来。他不是不会答，是真的没完整做过一个应用。

这就是我说的“理论派”和“交付派”的区别。理论派的知识是一颗一颗的珍珠，但没有一条线把它们串起来。交付派当然也懂理论，但他知道一条完整链路是什么样：从数据清洗、模型调用、结果解析、服务封装，再到前端展示和部署，每一环都摸过一遍。企业里要的是后者。因为 AI 落地不是一个模型就能解决的事，它是一整条工程链路。

1.2 什么是“能验收的应用”：三条硬指标

很多人对“应用”这两个字有误解，觉得做了一个 Jupyter Notebook、跑通了一个推理脚本就算完成了。这不是应用，这是实验。一个能验收的应用，要同时满足三条硬指标。

第一条是“能用”。别人能通过一个界面、一个接口或者一个命令行，输入他的真实数据，然后得到输出，整个过程不崩溃、不超时、不报莫名其妙的错误。这意味着你要有输入校验、异常捕获、超时重试，而不是自己在本地调通了就行。

第二条是“有用”。这个应用必须解决一个具体问题，而且结果可以被验证。比如你做一个“客服工单分类助手”，用户上传一条工单，系统返回它属于哪个类别。那“有用”的定义就是：在 100 条测试工单上，分类准确率达到某个值，比如 85%。没有这个标准，就是“感觉挺好用”的玄学。

第三条是“可交付”。代码能部署到服务器上，有基本的说明文档，别人接手后不会一头雾水。我见过很多做得不错的 demo，最后死在部署环节：本地能跑，换台机器就装不上依赖，甚至没有写运行命令。可交付意味着稳定、可复用、有人能接手。

一个应用如果这三条都满足，那它才是可以拿去验收的。否则，不管是背了多少理论做出来的，都只是“半成品”。

2. 从零开始：把一个模糊想法拆成可落地的应用

2.1 第一步：把“我想做 AI”翻译成验收口径

我接触过很多想学 AI 应用开发的人，他们最常见的开场白是：“我想做一个 AI 应用，但不知道做什么。”这句话的毛病在于它不是一个需求，它是一个情绪。

要用一页纸把它翻译成具体需求。这一页纸只需要回答五个问题：用户是谁？现在遇到了什么问题？应用的核心输入是什么？核心输出是什么？怎么判断结果好还是不好？

举个例子。假设我是一家电商公司的运营，每周要手动处理 500 条售后工单。我想做一个 AI 应用，能自动把工单按“退款、换货、物流、态度投诉、其他”分类，并且标出紧急程度。那这五问就是：用户是售后运营人员；问题是工单太多、人工分类费时；核心输入是工单文本；核心输出是分类标签和紧急度；判断标准是分类准确率达到 85%，紧急工单不漏报。

这五问填完，你就有了一个清晰的验收口径。后面所有的开发都围绕这个口径展开，而不是边做边猜。

2.2 第二步：选型和范围收缩，新手最容易在这两步翻车

选型是第一个容易翻车的地方。很多新手一上来就纠结“我要不要微调一个大模型”“是用 RAG 还是靠提示词”“要不要上 Agent”。我觉得这个阶段最理智的做法是：先选成本最低、链路最短的方案。

参考我的选型原则：如果现有大模型 API 能解决，就不微调；如果检索类问题不复杂，先用提示词把资料贴进去试试；如果流程固定，就不要强行上 Agent。做第一个版本，你的目标是跑通和验收，不是炫技。下面是不同场景的选型参考：

选定方案后，还要做一件事：收缩范围。第一个版本只做一条主链路，不要做“多模态输入 + 多轮对话 + 知识库 + 推荐”这种大而全的东西。每多一个功能，验收难度就翻一倍。先做减法，把一个点打到极致。

2.3 第三步：做 MVP，把链路完整跑通

MVP 的意思是“最小可行产品”，它不需要完美，但必须完整。一个典型的 AI 应用 MVP 包含五个环节：数据整理、模型调用、结果解析、展示界面、简单反馈。

以刚才的工单分类为例，我的做法是这样。先用 Python 写一个清洗脚本，把工单文本里的空行、特殊符号、乱码处理干净。然后写一个调用大模型接口的函数，参数是工单文本，返回预定格式的 JSON。这里有个关键点：在提示词里明确要求模型返回 JSON，并且用代码做校验，拿到结果后取出分类字段，最后把一个简单的页面套上去，让运营人员能粘贴工单、看到结果、点“正确/错误”反馈。

我见过不少新手死在“展示界面”这关，觉得前后端太难，其实第一版根本不需要复杂的框架。Python 里用 Flask 或 FastAPI 写一个十几行的接口，前端用最基础的 HTML 页面就够了。核心是先把链路打通，把接口调通，让用户真的能点一下、看到结果。

2.4 第四步：从“能跑”到“能给别人用”

MVP 做完，链路跑通了，但离验收还差一步。这一步要解决的，全是不起眼但致命的小问题。

输入容错。用户不会按照你的预期去输入。有人会粘贴一整个表格，有人会带表情符号，有人只传一个截图。开发时不能假设输入是干净的，要写一层校验和清洗。比如工单分类的应用，如果用户误传了一个 Excel 附件，系统至少要给一个明确的提示，而不是报一个看不懂的堆栈错误。

结果可解释。模型输出一个“退款”标签，用户凭什么相信？如果能在结果旁边显示一句判断依据，比如“检测到关键词‘退款’、‘退货退款’，判断为退款类”，用户的信任度会大幅提升。这就是 AI 应用里常说的可解释性，它不是学术概念，是实打实的用户体验。

兜底策略。模型一定会出错，网络一定会抖动。你的应用有没有处理“回答不了”的情况？有没有超时重试？有没有人工兜底入口？很多 AI 应用把“模型出错”当成一个 bug，其实它是常态。接受这一点，在设计上留出缓冲，才是真正有交付意识的做法。

3. 验收实战：怎么证明你的应用真的“过了”

3.1 验收用例设计：不要只看“能跑”

到了验收环节，很多人会犯一个错误：现场演示一遍，看着结果不错，就说“验收通过”。但一次成功不等于可靠。真正的验收要用一套用例来跑，包含正常路径、边界输入、异常输入、模型幻觉场景。

我还是用工单分类来举例。正常路径是粘贴一条格式标准的工单，预期返回正确分类。边界输入是字符特别多、全是英文、只有一句话。异常输入是空文本、纯表情、乱码。模型幻觉场景是模型返回了 JSON 之外的格式，或者把“退款”和“退货”混为一谈。当这些用例全部跑完，你才有底气说“这个应用是稳的”。

我建议做一张验收用例表，每一条都写明输入、预期输出、实际结果、是否通过。这张表不仅是验收凭证，更是一个回归测试集：以后每次改代码，都把它拿出来跑一遍，确保旧功能没被改坏。我自己的项目里，这张表的重要性甚至超过代码本身。

3.2 现场演示：从“代码能跑”到“业务能走”

验收时最好有一次完整的现场演示，而演示是有技巧的。不要一上来就打开代码给你看，没人关心你的代码结构。正确的演示顺序是：先讲业务背景，再讲你要解决的问题，然后用一个真实的数据现场操作，最后展示结果和业务价值。

演示数据一定要用真实的，不要造一个完美无缺的“演示专用数据”。真实的用户反馈里往往有错别字、口语化表达、语气词，模型能够处理这些“脏数据”，反而更能证明应用的价值。我见过一个做舆情分析的项目，演示时用了最新一周的真实舆情数据，模型把一条带方言的骂人话识别出来了，评审现场直接加分。

还有一个细节：准备一个“B 计划”。万一现场网络断了，API key 失效了，大模型服务本身就不可用，怎么办？我的习惯是提前录好一段 30 秒的演示视频，再准备一组离线数据的预计算结果，出现突发情况时直接切换到备用方案。验收演示的本质是证明你有交付能力，不是证明你运气好。

4. 避坑指南：AI 应用交付中的常见问题与排查技巧

4.1 最容易翻车的五个交付场景

第一个翻车场景是模型输出不稳定。同一个输入，两次调用返回了不同的结果。这在分类、抽取、生成类任务里非常常见。对策很简单：把 temperature 参数调到 0 或接近 0，让输出尽量确定；如果业务允许，对关键结果做缓存；无法避免的不确定性，就在界面上加一个“重新生成”按钮，把选择权交给用户。

第二个是脏数据问题。中文编码、Excel 里多余的空格、PDF 抽取出来的文本整段乱掉，这些都是常规操作。我的建议是数据清洗环节不要省，写一个专门的 dataset_clean 模块，把清洗步骤编上号，每一步都打印日志。这样出了问题，你能快速定位是清洗的锅还是模型的锅。

第三个是部署环境差异。本地明明跑得好好的，一上服务器就报依赖冲突。这个问题要用 Docker 解决，把 Python 版本、依赖包、系统库全部锁进镜像。我在项目里一定会写一个 Dockerfile，哪怕第一次用的时候不太熟，也值得花这个时间。环境的一致性，是交付稳定性的第一道防线。

第四个是“做完了”但没人敢用。模型说这是退款工单，但运营人员不敢信，还是要点开原文确认，效率根本没提升。这种情况说明你的应用缺少可信设计。解决方案是让系统给出置信度，或者展示关键依据，再或者设计一个人工确认的环节。AI 不是替代人，是辅助人，这一点要刻在应用的基因里。

第五个是评审现场“翻车”。这个我在前面讲演示技巧时提过，再重复一遍，因为太重要了：任何外部依赖都有挂掉的可能，所以一定要准备离线数据、预计算结果和录屏视频，三选一，至少有一个兜底。

4.2 我的几条实操心得

做 AI 应用这几年，我总结了几条很朴素的道理。

第一，给自己定一个“两天演示版”的 Deadline。不管项目多大，先逼自己在两天内做出一个粗糙但完整的闭环。它不用好看，不用完善，但必须能让人看到输入和输出的关系。这个版本的价值在于让你建立全局观，知道难点在哪里，才不会把时间浪费在无关紧要的地方。

第二，每周做一次“陌生人测试”。找一个完全不了解项目的人，让他只看你的页面自己操作。这个过程会暴露大量你视而不见的问题：按钮不够明显、加载没有提示、报错看不懂。陌生人能正常走通流程，你的应用才算真正跨过了“自嗨”的门槛。

第三，把“验收”作为开发的一部分，而不是最后一刻才做的事。我的习惯是每天收工前，把核心链路和验收用例跑一遍，持续集成最好。有问题当天修，不要攒到最后统一处理。AI 应用的可变因素太多，越早发现问题，修起来越便宜。

第四，写好 README 和演示脚本。这两件事不会让你涨工资，但会让你在交付时省很多麻烦。README 写明环境依赖、运行步骤、已知问题和联系人；演示脚本注明演示顺序、每个步骤的预期结果、出问题时的应急预案。写完之后，你会发现哪怕一个月后自己回来维护，也能快速找回状态。

我自己带过的项目里，凡是能做到以上几条的，最后都顺利交付并上线了。而那些天天争论“用哪个框架更先进”“要不要训练自己的模型”的项目，大多还在会议室里转圈。

这个系列后面我还会继续写，包括 AI 应用开发的完整学习路线、Agent 应用的验收标准、以及具体的端到端实战案例。如果你正在学 AI，建议停掉下一门网课，把脑中的一百个理论，收敛成这周就能做出来的一个小应用。哪怕它只处理一个问题，只服务一个人，只要能真正跑起来、经得起验收，它带给你的成长，远超十篇论文。