夜雨聆风软件工程 50 年,其实一直是"高级手工作坊"
1968 年 NATO 会议提出"软件工程"这个词的时候,目的是为了解决"软件危机"——项目延期、超预算、bug 丛生。50 多年过去,敏捷、Scrum、DevOps、CI/CD 一套套方法论轮番上场,真正发生"工程化"了吗?
答案是:没有。 这话乍听反直觉,但换一个参照系就清楚了。真正的工程是什么?看机械、化工、电力——它们都做了一件关键的事:用能源替代低阶智能。1788 年瓦特给蒸汽机装上离心调速器,化工厂的恒温器靠 PID 自动跑,人从生产主回路里退出来,只做更高阶的设计与维护。
软件工程没做过这件事。需求从用户到产品经理、到开发、到测试,每一环都在失真;代码要靠人一行行用脑子想出来;同一个功能,张三和李四写出来就是不一样。软件危机的本质,是"认知主体始终是人脑"。 只要靠人脑堆,不确定性就永远在。
但这 50 年也不是白干的。一整套自动化验证基础设施被搭了起来——编译器、类型系统、单元测试、CI/CD、监控告警。这套东西没能让软件工程"工程化",却给下一个时代备好了最坚硬的地基。
范式一:从"堆人脑"到"烧算力"的认知引擎
大模型来了。它的工程史地位被严重低估了。它不是"高级助手",而是工程史上的第一个认知引擎。
- • 经典工程:能源 → 低阶智能(机械控制)
- • 大模型:能源(算力) → 高阶智能(理解、推理、生成)
这是历史上第一次,"认知"这件事被能源化了。蒸汽机让"做功"能源化,开启了工业革命;大模型让"高阶认知"能源化,开启的将是"认知工业革命"。
这意味着,软件工程真正成为"工程"的时刻,现在才刚到来。 但也别高兴太早——把"人的不确定性"换成了"模型的不确定性":幻觉、漂移、不可解释。新范式的核心命题变成了:如何设计一个能自主纠偏的 AI 系统,并让人专门处理系统自己纠不回来的偏差。
下面是一个最小可跑的"认知引擎"调用示例,用 OpenAI 兼容接口展示大模型把自然语言需求直接转成可执行代码的过程:
# 需求:统计昨日订单总额超过 1000 的客户数
from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "你是数据工程助手,只返回 SQL。"},
{"role": "user",
"content": "统计昨日订单总额超过 1000 的客户数,表 orders(id, user_id, amount, created_at)"},
],
temperature=0,
)
print(resp.choices[0].message.content)
# 输出:SELECT COUNT(DISTINCT user_id) FROM orders
# WHERE created_at >= CURRENT_DATE - INTERVAL '1 day'
# AND created_at < CURRENT_DATE
# GROUP BY user_id HAVING SUM(amount) > 1000;看似平常的一段调用,实际上就是"烧算力换高阶智能"的最小单元。 单次成本 0.01 美元左右,跑完就能拿到一段过去需要 5 年 SQL 经验才能写对的查询。
范式二:AI 中心闭环 + 确定性裁判
当前业界主流——"人为中心,AI 辅助"(Copilot 模式)——是数字化时代的"马车配好鞍"。它不消除不确定性,而是在循环里放大它:AI 用人的代码训练,学会的是人的模式(包含错误);人再用人的标准去 review AI 输出。结果就是:很多团队用了 Copilot,代码量上去了,bug 率和 review 工作量并没降下来。
更隐蔽的代价是:你接受或拒绝 AI 的建议,这个"为什么"没有结构化地沉淀到本地。所有的反馈和数据,最终都在帮 OpenAI、Anthropic 训练下一代模型。不知不觉间,一线开发者成了 AI 厂商的免费数据标注员。
历史总是惊人地相似。20 世纪初电气化时,第一波工厂只是用电动机直接替换蒸汽机,传动系统和车间布局都没变,效率提升不到 30%。福特做的是为每台机器单独配电动机,并按"电力驱动"的逻辑彻底重设计流水线——效率提升数倍。第一波工厂全被淘汰。
正确的终局是AI 为中心,人工辅助。AI 是流程的主体,在从需求到设计、编码、测试、部署的链路里自动流转;人退到两端,前端定义价值,末端守卫边界。
它能成立的关键,在于"确定性裁判"。大模型本身是概率性的,无法自证清白。让它工程级可靠的唯一办法,是用外部确定性系统对其输出进行暴力审判:
- • AI 生成的代码 → 必须通过编译器 + 单元测试
- • AI 设计的接口 → 必须符合 Protobuf / OpenAPI 契约
- • AI 发布的变更 → 必须通过灰度监控指标
下面是一段最简的"裁判"伪代码,展示 AI 输出如何被自动化关卡拦截:
def judge(ai_output: CodePatch, ctx: BuildContext) -> Verdict:
# 1. 静态分析
if not type_check(ai_output):
return Verdict.REJECT, "type error"
# 2. 单元测试必须全绿
test_report = run_pytest(ctx.test_dir)
if test_report.fail > 0 or test_report.cover_delta < 0:
return Verdict.REJECT, f"tests failed: {test_report.fail}"
# 3. 性能回归不能超过 5%
bench = run_benchmark(ctx.bench_dir)
if bench.regression_pct > 5:
return Verdict.REJECT, "perf regression > 5%"
return Verdict.ACCEPT, ai_output过去 50 年软件工程留下的"废墟"——CI/CD、单测、类型系统——恰恰成了新范式最坚硬的地基。 失败的工程化尝试,反而为真正的工程化备好了钥匙。
范式三:Agentic Engineering,确定性前提正在崩塌
2026 年被 LangChain 创始人 Harrison Chase 称为"Agent 工程分水岭"。这一年里,软件工程的确定性前提正在崩塌——决定行为的,不再只是代码,还有模型本身。
过去几十年,软件工程有一个稳定不变的前提:系统的行为写在代码里。工程师读代码,就能推断系统在大多数场景下会怎么运行;测试、调试、上线,都围绕"确定性"展开。这个前提如此基础,以至于没人质疑——就像没人质疑重力存在一样。
Agent 出现后,前提被打破了。在 Agent 应用里,行为由代码 + 模型共同决定,而模型是个在代码之外运行、带着非确定性的黑箱。只靠读代码,已经无法真正理解一个系统;只能让它跑起来,看它在真实输入下做了什么,才知道系统到底在干什么。
这是 Agentic Engineering 的核心命题。它的实践要点有三:
第一,按"业务价值"切分,而非按技术栈。 单元不能按"前端/后端/算法"切,而要按端到端的业务价值切——"用户登录模块""支付下单模块""退款仲裁模块"各自是一个可自治的闭环。一个支付 Agent 跑在独立的沙箱里,具备读订单、调支付通道、写账的完整能力,而不是拆成"读订单 Agent + 调支付 Agent + 写账 Agent"三段互相串。
第二,评估优先于实现。 没有可量化的成功标准,就不要让 Agent 开工。每个 Agent 闭环必须先定义三件事——任务输入空间(覆盖典型业务流 90% 以上的输入形态)、成功判据(可被程序化判定,例如 JSON Schema 校验通过率 ≥ 99%)、失败模式分类(超时 / 幻觉 / 工具调用错误 / 边界输入,每类有对应回退路径)。
第三,反馈必须是结构化的、闭环的、可审计的。 用户每接受或拒绝一次 Agent 输出,这个判断必须以事件的形式沉淀进本地知识库(例如 SQLite + pgvector),成为下一次同类任务的参考。不在本地留痕的反馈,等于在帮模型厂商白打工。
下面是一段最小可跑的 Agent 闭环评估代码,展示"业务自治单元"如何用程序化判据替代人工 review:
# 评估一个退款 Agent 的输出是否符合业务规则
import json
from jsonschema import validate
refund_schema = {
"type": "object",
"required": ["order_id", "amount", "reason", "risk_score"],
"properties": {
"order_id": {"type": "string", "pattern": r"^OD\d{12}$"},
"amount": {"type": "number", "minimum": 0, "maximum": 50000},
"reason": {"enum": ["quality", "late", "wrong_item", "other"]},
"risk_score": {"type": "number", "minimum": 0, "maximum": 1},
},
}
def evaluate(agent_output: dict) -> dict:
try:
validate(agent_output, refund_schema)
if agent_output["risk_score"] > 0.8:
return {"verdict": "human_review", "why": "high risk"}
return {"verdict": "accept", "why": "schema ok"}
except Exception as e:
return {"verdict": "reject", "why": str(e)}这段代码的实际意义:Agent 的输出不再是"人眼看一眼",而是程序化、可审计、可回放的一次判定。 一次 reject 的原因可以被检索、被聚合,成为下次优化 prompt 或工具调用的依据。
范式落地:从"最小闭环"开始的 3 步走
三个范式听上去激动人心,但直觉的"逐个环节替换"是错的。正确的路径是闭环优先、节点开放。
第一步:建立最小的"AI 全流程闭环"。 不要全公司铺开 Copilot,集中火力找一个边界清晰、验证容易的小领域——管理后台的 CRUD、特定 API 封装、监控规则生成。在这个领域里,让 AI 跑通从自然语言需求、到生成代码、自动跑测试、部署验证的全流程。人在闭环里只做两件事:输入任务描述、最终点头验收。
第二步:在闭环内实现"双爬坡"。 一边 AI 模型自身在升级,另一边更关键的是工程规则库在爬坡——每一次 AI 出错被人纠正,这个纠正规则必须沉淀进本地知识库,下次不能再犯。AI 能力 + 规则库,像两个齿轮一样互相咬合着爬坡。一个口径是:每周从纠正日志里抽出 3-5 条高频失败模式,转化为系统级约束。
第三步:复制与扩张。 当这个小闭环的良率稳定下来(经验阈值:80% 的需求能零人工介入实现),就把"AI 全流程 + 确定性裁判 + 知识沉淀"这套模式,像复制生产线一样复制到其他领域。先做形式化程度高的(测试生成、运维脚本),再做难的(系统设计、需求分析)。
新岗位图谱:从"人肉编译器"到"产线设计师"
新范式下,过去很多程序员高薪的本质——为"人肉编译器"的能力付费——正在被系统性替代。但这不意味着岗位消失,而是岗位重新洗牌:
- • AI 产线架构师:最稀缺的终极岗位。负责设计软件生产流水线本身,定义分治结构,规划智能体协作。需要融合软件工程、控制论、领域知识的顶级系统思维。
- • 认知 SOP 工程师:把业务专家和资深开发的"直觉",翻译成 AI 可严格执行的流程、规则和标准。是过去 BP 工程师 + 测试架构师的合体升级版。
- • 偏差守卫专家:AI 系统的"急诊科专家",专门处理千奇百怪的跨领域复杂 bug。需要极强的领域深度、调试能力,以及元认知——知道 AI 不知道什么,比知道 AI 知道什么更重要。
- • 价值函数定义师:定义"什么是好软件"。把商业目标、用户体验、技术债务量化为 AI 产线可优化的客观指标。本质是产品经理 + 数据科学家的合体。
所有新岗位都围绕一个核心:处理不确定性——要么在设计阶段通过系统将其最小化,要么在运行时拥有处理它的超强能力。
真正难的,从来不是技术
三个新范式听上去工程量很大,但拆开看,每一步都有现成工具可以拼。难的从来不是工具,是组织本身——尤其是两件事:
第一件事,是 KPI 改写。 现有绝大多数研发团队的 KPI 还停留在"代码行数、需求完成数、bug 数"这三件套。这套 KPI 在新范式下不仅无效,甚至是反作用——它会让团队继续按"工时计件"的方式使用 AI,而不是按"闭环良率"的方式设计 AI。一线开发者的核心 KPI,必须从"完成需求"改成"将负责模块的隐性知识结构化沉淀进系统知识库"。 经验沉淀率,而不是代码量,才是新范式下的硬通货。
第二件事,是治理。 当 AI 是流程主体时,所有 AI 决策都必须可追溯、可解释、可回滚。这要求企业建立三套基础设施:模型行为审计日志(每一条 AI 输出对应到 prompt、上下文、工具调用链)、业务影响回放(任何一次 AI 上线后 7 天内的业务指标,都能在 30 秒内被还原到 AI 决策上)、红线清单(涉及金钱、账户、支付、凭据的改动,人类必须在场)。
这两件事,任何一件没做对,新范式就会退化成"Copilot 加量版"。工具升级从来不是范式革命,治理升级才是。
50 年后的真正"工程化",靠的不再是更多的方法论
1968 年 NATO 会议给行业留下了"软件工程"这个名字,但真正"工程化"这个目标,要等到 2020 年代后期才具备落地条件。条件不是某一种新方法论,而是三个同时成熟的东西:认知引擎(算力换智能)、确定性裁判基础设施(CI/CD + 类型 + 单测)、业务自治单元切分思维。
三者缺一,任何两个都只是局部优化。三者齐备,软件工程才第一次接近"用能源替代低阶认知"这个工程的本意。
下一阶段的胜负手,不在谁的 Copilot 用得更熟,而在谁先把"AI 中心闭环 + 确定性裁判 + 知识沉淀"这三件套跑通到生产环境。50 年的积累已经够厚,缺的是把积累重新组合的那一步。
