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

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 生成代码出错，谁负责》。

工程能力 on Lingming 灵明