做AI工程这些年，有个感触越来越深：会调API不等于会做AI工程。市面上铺天盖地的教程都在教你怎么调用模型接口、怎么跑通一个demo，但真正从零把一个AI项目做成产品级的东西，中间隔着大量没人讲的硬功夫——数据怎么管、提示词怎么迭代、链路怎么设计、线上怎么排障、成本怎么控制。这篇文章不是给你的"五分钟速成AI应用"指南，而是把我从零搭建AI工程体系、踩过的坑和沉淀下来的方法论，完整摊开来讲。
我默认你是那种不想停留在跑通demo、想把AI能力真正落到业务里的人。不管你是后端工程师转方向、数据工程师想进阶，还是产品经理想搞懂技术边界，这篇文章都能给你一条清晰的路径。我会按"从零开始"的节奏，从心智模型讲到环境搭建，从核心链路讲到生产级问题排查，把那些文档里不会写、教程里不会提的细节全部铺开。
1. AI工程的整体设计与思路拆解
1.1 先搞清楚：AI工程和传统软件工程到底差在哪
很多从传统后端转过来的朋友，最大的误区是把AI项目当成普通接口开发来排期和设计。传统工程讲究确定性：输入一样，输出就必须一样，逻辑写死了就行。但AI工程面对的是概率系统——同一个提示词、同一段输入，模型输出可能每次都不一样，甚至偶尔抽风给你一段胡话。这个本质差异决定了整个工程体系的设计思路必须跟着变。
我在设计AI工程架构时，第一件事就是承认不确定性，然后用工程手段把不确定性圈在可控范围内。具体来说，我会预留三层缓冲：输入层做规范化和校验，模型层做参数约束和输出格式化，输出层做兜底校验和降级方案。这三层不是可有可无的装饰，而是保证系统在模型抽风时仍然不会把错误结果直接暴露给用户的关键。
另一个核心差异是评价体系的转变。传统代码跑没跑对，看测试断言就行了；AI系统好不好用，需要一套多维度的评价标准——准确性、相关性、召回率、格式合规率、延迟、成本，甚至回答风格的稳定性。这意味着从设计阶段就要把评测机制考虑进去，而不是等项目上线了再临时找补。
1.2 为什么"从零搭建"比"抄别人demo"更有价值
我知道很多人学AI工程的第一步就是去GitHub找开源项目，Fork下来改改就上线。我不反对用现成方案，但如果你想在这个领域真正有竞争力，至少要把一条核心链路从零搭一遍。原因很直白：拷贝来的系统，你只知道它跑得通，不知道它为什么这么设计、哪些环节是雷区、删掉某个组件会发生什么。
我见过太多翻车现场：有人部署了开源的RAG系统，上线后才发现检索模块的排序权重根本没调过，召回结果质量差到离谱；有人直接搬了某个大厂的提示词模板，结果在自己的业务场景下完全水土不服。这些问题的根源就是缺少"从零搭建"带来的上下文理解。
从零搭建的核心路径，我建议按这个顺序走：先写一个不需要任何框架的裸API调用脚本，把模型的输入输出逻辑跑通；然后手动实现基于规则的问题路由；接着加入上下文管理；最后才把RAG、评测、缓存这些工程组件一个个加进去。每一步都亲手写过，你才知道每个组件解决的是什么问题、优化的边界在哪里。这个过程中的每一次调试、每一处妥协，都是知识体系的砖块。
1.3 技术选型背后的权衡逻辑
项目刚开始时最纠结的就是选型。模型用闭源API还是开源本地部署？向量库用专门的还是用PostgreSQL扩展？缓存用Redis还是直接用内存？编排框架用LangChain还是自研？这些问题没有标准答案，但我可以分享我的决策框架，一共就三个维度：团队能力、业务阶段、成本敏感度。
拿模型选型举例。如果团队里没人熟悉模型部署和GPU运维，业务又处在快速试错期，就直接用闭源API，把省下来的时间花在业务逻辑打磨上。如果业务对数据隐私有硬性要求，或者调用量巨大导致API成本失控，再考虑本地部署开源模型。我见过一个团队一上来就自建模型推理集群，结果三个人折腾了一个月还没把稳定性和并发扛起来，业务进度被拖垮了——这就是选型没有匹配团队能力的典型案例。
向量库的选型也遵循同样的逻辑。业务早期数据量小、查询模式简单，我甚至不建议引入独立向量库，直接在PostgreSQL里用pgvector就行，省掉一个基础组件，运维复杂度骤降。等数据量到了百万级以上、需要复杂的混合检索了，再引入专门的向量数据库。架构的演进要跟业务成长曲线对齐，一步到位是最不划算的工程投入。
2. 环境搭建与工程基座：从零开始的第一步
2.1 项目结构设计：一开始就别把代码写成一坨
很多AI项目的代码最后都变成了周一键文件："app.py"塞了三千行逻辑，"prompts.py"里堆了数十个字符串，"utils.py"什么都有。这种写法在demo阶段没问题，但一旦要加评测、加缓存、加日志，维护成本会呈指数级上升。我建议从第一个commit开始就保持下面这种清晰的结构：
ai-engineering-project/ ├── app/ # 应用代码 │ ├── api/ # 接口层 │ ├── core/ # 核心业务逻辑 │ ├── models/ # 数据模型和Schema │ └── llm/ # LLM调用、提示词管理 ├── data/ # 数据文件、向量索引存储 ├── eval/ # 评测脚本、测试集 ├── prompts/ # 提示词模板（独立于代码） ├── scripts/ # 运维、数据准备脚本 ├── tests/ # 自动化测试 ├── pyproject.toml # 依赖管理 └── .env.example # 环境变量模板重点说下为什么提示词要独立于代码放。我踩过最大的坑就是提示词散落在代码字符串里，改一个措辞要全局搜索替换，还经常漏掉某个副本造成线上行为不一致。把提示词模板化、集中管理之后，提示词和代码可以独立迭代和版本化，改提示词不需要重新发布代码，这在快速试错阶段极其重要。
数据目录也需要提前规划。AI项目会产生大量中间产物：原始数据、清洗后的数据、切分后的chunk、向量索引、评测结果。如果随手乱放，很快会陷入"文件找不着、不知道哪个是新版"的混乱。我的经验是建立统一的data/目录，里面按处理阶段分子目录，并且所有数据文件在命名时带上批次号或时间戳。这活儿不性感，但能省掉未来无数小时的找文件时间。
2.2 从第一个可运行脚本到可复现的工程环境
动手第一步永远是跑通最小闭环。我习惯先写一个最朴素的Python脚本，接上模型API，实现一次完整的"输入→模型调用→输出解析→结果打印"。这个阶段不考虑并发、不考虑缓存、不考虑容错，目标只有一个：确认链路通。
# llm_smoke_test.py """最小链路验证脚本：确认模型调用、输出解析、日志输出三方都正常。""" import json import logging import os from dotenv import load_dotenv load_dotenv() logger = logging.getLogger(__name__) logging.basicConfig(level=logging.INFO) MODEL = os.getenv("LLM_MODEL", "gpt-4o-mini") TEMPERATURE = 0.3 def call_llm(messages: list[dict], model: str = MODEL, temperature: float = TEMPERATURE) -> str: """调用模型并返回文本内容。这里用最小实现保持依赖单一化。""" # 以OpenAI兼容接口为例，实际项目请换成对应SDK from openai import OpenAI client = OpenAI() resp = client.chat.completions.create( model=model, messages=messages, temperature=temperature, ) return resp.choices[0].message.content def main(): user_input = "用一句话介绍什么是向量检索" messages = [ {"role": "system", "content": "你是AI工程助手。"}, {"role": "user", "content": user_input}, ] output_text = call_llm(messages) logger.info("模型输出: %s", output_text) # 输出必须走标准格式，便于下游统一消费 result = {"input": user_input, "output": output_text} print(json.dumps(result, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()跑通这个脚本的意义不只是"能用了"，而是为整个工程确立了一个最低可运行基线。之后所有的架构演进——加缓存、加检索、加评测——都可以在这个基线上逐步叠加，每一层都是可验证的增量，而不是一次性推倒重来。
在工程环境层面，有几个工具值得从第一天就配上。uv或Poetry管依赖，把环境锁文件提交到仓库，保证任何人拉下来都能复现；pre-commit做提交前检查，至少挂上代码格式化、排序import、简单lint；Docker做运行时环境标准化，避免"在我机器上能跑"的经典争论。我刚入行时总觉得这些是浪费时间，现在回头看，它们节省的排障时间远超配置成本。
2.3 配置管理：环境变量与模型路由的工程化
AI工程的配置管理比传统后端复杂一些，因为除了常规的数据库地址、密钥，还有模型相关的参数：模型版本、温度、最大token数、超时时间、重试次数、模型路由规则。我曾经在一家创业公司见过把模型名硬编码在五个服务里的乱象，每次切模型版本就是一次全员拉练。
我的配置分层策略是这样：所有环境相关的变量放环境变量文件（.env，不提交仓库），所有业务相关配置放统一的配置模块，所有模型相关的动态策略放单独的配置类或配置中心。举个例子，模型路由不应该因为改一行代码就重新发布，而是通过配置去控制——比如DEFAULT_MODEL=gpt-4o-mini、LARGE_CONTEXT_MODEL=claude-sonnet-4-20250514，业务按需读取。当你需要在不同模型之间做A/B测试时，这种动态设计能让你少改无数代码。
超时和重试参数尤其值得重视。LLM接口的延迟波动远大于普通HTTP接口，我建议超时时间至少给到60秒以上，重试次数2-3次，并且重试要带指数退避。另外强烈建议对每种调用设置独立的超时参数——短上下文对话、带检索的复杂查询、长文本生成，它们的延迟特征完全不同，共用一个超时策略的结果就是要么频繁误杀、要么等待过久。
3. 核心链路拆解与实操要点
3.1 提示词工程：不是"写个好prompt"那么简单
提示词工程在很多人眼里就是"拼字符串",但工程化之后，它涉及模板管理、版本迭代、变量注入、输出校验一整套流程。我在项目中已经把提示词完全从代码里抽离出来，统一放在prompts/目录下，用JSON或YAML格式管理。
先看一个模板设计的例子，这是我认为比较健壮的对话系统提示词结构：
system_prompt: role: "你是一名智能客服助手，负责解答用户在产品使用中遇到的问题。" guidelines: - "优先以简洁、分点的形式呈现答案。" - "如果问题不明确，先询问澄清，不要强行猜测。" - "对超出知识范围的提问，诚实说明并提供联系人工客服的路径。" constraints: - "输出必须使用中文。" - "不得编造不存在的功能或参数。" output_format: | 请按以下JSON格式输出： {"reply": "...", "confidence": 0.0-1.0, "need_clarify": true/false}为什么提示词要这样结构化？因为模型对混乱指令的响应质量，远低于对清晰分段指令的响应质量。把"角色""规则""约束""输出格式"分离开，每一部分都可以单独迭代，调试时也容易定位是哪个环节导致输出异常。
输出格式约束是我强烈建议从第一天就做的事。让模型输出结构化JSON，而不是自由文本，可以极大降低下游解析的脆弱性。但这里有个血泪教训：模型输出JSON但不保证合法JSON，所以解析必须做容错处理。我的方案是解析失败时先尝试修复（补括号、去注释、提取子串），修复不了再走重试，重试仍不行就降级到文本模式。这个兜底逻辑看起来"不优雅"，但在生产环境里它是救命的。
3.2 上下文工程：从裸调用到有记忆的对话
当你开始做真正的对话系统或Agent时，第一关就是上下文管理。LLM本身是无状态的，你每次调用都要携带完整的对话历史，但历史也不能无限携带——token都是钱，而且模型上下文窗口有限。
我的上下文管理策略分三层。第一层是窗口滑动，最简单的方案：保留最近N轮对话，超过就丢弃最早的部分。适合闲聊类、即时性问题。第二层是关键信息提取，维护一个"长期记忆库"，实时从对话中摘要出用户偏好、关键事实，并在新对话开始时作为背景知识注入。第三层是按需检索，把历史记录切成块存入向量库，每次对话根据当前问题的相关性召回历史片段，而不是全量塞给模型。
实操层面，滑动窗口的N值怎么定？我的经验是：简单问答场景保留5-10轮足够；复杂任务场景（比如代码辅助、多步分析）可能需要15-20轮。但这绝不是拍脑袋定的，而是通过评测数据来的——准备一组包含多轮依赖的测试问题，分别用不同窗口大小测试准确率，选取准确率和成本的最佳平衡点。我见过太多人窗口开得过大，对话质量没见提升，成本倒是翻了几番。
3.3 RAG实战：检索增强生成的坑比想象中多
RAG（检索增强生成）是当下把知识库和LLM结合的标准方案，但它远不是"文档转向量、查到了拼进提示词"这么简单。整个链路拆开看，有四个环节要么不做、要么做透：文档解析、切块策略、索引构建、查询与检索。
文档解析是最没啥技术含量但最容易翻车的环节。PDF、Word、扫描件各有各的坑，解析不干净直接导致后续切块质量崩盘。我建议这里花时间去清洗、规整、转换格式，实测效果远超用一个万能解析库一把梭。切块策略直接影响检索相关性——我试过固定长度切块、段落切块、语义切块，关键结论是：切块粒度要跟业务问题的粒度对齐。如果你的业务问题集中在"某个具体条款是什么"，切块就不能太大；如果问题是"总结一下整体内容"，切块大了才有效。推荐从小的块开始（200-500字），配合重叠窗口，并在真实问题集上测相关率来调优。
索引构建阶段，除了纯向量检索，我强烈建议做混合检索：向量检索负责语义相似度，BM25或全文检索负责关键词精确匹配，两者分数再做加权融合。纯向量检索有个致命盲区——它不懂精确字符串匹配，比如你用"iPhone 16"去检索，结果返回一堆讲"苹果手机"的内容，关键词相关性反而不如传统的全文检索。两个通道融合，能明显提升召回质量。
查询侧还有个常被忽略的问题：用户原始问题通常是碎片化的，直接拿去检索效果很差。我的做法是先做查询改写——用LLM把用户口语化的问题改写成适合检索的独立关键词或子问题，再执行检索。这一步会增加一次模型调用（成本+延迟），但换来的是检索相关性的显著提升。
3.4 Agent模式：从单次调用到多步任务执行
当AI系统要完成的不只是"回答一个问题"，而是"完成一个任务"时，就需要引入Agent的设计。多步任务、调用工具、观察路径、修正计划，这些能力组合起来才叫Agent。但这个领域现在虚火很旺，大部分Agent产品在真实业务里表现不如预期，原因是工程复杂度被低估了。
我建议从最简单的ReAct（推理+行动）模式开始做，理解核心机制后，再决定是否有必要用更重的框架。核心循环是：给定一个目标，模型先生成"下一步该做什么"的推理，然后执行动作（调用工具或查询知识库），观察返回结果，再决定下一步行动，直到任务完成。这个循环本身不复杂，难的是在每一步做工程加固：与用户目标偏差检测、循环检测（模型反复做同一件事）、最终回答不完整时如何补救。
工具调用的可靠性也是个巨大工程。我经历过模型生成了错误的JSON参数导致工具调用崩掉，也经历过模型选择了错误的工具名导致业务数据被误操作。现在的规范做法是：工具定义用严格的JSON Schema，模型输出先过Schema校验，非法请求直接拦下重试；工具执行结果统一包装成结构化反馈回传给模型。这些防护看起来影响"流畅性"，但生产环境里模型抽风的概率比想象中大得多，宁可慢也要稳。
4. 生产级落地：性能、成本与可观测性
4.1 控制延迟：从用户体感到工程指标的全面优化
模型生成速度是硬瓶颈，一个动辄几秒钟的请求如果不做任何优化，用户体感会非常差。延迟优化我有三层手段，优先级从高到低。
第一层是并联。如果一次对话既要检索知识库又要获取用户历史画像，这两次调用完全可以同时发起，而不是串行等待。我用asyncio.gather把多个无依赖步骤并发执行，实测能把链路的p95延迟降低30%-40%。这个优化几乎不增加任何系统复杂度，收益却立竿见影。
第二层是流式输出（SSE）。模型边生成边把token推送给前端，用户看到的是逐字流出的回答，而不是盯着空白页干等。流式输出的体感改善非常显著，哪怕总耗时不变，用户的主观等待感都会大幅缩短。代价是链路复杂度增加——流式连接的管理、中断处理、字节流缓存都要额外做。
第三层是语义缓存。遇到重复或高度相似的问题，直接返回之前的结果，不再调用模型。这和普通后端缓存思路一致，但难点在于"语义相似"的判断，简单哈希缓存只在完全一致时命中，收益有限。我的项目里会用向量相似度来判断缓存命中：把用户问题嵌入，和缓存库里的历史问题比对，相似度超过阈值就返回缓存历史结果。实测在客服等场景，缓存命中率能做到30%以上，成本和延迟同时降下来。
# semantic_cache.py """演示语义缓存流程：向量化→相似度检索→命中返回缓存结果。""" import hashlib from typing import Optional import numpy as np class SemanticCache: """一个最小语义缓存示例，生产环境建议把向量和值存进Redis+向量库。""" def __init__(self, embed_func, similarity_threshold: float = 0.92): self.embed_func = embed_func # 文本向量化函数 self.threshold = similarity_threshold self._keys: list[str] = [] self._embeddings: list[np.ndarray] = [] self._values: list[str] = [] def _embed(self, text: str) -> np.ndarray: vec = self.embed_func(text) return np.asarray(vec, dtype=np.float32) def get(self, question: str) -> Optional[str]: q_vec = self._embed(question) best_score, best_idx = -1.0, -1 for i, e_vec in enumerate(self._embeddings): score = self._cosine(q_vec, e_vec) if score > best_score: best_score, best_idx = score, i if best_score >= self.threshold and best_idx >= 0: return self._values[best_idx] return None def put(self, question: str, answer: str) -> None: self._keys.append(question) self._embeddings.append(self._embed(question)) self._values.append(answer) @staticmethod def _cosine(a: np.ndarray, b: np.ndarray) -> float: return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) + 1e-9))4.2 成本控制：把token当成预算去管理
AI工程有一句话说得特别准确：这不是算力密集型，而是token密集型。每多一次多余的模型调用、每多一段冗长的上下文、每一次重试，烧的都是真金白银。成本控制要从设计期就开始，而不是等账单来了才拍大腿。
我管成本的手段主要有这几个。一是限制重复调用——同一个用户请求的多个步骤之间做好状态跟踪，避免因为链路重入导致重复调用。二是按需选择模型规格——不是所有请求都要用旗舰模型，简单问答、格式化提取这类任务，用一个mini模型完全够，只有在复杂推理时才路由到更强的模型。三是控制上下文token消耗——在上下文管理里用记录级摘要替代全量历史，做动态截断，只保留对当前任务真正有影响的部分。
这里要特别讲一下prompt压缩。很多AI工程团队会忽略提示词本身的token占用，结果系统提示词越写越长。一条3000字的系统提示词，在每月的百万次调用下就是一笔巨大的固定成本。我的做法是每季度对提示词做一次瘦身：去掉重复约束、合并冗余描述、精简示例。优化完的提示词质量未必下降，token却能省下20-30%。这笔账，做过规模化AI服务的人都懂。
4.3 可观测性：AI系统怎么追根溯源
AI系统排障比传统系统难太多了。传统接口出错，看状态码、看堆栈就行；AI系统的错误往往表现成"回答质量不对""行为不符合预期"，不能简单归因。因此可观测性要从两个维度同时建设：基础链路维度（请求日志、耗时、状态码）和AI行为维度（模型决定、检索结果、输出质量）。
我强烈建议从第一天就做全链路日志。不是简单记一笔"调用了哪个模型"，而是要记住：确切的请求消息、模型返回原始内容、检索命中了哪些片段、最终输出是什么。这样一来，当用户反馈"答案不对"时，你可以回溯到底是在检索阶段丢了关键信息，还是模型理解偏差，还是最终拼接阶段出了错。没有这些日志，Debug AI系统就像在没有监控的线上服务器上猜故障原因，只能靠运气。
评测体系也要纳入可观测性。在RAG场景里，检索召回率、答案准确性、引用正确性是三个核心指标。怎么做评测？把典型问题进行业务标注，每次系统更新后把同一批测试集自动跑一遍，计算指标变化。在CI/CD里挂一个评测job，阈值不达标就阻止合并。我第一次把评测接入CI时，防御住了一次提示词"优化"导致准确率跳水的事故，从此彻底离不开了。
4.4 可靠性兜底：模型不可用和输出不可信怎么办
生产环境下，模型服务会有故障期、限流、超时。设计兜底策略时，我把系统从"完全依赖模型"改成了"模型不可用时仍然能给出有限服务"。
降级策略我设计了三档：全功能模式（模型可用，完整链路）、降级模式（模型服务不稳定，自动切换到备用模型或更低配置的模型）、冻结模式（模型完全不可用，改用预设模板或缓存回复，保证用户能收到响应而非白屏）。这个设计听起来简单，但落地时有个细节容易忽略：降级逻辑要自动触发，而不是等人去手动切换。我在网关层做了健康检查和熔断器，连续失败超过阈值就自动切换流量到备用通道。线上一个大模型服务故障的那天，这个机制保住了我们系统的可用性，体感上用户几乎没有受影响。
输出不可信的问题，我靠输出校验器来解决。模型输出的内容，先过一道Schema校验，再看是否包含需要拦截的内容（比如敏感词、超长输出、空回复），最后才正式返回。校验不通过就重试一次，重试仍失败就降级。这套机制看似笨拙，但你会发现，只要你长期运行AI服务，模型抽风一定是必然事件，校验器就是你的安全网。
5. 常见问题与排查技巧实录
5.1 模型输出格式不稳定的排查方案
这是出现频率最高的问题，没有之一。你让模型返回JSON，它偶尔给你加一段解释文字或者返回一个残缺的JSON，解析直接崩。我排查这个问题的标准化流程是这样的：
第一步，先看是不是提示词约束不够明确。在输出格式说明后，加一句"不要输出任何其他文字"，或者给一个强示范。第二步，看是不是用了流式响应导致截断。有些时候不是模型不配合，而是流式传输中连接中断或服务端截断，导致响应不完整。第三步，加上解析层的容错钩子，记录每一次解析失败时的原始输出，定期分析这些失败样本，找出pattern再针对性修改提示词。
我自己踩过的一个案例是：温度参数设得太高（0.8），导致模型在生成JSON时"发挥过度"，总喜欢在JSON外框加些话。后来把温度降到0.2，问题立刻大幅缓解。这就是典型的参数和格式约束互相影响的案例。排查时要先看系统设计参数，别一上来就怀疑模型能力。
5.2 检索质量差的归因路径
RAG检索不到相关内容，或者检索到了但答案依然不对，这是RAG项目最常见的困惑。我的排查路径遵循一个清晰的归因顺序：
先确认检索环节：查看日志里实际召回的分片内容，是分片本身包含正确信息却没被召回，还是所有召回分片都是次相关的。如果是后者，问题在向量表示或检索策略。我试过同一组文档用不同的Embedding模型，相关率能从70%掉到40%，Embedding选型的影响远超想象。如果是前者——召回里明明有答案模型却没用上，问题在提示词拼接——要么分片在上下文里被淹没，要么提示词没告诉模型"优先参考提供的资料回答"。
再往下查数据质量问题：文档没清洗干净、大量无关信息混在分片里，都会拉低召回质量。知识库的运维是个长期工程，需要定期清理失效文档、更新过期内容。我在生产项目里建立了一个"文档健康度体检"流程，用统计特征（平均分片长度、重复率、失效链接占比）来量化整个知识库的健康程度。别问为什么这么做——当你发现某个热门问题的答案一直基于一篇已经失效的文档生成时，哭都来不及。
5.3 上下文爆炸和长对话退化问题
对话轮数一多，两个问题必然出现：token消耗激增和历史扰乱了新任务的注意力。我的处理策略是"三步走」：检测长对话、自动摘要历史、合并保留关键信息。
实现上，我先维护一个累计token计数器，超过阈值时触发摘要流程。摘要会由一次单独的模型调用生成——让模型把一个阶段的对话历史浓缩成要点，包括用户核心关注点、已经达成的结论、未完成事项。然后把摘要作为新历史的一部分，把旧的原始对话丢弃。这一步做完，上下文长度从几千token直接降到几百，而且模型对关键信息的把握反而更准，因为"噪音"被清掉了。
腰椎间盘突出导致的行动不变，扯远了。但用医学做类比，AI对话的上下文管理费用就像给系统做"记忆压缩"，压缩得好不好直接影响整体“健康状况”。这套摘要机制单次看要花钱，但从长对话总体成本来看，是明确的净节省。
5.4 工具调用失败的工程化解法
Agent系统的工具调用失败，根源通常有三类。第一类是模型生成了非法参数——工具定义没给清楚，模型自己编了一个字段。解法是工具定义写严格的JSON Schema，并在提示词里给出每个参数的取值示例，这能明显降低非法参数概率。第二类是模型选错了工具——比如用户要查天气，它调了日历工具。解法是给每个工具加一段"使用时机"说明，并且在工具选择前加一道上下文相关性校验。第三类是工具本身返回了异常数据——这时不能在循环里反复调用，要给模型观察结果的窗口，或者直接把异常信息作为反馈传入下一轮推理。
工具调用的日志分析也值得做。我定期统计哪些工具的调用失败率最高、哪个工具最频繁被"误选"，这些数据反哺到提示词和工具定义的优化上，形成正向循环。市面上很多框架帮你把工具调用包装得很漂亮，但调试体验极差，我建议核心工具链自研，把日志和排障能力牢牢抓在自己手里。
6. 从零开始的完整路径再梳理
整个从零搭建AI工程的路径，核心就是反复验证这件事。不能从上往下"画饼式"设计——把所有理想模块都规划好再动工——而是从最小闭环起步，一层层加模块、一个个做验证。每加一层，都要回到真实场景里测试这一层的效果，不好的就调整，好的才固化。
我自己回顾从最初的裸API脚本到现在能承接生产流量的AI工程体系，最关键的分水岭就是从"关注模型输出"转向"关注链路指标"。当你开始关心检索召回率、评测通过率、缓存命中率、端到端延迟，而不是纠结"这次回答得好不好"，说明你已经具备了工程思维。这条路没有速成，每一步踩坑都是真实的学费，但只要持续迭代，系统的复杂性就不再是压力源。
最后再分享一个细节。我现在团队里的新人上手AI工程，我不会让他们先去看论文或框架文档，第一件事永远是"写一个不依赖任何框架的最小RAG链路"，从切分到检索到拼接，全部手写。这个练习做完，框架就只是工具，而不是不可逾越的黑盒。理解越深，未来的工程决策就越稳。希望对准备入局AI工程的朋友有参考价值，也欢迎有不同经验的朋友一起来碰撞。
