从 prompt tuning、ReAct 到今天的 skills，大模型应用的发展路径，其实一直在做同一件事：试图把一次次成功的案例经验，抽象成可复用、可迁移、可解释的方法论体系。
这句话看起来简单，但它触及了大模型应用工程最核心的矛盾。
我们一边试图把 LLM 工程推向“科学化”，让它拥有流程、结构、范式、评估和可复盘能力；另一边又不得不承认，前沿实践中大量有效方法仍然来自案例、经验、调参、试错和场景化总结。
它既不像传统软件工程那样高度确定，也不能简单归为玄学经验。
所以真正值得追问的是：复制一遍所谓最佳实践，能不能得到与案例一致的结果？
大概率不能。
同一个 prompt，换一个模型版本，结果可能不同。
同一个 ReAct 流程，换一个工具环境，表现可能不同。
同一个 agent 框架，换一个业务场景，可能从高效执行变成原地空转。
同一个 skill，换一个上下文质量，可能从稳定能力变成噪声放大器。
这不是因为大模型应用完全不科学，而是因为它面对的对象不是传统确定性程序，而是一个高维概率系统。
传统软件工程追求的是机械确定性：相同输入、相同代码、相同环境，理论上应得到相同输出。程序的可靠性来自明确逻辑、状态控制和执行路径。
而大模型不是这种机器。
它的输出来自概率分布，受模型参数、采样策略、上下文结构、工具返回、任务表达和隐含语义共同影响。它并不天然保证同样输入得到完全同样输出，更不保证同样案例复制到不同业务场景后仍然有效。
因此，大模型应用工程的科学化，不能被理解为把 LLM 改造成传统程序。
更准确地说，它是在概率系统之上建立条件可复现。
所谓条件可复现，不是承诺任何情况下都得到同一个结果，而是在任务边界、上下文结构、工具接口、流程编排、记忆机制、评估标准和风险约束被明确之后，让系统输出质量的分布稳定向目标收敛。
这才是大模型应用工程的核心。
它追求的不是绝对确定性，而是条件概率意义上的高确定性。
这也是 prompt tuning、ReAct、workflow、agent、skills、memory、RAG、tool use 一路演化的真实逻辑。
早期 prompt tuning 试图通过语言指令影响模型行为，本质上是在寻找“输入表达”与“输出质量”之间的经验映射。
ReAct 进一步把推理和行动交替展开，让模型不再只是一次性回答，而是在“思考—行动—观察—再思考”的过程中形成可追踪的执行链条。
Workflow 把复杂任务拆成阶段，让每一步有输入、输出、判断和回退。
Agent 把模型连接到工具、环境和任务状态，使它具备一定程度的自主执行能力。
Skills 则进一步把高频成功经验封装成可调用、可组合、可复用的能力单元。
这条路径不是 prompt 技巧升级，而是 LLM 应用从经验主义走向工程抽象的过程。
案例不是科学，案例是科学化的原材料。
一个成功案例只能说明：在某组条件下，这种方法曾经有效。
如果我们只复制表层做法，而不理解它背后的条件结构，那么复制最佳实践往往只是在复制表象。
真正重要的问题不是“这个案例怎么做”，而是：
为什么这个 prompt 有效？
为什么这个流程能够收敛？
为什么这个 agent 没有陷入循环？
为什么这个 skill 在某类任务上稳定？
为什么这个上下文提升了质量，而另一个上下文制造了幻觉？
为什么同样的方法在 demo 中有效，进入生产后却失效？
这些问题背后，才是大模型应用科学化的起点。
LLM 工程不是从“不科学”走向“传统确定性科学”，而是从粗糙经验走向条件可复现的工程科学。
这种工程科学有一个前提：不能浪漫化不确定性。
大模型的概率性不是优点本身。
在企业生产系统中，不确定性如果不能被度量、压缩、隔离、回放和治理，它不是创造力，而是事故源。
企业真正关心的不是模型偶尔有多聪明，而是它能否稳定交付。
不是一次回答有多惊艳，而是一万次运行后的质量分布是否可接受。
不是 demo 看起来多神奇，而是成本、延迟、权限、安全、责任和失败处理是否可控。
所以，大模型应用工程的核心任务，是把不确定能力转化为可管理生产力。
这需要一整套条件系统，而不是一条神奇 prompt。
第一，任务边界要清晰。
模型必须知道自己要解决什么问题，也必须知道自己不解决什么问题。很多 agent 失控，并不是模型太弱，而是任务边界过于模糊，导致它不断自我延展。
第二，上下文结构要治理。
上下文不是越多越好。更长的上下文可能带来更多信息，也可能带来更多噪声。真正有效的是被筛选、分层、去冗余、带有关系结构和优先级的上下文。
第三，工具接口要确定。
工具是大模型连接确定性世界的桥。计算、检索、数据库查询、代码执行、API 调用、文件操作，都能把语言生成的一部分不确定性转化为外部系统的确定性结果。
第四，流程编排要可观察。
复杂任务不能依赖一次性生成。它需要拆解、执行、检查、修正、回退和记录。没有过程可观察，就没有失败可复盘。
第五，技能能力要封装。
高频任务不能每次重新 prompt。能稳定复用的操作应该沉淀为 skill，成为系统能力资产，而不是个人经验技巧。
第六，评估反馈要持续。
没有评估样本，就没有工程改进。没有失败集，就没有可靠迭代。没有版本对比，就不知道质量是提升还是退化。
第七，风险治理要内建。
权限、审计、数据边界、人工确认、异常中止和责任追踪，不能作为上线后的补丁，而应该成为系统设计的一部分。
这些条件共同构成了 LLM 应用的“条件确定性”。
也就是说，大模型应用不是一个简单函数：
输入 A，必然得到输出 B。
它更像一个条件系统：
在条件 C 被充分定义和控制时，输出 B 的概率显著提高，并且失败模式可以被观察、解释和修正。
这才是 LLM 工程区别于传统软件工程的地方。
传统程序把确定性写进代码。
大模型应用把确定性建立在约束条件、外部工具、上下文治理、流程控制和评估反馈之中。
因此，未来真正有竞争力的 AI-Native 系统，不会只是“模型更强”，而是“条件系统更完整”。
模型能力决定可能性上限，工程结构决定可交付下限。
没有工程结构，模型越强，系统越不可控。
有了工程结构，模型的不确定性才可能被转化为创造性、适应性和生产力。
这也解释了为什么 skills 会成为重要方向。
Skills 的价值不在于让模型“多会几个技巧”，而在于把分散经验封装成可调用能力，把一次性成功沉淀为组织资产。它把 prompt 从临时表达，推进到能力工程；把个人调参经验，推进到系统化复用；把模型的即时生成，推进到长期可积累的能力体系。
但 skills 也不是万能答案。
如果没有任务边界，skill 会被误用。
如果没有上下文治理，skill 会被噪声污染。
如果没有评估机制，skill 的有效性无法证明。
如果没有版本管理，skill 的退化无法发现。
如果没有权限控制，skill 的自动化会放大风险。
所以，大模型应用的科学化，不是从 prompt 到 skills 的单点升级，而是从“提示词经验”到“条件系统工程”的范式迁移。
这里有一个关键分界：Demo 与 Production。
Demo 可以接受偶然性。
Production 必须管理偶然性。
Demo 展示一次成功。
Production 要承受重复运行。
Demo 可以依靠专家手感。
Production 必须依靠流程、指标、监控和回滚。
Demo 讲的是“模型能做到什么”。
Production 讲的是“系统在什么条件下稳定做到什么”。
这正是今天很多 AI 应用卡住的原因。
它们不是没有能力，而是没有把能力转化为条件可复现。
它们不是没有 demo，而是没有生产系统。
它们不是缺少 prompt，而是缺少工程闭环。
它们不是缺少模型调用，而是缺少质量治理。
从这个角度看，大模型应用的真正问题不是“科学还是不科学”，而是“是否具备可证伪、可复盘、可迁移、可治理的工程结构”。
如果一个方法只在某个专家手里有效，它还是经验。
如果它能被拆解成条件、步骤、变量和指标，它才开始工程化。
如果它能在不同场景中被验证边界、调整参数、复盘失败，它才逐渐接近科学化。
所以，“更诚实的科学”不是说 LLM 应用已经具备严格科学的全部条件，而是说它迫使我们承认：智能系统的工程化，本来就不应该被简化为机械复现。
面对概率系统，真正诚实的做法不是假装确定，而是定义条件。
不是承诺永远正确，而是持续提高正确概率。
不是消灭失败，而是让失败可观察、可解释、可修正。
不是迷信最佳实践，而是提炼最佳实践背后的适用边界。
大模型时代，工程确定性的来源正在发生变化。
它不再只来自代码，也来自上下文。
不再只来自流程，也来自评估。
不再只来自规则，也来自反馈。
不再只来自程序员写下的逻辑，也来自组织对知识、任务、工具和风险的系统治理。
这是一种新的工程科学观。
它承认模型是概率的。
它承认案例是不充分的。
它承认最佳实践不能直接复制。
但它不因此放弃工程化。
相反，它把工程化推进到更深一层：
从复现输出，转向复现条件；
从控制结果，转向控制分布；
从编写程序，转向设计系统；
从调用模型，转向构建能力资产。
最终，大模型应用的成熟，不取决于我们能不能写出一个完美 prompt，而取决于我们能不能建立一套让模型稳定创造价值的条件系统。
模型负责生成可能性。
工程负责约束可能性。
评估负责筛选可能性。
组织负责沉淀可能性。
这就是我对大模型应用科学化的理解：
它不是复制最佳实践。
它是理解最佳实践为什么成立、在什么条件下成立、如何迁移、如何失效、如何修正。
它不是消灭不确定性。
它是把不确定性变成可管理的生产资料。
它不是传统确定性软件工程的延续。
它是面向概率智能系统的条件可复现工程。
