AI重塑软件生产活动
一、代码是意图的拟像
传统软件开发中，编写代码就是实现意图。程序员把需求制作成软件行为，代码是行为的精确描述，也是唯一的真相来源。版本控制的整个世界观建立在这个假设上：变更单元是人对代码的一次编辑，代码文本就是 source of truth，同一次输入必然产出同一份代码，所以 diff 能完整回答"改了什么"，blame 能精确追踪"谁的责任"。
但 AI 时代，这个链条被重新拆解。AI 成了语义编译器，设置在传统编译器的前端：人输入意图（spec、use-case、prompt），AI 输出代码。代码生成成本趋近于零，稀缺性从"写代码"转移到"精确描述正确行为"。与此同时，同一个 prompt 两次生成可能不同，代码不再确定性地对应意图。
于是代码从真相来源降级为拟像，git log 与 blame 随之贬值：当代码可以零成本重新生成，复用与重构都失去了意义，你维护的不再是一段代码，而是一份意图。版本控制的对象，从"代码的增量"变成"意图的演进"。
但这里有一个致命问题：LLM 存在幻觉。AI 作为语义编译器，却不提供语义保持机制。它可能漂亮地实现了一个错误的理解，通过了全部功能测试，但业务意图完全错误。于是核心问题从"如何写代码"变成"如何贯彻意图"——确保 AI 输出的代码，完全、准确的反映意图。
二、劳动凝结面的转移
价值凝结在哪一层，责任就落在哪一层。传统开发里，劳动凝结在代码行上：需求、设计、调试、重构、评审，所有辛苦最终都凝结成代码。代码之所以珍贵、需要复用、需要重构、需要被追责，正因为它是凝结物——包含了人的劳动时间与判断。
AI 打断了这层凝结。作为语义编译器，它把"翻译意图"这一步从人手里接了过去；代码不再经过人类劳动的中转，也就不再承载劳动，从唯一的真相来源退化为一份随时可以重新投射的中间文件。劳动凝结面于是向上游移动——移动到描述意图（spec、use-case），移动到设定约束（不变量、断言、门禁），移动到选择模型与工具链，移动到批准变更与豁免门禁。真正需要长期维护、值得反复打磨的东西，从产物层转移到了意图层与门禁层。source of truth 的形态也随之改变：它不再是某一份代码，而是 spec、用例、不变量与门禁共同构成的约束。
然而理论总是晚于实践，凝结面转移了，责任还留在原地。AI 不能成为责任主体，验证责任在使用方；监管从不打算让 AI 担责，它只要求你证明：有合格的人在监督，并且拿得出证据。还有一条更基础的原则：责任不可外包。人可以外包执行，不能外包后果。
随着劳动凝结面的转移，责任也应随之移动：
L1 AI/工具：无责任能力，只是产物。
L2 提需求、写用例、选模型的人：对输入约束的正确性负责。
L3 设置、关闭、豁免门禁的人：对有没有设网负责——最该被追责的一层。
L4 点 approve 放行的人：对判断负责，前提是 L3 给了他足够的证据。
L5 定义授权范围与流程的人：管理责任，不可下放。
未来的软件也许不在需要重构，不再需要复用，需求变更引发的行为是重写一个新软件。当代码真正变成可丢弃的中间工件，git blame 就失去了意义——你不会去追责一次重新生成，你会问"是哪条约束变了"。追责的对象从代码行转移到 spec 和 use-case：谁写的需求，谁批准的变更，谁豁免了哪项门禁。
三、历史经验
意图层与产物层分离在软件行业已有实践。Knuth 在开发 TeX 时，并没有直接编写 Pascal 代码，而是写了一份文档（WEB文学编程）作为意图层，使用TANGLE程序转换为 Pascal 源代码，这是产物层。他为这个工作流设立了一条规则：不修改产物层，所有变更都进入上游的意图层。
第二个例子来自供应链治理。你不需要审查 log4j 的每一行代码，但是你需要有组件清单，漏洞扫描，准入白名单和应急预案。你不需要证明你所使用的每一个组件都是完美的，也不可能。但你必须知道自己使用了哪些组件、知道如何监控、如何应急。AI 生成的代码也是类似的：你不能也不需要逐行审查每一行AI代码，但你要知道它从哪条规则来、受什么约束、异常场景如何处置。
第三个例子来自制造业的可测试性设计。一块没有预留测试点的电路板在制造业是无法通过评审的。测试能力是设计出来的，是无法在后期补充的。
这些在软件里的对应物是：可控性，即能否把系统置于已知状态；可观测性，即能否看见它的行为。可测试性设计落到软件上，有四种具体的测试点：返回值、事件与消息、事务性发件箱、关联标识加结构化日志。事务性发件箱把副作用和业务数据更新通过同一个本地事务提交，相当于给软件加了一个测试点，让操作可重试、幂等、可审计，也让副作用可观测。
三个例子指向同一条结论：当产物变得廉价且不可信，可靠的办法从来不是更用力地检查产物，而是在上游建立可维护的意图层，在沿途埋下可观测的测试点。
四、正确：从绝对到几乎
传统软件追求"绝不出错"：形式化证明、穷尽测试、防御性编程，目标是零缺陷。但 AI 时代，代码生成是概率性的，绝对正确在经济上不可行。我们需要重新理解软件的正确性，把它从一个绝对命题，改写成一个带误差或概率的命题。它有两个可操作的维度：
几乎不出错（置信区间）：在绝大多数情况下，行为符合意图。
不会出大错（避免失控）：即使出错，错误也被限制在可接受的范围内，不会级联成灾难。
4.1 形式化和代数化
最理想的正确性，是形式化或代数化的：把程序写成可以推演的等式，用证明代替测试，一次证明，处处成立。AWS 用 TLA+ 验证 DynamoDB、S3、EBS 的关键算法，找出的是测试根本抓不到的角落 bug；工程师从零学到能产出可用结果，只要两到三周。SPARK 已用于空客飞管、NVIDIA Drive OS 的 ISO 26262 认证；巴黎地铁 14 号线 1998 年就用了 B-Method。
但这条路不便宜。写不变量和规格的投入，数倍于写代码本身。全量形式化验证在多数业务系统里不可行，所以现实路径是先从局部入手：把关键的、出错代价高的那一小块代数化，能往上推一层就往上推一层。断言的四个等级，就是这条上推路径：
0 级：assert，开发期。Python 加 -O 会整段擦除，连条件都不求值；AssertionError 继承自 BaseException，except Exception 抓不到。
1 级：运行时契约（Pydantic、Zod、Ada 后置条件），Release 生效。能检测到，且可观测。
2 级：精化类型（Ada 的 range、Rust 的 NonZeroI32），编译期。不可能发生。
3 级：静态证明（SPARK、Dafny、Lean），编译期。完全正确性。
1 级是"做了坏事会被抓住"，2 级是"做不了坏事"，3 级是"证明它做不了坏事"。在"不做坏事"这件事上，证明"它做不了"，永远强于统计"它没做"。
4.2 代数化残差：整体不是局部的简单加总
代数化的问题在于现实世界是非形式化的，总有些东西无法用代数描述。这使得正确的模块组合在一起之后未必得到一个正确整体——契约在边界处失效、时序在并发处翻转、状态在组合处爆炸，这些错误都出现在模块之间，不在模块之内。
同时静态正确也不等于动态正确。类型正确、形式推理正确、局部测试通过，在运行时仍然可能发生错误：因为配置错误、依赖降级、资源耗尽、外部系统超时等等，这些都不是静态能完全捕获的。
软件行为的合宜性必须从行为自身直接验证：依靠用例逼近运行时的全部真实行为。好消息是，用例的生成成本也趋近于零了——AI 能批量产出用例、边界组合、模糊输入、回归场景，过去因为"写测试太贵"而被跳过的覆盖，现在第一次变得负担得起。
覆盖率高不代表充分有效。Inozemtseva 与 Holmes 的研究显示：控制住测试套件的规模之后，覆盖率与测试套件有效性只有低到中度相关。覆盖率可能产生欺骗效果：一段代码被执行，不等于已经完成了对其行为所产生的结果进行了验证。真正测有效性的东西是变异分数：往代码里注入一批刻意做小的人工故障——把 > 改成 >=、删掉一行、把 && 改成 ||——然后看测试拦不拦得住。每个被注入故障的版本称为一个变异体；如果注入之后测试失败，说明对代码行为进行了验证，称这个变异体被"杀死"，被杀死的变异体的占比就是变异分数。
4.3 证明之外：失败而不失控
用例再多、覆盖再高，也无法保证"不出错"，总有些异常场景无法在设计时捕获。所以正确性的第三层，不在于追求绝对无错，而是保证在失败时不失控。"不做坏事"必须靠结构保证，不能依赖测试，测试只是采样。因此要重新理解"正确"这个词汇的内涵：正确不是"零缺陷"，而是"置信区间可控、爆炸半径可控"。
五、结语
AI 时代，软件正确性的定义被永久改写：我们不再追求绝不出错，而是追求几乎不出错（置信区间）与不会出大错（避免失控）。前者靠局部代数化与海量用例去逼近，后者靠断言保护。
代码的制作成本趋近于零，并不等于制作出可靠代码的成本趋近于零。生成一段能跑的代码几乎不花钱，但要证明这段代码值得信任，依然很贵——这份成本没有消失，只是换了地方：从"写"转移到了"证明"。
AI 时代的软件生产，重心必须整体后移：从关注软件如何被制作出来，转向关注它为什么值得信任。真正值得投入的，是可检查的规格、不可绕过的门禁、可断言的爆炸半径，是一个可以经得住检验的可靠过程。
转载自 CSDN-专业IT技术社区
