Software 1.0、2.0 与 3.0 如何共存
一句话收获：Software 3.0 扩大了可表达任务，但没有替代程序和专用模型。
这个场景在解决什么问题
目标（goal）是建立三种软件构造方式的职责边界，搞清楚"用程序硬编码、用数据训练模型、用自然语言驱动"这三条路各该负责什么。观察方式是：看同一个系统如何依次加入确定程序、数据形成的模型能力，以及自然语言驱动能力。它值得单独学，是因为很多人容易把"更强的模型"误当成"可以替代一切代码"，结果把不该交给模型的边界也交了出去。
先理清这条判断链（文字版）
先看 Software 1.0（显式代码）负责什么边界，再看 Software 2.0（数据驱动模型）补齐了什么能力，接着看 Software 3.0（自然语言驱动）把什么新东西带进了软件构造界面，最后回到一个关键判断——这三者不是替换关系，而是协同关系。判断链是：
- 先用 Software 1.0 把"不能违反的边界"用显式程序定死。
- 再用 Software 2.0 让系统通过数据获得识别、预测、生成等开放能力。
- 然后用 Software 3.0 把自然语言、上下文、工具和反馈引入构造界面。
- 最后验收三者如何协同：模型理解目标、程序校验边界、传统系统保存权威状态。
逐层详解
第 1 步：Software 1.0
原文：开发者用显式代码规定结构、权限、状态和确定流程。
白话：Software 1.0 就是传统编程——工程师一行一行把结构、谁能做什么权限、数据处在什么状态、流程按什么顺序走，全部写死在代码里。
类比：像盖楼前先画好施工图，承重墙、门窗、管线位置都提前定死，工人照着图纸干，不靠临场发挥。
举例：一个报销系统，金额超过 5000 必须由财务经理审批、审批通过后才能打款、每一笔状态从"待提交"到"已支付"都有明确流转，这些规则直接写在代码的 if/else 和权限校验里。
为什么重要：一旦不能违反的边界适合程序执行——比如"谁有权转账""金额上限是多少"，这类规则必须稳定、可测试，交给程序最可靠。
怎么验证（证据点）：
- 规则明确：每一步该做什么写得清清楚楚。
- 结果可测试：给定输入，输出是确定的，能写测试断言。
- 状态可追踪：每一步状态变化都能查到记录。
别踩的坑（边界）：显式代码不擅长开放语言理解——用户随便说一句"帮我看看这单能不能报销"，传统代码很难解析这种自由表达。
落地检查：确定边界继续由程序承担——落地时先问自己：哪些规则是"绝不能违反"的，这些就该留在代码里，别幻想用模型去兜底。
第 2 步：Software 2.0
原文：系统通过数据获得识别、预测和生成能力。
白话：Software 2.0 不再是手写规则，而是喂大量数据让模型自己学出规律，从而具备识别（这是不是发票）、预测（这个用户可能买什么）、生成（写一段回复）的能力。
类比：像教小孩认猫——你不逐条告诉它"有胡须、有尖耳朵、会喵喵叫"这些规则，而是拿一堆猫的照片给它看，它自己慢慢总结出"猫长什么样"。
举例：报销系统里，让模型识别上传的票据照片是不是发票、发票上的金额和日期读得对不对，这不需要手写几百条图像识别规则，训练好的模型直接判断。
为什么重要：不必逐条编写所有模式规则——语言、图像这类开放问题，规则列不完，靠数据学习才现实。
怎么验证（证据点）：
- 识别能力：能认出对象、类别。
- 预测能力：能对下一步给出概率判断。
- 行为概率化：输出是概率性的，不是 100% 确定。
别踩的坑（边界）：本课程不进入训练算法——我们只关心模型在系统里"占哪个位置、承担什么职责"，不深究模型内部怎么训练出来的。
落地检查：只建立它在系统中的位置——落地时把模型当成系统里的一个"能力组件"，明确它的输入输出和边界，而不是纠结训练细节。
第 3 步：Software 3.0
原文：自然语言、上下文、工具和反馈进入软件构造界面。
白话：Software 3.0 让"用自然语言描述目标"这件事直接参与软件构造——用户说的话、当前环境上下文、能调用的工具、执行后的反馈，一起成为驱动系统行动的输入。
类比：以前你得会编程才能让电脑做事，现在像直接给一个能干的实习生下口头指令，再给他配好工具箱，他能自己查资料、动手、看结果再调整。
举例：用户对报销助手说"帮我把上个月出差的三张发票整理成报销单"，系统理解这句话、读取上下文里的票据、调用查账和填表工具、根据反馈修正，最后产出报销单。
为什么重要：目标可以直接驱动模型生成候选代码和行动——不用把人的话翻译成死板的函数调用，目标本身就能推动系统往下走。
怎么验证（证据点）：
- 自然语言目标：用户意图用自然语言表达。
- 上下文环境：当前相关背景信息被装载进来。
- 工具反馈：调用的工具把结果反馈回来，供下一步判断。
别踩的坑（边界）：自然语言不因此成为硬约束——用户说的一句话是"意图"，不是法律条文，不能拿它当不可违反的规则。
落地检查：开放能力需要模型外工程边界——模型有了开放能力后，越要小心，得在模型外面加校验、权限、预算这些工程护栏，不能让它想干啥就干啥。
第 4 步：三者协同
原文：模型理解目标，程序校验边界，传统系统保存权威状态。
白话：真正落地的 Agent 系统是三件套一起干活——模型负责"听懂要做什么"，程序负责"拦住不能做的事"，传统数据库/系统负责"记录最终谁说了算的状态"。
类比：像一家公司的分工——销售（模型）理解客户需求、灵活沟通，法务（程序）卡死不能碰的红线，财务（传统系统）记最权威的账本，缺一个都会乱。
举例：报销 Agent 里，模型理解"这单能不能报销"的意图并给出建议，代码强制校验"金额上限、审批权限、预算余额"这些硬边界，而最终"是否已打款"的权威状态记录在财务系统里，而不是模型的一句话里。
为什么重要：真实 Agent 系统依赖多种范式共同工作——单一范式撑不起复杂业务，必须多范式协作。
怎么验证（证据点）：
- 职责清楚：谁理解、谁校验、谁记账，分工明确。
- 边界分层：硬边界、软判断分层处理。
- 证据可回查：每一步都有可追溯的记录。
别踩的坑（边界）：使用更强模型不能删除状态机和权限——换了更强的模型，不等于可以把状态机和权限系统拆掉，这两件事不搭界。
落地检查：架构判断比范式替换更重要——落地时别老想着"换个更强的模型解决一切"，先想清楚各范式怎么分工、边界放哪。
落地可行性小结
本场景涉及的技术栈：显式程序（Software 1.0，用普通后端代码实现权限、状态、流程）、数据驱动模型（Software 2.0，用训练好的识别/预测模型）、自然语言驱动（Software 3.0，用 LLM + Prompt + 工具调用）。落地时要做的核心动作是"画边界"：把不能违反的规则写进代码并配测试，把开放语义判断交给模型但配好校验护栏，把权威状态落在传统系统（数据库、财务系统）里。常见坑有两个：一是把模型的自然语言输出当硬约束直接用；二是以为换更强模型就能删掉状态机和权限系统。检查点：每条关键规则是否都有"程序校验 + 可回查记录"的落点。
回顾
- Software 1.0 管确定边界，Software 2.0 靠数据获得开放能力，Software 3.0 让自然语言驱动软件构造。
- 三者是协同关系，不是谁取代谁。
- 自然语言是意图不是硬约束，开放能力必须配模型外工程边界。
- 更强模型不能删除状态机和权限，架构判断比范式替换更重要。