AI 编程 on Lingming 灵明

黑箱转向（六）：从编码者到约束设计者？

Lingming — Sat, 07 Mar 2026 17:33:26 -0500

“以后工程师不用写代码，只要写规范”是一句很诱人的预测。它把职业变化压缩成从低层劳动到高层设计的升级，也避开了一个麻烦事实：如果不会阅读、运行和调试实现，人凭什么判断模型是否满足规范？

上一篇把架构解释为对故障半径、权限和时间的设计。本篇讨论承担这些工作的人。结论带一个问号：工程师确实会把更多时间放在约束和验证上，但“约束设计者”更适合作为能力重心，而不是已经取代程序员的新职业。

先区分任务变化与职业消失

一份工作由许多任务组成。代码补全可能大幅自动化样板实现，却不必然自动化需求协商、遗留系统判断、安全取舍、生产事故和组织责任。即使模型能够独立完成越来越长的编码任务，企业也要决定它可以访问什么、怎样验证输出，以及失败时谁行动。

现有数据不支持所有团队已经进入同一种未来。2025 年 Stack Overflow 调查中，AI 工具使用广泛，但代理尚未成为主流，多数受访者也不把 vibe coding 视为专业工作方式。METR 对资深开源开发者的早期实验观察到特定场景下的减速，2026 年后续则认为新工具可能已经带来加速，却无法消除选择偏差。DORA 的组织研究强调，AI 会放大现有平台和流程的优劣。

因此，更可靠的问题不是“程序员何时消失”，而是：

哪些任务的边际成本正在下降，哪些能力因而成为新的瓶颈？

实现变便宜后，六类工作更加显眼

定义问题

模型需要目标，但真实需求常包含冲突：更快与更安全、更灵活与更可审计、用户便利与隐私保护。工程师要把模糊愿望变成可以讨论的成功条件、禁止行为和风险预算。

这不是简单把产品经理的话改写成 prompt。约束之间可能矛盾，利益相关者可能漏掉边界，工程师必须利用领域和技术知识指出不可能三角。

配置上下文

生成质量取决于模型能看到哪些代码、文档、工具结果和历史决定。上下文不是越多越好：无关信息会增加噪声，敏感信息会带来泄漏风险，过时文档会稳定地产生错误方向。

工程师需要选择可信来源、标明优先级与有效期，并保证生成器不会把示例误当成规范。

划定权限

一个只能提出 diff 的助手，与一个能修改云资源、运行迁移和向用户发消息的代理，风险完全不同。约束设计包括工具白名单、沙箱、资源预算、审批点和不可逆操作边界。

权限设计比提示词更接近真正的控制，因为它能在模型判断错误时仍然阻止某些后果。

审查与整合

生成代码仍然要进入既有系统。工程师需要检查接口、数据、性能、安全、可运维性和历史兼容约束。审查不是阅读模型的“思维过程”，而是判断制品和证据能否支持合并主张。

当变更太大而无法认真审查，正确反应通常是拆小，不是降低理解标准。

建立保证证据

契约、性质测试、静态分析、依赖验证、威胁模型和渐进发布把自然语言意图变成不同强度的证据。工程师必须知道每种方法能发现什么、遗漏什么，而不是让模型同时生成实现与一套只会支持自己的测试。

运行并学习

生产系统会遇到训练数据和测试环境没有覆盖的条件。指标、事件、用户反馈和事故复盘应当反向修正规范、测试与架构。约束设计不是一次性写完文档，而是一个持续校准过程。

一条完整的生成式工程闭环

可以把上述能力组织成六步：

定义。 写出目标、非目标、禁止行为和风险等级。
限制。 选择上下文、工具、数据与权限边界。
生成。 让模型产生足够小、可以独立审查的候选变化。
检验。 由人和独立工具检查实现、性质、依赖与失败模式。
发布。 通过灰度、限流和恢复计划控制真实影响。
校准。 根据运行证据更新规范、测试和工具策略。

这个闭环没有把“编码”彻底删掉。模型可能承担第三步的大部分文本生产，人仍可能在任何一步直接修改实现，尤其是调试模型难以处理的边界、性能和底层系统问题。

为什么编码能力仍然重要

约束不是凭空出现的。要定义合理接口，必须理解实现成本；要写有区分力的不变量，必须理解状态怎样变化；要判断性能风险，必须理解算法、内存、网络和数据库；要处理事故，必须从观测信号回到具体执行路径。

如果工程师完全失去这些能力，会出现三种反向依赖：

无法识别模型给出的不可能保证；
无法在工具失效时缩小与定位问题；
只能用更多自然语言修补一个尚未理解的实现。

因此，阅读、调试和编写代码不只是旧时代手艺，也是约束设计的经验基础。任务比例可能变化，基础能力不会因为抽象层提高而自动失效，就像架构师仍需理解软件与系统边界。

“Prompt 工程”为什么不够

提示词是生成接口的一部分，通常缺少稳定版本、机器可检查语义和独立执行约束。措辞变化、上下文顺序和模型版本都可能影响结果。

成熟的规范体系还包括：

版本化需求与架构决定；
类型、模式和接口契约；
权限与资源政策；
可执行测试和不变量；
质量门槛与发布规则；
运行服务目标和事故流程。

Prompt 可以引用这些资产，却不应成为唯一事实来源。“把提示写得更聪明”无法替代组织对边界和后果的明确决定。

约束设计者也可能设计错约束

把职业叙事从“代码作者”升级为“系统裁决者”，容易制造新的自信幻觉。规范会遗漏，指标会被优化，测试会与真实用户脱节，架构边界也会转移风险而非消灭风险。

所以约束本身需要审查：

谁参与定义，谁的利益没有进入？
哪些性质可执行，哪些只存在于文档？
一个指标改善时，是否牺牲了未测量目标？
模型、测试和审查是否共享同一错误假设？
谁有权放宽边界，谁负责观察结果？

约束设计不是站在代码之上的绝对控制，而是把假设变成可见、可挑战和可更新的工程对象。

结语：角色在扩展，不是在脱离实现

AI 编程最可能发生的变化，是让高水平工程从“亲自产生全部文本”进一步转向“组织问题、候选实现和保证证据”。这确实强化了约束设计能力。

但真正可靠的新工程师不是不懂代码的指令发起者，而是能够在不同层级往返的人：他能定义边界，也能进入实现；能使用生成器，也能拒绝其答案；能看自动测试，也能判断测试遗漏；能提高吞吐，也能为生产后果负责。

“约束设计者”如果要成为有用概念，代表的不是摆脱编码，而是对整个生成—验证—运行闭环承担更完整的工程责任。

延伸阅读与参考资料

上一篇：《黑箱转向（五）：架构即风险几何》；下一篇：《黑箱转向（七）：AI 生成代码出错，谁负责》。

黑箱转向（四）：控制不可读之物，需要哪些证据

Lingming — Tue, 03 Mar 2026 14:53:41 -0500

假设 AI 生成了一个转账函数，单元测试全部通过。我们能否据此放心上线？

还不能。测试可能只覆盖余额充足的正常路径，没有检查重复请求、并发扣款、货币精度、审计记录或下游超时。即使每一行代码都由人写，问题也一样存在。阅读能够发现某些错误，却无法穷尽输入、状态和环境；测试能够提供行为证据，也无法证明需求本身完整。

上一篇讨论团队理解与系统之间的认知债。本篇转向工程保证：当完整理解不可得时，怎样建立足够但不虚假的信心？

不是从“实现控制”切换到“约束控制”

接口契约、不变量、测试先行和形式验证都早于生成式 AI。它们不是黑箱时代突然出现的新方法，也没有取代实现检查。AI 改变的是相对成本：候选实现更容易产生，明确性质和核验证据便显得更稀缺。

因此，更准确的方向不是二选一，而是从单一证据转向分层保证：

说明我们主张系统满足什么，用相互独立的方法支持这项主张，并诚实记录仍未覆盖的条件。

这与安全关键领域中的 assurance case 思路相近。控制不是“测试绿了”的感觉，而是一条可以被质疑的主张—证据链。

第一层：先证明问题被定义

转账功能的第一层不是代码，而是业务和风险要求：

金额必须为正，并使用明确的货币与精度规则；
同一幂等键不能造成重复扣款；
未授权主体不能发起转账；
余额与账本必须保持一致；
下游超时不能留下无法判定的中间状态；
每次变更必须留下可审计记录。

这些要求包含功能、禁止行为和失败处理。若团队只给模型一句“实现转账 API”，生成器会用训练数据中的常见模式填补空白。实现可以整洁，却不一定符合这个组织的真实制度。

需求层的证据来自领域专家确认、威胁建模、历史事故、法规和用户场景。它的盲点是自然语言可能歧义，利益相关者也可能遗漏风险。

第二层：把关键性质写成契约和不变量

契约把部分要求变成更精确的边界：

前置条件：调用者已授权，金额与货币合法；
后置条件：成功时借贷双方账本变化守恒；
不变量：任何时刻总账不能因内部转账凭空增加或减少；
接口保证：重复幂等键返回同一业务结果。

类型系统、数据库约束、状态机和权限策略都可以承担这种工作。它们让一部分错误变得不可表达，或者在边界处立即失败。

但契约不会自动正确。若把“每天限额”写错，机器可以完美验证一个错误规则；若性质没有包含隐私泄漏，形式上的资金守恒也不能证明系统安全。约束减少行为空间，不替我们决定哪一个空间值得允许。

第三层：用多种测试探索性质

示例测试适合固定已知场景；性质测试从更广输入中寻找反例；状态机或模型测试适合检查操作序列；模糊测试可以探索解析器和协议边界；故障注入则检查依赖失败时的系统反应。

对于转账系统，可以让生成器产生不同金额、账户状态、重复请求和并发顺序，持续检验余额守恒与幂等性。QuickCheck 在 2000 年已经展示了用随机数据检验程序性质的方法，这并不是 AI 时代的新发明。

测试的力量在于找到具体反例，而不是证明“所有可能情况都没问题”。测试数据分布、模拟环境和断言质量都会限制结论。AI 可以帮助提出边界案例，也可能生成与实现共享同一误解的测试，因此高风险性质需要独立来源。

第四层：检查实现，而不是宣布实现无关

代码审查、静态分析、依赖扫描、动态分析和渗透测试仍然重要。行为测试可能发现“发生了错误”，实现分析更容易解释错误怎样发生，以及是否存在同类模式。

代码覆盖率在这里仍有用途：它能指出测试从未执行的语句或分支。它不能证明需求已经覆盖，也不能衡量断言质量。所谓“行为覆盖”如果不定义行为模型、输入分区和性质集合，就只是一个好听的新标签。

更合理的关系是：

需求覆盖问：重要主张是否有证据；
代码覆盖问：实现结构哪些区域从未执行；
性质测试问：给定生成分布是否找到反例；
变异测试问：测试是否能识别人为注入的错误；
静态分析问：是否存在某类结构性缺陷。

这些维度互补，没有一个可以单独取代其余部分。

第五层：用形式验证承担适合它的高风险主张

形式验证可以证明实现相对于形式化规格满足某些性质。seL4 微内核展示了机器检查的功能正确性证明能够达到很深层级，同时也明确列出编译器、硬件和规格等可信假设。

这正说明形式证明的边界：它证明的是模型中写出的性质，不是现实世界的一切正确性。完整验证成本高，也不必施加在每段低风险业务代码上。

更现实的做法是风险分配：

用类型和约束处理大量局部错误；
用模型检测检查有限状态协议；
用求解器验证关键权限与资源性质；
对安全内核、加密协议或高后果控制器投入更强证明；
对其余系统保留测试、审查和运行防护。

AI 可能帮助生成规格或证明，但规格与证明脚本仍需独立检查。由同一个模型同时提出实现、测试和“证明”，容易产生相关性失败。

第六层：上线以后仍需验证

前五层都无法完整复制生产环境。真实流量、数据分布、依赖故障和运维操作会暴露新的条件，因此保证必须延伸到运行期：

灰度或金丝雀发布限制初始影响；
指标、日志和追踪帮助识别越界；
对账和审计任务检查业务不变量；
限流、熔断与权限边界限制传播；
降级、前滚修复或回滚缩短影响时间；
事故复盘把新事实反馈到需求和测试。

运行监控不是承认前面的工程失败，而是承认开放系统总会遇到模型外事实。

把证据放进同一张表

层级	转账案例中的主张	主要证据	不能单独证明
需求	这是正确的业务与风险目标	领域评审、威胁模型	要求无遗漏
契约	关键状态必须守恒	类型、约束、不变量	契约符合现实意图
测试	代表性场景满足性质	示例、性质、故障注入	输入空间已经穷尽
实现	没有已知结构性缺陷	审查、静态与动态分析	所有行为正确
形式验证	指定模型满足指定性质	机器检查证明	模型外环境安全
运行验证	真实系统保持在边界内	监控、对账、灰度	未来不会出现新风险

这张表的价值不在于让流程变长，而在于防止证据越权。测试通过只能支持它实际检查的主张，代码可读也只能提高发现某些错误的机会。

结语：控制是可审查的信心

黑箱系统最危险的不是我们没有读过全部实现，而是我们无法说清自己凭什么相信它。

分层保证保留了理解的价值，也承认理解的边界。工程师可以阅读关键实现，同时用契约限制状态、用测试搜索反例、用形式方法证明高风险性质，并在运行期准备发现和恢复。

控制不可读之物，不是把内部过程忘掉，而是让每项重要主张拥有与其风险相称的证据。

延伸阅读与参考资料

上一篇：《黑箱转向（三）：认知债——团队知道得越来越少吗》；下一篇：《黑箱转向（五）：架构即风险几何》。

黑箱转向（三）：认知债——团队知道得越来越少吗

Lingming — Mon, 02 Mar 2026 11:45:57 -0500

一次故障发生在周五深夜。代码风格整洁，测试也不少，但值班工程师无法回答三个问题：这个重试为什么设置为五次？两个状态字段为何必须一起更新？删除某段兼容逻辑会影响哪一批旧客户？

问题不是代码不可见，而是让团队安全修改它的知识没有留在可调用的位置。上一篇把生成拐点定义为实现吞吐超过保证吞吐。本篇讨论这种落差积累后的一个结果：认知债。

认知债不是“没人读过全部代码”

大型系统本来就不需要每个成员理解所有细节。健康的抽象允许团队只掌握与职责相称的部分。若把“不知道每一行”都算作债务，模块化本身就会成为问题。

本文采用一个更窄的定义：

认知债，是团队为了安全解释、修改和恢复系统所需要的知识，与当下能够及时调用的知识之间的缺口；这项缺口把成本和风险推迟到未来。

这个定义包含两个限制。第一，缺少的必须是未来任务真正需要的知识，而不是任何可能知识。第二，它必须产生延迟成本，例如变更更慢、审查失真、事故恢复困难或关键人员离开后风险上升。

因此，认知债不能仅凭代码行数、AI 生成比例或主观陌生感判断。它需要在具体任务中表现出来。

它与技术债、意图债有什么不同

技术债通常位于软件制品中：重复逻辑、脆弱依赖、缺少测试、不合理耦合。即使没人意识到，它们仍可能通过分析和重构被发现。

认知债位于团队与系统的关系中。同一份代码，对长期维护者可能没有认知债，对刚接手且没有文档的团队却可能风险很高。

还可以进一步区分意图债：系统保留了“做了什么”，却没有保留“为什么这样做”、替代方案为何被拒绝、哪些假设可能过期。意图债是认知债的重要来源，但两者不完全相同。团队也可能拥有设计记录，却缺乏把它应用到当前故障的能力。

债务	缺口主要在哪里	常见表现
技术债	代码与架构制品	改动牵一发而动全身、缺陷反复出现
认知债	团队可调用的心智模型	接手慢、审查无法质疑、事故定位困难
意图债	决策理由与约束记录	不敢删除旧逻辑、反复争论已解决问题

三者会相互强化，但治理手段不同。重构可以减少技术债，培训和轮岗可以减少认知债，决策记录和需求追踪更适合处理意图债。

AI 如何增加认知债

AI 并不是唯一来源，却会放大几种积累机制。

先有答案，后补问题模型

工程师在充分理解领域之前就得到可运行实现，容易把熟悉的代码形状误认为正确的问题模型。系统可以通过当前测试，却没有人能说明未测试的边界。

生成批量大于学习批量

一个人可能逐行编写时顺便形成局部心智模型；一次接受数百行跨模块变更时，这种伴随学习不会自动发生。阅读者如果只确认表面合理，就把理解成本推给未来维护。

设计理由停留在临时对话

模型对话可能包含关键约束、失败尝试和方案取舍，但最终仓库只保存代码。聊天记录即使被保留，也常常过长、含噪且难以检索，不能直接等同于设计文档。

能做出来被误认为能够维护

代理可以在熟悉基准上完成任务，却未必掌握组织内部历史、合规规则和运行经验。团队若因为生成成功而削弱人工所有权，故障发生时会发现工具和人都缺少完整上下文。

AI 也可能减少认知债

认知债不是使用 AI 的必然结果。同一种工具也能解释陌生模块、生成调用图、比较方案、补充测试、整理事故记录或把隐性知识转成可搜索文档。

关键差别是它承担哪一种角色：

替代角色：直接交付答案，人类跳过建模与质疑；
脚手架角色：帮助人类建立、检查和外化心智模型。

2026 年一项针对本科软件工程项目的初步定性研究把类似现象称为 comprehension debt。研究从学生反思记录中识别出黑箱式接受、上下文不匹配和绕过验证等积累模式，也观察到把 AI 用作理解脚手架的缓解模式。它提供了有用线索，但样本来自教学项目，不能直接外推到所有专业团队。

怎样观察认知债

认知债目前没有公认的单一指标，也不适合用一个分数制造虚假精确。可以组合观察以下信号。

修改前的预测能力

在查看测试结果之前，维护者能否预测改动会影响哪些模块、数据和用户？预测长期偏差，说明心智模型与实际系统脱节。

接手与解释成本

新成员完成一个真实变更需要多久？审查者能否用自己的话解释关键不变量？如果只有提示操作者能够继续工作，知识并未真正进入团队。

事故诊断能力

平均恢复时间上升不一定来自认知债，但事故中反复出现“没人知道为什么”“只能试着回滚”“不敢动这段代码”，是更直接的定性证据。

决策理由覆盖

高风险模块是否保存了关键约束、被拒方案和有效期限？文档数量不是重点，能否在需要时找到并验证才是重点。

审查的质疑密度

审查是否只剩格式和测试通过，还是有人挑战需求、权限、失败方式与可运维性？完全没有异议的大批生成变更，不一定代表质量极高，也可能代表审查者没有形成模型。

怎样偿还，而不是制造文档仓库

缩小生成批量。 让每次变化足够小，使审查者能解释其目的、边界和风险。
要求教回。 合并前由负责人不用模型复述关键数据流、不变量和失败模式。
保存决策，不保存全部对话。 把长对话压缩为简短的架构决策记录，并说明假设何时需要复查。
让测试表达性质。 除了示例输入输出，还记录为什么这个性质重要，以及哪些区域尚未覆盖。
轮换真实所有权。 通过结对、值班和跨人审查检验知识能否转移。
删除不必要实现。 AI 让增加代码很便宜，更需要把删除、合并和依赖收缩当作正式工作。
在事故后更新模型。 复盘不仅修 bug，还要说明此前哪条理解错误、怎样让下一位维护者更早发现。

这些做法的目标不是让每个人背下系统，而是让关键知识不只存在于某次生成会话、某个人的记忆或一个无法验证的解释里。

结语：债务来自延迟，而不是无知本身

工程师永远会对系统有所不知。健康工程的目标不是消灭未知，而是把未知放在合适边界内，并为重要未知配置验证和恢复机制。

认知债出现于另一种情况：团队今天接受了自己尚未理解、也没有外部证据充分约束的变化，把解释和维护成本推迟给未来。AI 让这种借款更容易，也能帮助偿还。决定方向的不是工具是否生成代码，而是组织有没有把理解视为需要持续维护的共同资产。

延伸阅读与参考资料

上一篇：《黑箱转向（二）：生成—验证落差，真正的拐点》；下一篇：《黑箱转向（四）：控制不可读之物，需要哪些证据》。

黑箱转向（二）：生成—验证落差，真正的拐点

Lingming — Mon, 02 Mar 2026 11:38:38 -0500

一个代码代理十分钟生成五个文件，并不意味着团队获得了十分钟的交付。有人仍要确认需求没有误解、依赖没有引入风险、边界条件得到处理、测试没有只证明理想路径，上线后也不会破坏既有数据。

代码生成把“得到一个可运行候选方案”变得很便宜，却没有同比例压缩其余工作。上一篇说明，大型软件早已依靠局部理解运行。本篇要定位 AI 带来的新增压力：不是软件第一次超出个体认知，而是实现吞吐量可能开始持续超过保证吞吐量。

代码产量不是软件生产率

软件工作的产出不是代码文本，而是被用户使用、能够维护并承担后果的系统变化。新增行数甚至未必是正向指标：更短的实现可能更好，删除不必要代码也可能比增加功能更有价值。

因此，“模型每秒生成多少行”无法直接与“工程师每小时写多少行”比较。模型可以快速制造候选实现，工程师则还在完成问题建模、取舍、集成和验证。两者不是同一种计量单位。

更合适的链条是：

需求澄清 → 候选生成 → 人工审查 → 自动验证 → 系统整合 → 渐进发布 → 运行反馈

AI 主要压缩其中一部分，有时也能帮助测试和解释，但任何未被压缩的环节都可能成为新瓶颈。候选代码越便宜，团队越容易把瓶颈从“写不出来”转移到“看不完、接不上、无法放心上线”。

现有证据不支持一个整齐的全球拐点

截至 2026 年，AI 编程的使用率和效果都在快速变化，但研究结果仍取决于任务与人群。

2025 年 Stack Overflow 开发者调查显示，很多开发者已经使用 AI 工具，但 72% 的相关受访者表示 vibe coding 不是其专业工作方式；对 AI 准确性持不信任态度的人多于信任者。高责任的部署与监控任务也最少被计划交给 AI。这说明“广泛辅助”不能直接改写成“AI 已是主要代码生产者”。

METR 在 2025 年对熟悉自己大型开源仓库的资深开发者进行随机实验，观察到允许使用当时 AI 工具的任务平均耗时反而增加。2026 年的后续说明认为较新的工具可能已经带来加速，却也指出不愿在无 AI 条件下工作的参与者造成了样本选择问题，无法给出稳定总体估计。

DORA 2025 的结论更适合这组复杂证据：AI 像一个放大器。它可以提高个人效率和交付吞吐，也可能同时增加交付不稳定性；平台质量、内部开发体验、小批量变更和清晰的组织政策会显著影响结果。

所以，本系列不把 2026 年某一天宣布为统一的“生成拐点”。拐点发生在具体团队内，而且需要用实际交付数据识别。

真正的落差发生在哪里

生成—验证落差至少有四种来源。

需求落差

模型可以忠实实现一条错误或不完整的需求。代码越快出现，团队越可能把“已有实现”误当作“问题已经被定义”。需求中的权限、失败处理、兼容性和非功能约束若没有先说清，后续审查只能在成品中反向猜测。

意图落差

人手编写也可能缺少设计理由，但 AI 会让这种情况更容易规模化。一个实现可能来自几轮对话、临时上下文和模型默认选择；仓库只保存最终 diff，没有保存哪些方案被排除、哪些假设仍不确定。

审查落差

生成工具可以一次交付大批变化，而审查者的注意力仍有限。大批量 diff 会降低逐项质疑的概率，“测试是绿的”很容易成为替代性判断。此时问题不一定是代码不可读，而是组织没有为阅读支付足够时间。

整合落差

模型擅长局部任务，不代表它掌握组织特有的部署约束、历史兼容负担和隐性业务规则。一段局部合理的实现，可能扩大依赖、破坏性能预算或绕过已有治理流程。真正昂贵的工作常发生在模块边界。

怎样判断团队是否越过了自己的拐点

不要只统计生成代码占比。更有用的是同时观察流量、质量和理解。

维度	可观察指标	危险信号
变更流量	PR 大小、并行变更数、审查等待时间	生成量上升，审查队列持续增长
返工质量	首次通过率、回退率、缺陷逃逸率	合并更快，返工与事故同步增加
系统整合	构建失败、兼容问题、依赖增长	局部测试通过，集成频繁失败
团队理解	设计理由覆盖、模块接手时间、事故定位时间	只有生成者会操作，没人能解释边界
运行结果	变更失败率、恢复时间、用户影响	吞吐增加，稳定性下降

当候选实现增长快于审查与运行保证，并且返工、恢复和接手成本持续上升，团队才真正越过了自己的生成拐点。

缩小落差，而不是限制一切生成

解决办法不是给 AI 设置一个统一代码配额，而是让生成批量与保证能力匹配。

先写成功条件、禁止行为和非功能约束，再请求实现。
把任务拆成能被独立审查的小变化，限制一次跨越的模块和权限。
要求每次生成同时提供测试主张、未覆盖边界和关键设计取舍。
对高风险代码保留更强人工审查、静态分析和独立验证。
用团队交付结果评估工具，而不是只看补全接受率或生成行数。
发现审查队列和认知债上升时，优先删除、合并和澄清，而非继续堆积实现。

AI 有时也能缩小验证成本，例如生成性质测试、解释陌生模块或帮助定位依赖。但这些输出同样需要核验。工具能够参与保证流程，不等于它可以为自己的结果签发可信证明。

结语：拐点是一条反馈曲线

生成式 AI 最重要的变化，不是把源代码变成神秘物体，而是解除实现产量原有的人力摩擦。这个变化可能释放创造力，也可能让组织更快地积累未经充分验证的系统。

真正的分水岭，不在于模型一次写了多少行，而在于团队能否让问题定义、审查证据、运行反馈和责任容量跟上。生成快于验证只是风险条件；是否滑向黑箱，要看组织怎样响应这条落差。

延伸阅读与参考资料

上一篇：《黑箱转向（一）：软件工程从来不是完全的白箱》；下一篇：《黑箱转向（三）：认知债——团队知道得越来越少吗》。