企业官网建设流程全解析

这几年“AI工程”这个词被炒得越来越热，尤其是在GitHub上刷到“ai-engineering-from-scratch”这类项目时，很多人的第一反应是：这跟“Prompt Engineering”有什么区别？跟“调API”又有什么区别？我自己在把几个真实业务场景落地之后，最大的感受是——AI工程不是某个单一技能，而是从“能跑通”到“稳定跑、能维护、可评估、敢上线”的一整套方法体系。这篇文章不聊大模型内部原理，也不做算法推演，只讲怎么从零开始把AI功能做成工程化产品，包含工具选型、流程设计、踩坑实录和一套可以直接抄走的实践模板，希望能对正在从“会调接口”走向“能做工程”的朋友有些实际帮助。

1. 内容整体设计与思路拆解

1.1 为什么“从零开始”的关键不是模型，而是系统

很多人学AI工程时容易陷入一个误区：花大量时间追最新的模型榜单、研究各种推理框架，却忽略了一个基本事实——在一个真实项目里，模型能力只占最终效果的一部分，甚至不是最大的一部分。数据质量、任务拆解方式、提示词策略、输出校验、失败兜底、监控评估，这些环节共同决定了用户实际感受到的“智能程度”。

我见过好几个团队拿着开源大模型做了很惊艳的Demo，但一上生产环境就崩：有的因为输出格式不稳定导致下游解析报错，有的因为用户在连续对话里“绕晕”了模型导致意图识别错乱，还有的因为响应延迟高、成本估算错误被业务方直接否决。“从零开始”的真正含义，是你愿意在模型之外花同等的精力去设计周边系统。

这里可以用一个生活类比来理解：模型像一个天资不错的厨师，AI工程则是餐厅的后厨管理体系。厨师再厉害，没有标准菜谱、没有食材质检、没有出菜顺序管理，面对高峰期一样会翻车。AI工程做的事情，就是把“厨师的手艺”变成“餐厅可复制、可扩张的出品能力”。

从这套思路出发，一个合格的AI工程团队至少要覆盖四个角色能力：任务定义（把模糊需求拆成机器可执行的任务）、输入工程（数据清洗、格式规范、示例组织）、输出控制（结构化生成、校验、纠错）、效果评估（离线测试 + 线上监控）。不一定是四个人，一个人如果能把这四件事都跑通，就已经比很多只会“写提示词”的开发者强一个量级了。

1.2 边界意识：先确定“什么不该让AI做”

我踩过最大的坑之一，是早期恨不得把所有功能都塞给大模型处理。“既然模型什么都会，那就让它直接输出结构化数据好了”——这个想法听起来很香，实际上会让系统变得不可控、不可预测，成本还高。

真正成熟的AI工程思路是：最小化模型承担的责任。能靠正则、规则、穷举、传统NLP解决的问题，绝不调用大模型；必须让模型做判断和生成的地方，尽量把任务切小，给足约束条件。比如一个客服工单分类系统，如果类别总数不超过50个，且关键词特征明显，那一个简单的文本分类器或规则引擎可能是最优解；只有当用户表达方式极其自由、类别边界模糊时，才需要让大模型出场。

这里需要明确一个“AI工程分层”的思维模型：

• L0 层：固定规则、字典匹配。成本趋近于零，响应毫秒级；
• L1 层：传统机器学习分类/回归。适合有历史标注数据的场景；
• L2 层：单次大模型调用。适合自由度高的理解和生成任务；
• L3 层：大模型 + 工具调用 + 多步编排。适合需要推理、操作、检索的复杂任务。

“从零开始”的意义就在这里：不是从Llama、GPT这些模型本身开始，而是从“判断哪一层方案最合适”的工程决策开始。很多时候最优解是用L0层过滤掉80%的简单请求，只把剩下20%的复杂请求交给L2/L3层，整体成本能下降一个数量级，稳定性和响应速度反而大幅提升。

2. 核心细节解析与实操要点

2.1 提示词工程：从“写作文”到“写接口契约”

Prompt Engineering 是AI工程里最基础也最容易被误解的一环。很多人写提示词像在跟老朋友聊天，各种口语化表达、无关的背景信息一大堆，结果模型输出跟抽盲盒一样随机。真正工程化的提示词，本质上是一份接口契约文档——它必须精确告诉模型：你是什么角色、输入什么结构、输出什么格式、遵循什么约束、遇到什么情况怎么处理。

我常用的提示词结构可以拆成六个部分：系统设定（System）、任务说明（Task）、输入格式（Input）、输出格式（Output）、约束条件（Constraints）、示例（Few-shot Examples）。前四部分保证“能跑通”，后两部分决定“跑得好”。

拿一个在线教育平台的“题目自动批改”场景举例，第一版提示词我写的是“帮我看看这道题学生答得对不对，给出分数”，结果输出千奇百怪，有的写“很不错”，有的给一段小作文式的点评，纯靠人工二次处理。改造后的系统提示词变成了这样：

角色：你是一名严格的中学数学教师。 任务：对比标准答案和学生答案，判断学生答案是否正确，并给出评分。 输入：题目内容、标准答案、学生答案，均以JSON格式提供。 输出：仅输出JSON对象，包含三个字段： is_correct: boolean（是否完全正确） score: number（0-100整数） feedback: string（不超过50字的点评，用中文） 约束： 1. 学生答案包含正确计算过程但有轻微誊写错误时，is_correct视为true，但score酌情扣分。 2. 不得在JSON之外输出任何其他文字。 3. 无法判断时，is_correct输出null，score输出0。 示例：...

改动后的效果立竿见影：解析失败率从15%降到接近0，评分一致性大幅提高。核心原因是模型不需要“猜测”人类想要什么，每条产出都有明确的格式约束和判断标准。

在实际操作里还要养成一个习惯：把提示词当代码管理——存进Git仓库、写版本记录、做A/B测试，不要直接在网页版对话框里反复试。因为“能跑”不等于“能上线”，提示词在离线测试里表现好，不代表在线上真实流量里同样好，必须有一份可演化、可追溯的版本。

2.2 结构化输出的工程化设计：JSON不是万能的

现在的大模型直接输出JSON已经比较可靠了，尤其是一些支持Json Mode或Function Calling的新版模型。但如果你做过生产级系统就明白，最大的坑不是“模型偶尔输出非JSON”，而是“模型输出的JSON结构对，但字段内容不符合业务预期”。

我见过太多团队在解析层写死“data.result.answer”，结果模型某天在result后面多加了一层嵌套，或者把answer字段输出成了null，代码直接炸掉。防御性解析是结构化输出工程里必须补的一课：不要假设模型会完美遵守契约，要在解析层做类型检查、范围检查、缺字段兜底。

一个更隐蔽的问题是：JSON Schema 约束本身可能限制模型的长文本生成能力。某些开源模型在强制JSON模式下，回答质量会明显下降，出现“为了满足结构、牺牲内容合理性”的情况，比如数学推理题在JSON输出模式下频繁算错。如果是这类任务，比较实用的折中方案是让模型先输出一段自由文本的推理过程，然后再通过第二次调用把这段文本转成结构化JSON，或者使用正则从自由文本中抽取关键字段。

有一种生成策略值得在工程里推广：先草稿、后格式化（Draft then Format）。和人类写报告一样，先不考虑格式把思考和答案写出来，再花精力排版。两个分开的调用虽然多花了点Token和时间，但在复杂任务上，内容的准确性和结构的稳定性反而都提升了，这部分额外成本通常值得。

另外要特别留意输出长度的控制。有些模型在“越详细越好”的暗示下能生成几千字的废话，对于大多数业务场景，响应时间和Token成本都不允许这种浪费。与其在提示词里反复说“请简洁”，不如在解码参数上直接设置Max Tokens上限，物理层面限制输出长度，效果明显更可靠。

2.3 上下文管理：对话历史不是越长越好

做聊天机器人、客服助手这类多轮交互系统时，上下文管理是最容易失控的地方。多数人的直觉是“把全部对话历史都传给模型，这样它最了解上下文”，但实际测试下来，这会带来三个问题：成本线性上涨、响应延迟明显增加、模型注意力被无关历史干扰导致关键信息反而被忽略。

有效上下文管理是AI工程里相对独立的技术活，核心思路叫“上下文窗口的预算分配”。整段对话就像一次采购，预算有限（Token上限），你得决定买什么、不买什么。我会把上下文划分成三类：

• 核心上下文：当前问题计算的必要信息，占预算的大头；
• 参考上下文：可检索的领域知识、历史结论，按需动态注入；
• 压缩上下文：很久以前的对话内容，用摘要替代原文。

实践中，长对话通常采用“滑动窗口 + 摘要”的方式：设定一个窗口，比如最近10轮对话完整保留，超过窗口的部分，每隔一定轮次用模型生成一段摘要，把摘要放到上下文的最前面。这样既保留了关键历史信息的连贯性，又避免了阻塞窗口。另外，实体和状态信息尽量从对话中抽取出来存成结构化字段，而不是指望模型每次从原始文本里重新理解一遍。比如客服系统里用户的会员等级、订单编号、问题类型，一旦识别到了就入库，后续轮次直接读库注入，不再依赖模型记忆。

这里要特别注意“记忆幻觉”问题：有些模型会把当前对话里被用户纠正过的信息搞混，如果你明确告诉它“用户说他不买手机了”，它可能下一轮又沿用旧信息推荐手机壳。工程上的解法是对关键实体做独立维护，在生成时通过模板强约束，尽量不让模型自行决定该用哪个版本的信息。

3. 实操过程与核心环节实现

3.1 从“能跑的脚本”到“可维护的AI服务”

有了前面的基础，下面我用一个实际的“AI文章审核辅助系统”来完整演示怎么从零开始搭一个AI服务。这个场景很典型：业务方每周有几百篇用户投稿需要审核，以前全靠人工阅读判断，现在想用AI做第一轮筛查。

纯调用大模型当然是最快的办法，但工程化就要想更多：调用失败怎么办？输出怎么解析？误判率怎么量化？后续优化从哪里下手？为了应对这些问题，整体架构分成三层：路由层负责判断哪些内容需要走AI审核，执行层负责模型调用和结构化输出，校验层负责规则复核和人工抽检。

路由层的实现不复杂，核心是一个规则引擎加一个轻量分类器。先通过正则把包含明显违禁词的投稿直接判为“待人工复核”，再把没有明显问题的内容交给大模型做语义级判断。为什么不全部交给模型？因为线路层只有几十毫秒的延迟且费用极低，几十倍成本差距在先做一遍过滤是绝对划算的。

执行层是整个系统的核心，需要把提示词、模型参数、运行日志串联起来。代码框架大致是这样：

import json from dataclasses import dataclass from typing import Optional import openai # 仅示意，实际可替换任意SDK @dataclass class AuditResult: risk_level: str # low / medium / high risk_types: list # ["广告", "暴力", "色情", ...] confidence: float # 0-1 reason: str # 审核依据摘要 needs_human: bool # 是否需要人工复核 SYSTEM_PROMPT = """你是一名内容安全审核专家... 只输出JSON：{"risk_level": "...", "risk_types": [...], "confidence": 0.0, "reason": "..."} 规则细节：...""" def audit_content(text: str, client) -> Optional[AuditResult]: try: resp = client.chat.completions.create( model="gpt-4o-mini", # 实际按成本/效果选型 messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"请审核以下内容：\n{text[:2000]}"} ], temperature=0.1, max_tokens=500, response_format={"type": "json_object"} ) data = json.loads(resp.choices[0].message.content) # 校验层：强制字段存在性检查 risk = data.get("risk_level") if risk not in {"low", "medium", "high"}: raise ValueError(f"Unexpected risk_level: {risk}") return AuditResult( risk_level=risk, risk_types=data.get("risk_types", []), confidence=float(data.get("confidence", 0.0)), reason=data.get("reason", ""), needs_human=(risk == "high" or float(data.get("confidence", 0.0)) < 0.6) ) except Exception as e: # 失败兜底：绝不能直接抛错，降级到人工审核 return AuditResult( risk_level="high", risk_types=["unknown"], confidence=0.0, reason=f"model_error: {e}", needs_human=True )

这段代码里最核心的设计不是“调用了模型”，而是三处工程化细节：异常降级策略保证模型挂了不会影响主流程、字段校验防止模型乱输出、needs_human 判断逻辑把低置信度结果强制转到人工。这些都是线上运行必不可少的一环，实际做的时候千万别图省事删掉。

3.2 费用与性能的平衡：模型选型和参数调优实验

任何AI工程项目在落地前，必须做一次模型选型对比实验，用数据说话，而不是拍脑袋选个最强的。我通常选三类候选模型做对比：顶尖旗舰模型（如GPT-4o级别）、中端均衡模型（如GPT-4o mini、Claude Haiku级别）、开源可私有化模型（如Qwen系列中等尺寸版本）。

测评维度包括准确率、格式遵循率、平均延迟、单次成本。我当时测出来的一组典型数据可以给大家参考：

准确率只差2.5个百分点，成本却是50倍的差距，这就意味着中端模型通常是绝大多数业务的甜点。旗舰模型只该被用在最难的5%样本上，比如语义极模糊、低置信度需要二次判断的内容。

实际部署时还需要做“动态路由”：先用中端模型低成本处理，如果它对结果置信度不高再升级到旗舰模型。我在实验中发现，这样优化后整体成本能再降50%以上，而最终准确率几乎不受影响。整个方案的本质是把成本花在刀刃上，而不是让每个请求都享受顶配待遇。

温度参数方面也值得多说一句。工程系统里的生成任务，比如分类、审核、抽取，跟创意写作不一样，需要的是稳定和一致，温度建议设在0到0.3之间；凡是看到有人用高温度跑这类任务的，基本都没想清楚系统要的是稳定性。另外把Top-P从1降到0.8左右，也能在不伤准确率的前提下减少一些无序输出，这是我在评测里发现的稳定有效的组合。

3.3 效果评估体系：没有评测，就没有优化

很多团队做AI工程时最缺的其实不是写代码的能力，而是评测意识。没有一套可量化的评估体系，你根本不知道改动提示词是变好了还是变坏了，也不知道线上出现的问题是模型退化还是数据出了问题。

评估体系至少需要三层。第一层是离线测试集，在项目启动时就要开始积累，比如审核系统里准备几百条已标注的“好内容/坏内容”，每次改提示词、换模型、调参数都跑一遍回归。第二层是线上A/B测试，把新策略跑在10%的流量上，对比旧策略的准确率、误判率、人工介入率。第三层是实时监控，记录每天的调用量、延迟、Token消耗、异常率、人工复合率，设置告警阈值。

离线测试要特别小心“测试集泄漏”问题。用真实线上数据构造测试集时，要确保和模型训练数据的时间段错开，不然过了几个月模型参数更新后，效果评估虚高的现象会骗过所有人。我一般会保留最近一个月的线上数据做“盲测”，前一个月的做“调试”，滚动更新来避免评估失效。

在人工评估维度上，还需要引入“混淆矩阵思维”。单纯看准确率会掩盖很多问题，比如内容审核系统里，把“低风险内容标成高风险”和“高风险内容漏成低风险”的代价完全不同。前者只是浪费人工复核时间，后者可能引发内容安全事故。因此工程上要给不同类型的错误设置不同权重，把评估指标从准确率改成“加权风险分”，这个数字才能真实反映线上风险水平。

4. 常见问题与排查技巧实录

4.1 模型“突然变蠢”怎么排查

线上AI服务最莫名其妙的问题就是：昨天还好好的，今天输出突然变差了。很多人第一反应就是“模型被官方偷偷换了”，说实话这种可能确实存在，但大部分时候其实另有原因。

我建议按这个顺序排查：先看输入数据漂移，再查上下文污染，最后才怀疑模型本身。输入漂移的例子很常见：业务方某天改了投稿格式，上传的内容里混入了大量HTML标签或Markdown符号，模型被这些噪声干扰导致判断不准。排查方法也简单，把最近输出异常样本的原始输入调出来，人眼扫一遍，通常很快就能发现规律。

上下文污染在高频出现且隐蔽的问题中排前两名。如果你的用户会话里有历史消息，排查时一定要看Prompt实际拼出来是什么样：有时某个历史轮次里带着HTML标签，有时用户往上下文里塞了很长的无关文本，直接把后续生成带偏。我的习惯是给线上每次请求都打印一份“完整提示词日志”，这在排查时价值极高，虽然存储成本高一点，但关键时刻能省几小时排查时间。

排除掉上面两个因素后，才考虑模型服务商端的更新问题。可以做一个标准化基准测试集，每天定时跑一遍，如果连续几天效果分数持续下降，且我们自己没改过任何东西，那才是真·模型退化。

4.2 成本失控的幕后黑手

AI工程上线后，最大的一张账单往往不是来自模型本身，而是来自“重复计算”。最常见的情况是缓冲区没做好，同一段文本在多个请求里被反复编码成Token；另一个是重试逻辑太粗暴，模型超时就立刻整单重跑，一次任务烧掉好几次的钱。

在排查成本问题时，我会先查单请求Token分布。比如在日志里看Max Tokens设置了多大的输出限制，有些模型即使你只需要它输出“是/否”，它还是会老老实实生成几百字，这就在白白烧钱。建议把所有生成任务的Max Tokens压到业务所需上限的1.2倍左右，本质是一个保险系数，但不给模型留下挥霍空间。

另一个隐蔽的成本项是“上下文缓存未命中”。现在多个主流服务商都支持Prompt缓存功能，如果请求间有共同的前缀部分，会被缓存复用，费用大降。但缓存命中率取决于Prompt前缀的稳定程度。有些人习惯把当前时间、随机ID拼进系统提示词，导致每次前缀都不同，缓存全部失效。把动态内容移到消息末尾，是让缓存生效最简单的技巧之一，改动很小但成本优化立竿见影。

4.3 多步骤任务的状态与重试设计

当AI工程从“单次调用”进化到“Agent多步编排”后，最折磨人的问题往往集中在上一步输错、下一步就跟着错。比如一个“AI写稿助手”工作流里，模型先生成大纲，再根据大纲生成全文，如果大纲阶段就偏离了主题，后面全文越写越离谱，而且几乎无法通过调优提示词解决。

工程化解法是引入“中间产物校验门”。每步执行完、进入下一步前，加一道检查逻辑。这个检查分两种：轻量规则检查负责格式、字段、关键词等的验证；语义检查本质是再调用一次模型来审视上一步的产出质量。虽然增加了一些调用次数和延迟，但放在任务成功率和高价值场景里，这笔账通常是划算的。

在更高的技术上，这种做法叫“Plan-Execute-Review”模式，核心思想就是让每一步都有明确的成功标准。要对每一步设定判定规则，建议提前和业务方对齐“请给明确的标准而不要你对我说尽量做好”，掌门人会给模糊标准则模糊结果，带标准规则才能收获可靠流程。

失败重试设计上也值得有章法。不要做普通的“失败就整段重跑”，那样既浪费又可能重蹈覆辙。更合理的做法是分步重试：哪一步失败就只重跑哪一步，并允许把失败原因反馈给模型，让它调整策略再试一次。连续两次不成功就标记给人工或降级方案。

5. 工具链选型与工程化基础设施

5.1 核心工具矩阵：LLM框架、可观测性与评测平台

聊完实操环节，补充一下工具链选型的思路，这是“从零开始”的路线上绕不开的决策点。当前AI工程圈常用的技术栈大致可以分成四层：编排层、调用层、可观测层、评测层。我的个人选型建议如下：

很多人在这些工具里挑花眼。我的建议是按“被需要时才引入”的原则来选择：刚开始只在调用层加一个LiteLLM，避免绑定单一厂商；等到项目有了第二、第三个功能后再考虑编排框架；可观测层建议从第一天就接，哪怕只是简单打个日志，因为早期数据才是后续优化评估的起点。

5.2 RAG类应用的工程细节与避坑

大模型+RAG是现在AI工程里实用性极高的一类应用，但也是表面上简单、暗坑最多的一类。第一代做RAG的团队通常都会遇到“检索到了但回答没用”的情况，原因往往是分块策略没做好。最常见的错误是把一个合同文本按固定字符长度截成几块，导致一个完整法律条款被拦腰切断，模型在生成时哪一块碎片都看不全。

我做知识库问答时，分块前会先做结构解析：PDF按章节标题切、Markdown按Heading切、法律文本按条/款/项切、对话记录按轮次切。每个分块还带上一层“父文档块”的上下文信息，检索命中到子块，同时把父块内容一起注入Prompt。这样既保证了片段足够聚焦，又不丢失大语境信息，效果提升非常明显。

检索环节还存在一个嵌入模型很关键但常被忽略的事实：Embedding模型的长度限制和相似度分布都是需要专门做适配的。通用中文文本适合用开源BGE系列时，先做一波相似度统计，搞清楚命中分数段的分布，再定“取几个块、相似度阈值多高”，对整体回答质量有决定性影响。

5.3 从单机脚本到服务化部署的完整链路

最后把服务化部署这条链路串一遍。一个标准的AI工程服务化流程至少包含以下环节：

• Prompt模板版管理存在Git库，发版走普通代码评审流程，顺便做版本标注；
• 模型配置集中管理，包括模型名、温度、Max Token、重试次数、超时等等，都集中到同一个配置文件或配置中心；
• 请求入口加一层签名认证与限流控制，防止刷量攻击，AI服务比普通接口的调用成本高得多，限流是刚性需求；
• 反正接的结果异步化尽量做实，像审核这类的场景用户不需要秒级返回，直接把请求丢进队列，模型处理完回调结果即可；
• 写一个独立的健康检查接口，对模型供应商做探活，返回服务状态供负载均衡使用。

实际业务中被问到最多的是怎么评估性能。这里带一个基本计算：假设单次模型调用耗时2秒，一台单机并发数16，那每分钟最多处理480个请求；如果每天有10万篇内容需要审核，就需要至少3台机器，同时还要考虑重试和调用的高峰冗余。这种“用吞吐量倒推开机器数量”的计算方法，避免了拍脑袋扩容和预算失真。

6. 从工程实践到个人成长路线图

6.1 从“会用”到“会设计”的能力进阶

做了这么多项目，有个感受越来越深：AI工程不是一个静态的技术栈，而是一套持续演进的思维方式。入门时你可能专注于写提示词和调模型，这是正常的；做了几个真实项目后，注意力会自然转向数据流设计、评估体系、成本控制、故障恢复这些更底层的议题。

从我个人经验看，比较顺滑的成长路径倒是不复杂：先完成一个最小闭环项目，把它完整跑通上线；然后回顾这个项目里哪些环节最不稳定、成本最高、效果最差，分别针对性地去做优化；优化过程中自然会接触更多工具和方法论，慢慢就把整条技术栈拉通了。这个过程中最重要的一条心态是“不要神话AI能力”，模型只会越做越强，而工程体系的竞争力永远是数据、评估和业务理解。

每条工作流里最容易被新人忽略的往往是对输出的珍视程度：无论你是用提示词让模型生成内容，还是让Agent执行一系列动作，都要假设每次输出的结果会用于正式场合，于是你会自然愿意在结构化、校验、兜底上花功夫。这是把“玩AI”变成“做AI”的分水岭。

6.2 后续可以继续扩展的方向

如果在当前思路上还想往深里走，下面这几个方向都特别适合作为下一阶段的实验课题：

• 多Agent协作，不同角色模型分别承担“分析、执行、审查”，用策略把它们串成闭环，特别考验状态交互设计能力；
• 小模型微调，在特定业务场景里把“调用大模型”变成“本地小模型”，成本可能降到原来的十分之一以下，推理延迟也会更理想；
• 反馈飞轮设计，在线上让用户对AI输出打分或点踩，把数据回流到评测和提示词优化里，形成持续改进；
• 多模态工程，把图像、音频、视频等非结构化输入纳入原有流程，场景比纯文本多不少，后续想象空间也大。

这些方向每次都能单独写出好几篇实战记录，但根基永远是前面聊到的那套方法论：边界判断、任务拆解、结构化输出、评测闭环、降级恢复。把这些基本功打扎实，后续往上怎么长都不会跑偏。

我自己刚接触AI工程时也觉得，这领域变化太快、工具太多，学不过来。真正做了几个项目之后才明白，底层那套“系统化解决问题”的框架，跟做传统软件工程没有什么本质区别——都是想清楚边界、设计清楚流程、盯紧数据和结果，不断迭代。AI能力只是为你提供了一个新的、更强大的功能模块，工程思维仍然是那根顶梁柱。