企业官网建设流程全解析

1. AI工程到底在造什么：从提示词到生产系统的思维转型

这几年技术圈有个很割裂的现象：一边是铺天盖地的“AI赋能”案例，另一边是大量团队拿着大模型API做不出能稳定交付的产品。我身边不少朋友从零起步做AI项目，起步动作几乎都一样——注册个Key、调通接口、写几段Prompt，Demo跑通了就兴奋地往架构图上填方案。结果呢？十个项目有六七个死在“Demo能跑、上线就废”这道坎上，剩下几个在“效果不稳定”和“成本控不住”之间反复拉扯。

这也是“ai-engineering-from-scratch”这个方向戳中我的原因。它代表的不只是一个技术清单，更是一种认知转变：AI工程不是提示词工程，不是把模型API接进来就完事的集成工作，而是把模型、数据、评估、推理、部署、监控串成一条完整链路的系统过程。你搭的不是一个“调用模型的脚本”，而是一套能在真实业务环境里持续稳定运行、可维护、可迭代的生产系统。

这篇文章我想用实际踩坑经历加上这套项目里常见的知识组织方式，把“从零开始做AI工程”这件事拆成几个核心板块讲清楚。每个板块里都会说清楚“为什么这么做”，而不只是“怎么做”，因为现在网上能找到的代码片段和架构图太多，真正稀缺的是那些驱动你做选择的判断依据。适合谁看？一类是准备从原型走向产品的独立开发者和创业团队，另一类是刚接手AI项目的技术负责人、算法工程师，还有把大模型应用引进业务体系但心里没底的产品和技术同学。读完之后你至少能知道，从零开始搭一个可交付的LLM应用，哪几个坑绝对不能踩，哪些环节才是真正决定成败的地方。

1.1 从“写Prompt”到“搭系统”：最核心的认知跃迁

先讲一个我自己的经历。早两年我刚接触LLM应用时，和大多数人一样，以为Prompt写得好就等于AI工程做得好。当时我花了不少力气研究各种提示词技巧，什么角色扮演、思维链、Few-shot模板，一套一套往里砸。项目前期确实爽，模型输出质量肉眼可见地提升，团队士气高涨。但等用户量一上来，问题全暴露了：同一个Prompt在不同输入下的表现方差极大，稍微换个表达方式回答质量就崩；上下文长了以后模型开始丢信息甚至胡编；线上bad case回收全靠人工截图反馈，根本跑不过来。这时候我才意识到，写Prompt只是在调一个黑盒的旋钮，离“工程化”还差着十万八千里。

真正的AI工程，核心是把“模型能力”变成“产品能力”的那层工作。模型本身是不可控的，它的输出有概率性，它的训练数据有截止时间，它不知道你的业务规则。工程要做的事情，就是在这堆不确定性外面包一层确定性：用评估来度量每一次变更的好坏，用数据工程来保证模型有干净可用的燃料，用RAG把私域知识接进来，用缓存和限流控制成本和风险，用监控把线上的质量损耗及时暴露出来。这一步思维的转变，决定了你是在“做一个调用模型的玩具”，还是在“做一个能吃住线上流量的系统”。

我后来复盘时给团队画过一张图，把AI工程拆成“一圈一环”的闭环系统：最内核是模型能力，包括基座选择、提示词、微调；往外一层是数据层，负责采集、清洗、标注、反馈回收；再往外是质量层，解决“你怎么知道新版本更好”的评估问题；最外面是交付层，包含推理服务、成本控制、可观测性。所有的层次串起来才形成闭环。这也是为什么单点优化见效快但走不远——你只拧了闭环里的一个螺丝，其他环节很快会成为瓶颈。

1.2 一张知识地图：AI工程涉及的板块与阶段节奏

刚开始接触AI工程的人，最容易产生的困惑是“我到底该从哪学起”。网上信息太杂，今天看篇文章讲RAG，明天刷到视频讲Agent，后天又看到有人吹微调，结果越学越焦虑，觉得自己什么都不会。其实AI工程的知识体系是有结构的，按项目推进节奏走，每一步对应明确的板块，盲目追热点才是最大的时间杀手。

从零起步的项目，通常跑四个阶段。第一个阶段是“搞清楚要解决什么问题”，对应的是需求分析和可行性判断，核心是搞明白你的场景对幻觉的容忍度、数据能不能获取、模型能力够不够用。第二个阶段是“跑通最小闭环”，对应的是模型选型、Prompt设计和架构骨架搭建，核心是用最小成本验证技术路线是否成立。第三个阶段是“把质量稳定住”，对应的是评估体系建设、数据回收和RAG优化，核心是让系统的输出从“偶尔惊艳”变成“稳定及格”。第四个阶段是“上线扛住流量”，对应的是推理部署、成本控制、可观测性和告警，核心是让系统在真实负载下不崩、不失控、不被账单调教。

这套阶段划分在“ai-engineering-from-scratch”的知识地图里也很清晰，且有一个关键认知贯穿始终，叫“评估先行”。很多团队是上线之后才想起来搞评测，测试集随便整几条就问模型效果，完全测不出系统的真实水平。正确的节奏应该是：在做架构和数据之前，先花力气建一套离线评测集，把你要的“好”定义清楚。否则后面所有优化都是无头苍蝇——你改了RAG、调了Prompt，怎么知道是变好了还是变坏了？拿肉眼感觉说话吗？在一个概率性的系统里，没有量化比较的修改基本等于赌运气。

2. 模型选型与系统骨架：两个最不该拍脑袋的决定

模型选型和系统架构，是AI工程里最前端、影响面最大的两个决定。不少人把这俩当成最无所谓的事，觉得“反正都能调API，先用最强的准没错”“架构嘛，先跑通再说”。这个态度放在Demo阶段没问题，但如果是奔着生产系统、奔着可持续迭代去的，这两步拍脑袋的代价极高，后面几乎是拿踩坑来赎罪。

我记得有次参与一个企业知识问答项目，架构评审时团队还在纠结用闭源模型还是开源模型，技术负责人一句“我倾向用最强的商业模型，效果碾压”把讨论带过去了。结果走到第三个迭代周期，痛点全都暴露了——每次改Prompt都要小心翼翼因为文档里写满了数据合规要求，上下文窗口吃紧导致单轮问答成本居高不下，内部希望微调模型定制语气，结果被闭源接口锁得死死的。最后团队花了三周重写检索链路、压低token用量，才把成本降回来。这次项目的教训就一句话：模型选型和架构设计，本质上是在给未来做约束，多花半天把约束条件想清楚，能省下后面几周的重构时间。

2.1 基座模型怎么挑：尺寸、能力、生态的三方权衡

模型选型的核心权衡项有三个：能力上限、运行成本和生态约束。很多教程喜欢列模型对比表格，什么参数量、什么榜单分数，但其实作为应用方，你最该关心的不是模型内部有多大，而是“在你真实场景下的表现和代价”。

先说能力上限，这里面有个容易被忽略的坑：模型榜单分数和实际业务效果相关性没有想象的那么高。我见过一个团队，在线评测排行榜里挑了个分数最高的模型来写法律文书，结果上了线才发现它生成的条款格式很漂亮，但具体法条引用经常张冠李戴，榜单根本测不出这种领域精度。所以务实的做法是：拿你业务里最典型的三五十条真实输入，把候选模型轮番跑一遍，肉眼加结构化对比，而不是直接看公开分数。

然后是运行成本。这里背后面有个很有意思的经济学问题：模型能力是“按token计价的商品”，你要买的是“够用且能赚钱”的那档，而不是“最强”的那档。我自己的经验法则是，先用最强模型摸能力天花板，再往下探性价比边界。很多场景下，小模型加好的RAG和Prompt设计，效果能逼近大模型，成本却能省30%以上。没错，很多团队怕降级后效果崩，但只要你手里有离线评估集，这件事就能量化验证，而不是靠感觉冒险。

最后是生态约束。这一点最容易被人忽视，却往往是最致命的。你得想清楚几个问题：是否需要对模型做微调？是否需要私有化部署？你的工具链对开源模型的支持是否成熟？这些都是在选型阶段就要定好的方向。选闭源模型，你把灵活性交给供应商；选开源模型，你要承受部署和运维的负担。没有标准答案，但一定要让这个选择成为一个“决定”，而不是一个“默认选项”。

2.2 架构骨架：编排层、记忆层与工具接入层

模型定下来之后，紧接着是系统骨架。很多人以为架构设计就是画个Agent流程图，实际上核心要拆开的是三个层次：编排层、记忆层、工具接入层。

编排层解决的是“模型怎么被调用、流程怎么被组织”的问题。最简单的形态是做一个“接收输入→拼Prompt→调模型→返回结果”的同步服务，再复杂一点加上意图识别、多轮对话、条件分支。说实话，很多应用根本不需要复杂编排，一堆花哨的Agent框架反而会引入不必要的失控因素。我的建议是：能用线性流程解决的绝不引入循环，能用简单状态机管理的绝不套Agent框架。系统每多一个不确定性节点，线上排查的难度就翻一倍。

记忆层解决的是“模型的上下文窗口怎么分配”的问题。LLM的记忆能力不等于无限的，很多从零起步的团队犯的最大错误就是想多塞些内容，结果发现上下文太长模型输出质量急剧下降，成本还翻着番往上涨。要做的是对上下文做取舍管理——该放系统提示词的放系统提示词，该用检索实时取的实时取，历史对话就交给摘要和截断策略处理。这里有一个经验：给上下文设定硬性上限，比如总token不超过模型窗口的一半，留出一半给生成余量，超出部分就用策略裁剪。

工具接入层解决的是“模型怎么调用外部能力”的问题。无论是搜索引擎、业务API还是数据库查询，都要考虑工具的结构化入参和容错。很多系统在模型调用工具时会遇到参数幻觉，也就是模型把不存在的参数名编出来，导致工具调用直接崩溃。规避办法也很成熟：工具Schema要给完整，接返回结果要做严格的格式校验，不能让模型输出直接接管控制流。

3. 离线评估先行：让优化有据可依的评测体系搭建

我在前面反复强调评估先行，这里专门展开讲，因为这个环节直接决定了AI工程能不能形成正循环。没有评估，团队就像闭着眼开车，你说改了Prompt效果好，他说加了RAG效果差，但谁都没有证据。这是AI工程和传统软件开发很不一样的地方：传统软件有单元测试，行为可预期；LLM应用输出是概率性的，不对每次回答做衡量，就永远说不清好或坏。

我见过一个项目组，连评估集都是临时从线上问答记录里拷出来一百条，让开发和产品轮流打分。刚开始大家还挺认真，过两天打累了就开始打平均分，分数全都集中在“还行”附近。这种评估最大的问题还不是人累，而是评测标准不统一、结果不可复现，周一打分和周三打分结论就能不一样。后来我们花了一周时间把评测标准化之后，整个迭代节奏就变了——每一次改动都有量化对比，谁好谁坏一目了然。

3.1 测试集设计：从“随手攒”到“分层覆盖”

评估集的质量，决定了你的优化方向靠不靠谱。很多团队做评估集就是拿历史数据切一部分出来，跑一遍就算完事。这不是评估，这是看热闹。合格的测试集设计要做分层覆盖：业务场景分层、输入难度分层、输出形态分层。

业务场景分层是第一条，核心思路是把你的用户访问分成几类，每类覆盖足够数量。比如电商客服机器人，你先要区分售前咨询、售后服务、物流查询、退换货处理这些子场景，每个子场景里还要覆盖常规问题、边缘问题、容忍度低的问题。别小看这个分类动作，它的价值在于你能看清模型在哪个子场景具体拉胯，而不是笼统地说“效果不好”。

输入难度分层是第二条。这是判断系统真实水平的关键。我习惯把测试样本分为三层：简单层（用标准话术问常规问题）、中等层（换表达方式或包含轻微干扰信息）、困难层（包含歧义、超长上下文或复合任务）。只拿简单层测试，你会做出一个虚假的自信；把三层加权看总分，才看得出你的系统边界在哪里。真实场景里用户的问法千奇百怪，递进难度的测试本质上就是压力测试。

输出形态分层也值得重视。不同任务类型要有不同的检查维度。需要抽取信息的任务，检查是否抽全抽准；需要生成的文本，检查事实性和风格是否达标；需要多轮对话的任务，检查是否保持上下文一致性。把这些维度拆开打分，相当于给模型表现画了张雷达图，哪块缺补哪块，而不是只看一个模糊的总分。

3.2 评估执行：人工打分、规则校验与LLM-as-a-Judge的组合打法

测试集建好之后，第二个问题是怎么打分。很多人以为评分必须靠人工，全自动都是骗人的。实际上成熟的评估体系是分层的，把人工、规则、模型评估三者结合，才最有效率。

第一层是规则校验，适合客观性强、答案确定的任务。输出格式对不对、关键词有没有、指定字段在不在，这些用代码写死规则就能判断，不消耗人力也不消耗token。我之前做过一个抽取任务，三分之一的质量问题都是靠规则层自动拦截的，比请人看效率高太多。

第二层是LLM-as-a-Judge，也就是用大模型给大模型打分。这个方法适合主观性强的任务，比如回答是否自然、是否贴切、是否完整。做法是设计打分依赖的评判Prompt，设好评分维度，让大模型输出一个带评分的结论。但有一件事必须提醒：用模型评估就是用一个不确定系统评估另一个不确定系统，要从机制上保证公平。一定要做盲评，不让打分模型看到哪个回答是哪次迭代的，避免“改动后倾向给高分”的隐形偏好。

第三层是人工抽检，适合疑难问题和敏感case。规则和模型都拿不准的，拉人看一眼，尤其是有业务背景的人。这一层可以只做到5%的抽检率，但必须长期存在，因为它是评估体系里兜底的那个确定性来源。

三层权重怎么定？我的习惯是：能规则必规则，不能规则的用大模型盲评，这两者之外的才进人工。把评估做成自动化流水线之后，才能做到“每次改动先用评估集回归一遍”的工程纪律，这是持续迭代的前提。

4. RAG与上下文工程：企业知识落地的关键链路

如果你做的是一个面向企业或垂直领域的AI应用，RAG几乎是绕不开的环节。原因也很现实：基座模型训练时没见过你们公司的内部资料、行业规范、私有业务流程，直接问它等于让它瞎编。RAG的核心思路很简单：在模型回答之前，先把相关的知识片段检索出来，拼进上下文里，让模型的回答有依据可循。

思路虽然简单，落地全是细节。我见过太多团队把RAG做成了“文档切块+向量搜索”，上线后才发现效果一塌糊涂：搜出来的片段不相关，相关的内容被切碎了检索不到，上下文拼了一大堆结果模型反而被干扰。这背后的根因在于：RAG的瓶颈通常不在“搜索技术本身”，而在“你对知识的组织和消费方式是否研究明白”。

4.1 检索链路：切分策略、Embedding与召回的后端配合

做RAG第一步是切分。常见做法是“按固定长度切块”，比如512个字一块，省事但质量很随缘。一个逻辑完整的段落被拦腰切断，半句话塞进向量库之后，检索出来的片段读着就像失忆的人说话，模型拿这种输入生成答案，效果如何只能靠运气。我自己更推荐的方法是按语义边界切分：优先用标题层级、段落、列表这种天然结构做边界，再配合模型或启发式规则补充语义块划分。切块大小上，我一般控制在200到500个token之间，太短会丢上下文、太长会稀释相关性。

切完之后，Embedding模型的选择和工作方式也有一些讲究。很多人习惯把所有文档一股脑灌进同一个向量模型，但不同领域其实可以做一些适配。如果预算和技术条件允许，可以用领域数据对Embedding模型做增量训练，这声音看着大但实际并不难理解：就像通用的字典查词够用，但如果你查的是医学术语，期望有一本医学词典会更准确。另外有一个通用细节：切块时记得把相邻块的一小段重叠区域带进当前块的向量，能明显改善切点位置的检索丢失问题。

召回之后还有个常被忽略的动作——重排。向量相似度检索出的TopK结果，可能有四成是无关内容，因为语义接近不代表信息准确。我的建议是在向量召回后端挂一个交叉编码器做重排，把Top50压到Top5，能显著提升最终进上下文的片段质量。这个环节优化空间大，是RAG里性价比最被低估的一步。

4.2 上下文取舍：不是检索越多越好

RAG做熟的团队都清楚一句话：检索到的东西越多，模型的负担越重。许多新手有一个默认假设，认为“上下文里相关内容越多，回答质量就越高”。真实实验做下来经常打脸：塞进六段高相关文本，效果反而不如只塞三段。原因在于，模型要同时处理的无关信息和有效信息一起增多，反而稀释了核心信号的权重。

所以上下文工程的核心是取舍。首先是去重：检索结果里经常出现多个表达相似的内容片段，如果不处理，模型会在重复信息上消耗宝贵的上下文预算。其次是排序：光去重不够，还得把最重要的信息放在上下文最前面的位置。LLM对上下文不同位置的注意力分布是有差异的，开头和结尾通常效果更好，中间容易被忽略。这个特征是模型训练时的注意力机制偏置决定的。

还有一个我们在实际业务里踩过的坑：把检索片段原封不动塞进Prompt，既不标注来源也不约束回答逻辑，模型经常出现“用了检索内容但没说清哪来的”这种问题。后来我们在Prompt里明确要求：“请优先基于给定资料回答，如资料中没有可引用内容，请直接说明资料未覆盖，而不是自行推测。”这个简单修改直接把幻觉率降下来不少。说到底，上下文工程不是简单把资料区填满，而是要像给一个信息过载的同事做简报，给他刚好看得完又够有用的信息量。

5. 上线前的硬仗：成本、延迟与可观测性

从开发环境跑到生产环境，是AI工程最激动也最容易翻车的一环。很多团队在开发阶段只关心“效果好不好”，等上了线才发现“太贵了”“太慢了”“出了问题根本不知道在哪”。这三个问题不是运营问题，而是工程问题，它们必须在系统设计阶段就预留好控制手段。

我参与过一个文档解析智能助手，开发阶段大家都很满意，一条条case跑得飞起，结果压测那天直接现场崩盘：用户并发一上来，单次请求平均耗时飙升到8秒，半个月的token预算一天干完一半。后来查下来，根因是系统里有一处没加缓存的重复调用——同一个文档被解析多次，每次都完整调用了一遍大模型。这类问题不压测根本暴露不了。所以对AI应用来说，线上性能和成本的表现，不是“上线后再优化”的事，而是从第一天起就要像对待核心功能一样对待它们。

5.1 推理侧的降本增效：缓存、批处理与模型分级

先聊成本。大模型应用的账单主要由三块构成：输入token、输出token、以及Embedding或微调等附加服务。其中输入token往往是大头，因为RAG和对话历史都会持续消耗。在这个结构下，降本的方向都很明确，就看有没有提前设计。

第一板斧是缓存。对公共知识类、规则说明类这类回答高度确定的问题，可以做成完全缓存，用相似度或语义哈希命中后直接返回离线答案，不走模型调用。对个性化强的问题，至少做“Key前缀缓存”，把System Prompt和固定检索结果缓存起来，省掉重复计算的输入token。我在一个实际项目里测算过，加了缓存后输入token消耗降了接近一半。

第二板斧是模型分级。线上应用根本不需要所有请求都使用同一个模型，尤其是最强也最贵的模型。把任务按复杂度路由：简单问答走小模型，复杂推理走大模型。判断方式可以是规则（问题长短）、也可以是分类模型（意图识别）。这里面有个核心的观察点：很多场景里70%的请求其实都是简单请求，用大模型是明显的性价比浪费，分级之后成本能再降一层。

第三板斧是推理侧的批处理。如果能接受非实时延迟，把同批次请求合并调用，可以大幅降低单条请求的推理成本。对报表生成、批量分析类任务尤其合适。对实时交互类任务，批处理往往不适用，但也可以参考异步化思路，把重计算挪到后台做，前端先返回轻量反馈。

5.2 可观测性设计：延迟、质量漂移与告警闭环

成本之后是延迟和可观测性，这两个放到一起说，因为运维手段是同一套。

延迟优化方面，最高的杠杆在推理阶段本身。减少输出长度、缩短Prompt、用流式输出替代一次性等待，都能直接改善用户体感。如果用的是自部署模型，那么量化、KV Cache、动态批处理这些推理优化手段也要考察。但有一个容易被忽略的点：很多延迟不是模型造成的，而是上游组件拖沓，比如检索太慢、外部API超时、代码里串行依赖过多。我处理过一个“模型输出只要2秒、总耗时却要7秒”的case，最后定位到问题是某个第三方工具接口连接池配置不当，每次请求都在建连上消耗了3秒多。这类问题不在评估集里反映，只能靠链路追踪抓出来。

可观测性方面，传统的监控埋点只能看到服务器指标，对AI应用还远远不够。你要额外监控三个层次的暴露：成本层（每天token消耗趋势、单用户成本、按场景的成本分布）、性能层（端到端延迟、模型调用延迟、检索延迟、并发容量）、质量层（线上bad case率、用户反馈低频关键词、回答内容里的风险词出现频率）。前两层技术团队都会做，但质量层的监控经常被忽视，而它恰恰是AI应用最特殊的风险点。

质量漂移是LLM应用上线后最阴险的问题。模型自身更新、用户问题分布变化、检索数据更新，都可能导致回答质量悄悄下滑，而用户不会主动告诉你“你的AI变笨了”，他们只会安静流失。所以我们上线后一直坚持“用评估集定期抽查线上日志”，每周跑一次回归测试，分数掉得明显就拉响告警，回滚或调整策略。这个习惯不算复杂，但救过我们不止一次。

6. 从Demo到生产：典型翻车场景与排查实录

最后分享几个实际项目里遇到的典型问题，把现象、排查思路和解决方案一条条列清楚，这些经验在教科书里基本找不到，全是真金白银踩出来的。

6.1 场景一：上下文太长导致模型“选择性失明”

现象：某知识库问答系统，用户问一个细节问题时，系统明明把包含正确答案的文档片段放进来了，模型却答错或直接答“资料里没找到”。排查过程先确认了检索链路没有问题，但打印出完整的系统Prompt后发现，上下文总长度达到了一万两千个token，而正确答案藏在第八千个token的位置——正好落进了“中间遗忘区”。找到原因后我们把上下文策略改了：先做无关片段裁剪，再把最相关的三条提到最前面，长度压到五k以内。结果同一条测试case的正确率明显回升，线上差评数量也降下来了。这个案例最典型的价值就是印证了那句老话：对上下文做减法，效果比加法好。

6.2 场景二：评估过拟合，上线即翻车

现象：某项目在离线评估集上跑分很漂亮，结果一上线用户反馈立刻糟糕。排查后发现评估集是从开发期Demo日志里攒出来的，样本的分布和线上真实输入已经严重不一致。比如评估集里三分之二是标准问法，但线上的真实问题里夹杂着大量口语化表达、错别字和上下文指代，系统在这些“脏输入”面前手足无措。这轮整改动作有三个：一是从线上日志重建了评估集并做分层覆盖；二是给系统加了基础输入预处理，对明显错别字和冗余语气词做清洗；三是建立自动化回流流程，定期把线上bad case补充进评估集。整改后，离线分数和线上体验终于对得上号，迭代节奏才找回来。这个教训的核心在于：评估集是有保质期的，它是活的数据资产，要和线上流量保持一致。

6.3 场景三：缓存策略不当，把错误答案缓存给了用户

现象：一个客服机器人上线后，用户隔几天问同一个问题，得到了一模一样的错误回答。查下来发现是语义缓存命中逻辑设置过宽，把部分质量有问题的回答也缓存住了，导致错误被反复投喂给后来的人。这属于低概率但杀伤力极大的隐患。解决思路是给缓存加三重约束：只有高置信度的答案（比如规则校验通过＋低温度生成）才允许进缓存；缓存答案设定过期时间，超时后用新模型重跑；所有缓存内容在返回前先过一遍关键词风险过滤。另外，清缓存的操作要做成“一键命令”，这样一旦发现线上错误answer缓存，马上可以全量清空，不用等它慢慢过期。

6.4 快速排查速查表

这张表整理出来之后，我让团队贴在每日站会旁边，出了线上问题先按行查一轮，大多数问题能在半小时内定位。排查问题的核心思路只有一个：不要盯着模型输出猜，要在链路的每个节点埋好标记，先确定断点在哪一环，再动手改。这是传统软件工程的排障思维，大模型应用比传统系统更需要这套确定性。

7. 几个容易被忽略的综合经验

写到这里，核心内容也差不多聊完了，最后再集中分享几点我实操下来觉得最重要、但又不方便塞进前面任何一个小节的经验。这些经验不属于某个具体技术模块，却会在项目任何一个阶段跳出来影响全局。

第一点，关于提示词版本管理。传统软件有Git管理代码，但在AI项目里，Prompt就是逻辑代码的一部分，很多团队却拿它当备忘录在管理，出了效果直接复制粘贴覆盖旧版本。这个习惯极其危险，因为线上优化经常需要对比“哪个Prompt效果好”，你如果没有版本记录，怎么对比？我的习惯是给每个Prompt写清楚版本号、生效时间、目标场景和关联评估集，每次修改走一次“评估集回归＋AB对比”的流程，确定胜出才上线。Prompt这只怪兽越早管住，后面越省心。

第二点，关于“效果数据”的采集。AI系统上线之后的一个重要任务，是持续记录用户的真实反馈信号——点踩、纠错、复制量、重新提问次数。这些信号既可以用来自动筛选bad case回流评估集，也可以用来计算系统质量漂移指标。很多人以为数据工程是模型训练阶段的事，实际上，应用上线后这套数据管道才是你最宝贵的资产，它会不断喂给你“系统哪里不行”的事实，而不是让你靠猜。

第三点，也是我觉得对长期做AI应用最重要的一点，就是保持对系统边界的清醒认知。大模型很强大，但它只是一个概率组件，不可能100%正确。工程的目标从来不是做出一个“永不犯错”的系统——那不现实；而是做一个“错得有限、错得可被监测、错得可快速修复”的系统。这个心态一旦建立起来，你和AI工程的相处就会少掉很多心浮气躁，因为你不再和概率较劲，而是在不确定性周围建起一圈护栏。

“ai-engineering-from-scratch”这条路，本质上就是在不确定性上面搭建确定性的过程。它不性感，没有“写一段高深Prompt”那么玄妙，但它真实地存在于每一个经得住考验的AI产品背后。如果你正打算或者正在从零开始做AI应用，希望这篇内容能帮你少绕几个弯。毕竟这行的机会窗口不会无限敞开，尽早把工程体系搭起来的人，才能稳稳接住AI这波浪潮。