企业官网建设流程全解析

先说一个真实的感受：很多人看到“AI engineering from scratch”这个标题，第一反应是“从零手写一个Transformer”“从零训练一个大模型”。但我做AI工程这些年最大的体会是，绝大多数团队和开发者真正缺的，不是训练模型的数学基础，而是把一个“能跑的Demo”变成“能上线的系统”的那一整层工程能力。

这篇文章我想聊聊，从零开始做AI工程到底要经历什么。我会从提示词工程讲起，再到Agent编排、评测体系、Harness Engineering，最后落到“什么时候才值得从零训练模型”。这一路都不是教科书式的理论，而是我在真实项目里踩过坑、填过土之后沉淀下来的实践经验。无论你是刚接触AI的开发者，还是已经在做ChatBot想往深处走的工程师，这篇文章都值得你花十分钟读完。

1. AI工程从零开始，先搞清楚它在工程化什么

1.1 从“调API”到“跑系统”：三个关键变化

我见过不少朋友的入门路径：注册一个API账号，写十几行代码把大模型调用通了，然后发一个“XXX AI助手诞生了”的朋友圈。这不是工程，这只是调接口。

真正的AI工程，是你拿到一个业务需求——比如“做一个能回答用户售后问题的客服机器人”——然后你要面对的不再是“让它生成一句回答”这个简单动作，而是一整条链路：用户消息进来，你要先做意图识别，再决定调用哪个模型或工具，模型返回的结果要做格式校验，失败了还要自动重试或降级，最后把答案推送给用户。整条链路里任何一个环节出问题，用户感知到的就是“这机器人真笨”或者“这系统又崩了”。

从“调API”到“跑系统”，我总结出三个本质变化：

1. 输入从“单条指令”变成“多源异构数据”。真实场景里，用户的输入长短不一、口语化严重、还可能掺杂错别字和emoji。你的系统要能容忍这种不确定性，而不是直接把原文扔给模型。
2. 输出从“一段话”变成“要被程序消费的结构化结果”。你在Demo里可以让模型随便说，但生产系统里模型的输出往往是一个JSON结构、一个SQL语句、一段代码、或者一个具体的工具调用参数。模型说多了、说少了、格式错了，程序都会崩。这是AI工程最常踩的坑。
3. 失败从“可以人工干预”变成“必须自动化恢复”。Demo挂了你可以重新跑一次，生产环境挂了你自己都不知道。所以AI系统必须预设好超时、重试、熔断、兜底逻辑，让系统在模型表现不佳时也能平稳运行。

1.2 其他软件工程经验，哪些能继承哪些要放弃

我最早是从传统后端转来做AI应用的，当时最痛苦的一件事就是：我以前那套“精确定位Bug”的思路，在大模型面前失灵了。

传统软件里，程序出错一定有确定性的原因——数据库连不上、空指针、字段拼错。你只要翻日志、断点调试，总能找到根因。但大模型出错，很多是没有“根因”的：不是因为代码逻辑错了，而是因为模型这一次生成的结果偏离了你想要的方向。你再怎么打印日志，也找不到“为什么它偏偏在这次说了这句话”。

这不是说传统软件工程的经验就没用了。恰恰相反，版本管理、模块化、自动化测试、CI/CD、监控告警，这些AI工程一样都离不开，甚至更重要。模型本身就是巨大的不确定性来源，你需要用工程手段把这个不确定性围堵住，让它不要直接爆到用户面前。

所以我的建议是：做AI工程，你的心态要从“消灭错误”变成“控制错误的影响范围”。你不是要和一个概率系统较劲，而是要给这个概率系统装上方向盘和刹车。

2. 提示词工程的本质：它其实是一种接口设计

2.1 用开发接口的思路来写提示词

很多人写提示词特别随便——“帮我写个周报”。模型也真的就给你写了一段通用周报，然后你骂模型不好用。但模型很冤枉，因为它根本不知道你是谁、你的项目是什么、周报要报给谁。

我把提示词看成一种接口设计：大模型是你无法打开源码、只能通过文本调用的外部服务，提示词就是你这个服务的“API文档”和“入参结构”。如果你在调用一个SDK的时候，连参数名都懒得传对，你会怪SDK不靠谱吗？模型也是一样的道理。

一套相对完整的提示词，通常会包含这几个部分：

我在实际项目里，会把提示词跟代码一样放在Git仓库里管，而不是写在用户聊天框里试了就算了。每次改动提示词，都要提交一次变更记录，标注“为什么改、改了之后影响哪些场景”。这样你出了线上事故，还能回溯到“上一版这个时间段用的提示词是什么”。

2.2 少样本与思维链：实例比命令更有效

这里说一个很反直觉的经验：你给模型下“不要做什么”的命令，往往不如给模型“该怎么做”的示例管用。

我试过在提示词里写“不要回答与售后无关的问题”，模型还是会偶尔放飞自我。但当我改成在示例里给了一条“问：今天天气怎么样？答：抱歉，我只负责处理售后问题”之后，模型的守规矩程度明显上升。原因在于：命令是抽象的，模型很难从抽象规则里提取出精确的行为准则；而示例是具体的，模型本身就是在“预测下一个token”的任务里训练出来的，你给它看大量“输入→正确输出”的配对，它自然会把行为收缩到你期望的那条路径上。

还有一个很关键的技巧是思维链（Chain of Thought）。你让模型做复杂推理的时候，单纯问“这个退款申请该不该通过？”它可能直接给个“应该”，但理由毫无逻辑。如果你在提示词里引导它“先列出退款政策，再列出用户情况，再逐条比对，最后给出结论”，模型的推理准确率会明显提升。本质上是让模型把隐含的推理过程显式化，因为大模型是“接着往下写”的，你让它先写推理过程，它就会顺着推理过程往下走，而不是直接跳到结论。做AI工程的朋友，思维链这个技巧真的要刻进DNA里。

2.3 提示词也要做版本管理和回归测试

提示词是AI系统的灵魂，但这个灵魂经常被随手改来改去，这是我最不能忍的。

一个正经做AI工程的人，应该给提示词建立一套跟代码一样的生命周期管理流程：变更前先跑一遍回归测试，确认影响面；变更后记录版本号，方便线上回滚。我自己的项目里有个简单做法：把提示词按场景拆分存成独立文件，比如prompts/refund_review.txt、prompts/order_query.txt，每个文件顶部写作者、版本、修改日期，然后在代码里按版本号加载。

这样做还有个额外的好处：当你发现线上效果变差了，你可以快速定位是“这个版本提示词的问题”还是“模型侧的问题”，不用整个系统翻一遍日志。很多AI工程事故，其实只是有人在某个下午手痒改了一句prompt导致的。

3. Agent编排实战：单次调用变成完整的业务流程

3.1 工具调用的原理与选型

当你觉得“单次问答”已经满足不了业务的时候，就会自然地走向Agent——让模型不只是“说话”，而是“做事”。比如用户说“帮我查一下订单OD20240001的物流”，模型需要先调用订单查询工具，拿到结果，再组织语言回答用户。

这个过程的官方术语是Function Calling（函数调用），有些框架里也叫Tool Use。它的本质是：模型不直接执行代码，它只是生成一个“调用计划”——决定该调用哪个工具、传什么参数——真正执行工具的行为是由你自己的代码来完成的。

做一个工具调用系统，最重要的不是写模型的调用代码，而是把每个工具的描述写得足够清晰。模型是靠工具描述来“决定”要不要调用、怎么传参的，所以你的工具描述要像API文档一样，写清楚：

• 这个工具是干什么的（语义清晰，避免模型误解）
• 什么时候该调用、什么时候不该调用
• 每个参数的含义、类型、取值范围

我见过一个经典翻车：有个团队给模型注册了一个“删除订单”的工具，工具描述写的是“删除指定订单”。然后用户吐槽“你们这个网站真难用”，模型直接调用了删除工具把某个订单删了。这不是模型的问题，是工具描述里没写“仅在用户明确要求删除，且验证用户身份后，才能调用本工具”。工具的边界描述不到位，模型就会拿着锤子看见什么都是钉子。

3.2 计划-行动-观察循环：三大坑与防御手段

标准的Agent工作方式是“计划-行动-观察”（Plan-Act-Observe）循环：模型先想下一步要干嘛（计划），然后调用工具或生成文本（行动），再根据结果（观察）决定下一步。这个循环可以拆成一次对话里的多轮推理。

听起来很美好，但我在实际做Agent的时候，踩过三个特别深的坑：

第一个是死循环。Agent在循环里反复调用同一个工具，拿到的结果还是一样的，它却不肯停下。解决方式是硬性设置最大迭代次数，比如最多5轮，超出就强制终止并返回当前最优结果。这个数字不能太大，否则一次请求可能跑几十秒，用户早跑了。

第二个是上下文爆炸。每多一轮，Agent的上下文就把上一轮的输出塞回去，Token越滚越多，最后要么超长截断，要么成本飙升。我的做法是只保留关键轮次的记录，把已经完成的中间结果压缩成一句话摘要，而不是全部塞进去。

第三个是**“幻觉自信”**。Agent调用工具拿到一个异常结果，比如订单查询返回空，它可能不是如实说“查不到”，而是编造一个“订单已发货”的回答。这个问题靠提示词很难根治，必须在代码层做校验：工具返回空结果时，直接剥掉Agent的解释权，强制它返回“未查询到”的模板话术，不让它自由发挥。

3.3 多Agent协作时的状态同步问题

单Agent搞定了，很多人就开始搞多Agent：一个负责分析需求，一个负责写代码，一个负责测试。这种架构听起来很酷，但工程复杂度是指数级上升的。

我在项目中用过“主Agent+子Agent”的架构，最大的教训是：不要让每个Agent都直接改全局状态。比如主Agent让子AgentA去查资料、子AgentB去写报告，如果两个子Agent各自维护一份状态，最后你会发现大家手里的数据完全对不上。

正确的做法是设置一个共享状态机：所有Agent不直接修改全局数据，而是返回结构化的变更指令，由你的代码统一落地。好比公司里不是每个人都能直接动财务账本，而是所有人填报销单，财务统一审核入账。这个“财务”就是你的业务代码。结构化返回还可以用我前面讲的JSON Schema做校验，确保每个Agent交上来的“变更单”是合规的。

4. 评测体系：没有衡量，就谈不上工程

4.1 评测集怎么搭：三类样本缺一不可

做AI工程，最怕的就是“凭感觉”。“我觉得这次改好了”“用户好像反馈还行”——这些主观描述在系统规模小的时候还行，一旦Agent变复杂、提示词迭代频繁，你就完全失控了：改了一个场景的效果，另外三个场景全挂了。

所以AI工程的第一步，是建一个评测集（Evaluation Set）。我的建议是至少包含三类样本：

1. 基础正例：业务里最常见、最标准的输入。比如客服机器人，就是“我要退款”“我的订单到哪了”这类高频问题。这些例子保证系统不倒退。
2. 边界Case：容易踩坑的场景。比如“用户问价但是语气很不耐烦”“用户同时问了两个问题”“用户输入只有三个字‘很生气’”。这些例子帮你测出系统的韧性。
3. 对抗Case：主动设计的难题。比如有用户想诱导模型越狱、问敏感问题、或者故意用错别字和同音字混淆模型。这类样本用来测安全性和鲁棒性。

评测集不用贪大，50到100条就够起步，但必须稳定、可复现、覆盖面广。每周我会往里补充线上真实遇到的失败案例，这样评测集就会越滚越像一个“系统体检表”。

4.2 评测维度：不只准确率，还有格式、安全、成本

很多团队做评测只知道看“答得对不对”，但生成式AI的工程化评价远不止这一点。我自己搭了一个多维评分体系，每个维度单独打分，汇总后才能判断一个Agent能不能上线：

这个表里最容易被忽视的是“格式合规率”。有一次我线上系统突然大量报错，排查半天发现是模型在返回JSON时多了一句“好的，这是您要的信息：”在JSON前面，导致json.loads解析失败。从那以后，我规定所有模型输出必须过一层“提取器”，先把代码块和多余说明剥掉，再进解析器。永远不要把模型输出的格式正确性当成默认前提。

4.3 自动化评测：把评测塞进CI流程

评测集搭好之后，如果你还靠手工一条条跑，那是给自己挖坑。正确的做法是把它接入CI/CD流程：每次修改Agent代码、提示词或模型配置，都自动跑一遍评测集，输出一份“指标对比报告”，低于阈值的改动直接不让合并。

我团队里的做法是开发了一套简单的命令行评测工具，跑完之后自动输出Markdown格式报告。有了这个机制之后，我再也不怕任何人“手痒改了一下prompt”了——改之前跑一跑，效果好你就改，效果差就别动。没有自动化评测，AI工程就是碰运气。

这里补充一个实操细节：评测怎么打分？中小项目直接让GPT-4当裁判（LLM-as-a-judge）性价比最高。你要在打分提示词里写清楚“参考标准答案，根据准确性、完整性、简洁性打1到5分”，并且要随机打乱答案顺序再提交给裁判模型，避免它的惯性偏见。至于等级，我建议先用“通过/不通过”这类二元判断，等你需要精细化调优时再上1-5分评分。

5. Harness Engineering：给大模型设计轨道

5.1 为什么非加“轨道”不可

“Harness”这个词在AI圈越来越火，它直译是“背带、挽具”，用在AI工程里我更愿意把它理解成轨道：你无法改变火车头的动力大小，但你可以决定它能往哪个方向跑。

大模型本身是一个开箱即用的“超级生成器”，它能写诗、写代码、胡说八道。你要是不加约束，它就什么都能干、什么都敢说。Harness Engineering就是给模型加上一层又一层的工程约束，让它只能做系统允许它做的事情。

我见过一个最惨痛的生产事故：某个内部知识库机器人，用户问“公司裁员名单是什么”，模型没有知识库里找到相关信息，却自己编了一份“内部资料”回答用户。问题根源不是模型太笨，而是系统没有加“不知道就承认不知道”的Harness。从那以后，我定了一条铁律：任何生成式AI系统，上线前必须通过“无信息拒答测试”——故意问一个知识库里不存在的问题，看它会不会编造答案。

5.2 结构化输出与兜底逻辑：双保险模式

第一道Harness是结构化输出约束。现在各大模型服务商都支持JSON Mode或者Response Format，你可以强制模型返回合法的JSON。但这道约束不是百分百可靠的，所以我设计了一套双保险：

1. 第一层：强制模型按JSON Schema输出。2. 第二层：代码里做容错处理，拿到输出先清理再解析，解析失败就带着修正指令重试一次，再失败就走兜底回复。

举个例子，我要求模型返回“退款原因分类”时输出JSON，解析逻辑大概是：

import json import re def parse_model_output(raw: str): # 第一步：去掉可能的代码块标记 cleaned = re.sub(r"```json|```", "", raw).strip() try: return json.loads(cleaned) except json.JSONDecodeError: # 第二步：尝试提取第一个 { 到最后一个 } 之间的内容 start = cleaned.find("{") end = cleaned.rfind("}") if start != -1 and end != -1 and end > start: try: return json.loads(cleaned[start:end+1]) except json.JSONDecodeError: return None return None

这段代码算不上高深，但它在线上救过我无数次。模型输出的正确性不是前提，而是需要你用工程手段去保护的变量。

5.3 权限、预算与超时的工程化管控

Harness Engineering不止体现在“让模型答得好”，还体现在“让模型别闯祸”。

• 工具权限管控：每个Agent能调用的工具集要最小化授权，比如“售后客服”只让查订单和退款单，“数据分析师”只让查数据库视图，绝不能让它直接执行删除或更新操作。
• 成本预算上限：给每个会话或每个用户设置单日Token消耗上限，超过自动降级到免费模型或直接熔断。宁可服务降级，也不能让一个用户的恶意请求烧掉你一整月预算。
• 超时与重试机制：模型接口调用设置合理超时时间，超时就触发一次最大2次的退避重试，仍失败就走预置的兜底话术。这个兜底话术也要提前写好，不要让用户在报错页面干等。

这三个“舵”是AI系统能否稳定运行的关键。很多人把注意力全花在“模型调优”上，却忘了工程学的本质是面对最坏情况还能兜底。

6. 从零构建模型：什么情况下值得走这条路

6.1 学习路径和生产决策是两码事

回到文章最开头那个问题：到底要不要“from scratch”去训练一个模型？我的答案分两种情况。

如果你的目标是做出一个能解决业务问题的AI应用，我强烈建议不要从训练模型开始。原因很实际：预训练一个大模型的算力成本是以百万美金计的，数据收集和清洗又是一座让人头皮发麻的大山。你完全可以用现成的API或开源权重，把精力集中在提示词、Agent编排、评测体系和Harness上——这些才是绝大多数业务项目真正的核心竞争力。

如果你的目标是深度理解AI模型的工作原理，那“从零构建”是一条极好的学习路径。我建议你去看一些经典的开源实现，比如用纯Python和NumPy实现一个简化版Transformer，跑通一次前向和反向传播。这个过程中你会真正理解“为什么Token要Embedding”“Self-Attention到底在算什么”“为什么训练要吃那么多显存”。这类知识在纯调API的过程中是永远学不到、也永远理解不透的。

6.2 模型选型决策表：别一开始就选最重的

很多人一上来就在“要微调一个开源模型”和“要自己训练一个模型”之间纠结。我给你一张贴切的选型表：

我做项目的决策习惯是：能用API解决的绝不自己训练，API搞不定的再考虑开源权重部署，数据敏感影响业务安全的才上微调。每一步往下走，都要有一个具体的问题逼着你去换方案，而不是为了“技术炫酷”去升级链路。

6.3 我的起步路线建议

根据我带团队的经验，一个比较合理的“AI工程从零起步”路线是这样的：

• 第一个月：熟悉主流大模型API的调用方式，重点练提示词工程。建立一个至少30条的基础评测集，学会用LLM-as-a-judge给自己写的提示词打分。
• 第二个月：尝试做一个带工具调用的Agent，比如本地文件问答机器人或订单查询机器人。给它接上“计划-行动-观察”循环，加上最大轮数和超时控制。
• 第三个月：把评测体系自动化，接进CI；给你的Agent套上Harness，加上结构化输出校验、拒答逻辑和成本监控。
• 第四个月：如果你还想往深走，选一个开源小模型（7B级别），用LoRA做一个领域微调，比如让它学会你公司的产品术语。这是“from scratch”学习曲线里最有成就感的一步。

每个阶段都要有一个“上线”动作。哪怕是给团队内部用的小工具也行，因为只有真实跑起来，你才会遇到那些教程里不会写的破事——Token超了、JSON解析崩了、用户提问把Agent带偏了。这些问题本身就是最宝贵的教材。

最后再分享一个我个人的习惯：我在每个项目里都会维护一个“模型翻车记录”文档，把线上遇到的失败案例、错误输出截图、复现问题和修正方式全部记下来。这个文档在团队里被传阅的次数，比任何一本AI教科书都多。因为AI工程这门手艺，本质上就是不断积累“怎么让概率系统稳定干活”的经验。你踩过的每一个坑，都是之后最值钱的判断力。