后记：没有人的回路，就没有软件工程

本文是「企业级应用中 Harness Engineering 的实践与思考」系列的后记。

当 AI 能够承担越来越多分析、实现、审查、测试和协调工作时，一个过去很少被认真追问的问题开始浮出水面：

软件工程还为什么需要人？

这里说的回路，不只是代码执行回路，也不是某个审批节点，而是软件从目标被提出、价值被判断、风险被接受、结果被确认，到责任被承担的完整回路。

这个问题不是一个情绪问题，也不是一个立场问题。它是 AI 进入软件工程之后，整个领域第一次无法绕开的主体问题。

软件工程第一次失去了默认主体

过去的软件工程一直有一个默认前提：人是核心执行者。

人理解需求，人写代码，人做审查，人做验证，人设计架构，人判断风险，人确认结果，人承担责任。

正因为这个前提过于自然，很多问题并没有被真正追问。

为什么一定要人理解需求？为什么一定要人做架构判断？为什么一定要人审查？为什么一定要人批准？为什么最终必须有人确认？

过去的答案往往是隐含的：因为除了人，也没有别的执行者能够稳定承担这些事情。

所以，很多机制虽然在经验上是合理的，却不一定有完整的理论闭环。大家知道需要审查，需要流程，需要验证，需要责任闭环，但很少需要追问到最底层：为什么一定要有人在这里？

AI 出现之后，这个问题第一次被系统性地摆到台面上。

如果 Agent 可以分析需求、生成代码、执行测试、审查实现、总结报告、推动流程，那么人是不是只是低效的审批者？人是不是系统中的噪声？人是不是系统瓶颈？人是不是不可靠？人是不是因为不稳定、不可控、能力有限，所以应该被逐步移出主回路？

这些问题的出现，说明软件工程正在经历一次主体变更期。很多过去被“人类天然存在”遮住的问题，现在被 AI 暴露出来了。

于是，很多看起来是工程方案之争的问题，背后其实已经开始触及更底层的追问：什么是开发？什么是工程？什么是责任？什么是正确？什么是协作？什么是知识？什么是组织？什么是价值？什么是验证？什么是治理？当默认主体不再天然是人时，软件工程应该如何重新安放人？

这不是“人还要不要写代码”的问题，而是“人是否仍然是软件工程中的责任主体和价值主体”的问题。

工程控制为什么会进入软件工程

工程控制论从来不是软件工程专享的东西。

很多工程领域早就面对过类似问题：系统太复杂，反馈太快，风险太高，人类不能也不应该直接站在所有控制回路里。

巨轮不能靠人手直接修正每一次姿态变化，飞机不能靠飞行员直接响应每一个气动扰动，燃气轮机不能靠人眼判断每一次燃烧状态，化工反应釜不能靠操作员手动调节每一个温度和压力波动，机械臂也不能靠人类逐帧控制每一次运动轨迹。

在这些场景里，把人从某些底层执行回路中移出去，让传感器、控制器、模型和反馈系统接管高频、稳定、精确的控制，是工程进步。

现在，AI 进入软件开发之后，软件工程也开始面对类似的诱惑。

既然 AI 可以更快地阅读、生成、修改、验证代码，既然 AI 可以承担越来越多过去由人完成的执行工作，那么软件开发是不是也应该像其他工程系统一样，把人从回路中尽量移出去？是不是可以像无人工厂一样，设计一种无人化的软件工程？

这个问题并不奇怪。新的生产力出现之后，旧的软件工程思想显然还没有完全匹配它。于是各种新的设想都会出现：更自主的编码方式，更原生面向 AI 的工作流，更少的人为确认，更接近自动运行的软件生产系统。

所以，认为人低效、不稳定、不可靠，进而希望用更强的控制系统把人逐步移出软件工程回路，并不是一个凭空出现的想法。它有现实来源，也有工程诱惑。

我反对的不是控制，而是无人价值回路

需要先说清楚：我并不反对工程控制，也不反对自动化、流程、反馈系统和硬工具。

恰恰相反，软件工程从诞生开始就一直在吸收这些东西。它不断追求更高的自动化，更短的反馈链路，更好的可观测性，更清晰的权限边界，更稳定的质量度量，更高的可访问性和性能。

这些都是工程化的重要部分。

这里说的无人价值回路，指的不是让机器承担更多执行，而是让目标定义、偏差判断、风险接受和责任归属也逐渐脱离人。

我不能接受的是另一种推论：因为人不完美、低效、容易犯错，所以为了追求更完美、更高效、更聪明的软件工程系统，就应该把人从软件工程的整个回路中逐出去。

这个推论看似工程化，实际上偷换了问题。

问题不在于要不要控制，而在于控制的目标由谁定义；问题不在于要不要自动化，而在于偏差由谁判断；问题不在于系统能不能高效执行，而在于后果由谁承担。

把人从重复执行中解放出来，是工程进步。把人从价值判断中驱逐出去，是工程失根。

软件的正确性不是纯工程指标

软件工程和很多工程的不同之处在于，它的产出物是软件，而软件最终嵌入人的生活、组织、商业、制度和社会关系之中。

软件当然需要工程意义上的正确。它需要能运行，需要稳定，需要安全，需要可维护，需要性能达标，需要通过测试，需要符合约束。

但“正确的软件”从来不只是没有 bug、性能达标、指标提升。

一个软件是否正确，还取决于很多无法被纯工程指标覆盖的问题：什么是合理流程，什么是好的体验，什么是公平，什么是隐私，什么是伤害，什么是可接受风险，什么是不该被优化的目标。

这些问题不是传感器能够直接捕获的。

传感器可以告诉我们温度、速度、电压、压力和故障率。日志可以告诉我们请求量、点击率、转化率、响应时间和错误率。测试可以告诉我们某个条件下行为是否符合预期。

但它们无法独自回答：这个目标是否应该被追求？这个优化是否值得？这个体验是否尊重人？这个风险是否可以接受？这个系统正在塑造什么样的行为？

软件的“正确”不是自然界给出的物理常数，而是人类社会不断变化的判断。

因此，软件工程不能脱离人来定义完美的软件。没有人的价值判断，软件工程最多只能优化一个被给定的目标；但它无法回答这个目标是否应该被优化。

软件也在塑造价值

如果说上一层问题是软件必须接受人的价值判断，那么更深一层的问题是：软件本身也会反过来塑造人的判断。

软件不只是被社会的价值观和审美引导，它也会反过来塑造社会的价值观和审美。

一个为特定群体设计的软件，可能让原本被忽视的身份、关系和需求被看见。一个优秀的交互系统，可能改变大众对“好用”“自然”“高级”的理解。一个推荐系统，可能改变人们获取信息、形成偏好和参与公共讨论的方式。一个企业软件，可能改变组织如何定义效率、责任和协作。

软件不是中性的容器。

它会定义哪些行为更容易发生，哪些行为更难发生；哪些需求被放到台前，哪些需求被藏到角落；哪些价值被不断强化，哪些价值被逐渐淡化。

所以软件工程不能只问“怎样把需求实现得更快”。它还必须追问：我们正在把什么样的行为工程化？我们正在把什么样的判断写进系统？我们正在让什么样的关系、效率、审美和权力结构变得默认？

这些问题并不因为软件开发被 AI 加速而变轻。恰恰相反，当软件能够以更快速度被生成、修改、部署和放大时，它对人的行为、组织和社会的影响也会被更快放大。

因为 AI 不只是让软件出现得更快，也让错误目标被实现得更快。

只有不完美的人，才能理解不完美的人

人当然不完美。

人会犯错，会犹豫，会低效，会受情绪影响，会被经验限制，也会在不同价值之间摇摆。人今天觉得好的东西，明天可能不再觉得好。一个社会今天接受的做法，明天可能认为它越界。审美会变，制度会变，风险容忍度会变，人对尊严、隐私、公平、效率和自由的理解都会变。

但这恰恰不是把人移出回路的理由。

软件服务的对象正是这样的人。软件嵌入的世界也正是这样一个不断变化、不断争论、不断重新定义自己的社会。

如果人是稳定、完美、一致、可形式化的，也许我们真的可以把价值判断一次性写进目标函数，让系统沿着它自动优化。但现实不是这样。

人的不完美不是软件工程试图消除的噪声，而是软件工程必须服务和回应的现实。我们不只是被迫接受这种不完美，也应该允许这种不完美、保护这种不完美，甚至在某种意义上赞美这种不完美。因为人的犹豫、变化、差异、争论和重新判断，正是人之所以为人的一部分。

为人服务的软件，绝对不应该追求一种抹平差异、消除犹豫、压平情绪、统一价值的所谓“完美”。

人在回路不是建立在人类完美之上，而是建立在人类不可被完全形式化之上。

人留在回路中，不是因为人永远正确，而是因为只有身处社会之中的人，才会不断感知、争论、修正和重新定义什么是值得做的，什么已经不应该继续做，什么风险已经不能接受，什么结果必须被负责。

把人移出价值回路，不是消除了不确定性，而是把最重要的不确定性伪装成已经被解决。

这也是为什么一个没有人的系统，只能优化被给定的目标，却无法判断目标本身是否仍然应该成立。

一个系统可以非常稳定、高效、聪明地优化目标。

它可以持续提升指标，可以减少故障，可以提高吞吐，可以降低成本，可以更快生成代码，可以更快完成测试，可以更快推动流程。

但系统无法自己证明目标值得。

历史数据只能告诉系统过去发生过什么，不能告诉系统未来应该避免什么。指标只能描述局部变化，不能决定什么值得被优化。模型可以生成方案，不能承担方案造成的责任。

如果目标本身错了，一个强大的系统只会把错误执行得更稳定、更高效、更大规模。

这不是工程能力不足的问题，而是工程能力过强之后暴露出来的问题。

当系统还很弱时，错误目标的伤害可能被执行能力限制住。当系统越来越强，越来越自动化，越来越能够独立推进，目标本身是否正确就变得更加关键。

所以，软件工程不能只追求让系统更聪明、更高效、更自动。它还必须保留一种能力：在系统运行得很顺畅的时候，仍然能够停下来追问，它正在优化的东西是否仍然正确。

这个问题不能完全交给系统自己回答。

不完美的人留在回路里，正是为了保证软件不会以“完美”的名义消灭人的不完美。

看向未来：软件工程必须重新安放人

未来的软件工程一定会越来越自动化。

更多代码会由 AI 生成，更多测试会由 AI 补齐，更多审查会由 AI 辅助，更多文档会由 AI 整理，更多流程会由 AI 推动。人不应该继续困在大量重复执行、机械检查、信息搬运和状态同步里。

这些工作能够交给机器，就应该尽量交给机器。

但这并不意味着人应该退出软件工程。恰恰相反，当执行被大量自动化之后，人更应该站到更高价值的位置上：定义方向，判断价值，接受风险，纠正系统，承担责任。

今天已经没有人会和吊车比赛搬运，未来也不应该有人和 AI 比赛写代码。问题不在于人是否还要亲自完成所有执行，而在于当机器承担了执行，人应该站到哪里。

软件工程的未来，不应该是无人化的软件工程，而应该是人从低价值执行中退出来，进入更高价值判断的软件工程。

AI 可以改变软件开发的执行方式，但不能替人回答软件为什么值得存在。工具可以让系统更可靠，流程可以让状态更清晰，反馈可以让问题更早暴露，自动化可以让执行更高效。但只要软件仍然面对人，人的判断、价值和责任就不能从回路中消失。

软件最终面对的是人。

脱离人的软件没有意义。

回路中没有人的软件工程，也没有意义。