从零开始搭建AI工程我的完整路线与避坑记录这个标题“ai-engineering-from-scratch”其实藏着两个关键词一个是“AI”一个是“engineering”。很多人一看到AI就想到模型、算力、算法但真正在项目里跑过一轮之后你会发现AI工程的难点从来不在“训练出一个模型”而在于怎么把模型能力稳定、可靠、可维护地嵌进真实业务里。这篇内容我打算把自己从零起步做AI工程的经验完整拆开从环境搭建、Prompt工程、Agent开发到质量保障和问题排查全部走一遍适合刚入行想系统学习AI开发的读者也适合已经在调API但总觉得差点工程感的同学。看完之后你至少能建立起一套自己的AI工程框架而不是今天调个接口明天拼个提示词。1. AI工程的整体设计与思路拆解1.1 从“会调API”到“会做工程”的认知跨越刚接触AI开发的时候大多数人的路径是从调用大模型API开始的——写个Prompt调接口拿到回复觉得“哇AI好厉害”。但真正进入工程阶段你会发现这条链路远没有想象中那么简单。一个完整AI工程至少要包含需求拆解、数据准备、模型选型、Prompt设计、结果校验、异常兜底、成本控制、效果评估这八个环节而且每个环节之间是相互耦合的。我用一个生活化的例子来解释把AI工程想象成开一家餐厅。大模型API就像你请来的主厨能力很强但脾气不定Prompt是你的菜单设计直接影响主厨发挥数据是食材品质决定了菜品上限评测和监控是食品安全检查没它你不敢开业。很多人只盯着“请到好主厨”这一件事结果菜单乱写、食材随意、没有品控开业就翻车。AI工程的核心就是用流程和规范把“不稳定的智能”变成“相对稳定的服务”。从零开始的第一个关键决策就是明确你要做的是“应用型AI工程”还是“基础模型研发”。绝大多数业务场景属于前者——基于现成大模型比如通过API调用或本地部署开源模型构建具体应用。这意味着你的核心竞争力不在模型参数而在工程化能力怎么设计Prompt、怎么编排Agent流程、怎么评估效果、怎么控制延迟和成本。对初学者来说这条路也是性价比最高的起点。认清这个边界后面所有的工作才不会做偏。1.2 为什么“from scratch”不等于“不用任何现成工具”这里要澄清一个常见误解。“From scratch”在AI工程语境里指的是“从零建立起完整的工程体系”而不是“从零开始训练一个模型”。我见过不少人一听到from scratch就直接去研究Transformer源码、准备自己训练大模型结果半年过去还在调参业务一个没落地。真实的AI工程开发者绝大多数工作是在“系统地组装和优化现有AI能力”而不是“从第一性原理重写AI”。我自己的实践路径是分层的。底层是模型层直接选用靠谱的开源模型或商用API中间是框架层用LangChain、LlamaIndex这类工具把模型封装成可复用的能力模块顶层是业务层针对具体场景设计和优化Prompt、编排流程。每一层只关注自己的职责边界。这样做的好处是每一层出问题时可以快速定位、独立替换而不是牵一发动全身。1.3 工程思维的核心把不确定性当成系统设计的一部分大模型应用和传统软件开发有一个本质区别——传统代码的行为是可预期的模型输出是不可预期的。一个普通的函数调用输入相同、输出一定相同但你给模型同一个Prompt问十次可能得到十种不同的回答。这种不确定性不是Bug而是模型的固有属性。工程化的关键不是消除不确定性——这不可能也不必要——而是把不确定性纳入系统设计确保在模型偶尔“答非所问”的时候整个系统依然能稳定运行。所以我在设计AI系统时默认假设模型一定会出错然后在外面套上“校验层”和“兜底层”。校验层负责判断模型输出是否符合预期格式和内容要求兜底层负责在校验不通过时进行重试、降级或人工介入。这个思路贯穿整个工程体系后面讲到的所有实操内容其实都是围绕“怎么管理不确定性”展开的。2. 从零起步的环境搭建与基础技术栈2.1 Python环境与项目结构的最佳实践AI工程开发绕不开Python但这不意味着你要成为一个Python专家才能动手。对初学者来说关键是先把环境管理这件事做对后面能省掉大量麻烦。我强烈建议从第一步就使用uv或conda管理Python环境而不是直接往系统Python里装包。以我自己现在常用的方式为例用uv初始化项目uv venv .venv source .venv/bin/activate uv pip install openai langchain python-dotenv pytest这里面有个容易被忽视的细节所有密钥和敏感配置一律走环境变量或.env文件绝不硬编码在代码里。我见过太多人把API Key直接写在Python文件里传到Git仓库然后被爬虫扫走账单直接爆掉。用python-dotenv统一管理配合.gitignore排除环境文件是AI工程最基本的安全底线。项目结构方面我会在一开始就按功能模块分目录而不是所有代码堆在一个文件里project/ ├── app.py # 入口文件 ├── core/ # 核心业务逻辑 │ ├── engine.py # 模型调用封装 │ ├── prompts.py # 全部Prompt集中管理 │ └── validators.py # 输出校验逻辑 ├── api/ # API服务层 ├── tests/ # 测试用例 ├── config/ # 配置文件 └── .env # 环境变量不入库这样的结构看起来简单但它解决了一个真实痛点Prompt集中管理。当你的系统里有几十上百个Prompt时散落在代码各处的Prompt会变成灾难——改一个措辞要全局搜索而且很容易漏改。集中管理之后你可以统一做版本迭代、A/B测试甚至做一个简单的Prompt配置中心。2.2 大模型API的接入与封装踩坑指南接入大模型API是第一个会让你踩坑的点。市面上主流的模型服务商接口格式各不相同返回结构也有差异。我建议不要直接在业务代码里调用API而是封装一层统一的模型接口层把不同服务商的差异挡在外面。最基本的封装逻辑是这样from openai import OpenAI client OpenAI(api_keyos.getenv(API_KEY), base_urlos.getenv(BASE_URL)) def chat(model: str, messages: list, temperature: float 0.7): try: response client.chat.completions.create( modelmodel, messagesmessages, temperaturetemperature, timeout30 ) return response.choices[0].message.content except Exception as e: # 统一异常处理记录日志 logger.error(f模型调用失败: {e}) raise这段代码里有几个细节值得注意。第一timeout参数一定要显式设置否则默认超时可能长达几分钟你的接口响应就会被拖垮。第二temperature是一种“随机性旋钮”值越高回答越发散越低越稳定。做分类、抽取这类对准确性要求高的任务我一般设0到0.3做创意写作、头脑风暴可以拉到0.7甚至更高。这个参数后面会反复提到。还有一点务必在正式环境做好重试机制。模型服务商在高峰期经常出现瞬时错误简单的指数退避重试就能大幅提升成功率。我用的是tenacity库三行代码搞定from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(min1, max10)) def chat_with_retry(model, messages): return chat(model, messages)2.3 模型选型一个被反复低估的决策模型选型是整个AI工程里ROI最高的决策之一但很多人对它不够重视。选错了模型后面所有环节都在给这个错误买单。我自己总结了一套比较实用的选型框架先看任务类型。如果是简单分类、信息抽取、实体识别这类结构化任务中小尺寸模型比如7B~14B级别的开源模型往往就够了用大模型属于浪费。如果是复杂推理、长文本生成、角色扮演类任务才需要考虑70B级别以上的模型或顶级商用API。再看成本结构。有些模型看似便宜但需要多次重试才能得到理想结果综合成本反而更高。我习惯做“有效成本”测算单次调用成本除以一次成功所需平均调用次数才是真实的单任务成本。最后看数据隐私要求。业务数据能不能出内网如果能用商用API是最省事的如果不能必须在私有环境部署开源模型。这里我特别提醒一句不要在Prompt里塞未经脱敏的敏感信息哪怕用了商用API也不行。3. Prompt Engineering从“问对问题”到“系统化设计”3.1 为什么Prompt是整个AI工程最关键的杠杆如果说模型是引擎那Prompt就是方向盘。同一台引擎方向盘打得不同跑出来的路线天差地别。我见过不少团队模型选了最好的、算力砸了最多的结果输出质量一塌糊涂最后排查半天发现是Prompt写得一塌糊涂。Prompt Engineering提示工程本质上是一种“面向语言模型的编程范式”。它的核心命题是如何用自然语言把任务需求完整、清晰、可执行地传达给模型。你写的每一句话都在影响模型对任务的理解。而模型的理解偏差会直接传导到最终的业务结果上。我自己的实践体会是Prompt Engineering可以分为三个层次大多数人停留在第一层止步于第二层做到第三层的人极少第一层会写指令——告诉模型“你要做什么”能应付简单任务第二层会设框架——把角色、任务、限制条件、示例、输出格式全部结构化解决复杂任务第三层会做迭代——把Prompt当作代码来管理、测试、版本化与评测体系联动持续优化这个认知对我帮助很大分享出来。下面展开说说第二层和第三层具体怎么做。3.2 构建结构化Prompt角色、任务、限制与示例四要素很多人写Prompt就是一句话“帮我写个周报”。这种Prompt不是不能用而是结果极不稳定。模型没有上下文不知道你是谁、工作是什么、周报要写给谁看。与之相比一个经过设计的结构化Prompt会把所有决策上下文显式声明大幅压缩模型的猜测空间。我常用的Prompt模板包含四个部分你是一名[角色]需要帮助用户完成[任务描述]。 具体要求 1. [限制条件一输出语言/风格/字数等] 2. [限制条件二禁止事项/处理边界] 3. [输出格式JSON/列表/Markdown等] 参考示例 输入XXX 输出XXX这里每个部分都有存在的原因。角色设定给模型一个“立场”让它按特定视角输出任务描述用动词开头明确“做什么”限制条件是为了约束模型的发挥自由防止跑偏示例Few-shot则是“锚定输出格式”最有效的手段——给两到三组输入输出对模型基本就能跟着范例走。举个例子我要做一个“技术文档摘要提炼”的功能结构化Prompt可以这样写你是一名资深技术编辑请阅读下面的技术文档并生成结构化摘要。 要求 - 用中文输出不超过200字 - 以列表形式输出背景、核心内容、结论 - 不添加原文没有的信息 - 技术术语保留英文原词 文档 {{document_content}}看起来平平无奇但实际效果对比过就知道加了这四个要素之后输出的稳定性和格式可解析性会有一个质的提升。特别是输出格式明确为结构化数据后下游的解析和校验会轻松很多。3.3 从提示词到“提示词系统”版本管理与评测闭环把Prompt当成“代码”来管理是Prompt Engineering从入门到进阶的分水岭。我经历过一次惨痛教训项目上线后同事觉得某个Prompt效果不好随手改了一句措辞结果整个下游输出格式全部变化解析程序崩溃线上服务挂了整整两个小时。从那以后我强制要求项目里的所有Prompt必须遵循三个规范统一存储为可版本化的文本文件而不是散落在代码里。我把每个业务场景的Prompt单独存到一个.md或.txt文件里文件名带版本号比如summary_prompt_v3.txt。代码运行时从文件加载Prompt改Prompt不是改代码可以走独立的审批与发布流程。每次修改必须记录变更内容和原因。不是写那种“优化了一下”的废话记录而是具体到“修改了角色设定从技术编辑改为产品经理”“增加了字数限制”“调整了示例输入的行业属性”。有了变更记录才能回溯和撤销。建立Prompt效果评测集。准备一个固定的测试用例集比如50个典型输入每次改了Prompt之后跑一遍评测集看输出质量评分是高是低。没有评测集就谈不上优化因为你根本不知道改动是变好了还是变差了。我自己用的是一个很轻量的方式用GPT-4给输出按多个维度打分和旧版做对比。这其实就是后面讲到的LLM-as-a-Judge用大模型当裁判的雏形。4. AI Agent与多模型协同构建真正的“AI工程系统”4.1 从“单次问答”到“自主完成任务”的范式跃迁纯粹的问答式调用——用户提问模型回答——是最简单的AI应用形态但它的能力天花板很低。真正体现AI工程价值的是构建AI Agent智能体让模型不只是“回答”而是能够规划步骤、调用工具、获取信息、验证结果像一个独立的执行者那样去完成多步任务。举一个我实际做过的场景。用户提一句“帮我调研一下这篇论文的核心创新点并对比现有方法”。如果只是问答式调用模型只能凭训练数据里的知识泛泛而谈很容易编造不存在的引用。但如果是一个Agent它的执行链路会变成先把论文文本加载进来提取关键信息标题、方法、实验结果调用联网搜索或知识库检索查找相关对比方法综合信息生成对比分析报告校验引用来源是否真实存在每一步都是一次模型调用但Agent通过循环和工具调用把它们编排成了一个完整的任务流。用户得到的不是一次“猜测”而是一个经过多步验证的综合结论。我第一次感受到Agent的威力是在做一个资料整理项目的时候——任务涉及十几个网页的逐页信息抽取与汇总。如果靠手工写脚本需要处理各种页面结构差异费时费力但如果让Agent自动决定“先打开哪些页面、提取什么字段、怎么合并冲突信息”整个任务的编码量大幅降低而且面对页面微调时韧性更强。4.2 Agent的核心架构规划、工具、记忆与循环虽然Agent的概念听起来很科幻但拆开来看一个可落地的Agent系统其实由四个核心模块构成规划器Planner负责将任务拆解为多个步骤。它接收用户的目标输出一个“待办清单”。比如“写一篇产品评测文章”可以拆成“查找产品参数”“查找用户评价”“对比竞品”“撰写初稿”“润色修改”五个步骤。规划结果的表现形式通常是一组结构化动作序列。工具层ToolsAgent不是闭门造车它需要外部能力——搜索引擎、数据库查询、代码执行器、文件读写、API调用等。每个工具在Agent系统中注册为“一个函数一段功能描述”模型根据描述决定何时调用哪个工具。这里的设计核心是工具的接口简洁、描述准确因为工具描述本身相当于Agent的“说明书”写得不够清楚Agent就不会用。记忆模块MemoryAgent需要“记住”对话历史和中间结果。最简单的实现是把完整上下文都塞进模型的输入窗口但上下文一长成本和延迟都会飙升。工程上通常需要分层记忆短期记忆当前任务的中间结果、长期记忆用户的历史偏好、跨任务的背景知识。执行循环LoopAgent本质上是一个不断循环的“思考-行动-观察”过程。模型思考下一步做什么执行工具调用拿到工具结果之后再次思考直到任务完成为止。循环需要一个终止条件常见的是“步骤数达到上限”或“模型判定任务已完成”。我用一个简化版伪代码来说明这个架构怎么落地class SimpleAgent: def __init__(self, tools, max_steps5): self.tools {tool.name: tool for tool in tools} self.max_steps max_steps def run(self, task): messages [{role: user, content: task}] for step in range(self.max_steps): reply self.llm_reply(messages) # 模型决策 action parse_action(reply) # 解析是否调用工具 if action is None: # 模型认为可以收尾 return reply result self.tools[action.name].execute(action.args) messages.append({role: assistant, content: reply}) messages.append({role: tool, content: result}) return 已达到最大步骤未完全完成4.3 多Agent协作与工作流编排让专业Agent各司其职当单个Agent的能力趋于稳定后下一步自然就是“多Agent协作”。核心思想很简单让每个Agent只专注于一个领域然后通过一个“调度者/协调者”来统一编排避免把所有能力塞进一个Agent导致Prompt爆炸和互相干扰。我的一个实际项目里用了三个Agent协作来完成一篇行业分析报告信息采集Agent负责联网搜索、获取数据、筛选信息分析写作Agent负责把采集到的信息分析重组形成初稿质量审校Agent负责检查初稿的事实性错误、逻辑漏洞、格式问题调度者先把任务发给信息采集Agent拿到结果后传给分析写作Agent再由审校Agent做最后把关。三个Agent各司其职每个Agent的Prompt都简洁清晰不背负额外职责出了问题也好定位。这里有一个重要的工程判断不是所有场景都需要多Agent。当你用一个Agent加几个工具就能搞定任务时引入多Agent只会增加系统复杂度、延迟和成本。多Agent的真正优势在于“隔离关注点”让每个环节可以使用不同的模型比如信息采集中可以用速度快的小模型写作环节用推理能力强的大模型以及对每个环节单独做质量控制和成本监控。如果场景简单别为了“炫技”而过度设计。4.4 工具调用的可靠性与容错设计Agent系统的可靠性短板往往不是模型本身而是工具调用质量。模型可能生成错误格式的工具调用参数工具可能超时或返回异常数据多个工具之间还可能存在隐形依赖。这些在工程上都必须兜住。我的做法是三层防护。第一层是调用参数校验在模型生成工具调用指令后先做一次JSON格式和字段校验不合格直接要求模型重新生成不给它机会把坏参数传给工具。第二层是工具执行异常捕获任何工具调用都包在try-except中超时、空返回、格式非法都作为“执行失败”反馈给模型让模型决定是换个方式调用还是换个工具。第三层是结果截断与摘要工具返回的内容可能非常长比如爬回来的整篇文章几十KB超过模型上下文窗口必须先截断或摘要后再喂回给模型否则会直接报错。这层容错设计非常重要。一个没有兜底的Agent在模型输出参数稍有偏差时就会整个崩溃看起来就像是“AI不靠谱”。而把边界处理到位之后很多看似“AI犯傻”的问题其实都在系统内部消化掉了。5. AI工程的质量保障与上线避坑指南5.1 效果评测没有“度量衡”就没有优化做AI工程项目最忌惮的一句话是“感觉效果还不错”。感觉不是度量。没有一套稳定的评测机制你就没法判断一次改动是变好了还是变坏了也没法在多个方案之间客观做选择。我在项目里落地的一套轻量评测方案如下第一步攒一个高质量测试集。50到100条覆盖典型场景的输入就够起步。测试集分为“标准集”日常高频场景和“边界集”异常输入、模糊指令、超长文本等分开记分。第二步定义评分维度。不同任务维度不同。比如信息抽取类任务看重准确率和完整率内容生成类任务还关注流畅度和风格一致性。每个任务都有“硬性指标”比如输出必须是合法JSON、必须包含关键字段和“软性指标”内容是否准确、逻辑是否自洽。第三步跑分并记录。每轮Prompt或参数调整之后在同样测试集上重新跑一遍把分数和变更记录一起归档。实测发现这套方法对Prompt迭代的帮助非常直接。曾经我优化一个客服问答分类器感觉新版Prompt逻辑更“清晰”但是跑完评测集之后发现准确率反而下降了5个百分点。当时的感觉是“自己觉得好”和“数据觉得好”之间差别太大了。现在没有评测结果我心里根本不踏实。5.2 输出校验与“格式围栏”防止模型胡言乱语模型输出不符合预期格式是AI工程上线时最头疼的问题之一。你今天让它输出JSON它明天心情好给你加一段解释文字你规定只能从三个选项里选一个它非要自创第四个选项。解决这类问题有一个系统性的方法论——我称之为“格式围栏”策略。第一层围栏在Prompt里穷举格式要求和反例。比如必须只输出JSON对象不要输出任何解释文字。 允许字段type限定值为tech/news/review、title、summary、tags。 不要使用Markdown代码块包裹。第二层围栏用代码做硬校验。模型输出后先走解析器用JSON解析或用正则在关键位置做检查。解析失败就直接进入“重试通道”——把错误信息反馈给模型要求它按格式重新输出。最多重试两到三次。这一招能解决九成以上的格式问题。第三层围栏为关键任务设置“选择型输出”而非“生成型输出”。如果任务是从候选类别中做判断就要求模型先输出选项序号而不是选项文本再在代码里映射为最终结果。这等于把开放式的文本生成问题降维成了确定性的选择问题格式稳定性大幅提升。我之前处理过一个多标签分类场景直接让模型输出标签名结果三种标签里出现几十种五花八门的排列组合下游匹配一塌糊涂。后来改成让模型输出标签编号配合逻辑校验问题彻底消失。5.3 成本控制不让API账单悄悄吃掉项目利润做AI工程绕不开钱。大模型API按token计费而token消耗的大头往往不在“一次问答”而在“长上下文”、重试和Agent多步调用上。等账单出来才发觉超标项目利润已经被吃掉了。控制成本有几个有效手段。第一精简输入。在喂给模型之前先做内容的去重、截断、摘要。尤其在做长文档处理的时候一次性塞入全文和塞入精炼摘要的token消耗可能相差十倍。第二模型分级。根据任务难度选用不同规模的模型——简单任务用便宜的小模型复杂推理才用贵的大模型平均成本直接下降。第三是缓存这是一个常被忽略的点。很多业务场景中用户的请求高度相似比如同一批商品描述反复需要生成摘要完全可以用语义缓存把之前的模型答案存起来下一次命中相似Query时直接返回不必重新调模型。我实施过一次缓存命中率接近30%对账单是非常直观的改善。5.4 典型故障与排查实录做AI工程这么长时间我几乎踩过所有常见的坑。下面把几个最具代表性的问题整理成速查表你遇到类似情况可以直接照着排查。故障现象可能原因排查思路输出内容经常有错别字或逻辑混乱temperature设置偏高1.0检查temperature尽量调到0.2以下再测同样的Prompt结果忽好忽坏输入Prompt中存在非确定性因素或者模型版本被悄悄切换固定模型版本检查服务商是否有模型升级说明输出JSON解析时不时报错模型返回了Markdown代码块或额外文本加上“不要输出任何解释文字”限定并做解析失败自动重试Prompt改了之后效果反而变差改了一处措辞但影响了下游依赖建议跑一遍评测集对比结果不要凭感觉判断Agent执行到第三步突然中断工具返回结果过长超出模型上下文限制对工具结果做截断或摘要再喂回模型接口响应延迟高输入token或输出token过长频繁触发模型服务限流精简Prompt、限制输出长度、加上限流等待逻辑账单比估算高出数倍一次任务内模型循环调用次数过多检查Agent的max_steps确认是否有死循环在这些问题里我一直认为“上下文超限”最凶险。很多工程新手喜欢把长文档全文丢给模型做分析觉得“模型能处理长文本肯定没问题”。实际上输入一旦超过模型的上下文窗口要么直接报错要么中间片段被悄悄忽略你还不自知。解决方式永远是预处理——切片、摘要、按需检索而不是无脑全塞。5.5 上线前的压测与灰度发布从Demo到产品的关键一跃从Demo到线上产品是一条巨大的鸿沟。Demo只需要“看起来能用”线上服务必须应对并发、延迟、异常输入、恶意攻击等一堆“非功能性问题”。我的上线流程分四步走第一步单请求压测。先单独测一个请求的完整耗时——从用户发起请求到拿到结果。AI应用的耗时大头在模型调用上一个简单问答可能1到2秒多步Agent可能达到10秒以上。如果超过业务容忍的上限就必须做异步化处理改成“先返回任务ID再轮询结果”的模式。第二步并发压测。模拟多个用户同时请求观察服务的响应时间和错误率。这里最可能暴露出来的瓶颈是外部模型API的限流——服务商对每分钟请求数有硬性限制你在并发压测时会看到大量429错误。解决方式是本地做一层“调用队列令牌桶”控制出站速率。第三步异常注入测试。故意给系统喂空输入、超长输入、重复提交、以及各种“刁钻”Prompt比如要求模型透露系统Prompt、进行有害内容生成等。这一步的目的不是追求系统“什么都能答”而是确保系统在异常场景下能优雅拒绝或降级而不是直接抛5xx。第四步灰度发布。线上流量先切5%到新版本观察核心指标响应成功率、平均耗时、用户反馈是否平稳再逐步放量到50%、100%。不要一次全量上——模型版本、Prompt、Agent编排任何一处的细微差异都可能在真实流量中放大成事故。6. 写在最后AI工程的核心心法如果让我用一句话总结这段AI工程的实践经历那就是“模型能力决定上限工程能力决定下限”。我见过太多项目模型选得顶级、算力资源充足但因为Prompt管理混乱、评测机制缺失、异常兜底不足最终线上效果一塌糊涂。反过来也有不少项目用的只是普通模型但因为工程体系扎实每一步都在可控范围内最后交付的质量反而超出预期。在实际操作中我还有三个心得体会想分享给正在走这条路的人。第一养成“先写评测集再写Prompt”的习惯。很多人拿到需求第一反应是打开聊天窗口开始写Prompt我的建议是先把测试集攒出来哪怕只有二三十条。有了评测集你后面的每一次调整都有了标尺不会瞎优化。第二任何模型输出都要过一遍“真实性校验”。大模型存在幻觉问题是常态不是例外。涉及事实性的内容输出要么让模型给出可验证的来源要么接一层检索增强把外部知识库的内容作为参考依据要么加一道人工抽查机制。不要天真地以为模型“看起来说得挺对”就真的对。第三保持简单。一个功能如果用单个模型调用外加一层校验就能实现就不要过度设计成多Agent协作。每增加一个环节就增加一份延迟、一份成本、一份出错概率。AI工程的能力不体现在系统有多复杂而体现在复杂与可靠之间找到了那个最适合业务的平衡点。AI工程这条路最大的挑战不是学不完的新技术而是在不确定性中建立确定性的能力。希望这篇内容能帮你把第一段路走稳一点。