我一直觉得，「ai-engineering-from-scratch」这句话最容易被误解的地方，就是那个"from scratch"。很多人以为这是指从数学公式开始推导神经网络，或者从反向传播手写一个Transformer。我第一次看到这类项目名时也差点被带偏，但真正进入这个领域之后才明白，AI工程化里的"从零开始"，指的是把一个只会点接口、调参数的人，培养成一个能把提示词、Agent、工作流、评测、成本治理全都跑通的人。换句话说，你缺的不是模型原理，而是一整套把模型用稳、用好、用出价值的工程方法。

这篇文章就是围绕这条主线展开的。我会先拆清"AI工程"到底包含哪些能力，再依次讲透提示词工程、Agent工具调用、工作流编排、评测回归和问题排查这五个核心环节，最后给出我认为最值得复制的实操套路。无论你是刚开始接触大模型API的开发者，还是已经在业务里接了好几个模型但总觉得不稳定、不可控的工程师，这篇文章都能给你一条可以直接照着走的路径。

1. 先把"AI工程"这件事拆清楚

1.1 AI工程不是"训练模型"，也不只是"调API"

行业里对"AI工程"这个词的使用一直很混乱。做算法的认为AI工程是把模型训练流程化、部署化；做后端的认为AI工程是调通一次接口然后把结果存进数据库；做产品的认为AI工程是找到一个合适的Prompt让机器人回答问题。这些说法都沾边，但都不完整。

以我的实践经验来看，在大模型时代，AI工程的核心已经迁移到了"模型行为工程"。你不必自己训练模型，你面对的是一个已经具备很强通用能力的黑盒，你的任务是想办法让这个黑盒在你设定的边界内稳定输出。这个过程包括了设计提示词、构造上下文、拆解任务、编排工具调用、设计Agent决策逻辑、建立评测集、控制成本和延迟。任何一个环节没做到位，最后交付出去的功能都会表现得"时灵时不灵"。

这就是为什么很多团队用大模型API做原型只需要一两天，但上生产环境却花了几个月。模型本身没变，变的只是工程化程度。理解了这一点，"from scratch"的含义就清楚了：不是从零学模型原理，而是从零建立一套驾驭模型能力的工程体系。

1.2 从零开始的四层能力地图

如果让我给一个新人画一张AI工程的学习地图，我会把它分成四个层次，这四个层次刚好对应一个AI功能从想法到稳定上线的完整链路。

第一层是提示词工程与上下文管理。这是最基础的地基，解决的是"单次调用如何拿到高质量结果"的问题。你不需要会写复杂的正则，也不需要懂特征工程，但你必须知道角色设定、任务描述、约束条件、输出格式、示例这些要素分别起什么作用，以及当模型输出不符合预期时，应该先调什么、后调什么。

第二层是Agent与工具编排。当任务足够复杂时，单次提示词调用搞不定，你需要让模型决定"自己接下来该做什么"。这就是Agent的雏形。你要学会定义工具、设计决策循环、处理模型返回的调用指令、把外部执行结果再喂回给模型。这一层解决的是"复杂任务如何拆解"的问题。

第三层是工作流与多模协作。单个Agent能做简单任务，但稳定性和成本都会随着复杂度下降。成熟的方案是把任务拆成固定节点，每个节点用不同模型或不同提示词来承担，再通过流程编排把它们串起来。这一层解决的是"如何平衡质量、成本、耗时"的问题。

第四层是评测、回归与观测。这是绝大多数团队最容易跳过的一层，也是AI工程和写脚本最大的区别所在。没有评测集，你就说不清楚修改提示词到底是变好了还是变差了；没有回归测试，你就不敢持续迭代。这一层解决的是"如何长期稳定地改进"的问题。

我建议所有人都按照这个顺序去搭建自己的能力，不要一上来就追最新的Agent框架。框架只是把第二层和第三层的常见模式封装好了，如果你不理解底层机制，出了问题连排查方向都没有。

1.3 为什么现在值得从头起步

有一个现象很有意思：两年前做大模型应用，大家最发愁的是"模型能力不够"，很多任务怎么调提示词都达不到可用水平。但现在模型能力已经上来了，通用对话、文本总结、代码生成、信息抽取这些任务，稍微用点心就能做到七八十分。于是瓶颈就转移到了工程侧，怎么控制输出稳定性，怎么接对业务系统，怎么对抗上下文爆炸，怎么让多个模型各司其职。

这个变化对新人反而是个机会。因为工程能力的积累不是靠读论文得来的，而是靠踩坑堆出来的。现在动手从零开始搭建自己的AI应用，不需要GPU，不需要标注团队，只需要一个模型API和一台普通电脑就能起步。等到你把这些工程问题都亲手处理过一遍，再去看那些热门的Agent框架、编排工具，就会觉得"这不过是我手写逻辑的封装版"。

2. 第一块地基：提示词工程与上下文管理

2.1 提示词为什么是"工程"：结构化拆解

提示词这个词听起来很玄，但本质上它就是你发给模型的输入。所谓工程化，指的是把这段输入从"随手写几句话"变成"有固定格式、可测试、可迭代的配置项"。

一个可维护的结构化提示词，我建议至少包含五个部分：角色定位、任务描述、约束条件、输出格式、示例。角色定位告诉模型用什么样的视角思考，任务描述说明要做什么，约束条件划定不可逾越的边界，输出格式保证结果可以被程序解析，示例则用来对齐你对输出样式的预期。

举个我实际用过的例子。我要让模型从用户反馈中提取问题类型和紧急程度，如果只写"请分析下面这段反馈"，结果多半是长篇大论，字段也乱七八糟。但用结构化提示词就不一样：

system_prompt = """ 你是一个用户反馈分类助手。 任务：从用户反馈中提取“问题类型”和“紧急程度”。 约束： - 问题类型只能从：功能异常、体验问题、性能问题、需求建议、其他 中选一个。 - 紧急程度只能是：高、中、低。 - 不要输出任何解释性文字，只输出JSON。 示例1： 用户说：这个页面一打开就闪退，什么也看不了 输出：{"problem_type": "功能异常", "urgency": "高"} 示例2： 用户说：如果能加个夜间模式就好了 输出：{"problem_type": "需求建议", "urgency": "低"} """

这样做的优势不是一次就能调到完美，而是可调整。比如模型总把"页面卡顿"归类为"体验问题"，但业务上希望归为"性能问题"，你只需要改示例或者在约束里加一句"卡顿、加载慢、响应时间长都属于性能问题"。这种调整是可预估的、可验证的，这就是工程性所在。

2.2 上下文管理：决定输出质量的关键

提示词写得再好，如果上下文管理混乱，照样拿不到理想结果。我把上下文管理拆成三件事：放什么进去、以什么顺序放、放多少。

先说放什么。模型并不知道你整个业务系统的状态，它能看到的只有你塞进上下文窗口里的内容。所以你需要主动决定哪些信息是最必要的。比如做客服问答，用户问"多久能发货"，你不需要把整个商品库塞进去，只需要把该订单的物流状态、预计发货时间这几个字段放进去就够了。多放无关信息反而会稀释模型的注意力。

其次是顺序。实践中有个很实用的经验：越重要的指令越要靠前放，系统提示词在最前面，然后是用户的任务描述，最后才是长文档和参考内容。如果有一段很长的资料需要模型参考，我会把"请阅读以下资料并回答问题"这句话放在资料前面，让模型带着任务去读资料，而不是先读完资料再收到任务。

最后是放多少。上下文窗口再大，也不能无限塞。一方面是成本问题，token是按量计费的；另一方面是"迷失在中间"效应，模型对长文本开头的指令和结尾的内容记忆更牢，中间部分容易忽略。我的经验是，如果单个文档超过四五千字，优先做切片或摘要，再决定是全部传入还是只传入相关片段。真正常用的上下文管理工具，不是向量数据库，而是"先判断需要什么，再决定传什么"这一套取舍逻辑。

2.3 提示词评测：怎么知道你的提示词改好了

很多人改提示词全凭感觉：换几个词，跑一次，看起来不错，就上线了。这在小项目里没问题，但一旦功能要长期迭代，没有评测就会陷入"改A修好了情况1，却坏了情况2"的窘境。

我的做法是给每个关键场景维护一个小型评测集。不需要很大，每个场景三四十条标准样例就够。每条样例包含输入和期望输出，期望输出可以是一个关键词、一个JSON结构，也可以是一段简要描述。每次修改提示词后，拿整个评测集跑一遍，统计通过率。通过率上升就保留，下降就回滚。

具体落地时可以写一个简单的评测脚本：

import json test_cases = [ {"input": "这个页面一打开就闪退", "expected_type": "功能异常", "expected_urgency": "高"}, {"input": "希望能增加深色模式", "expected_type": "需求建议", "expected_urgency": "低"}, # ... 继续补充 ] def run_evaluation(prompt_template): passed = 0 for case in test_cases: result = call_model(prompt_template, case["input"]) try: data = json.loads(result) if data["problem_type"] == case["expected_type"] and data["urgency"] == case["expected_urgency"]: passed += 1 except Exception: pass return passed / len(test_cases) print(run_evaluation(system_prompt)) # 把 system_prompt 当作参数传入

不需要用复杂的指标，准确率加上人工抽查就足够日常迭代。复杂到要用BLEU或者语义相似度来评估的，通常是内容生成类任务，那种场景我建议直接人工看二十条输出，比任何自动化指标都可靠。评测集不怕小，就怕没有。有了这个机制，你才敢放心大胆地去调提示词。

3. 第二块地基：Agent与工具调用的完整闭环

3.1 Agent的本质：模型负责决策，代码负责执行

市面上关于Agent的讨论非常多，动不动就是"规划记忆工具"。剥开这些概念，Agent的本质是一套循环：模型根据当前状态判断下一步应该做什么，如果判断需要调用工具，就输出一个结构化指令；代码收到指令后执行真实操作，并把结果返回给模型；模型再基于新信息继续判断，直到它认为自己可以给出最终答案。

这里面最关键的认知是：模型不执行操作，只做决策。查天气、发邮件、查数据库、调用别的API，这些都是代码干的活。模型做的只是决定"现在该调用哪个工具，参数是什么"。这样设计的好处是，工具能力可以无限扩展，模型只需要学会调用新工具即可，而工具的可靠性由代码来保证。

所以当我们说"搭建一个Agent"时，实际要做的事有两件：一是定义工具列表并写好每个工具的调用函数，二是写一个决策循环让模型在"调用工具"和"给出最终回答"之间做选择。理解了这个结构，你就掌握了所有Agent框架的核心逻辑。

3.2 从零写一个能自己调用工具的小管家

为了不纸上谈兵，我直接写一个最小可用的Agent决策循环。这个例子是让AI充当一个考勤小助手，它有两个工具：一个查请假余额，一个提交请假申请。模型需要根据用户的对话内容决定调用哪个工具、传什么参数。

import json # 第一步：定义工具及其执行函数 tools = [ { "name": "query_leave_balance", "description": "查询指定员工的剩余年假和病假余额", "parameters": {"employee_id": {"type": "string", "description": "员工ID"}}, "function": lambda args: f"员工 {args['employee_id']} 剩余年假5天，病假3天", }, { "name": "submit_leave_request", "description": "提交请假申请", "parameters": { "employee_id": {"type": "string"}, "start_date": {"type": "string"}, "end_date": {"type": "string"}, "leave_type": {"type": "string", "description": "年假或病假"} }, "function": lambda args: f"已提交 {args['leave_type']}，从 {args['start_date']} 到 {args['end_date']}，返回申请编号A-1001", }, ] # 第二步：把工具列表转成模型能理解的JSON描述 tool_descriptions = [ { "type": "function", "function": { "name": t["name"], "description": t["description"], "parameters": { "type": "object", "properties": {k: {"type": v["type"], "description": v["description"]} for k, v in t["parameters"].items()}, "required": list(t["parameters"].keys()), }, }, } for t in tools ] # 第三步：决策循环 def run_agent(user_message): messages = [ {"role": "system", "content": "你是考勤小助手，需要查余额或请假时调用对应工具。"}, {"role": "user", "content": user_message}, ] for step in range(5): # 限制最大步数，防止死循环 response = call_model_with_tools(messages, tool_descriptions) if response.get("tool_calls"): tool_call = response["tool_calls"][0] tool = next(t for t in tools if t["name"] == tool_call["name"]) result = tool["function"](tool_call["arguments"]) messages.append({"role": "assistant", "content": None, "tool_calls": [tool_call]}) messages.append({"role": "tool", "name": tool_call["name"], "content": result}) else: return response["content"] return "已达最大轮次，无法完成任务"

这里的核心就三件事：把工具信息交给模型、解析模型返回的调用意图、执行工具并把结果回传。各家大模型API对工具调用的格式略有不同，但整体就是这样一个"工具调用闭环"。当你把这个循环跑通之后，再去看LangChain之类的框架，就会发现它们做的不过是把这段逻辑包装得更通用而已。

3.3 工具设计：参数要简单，失败要能重试

Agent能不能稳定工作，一半取决于模型决策能力，另一半取决于工具设计。工具设计做得差，再强的模型也容易出错。

我对工具设计的第一个要求是参数尽量少、语义尽量明确。一个工具如果参数超过四五个，模型传参时很容易出错。比如查天气的工具，设计成只接受城市名加省份，就比接受一长串经纬度、时区、单位制要好得多。模型不是工程师，你给它越简单的接口，它犯错的概率越低。

第二个要求是工具必须容忍失败。实际运行中，查数据库可能超时，调外部API可能报错，给模型返回一段冷冰冰的异常栈只会让它更懵。正确做法是工具内部捕获异常，返回一段人话，比如"查询超时，请稍后重试"或"未找到对应订单，请确认订单号是否正确"。模型收到这种结果后可以自然地告诉用户，甚至主动试探另一个方案。

第三个要求是及时记录工具调用的原始返回。Agent做错了或者答非所问时，排查的第一步永远是把工具返回看了，再去看模型决策。如果工具本身就返回了错误数据，模型决策再正确也没用。所以我的每个工具函数里都会加一行日志，把入参和输出打出来，这样后面排查会省非常多的力气。

4. 把流程工程化：从单次调用到稳定工作流

4.1 工作流编排：把自由度换成可控性

单个Agent灵活，但不够稳。因为大模型的决策天然带有随机性，同一个问题这次走A路径，下次可能走B路径。业务系统不怕慢，最怕不可控。所以工程化的下一步，就是把已经确定的流程从Agent的"自由决策"中抽出来，固化成节点，让Agent只负责那些真正需要它发挥语言理解能力的地方。

我举一个实际场景：自动处理退款申请。如果全交给一个Agent，它的决策链条会很长，判断是否符合条件、计算退款金额、生成回复话术、确认是否升级人工，每一步都可能有偏差。但如果用工作流去编排，流程就变成：先用固定代码判断订单是否存在、是否在可退款时间窗内；再调用模型做退款原因分类；再按分类结果从配置表里取出对应处理策略；最后让模型基于策略生成一段回复文案。每一步的职责单一，出了问题只需要盯住出错的节点，而不是追着整个Agent问"你刚才为什么这么做"。

工作流的核心思路可以总结为一句话：确定性逻辑交给代码，开放性理解交给模型。凡是可以用规则判断的，就不要让模型来选；凡是必须依赖语义理解的，才交给模型。这个原则几乎适用于所有AI落地方案。

4.2 多AI协作：什么时候拆成多个模型各干一段

在搭工作流的过程中，你会面临一个问题：一个模型把所有活全干了，还是拆成多个模型各干一段？我的经验是，当任务的下游处理强依赖上游输出的结构时，就应该拆。

比如一个生成营销文案的系统，我把它拆成了三个节点：节点一用一个小参数模型做产品卖点抽取，输出结构化字段；节点二用一个大参数模型根据字段写文案；节点三再用一个小模型做敏感词检测。这么做的好处有三个：第一是省钱，结构化抽取任务简单，不需要每次都调最贵的模型；第二是质量可控，文案生成单独用一个强模型，不受抽取任务干扰；第三是便于升级，三个节点互相独立，某个模型更优了可以只替换一个节点。

多AI协作最忌讳的是让模型A的输出直接作为模型B的输入，也不做中间校验。模型A输出一个格式不完整的JSON，模型B再强也只能基于垃圾内容生成垃圾结果。所以我会在每个节点之间设一个格式校验层，如果输出不合法就重试一次，重试还不合法就走兜底逻辑。这层校验看似简单，却能大幅提升整个流水线的稳定性。

4.3 缓存与降级：省钱和保稳定是一回事

大模型API的计费模式决定了成本和稳定性是强相关的。调用越多，越容易遇到限流和超时，账单也越高。所以工程化程度高的团队，都会认真设计缓存和降级策略。

最常见的缓存是结果缓存：同样的输入参数，在有效期内直接返回上次的结果。适用场景很广，比如商品描述生成、FAQ问答、标签抽取，这些输入重复率高的功能，加了缓存之后成本能直接降一半以上。

更进阶一点的是语义缓存。所谓语义缓存，就是不是精确匹配相同输入，而是判断语义相似就复用缓存结果。比如用户问"你们几点上班"和"营业时间是什么时候"，其实是一个意思。实现语义缓存通常需要引入向量化比对，但这个投入在问答类场景里非常值。

降级策略也同样重要。我当时的做法是给每个关键AI功能设置分级降级：先试主力模型，超时就切备用模型，备用模型也不通就返回缓存中的历史结果，还不行就返回一条预设的兜底文案并记录告警。这套策略看起来简单，但真的能把AI功能的可用性从"看模型脸色"变成"满足生产需求"。用户不在乎你用哪个模型，在乎的是功能稳定可用。

5. 评测与回归：AI项目最容易被忽略的一环

5.1 没有评测，就没有优化

做了大半年AI应用之后，我形成一个非常强烈的观念：AI项目的优化闭环里，评测集是最重要的资产，比提示词重要得多。提示词可以随时重构，但评测集一旦建好就能长期复用。没有评测集，你所谓的优化只是在碰运气。

我建议从项目第一天就开始积累评测数据，哪怕只有十条。每一条都来自你真实需要处理的输入，不要凭空编。我做客服场景时，评测数据就直接从历史工单里抽，用户怎么说、期望怎么分类、期望什么样的回复，全部标准化成一条条测试用例。数量不用刻意追求，日常工作里遇到一个有趣的输入就加一条，三个月下来几百条就有了。

评测集的价值还体现在协作上。团队里任何一个人改了提示词或换了模型，跑一遍评测集就知道有没有变差。这就把"我感觉它变强了"这种主观判断，变成了"通过率从78%升到82%"这种客观数据。让人力聚焦在真正需要判断力的地方。

5.2 回归测试：每次改完都跑一遍

在传统软件开发里，回归测试是基本动作。但在AI开发里，大多数团队完全没有这个概念。我今天改了一个提示词去修某个坏例，三天后又改另一个提示词，回过来发现之前修好的问题又复现了。这种反复横跳是AI项目迭代效率低的最大根源。

我的解决方法很笨但有效：每次修改前记录当前评测集得分，修改后重新跑一遍，要求全量指标不低于之前水平才算通过。我甚至会在修改提示词时写一句变更说明，记录"这次改是为了解决什么问题、评测集得分变化是多少"。这样坚持了几个月后，手上已经有一份完整的迭代历史和一套经过多次验证的高质量提示词。这就叫工程积累。

回归测试的频率也有讲究。小改动可以一次一跑，大改动至少要在多个典型场景上都验证一遍。我见过最惨的案例是团队把对话系统的主提示词大改了，只拿几个demo用例测了就上线，几天后客服反馈说用户根本问不到答案，回去一查才发现导出答案的关键指令在新提示词里被删了。一次回归测试能避免的事故，远比它消耗的十分钟重要。

5.3 灰度与观测：真实流量下的评估

评测集再完善，也只能覆盖你预想到的情况。真实用户不会按照你的样例提问，所以灰度发布和线上观测就是评测的最后一环。

我习惯把AI功能按比例灰度：先切5%流量给新版本，观察返回时长、错误率、用户反馈这几个核心指标，没问题再逐步放大到30%、100%。如果过程中发现异常，立刻切回旧版本。这个流程做熟了之后，我甚至不太担心提示词改错上线，因为风险已经被隔离在小比例流量里。

线上观测需要明确的指标，而不是天天盯着日志。我会重点盯三个：调用失败率、平均响应时长、无答案率或拒答率。其中无答案率这类指标最能反映模型有没有"变傻"，因为失败和超时往往是基础设施问题，而无答案往往意味着提示词或上下文策略出了问题。把这些指标接进告警系统，异常时及时收到通知，AI项目才算真正做到可运营。

6. 常见问题与排查技巧实录

6.1 模型输出不稳定：先查温度，再查结构

模型对同一个问题给出不同答案，这是AI应用最常见的吐槽点。排查思路是有优先级的：第一件事就是看有没有把温度参数调成0或接近0。很多大模型API默认温度是0.7甚至更高，生成内容天然带随机性。如果业务场景追求确定性，比如分类、抽取、JSON输出，温度直接设0。如果内容生成类任务需要多样性，才保留一定温度。

第二件事是检查有没有要求结构化输出。让模型输出JSON，最好在提示词里给出明确的JSON Schema或者示例，并且开启API提供的JSON模式，如果支持的话。哪怕温度设了0，没有格式约束时模型偶尔也会输出多余的解释文字，导致解析失败。

如果温度和结构都设了还是不稳定，就要考虑是不是上下文里的干扰信息太多了。把不相关的历史对话、冗余背景从上下文里移除，往往比反复改提示词更有效。记住一个常识：你塞进上下文的每一个字符，都在参与影响模型的决策。

6.2 上下文太长：截断、摘要、向量库怎么选

上下文越来越长是Agent应用的常见病。早期症状是响应变慢、成本变高，晚期症状是模型开始忽略你放在最前面的指令，或者回答内容明显残缺。处理这个问题有三个层次。

第一层是截断。只保留最近N轮对话，或者只保留与当前任务最相关的文档段落。适合场景是对话历史管理和单篇文档处理。第二层是摘要。把早先的详细对话压缩成几句话，作为长期记忆放入上下文。适合场景是客服对话这类需要记住之前说了什么但又不需要逐字还原的。第三层才是向量检索，先把知识库切片向量化，每次根据用户问题召回最相关的几个片段，再把片段拼入上下文。适合场景是知识库问答。

我见过很多团队遇到上下文爆炸就直接上向量库，其实是过度设计。先试试截断和摘要，大部分场景都能解决。向量库也解决不了的问题，比如模型把关键指令忘了，那问题往往不在检索，而在你的指令没有放在正确的位置上。

6.3 Agent陷入死循环：最大轮次只是最后一道防线

Agent在调用工具时来回打转，这是每个做过Agent的人都会遇到的事。最直接的解法是设定最大轮次，跑满就强制结束并返回兜底结果。但这只是最后一道防线，不能只靠它。

更深层的原因通常是工具调用后的结果没有改变决策条件。比如Agent查了订单状态，发现订单还没发货，它不知道该不该再次查询，于是一遍又一遍地查。解决方法是每次工具调用之后，给模型补充一段"当前状态与下一步选择"的引导文字，比如"订单状态未变化时不需要重复查询，直接回复用户当前状态即可"。这就是所谓的决策提示。

另外要警惕一个隐藏坑：工具返回的结果里包含了过大的信息量，模型在下一步决策时被多余信息干扰，丧失了判断力。我习惯让工具返回精炼后的结果，必要信息保留，废话一律不加。工具返回的文本越清爽，Agent的决策越稳定。

6.4 成本失控：预算上线、模型分级、缓存三管齐下

AI项目的成本失控往往不是一夜之间发生的，而是每次加功能都多调用几次模型，日积月累账单就爆了。我会把成本治理当作独立的工程任务来对待。

首先，每一类模型调用都要有预算上限。技术团队应该清楚每个AI功能每月的成本预算是多少，一旦超过就要告警。其次，模型分级使用，简单任务绝不调用大参数模型。你在第五章提到的多AI协作，本身就是一种成本控制手段，处理一个需求建议的分类用大模型纯属浪费。最后，缓存必须落地。语义缓存和结果缓存双管齐下，重复性高的场景成本直接对半砍。

我把成本和稳定性放在一起讲，是因为很多团队在做降级策略时只考虑了稳定性，没用它来控成本。其实降级不只在兜底时起作用，日常也可以设置规则，比如高峰期自动把大模型流量切一部分到小模型或缓存，高峰期过了再切换回来。这样既稳定又省钱。

7. 一点个人经验

如果要把整个"ai-engineering-from-scratch"的路径压缩成一条建议，我会说：先别急着追框架，也别急着搭复杂的多Agent系统，而是老老实实做一个单场景的小功能，把提示词、评测集、代码逻辑全部自己手写一遍，坚持迭代两个月。做完这一步，你对AI工程的理解会超过大部分只见过封装框架的人。

最后分享一个我自己一直在用的小习惯：每次修改提示词或调整流程后，在注释里留下一行变更原因，并跑一遍评测集，把通过率的变化也记录下来。这个习惯不花多少时间，但几个月后回头看，你手里就有了一条清晰的优化轨迹，哪次改动真正有效、哪次改动是无用功一目了然。AI工程能力的成长，说到底就藏在这些看似琐碎却坚持重复的日常里。