两年前我接手第一个AI项目时，最大的困惑不是模型效果不好，而是根本不知道从哪一步开始。找开源代码、跑通Demo、调API、拼提示词，这些动作单独拿出来我都会，但距离"工程化交付"还差着十万八千里。项目一多，问题就暴露了：模型输出不稳定怎么兜底？评测指标怎么定？提示词改了之后如何确认没把别的场景搞坏？Agent调工具失败怎么重试？这些问题没有一个能靠"再调调参"解决，它们属于同一门学科——AI工程（AI Engineering）。
这篇文章想把我从零构建AI工程能力的过程完整拆开讲一遍：先厘清AI工程到底是个什么东西，再讲哪些基础知识必须打牢、哪些可以边做边补，然后给出我实际跑通一个项目的完整链路，最后花大篇幅聊提示词工程、Agent/Harness工程、以及最容易被忽视的测试与监控。内容偏实战，适合两类人：一是刚转行AI方向的开发者，手里有编程基础但不知道系统学什么；二是已经在用大模型API做功能、但总觉得"差点意思"的工程师。读完你应该能对自己缺什么、下一步补什么有一个清晰的判断。
1. 从"会调API"到"会做AI工程"：我理解的本质转变
1.1 为什么这个话题值得单独写一篇
"从零开始学AI工程"这句话听起来很宏大，但落到日常就是一连串具体的抉择：学深度学习框架还是先学推理框架？transformer原理要掌握到什么程度？RAG、Agent、Fine-tuning到底先学哪个？市面上90%的教程都在教"用一个框架跑通一个功能"，但AI工程的核心恰恰不在"跑通"，而在"稳定地跑、可衡量地跑、可维护地跑"。
我见过太多开发者（包括我自己早期）陷入一个误区：把模型效果当成了全部。模型答得好就欢呼，答不好就换更贵的模型。但真实业务里，模型只是系统中的一个组件，和它打交道的还有输入校验、上下文组装、结果解析、缓存、降级、日志、用户反馈回收。这些组件的工程质量，往往决定了AI功能的生死。
"AI engineering from scratch"这个主题真正的价值，就是让我们把视角从"模型"切换到"系统"。这个转变，是我认为AI工程师和"会调用AI的软件工程师"之间的本质分界线。
1.2 AI工程与传统软件工程、机器学习研究的边界
要搞清楚AI工程是什么，最好的方式是把它和两个相邻领域做对比。
传统软件工程（Software Engineering）处理的是确定性逻辑：输入A永远得到输出B，bug可以复现，测试可以穷举。AI工程面对的是概率性系统：同样的输入，模型可能给出三种都合理的回答，错误难以稳定复现，测试只能用覆盖率而不是穷举法。这意味着工程实践的底层逻辑"质量保障"必须换一套打法。
机器学习研究（ML Research）关注的是"模型还能不能更强"，以论文、基准测试、实验为核心产出。AI工程关注的则是"这个模型能力放进业务里能不能持续产生价值"，以服务稳定性、用户满意度、成本、迭代效率为核心指标。研究者可以接受模型输错十次然后改进一次，工程上输错十次用户早就走了。
AI工程的位置，恰好是这两者的交集：要用工程手段约束概率性输出，同时要用模型能力解决传统规则写不清的问题。这也解释了为什么它难学——因为它要求一个人同时具备软件工程师的严谨和数据分析师的实证思维。
1.3 "从零开始"的真实起点
很多人以为"从零开始"意味着从数学、从tensorflow手写反向传播开始。我个人的结论是：不需要，也不建议。
我在项目中实际用到的知识，按频率排个序的话大概是：Python数据处理与工程化（每天）＞ 大模型推理与调用的机制理解（每周）＞ 提示词工程/结构化输出（每天）＞ 基础评估与数据分析（每周）＞ 机器学习训练原理（偶尔）＞ 数学推导（几乎不涉及）。
所以真实的起点是：能熟练处理数据和写工程代码，然后把大模型当成一个"概率性的外部组件"去构建系统。底层数学可以后续按需补，而不是前置拦路虎。这一点想清楚，学习路径会轻松一半。
2. 知识底座：哪些基础必须打牢，哪些可以边做边补
2.1 编程与数据基础：最省时间的补法
如果现在让我给一个"从零学习者"划红线，我会说：Python语言、JSON处理、SQL、基础Linux命令，这四样必须熟练掌握到不用想的地步。因为AI工程日常工作就是三件事：准备数据、调用模型、处理结果。这三件事全都建立在上述四样基础之上。
数据操作的熟练度尤其重要。我在实践中总结过一个比例：一个AI项目里，真正写模型调用代码的时间大概占20%，剩下80%的时间全在清洗数据、拼接上下文、解析输出、修格式错误。如果你对Pandas、json库、正则表达式不熟，那这80%的时间会变成灾难。
这里给一个自测标准：给你一个包含用户对话记录的JSON文件，要求你把每轮对话组装成一个"系统提示词＋用户消息＋历史上下文"的新请求格式，并处理掉其中的空字段和超长文本，你能不能在半小时内写出干净可运行的代码？这个能力比背下来transformer的公式有用得多。
2.2 语言模型原理：从词向量到注意力机制
很多人问我要不要读《从零构建大语言模型》这类书，我的回答是：读，但要有策略地读。你不需要理解每一个矩阵运算的推导，但必须建立四个核心心智模型：
第一，Token与上下文窗口。语言模型不是按"词"处理文本，而是按"子词"（Token）切分。上下文窗口就是模型一次能"看到"的Token上限。这直接决定了你的工程策略：超长文档怎么截断、历史对话怎么压缩、RAG怎么决定检索多少片段。不理解Token，你就不可能做好上下文工程。
第二，Embedding（嵌入）与语义检索。模型会把Token映射到高维向量空间，语义相近的内容向量距离近。RAG（检索增强生成）、语义搜索、聚类去重全都建立在这个原理上。理解了这一点，你就知道为什么"关键词匹配"和"向量检索"是不同维度的东西，什么时候该用哪个。
第三，注意力机制与信息"稀释"。Transformer的核心是注意力：模型在处理每个Token时都会"关注"上下文中的其他Token。但注意力不是均匀分布的，长文本中中间部分的信息容易被稀释。这就是为什么"把重要信息放在提示词开头和结尾"是有效的，不是玄学。很多上下文工程技巧，本质上都是围绕注意力特性设计的。
第四，自回归生成与"不可能完美"。大模型是逐Token预测下一个Token的，这意味着每一次生成都是一次概率采样，天然存在随机性。把温度调到0可以减少随机，但不能消除不确定性。接受这一点，你才会在设计系统时主动加校验、重试、兜底，而不是祈祷模型表现稳定。
2.3 从零构建一个推理模型：值得做，但要知道目的
热词里"build a reasoning model from scratch"很多人搜，我也实际带过一个小项目，用几万条推理数据微调了一个小型模型。这个过程的真正收获不是模型本身，而是把上面说的原理亲手验证了一遍：数据质量如何决定效果上限、训练与推理的内存开销差异、量化后效果损失来自哪里、为什么大模型"涌现"的能力在小模型上就是没有。
如果你也想做一次，我建议目标设置成"复现一个小而完整的训练-评估-部署流程"，而不是"做出一个能用的模型"。推荐路径：用Hugging Face Transformers加载一个1-3B的开源模型，准备5000-20000条SFT（监督微调）数据，用LoRA做参数高效微调，再部署到vLLM上做推理服务。这条链路走完，你对于"模型生命周期"的感觉会和只看教程完全不同。
但我也要泼一盆冷水：不要把训练模型当成AI工程学习的主线。在绝大多数业务场景里，直接用成熟的商用API或7B以上的开源模型，远比从零训练划算。训练模型是为了理解，不是为了让业务跑起来。
3. 第一个能落地的AI项目：从选型到上线的完整链路
3.1 项目选型的三个原则
我的第一个正式AI项目是一个内部知识库问答系统，选它的原因现在回头看非常正确：业务场景清楚、数据可控、评估相对容易、不需要处理太复杂的Agent逻辑。给从零开始的人推荐首选项目，我一般建议满足三个原则。
第一，单点能力项目优于复合能力项目。先做"一个模型调用完成一个明确任务"的项目，比如文档分类、信息抽取、文本润色、客服问题路由。不要一上来就做Agent、多轮对话、复杂工作流——那些是多个单点能力的叠加，出问题时你根本分不清是哪个环节坏了。
第二，有明确的对错标准。信息抽取类任务特别适合入门，因为你可以人工标注一批标准答案，用精确匹配或相似度来量化评估。而"生成一段广告文案"这类开放生成任务，评估难度就高很多，不适合作为第一个项目。
第三，使用频率高、影响范围小。内部工具优于面向外部用户的产品。影响范围小意味着即使模型出错，代价也可控，敢上线、敢迭代，学习速度才快。
3.2 最小可行系统的搭建
拿我当时的客服问题路由项目举例，最小可行系统长这样：用户输入问题 → 调用模型给它归类到预定义的10个业务标签 → 输出JSON格式结果 → 程序解析后路由到对应人工处理队列。完整代码核心部分其实只有几十行。
import json from openai import OpenAI client = OpenAI() SYSTEM_PROMPT = """ 你是客服问题分类器。将用户问题归类到以下标签之一： [订单查询, 退换货, 支付问题, 物流进度, 发票开具, 投诉建议, 产品咨询, 其他] 只输出JSON，格式：{"label": "标签名", "confidence": 0.0-1.0} """ def classify_user_query(query: str) -> dict: response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": query} ], temperature=0, response_format={"type": "json_object"}, ) return json.loads(response.choices[0].message.content)就这么简单。但工程化的关键在于它周围的那层"壳"，我在生产落地时依次补上了五个部分：
- 输入预处理：清洗特殊字符、截断超长文本、敏感信息脱敏。
- 输出校验：模型返回的JSON可能字段缺失或格式错误，必须写schema校验和默认值兜底。
- 重试与降级：API超时或限流时退避重试；连续失败切换到备用模型或规则匹配兜底。
- 日志与追踪：记录每次调用的输入、输出、耗时、Token数、confidence，方便后续分析。
- 人工复核机制：confidence低于阈值的样本自动进入人工处理池，同时回收为标注数据。
这五个壳加完，才可以说这个AI功能"能交付"。它们也恰好印证了前文说的观点：模型只是组件，系统才是产品。
3.3 模型评估：我踩过的"看起来有效"的坑
第一个项目上线前，我犯过一个典型错误：用20条测试用例验证，准确率95%，就以为可以上线了。结果上线第二天就翻车——用户实际问法和测试用例风格差异很大，真实准确率可能只有70%。
这个教训让我建立了AI评估的三个基本认知：
第一，测试集必须贴近真实分布。最好从真实历史数据中采样，而不是自己编造。我当时自己编的用例用词太规范，用户真实提问则是口语化、带错别字、夹杂情绪化表达，完全是两个分布。
第二，评估标准必须预先定义。在动手写代码之前，就要确认"准确"的定义。多标签分类怎么算对？部分匹配算不算？错误标签和"其他"标签哪个代价更高？这些问题没有标准答案，但不提前想清楚，评估就是一笔糊涂账。
第三，评估要留出足够的样本量。分类任务至少准备200条以上测试集，才能对真实准确率有一个置信度较高的估计。20条只能算冒烟测试，不能作为决策依据。
4. 提示词工程与Harness Engineering：工程化的关键能力
4.1 提示词工程不是"写话术"
很多初学者把提示词工程理解为"把需求说得好听一点"，这是一大误解。我做了大量提示词迭代后，认为它的本质是结构化地约定模型的输入输出行为，类似于给模型设计一份接口协议。
一份工程化的系统提示词，我通常会拆成四个模块：
- 角色与任务边界：模型是什么角色、能做什么、绝对不能做什么。
- 输入输出格式协议：输出的结构、字段定义、枚举值范围，必要时附上正反例。
- 处理规则与优先级：遇到边界情况怎么处理，规则冲突时以哪条为准。
- 约束与底线：拒绝回答的范围、长度限制、引用要求等。
举一个信息抽取场景的片段：
你是一个合同信息抽取助手。 目标字段：合同编号、签约双方、合同金额、生效日期、有效期。 规则： 1. 金额只取阿拉伯数字并统一单位为万元，若原文为"壹佰万"需转换为100万。 2. 日期统一输出为YYYY-MM-DD格式。 3. 若字段在原文中不存在，输出null，禁止猜测。 4. 输出JSON，不要输出任何解释性文字。你会发现，这里面的每一条规则都是在"减少不确定性"。写提示词的功夫，不在于辞藻，而在于把业务规则翻译成模型能理解并严格执行的约束。所以提示词工程本质上是需求分析和规则设计，只不过表达介质从代码换成了自然语言。
4.2 Harness Engineering：模型之外的"脚手架"
热词里"harness engineering"最近讨论度高，这个叫法虽然新，但描述的事情并不神秘：把模型能力接入业务系统所需的所有外部机制。Anthropic在讲Agent设计时反复强调"harness"——模型是引擎，harness是底盘、油箱、方向盘、仪表盘。
我理解harness工程包含四个核心模块：
- 上下文工程（Context Engineering）：决定模型每轮调用能看到什么。包括指令、检索结果、历史对话、工具描述、示例，以及它们如何排序、截断、压缩。这是AI工程里最微妙也最影响效果的部分。
- 工具与行动空间（Tools & Actions）：定义模型通过函数调用能对外界施加哪些操作。工具的命名、参数Schema、返回格式的设计，直接影响模型能否正确使用它们。
- 控制流（Control Flow）：单次调用之外的循环、分支、终止条件。比如"最多重试3次""检索不到就换关键词再搜一次""用户确认后再执行写入操作"。
- 安全与权限（Safety & Permissions）：模型能访问什么、不能访问什么、敏感操作是否需要人工二次确认。
一个只调一次API的RAG问答，harness是"检索→组装→生成→校验"这条短链。一个能自主完成数据分析的报告Agent，harness就是"规划→调工具→观察结果→修正→再执行"的循环。AI工程能力的差距，很大程度上就是harness设计能力的差距——同样的模型，不同的harness，产出质量天差地别。
4.3 从单次调用到工作流编排
当我从第一个项目走向更复杂的功能时，最先学会的是把单次调用拆成"工作流"（Workflow）。举一个我常讲的例子：从非结构化简历中抽取候选人信息并生成评估报告。
单次调用的做法是：把简历全文塞给模型，让它一次输出结构化信息加评估意见。这样做的问题很明显：简历太长超出上下文窗口；信息抽取和主观评估混杂在一起，模型容易顾此失彼；结果不稳定且难以定位问题。
工作流做法的设计是：
- 前置清洗管线：解析PDF/Word，去掉页眉页脚，分段。
- 抽取模块：模型只负责抽取结构化字段，输出严格JSON，temperature设为0。
- 质量校验模块：用代码检查必填字段是否存在、日期格式是否合法，不合格则触发带错误信息的二次抽取。
- 评估模块：将抽取结果与岗位要求一起送入模型，输出结构化评分和评语。
- 汇总模块：把评分数据写入表格，对低分项生成提醒。
这个设计把"一个复杂任务"拆成"多个简单任务"，每一环的输出都是下一环的输入，而且每一步都有独立的校验点和日志。好处是：出问题能迅速定位到具体环节；单环节可以独立优化；可以针对不同环节使用不同模型（抽取用便宜的小模型，评估用更强的大模型）。
我给这个阶段的学习者的建议是：先别急着上Agent。用工作流方式把两三个单点项目串起来，你会彻底理解"工程化"三个字的分量。Agent不过是在工作流上加了自主决策的循环，没有工作流的掌控力，直接上Agent只会得到一个失控的黑盒。
5. AI Agent与多智能体协作的工程实践
5.1 Agent的本质与边界
Agent（智能体）最近是热度最高的词之一，但也是被滥用最严重的词。我个人的定义很简单：Agent是一个能根据目标自主决策、调用工具、观察结果并迭代行动的AI系统。工作流是预定轨道上的列车，Agent则是带着目的地、自己选择路线的驾驶员。
工程上，Agent和普通提示词调用的核心区别是那个循环（业界常称agent loop）：提出计划 → 执行工具调用 → 观察工具返回结果 → 根据结果调整下一步 → 直到达成目标或到达终止条件。每一轮循环都是一次完整的大模型调用，因此Token消耗、延迟、失败概率都会成倍增加。这不是坏事，前提是你清楚这些代价。
我在决定"要不要上Agent"时有一个判断标准：如果任务的步骤可以被预先穷举，就用工作流；只有步骤无法预判、需要根据中间结果动态决策的任务，才值得用Agent。比如"按固定模板生成周报"用工作流，"给我做一份本市咖啡店市场调研"才用Agent。
5.2 工具调用与记忆设计：Agent工程的两个硬骨头
Agent能不能跑起来，很大程度上取决于工具调用设计。我踩过几个坑，现在沉淀成四条规则：
第一，工具描述要写清楚"什么时候用"和"返回什么"。模型是靠描述来决定是否调用工具的，描述含糊它就会犹豫或者用错。比如"search_documents(query: str) → List[Document]，用于在知识库中进行语义检索"就比"搜索文档"明确得多。
第二，工具返回结果要结构化并可被模型消费。原始数据库记录、完整网页正文，这些直接丢给模型会撑爆上下文。好做法是让工具返回精简后的摘要，或者只返回元数据加正文片段。
第三，工具要有失败反馈机制。工具执行失败时必须返回可读的错误信息（如"API超时，服务端无响应"），模型才能据此调整策略。返回一个空结果会让模型误以为"搜不到"，从而给出错误结论。
第四，工具数量要克制。给Agent暴露的工具越多，它选错的概率越高。一次对话暴露5-8个核心工具就够，其余可通过子Agent或分步展开。
记忆设计是另一个难点。Agent的"记忆"在工程上有三层：上下文窗口内的短期记忆、外部存储中的长期记忆（向量库、KV数据库）、以及系统设计层面的状态管理。我踩过的最大教训是：不要试图把全部历史都塞进上下文，Token一旦太长，模型会越来越"健忘"且延迟飙升。靠谱做法是定期对历史对话做摘要压缩，只保留最近几轮原文加压缩后的"关键事实"。
5.3 多AI协作：一个实际案例与教训
多智能体协作（Multi-Agent）我实际做过一个案例，两名子Agent配合处理客服投诉：一个负责情绪安抚与话术沟通，一个负责查询订单与退款规则，中间由一个主Agent协调。结果确实能处理一部分复杂场景，但代价也不小。
第一个教训是角色之间如果没有明确的信息传递协议，协作就会变成互相扯皮。我从第一个版本就开始要求子Agent所有产出都以结构化JSON传递，比如{“action”: “query_order”, “order_id”: “xxx”, “result_status”: “found”, “summary”: “...”}。这样主Agent才能可靠地读取并使用。
第二个教训是多Agent的调试成本呈指数级上升。单Agent出错，可以看日志定位；多Agent协作出错，你得还原整个决策链——谁先说了什么、另一个基于什么信息行动了。没有一套完善的trace机制，排查问题会变成噩梦。建议任何多Agent项目第一优先级就是做完整的调用链路追踪，每一步的输入、输出、决策理由全部落日志。
第三个教训是成本。一次多Agent协作对话，可能消耗几千个Token。业务上是否有必要，一定要提前评估。我现在的倾向是：能用单Agent加工具解决的，绝不上多Agent；多Agent只用于真正需要不同角色视角的复杂任务。
6. AI工程的质量保障：测试、评测与监控
6.1 为什么AI应用测试这么难
传统软件测试建立在一个前提上：预期输出是可以精确判定的。AI应用打破了这一前提，同一个输入，模型今天和明天可能给出不同的回答，而且两种回答可能都"对"。那怎么定义bug？
我的经验是把AI系统的质量问题分成三个层次来处理：
- 确定性错误：格式错误、JSON解析失败、必填字段缺失、敏感信息泄漏。这些可以用传统代码检查全部拦截，是性价比最高的防线。
- 语义偏差：答案与标准答案不一致、遗漏关键信息、引用不存在的内容（幻觉）。这类需要构建评测集，用大模型打分或相似度计算来辅助评估。
- 体验问题：回答语气不友好、过于简短、不给用户台阶下。这类最难量化，适合用规则加人工抽检控制。
我还想特别强调一个工程原则：用代码能拦截的错误，绝不要指望模型自觉避免。比如要求模型输出JSON，一定要在代码里加JSON解析和schema校验；要求模型只输出指定枚举值，一定要在代码里检查值合法性。模型是概率性的，但系统边界必须是确定性的。
6.2 评测集的构建：从零到能支撑迭代
评测集中最重要的思想是"以增量方式沉淀"。我第一次上线的评测集只有50条，后来每次线上出问题，就把问题样本修正好后补充进评测集，现在规模已经超过500条。这个过程持续不断，评测集就会越来越接近真实世界的复杂分布。
评测集要覆盖三类样本：典型样本（高频场景）、边界样本（模糊表达、极端长度、多意图混淆）、对抗样本（攻击性输入、越狱尝试、自相矛盾的指令）。边界样本尤其重要，因为模型在边界上的表现往往最能反映系统的真实鲁棒性。
评测方式我常用三种组合：
- 规则断言：校验必填字段、格式、长度、引用来源是否存在。
- 模型打分：用更强的大模型按既定标准（相关性、完整性、忠实度）对回答打分。注意打分模型的Prompt里要附上明确标准，最好隔一段时间抽样人工复核打分质量。
- 人工抽检：对于高风险场景，定期抽检原始对话记录，发现评测集覆盖不到的新问题。
6.3 线上监控与回归：保证"改不坏"
AI功能上线之后，真正的考验才开始。模型厂商更新版本、提示词优化、上下文结构变化，任何一项改动都可能影响整体表现。我在线上至少会监控四类指标：
- 调用层面：成功率、延迟、Token消耗、超时率、重试率。这些是系统健康度的第一信号。
- 输出质量层面：空输出率、格式错误率、低置信度率、触发兜底逻辑的频率。这些反映模型输出是否稳定。
- 业务层面：用户满意度、转人工率、任务完成率。这是最终价值的度量。
- 成本层面：单次调用平均成本、日均总消耗、预算使用率。AI项目的成本波动比传统服务大得多，不设监控容易失控。
回归测试是我现在每个AI项目必做的环节。做法不复杂：把评测集固化为自动化测试用例，任何代码改动、提示词改动、模型版本升级之前，先跑一遍全套评测，对比关键指标有没有回退。没有这套机制，你根本不敢优化提示词——因为你不知道改完第3个prompt会不会把第1个场景弄坏。
7. 个人学习路线总结与避坑清单
7.1 我沉淀下来的学习路线图
如果从头再走一遍，我会把"ai engineering from scratch"的学习路径压缩成四个阶段：
阶段一：工程基础与模型调用（约2周）。目标不是学理论，而是熟练完成"数据输入→模型调用→结果处理"的闭环。做3个极简项目：文本分类、信息抽取、格式转换。每做一个，都强制自己加上输出校验和日志。这个阶段结束时，你应该能独立完成一个无交互的单点AI功能。
阶段二：上下文与提示词工程（约3周）。系统学习上下文窗口的影响、结构化输出、少样本示例、提示词版本管理。核心产出是：能针对一个真实业务场景，写出带完整规则的提示词，并设计出一套50条以上的评测集来衡量效果。这里的练习重点是"可衡量"。
阶段三：RAG与工作流（约4周）。做知识库问答项目，理解切分、嵌入、检索、重排、生成整条链路；然后把两三个单点能力串联成工作流，每一环都加校验和错误处理。这个阶段结束时，你应该具备把复杂任务拆分并工程化落地的能力。
阶段四：Agent与评估体系（约4-6周）。实现一个带工具调用的单Agent，设计清晰的任务循环和终止条件，上加完整的trace日志；有条件再尝试多Agent协作。同时把评测、回归、监控体系完整搭建起来。至此，你已经有能力独立交付一个中等复杂的AI系统。
每个阶段的核心是重复"假设-实验-测量-改进"的循环，而不是单纯堆知识。我的经验是：AI工程技能的成长速度，和你做实验的频率成正比，和你刷教程的时长关系不大。
7.2 给从零开始者的避坑清单
最后整理一份我在实践中反复踩过的坑，每条后面附一句自救建议，希望你能少走弯路。
坑1：沉迷模型原理，忽略工程落地。很多初学者把大量时间花在读论文、推导公式上，但项目还是不会做。自救建议：每天最多花20%时间学原理，80%时间做项目，用项目倒逼原理理解。
坑2：跳过评测直接调提示词。没有评测集的提示词优化，基本都是自我感觉良好。改完prompt觉得"看起来更好了"，一上线就原形毕露。自救建议：任何改动都要有评测数据支撑，哪怕只是20条用例的快速对比。
坑3：盲目追求Agent化和多Agent。简单任务非要用Agent，复杂任务直接上多Agent，结果成本和不确定性双双飙升。自救建议：先工作流，后Agent；先单Agent，后多Agent；每一步都要有明确的必要性判断。
坑4：忽略日志和可观测性。AI系统的debug难度远高于传统系统，没有完善的日志，一次偶发错误足以让你排查一整天。自救建议：从第一天就记录每次调用的完整输入输出、耗时、成本、版本号。
坑5：上下文塞得太满。总觉得历史信息越多模型越聪明，结果Token爆掉、延迟飙升、模型注意力被稀释。自救建议：建立上下文压缩和裁剪机制，只保留当前决策真正需要的信息。
坑6：没有模型版本管理。厂商更新模型后，你的AI应用效果悄悄变化，用户开始投诉你却找不到原因。自救建议：生产环境固定模型版本，升级前务必先跑整套回归评测。
我在实际项目中最大的体会是：AI工程这条路没有捷径，但确实有"正确的绕行方式"。把系统思维、工程纪律和模型理解结合起来，哪怕起点再低，迭代速度都会很快。如果你正站在入口处不知道该往哪走，挑一个最不起眼的单点功能，把它的评测、校验、监控做完整——这一个闭环走完，你看到的就不再是"模型能做什么"，而是"系统该如何被构建"。这个视角的转变，就是"from scratch"最重要的收获。