计算机从来不等于编程

一个预览按钮，可以有什么问题？

我说计算机不等于编程，并不是把编程从学科中拿走，而是把注意力从“怎样写出指令”向前、向后各移一步：前面是如何表示问题、选择算法，后面是结果是否满足约束、能否在系统中可靠地重复发生。下面只借一个小功能，观察其中关于状态的一部分。

设想一个杂交预览：选择两株植物，界面显示可能结果。如果开发者为了展示结果，直接调用真正生成后代的函数，会发生什么？画面也许完全正常，但随机序列可能已经向前推进。用户只是多看了几次预览，后续确认结果却可能改变。这里描述的是一种错误实现的说明性反例，不是声称项目曾经出现过这个故障。

零号试剂的现有规则测试恰好检查这条边界：记录杂交随机流状态，连续十次调用预览，再确认状态没有变化。2026 年 9 月 6 日运行相关遗传测试，11 项通过。它证明的是这些具体断言在本次测试条件下成立，而不是游戏不存在其他缺陷。^[1]

把显示、规则与状态分开

这不是换一种语法能解决的问题。我们必须区分查询与命令：查询解释当前有哪些可能性；命令验证前提、消耗资源并提交变化。随机流也是状态，不能因为它没有显示在界面上，就把它当成无关的实现细节。

这种分离使测试不必先启动整个图形界面。规则可以面对固定输入与随机种子；界面则验证反馈、焦点和取消行为。如果所有逻辑都嵌在按钮回调里，想证明“预览没有副作用”就需要穿过更多无关条件。

测试的不只是输出，还有不变量

输出测试问“结果是否在允许范围内”；不变量测试还问“本不该变化的东西是否保持不变”。资源不足时，确认操作不应先扣一半费用；重复提交结算，不应记两次成绩。这类约束决定一段逻辑能否被安全地组合进更大的系统。

但通过单元测试仍不等于用户体验正确。界面可能显示过期预览，取消按钮也可能没有取消用户以为取消的操作。规则测试与交互测试回答不同问题，两者不能互相冒充。

这是不是把简单事情做复杂？

这是一个合理反问。一次性的计算脚本，没有必要复制大型系统的层次。抽象需要成本：接口、文件与概念增加后，读懂代码也可能更难。只有当规则被多个入口复用、状态错误难以追踪，或需要独立验证时，这种分离才更值得。

同样，“计算机科学不等于编程”不意味着编程不重要。不会读调用链、理解可变状态和定位边界错误，再漂亮的架构词汇也无法替代调试。AI 辅助生成代码可以进入工作流，但它不会免除检查前提、执行测试和理解失败的责任。这里是工程判断，不是对未来岗位数量的预测。

把抽象落实到一个可检查的问题

我希望保留的训练方式很朴素：为一个功能写下输入、允许的变化、禁止的变化和失败结果，再决定需要怎样的代码组织。学科框架可以帮助发现盲区，但具体能力仍要在实现与验证中表现出来。

下次再看一个“已经能用”的功能，可以多问一句：用户什么都没有确认时，系统是否也真的什么都没有改变？这比把代码行数当作工作量，更接近我理解的系统构建。

我需要修正“AI 只利空软件工程”

早期我把计算机科学与编程区分开时，说过 AI 只是利空软件工程。这个说法把软件工程缩成了写代码。需求、验证、可靠性与维护本来就是工程的一部分，而代码生成越快，这些问题未必越少。

更准确的判断是，学科内部的工作结构正在变化。重复表达的成本可能下降，理解约束和验证结果仍然重要。不能拿一个专业名称预测每个人的命运，也不能因为生成工具更强，就放弃理解它生成的系统。