做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(levellogging.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( modelmodel, messagesmessages, temperaturetemperature, ) 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_asciiFalse, indent2)) if __name__ __main__: main()跑通这个脚本的意义不只是能用了而是为整个工程确立了一个最低可运行基线。之后所有的架构演进——加缓存、加检索、加评测——都可以在这个基线上逐步叠加每一层都是可验证的增量而不是一次性推倒重来。在工程环境层面有几个工具值得从第一天就配上。uv或Poetry管依赖把环境锁文件提交到仓库保证任何人拉下来都能复现pre-commit做提交前检查至少挂上代码格式化、排序import、简单lintDocker做运行时环境标准化避免在我机器上能跑的经典争论。我刚入行时总觉得这些是浪费时间现在回头看它们节省的排障时间远超配置成本。2.3 配置管理环境变量与模型路由的工程化AI工程的配置管理比传统后端复杂一些因为除了常规的数据库地址、密钥还有模型相关的参数模型版本、温度、最大token数、超时时间、重试次数、模型路由规则。我曾经在一家创业公司见过把模型名硬编码在五个服务里的乱象每次切模型版本就是一次全员拉练。我的配置分层策略是这样所有环境相关的变量放环境变量文件.env不提交仓库所有业务相关配置放统一的配置模块所有模型相关的动态策略放单独的配置类或配置中心。举个例子模型路由不应该因为改一行代码就重新发布而是通过配置去控制——比如DEFAULT_MODELgpt-4o-mini、LARGE_CONTEXT_MODELclaude-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, dtypenp.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工程的朋友有参考价值也欢迎有不同经验的朋友一起来碰撞。