1. 重新理解AI工程它不等于写Prompt也不等于调API我见过太多人把AI工程和提示词工程划等号也见过不少人觉得只要把模型的API接进来就算完成了一个AI项目。说实话这两类理解都只摸到了大象的一条腿。真正意义上的AI工程是从一个模糊想法开始经过需求拆解、技术选型、数据准备、模型调用、工具集成、评估迭代到最后稳定运行的全链路过程。这个过程里有大量脏活累活也有大量决定成败的隐性细节。为什么说from scratch这件事值得认真对待因为当你从零开始搭一套AI系统的时候你被迫去理解每一层的原理模型是怎么接收上下文的、为什么同样的Prompt在不同的温度参数下表现完全不同、为什么简单的应用也要做输入校验、为什么把文档切碎后丢进向量库并不是RAG的全部。这些知识在调用现成服务的视角下是永远碰不到的但恰恰是它们决定了你能不能从跑通demo走向扛住生产环境。这篇文章适合几类人已经会用ChatGPT或DeepSeek这类产品、想进一步理解背后工程逻辑的同学写过程序但还没有系统性接触过AI开发的工程师以及那些手上已经有业务场景希望通过自己的技术方案把AI真正落地而不是停留在尝鲜阶段的实践者。我会尽量把关键环节的为什么讲清楚再配上可以直接抄的步骤和材料。我自己的经历也值得一提我最开始做AI相关项目的时候觉得最难的肯定是模型本身结果真正开始做了才发现模型调用是整条链路里最简单的一环。最难的是对输入的理解、对输出的校验、对错误的处理、对效果的度量以及在不同环节之间传递信息时怎么不丢失关键语义。这些才是AI工程的主战场。2. 从零开始的第一步梳理AI系统的五层核心能力地图那么从零开始到底该先做什么第一步不是打开某个IDE写代码也不是到处找模型API的Key而是先建立一张能力地图搞清楚一个完整AI系统到底由哪些部分组成。2.1 第一层模型接入层——选型、部署与调用方式这层解决的是最底层的问题用哪个模型是调用云端API还是本地部署使用基座模型还是微调后的衍生模型对多数人来说第一轮选型通常是在云端API与本地部署之间做权衡。云端API的好处是零部署成本、推理性能有保障、生态完善适合快速验证和中小规模应用。常见的代表就是OpenAI的GPT系列、DeepSeek的对话模型以及各种国内大模型服务。缺点是存在数据外溢风险、单次调用成本会随着规模线性增长、对网络环境有要求而且不同服务的接口风格、限流策略、内容审核策略都不同接入后还需花时间适配。本地部署的好处则是数据自主可控、完全离线可用、长期运营成本可以压低适合对隐私敏感或需要深度定制的场景。但代价是你需要一台足够好的机器至少要有16G以上显存的GPU否则连7B模型都跑不顺、需要处理模型下载、格式转换、推理框架配置、显存优化等一系列问题。我在早期项目里的做法是云上验证、本地兜底先用云端API把功能逻辑全部跑通确认Prompt设计、返回解析、容错逻辑都没有问题了再根据实际使用场景决定要不要迁移到本地。这样既不会让硬件条件拖慢开发进度也不会让应用在关键时候被API服务的不稳定牵制。2.2 第二层幻觉与可信度压制层——大部分人最容易忽略很多初学者会觉得模型返回什么我就解析什么这有什么可纠结的等到真实项目里发现模型的回答有时候会胡编乱造、有时候会因为用户输入里的一个诡异措辞而跑偏才知道可信度是AI应用里最棘手的问题。这一层做的事情包括对用户输入做规范的清洗和校验、在Prompt里加入格式约束和思维框架约束、对模型输出设置额外的后处理规则比如要求模型输出JSON并用模式校验、让模型学会说不知道而不是胡猜以及在关键业务场景里接入检索增强来给模型提供事实依据。一个简单但有效的办法是双层约束第一层约束在Prompt层面告诉模型你只能基于给定的资料回答资料中没有的信息直接回答不知道第二层约束在代码层面对返回内容做关键词检查、格式检查、敏感信息过滤。两层都过了才能把结果展示给用户。这套双重保险在实践中能把幻觉率压下去一个数量级代价只是多写几行校验代码。2.3 第三层上下文工程层——决定模型懂不懂你在说什么我在实际开发中最深刻的体会是模型能力的上限往往不是由模型本身决定的而是由你喂给它的上下文质量决定的。上下文工程这个词指的是围绕单次或多次模型调用如何组织输入信息、如何选择历史对话、如何压缩和摘要、如何嵌入外部知识。上下文窗口意识LLM都有上下文长度上限常见的是几千到几十万tokens。超过上限要么直接被截断要么报错。工程上要时刻关注当前对话消耗了多少上下文、还能剩多少必要的时候对历史消息做截断或摘要压缩。信息密度意识同样的信息量一份是冗长的原始文档一份是提炼过的结构清单模型理解后者质量会明显更高。所以在把资料丢给模型之前先自己把关键信息提取一遍或者先用一个小模型跑一遍信息抽取再喂给大模型。角色与目标锚定上下文里除了事实信息还要包含任务的目标说明和边界说明。我一般会固定写一段系统提示词任务指令输出格式把它放在上下文的最前面。因为模型对开头的注意力权重天然更高重要信息放到前面才能保证它不跑偏。2.4 第四层工具与行动层——从会说到会做一个只会生成文本的模型就像一个只会给建议却动不了手的顾问。工具与行动层的目的是让模型能够调用外部能力执行函数、查询数据库、调用搜索、读写文件、操作浏览器。这一层把应用从聊天机器人提升到了智能体。技术上的核心是Function Calling或Tool Use机制。简单说就是我们给模型声明一批工具的JSON Schema模型根据用户意图决定调用哪个工具、填入什么参数然后我们截获这个调用意图在代码里真正执行对应操作把执行结果返回给模型模型再基于结果继续生成回复。这里有三个很关键的工程细节给工具的说明要足够详细很多初学者只写search(query: str)这种名字和参数导致模型根本不知道怎么用。我给每个工具写清楚什么时候用这个工具参数应该从用户哪句话里提取这样的元信息工具的准确率能提升不少。执行结果的反馈必须结构化不要直接拼一个字符串丢回去而是用一个统一的结构告诉模型执行成功了结果是什么执行失败了错误是什么。这样模型才能判断下一步怎么做。循环必须设置上限模型执行工具→得到结果→再执行工具这个循环如果没有次数限制遇到复杂任务时可能无限转圈。我在所有Agent逻辑里都加了最大迭代次数和单步超时时间两个硬性阈值。2.5 第五层评估与回归层——没有评估就没有迭代评估是AI工程里最容易被拖到最后、甚至直接被省略的环节。没有评估你改动一个Prompt或者换一个模型版本的时候就全靠感觉判断是不是变好了这在工程上等于没有方向盘开车。我认为一个合格的AI项目在上线前至少要建立一套最小评估集几十条有代表性的输入配上期望行为的描述然后每次改动后都跑一遍对比改动前后的输出质量。高级一点的可以引入自动化指标比如基于规则的答案包含性检查、基于模型评分的相关性打分、格式正确率等。把评估集沉淀下来作为项目的回归测试这就是AI工程走向正规化的标志。有了这五层能力地图以后你会发现市面上几乎所有AI应用拆开来看都是在解决这五层里的某几个问题。写文章之前先花半小时把这五层过一遍比直接动手写代码省的时间要多得多。3. 实际项目拆解以本地知识库问答机器人为例的完整搭建路径纸上谈兵没用下面我用一个侧重点突出、可复现的真实项目来演示from scratch的完整路径。这个项目是用本地部署的开源模型搭建一个能根据指定文档内容回答问题的知识库问答机器人。很多人会把这个项目等同于把PDF切碎放到向量数据库里然后做相似度检索再扔给模型但真实项目里要解决的问题远不止这些。3.1 需求定义与架构草图我建议所有项目第一步都先写一句话需求用户上传一份或多份文档之后可以向系统提问系统只依据这些文档的内容给出答案答案需要标注来源依据文档没有覆盖的问题要明确拒绝回答。这句话里其实已经隐含了一堆工程约束只依据文档回答意味着这道题必须走检索增强生成路线并且要在Prompt层面和代码层面双重守住事实边界标注来源依据意味着文档切块时就要给每个块带上索引号、来源文件名、页码等元信息明确拒绝回答意味着不能只靠模型自觉还要在后置环节做兜底检查。架构上我选了最老练清晰的几件组件本地部署一个开源对话模型这里用的是Qwen系7B级别原因后面展开用向量数据库存文档切片用一套中文文本分割逻辑做文档切块用嵌入式模型给切片做向量化在代码里实现检索→组装上下文→调用模型→输出校验的串联逻辑。在动手装任何东西之前我强烈建议先在纸上画出这个架构图标清楚数据从哪来、存到哪、查询时怎么走、模型在哪被调用、失败了什么逻辑兜底。画图的过程就是提前踩坑的过程很多依赖冲突、上下文组装顺序、边界条件问题在动手前就能发现一多半。3.2 模型选型与本地部署为什么我选了7B量级模型本地部署这件事第一步就是现实问题你的机器有多强的算力显存是最大的硬约束。一个粗略的经验公式是7B量级的模型用INT4量化后大约需要4到6GB显存INT8量化需要约8GBFP16需要约14GB。13B量级在INT4量化下也要8GB以上FP16则要接近28GB。所以在一张消费级显卡例如RTX 3060 12G、RTX 4070 12G这些主流配置上最合理的选择往往是7B模型的INT4或INT8量化版本。更小的比如1.5B到4B跑起来飞快但理解能力和知识储备明显偏弱在知识库问答这种需要读文档细节的场景里容易答非所问更大的比如14B、32B虽然能力更强但硬件门槛直线上升如果你只有16G显存还要把向量化、检索流程都跑在同一台机器上显存会捉襟见肘。部署工具方面现在最省心的几个选择是工具特点适合人群Ollama一条命令拉模型跑模型自带OpenAI兼容API想最快速度把模型跑起来验证想法的初学者llama.cpp纯CPU/GPU混合部署量化格式GGUF资源占用低配置不高、希望精细控制推理参数的场景vLLM高吞吐推理服务支持批量推理生产级性能需要同时服务大量请求的服务端场景这里有个很实用的经验Ollama虽然部署最方便但你用的如果是不带GPU的老机器推理速度会慢得让人失去耐心。我自己的策略是开发调试用Ollama压测和上线用vLLM先在Ollama上把Prompt和逻辑调好然后切到vLLM跑高并发验证两边通过OpenAI兼容的接口无缝切换只改一个base_url的配置就行。3.3 文档切块的工程细节不是随便切切就完事数据准备阶段最容易被低估的就是文档切块。很多人直接用固定长度比如500个字符把文档线性切成一块块结果切出来的块经常语义断裂、上下文粉碎检索质量自然稀烂。我对中文技术文档的切块逻辑做了三轮迭代最终可用的方案是这样的按语义结构粗切先根据文档的标题层级Markdown的#和##或者PDF的目录结构把整个文档切分成章节块每个章节块独立处理。章节块内部再按段落和长度细切一个章节如果太长再按空行分隔的段落细切段落本身超过设定上限我是按300到500个中文字符再从上一个句号处做软切断保证切的不是词语和半句话。相邻块之间保留重叠我给每个切割块保留前后约50到80字符的overlap。这个操作在向量检索里非常管用因为一个完整的意思可能横跨两个块重叠能确保两个块都包含足够上下文检索时不容易漏掉关键信息。切块完了以后还要做一步很多人会忽略的元信息挂载给每个块加一个JSON头部记录来源文件名、章节路径、页码如果有、切块序号。后面给用户展示能看到我在文档里哪一段找到了依据的时候全靠这些元信息定位。3.4 检索增强的组装逻辑让模型照着材料说话RAG的核心代码只有几十行但组装上下文的顺序和筛选逻辑需要认真设计。我在项目里的实现是用户提问进来先用同一个嵌入式模型把问题转成向量在向量数据库中做余弦相似度检索取出TopK个候选块。这里K的取值是个经验活一般默认取4到6个K越大回答越全面但上下文消耗也越大、模型越容易捡到无关内容K太小又可能漏答案。取出候选块以后我不会直接把原始块倒进Prompt而是做一次重排——可以用一个匹配分数排序也可以用更轻量的规则比如优先选择标题层级更高的块、优先选择包含较多核心关键词的块。在Prompt的组装顺序上我采用的固定格式是系统指令 → 本次任务说明 → 检索到的资料片段 → 用户问题 → 输出格式约束。有个细节检索到的资料片段在Prompt里要用清晰的边界标志括起来比如 ... 并且明确告诉模型只有被 包裹的内容才是事实依据。这样能减少模型自由发挥的空间显著降低回答里混入常识性幻觉的概率。检索效果不理想的时候我第一反应通常不是调模型而是先看切块有没有问题。实测下来检索质量问题的根源七八成都在切块不合理只有两三成是嵌入式模型选型不对。所以查问题的时候先切块、再向量、后提示词这个顺序基本不会错。3.5 输出校验与不知道的兜底策略代码里最后一个环节是用户直接面对的部分也是决定产品质感的部分。我的后置校验逻辑是这样写的解析模型的原始输出要求模型在输出时给出一段JSON格式的结果包含answer和source_ids两个字段解析失败就触发一次自动重试把错误信息回传给模型让它重新生成一次。检查answer字段的长度如果模型输出的是一堆对不起我无法回答但检索结果明显包含相关信息就说明可能是Prompt里资料格式出了问题而不是真的没答案。做一个疑似幻觉检测把answer里出现的名词短语与检索块里的名词短语做一次粗粒度的集合比对。如果answer里有一半以上名词在检索块里完全找不到就判定为有幻觉风险强制改成根据当前资料暂时无法确认该信息。这一套兜底策略是我在所有知识类项目里都会复用的安全网。它不能做到100%拦截幻觉但能把明明没有依据还一本正经地编答案这类问题压到非常低的概率对这个项目来说已经够用。到这里这个本地知识库问答机器人才算真正从零走到了可以交付的状态。整个路径下来你会发现技术栈本身并不复杂真正花时间的是那些模型之外的工程细节切块切得合不合理、上下文够不够干净、校验兜不兜得住。4. 从单轮到多轮把问答机器人升级成Agent工具链知识库问答机器人是个很好的起点但它本质上是单轮问答被动响应的形态。如果你想让AI系统从回答问题进化为帮人完成任务就得进入Agent工程的领域。这也是整个AI工程里目前最受关注、演进最快的方向。4.1 什么是Agent从生成文本到规划并行动用一句最直白的话概括传统模型调用是你问一句我答一句Agent则是你给一个目标我自己拆解步骤、调用工具、检查结果、动态调整最后把任务交付给你。一个标准的Agent循环大致是接收用户的目标描述大模型基于当前状态做规划决定下一步该调什么工具、或者该直接回答如果选择调工具就输出一个结构化的工具调用请求代码层执行工具把结果作为新的观察信息反馈给模型重复2到4步直到模型认为任务完成、或者触发了我们设好的循环上限。这个思维链行动链的组合方式让模型第一次具备了闭环执行的能力。你可以让Agent帮你去查天气然后安排行程、去数据库查订单然后给出汇总报表、去抓取网页信息然后整理成对比表格——前提是你在工具层把这些能力都投射给它。4.2 工具层设计Agent的能力边界靠工具清单定义Agent的能力边界不是由模型决定的而是由你提供的工具清单决定的。一个没有工具的Agent本质上还是聊天机器人给它加了几个好工具它才会表现出能干活的样子。在设计工具清单时我总结出了几条原则粒度适中一个工具对应一个完整的子任务比如query_order_info作为一个工具就不要拆成connect_db和parse_result这种细碎步骤。粒度过细会让模型规划时无所适从粒度过粗又会让单个工具无法复用。每个工具都带使用说明工具名称、参数Schema是给模型看的说明书。我在Schema的description字段里会写清楚这个工具做什么、什么情况下调用、参数怎么从用户语句里提取、返回格式长什么样。说明写得越具体模型调用的准确率越高。工具结果必须结构化反馈无论工具内部做什么返回给模型的结果我用统一的JSON包裹(success: true/false, data: ..., error: ...)。这个格式让模型能以一个非常稳定的心智模型去理解刚才发生了什么从而做出更合理的下一步决策。还有个重要细节工具执行的超时与异常处理。Agent调工具的时候如果工具本身卡死了、或者抛了异常你不能让模型干等。正确的做法是给每个工具调用包一层超时控制超时后返回一个工具超时失败请换个策略或者如实告诉用户当前无法完成的结果让模型有机会重新规划而不是整条Agent链路瘫掉。4.3 状态记忆Agent做一半忘了前面说过什么怎么办Agent与普通聊天的不同在于它可能要执行多步工具调用、收集中间结果。为此你需要一套状态管理机制来维护会话上下文任务上下文。我的做法是维护一个内存中的上下文对象包含三个部分系统指令始终固定声明Agent的角色和能力边界历史对话摘要用一个小模型对长对话做滚动摘要避免上下文无限膨胀任务执行轨迹记录每一步工具调用的输入输出摘要让Agent在后续步骤里可以回溯我之前查到了什么、还差什么没做。在实现上任务执行轨迹我限制最多保留最近10步的摘要超过的部分只保留关键结论比如已经查到了某个订单号的金额但丢弃中间的计算过程。这套设计在长任务场景下效果显著既保住了核心状态又把上下文开销控制在了合理范围。4.4 Agent工程的底线迭代上限、成本上限、权限边界Agent能力强了以后危险也变大了。这里的危险不是指某种玄学风险而是实打实的工程问题Agent可能陷入无意义的循环白白消耗token、可能因为工具调用失败重试几十次、可能被用户诱导去操作它本不该触碰的权限。所以Agent上线前必须有硬性的底线约定迭代次数硬限制我习惯设为5到10次。超过这个次数还没有收敛Agent就必须停下来给用户一个当前问题复杂度超出了自动化范围的说明而不是继续无限循环。单轮成本与整体成本配额在调用模型API的时候我会在代码里按会话记录累计token消耗超过配额就切换到简化模式比如改用更小的模型或者关闭部分工具。权限最小化Agent能访问的工具范围永远只开放给完成当前任务必要的最小子集。比如一个只负责查天气的Agent不该有发邮件、删除文件的权限。这条原则越早落地后面越省心。我在实际项目里见过不少翻车案例几乎无一例外都出在这三条底线上不是循环跑飞了就是超额花钱了要不就是工具权限范围开得太大被用户钻了空子。Agent能力的天花板很高但地基一定先打好这三条。5. 避坑实录我在AI工程落地中踩过的六个实质性坑说再多方法论都不如真实踩坑经历来得有说服力。下面这六个坑是我在AI工程实践中真实遇到、并且花了真金白银和时间才爬出来的每一个都具有相当的普适性。5.1 坑一生成结果不稳定就归咎于模型不行很多人一看到模型输出时好时坏第一反应就是这个模型效果太差换个更大的模型。但你冷静想想同一套Prompt参数温度不一致、上下文拼接顺序有变化、不同用户的输入措辞差异很大这些因素都会造成输出波动。我的排查顺序是这样的先固定随机种子和把温度降到0或者0.2减少采样随机性然后把Prompt里的指令逻辑精简减少模糊表达接着检查上下文里塞进来的历史消息是不是有干扰噪声比如上一轮的无关问题结果混进了本轮最后才考虑换模型。实测下来八成以上的不稳定问题通过固定参数和清理上下文就能解决跟模型本身关系不大。5.2 坑二盲目堆砌上下文把模型窗口塞得满满当当RAG项目里有个常见误区既然模型支持很长的上下文那我就把所有检索到的资料全部塞进去越多越好。这个想法听起来合理做起来就有问题了。过长的上下文会带来三个副作用一是成本显著上升很多模型按token计费二是模型更容易迷失在中间对长上下文中段的资料关注度明显下降三是响应延迟变长用户等得越来越不耐烦。我做检索增强时的上下文体积控制原则是单次应答的检索上下文控制在2000到3000个token以内只放与当前问题最相关的TopK个切块。如果需要参考的资料确实很多就先用一个摘要模型把若干切块压成精简摘要再把摘要放进最终上下文。这个做法兼顾了信息完整性和模型注意力质量。5.3 坑三嵌入式模型与问答模型各自为战检索语义对不上知识库系统里有两个模型在协作一个是嵌入式模型负责把文本转向量做检索一个是问答模型负责根据上下文生成回答。如果两者来自不同体系、或者根本没有做选型匹配经常出现检索阶段找回来的块语义偏差大、答非所问的问题。选型经验嵌入式模型尽量选同一生态体系内匹配度高的比如BGE系列、M3E这类中文表现稳定的嵌入式模型在搭建前先手工挑十几条测试问题逐个验证检索到的Top3块是否真的对得上。我见过太多人跳过这十几条测试直接搭完整系统结果上线后检索质量一塌糊涂排查起来才发现是嵌入式模型的语义空间和问答模型不在一个频道上。5.4 坑四忽略输入格式校验用户一传脏数据系统就崩很多AI应用的输入是自由文本开发者就默认不需要做什么格式校验了。这绝对是错觉。用户可能上传一个损坏的PDF、粘贴一段超长字符串、输入带各种特殊符号的指令这些脏输入轻则让解析逻辑出错重则让Prompt注入变得可能。我现在的标准做法是所有用户输入进来都先走一遍清洗管线——限制最大长度、过滤控制字符、识别并拦截明显的Prompt注入模式比如ignore previous instructions这类黑名单词、对上传文件做类型和大小校验。这套清洗管线虽然看起来不AI但它决定了系统的稳定性上限。5.5 坑五上线以后没有监控出了问题只能瞎猜AI系统的输出是非确定性的即使温度设为0某些模型在多线程或不同硬件上也可能有细微差异所以上线后的监控比传统软件更应该细致。我给自己定的最小监控清单是每次模型调用的延迟、token消耗、返回状态码、以及输出结果的异常标记比如触发了几次格式重试、几次幻觉检测拦截。这些日志统一收集到一个本地文件或轻量级监控面板上出现明显指标恶化时能第一时间发现而不是等用户来投诉。在AI项目里没有监控基本等于全靠运气。5.6 坑六Prompt版本失控改着改着不知道自己改了什么Prompt的迭代速度比代码快得多但很少有人像管理代码一样管理Prompt。结果就是一个文件里积攒了几十版修改痕迹出了Bug不知道是谁改的、什么时候改的、为什么改。我的解决办法很土但很有效把每个Prompt版本单独存成带版本号的文件比如v1.2加了输出JSON约束、v1.3修了系统指令的语气冲突并且每次改动都记录在案。后面做评估回归的时候能精准知道哪个版本引入了哪个问题。6. 好工程靠反馈飞轮建立你自己的AI质量评估闭环最后说一个我认为AI工程和传统软件开发最不一样的地方传统软件的功能对不对可以写断言、跑单元测试AI系统的回答好不好却很难用简单的断言覆盖。正因为如此AI项目更需要一套反馈闭环用持续收集到的数据来驱动迭代。6.1 最小可行评估集50条样本起步覆盖典型与边界我每个项目都会从第一周就建立评估集先攒50条用户可能提出的问题给每条配上期望行为描述而不一定是标准答案。期望行为包括应该引用文档第X章的内容、应该拒绝回答并说明原因、应该调用某个工具而不是直接回答等。这样做的价值是以后每次改Prompt、换模型、调参数都先在评估集上跑一遍看整体通过率是上升还是下降。这套东西就是AI项目的单元测试。它不需要很复杂甚至都不用自动化手动跑也行但必须有。6.2 在线反馈收集让真实用户帮你打分评估集只能覆盖你知道会发生的情况真实用户总会给你惊喜。所以要主动做在线反馈收集在每条回复下面放一个有用/没用的按钮把用户反馈连同当时的输入、输出、检索上下文一并记录。每周看一次没用的数据按问题类型聚类就能非常精准地知道下周该优化什么。我自己看过一轮真实反馈之后发现用户反馈没用的原因里排名前列的往往不是模型回答本身的内容质量而是速度太慢、格式不友好、回答没有标明来源。这进一步印证了那句话AI工程的核心挑战很多时候不在模型而在模型之外的体验设计。6.3 用自动化裁判给质量打分人工评估有天花板为了让评估闭环能够更高效地运转我引入了模型即裁判的方案用一个相对便宜的模型通常和线上模型同系但更小按照一套评分标准给线上模型的回答打分比如相关性、忠实度、完整性各打1到5分。这里的关键是评分标准要写得很具体最好配示例。比如忠实度5分回答里的每一个关键事实都能在检索块中找到对应原文2分回答有明显的信息编造或与原文冲突。裁判模型会严格按这套标准打分虽然不能完全替代人工但作为回归手段够了。经过一段时间的数据沉淀你就会拥有一个完整的反馈飞轮真实用户反馈被归集成优化方向评估集负责验证每次改动裁判模型负责批量回归。三个轮子转起来以后AI系统就会进入越用越靠谱的正循环而不是上线即停滞。我自己在多个项目里跑通这套飞轮以后最大的体会是AI工程从零到一是冲锋从一到一百才是真正的修炼。前者考验你在模型能力层和工程整合层的基本功后者考验你有没有一套系统的方法去度量、反思、迭代。如果你也正准备从零做一个AI项目我建议你在动手写第一行代码前先花半天把这篇文章里那张五层能力地图在纸上画出来顺便写下你的第一版评估集。这个习惯会在未来几个月里帮你省下无数个当时要是早知道就好了的时刻。