AI 工程化的主线：把概率模型放进反馈系统

一、单模型能力不是终点

2017 年 Google 发表 Transformer 论文时，没有人能预料到，把参数量推到千亿级，并叠加更大规模的数据和训练算力后，一个简单的 next-token predictor 会表现出某种类似"理解"的能力。AlexNet 在 2012 年 ImageNet LSVRC 上把 top-5 error 降到约 15.3%（领先第二名 10 个百分点）已经让学界震惊¹，但那是视觉分类——规则明确、有标准答案。而当 ChatGPT 能聊哲学、写诗、编代码时，人们开始用"涌现"这个词来解释：某些能力似乎不是被显式训练的，而是在到达某个规模后自己"冒出来"的。

但即便把这些能力称为"涌现"，也不意味着模型获得了人类意义上的理解。它至少表现为一种随规模变化出现的能力跃迁，但这种跃迁不能直接作为可靠性的基础。在高层抽象上，整个模型家族的底层原理一致：token 化 → embedding → 自注意力（Q/K/V）→ FFN → 残差流 → next-token prediction。它们是超级模式匹配器，把一切信息转化为数字，在海量数据中寻找统计模式，再用模式预测输出²。

“聪明"和"犯傻"来自同一个机制——模型优化的是文字序列的统计可能性，不是事实准确性。这最直观的表现就是幻觉：2023 年 Mata v. Avianca 案中，律师提交的法律文书引用了 ChatGPT 编造的六个不存在的判例——模型不是故意撒谎，它只是在统计层面认为"这个引用格式在类似上下文中是合理的下一个 token”。幻觉不是普通意义上的实现 bug，而是 next-token prediction 在缺乏外部事实核查时自然会暴露出的能力边界³。

这条能力边界推出一个核心判断：单模型能力不是终点。LLM 是概率性的——它最大化的是 token 序列的统计似然，不是事实正确。概率分布集中于某个输出只意味着"在训练语料中这类序列很常见"，不等于"这个输出是正确的"——模型可以高度确定性地输出错误内容。因此把它从"酷 demo"变成"可靠生产力"的，不是更强的模型权重，而是模型外面那一层层核查和工程约束。

下面按三层展开：推理系统层（上下文输入 + 循环验证）解决运行时输入与纠错，训练学习层解决奖励如何写回模型能力，组织反馈层解决失败如何变成长期可复用约束。在进入三层之前，先用代码突破这个案例引入一组跨层的关键概念。

P.S. 本文讨论的是语言模型的工程化，不涉及推荐系统、风控模型、缺陷检测等传统工业模型——那些是为特定任务从头训练的专用模型（GBDT、CNN、LSTM 等），和 LLM 不是同一个赛道。

二、为什么代码先突破

大模型在生产力场景中最早在代码领域取得突破性成功，不是偶然。代码同时满足了几个对当前模型架构极其友好的条件。

• 可自动验证：编译器、测试框架和 linter 是确定性的裁判——代码对不对，运行一下就知道。这种高密度、高质量、零人力成本的可验证奖励信号，使代码成为强化学习（RL）的天然训练场。和 SFT 的行为克隆不同，在奖励可靠、任务可重放、反馈足够密集的环境中，RL 更有机会让模型探索出自纠错和多步验证策略⁴。
• 代码验证是硬验证：在验证器定义的范围内，通过就是通过，报错就是报错。对比很多其他任务的"软验证"——LLM-as-Judge 评分、用户满意度打分、产品指标——硬验证的成本和可攻击性完全不同。但测试通过不等于需求正确，验证器覆盖不到的需求理解、架构取舍和长期可维护性仍然需要额外判断。这个区分贯穿后续的所有工程选择：能用硬验证就别靠软验证，需要软验证的地方必须建多层防御。
• 高度结构化：代码语法可被确定性解析，控制流和数据流结构比自然语言稳定，重复模式极长。不是说代码没有模糊性——需求、API 契约、并发行为都可能高度含糊——但代码比自然语言更容易被形式化验证和搜索。
• 数据有筛选信号：GitHub 上的开源代码水平参差不齐，但代码至少比自然语言多出一些可用的质量筛选信号——编译状态、测试覆盖、PR review、merge 记录、issue 讨论和依赖使用情况都能帮助过滤样本。虽然这些信号并不完美，但比任意网页文本更容易机械筛选。
• 错误可快速迭代：代码报错信息明确（堆栈 trace、类型错误），模型看到就能修正；而"这段话写得不够好"太主观，难以形成高效训练回路。

小米大模型负责人罗福莉的判断是：Code 在每个范式转折点都戳中了关键——R1 时代有 verify 的指标，Agent 时代软件开发是天然的长程任务，且代码任务天然混合自然语言需求、文档、错误信息和形式化语法，Code 上做出的成果容易泛化到其他领域。她认为 Anthropic 两年前就看清了代码 + RL 这条路径，行业到 2026 年才形成共识⁵。

3Blue1Brown 的对话给了一个更深的洞见：可验证只是必要条件，可打磨性（muzzability） 才是解释突破速度的关键条件——任务能否被容器化、并行化、无限重试，决定了 AI 能在哪个领域快速突破。数学和代码远超电脑操作、交易、社交等其他同样可验证的任务，根本原因不是"更可验证"，而是问题状态可打包、验证可自动化、可以同时跑一千个并行实例各自尝试不同路径⁶。

代码之所以成为 AI 工程化的样板场景，是因为它同时满足了三类条件：训练层有硬验证奖励，推理系统层有编译器和测试框架做即时反馈，生态层有 GitHub 社区和 CI/CD 基础设施在持续筛选和沉淀高质量信号。理解了代码为什么突破，就理解了三层框架为什么要分开设计。

三、推理系统层：把概率输出放进可控运行环境

有了强大的通用基座模型，实际问题变成：怎么让它适应你的具体业务场景？

上下文工程：把私域知识放进输入

从微调到上下文工程

LLM 刚出现时，上下文窗口很小。早期 GPT-3/ChatGPT 时代及第一批开源模型只有 2K 到 4K 的上下文——塞几页文档就满了，装不下一个业务场景所需的完整背景知识、规范和示例。那时对于需要稳定注入业务知识的场景，微调常被视为主要路径：收集几百到几千条业务标注数据，在基座模型上做 SFT。

转折点在于长上下文能力的突破。当模型上下文窗口扩展到 128K、1M 甚至更高时，“通用基座 + 合适的上下文"变得真正可行。不需要标注数据、不需要 GPU 训练，只需把业务知识整理成清晰的 prompt、Rules、Skills 或知识库文件，在推理时注入给模型。但窗口变长不等于所有信息都该塞进去，长上下文真正释放价值的前提仍然是筛选、排序和压缩。

这就是上下文工程（Context Engineering）：在推理阶段，通过管理输入给模型的上下文来最大化输出质量。核心原则是：寻找能够最大化产生期望结果可能性的最小、高信号 Token 集⁷。

从组织视角看，上下文工程不只是"写更好的提示词”——它是把原来散落在人、文档、代码、流程里的隐性知识，改造成模型运行时可调用的上下文资产。Rules 是组织偏好的压缩，Skills 是重复任务的操作封装，Spec 是判断标准的显式化，知识库是历史材料的外部检索记忆，MCP 和工具接口则划定模型与外部世界交互的边界。这些资产和接口的共同特征——可版本化、可组合、可独立更新——让系统层的改进不再依赖模型升级，且每类资产都能在组织内复用。

上下文工程为什么在当下优于微调

上下文工程不是一开始就优于微调——它是被长上下文能力"解锁"的。现在成为首选，有几条理由：

成本不对称。至少在初始探索和验证阶段，上下文工程的优势明显：微调需要标注数据、训练算力、版本迭代后的重训维护；上下文工程只需写好 prompt、整理好知识库、设计好工具接口。不过上下文工程同样有长期维护成本——prompt 漂移、规则膨胀、知识库过时——只是这些成本分摊在整个使用周期中，不像训练那样一次性集中投入。

快速反馈。改几句 prompt 就能立刻看到效果——像是项目 MVP，先跑通再优化。

模型在快速进步。今天微调的模型，半年后基座大幅提升，你的微调可能成为负资产。上下文工程比微调更容易跨模型复用：基座升级后，Rules、Skills、知识库这些资产大体继续有效，虽然具体 prompt 组织和工具调用细节仍可能需要适配。

覆盖领域知识盲区。LLM 的训练数据覆盖了公开知识，但每个团队都有自己的隐性知识——架构决策的原因、模块间的隐含契约、历史 Bug 经验。这些不在预训练数据里，微调样本量远不足以系统性地教会模型。上下文工程通过 Spec、Rules、Skills、MCP 等机制，在推理时动态注入私有上下文，是更高效的传递方式。

所以目前业界的实践是：能用上下文工程解决的问题，通常不会急于微调；只有当场景稳定、数据充足、收益明确时，才会考虑微调甚至重新训练。这也是为什么很多企业优先建设数据、评测和反馈闭环，而不是一上来就投入昂贵的模型训练。

上下文工程不是万能药

反向边界同样重要。以下场景中上下文工程未必最优：

• 高频稳定任务：输出格式固定、需求变化极少的场景（如标准化分类、格式转换），fine-tuning 或小模型蒸馏可能比长 prompt 更经济
• 延迟/成本极度敏感：长上下文注入会增加首 token 延迟和 token 消耗，对实时场景可能是瓶颈
• 已有大量标注数据：如果标注数据已经积累到可以系统性覆盖边界 case，微调可以直接把知识压进权重，效果可能更稳定

微调没有消失——当上下文工程把场景打磨到足够稳定、数据自然积累到足够量级时，微调是进一步提效的合理选择。两条路径不是非此即彼，而是不同阶段的杠杆。

运行闭环：循环验证把概率输出变成可控过程

上下文工程给出了输入侧的控制。但模型依然是概率性的——它可能忽略指令、选错工具、在长任务中丢失早期约束。这需要第二层杠杆：循环与可验证。

Sydney Runkle 的四层循环堆叠框架把这个思路组织得很清楚⁸：

1. Agent 循环：模型在循环中调用工具直到任务完成——模型能做什么，怎么做
2. 验证循环：外层 grader 对 agent 输出评分，不通过则带反馈重试——Agent 做得对不对
3. 事件驱动循环：webhook、cron、消息通道自动触发 Agent——Agent 什么时候该做
4. 爬山循环：分析生产 trace 识别问题模式，自动更新 prompt、工具配置、grader 规则——Agent 配置如何自动变好

多数团队收敛在 1-2 层。但复利在 3-4 层——当爬山循环每转一圈都让内层更有效时，系统从"人在驱动"变成"系统自我改进"。

从另一个角度，吴恩达提出了一组按人类和 AI 各自的时间节奏区分的三层循环⁹：

• 智能体编程循环（分钟级）：Agent 自主编码、测试、修复，人完全离开——把"验证-修复"的短反馈交给模型闭环
• 开发者反馈循环（十分钟到小时级）：人审视产品现状，调整功能优先级、改进 UI。核心贡献是上下文优势——我们比 AI 更了解用户和产品环境
• 外部反馈循环（小时到天级）：内测、A/B 上线、用户反馈反哺产品愿景，愿景再驱动 spec，spec 驱动编程循环

两组框架切入角度不同，无法简单一一对应——Sydney 的 Agent 循环大致对应吴恩达的智能体编程循环（都是 Agent 自主执行的分钟级闭环），但验证循环中 grader 规则的设计已经是开发者反馈循环的范畴，而爬山循环同时跨越了开发者反馈和外部反馈两层。互补的不是对应关系，而是它们回答的问题不同：Sydney 回答"反馈系统本身怎么设计"，吴恩达回答"人的判断在哪个时间尺度上不可替代"。两条线共同指向同一个判断：循环的价值不在于让 AI 更快，而在于让正确的反馈在正确的层级上闭合。

验证的层次

这里有一个关键的工程区分：验证不是只有一种。

• 硬验证：编译器、测试框架、linter、类型检查——确定性裁判，通过即通过，失败即失败。成本低、更难被主观偏差影响，但仍可能被 reward hacking 或 benchmark gaming 投机优化；
• 软验证：LLM-as-Judge 打分、用户满意度、产品指标——概率性裁判，有偏差、可被对抗样本攻击、需要校准。成本高、需要多重防护。

回头看第一章的幻觉问题——缓解幻觉靠的不是让模型"不撒谎"，而是让验证循环中的多重信号交叉核查：检索增强把输出锚定到外部事实、工具调用让模型必须提交可执行结果、硬验证在可行处拦截错误、多重软验证在不可行处交叉印证。这也是为什么硬/软验证的区分不只是概念游戏——它是对抗概率性输出的工程策略。

可验证性不是天然就有的。代码场景里硬验证是"免费"的。但到了更广泛的生产力场景——写需求文档、分析业务问题、排查线上故障——“对错"本身就需要被定义和建设。这要求把隐性判断转化为显式标准：什么是好的 spec？什么算排查到位？什么情况下 Agent 应该停止搜索转向人类确认？

给 Agent 设计验证信号，和训练时设计奖励是同一类问题。但推理层的验证反馈更快——改几句 prompt、调整验证规则就能看到效果，再迭代。软验证在这个阶段是务实起点，但目标始终是往硬验证方向迁移：把模糊标准拆解为可检查项；硬验证不可行处，把 LLM-as-Judge 校准到接近人类水平并搭配多重软验证交叉印证。

四、训练学习层：奖励把反馈写回模型能力

上下文工程和循环验证是推理时的杠杆。奖励（Reward） 是训练时的核心驱动力——它把反馈信号写回模型权重。

LLM 的训练分多个阶段：预训练用 next-token loss 做自监督，SFT 用标注数据做行为克隆，RL（RLHF/RLAIF/RLVR）通过奖励信号让模型在探索中优化策略。RL 阶段尤其依赖奖励设计——模型采取行动 → 环境给奖励信号 → 模型调整策略以最大化累积奖励。奖励信号的质量和密度直接决定了模型能学到什么程度。

代码领域 RL 效果拔群，因为奖励是硬验证的——编译通过、测试通过、benchmark 提升，模型不需要人类来告诉它每一步对不对。

但 RL 的塑造力远超代码。Anthropic 的 Sleeper Agents 研究更适合作为反向警示：后训练流程可能保留甚至强化复杂的条件触发行为，常规安全训练也未必能可靠消除它们⁴。这说明奖励和数据设计极其关键，也可能极其危险；但不能由此直接推出 RL 总能塑造任意期望能力——可塑性大不等于可塑方向可控。

罗福莉的判断是：AI 正从预训练主导的 Chat 时代转向后训练主导的 Agent 时代，后训练算力投入将与预训练持平（1:1），长上下文和 Agent 框架设计成为核心竞争力⁵。

奖励与偏好监督机制本身也存在多个维度：代码编译/测试通过的确定信号（verifiable reward）更接近正确性，对中间推理步骤的打分（process reward）关注过程质量，用宪法原则将人类偏好转化为可规模化监督信号的 Constitutional AI 则处理安全与偏好对齐⁴。这些不是线性替代——verifiable reward 在代码场景中仍最直接有效，CAI 解决的是偏好对齐而不是正确性验证。

五、组织反馈层：把失败转成可复用约束

循环、可验证、奖励——这三者背后是同一个问题：反馈信号从哪里来，怎么让它持续变好？

数据飞轮：信号积累的复利

数据飞轮的核心逻辑是：模型越好 → 用的人越多 → 产生的高质量反馈越多 → 训练数据越丰富 → 模型越好。Claude Code 这类 AI 编程产品可以作为这种机制的例子：代码生成结果、测试反馈、用户采纳或拒绝等交互痕迹，在机制上都可能成为后训练可用的反馈信号⁴。

但飞轮不等于护城河。只有当反馈信号稀缺（别人采集不到）、专有（来自你的独特场景）、能转化为模型或系统改进、且改进又带回来更多使用时，才是壁垒。否则只是数据堆积。

从失败 trace 到训练信号：中间缺的转换层

数据飞轮的瓶颈往往不在数据量，而在转换层——什么样的失败 trace 能变成有效的奖励信号？这中间需要一系列工程判断：

• 哪些用户拒绝是"模型错了"而不是"用户偏好不同”？
• 哪些编译失败值得变成训练样本，哪些只是环境配置问题？
• 线上多轮交互中的哪个 step 是真正的失败点？

这个转换层没有自动化公式，它要求人持续做判断——这本身就是组织能力。

内循环 vs 外循环

企业更务实的起点不是模型公司的数据飞轮，而是把每一次错误变成系统进化的机会：Agent 执行中暴露的失败模式 → 诊断根因 → 沉淀为 Rules / Skills / 评估用例 → 同类错误不再发生。这不是让模型变聪明，而是让系统层的上下文和约束越来越精准。

这里有一个关键区分：内循环是 Agent 与用户交互执行工作（ReAct 循环），外循环是一个独立系统——观察内循环的运行轨迹、识别反复出现的失败模式、更新 prompt 和工具配置、甚至主动向人类提问以学习组织偏好。Introspection 公司的 autoresearch 概念把外循环产品化：它不是"更复杂的 prompt 循环"，而是一个自治系统，让内循环的改进不再依赖人的持续注意力¹⁰。

真正的壁垒是组织能力

全文讲技术机制，但真正难的不是懂这些原理。而是把隐性判断持续转化为可执行约束的组织流程：

• 需求评审中模糊的"这个不太对"怎么变成 spec 里的验证标准？
• 线上一次错误的 Agent 决策怎么变成 eval 用例和回归测试？
• 老工程师脑子里的架构约束怎么变成 Rules 让 AI 参考？
• 谁负责在模型升级后复测旧约束是否还有效？

这是上下文工程、循环验证、奖励设计和数据飞轮背后的共同前提。AI 工程化的壁垒不是"会 prompt"，而是持续把失败转成可复用约束的组织能力。

六、收束：AI 工程化的主线是反馈工程

前面几条线索看似分属不同层级——上下文工程在推理时，循环验证在运行时，奖励设计在训练时，数据飞轮在组织层——但它们其实都在处理同一个问题：反馈信号如何进入系统，并在下一次行动中发挥作用。

上下文工程和奖励设计不是替代关系，而是作用在不同时间尺度的两种反馈机制：

• 上下文工程在推理时提供信息和约束，让模型在当前任务中少走偏；
• 奖励设计在训练时改变行为分布，让模型在未来类似任务中更可能走对。

前者适合承载变化快、语境强、组织专有的知识，后者适合吸收稳定、可重复、大规模验证过的信号。把临时规则过早写进训练会污染模型，把高度稳定的通用行为长期留在 prompt 里也会造成运行时成本和维护负担。

因此关键问题是"什么反馈应该写到哪一层"：

• 大规模、低歧义、可自动验证的信号适合进入训练层（编译、测试、benchmark）；
• 中等规模、随业务调整但相对稳定的偏好适合进入推理系统层（Rules、grader、eval）；
• 小规模、高价值、强语境依赖的判断留在组织反馈层（产品取舍、架构原则、一次线上事故暴露出的边界条件）。

三类信号的更新频率和适用范围不同，强行混合只会互相污染。

三层框架不是流水线，而是反馈网络：训练层的能力提升让推理系统层可以使用更复杂的上下文和更长的任务链 → 推理系统层积累的 trace 让组织层更容易识别反复出现的失败模式 → 组织层沉淀为 Rules、Skills、eval 再反过来提升系统和模型。这个正向循环能转多快，取决于组织能否持续把隐性判断转化为可执行约束，而不只是模型本身变得多强。

由这套反馈分层，可以回看前面的几个关键判断：

• 上下文工程是推理系统层的主战场：对多数尚未建立后训练能力的团队来说，前沿模型能力基本是外部变量，上下文管理才是更快、更可控的提效杠杆。整理私域知识、Rules、Spec，核心目的是让输出可验证、可预测。但上下文工程不是万能——高频稳定、延迟敏感、已有大量标注数据的场景，微调或蒸馏更划算。
• 循环把概率输出变成可控过程：单次调用的正确率不够，需要外层验证包裹、trace 分析和自动改进。硬验证优于软验证，需要软验证的地方必须建多重防护。循环堆叠降低了执行层的人力依赖，但同时也提高了系统设计层的认知负担——层级越高，故障模式和调试难度也越复杂。
• 奖励设计塑造后训练的行为分布：verifiable reward、process reward、Constitutional AI 等机制，奖励设计是 Agent 时代模型能力兑现的关键杠杆之一。但奖励的前提是可验证，而可验证性本身需要先被建设——任何想要 AI 深入的场景，首先要回答的都不是"怎么训练"，而是"什么算对"。
• 数据飞轮的价值取决于转换层：反馈信号必须稀缺、专有、能转化，才是壁垒。真正的稀缺资源是将失败 trace 筛成有效训练信号、将隐性判断转化为显式约束的组织能力。
• 人的判断力仍是外循环的关键输入：AI 降低了执行成本，但没有降低判断成本——什么值得做、什么算做好、什么情况下该停。正如吴恩达所说，只要人类知道 AI 不知道的事情，就需要人在回路。定义问题、设计验证标准、识别高价值方向，这些能力不会因为模型变强而贬值，反而因为执行变得便宜而更稀缺。

这个领域变化快，但贯穿其中的线索是稳定的：AI 是概率性的，工程化的目标是把它放进可验证、可反馈、可改进的系统里。推理系统层管输入和运行时反馈，训练层管奖惩信号如何写回模型，组织反馈层管失败信号如何积累成长期约束。全文反复出现的不是某个技术，而是反馈的形态：硬反馈与软反馈、即时反馈与延迟反馈、内循环反馈与外循环反馈。真正的分水岭不是谁用了更新的模型，而是谁能把一次失败变成下一次不会重复的约束。

参考来源