企业官网建设流程全解析

“ai-engineering-from-scratch”这个项目，翻译成人话就是：不依赖任何现成的AI套件，从模型接入、提示词设计、服务封装、质量评估到成本控制，自己动手搭一条完整的AI应用生产线。我给自己定的目标很简单：在真实业务里跑通一个由大模型驱动的功能，而不是只在笔记本上跑通一个demo。这篇文章记录的就是这条线路上最关键的决策、最常踩的坑，以及我最后沉淀下来的一套可复用的操作流程。

很多人会把AI工程理解成“调一调提示词、把模型API接进来就完事”，但真正到了生产环境里，你会发现差异全藏在细节里：模型返回了非法JSON怎么办？用户输入超长怎么截断？接口超时是重试还是降级？同一个问题换一种问法结果就漂了又该怎么兜底？这些才是“工程”二字的真正含义。下面我就按照从拆解需求到上线优化的顺序，完整走一遍这个项目。

1. 先把“AI工程”四个字拆明白

1.1 这不是调参，是搭生产线

AI工程和算法研究最大的区别在于目标不同。算法研究追求的是模型效果的边界，而AI工程追求的是“在有限成本、有限时间、有限可靠性要求下，让模型稳定产出可用结果”。所以你会发现，一个合格的AI工程实践，核心动作往往不是写更聪明的提示词，而是设计一套机制，让模型即使偶发犯错，整体系统依然能交付结果。

我在拆解这个项目的时候，把整个链路拆成了五层：输入层负责清洗和校验用户数据，上下文层负责决定哪些内容该进提示词，模型层负责实际推理，解析层负责把模型的自由文本变成结构化数据，兜底层负责处理一切异常。每一层都有独立的判断标准，层与层之间通过明确的接口对接。这种分层方式带来的直接好处是：出问题时你能第一时间定位是哪一层坏了，而不是对着整段代码发愁。

1.2 为什么“从零开始”反而更有价值

我见过太多团队“接入”大模型很快，但“用好”大模型很慢。原因在于现成的SDK帮你省掉了接入的体力活，却没法替你做判断：这个场景适不适合用大模型？用哪种模型？温度参数怎么设？输出结构怎么保证？上下文塞多长才划算？这些判断力只能靠完整的项目实践练出来。

从零开始搭这个项目，逼着我走完了每一个环节。没有现成的封装库，我就得自己处理流式输出；没有现成的评估脚本，我就得自己标注测试样本；没有现成的监控看板，我就得自己记录Token消耗。这个过程很琐碎，但恰恰是这些琐碎的地方，藏着AI工程真正的门道。等这些基础能力都过了一遍之后，再去看市面上各种框架，你会一眼看穿它帮你做了什么、没帮你做什么。

1.3 这条路线适合谁

如果你是想在真实项目里落地AI功能的工程师，这篇文章的路线和踩坑记录值得从头看一遍；如果你是刚入门、想从“会调用接口”进阶到“会设计AI系统”的同学，可以把第三部分的实操代码当作一个起步模板；如果你是团队里负责技术选型的人，第二部分关于接入方式和模型部署的对比可以直接拿来当参考。

我不建议完全照搬我的技术栈，但建议你保留我那份“拆解需求→定义验收标准→选型→写提示词→搭服务→评估→优化”的顺序。这套顺序本身比任何具体工具都重要。

2. 工具链选型与核心概念解剖

2.1 大模型接入的三种姿势

动手写代码之前，先要决定模型怎么接进来。我把常见的接入方式分成三种，实际项目里可以根据阶段灵活切换：

我的建议是：项目初期直接调用商用API，把精力花在业务逻辑上。等业务量起来、需要对比多家模型或者做容灾切换时，再补一个转发层。过早抽象反而会增加工作量。我见过有人第一步就搭了一个庞大的模型网关，结果后面三个月都在维护网关本身，业务功能一点没推进。

2.2 提示词工程的三个层次

提示词工程不是背模板，而是控制模型的输出分布。我习惯分三层来写：

第一层是角色与任务层，告诉模型“你是谁、目标是什么”。这一层决定了模型整体的行为基调。第二层是约束与格式层，给出输出结构、长度、语言、风格要求。这一层是工程化最依赖的部分，因为只有约束明确，下游解析代码才好写。第三层是示例与边界层，给出一两个正面样例，再说明什么情况下不要怎么做。

举个例子，我在做“会议纪要素材整理”功能时，第一版提示词只写了“把下面这段会议录音转成要点”，结果输出经常自带“以上就是本次会议的全部内容”之类的废话。改成“你是一名会议记录助理。请从以下转录文本中提取决定、待办事项、责任人三类信息。输出为Markdown列表，不输出任何寒暄”之后，输出质量立刻上了一个台阶。关键区别在于把“输出行为”限定死了，而不是让模型自由发挥。

2.3 Agent不是玄学，是任务分解协议

搜索引擎里“AI Agent”的热度一直很高，不少人把它当成某种神秘能力。我的理解非常简单：Agent就是“模型+工具+循环”的组合。模型负责推理，工具负责执行动作，循环负责检查结果并决定下一步。

让它可靠运转的核心，是一份清晰的任务分解协议。协议里要写清楚：什么情况下调用哪个工具，工具返回什么结果算成功，失败之后回退到哪一步。很多Agent翻车的根因不在模型不够聪明，而是协议定义得不清晰。比如“帮我查一下订单状态”这句话，模型理解了语义，但不知道该调“订单查询”接口还是“物流查询”接口。把协议细化到这种程度，比单纯换一个更大的模型管用得多。

2.4 模型部署的基本形态

模型部署听起来偏后端，但其实牵扯到整个系统的交互设计。我梳理出三种基本形态：

• 在线推理：请求一来立刻处理，适合实时对话、实时内容分析。
• 批处理：定时喂一批数据进去，统一产出结果写回存储，适合离线报告、批量审核。
• 流式输出：服务器边生成边推送，前端像打字一样逐字显示，能显著降低用户等待感。

我在第一版里只做了在线推理加流式输出，把主流程跑通；批处理等业务量上来之后再补。部署形态不必一步到位，但要在架构上留出扩展空间，比如把“模型调用”封装成独立模块，后续加批处理时不用动业务代码。

3. 实操：从一条指令到一个可用功能

3.1 先定义验收标准，再写代码

工程化的第一步不是写代码，而是把“效果不错”变成可检查的指标。我这个项目做的功能是内容分类与标签生成：用户给一段文本，系统输出它的分类和3到5个标签。

验收标准我一开始就定了三条：分类准确率达到90%以上（拿50条人工标注样本做测试）；标签必须来自预设词表，不允许发明新标签；单次请求的端到端耗时不超过3秒。这三条标准看起来简单，但它决定了后面所有技术选型：要控制耗时，就用流式输出和轻量模型；要限定标签，就在提示词里给出完整词表并让模型只输出一个JSON对象。

没有验收标准的最大风险是“感觉还行”式交付。你觉得模型输出挺像样，业务方也觉得挺像样，但一旦接到真实流量，各种边缘情况全冒出来，这时候再回头补标准，成本就高了。

3.2 提示词版本的迭代过程

提示词不是一次写好的，我经历了四个版本。

V1只有一句话：“给下面的文本分类并打标签”。输出格式随意，经常把标签写成完整句子。

V2增加了输出结构约束：“输出JSON，包含category和tags两个字段”。这下能解析了，但分类标准混乱，“科技新闻”和“数码评测”经常混在一起。

V3给出了分类定义和词表：分类只能从预设列表里选，标签必须是词表中的词语，不能自创。准确率明显上升。

V4又增加了一个少样本示例，给出一个输入和期望输出的对照。这一次不仅准确率上去了，连格式都完全可控。

整个过程中我坚持一条原则：一次只改一个变量，改完立刻拿同一套测试集跑对比。别同时改温度参数和提示词，不然出了问题根本不知道是谁的锅。

3.3 服务端代码结构与流式输出

我用的是Python FastAPI加一个简单的内存缓存，代码结构大致是这样：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Item(BaseModel): text: str @app.post("/classify") async def classify(item: Item): # 1. 参数校验 if len(item.text) > 2000: return {"error": "text too long"} # 2. 提示词拼装 prompt = build_prompt(item.text) # 3. 模型调用，走流式 result = await call_model(prompt) # 4. 输出解析与校验 parsed = parse_output(result) # 5. 兜底返回 return parsed

分层很清楚：校验、拼装、调用、解析、兜底各管一件事。实际开发时，我建议把build_prompt和parse_output单独拆文件维护，因为它们会频繁迭代，独立出来后方便做版本管理。

流式输出值得单独说一下。大模型接口普遍支持流式返回，服务端拿到首块内容就可以推给前端，用户感知到的首字延迟会明显下降。但这里有个容易忽略的细节：流式传输时HTTP应答头要设置Transfer-Encoding: chunked，前端也要用onmessage方式逐块渲染。我第一次实现时没在意这个，结果前端要等全部输出完才显示，体验跟非流式一模一样，等于白做。

3.4 质量评估与回归用例

在AI工程里，评估体系就是“测试用例”。我维护了一份固定的测试样本集，大约50条真实文本，每次改提示词、换模型之后，都会把整份样本集跑一遍，记录分类准确率和输出可解析率。

另外我还加了一个自动断言：输出必须能被json.loads解析，category必须命中预设分类，标签数量必须在3到5之间。凡是跑不过断言的，就人工检查是模型能力问题还是提示词引导问题。

这套回归体系在后面一次模型版本升级时帮了大忙。新模型看上去更强，但跑完测试集发现，它在少数边缘样本上的分类结果和旧模型不一致，而且从业务角度看是退步的。要是没有这套评估，我可能就直接上线了。

4. 常见问题、排查技巧与成本优化

4.1 模型输出总是“飘”怎么办

输出“飘”是指同样类型的输入，结果时好时坏，没有规律。我的排查顺序是固定的：

1. 降低温度参数，一般从0.7降到0.2左右；
2. 检查提示词里是否有歧义，把分类定义写得更细；
3. 增加少样本示例，让模型照猫画虎；
4. 如果还不行，换一个更强的模型跑一遍对比，判断是引导问题还是模型能力问题。

这里最容易被忽视的是温度参数。很多人把它当成摆设，其实它控制的是回答的随机性。对结构化输出任务，0.1到0.3是合理区间；对创意型任务才需要0.7以上。我见过有人在做分类任务时把温度设为1.0，结果同样的输入每次返回的标签都不同，还以为是模型出 bug 了。

4.2 Token用量失控

Token用量是AI应用成本的大头，我踩过最经典的坑：把整本产品手册塞进提示词里当背景知识，结果每次请求都在烧钱。后来改成先做关键词检索、按需拼装上下文的方案，Token用量直接砍掉七成。

控制Token我做了三件事：第一，给系统提示词设定长度上限，超过就抛异常，防止拼接逻辑把无用的长文本带进来；第二，给返回内容设置max_tokens，防止模型啰嗦，同时在业务层丢弃超长输出；第三，在业务侧做上下文裁剪，只保留对当前任务有用的片段，而不是能给的都给。

这里有一个容易忽略的权衡点：Token用量和模型质量往往成正比，上下文越全，回答越准。所以裁剪时要先做小范围实验，确认质量不掉太多再上线，别为了省钱把模型效果砍没了。

4.3 并发瓶颈和缓存策略

服务上线之后，难免被并发请求打满。我的方案分三层：

• 缓存层：相同输入在前几分钟内直接命中内存缓存，减少重复计费。
• 限流层：给每个调用方设置每分钟请求上限，防止单个用户把配额吃光。
• 降级层：主模型超时后自动切换到备用模型，同时返回一个质量稍低但依然可用的结果。

这套策略里最容易遗漏的是“降级层”。接口不可能永远不出问题，出问题时宁可返回一个可靠的低质量结果，也不要让整个页面挂掉。我处理过一次线上事故，主模型服务端抖动，所有请求都在排队，页面全部白屏。加了降级逻辑之后，同样的场景顶多是回答质量差一点，但功能始终可用。

4.4 可观测性：日志、评估、追踪

AI应用的可观测性比传统应用多一层：不只记录请求和响应，还要记录提示词版本和模型版本。我习惯在每条请求日志里带上prompt_version和model_name两个字段，线上出问题时可以快速定位是提示词改坏了还是模型换坏了。

请求耗时和Token消耗我也会按天统计，按模型维度看当天的调用次数、平均延迟、总Token数和花费。这张统计表就是成本监控的底表。某天费用突然翻倍，我先看哪个模型消耗变大，再看是哪个功能调过来的，基本五分钟内就能定位问题。

4.5 实战问题排查速查表

这张表是我平时处理问题的起点。每遇到一个新问题就往里补一行，现在已经攒了几十条。排查时先看表，能解决大半问题；解决不了再深入看日志。

5. 接下来还可以往哪边走

5.1 多Agent协作的工作流实验

单Agent做到一定程度后，我尝试了多Agent协作。一个典型的实验是把内容生产拆成两个角色：写手Agent负责生成初稿，审校Agent负责按标准检查并返工。效果不错，但代价是Token消耗翻倍，响应时间也变长了。

我的建议是：先用单Agent解决问题，确实出现单模型无法兼顾的质量瓶颈时，再拆多个Agent。别为了赶潮流而拆。多Agent的真正价值在于隔离不同任务的质量标准，而不是字面上的“多个模型一起干活”。

5.2 RAG接入后的数据飞轮

把项目从demo变成真正好用的工具，最值得加的是RAG（检索增强生成）：先准备知识库，用户提问时检索相关片段，再把片段拼进提示词，让模型基于事实回答。这样一来，模型不需要记下所有知识，也能给出有依据的回答。

做了RAG之后，我发现一个隐含的正反馈：用户每次提问和纠错，都可以沉淀为新的知识片段。知识库越用越准，回答质量也随之上升。这就是所谓的数据飞轮，它比单纯调提示词的杠杆大得多。如果你做的功能是问答、客服、文档分析这一类，我建议尽早把RAG纳入规划。

5.3 走向生产环境的最后三件事

最后说三件容易被忽略但很关键的事：

• 安全边界：用户输入里可能夹带恶意指令，服务端必须有独立的过滤和长度限制，不能盲目信任模型输出。该拦截的拦截，该脱敏的脱敏。
• 灰度发布：新提示词不要一次性全量上线，先放5%流量观察指标，没问题再逐步放大。提示词改动看起来小，实际影响范围可能很大。
• 成本告警：设定每日费用阈值，超过阈值自动停掉重模型调用或者发告警通知，避免睡一觉起来账单爆炸。

这三件事花不了多少时间，却能在关键时刻拦住绝大多数生产事故。上线前多问自己几个“如果”，比事后补锅划算得多。

我自己的体会是，从零开始搭AI工程，真正的难点不是某一个具体技术点，而是把“模型能力”和“工程约束”对齐的过程。模型的输出天生带有概率性，工程系统恰恰最排斥不确定性，两者之间的磨合，就是AI工程师的核心价值所在。每踩一个坑，你对这层对齐关系就多一分理解。

这个项目做完之后，我养成了一个习惯：任何AI功能上线前，先问自己三句话——如果不返回结果怎么办？如果返回错结果怎么办？如果调用失败怎么办？把这三个问题回答清楚了，这个功能的可靠性基本就有保障了。这套思路也分享给你，希望你的AI工程之路能比我少踩几个坑。