1. 先泼一盆冷水AI工程从来不是会写提示词我见过太多人把AI工程理解成用AI写段话或者调一个API返回结果。真正上手做过项目的人会明白这两者之间的距离大概相当于会点火和会造发动机之间的距离。举个最直观的例子同样是用大模型处理一份合同初学者写一句帮我总结这份合同的风险点得到的是一段泛泛而谈的概括而有工程思维的人会设计一套流程——先拆页、分段清洗、定义风险类型枚举、让模型逐段标注、再把结果聚合、最后用规则引擎复核关键条款。同样的模型同样的知识库后者的输出质量、稳定性和可追溯性完全碾压前者。ai-engineering-from-scratch这个标题翻译过来就是从零开始搞AI工程。它不是一个名词而是一条路线图。我在这条路上走了将近两年从第一个简单脚本到现在能支撑并发调用的完整系统中间踩过的坑、推翻过的设计、重写过的代码都比想象中多得多。这篇文章我把整条路径拆开来讲提示词工程、Harness Engineering编排层、AI Agent、工具链搭建、以及落地过程中的实战经验每个环节都会讲清楚为什么这么做和实际做的时候会撞上什么墙。适合读这篇文章的人有三类一是刚接触AI开发、想建立系统认知的初学者二是已经能用API但总觉得不够稳、不够好用的开发者三是想在企业内部推动AI落地的技术负责人。这篇文章不教你怎么问问题而是教你怎么把问问题这件事本身变成一个可靠、可复用、可规模化的系统。2. 提示词工程Prompt Engineering所有AI工程的底层地基2.1 为什么说提示词是接口设计而不是说话技巧很多人对提示词工程有一个误解觉得它是怎么把话术写得更优美这就大错特错了。提示词工程更准确的类比是接口设计——你在定义一个稳定的输入输出契约。我举个具体例子。早期我做合同风险提醒项目时最开始用的提示词是帮我看看这个合同有没有问题模型给的结果时好时坏有时候能列出风险点有时候给出的是合同背景介绍。后来我把提示词重构成这样你是一名法务专家负责合同风险审查。请按以下格式输出结果 - 风险级别高/中/低/无 - 风险条款编号精确到条款号 - 风险描述不超过50字 - 修改建议不超过100字 合同文本如下以START和END标记边界 START [合同内容] END 若未发现风险输出无风险不要附加任何其他内容。效果立竿见影。原因不在于我会说话而在于我给模型定义了清晰的输出协议建立了角色约束和边界标记。从工程视角看每一次提示词设计本质上是在定义函数签名。你在构思提示词时应该像设计API一样思考输入是什么格式输出是什么结构边界条件如何处理异常情况怎么兜底我还建议给每个提示词起版本号。别笑这不是形式主义。我见过太多团队prompt改了一版又一版效果回退时根本不知道是哪次改动造成的。我自己的项目里每一个prompt模板都带一个version字段模板内容改动时必须同步更新版本号配合后端的prompt管理表一起使用。这条习惯后来帮我省了无数次排查时间。2.2 结构化提示词的三层结构角色层、任务层、输出层复杂的生产级提示词通常需要三层结构缺一层都会出问题。我这套方法是从Anthropic的工程实践中演化出来的经过了许多实际项目的检验整理如下第一层角色层。给模型一个明确的行为基准。注意不是简单说你是专家而是要说清楚你的知识边界、你的工作原则、你的输出风格。比如你是一名资深数据工程师熟悉SQL性能优化。你的原则是 1. 永远先分析查询计划再给出改写建议 2. 对于超过500万行的表强制考虑索引策略 3. 输出建议时必须附带理论依据不能只给结论。这一层的作用是让模型进入专业模式减少常识性错误。很多人忽略了一个细节角色设定里应该包含否定约束也就是明确告诉模型不要做什么。比如上面第三条就是典型的否定约束。第二层任务层。描述你要做什么但不要急着写怎么做。这里的关键是把目标拆解成模型可以逐步执行的子任务序列也就是用思维链的方式引导。举例来说与其说帮我优化这段SQL不如说请按以下步骤处理这段SQL 第一步解读该SQL的业务含义判断涉及哪些表、哪些字段 第二步分析当前执行计划中可能的性能瓶颈全表扫描、隐式转换、笛卡尔积等 第三步针对每个瓶颈给出具体的优化方案 第四步输出改写后的SQL并解释为什么这样写更高效。第三层输出层。这一层很多初学者完全忽略。输出层的作用是让模型的结果可程序化解析。生产环境里你不可能每次都用肉眼去看模型返回的自然语言你需要的是稳定结构。前文合同审查的例子已经是输出层的最佳实践这里补充一个技巧给出正例和反例。比如输出格式要求 - 每条建议占一行用|分割字段 - 正确示范高|第3.2条|违约金比例过高超过法定上限|建议调整至每日万分之五 - 错误示范该条款存在法律风险不要这样写缺少结构正例反例的对比比一百句请严格按照格式输出都管用。2.3 温度、Top-p和max_tokens一批真正影响输出的参数说完了提示词本身再聊一个很多人没搞明白的东西采样参数。它们在工程意义上的重要性不亚于提示词本身。我在生产环境里的经验值如下这是基于我个人项目的实践总结不同场景需要微调参数取值适用场景备注temperature0~0.3分类、抽取、结构化输出越低越稳定建议从0.2起步temperature0.5~0.7生成式写作、发散式思考高于0.7容易胡说八道top_p0.8~0.9配合temperature使用二选一调整即可不必同时精细调max_tokens按需估算控制成本与延迟别不舍得给截断比冗长更糟糕stop自定义结束标记控制对结构化输出很有用有一个反直觉的坑很多人以为temperature调低模型就会变聪明实际上它只是变得保守倾向于反复输出训练集中最常见的答案。在分类任务里比如判断一段文本的情感极性temperature0往往效果最好因为你要的是稳定正确但在生成创意文案时temperature0.3会让所有结果都长得一模一样完全没有多样性。另一个常见问题是max_tokens设得太小。模型在生成过程中如果你设置了截断上限API不会告诉你输出被截断了你拿到的是一段戛然而止的文本。我曾经在一个日志分析项目上被这个坑惨了模型分析日志时输出被截断我拿后半段去解析JSON每次都在同一个地方报错花了半天才意识到是截断问题。现在我的代码里固定有一个is_truncated检查逻辑response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], max_tokens2000, temperature0.2, ) content response.choices[0].message.content finish_reason response.choices[0].finish_reason if finish_reason length: logger.warning(输出被截断考虑增大 max_tokens 或拆分输入)3. Harness Engineering真正拉开差距的编排层3.1 什么是Harness Engineering从单匹马拉车到多马协动这是最近一年AI工程领域讨论度直线上升的概念但我发现很多人对它有误解。Harness Engineering直译是挽具工程从马车时代的挽具harness借来的词——它解决的原始问题是一匹马的力量不够如何把多匹马套在一起让它们合力拉动一辆车。在AI工程里这个思想有非常具体的映射单一模型的能力不够如何把多个模型同构或异构编排起来组成一个更强的系统。它不同于简单的多Agent聊天而是一种系统级的架构设计。我最初接触这个概念是因为一个真实需求公司的客服系统要同时处理用户问题分类、情感识别、知识库检索和答案生成四个子任务。最开始我的做法是一个大模型一把梭——把四个任务全塞进一个prompt结果发现四个任务互相干扰。分类任务要求低温度、保守生成任务要求较高温度、有创造性。同一个模型、同一个temperature根本没法同时满足两端需求。这就是拆出来的问题。最后我设计了四个独立模型调用然后用一层编排逻辑把它们串联起来形成一个流水线。后来我才知道这就是Harness Engineering的雏形利用多个异构模型的差异化能力通过编排逻辑组合出单个模型无法胜任的系统。3.2 为什么你需要多个模型而不是一个大而全的模型再往深里说一步。行业内有个流行的迷思GPT-4级别的大模型什么都能干我只需要调一个就好。说真的这个说法在小规模demo阶段完全成立但在生产规模下有两个致命问题第一是成本失控。一个复杂的分析任务如果每次请求都携带大量上下文token消耗是指数级攀升的。我算过一笔账我维护的一个内部文档问答机器人如果把OCR、摘要、检索、生成全部用同一个旗舰模型单次问答成本大概是2元人民币拆成OCR用小模型、摘要用中模型、生成用旗舰模型之后单次成本降到了0.4元效果几乎无差别。省下来的钱够我再开两个实验项目。第二是能力错配。大模型强在理解力和生成力但在很多窄任务上比如关键词抽取、文本分类、格式转换小模型的准确率和响应速度往往反而更好。举一个实际观察到的现象用一个专门微调过的字节级小模型做敏感词过滤准确率能到99%以上而且延迟极低换用大模型反而会漏检因为大模型更关注语义而不是精确匹配。所以Harness Engineering的核心思维是不要问哪个模型最强而要问哪个模型最适合哪一层。你需要的是组建一个团队而不是找一个全能的超人。3.3 一个完整的多模型编排案例合同审查系统这部分我用一个真实改造过的项目来讲编排层的设计逻辑。这个项目处理的是合同审查任务分为三个阶段每个阶段我都选了不同的模型和策略。阶段一OCR与文档结构化。输入是扫描版PDF我用的是工业级OCR工具把PDF转成带坐标信息的文本。这个阶段的目标是尽量完整、尽量保真地抽取原文不需要理解力只需要识别率。我的经验是这一步尽量选专精OCR的模型不要用通用大模型做看图识字细节错误率会高出不少。阶段二风险条款抽取与分类。这是核心环节我用了一个中等规格的模型temperature设为0.1搭配一个强结构化的提示词。提示词里明确要求输出JSON数组每个元素包含条款编号、风险类型、风险描述。为了保证输出能稳定解析我在解析层做了容错如果JSON解析失败自动重新调用一次模型但这次让模型只输出修正后的JSON上下文里带上上次的错误信息。def extract_risks(text, client): prompt build_risk_extract_prompt(text) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.1, response_format{type: json_object}, ) result parse_json_safely(response.choices[0].message.content) if result is None: # 二次修正机制 fix_prompt ( f以下是上次提取的无效JSON请修正为合法JSON并补全缺失字段\n f{response.choices[0].message.content} ) ... return result阶段三风险评估与生成审查意见。这一步才轮到旗舰大模型上场。我把前两阶段抽取的风险点作为输入让旗舰模型基于这些结构化的风险点生成逻辑严谨的综合审查意见。这个设计的巧妙之处在于旗舰模型处理的不是原始合同全文而是已经经过抽取的高质量中间结果上下文长度大幅缩短且不会因为细节过多而迷失。整个编排流程用了一层简单的状态机控制初始化 → 抽取成功 → 转评估 → 输出报告任何一个环节失败都有对应的重试策略。这就是Harness Engineering在实战中的样子每个模型负责自己的强项层层递进而不是把所有任务压在一个模型上。4. AI Agent与AI工作流把编排思想推向动态化4.1 静态流水线 vs 动态Agent什么时候该升级上一节的合同审查系统属于静态流水线——流程固定、步骤清晰、每个环节做什么都是预先定义好的。静态流水线适合任务稳定、输入输出格式明确的场景。但真实业务里有大量任务的执行路径是不可预知的。举个例子你要做一个网页数据自动采集的Agent用户可能今天要采招聘信息明天要采商品价格后天要采论文摘要。你不可能为每个场景都预先设计一条流水线。这时候就需要Agent架构。Agent的核心特征是动态决策模型不再是按照固定脚本执行而是根据当前状态自主决定下一步动作。用大白话说静态流水线是套模板Agent是自己规划路径。我在生产环境判断是否升级到Agent架构主要看三个条件任务步骤是否经常变化如果业务方每个月都会提新的规则静态流程会疲于奔命是否存在分支深的场景比如如果A条件满足则走X路径否则先检查B再决定Y是否需要工具调用能力和外部信息交互纯文本生成的任务Agent架构反而增加系统复杂度。4.2 Agent的核心结构记忆、工具、计划三要素现在市面上关于Agent的文章很多但大多停留在概念层面。我从工程实现角度谈谈一个实用的Agent结构三个核心模块缺一不可记忆模块。分成短期记忆和长期记忆。短期记忆就是上下文窗口用来记住当前任务进行到哪一步、已经拿到了哪些结果长期记忆是外置的知识存储可以是向量数据库也可以是简单的JSON文件。我的经验是千万不要把长期记忆塞进上下文窗口成本爆炸且响应变慢。正确做法是每次需要时检索出与当前任务相关的片段注入上下文。工具模块。Agent需要手否则它只能空想。工具可以是搜索接口、数据库查询函数、文件读写API或者第三方服务。我这里想强调的是工具注册表和错误处理。工具注册表指Agent可以调用哪些工具、每个工具的输入输出schema是什么这个信息也需要注入到上下文里错误处理则是说工具调用失败时Agent要知道该怎么重试还是换一个方案。这一步是Agent工程化的分水岭。计划模块。这是Agent聪明与否的关键。最简单的实现方式是ReAct模式——Reasoning推理和Acting行动交替进行Agent先分析当前状态决定下一步动作执行动作后观察结果更新状态再做下一轮推理。你可以用循环实现def run_agent(initial_task, tools, max_steps10): state {task: initial_task, history: []} for step in range(max_steps): action plan_next_action(state, tools) if action[type] finish: return action[result] result execute_tool(action) state[history].append({action: action, result: result}) return {error: max_steps_reached, partial: state}这里有个很关键的工程细节Agent的循环必须有上限。我见过太多Agent项目因为没有步数限制模型在循环里反复调用工具直到把API预算耗尽。设一个max_steps比如10步到20步是绝对必要的。4.3 从文本对话到AI工作流工程化落地的一次案例复盘去年我做的最有意思的一个项目是一个竞品信息日报系统。需求很简单每天早上9点系统自动爬取竞品网站、新闻、社交媒体上的更新整理成一份结构化日报发给团队。如果只在ChatGPT里对话这个需求就是一个prompt的事帮我看看XX公司有什么新动态。但做工程的人都知道这个需求落到生产环境要面对的是网页结构会变、反爬策略会挡、信息源会出现假数据、不同语言的内容需要翻译、报告格式要稳定……我最终的架构是这样的采集层用定时任务触发爬虫抓取目标网站更新源码经过去噪处理存入中间库解析层调用一个中型模型做页面语义抽取把HTML转成结构化事件记录标题、时间、摘要、链接鉴权层用一个轻量模型做可信度筛查过滤明显是广告或无关的信息聚合层把多条事件按主题聚类调用旗舰模型生成日报正文分发层格式化并推送到团队群。整个流程是静态流水线和Agent思想的混合体。采集、鉴权用规则和轻模型解析和聚合用重模型。这个项目给了我一个非常重要的心得AI工程不是非黑即白的选择题不要陷入要么全自动Agent、要么全手工规则的二元思维。最好的方案往往是分层设计该用规则的地方用规则该上模型的地方上模型该让模型自主决策的地方才引入Agent。5. 工具链与实战环境搭建从零到一的具体过程5.1 我的选型清单模型、框架、向量库、观测工具聊完了方法论下面分享一套我实际在用的工具链。需要先说明的是这组选型基于我个人的技术栈和项目需求不代表全行业最优解但可以作为一份踏实的参考。模型侧API调用上主力使用GPT-4o和GPT-4o-mini的组合旗舰模型负责生成、中等模型负责抽取部分窄任务用开源模型本地部署。选择标准很简单每个任务单元只选当前性价比最高的模型不搞绑定。框架侧我用的是LangChain作为胶水层起家但现在其实很多复杂流程我自己写编排逻辑LangChain更像是一个工具库而不是全家桶。如果你是初学者我建议先用纯Python写一遍核心流程——只有自己写过一遍编排你才能理解LangChain帮你省了哪些事也才能知道它哪些地方设计得别扭。直接上手框架会出现黑盒依赖问题一旦框架更新或者API变化你连排查问题都不知道从哪下手。向量库我用过FAISS和Milvus最终在中小型项目上稳定用FAISS。原因是部署简单、够用、文档全。如果你的数据量超过千万级别再考虑上Milvus这类服务化向量库。观测工具这是最容易被忽略的模块。AI应用和传统应用的排查方式完全不同传统应用报错有明确的堆栈信息AI应用报错常常表现为输出质量下降或某次调用返回了意外格式。没有观测工具你根本不知道问题出在提示词还是模型参数还是上游数据。我现在每个项目都接一套简单的日志体系记录每个请求的prompt、model、temperature、tokens、finish_reason定期抽样审查。5.2 环境搭建中最容易踩的五个坑第一个坑是本地模型和API模型的prompt行为不一致。同样一段提示词GPT-4o上输出稳定换成本地模型就开始自由发挥了。原因在于不同模型对格式指令的遵循度差异很大一个看起来很严格的结构化提示词在弱模型眼里可能只是礼貌建议。解决方案是每个模型单独维护一套提示词变体不能一套提示词通吃所有模型。第二个坑是上下文管理混乱。当你使用RAG检索增强生成时常见的错误是把所有检索结果全部塞进上下文。我给一个参考阈值上下文里只保留与当前问题最相关的前5到10个文本块每个块控制在300字以内。超过这个量级模型的指令遵循度和生成质量都会明显下降。第三个坑是没有做评估集。我一度陷入感觉效果挺好但不敢上线的状态原因就是没有一套客观评估标准。后来我花了两个星期从历史数据中整理了100条典型输入给每条都写了期望输出建立了最小评估集。每次改prompt或换模型都先跑一遍评估集看准确率和召回率变化。这是从拍脑袋调参到数据驱动迭代的分水岭。第四个坑是重试逻辑写得过于简单。很多AI应用的架构里网络超时、限流、模型返回格式错误都会发生。只写重试3次远远不够要在重试时加入退避策略和上下文微调。比如格式错误重试时把上一次的错误信息一起喂给模型让它在错误基础上修正成功率会大幅提升。第五个坑是忽视输出可用性。模型输出的内容在进入业务系统前必须经过一层校验。特别是用户生成内容必须有安全和公共秩序层面的把关不能把模型的原始输出直接展示给用户或写入数据库。这层校验可以是规则过滤、关键词匹配或独立的小模型分类但绝对不能省。合规底线问题不是概率问题而是必须守住的红线。5.3 pycharm、codebuddy等工具在AI工程流程中的角色聊到工具很多人会问我是不是该用某个IDE的AI插件我的观点很明确IDE AI插件是效率放大器不是引擎。它们是辅助写代码的不是用来替代工程思维的。举一个实际例子我在PyCharm里配置了AI插件它最大的价值是写重复性代码和补全单元测试模板确实节约了不少时间。有一个项目里的数据清洗模块几十行几乎一模一样的字段处理代码我之前手工写费了半小时插件直接补全了80%我只需要微调一下字段名。这类工具欢迎多用没有什么可顾虑的。但我也提醒一句不要让它替你写核心架构代码。AI生成的代码在简单场景下看起来没问题一旦涉及并发控制、错误恢复、数据一致性这些深度工程问题它很难凭空给出可靠方案。这些场景需要的是工程师的判断而不是概率预测。我用AI插件有一条底线原则代码让我惊喜了那一定是出了问题。CodeBuddy这类工具我也实测过用于写脚本、做数据可视化、写文档片段效率都很高。它们的定位更像资深初级工程师助手适合独立小任务不适合独立负责高复杂度模块。真正让你跟别人拉开差距的仍然是你对系统设计的理解和掌控力。6. 从零开始做AI工程项目的完整路径6.1 第一步明确问题边界与评估指标我不止一次看到有人上来就想做一个AI产品但问到他你要解决什么问题、用户是谁、成功标准是什么时他支支吾吾答不上来。这种情况下做出来的东西最后大概率是一个技术demo而不是工程产品。工程项目的起点永远是问题定义。这里说的不是我要用AI做什么而是现状有什么痛点、这个痛点值多少钱、AI介入后如何度量改善。度量指标可以是准确率、转化率、处理时效、成本下降百分比。有一个清晰指标的好处是后续所有技术决策都有了判断标准。举个例子我做客服问答机器人时定的核心指标是首次解决率。所有优化动作——调整检索策略、改写提示词、引入多轮记忆——都围绕这个指标做A/B测试效果立竿见影不用凭感觉争论方案优劣。6.2 第二步小步快跑一个最小的端到端Demo定义好问题后我强烈建议你先做一个最小可行闭环先求完整再求完善。比如你想做一个文档问答系统不要一上来就部署向量数据库、搭Agent框架、接各种工具。先把最简单的事情跑通文档→切片→调模型API→生成答案→展示在网页上。哪怕这个版本只有一个输入框和一个输出框哪怕检索就是全文档拼进上下文都没关系。关键是帮你把整条链路走通验证这一整套方案本质上可行。我见过最典型的失败模式是过度设计前期架构结果发现核心假设根本不成立。举个例子三个人花了四周做了一个基于RAG的客服系统结果上线后发现用户的问题里有30%是文档里根本没有的内容整个RAG链路根本答不上来架构再完善也救不了核心需求的错位。而如果先做一个模型直接答文档拼接的低配demo一周就能验证出文档外问题占比过高这个致命风险。这一步的产出物不是优秀代码而是关键假设的验证结果模型的输出质量能否达到业务底线延迟和成本是否在可接受范围用户是否愿意为这个结果买单6.3 第三步让系统变稳——提示词版本管理、输出校验、异常兜底Demo跑通之后接下来是工程化的第二阶段让系统从偶尔好用变成一直好用。这一步要解决三个问题稳定、可控、可回溯。稳定。通过提示词版本管理前文提过的version字段、结合输出结构的校验和重试机制解析失败自动修正、以及合适的temperature设置把模型输出的不确定性压到可接受范围。我不追求100%准确那是反人性的。我追求的是错误可预期、可拦截、可弥补。可控。对任何模型输出都要有一道校验关卡。比如格式校验、范围校验、合规校验不合格的输出宁可丢弃也不可用。这一步在AI工程里叫安全护栏。它可能需要用规则引擎拦截一些常识性问题也可能需要用小模型做一轮独立审查。核心原则是模型的输出不能没有质检就直达用户。可回溯。每个请求的完整日志输入、输出、耗时、token数、模型版本、prompt版本都要记录。这是AI应用和传统应用最大的区别传统应用你靠堆栈信息排查问题AI应用你靠日志里的上下文排查问题。没有完整日志出问题就是两眼一抹黑。6.4 第四步渐进式引入Agent、知识库与多模型编排系统稳定之后你就会自然触到天花板任务类型变多了、用户问题变复杂了、单模型的上下文窗口不够用了。这时候才适合引入更高级的架构知识库RAG解决模型没见过的问题Agent架构解决任务路径不确定的问题多模型编排解决单模型能力不均衡的问题。这一阶段的准则我从实践中总结为四个字增量演进。不要推翻重来而是在现有稳定系统上逐步叠加能力。先接一个向量库做检索增强看看指标变化再引入一个调度层把简单任务和复杂任务分流给不同模型最后再考虑Agent化。每一步都要回到第一阶段定义的指标上去验证——这个改动到底是变好了还是变差了。6.5 从个人项目沉淀为团队工作流的经验最后聊一个组织层面的问题如何把个人验证过的流程复制给团队。我踩过最大的坑是把个人经验直接变成文档发给团队结果基本没人看。后来学到的做法是把流程变成工具。我自己封装了一套内部工具把prompt模板管理、评估集运行、日志查看、模型对比都集成到一个简化的Web界面里团队成员不需要理解底层原理只需要在界面上传测试集、跑评估、看结果。工具本身成了知识的载体。具体的落地路径是先做一个可复用的代码库把常用模块检索、抽取、生成、校验封装成标准函数写一份部署文档保证任何人都能本地跑起来每两周迭代一次评估集把线上出现的新问题类型补进去让团队里每个人都能跑评估、看对比、提改进建议。这个过程最花时间的不是写代码而是对齐标准和建立反馈循环。把AI工程做进团队流程难度不在于技术深度而在于让整套系统有共同语言——统一的评估指标、统一的prompt管理方式、统一的日志规范。有了这三样团队协作才会顺畅。最后分享一个我的习惯这一路走过来如果要我从所有经验里挑一条最值得分享的我会说是**永远维护一份错误日志**。我有一份独立的笔记文档专门记录每次项目里出现的诡异问题某次模型返回了非法JSON、某次重试导致重复扣费、某次热词更新影响了检索相关性、某次上下文过长导致响应延迟翻倍……每条记录都包含问题描述、根因分析、解决方案、以及如果再遇到第一时间检查什么。这份日志的价值随着时间的推移越来越大。很多新项目遇到的问题我翻一下日志就有答案不用重新踩一遍坑。我强烈建议每个做AI工程的人都建立这样一份自己的日志。技术会迭代模型会被替代框架会更新但踩坑的规律和对系统的直觉是最不容易被淘汰的资产。希望这篇文章能让你在这条路上少走一些弯路多一些从容。 从零开始AI工程：提示词、多模型编排与Agent实战指南
1. 先泼一盆冷水AI工程从来不是会写提示词我见过太多人把AI工程理解成用AI写段话或者调一个API返回结果。真正上手做过项目的人会明白这两者之间的距离大概相当于会点火和会造发动机之间的距离。举个最直观的例子同样是用大模型处理一份合同初学者写一句帮我总结这份合同的风险点得到的是一段泛泛而谈的概括而有工程思维的人会设计一套流程——先拆页、分段清洗、定义风险类型枚举、让模型逐段标注、再把结果聚合、最后用规则引擎复核关键条款。同样的模型同样的知识库后者的输出质量、稳定性和可追溯性完全碾压前者。ai-engineering-from-scratch这个标题翻译过来就是从零开始搞AI工程。它不是一个名词而是一条路线图。我在这条路上走了将近两年从第一个简单脚本到现在能支撑并发调用的完整系统中间踩过的坑、推翻过的设计、重写过的代码都比想象中多得多。这篇文章我把整条路径拆开来讲提示词工程、Harness Engineering编排层、AI Agent、工具链搭建、以及落地过程中的实战经验每个环节都会讲清楚为什么这么做和实际做的时候会撞上什么墙。适合读这篇文章的人有三类一是刚接触AI开发、想建立系统认知的初学者二是已经能用API但总觉得不够稳、不够好用的开发者三是想在企业内部推动AI落地的技术负责人。这篇文章不教你怎么问问题而是教你怎么把问问题这件事本身变成一个可靠、可复用、可规模化的系统。2. 提示词工程Prompt Engineering所有AI工程的底层地基2.1 为什么说提示词是接口设计而不是说话技巧很多人对提示词工程有一个误解觉得它是怎么把话术写得更优美这就大错特错了。提示词工程更准确的类比是接口设计——你在定义一个稳定的输入输出契约。我举个具体例子。早期我做合同风险提醒项目时最开始用的提示词是帮我看看这个合同有没有问题模型给的结果时好时坏有时候能列出风险点有时候给出的是合同背景介绍。后来我把提示词重构成这样你是一名法务专家负责合同风险审查。请按以下格式输出结果 - 风险级别高/中/低/无 - 风险条款编号精确到条款号 - 风险描述不超过50字 - 修改建议不超过100字 合同文本如下以START和END标记边界 START [合同内容] END 若未发现风险输出无风险不要附加任何其他内容。效果立竿见影。原因不在于我会说话而在于我给模型定义了清晰的输出协议建立了角色约束和边界标记。从工程视角看每一次提示词设计本质上是在定义函数签名。你在构思提示词时应该像设计API一样思考输入是什么格式输出是什么结构边界条件如何处理异常情况怎么兜底我还建议给每个提示词起版本号。别笑这不是形式主义。我见过太多团队prompt改了一版又一版效果回退时根本不知道是哪次改动造成的。我自己的项目里每一个prompt模板都带一个version字段模板内容改动时必须同步更新版本号配合后端的prompt管理表一起使用。这条习惯后来帮我省了无数次排查时间。2.2 结构化提示词的三层结构角色层、任务层、输出层复杂的生产级提示词通常需要三层结构缺一层都会出问题。我这套方法是从Anthropic的工程实践中演化出来的经过了许多实际项目的检验整理如下第一层角色层。给模型一个明确的行为基准。注意不是简单说你是专家而是要说清楚你的知识边界、你的工作原则、你的输出风格。比如你是一名资深数据工程师熟悉SQL性能优化。你的原则是 1. 永远先分析查询计划再给出改写建议 2. 对于超过500万行的表强制考虑索引策略 3. 输出建议时必须附带理论依据不能只给结论。这一层的作用是让模型进入专业模式减少常识性错误。很多人忽略了一个细节角色设定里应该包含否定约束也就是明确告诉模型不要做什么。比如上面第三条就是典型的否定约束。第二层任务层。描述你要做什么但不要急着写怎么做。这里的关键是把目标拆解成模型可以逐步执行的子任务序列也就是用思维链的方式引导。举例来说与其说帮我优化这段SQL不如说请按以下步骤处理这段SQL 第一步解读该SQL的业务含义判断涉及哪些表、哪些字段 第二步分析当前执行计划中可能的性能瓶颈全表扫描、隐式转换、笛卡尔积等 第三步针对每个瓶颈给出具体的优化方案 第四步输出改写后的SQL并解释为什么这样写更高效。第三层输出层。这一层很多初学者完全忽略。输出层的作用是让模型的结果可程序化解析。生产环境里你不可能每次都用肉眼去看模型返回的自然语言你需要的是稳定结构。前文合同审查的例子已经是输出层的最佳实践这里补充一个技巧给出正例和反例。比如输出格式要求 - 每条建议占一行用|分割字段 - 正确示范高|第3.2条|违约金比例过高超过法定上限|建议调整至每日万分之五 - 错误示范该条款存在法律风险不要这样写缺少结构正例反例的对比比一百句请严格按照格式输出都管用。2.3 温度、Top-p和max_tokens一批真正影响输出的参数说完了提示词本身再聊一个很多人没搞明白的东西采样参数。它们在工程意义上的重要性不亚于提示词本身。我在生产环境里的经验值如下这是基于我个人项目的实践总结不同场景需要微调参数取值适用场景备注temperature0~0.3分类、抽取、结构化输出越低越稳定建议从0.2起步temperature0.5~0.7生成式写作、发散式思考高于0.7容易胡说八道top_p0.8~0.9配合temperature使用二选一调整即可不必同时精细调max_tokens按需估算控制成本与延迟别不舍得给截断比冗长更糟糕stop自定义结束标记控制对结构化输出很有用有一个反直觉的坑很多人以为temperature调低模型就会变聪明实际上它只是变得保守倾向于反复输出训练集中最常见的答案。在分类任务里比如判断一段文本的情感极性temperature0往往效果最好因为你要的是稳定正确但在生成创意文案时temperature0.3会让所有结果都长得一模一样完全没有多样性。另一个常见问题是max_tokens设得太小。模型在生成过程中如果你设置了截断上限API不会告诉你输出被截断了你拿到的是一段戛然而止的文本。我曾经在一个日志分析项目上被这个坑惨了模型分析日志时输出被截断我拿后半段去解析JSON每次都在同一个地方报错花了半天才意识到是截断问题。现在我的代码里固定有一个is_truncated检查逻辑response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], max_tokens2000, temperature0.2, ) content response.choices[0].message.content finish_reason response.choices[0].finish_reason if finish_reason length: logger.warning(输出被截断考虑增大 max_tokens 或拆分输入)3. Harness Engineering真正拉开差距的编排层3.1 什么是Harness Engineering从单匹马拉车到多马协动这是最近一年AI工程领域讨论度直线上升的概念但我发现很多人对它有误解。Harness Engineering直译是挽具工程从马车时代的挽具harness借来的词——它解决的原始问题是一匹马的力量不够如何把多匹马套在一起让它们合力拉动一辆车。在AI工程里这个思想有非常具体的映射单一模型的能力不够如何把多个模型同构或异构编排起来组成一个更强的系统。它不同于简单的多Agent聊天而是一种系统级的架构设计。我最初接触这个概念是因为一个真实需求公司的客服系统要同时处理用户问题分类、情感识别、知识库检索和答案生成四个子任务。最开始我的做法是一个大模型一把梭——把四个任务全塞进一个prompt结果发现四个任务互相干扰。分类任务要求低温度、保守生成任务要求较高温度、有创造性。同一个模型、同一个temperature根本没法同时满足两端需求。这就是拆出来的问题。最后我设计了四个独立模型调用然后用一层编排逻辑把它们串联起来形成一个流水线。后来我才知道这就是Harness Engineering的雏形利用多个异构模型的差异化能力通过编排逻辑组合出单个模型无法胜任的系统。3.2 为什么你需要多个模型而不是一个大而全的模型再往深里说一步。行业内有个流行的迷思GPT-4级别的大模型什么都能干我只需要调一个就好。说真的这个说法在小规模demo阶段完全成立但在生产规模下有两个致命问题第一是成本失控。一个复杂的分析任务如果每次请求都携带大量上下文token消耗是指数级攀升的。我算过一笔账我维护的一个内部文档问答机器人如果把OCR、摘要、检索、生成全部用同一个旗舰模型单次问答成本大概是2元人民币拆成OCR用小模型、摘要用中模型、生成用旗舰模型之后单次成本降到了0.4元效果几乎无差别。省下来的钱够我再开两个实验项目。第二是能力错配。大模型强在理解力和生成力但在很多窄任务上比如关键词抽取、文本分类、格式转换小模型的准确率和响应速度往往反而更好。举一个实际观察到的现象用一个专门微调过的字节级小模型做敏感词过滤准确率能到99%以上而且延迟极低换用大模型反而会漏检因为大模型更关注语义而不是精确匹配。所以Harness Engineering的核心思维是不要问哪个模型最强而要问哪个模型最适合哪一层。你需要的是组建一个团队而不是找一个全能的超人。3.3 一个完整的多模型编排案例合同审查系统这部分我用一个真实改造过的项目来讲编排层的设计逻辑。这个项目处理的是合同审查任务分为三个阶段每个阶段我都选了不同的模型和策略。阶段一OCR与文档结构化。输入是扫描版PDF我用的是工业级OCR工具把PDF转成带坐标信息的文本。这个阶段的目标是尽量完整、尽量保真地抽取原文不需要理解力只需要识别率。我的经验是这一步尽量选专精OCR的模型不要用通用大模型做看图识字细节错误率会高出不少。阶段二风险条款抽取与分类。这是核心环节我用了一个中等规格的模型temperature设为0.1搭配一个强结构化的提示词。提示词里明确要求输出JSON数组每个元素包含条款编号、风险类型、风险描述。为了保证输出能稳定解析我在解析层做了容错如果JSON解析失败自动重新调用一次模型但这次让模型只输出修正后的JSON上下文里带上上次的错误信息。def extract_risks(text, client): prompt build_risk_extract_prompt(text) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.1, response_format{type: json_object}, ) result parse_json_safely(response.choices[0].message.content) if result is None: # 二次修正机制 fix_prompt ( f以下是上次提取的无效JSON请修正为合法JSON并补全缺失字段\n f{response.choices[0].message.content} ) ... return result阶段三风险评估与生成审查意见。这一步才轮到旗舰大模型上场。我把前两阶段抽取的风险点作为输入让旗舰模型基于这些结构化的风险点生成逻辑严谨的综合审查意见。这个设计的巧妙之处在于旗舰模型处理的不是原始合同全文而是已经经过抽取的高质量中间结果上下文长度大幅缩短且不会因为细节过多而迷失。整个编排流程用了一层简单的状态机控制初始化 → 抽取成功 → 转评估 → 输出报告任何一个环节失败都有对应的重试策略。这就是Harness Engineering在实战中的样子每个模型负责自己的强项层层递进而不是把所有任务压在一个模型上。4. AI Agent与AI工作流把编排思想推向动态化4.1 静态流水线 vs 动态Agent什么时候该升级上一节的合同审查系统属于静态流水线——流程固定、步骤清晰、每个环节做什么都是预先定义好的。静态流水线适合任务稳定、输入输出格式明确的场景。但真实业务里有大量任务的执行路径是不可预知的。举个例子你要做一个网页数据自动采集的Agent用户可能今天要采招聘信息明天要采商品价格后天要采论文摘要。你不可能为每个场景都预先设计一条流水线。这时候就需要Agent架构。Agent的核心特征是动态决策模型不再是按照固定脚本执行而是根据当前状态自主决定下一步动作。用大白话说静态流水线是套模板Agent是自己规划路径。我在生产环境判断是否升级到Agent架构主要看三个条件任务步骤是否经常变化如果业务方每个月都会提新的规则静态流程会疲于奔命是否存在分支深的场景比如如果A条件满足则走X路径否则先检查B再决定Y是否需要工具调用能力和外部信息交互纯文本生成的任务Agent架构反而增加系统复杂度。4.2 Agent的核心结构记忆、工具、计划三要素现在市面上关于Agent的文章很多但大多停留在概念层面。我从工程实现角度谈谈一个实用的Agent结构三个核心模块缺一不可记忆模块。分成短期记忆和长期记忆。短期记忆就是上下文窗口用来记住当前任务进行到哪一步、已经拿到了哪些结果长期记忆是外置的知识存储可以是向量数据库也可以是简单的JSON文件。我的经验是千万不要把长期记忆塞进上下文窗口成本爆炸且响应变慢。正确做法是每次需要时检索出与当前任务相关的片段注入上下文。工具模块。Agent需要手否则它只能空想。工具可以是搜索接口、数据库查询函数、文件读写API或者第三方服务。我这里想强调的是工具注册表和错误处理。工具注册表指Agent可以调用哪些工具、每个工具的输入输出schema是什么这个信息也需要注入到上下文里错误处理则是说工具调用失败时Agent要知道该怎么重试还是换一个方案。这一步是Agent工程化的分水岭。计划模块。这是Agent聪明与否的关键。最简单的实现方式是ReAct模式——Reasoning推理和Acting行动交替进行Agent先分析当前状态决定下一步动作执行动作后观察结果更新状态再做下一轮推理。你可以用循环实现def run_agent(initial_task, tools, max_steps10): state {task: initial_task, history: []} for step in range(max_steps): action plan_next_action(state, tools) if action[type] finish: return action[result] result execute_tool(action) state[history].append({action: action, result: result}) return {error: max_steps_reached, partial: state}这里有个很关键的工程细节Agent的循环必须有上限。我见过太多Agent项目因为没有步数限制模型在循环里反复调用工具直到把API预算耗尽。设一个max_steps比如10步到20步是绝对必要的。4.3 从文本对话到AI工作流工程化落地的一次案例复盘去年我做的最有意思的一个项目是一个竞品信息日报系统。需求很简单每天早上9点系统自动爬取竞品网站、新闻、社交媒体上的更新整理成一份结构化日报发给团队。如果只在ChatGPT里对话这个需求就是一个prompt的事帮我看看XX公司有什么新动态。但做工程的人都知道这个需求落到生产环境要面对的是网页结构会变、反爬策略会挡、信息源会出现假数据、不同语言的内容需要翻译、报告格式要稳定……我最终的架构是这样的采集层用定时任务触发爬虫抓取目标网站更新源码经过去噪处理存入中间库解析层调用一个中型模型做页面语义抽取把HTML转成结构化事件记录标题、时间、摘要、链接鉴权层用一个轻量模型做可信度筛查过滤明显是广告或无关的信息聚合层把多条事件按主题聚类调用旗舰模型生成日报正文分发层格式化并推送到团队群。整个流程是静态流水线和Agent思想的混合体。采集、鉴权用规则和轻模型解析和聚合用重模型。这个项目给了我一个非常重要的心得AI工程不是非黑即白的选择题不要陷入要么全自动Agent、要么全手工规则的二元思维。最好的方案往往是分层设计该用规则的地方用规则该上模型的地方上模型该让模型自主决策的地方才引入Agent。5. 工具链与实战环境搭建从零到一的具体过程5.1 我的选型清单模型、框架、向量库、观测工具聊完了方法论下面分享一套我实际在用的工具链。需要先说明的是这组选型基于我个人的技术栈和项目需求不代表全行业最优解但可以作为一份踏实的参考。模型侧API调用上主力使用GPT-4o和GPT-4o-mini的组合旗舰模型负责生成、中等模型负责抽取部分窄任务用开源模型本地部署。选择标准很简单每个任务单元只选当前性价比最高的模型不搞绑定。框架侧我用的是LangChain作为胶水层起家但现在其实很多复杂流程我自己写编排逻辑LangChain更像是一个工具库而不是全家桶。如果你是初学者我建议先用纯Python写一遍核心流程——只有自己写过一遍编排你才能理解LangChain帮你省了哪些事也才能知道它哪些地方设计得别扭。直接上手框架会出现黑盒依赖问题一旦框架更新或者API变化你连排查问题都不知道从哪下手。向量库我用过FAISS和Milvus最终在中小型项目上稳定用FAISS。原因是部署简单、够用、文档全。如果你的数据量超过千万级别再考虑上Milvus这类服务化向量库。观测工具这是最容易被忽略的模块。AI应用和传统应用的排查方式完全不同传统应用报错有明确的堆栈信息AI应用报错常常表现为输出质量下降或某次调用返回了意外格式。没有观测工具你根本不知道问题出在提示词还是模型参数还是上游数据。我现在每个项目都接一套简单的日志体系记录每个请求的prompt、model、temperature、tokens、finish_reason定期抽样审查。5.2 环境搭建中最容易踩的五个坑第一个坑是本地模型和API模型的prompt行为不一致。同样一段提示词GPT-4o上输出稳定换成本地模型就开始自由发挥了。原因在于不同模型对格式指令的遵循度差异很大一个看起来很严格的结构化提示词在弱模型眼里可能只是礼貌建议。解决方案是每个模型单独维护一套提示词变体不能一套提示词通吃所有模型。第二个坑是上下文管理混乱。当你使用RAG检索增强生成时常见的错误是把所有检索结果全部塞进上下文。我给一个参考阈值上下文里只保留与当前问题最相关的前5到10个文本块每个块控制在300字以内。超过这个量级模型的指令遵循度和生成质量都会明显下降。第三个坑是没有做评估集。我一度陷入感觉效果挺好但不敢上线的状态原因就是没有一套客观评估标准。后来我花了两个星期从历史数据中整理了100条典型输入给每条都写了期望输出建立了最小评估集。每次改prompt或换模型都先跑一遍评估集看准确率和召回率变化。这是从拍脑袋调参到数据驱动迭代的分水岭。第四个坑是重试逻辑写得过于简单。很多AI应用的架构里网络超时、限流、模型返回格式错误都会发生。只写重试3次远远不够要在重试时加入退避策略和上下文微调。比如格式错误重试时把上一次的错误信息一起喂给模型让它在错误基础上修正成功率会大幅提升。第五个坑是忽视输出可用性。模型输出的内容在进入业务系统前必须经过一层校验。特别是用户生成内容必须有安全和公共秩序层面的把关不能把模型的原始输出直接展示给用户或写入数据库。这层校验可以是规则过滤、关键词匹配或独立的小模型分类但绝对不能省。合规底线问题不是概率问题而是必须守住的红线。5.3 pycharm、codebuddy等工具在AI工程流程中的角色聊到工具很多人会问我是不是该用某个IDE的AI插件我的观点很明确IDE AI插件是效率放大器不是引擎。它们是辅助写代码的不是用来替代工程思维的。举一个实际例子我在PyCharm里配置了AI插件它最大的价值是写重复性代码和补全单元测试模板确实节约了不少时间。有一个项目里的数据清洗模块几十行几乎一模一样的字段处理代码我之前手工写费了半小时插件直接补全了80%我只需要微调一下字段名。这类工具欢迎多用没有什么可顾虑的。但我也提醒一句不要让它替你写核心架构代码。AI生成的代码在简单场景下看起来没问题一旦涉及并发控制、错误恢复、数据一致性这些深度工程问题它很难凭空给出可靠方案。这些场景需要的是工程师的判断而不是概率预测。我用AI插件有一条底线原则代码让我惊喜了那一定是出了问题。CodeBuddy这类工具我也实测过用于写脚本、做数据可视化、写文档片段效率都很高。它们的定位更像资深初级工程师助手适合独立小任务不适合独立负责高复杂度模块。真正让你跟别人拉开差距的仍然是你对系统设计的理解和掌控力。6. 从零开始做AI工程项目的完整路径6.1 第一步明确问题边界与评估指标我不止一次看到有人上来就想做一个AI产品但问到他你要解决什么问题、用户是谁、成功标准是什么时他支支吾吾答不上来。这种情况下做出来的东西最后大概率是一个技术demo而不是工程产品。工程项目的起点永远是问题定义。这里说的不是我要用AI做什么而是现状有什么痛点、这个痛点值多少钱、AI介入后如何度量改善。度量指标可以是准确率、转化率、处理时效、成本下降百分比。有一个清晰指标的好处是后续所有技术决策都有了判断标准。举个例子我做客服问答机器人时定的核心指标是首次解决率。所有优化动作——调整检索策略、改写提示词、引入多轮记忆——都围绕这个指标做A/B测试效果立竿见影不用凭感觉争论方案优劣。6.2 第二步小步快跑一个最小的端到端Demo定义好问题后我强烈建议你先做一个最小可行闭环先求完整再求完善。比如你想做一个文档问答系统不要一上来就部署向量数据库、搭Agent框架、接各种工具。先把最简单的事情跑通文档→切片→调模型API→生成答案→展示在网页上。哪怕这个版本只有一个输入框和一个输出框哪怕检索就是全文档拼进上下文都没关系。关键是帮你把整条链路走通验证这一整套方案本质上可行。我见过最典型的失败模式是过度设计前期架构结果发现核心假设根本不成立。举个例子三个人花了四周做了一个基于RAG的客服系统结果上线后发现用户的问题里有30%是文档里根本没有的内容整个RAG链路根本答不上来架构再完善也救不了核心需求的错位。而如果先做一个模型直接答文档拼接的低配demo一周就能验证出文档外问题占比过高这个致命风险。这一步的产出物不是优秀代码而是关键假设的验证结果模型的输出质量能否达到业务底线延迟和成本是否在可接受范围用户是否愿意为这个结果买单6.3 第三步让系统变稳——提示词版本管理、输出校验、异常兜底Demo跑通之后接下来是工程化的第二阶段让系统从偶尔好用变成一直好用。这一步要解决三个问题稳定、可控、可回溯。稳定。通过提示词版本管理前文提过的version字段、结合输出结构的校验和重试机制解析失败自动修正、以及合适的temperature设置把模型输出的不确定性压到可接受范围。我不追求100%准确那是反人性的。我追求的是错误可预期、可拦截、可弥补。可控。对任何模型输出都要有一道校验关卡。比如格式校验、范围校验、合规校验不合格的输出宁可丢弃也不可用。这一步在AI工程里叫安全护栏。它可能需要用规则引擎拦截一些常识性问题也可能需要用小模型做一轮独立审查。核心原则是模型的输出不能没有质检就直达用户。可回溯。每个请求的完整日志输入、输出、耗时、token数、模型版本、prompt版本都要记录。这是AI应用和传统应用最大的区别传统应用你靠堆栈信息排查问题AI应用你靠日志里的上下文排查问题。没有完整日志出问题就是两眼一抹黑。6.4 第四步渐进式引入Agent、知识库与多模型编排系统稳定之后你就会自然触到天花板任务类型变多了、用户问题变复杂了、单模型的上下文窗口不够用了。这时候才适合引入更高级的架构知识库RAG解决模型没见过的问题Agent架构解决任务路径不确定的问题多模型编排解决单模型能力不均衡的问题。这一阶段的准则我从实践中总结为四个字增量演进。不要推翻重来而是在现有稳定系统上逐步叠加能力。先接一个向量库做检索增强看看指标变化再引入一个调度层把简单任务和复杂任务分流给不同模型最后再考虑Agent化。每一步都要回到第一阶段定义的指标上去验证——这个改动到底是变好了还是变差了。6.5 从个人项目沉淀为团队工作流的经验最后聊一个组织层面的问题如何把个人验证过的流程复制给团队。我踩过最大的坑是把个人经验直接变成文档发给团队结果基本没人看。后来学到的做法是把流程变成工具。我自己封装了一套内部工具把prompt模板管理、评估集运行、日志查看、模型对比都集成到一个简化的Web界面里团队成员不需要理解底层原理只需要在界面上传测试集、跑评估、看结果。工具本身成了知识的载体。具体的落地路径是先做一个可复用的代码库把常用模块检索、抽取、生成、校验封装成标准函数写一份部署文档保证任何人都能本地跑起来每两周迭代一次评估集把线上出现的新问题类型补进去让团队里每个人都能跑评估、看对比、提改进建议。这个过程最花时间的不是写代码而是对齐标准和建立反馈循环。把AI工程做进团队流程难度不在于技术深度而在于让整套系统有共同语言——统一的评估指标、统一的prompt管理方式、统一的日志规范。有了这三样团队协作才会顺畅。最后分享一个我的习惯这一路走过来如果要我从所有经验里挑一条最值得分享的我会说是**永远维护一份错误日志**。我有一份独立的笔记文档专门记录每次项目里出现的诡异问题某次模型返回了非法JSON、某次重试导致重复扣费、某次热词更新影响了检索相关性、某次上下文过长导致响应延迟翻倍……每条记录都包含问题描述、根因分析、解决方案、以及如果再遇到第一时间检查什么。这份日志的价值随着时间的推移越来越大。很多新项目遇到的问题我翻一下日志就有答案不用重新踩一遍坑。我强烈建议每个做AI工程的人都建立这样一份自己的日志。技术会迭代模型会被替代框架会更新但踩坑的规律和对系统的直觉是最不容易被淘汰的资产。希望这篇文章能让你在这条路上少走一些弯路多一些从容。