1. 项目解读从零开始的AI工程到底在做什么先说一个我踩过的坑。刚接触AI编程的那段时间我一度以为写AI应用就是调大模型的API把用户问题丢进去再把模型的回复原样返回。这种套壳思路做出来的东西最多能在演示环境里跑通一旦面对真实用户、真实数据、真实业务约束立刻崩得稀里哗啦。后来我逐渐意识到从零开始做AI工程真正难的不是让模型说话而是让模型稳定地做对事、可被测试、能持续迭代。这个项目标题很有意思ai-engineering-from-scratch。它强调的不是某个具体的模型或框架而是一整套从需求拆解到系统落地的工程方法论。你可以把它理解为不依赖现成的AI全栈平台而是亲手把大模型、数据处理、Prompt设计、工具调用、质量评估、上线监控这几块拼成一个闭环。整个项目要解决的核心问题有三个怎么把模糊的业务需求转成模型能理解、能执行的任务怎么让模型在多次调用中保持稳定输出而不是偶尔抽风怎么评估模型效果做到上线前可量化、上线后可观测这套方法论适用于很多场景。比如你在做智能客服、做内容生成工具、做AI编程助手、做自动测试平台甚至只是想把大模型塞进一个已有的业务系统里都会碰到同一批问题。这篇文章我会按实际搭建项目的顺序把从零开始构建AI工程的关键环节逐个拆开讲包括模型选型、Prompt工程、Agent工具调用、测试评估、性能优化和成本控制。里面的所有内容都来自我的实操经验踩过的坑、试过的方案、验证过的参数我都会直接写出来你可以照着走也可以根据自己的业务做一些调整。2. 思路拆解AI工程不是写代码是编排智能在动手之前我先讲讲整个项目的顶层设计思路。传统软件工程的输入是明确的指令输出是可预期的结果。AI工程不一样模型是一个概率系统同样的输入可能产生不同的输出幻觉、漏答、格式错乱都是常态。所以AI工程的核心不是写代码让计算机执行而是设计一套机制让模型在概率输出中尽量逼近确定结果。2.1 从函数调用到能力编排的思维转换传统开发的思维是我定义一个函数输入A输出B函数的逻辑是固定的。而AI工程的基本单元是一个自然语言接口加一堆参数。举个例子你想做一个内容摘要功能传统做法是写一个抽取算法AI做法是写一段Prompt让模型总结。此时模型就像是一个极度聪明但偶尔走神的实习生你需要给他清晰的任务书、给出示例、限制输出格式、并在必要时让他调用外部工具来补充信息。这个思维转换直接影响工程实现方式。我见过不少从传统后端转过来的同学喜欢用if-else去判断模型的输出试图用规则穷举所有可能。这种做法在Demo阶段还能将就一旦输出形式稍微变化代码就变成一坨补丁。正确的做法是把模型当成一个推理引擎把业务规则放进Prompt和工具设计里让模型在约束下自行决策代码只负责组装和兜底。2.2 为什么上下文工程比模型参数更重要很多人一上来就问需要用多大的模型这个问题的答案其实是先算清楚你的上下文需求。模型能力再强如果上下文里塞的信息不够、排列混乱照样给出让人无语的回答。我个人的经验是在从零开始的项目里上下文工程也就是给模型提供什么材料、以什么顺序提供、如何筛选和截断往往决定了70%的效果剩下30%才轮到模型选型、采样参数和微调。上下文工程包含几个关键决策点系统提示词怎么设计、用户输入怎么清洗、外部检索到的知识怎么拼装、历史对话怎么压缩。每一条背后都有对应的坑。系统提示词写得太长会把注意力分散到无关细节写太短又约束不住格式历史对话直接全量塞进去很快就会撞上上下文窗口上限检索结果不经过提炼就拼进Prompt噪音会直接干扰推理。后面我会分别展开细说。2.3 四大核心模块理解、生成、验证、迭代我把整个AI工程拆成四个核心模块这也是我搭建项目时的骨架理解模块负责把原始输入转成模型需要的结构化指令包括意图识别、实体抽取、输入校验。生成模块负责调用模型完成任务包括Prompt组装、采样参数设置、工具调用触发。验证模块负责检查模型输出的正确性和合规性包括格式校验、逻辑校验、幻觉检测。迭代模块负责收集线上的真实表现形成数据集反哺Prompt和模型形成闭环。这个划分和传统软件的分层架构很像但每一层的内容都变了。理解模块不再是写正则和规则而是用模型做分类和抽取验证模块不再是断言输出而是用另一套模型或规则去交叉验证。只要这四个模块搭起来哪怕最开始非常简陋项目的骨架就已经成型。3. 从零起步搭建第一个可用的AI工程基础设施这部分是实操的开始。我会带你从环境准备开始逐步搭出一个最小可用的AI工程骨架。这个骨架可以直接用于后续的Agent开发、测试评估和迭代优化。3.1 模型选型别盲目追大先看任务复杂度模型选型是很多新人的第一个卡点。我的建议是从零开始做项目先别想着上几百B参数的大模型。对绝大多数任务来说7B到70B级别的开源模型或者中等规模的商业API模型已经够用。选型时主要看三件事推理能力下限、响应延迟、单次调用成本。我做过一个测试让一个70B模型和一个7B模型分别做同样一批分类和抽取任务在任务复杂度较低时两个模型的准确率差距不超过3%但7B模型的推理速度快了将近4倍成本可能只有前者的十分之一。只有在需要复杂推理、长链思考或多步工具调用的任务上大模型的优势才明显。所以正确做法是先把你最复杂的一批任务抽出来做基准测试用真实任务的实际效果来选型不要被参数数字迷惑。另外一个容易被忽略的点是上下文窗口长度。当前主流模型都支持8K到128K的上下文可窗口长不等于效果好。模型对长上下文中部信息的关注度会衰减尤其是需要精确引用某一段内容时放在上下文最前或最后的材料利用率最高。所以选型时不要只看最大窗口还要看模型在中间位置的信息召回表现这个得靠实测。3.2 第一个API调用背后的隐藏配置项当你拿到一个大模型API先别急着写业务逻辑把下面的基础配置逐一搞清楚。以OpenAI兼容接口为例一个典型的请求长这样from openai import OpenAI client OpenAI( api_key你的key, base_urlhttp://你的网关地址/v1 # 自建网关或兼容接口 ) resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是AI工程助手回答必须简洁使用列表输出。}, {role: user, content: 说明什么是上下文工程。} ], temperature0.3, max_tokens500, top_p0.9, streamFalse )这里我最想强调temperature。它控制的是采样随机性取值0到2之间0表示近乎贪心解码输出最稳定1左右表示有一定多样性。做工程化应用时除了内容创作类任务我几乎一律把temperature放在0.2以下。很多奇怪的问题比如同一句话问两遍答案不一样、格式偶尔跳变根源就在于温度太高。如果你需要模型输出JSON结构temperature建议设为0同时配合response_format参数强制JSON模式。max_tokens也需要仔细掂量。它限制的是模型生成的最大Token数包含所有回复内容。如果设得太小回答会被截断导致JSON不完整设得太大在坏输入上会浪费时间和费用。我习惯先统计业务输出的平均Token数然后乘以1.5作为默认值并单独配置一个上限用来拦截异常生成。还有一个很实用的参数叫stop可以让模型在遇到指定字符串时停止生成。比如你希望模型输出完JSON就结束可以在stop里配置\n或者配置一个结束标记词。这样能有效防止模型在代码块结尾后追加无关内容。3.3 网关与缓存工程化的第一道基础设施如果你的项目只做少量调用直接连官方API就够了。但从零开始做工程我强烈建议在API和你之间加一层网关。网关能帮你做三件事统一管理多个厂商的模型Key、记录所有请求和响应的日志、实现缓存和限流。缓存的收益在AI工程里被严重低估。我见过一个文档问答系统上线后50%以上的请求都在问相近的问题加了语义缓存之后这部分请求直接从大模型改走了缓存响应时间从2秒降到100毫秒月度成本下降了40%。实现方式也不复杂用向量数据库存问题的语义向量新请求先算相似度命中阈值比如余弦相似度大于0.92就直接返回缓存结果。代价是缓存命中率需要不断调整阈值太松会返回答非所问的结果太紧又起不到效果这个后面会细说。日志比缓存更重要。没有日志你根本不知道模型在线上做了什么、为什么出错。我习惯在网关照单记录每一次请求的完整信息输入内容、系统提示词版本、采样参数、输出内容、耗时、Token数、成本。这些日志是后面做问题排查和Prompt迭代的唯一数据来源。4. Prompt Engineering实战把需求翻译成模型能执行的指令很多人把Prompt Engineering当成写几句好听的话这是最大的误区。Prompt本质上是给模型的一份任务说明书它直接影响模型的行为边界和输出质量。我在这里分享一套从零到可用的Prompt编写框架。4.1 系统提示词的结构化写法我写系统提示词时会分五个区块每个区块用清晰的标记分隔角色与目标告诉模型你是什么、要完成什么任务例如你是一个内容审核助手负责判断用户评论是否包含广告信息。输入说明描述你会收到什么格式的数据字段含义是什么。处理流程用编号列出模型应该遵循的步骤例如第一步提取文本中的所有联系方式第二步判断是否属于广告第三步输出JSON结果。输出格式用严格的Schema和示例定义输出结构包括字段名、类型、枚举值。禁忌与兜底说明哪些情况不能做、遇到异常怎么处理例如如果无法判断输出unknown不要猜测。这里最关键的一点是输出格式的示例不能随便写。模型会模仿示例的措辞和结构你的示例必须覆盖边界情况。比如你想让模型输出JSON示例里就要给一个字段缺失的样例告诉模型这种情况该怎么处理。事实证明给一个反例比给十个正例更能降低格式错误率。4.2 少样本示例与上下文注入的技巧少样本few-shot是提升输出稳定性的利器。对于分类、抽取、格式转换这类任务给3到5个输入输出对模型的表现能有质的飞跃。但少样本不是随便找几个例子塞进去必须遵循三个原则示例与真实输入分布一致。如果你的业务里用户输入80%是短句20%是长段落示例也要按这个比例来。示例要覆盖边界情况。比如抽取电话号码要给一个没有电话的误例句让模型学会输出空结果。示例的标签必须是确定性的。如果你给的示例本身存在歧义模型会学到这种歧义。上下文注入则是指把外部数据动态拼进Prompt。这里的大坑是塞得越多越乱。模型对长文本中的关键信息有注意力衰减我实测过同一份材料放在上下文开头和放在中间模型对其中信息的引用准确率差将近20个百分点。所以动态注入内容时要么放最前面要么放最后面并用分隔符明确标识以下是参考资料。4.3 结构化输出让模型吐JSON的可靠姿势工程化应用里让模型输出JSON几乎成了刚需。模型直接输出的JSON经常有多余字符、换行、尾逗号、字段名跑偏等问题。要解决这个我有四层保险第一层在系统提示词里写明只输出JSON不要任何解释。第二层用API自带的response_format{type: json_object}强制JSON模式。第三层在Prompt里给出JSON Schema示例把字段名和类型写死。第四层在代码里做JSON解析兜底解析失败时自动重试一次并把错误信息回传给模型让它修正。这四层叠下来我在生产环境里的JSON解析成功率能到99.8%以上。那0.2%的失败通常是模型“想太多”导致的此时重试机制就能覆盖。另外补充一个技巧如果你需要模型输出非常复杂的嵌套JSON可以拆成多次调用每次只生成一部分然后用代码组装比让模型一次生成整块更可靠。4.4 Prompt版本管理与A/B测试Prompt会频繁变更如果不做版本管理你会陷入不知道改了哪句话导致效果变差的泥潭。我的做法是把每个Prompt写成一个独立文件存进Git仓库文件名包含版本号。系统提示词里的核心指令尽量参数化比如用{{template}}代替具体的格式描述这样不同版本之间可以动态切换。线上如果要调整Prompt一定先做A/B测试。把流量分为对照组和实验组分别使用旧版和新版Prompt用你定义的核心指标准确率、格式合法率、用户满意度来对比评估。千万不能凭一两个案例的感觉就拍板上线模型的表现在个别案例上欺骗性很强必须看统计结果。5. AI Agent实践从单次问答到多工具自主协作说到热词里的AI Agent和“多AI协作”这块是AI工程从玩具走向真工具的分水岭。单次问答只能解决给我一个回答的问题而Agent可以解决帮我把一件事做完的问题。5.1 Agent的核心循环规划、调用、观察、再规划我实现的第一个Agent并不复杂本质是一个循环接收用户目标由大模型拆解成若干子任务并决定调用哪个工具。执行工具调用拿到工具返回的结构化结果。把工具结果和原始目标一起交给模型模型判断是否达成目标。如果没达成继续规划下一步直到完成或超过最大轮数。这个模式常被称为ReActReasoning Acting。代码实现比你想象的简单核心就是一个while循环循环里反复调大模型直到出现任务完成信号。难点在于工具的定义和错误处理。每个工具都要有一个清晰的名字、描述、输入参数Schema模型靠描述来决定何时调用哪个工具。所以工具描述写得越准确Agent越不容易瞎调用。5.2 工具注册与调用规范我在项目里把工具按读和写两类分开。读工具如search_docs、fetch_webpage、query_database它们不产生副作用写工具如send_email、create_issue、update_record它们会改变外部状态。写工具必须加上人类确认环节不能让Agent直接执行不可逆操作否则一旦模型误判就完蛋。工具输入参数也需要做严格校验。模型生成的可能是不合法的参数比如日期格式错误、数字超出范围。我在工具调用前会加一层参数校验如果校验失败会把错误信息作为观察反馈给模型让它重新生成。这种失败反馈进上下文的机制是Agent稳定性的关键。多工具协作则靠工具上下文来串联。每个工具返回的结果都要带有元信息比如数据来源、时间戳、置信度。这样模型能判断哪些信息是实时的、哪些是静态的避免把旧数据当新数据用。5.3 多AI协作的几种落地形态热词里提到多AI协作这其实有几种不同的工程形态。第一种是主持人-专家模式一个主Agent负责拆解任务把子任务分发给多个专门的小模型再把结果汇总。第二种是流水线模式多个模型按顺序处理同一个任务流比如先做意图识别再做信息抽取最后做答案生成。第三种是评审模式一个模型生成内容另一个模型负责审核和修改。我实际用得最多的是主持人-专家模式。好处是每个专家模型可以针对性优化比如做内容审核的专家只关注安全过滤做摘要的专家只关注压缩方法各自的Prompt可以独立迭代、独立测试。代价是多模型之间的通信需要设计好协议不然信息在传递中会丢失或扭曲。一个真实的例子是我做过一个专利相关辅助链接的场景需要从大量文档中提取技术特征、判断新颖性、生成对比分析。如果用一个大模型一把梭输出内容又长又乱跑一次还特别贵。后来改成三个专家协作第一个负责从文档里做命名实体识别第二个做技术特征对比第三个做结论生成。每个环节用相对小的模型速度和成本都大幅下降最终输出质量反而更高因为每个模型的任务边界清晰了。5.4 Agent防失控最大轮数、预算限制与兜底策略Agent最大的风险是失控。模型可能陷入无限循环、反复调用同一个工具、或者在错误的方向上越走越远。我至少会设置四道防线最大循环轮数比如最多8轮超过后强制停止并返回当前进度。工具调用次数限制每个工具单次任务最多调用N次防止死循环。成本预算累计Token数或费用达到上限后自动终止。兜底响应当Agent无法完成任务时明确告诉用户我没能完成原因是...而不是假装成功。这四道防线缺一不可。我见过一个没有预算控制的Agent在测试时因为模型连续调用检索工具几分钟内花掉了正常情况下一个月的Token预算。从那以后所有Agent项目的成本控制都是第一优先级。6. 质量保障AI测试、评估与防幻觉AI工程上线后最重要的问题就是我怎么知道它在真实场景里表现如何。传统的软件测试思路在这里只能覆盖一部分AI测试需要一套新的评估体系。6.1 三类测试单元测试、回归测试、线上监控我把AI测试分成三类。第一类是单元测试针对单个Prompt或单个工具用固定数据集验证输出是否稳定、格式是否正确、关键逻辑是否成立。这里的测试断言不能太严格比如不能要求文本逐字相等而是用规则模型判断结合的方式评估。第二类是回归测试。每次修改Prompt、更换模型、调整采样参数后都要跑一遍固定的评估数据集看效果有没有回退。这个数据集必须是业务里的真实样本不能是网上随便找的问答对。我在项目里会维护一个黄金数据集包含500到2000条典型输入、期望输出和可选的评分标准。第三类是线上监控。上线后所有的模型调用都要记录并对结果做实时采样评估。监控的核心指标包括错误率、超时率、格式非法率、用户反馈率、平均延迟、成本。其中错误率不能只看请求失败更要看成功请求但回答错误后者需要额外的评估机制。6.2 幻觉检测比想象中更需要工程化热词里无限制AI之类的东西我不会碰但幻觉确实是AI工程绕不开的话题。模型一本正经地编造事实对很多业务来说是致命的。检测幻觉的方法有几条路自带引用强制模型在回答中给出信息来源没有来源的内容要标注为推测。交叉验证用一个评估模型去判断回答中的关键事实是否与检索到的资料吻合。结构化约束对于知识类任务先用检索拿回候选片段再让模型在片段范围内生成超范围的内容直接拦截。高置信度阈值对于不确定的判断让模型输出unknown而不是硬猜。在内容生成类场景我还会加一道事实一致性检查工序。生成完毕后把关键实体、数字、时间戳提取出来与原文比对不一致的地方自动打回重写。这套工序的成本不低但对于准确性要求高的业务比如金融、医疗、专利分析省不掉。6.3 评估指标设计别让准确率骗了你AI任务的评估指标要因任务而异。分类任务可以看准确率和召回率但生成式任务要更复杂。我常用以下几个指标组合格式合法率输出能否通过Schema校验。关键信息完整率期望出现的重点信息是否出现。事实错误率人工抽检中事实性错误的比例。重复率与冗余度生成内容是否有大量重复。用户最终满意度结合点赞、点踩、复购等隐性反馈。关键是要建立一套低人工成本的评估流程。纯靠人看一天根本看不完多少条。我的做法是把评估分成两层第一层用规则和模型自动打分筛掉明显不合格的第二层只对自动打分处于模糊区间的那部分请人来做判断。这样人工成本能降一个量级评估的覆盖面反而更大。7. 实用案例AI编程助手与AI测试开发落地全流程用上面的方法论我实际操作过一个AI编程助手和AI测试开发工具这里拆成一个典型案例来讲让你看到各个环节是怎么串起来的。7.1 需求定义从写代码到改代码项目目标是做一个AI编程助手能帮开发者完成代码生成、解释、重构和单元测试生成。一开始我们想做得很大后来砍到只剩三个核心功能根据自然语言生成函数、解释一段现有代码、生成指定函数的单元测试。就这么三个功能用了三周从零到可用。代码生成功能的核心是Prompt和上下文设计。我们给模型输入函数签名、依赖列表、相关代码片段和风格指南。这里有个经验模型输出的代码质量高度依赖于附近的相关代码如果能把调用关系最近的上游代码也塞进上下文里生成的函数能更好地保持接口一致。解释代码功能则是另一回事。我们把目标代码按函数切成一小块并附带静态分析得到的结构信息比如函数调用图、变量定义位置。模型基于这些信息生成解释文本避免它在长代码里迷失。单元测试生成是最难的。模型生成的测试经常跑不过因为缺少mock的上下文。我们后来换了个思路先把测试代码生成和运行测试解耦让Agent先调用工具找出被测函数的依赖情况再让它生成带mock的测试最后自动运行并反馈测试结果。这一个改动让测试用例的运行通过率提升了接近一倍。7.2 AI测试开发的闭环从生成到回归做完AI编程助手后我又把同一套思路复制到了测试平台上。核心是一个测试直觉的Agent给定被测接口的OpenAPI描述和代码片段Agent自动生成测试用例、执行测试、收集失败信息、分析失败原因、修正测试再重新执行。这个闭环里的关键点在于失败信息不能只是贴一个堆栈而是要把接口返回的实际响应和预期响应的差异结构化地反馈给模型。这样模型才知道要修正断言还是修正入参。我们设计了一个反馈模板把接口名、入参、出参、断言行、错误类型、堆栈摘要拼进上下文再让模型给出一份修改后的完整测试。这个方案做完后测试生成的直接可用率达到了80%以上剩下的20%多数是环境依赖问题跟模型能力关系不大。7.3 AI建站与智能投流的工程化尝试热词里出现AI建站和AI投流我也简要提一下。这些场景本质上都是内容生成渲染的流水线。AI建站的核心是让模型生成结构化页面数据组件树、文案、样式变量然后由前端框架渲染而不是让模型直接吐HTML。AI投流则更依赖数据分析和自动决策模型负责生成投放文案、预测转化率、自动调整预算分配但每一步都要有明确的约束和人工回退机制。这些项目我都是按同样的骨架做的理解业务输入组装Prompt调用模型验证输出再对接执行引擎。底层方法论完全一致区别只在上层业务封装。这也是我推荐大家从零搭建自己的AI工程而不是买一篮子现成方案的核心原因——只有亲手把这几层搭起来你才真正拥有了一套可复用的智能业务能力。8. 性能调优与成本控制让AI工程跑得更快更便宜AI工程跑通只是第一步跑得稳定、快、便宜才是能不能真正落地为产品的关键。这一节我讲讲性能与成本方面最实用的几条经验。8.1 降低延迟的三个有效手段第一个手段是流式输出。把stream设为true让模型边生成边返回结果。用户感知的首字延迟会大幅降低尤其是在回答比较长的时候体验差距非常明显。第二个手段是模型分级。把请求按难度分级简单请求走小模型复杂请求走大模型。我做一个内容审核工具时先用规则和关键词过滤掉60%的明显内容剩下模糊的用7B模型判断仍然无法确定的再送70B模型。这个策略在保证准确率的前提下把平均单次调用成本降到了原来的三分之一。第三个手段是并发与超时管理。API调用是IO密集型操作用异步客户端可以大幅提升吞吐。我习惯用asyncio.Semaphore控制并发数避免瞬间把API打爆。超时时间也一定要设置我见过一个请求因为模型异常生成硬生生跑了3分钟才返回用户早就关掉了页面。把超时设为30秒超时后立即返回一个兜底提示用户体验远好于无限等待。8.2 Token成本核算与控制AI工程的成本大头是Token费用。控制成本最有效的方法是减少发送给模型的无效内容。我见过很多项目的Prompt里塞了一堆废话比如请务必认真回答如果不知道就说不知道——这些内容对输出质量毫无帮助但每个Token都要花钱。更系统的做法是给每个任务设置Token预算。比如一个摘要任务规定系统提示词输入输出总共不能超过4000 Token超过这个预算就触发降级策略要么截断输入要么换小模型要么拒绝处理。这样能在源头控制成本上限。还有一个技巧是大量使用缓存。上一节提到的语义缓存是对效果最明显的。另外KV Cache也在大模型服务中常被使用如果模型同一段Prompt被大量重复调用服务端可以复用缓存但这通常需要自建服务端才能利用上API模式下能做的还是应用层缓存。8.3 模型量化与本地部署的判断标准对于开源模型量化是降低推理成本的一大利器。4bit量化的70B模型显存占用可能从140GB降到40GB左右单卡就能跑起来推理速度明显提升效果损失通常在可接受范围内。我做过的分类和抽取任务4bit和16bit的准确率差异不超过1.5%代价完全值得。但量化不是没有代价。对于数学推理、代码生成这类需要精确计算的任务量化可能会导致输出质量下降。所以是否量化还是要拿真实任务做评测。我的判断标准是如果你的任务以自然语言理解和生成主量化可以大胆用如果涉及复杂逻辑推理和精确数值建议保留更高精度的模型优先考虑用小模型加量化来分担简单任务。9. 问题排查与避坑指南线上AI系统常见故障实录最后这部分我把实际运营AI系统时最常遇到的故障和排查思路列成一个速查表每条都是我或者我身边团队真的踩过的坑。现象可能原因排查思路与解决方案同一输入多次调用结果不一致temperature过高或模型版本不一致将temperature降到0.2以下核对网关日志里的模型名和参数输出JSON解析经常失败模型被max_tokens截断或输出里带有多余文本调大max_tokens启用强制JSON模式增加解析失败自动重试回答总是漏掉关键信息上下文材料过多关键信息被稀释精简上下文把关键信息放到Prompt开头或结尾用分隔符强调Agent陷入重复工具调用工具描述不清晰或模型没有收到工具返回的完整结果检查工具描述和返回格式建议把返回结果做结构化摘要线上延迟突然飙升并发过高或模型服务端负载高加熔断和降级使用流式输出检查是否触发了服务端限流成本失控没有设置单次预算或缓存命中率太低为每次请求设置Token上限优化缓存阈值日志里加上累计成本监控模型幻觉严重没有提供知识来源或Context里冲突信息太多强制要求引用来源使用检索片段作为生成范围增加交叉验证模型Prompt小改后效果大幅波动改动影响了模型的注意力分布坚持版本管理每次只改一个变量做A/B测试再上线我再额外说一个自己踩过的很隐蔽的坑系统提示词里的标点符号。有一版Prompt我为了美观把列表里的句号换成了分号结果模型输出格式出现了大面积偏移。排查了很久才发现模型对示例格式的模仿非常细致任何一个标点变化都可能被当成格式规范去跟随。所以Prompt里的任何字符改动都算一次版本变更都要走回归测试。另一个坑是历史对话的累积。做聊天类应用时直接把多轮对话全部拼进Prompt很快上下文就爆了而且模型容易被早期对话带偏。我的做法是维护一个滚动摘要每过几轮就用模型把前面的对话压缩成摘要然后用摘要最近几轮原文作为新的上下文。这样既保留了关键信息又控制了上下文长度。10. 从零开始的个人践行清单如果你准备从零开始搭建自己的AI工程我最后给你一份可以直接照着做的行动清单。第一周定义一个明确的小任务比如把一篇文章自动整理成结构化摘要。准备10条真实业务样本接一个API模型把最简单的Prompt跑通记录输出效果和成本。第二周搭建一个最小网关记录请求日志。设计系统提示词结构加入少样本示例尝试让输出变成JSON。跑一遍20条数据的回归集把格式合法率和关键信息完整率记录成基线。第三周引入工具调用做一个简单Agent比如根据文档回答问题。加上检索工具让Agent能翻文档设置最大轮数和预算限制。收集一些失败案例分析是检索出问题了还是Prompt出问题了。第四周加入自动化评估用规则模型评判的方式评估输出质量。建立回归测试流水线每次改动Prompt或者换模型自动跑一遍基线集。开始记录线上日志做成本和使用量的日报监控。这套清单按部就班走下来差不多一个月你就能拥有一个可观测、可评估、可迭代的最小AI工程而不是一个只能演示的API套壳。项目的名字叫从零开始但真正从零开始的价值是让你把AI工程的每个环节都握在自己手里。以后无论模型怎么升级、框架怎么变化这套底层的拆解和评估能力都不会过时。