1. AI工程到底在造什么从提示词到生产系统的思维转型这几年技术圈有个很割裂的现象一边是铺天盖地的“AI赋能”案例另一边是大量团队拿着大模型API做不出能稳定交付的产品。我身边不少朋友从零起步做AI项目起步动作几乎都一样——注册个Key、调通接口、写几段PromptDemo跑通了就兴奋地往架构图上填方案。结果呢十个项目有六七个死在“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 快速排查速查表症状优先排查方向常见处理方案回答明显与资料不符上下文裁剪策略、检索排序压缩总token、重排前置、限制来源范围生成内容突然变化模型版本是否更新闭源/开源均是锁模型版本、跑回归评估、必要时回滚延迟突然走高上游外部API超时、连接池耗尽抓链路追踪、加超时和重试、扩并发配置成本直线飙升缓存命中率下降、输出token过长检查缓存策略、限制输出长度、加用量告警特定用户群体差评多该群体输入分布与评估集偏差过大给该群体单独建评估集、做Prompt定向调优同问题两套回答未锁模型版本、缓存新旧混杂全链路锁版本、一键清缓存这张表整理出来之后我让团队贴在每日站会旁边出了线上问题先按行查一轮大多数问题能在半小时内定位。排查问题的核心思路只有一个不要盯着模型输出猜要在链路的每个节点埋好标记先确定断点在哪一环再动手改。这是传统软件工程的排障思维大模型应用比传统系统更需要这套确定性。7. 几个容易被忽略的综合经验写到这里核心内容也差不多聊完了最后再集中分享几点我实操下来觉得最重要、但又不方便塞进前面任何一个小节的经验。这些经验不属于某个具体技术模块却会在项目任何一个阶段跳出来影响全局。第一点关于提示词版本管理。传统软件有Git管理代码但在AI项目里Prompt就是逻辑代码的一部分很多团队却拿它当备忘录在管理出了效果直接复制粘贴覆盖旧版本。这个习惯极其危险因为线上优化经常需要对比“哪个Prompt效果好”你如果没有版本记录怎么对比我的习惯是给每个Prompt写清楚版本号、生效时间、目标场景和关联评估集每次修改走一次“评估集回归AB对比”的流程确定胜出才上线。Prompt这只怪兽越早管住后面越省心。第二点关于“效果数据”的采集。AI系统上线之后的一个重要任务是持续记录用户的真实反馈信号——点踩、纠错、复制量、重新提问次数。这些信号既可以用来自动筛选bad case回流评估集也可以用来计算系统质量漂移指标。很多人以为数据工程是模型训练阶段的事实际上应用上线后这套数据管道才是你最宝贵的资产它会不断喂给你“系统哪里不行”的事实而不是让你靠猜。第三点也是我觉得对长期做AI应用最重要的一点就是保持对系统边界的清醒认知。大模型很强大但它只是一个概率组件不可能100%正确。工程的目标从来不是做出一个“永不犯错”的系统——那不现实而是做一个“错得有限、错得可被监测、错得可快速修复”的系统。这个心态一旦建立起来你和AI工程的相处就会少掉很多心浮气躁因为你不再和概率较劲而是在不确定性周围建起一圈护栏。“ai-engineering-from-scratch”这条路本质上就是在不确定性上面搭建确定性的过程。它不性感没有“写一段高深Prompt”那么玄妙但它真实地存在于每一个经得住考验的AI产品背后。如果你正打算或者正在从零开始做AI应用希望这篇内容能帮你少绕几个弯。毕竟这行的机会窗口不会无限敞开尽早把工程体系搭起来的人才能稳稳接住AI这波浪潮。