软件工程

架构不能保证每个组件正确，却能决定错误可以到达哪里、持续多久以及造成多大损失。本文把“风险几何”明确为故障半径、权限范围、暴露时间和相关性四个维度，并说明隔离、零信任、可观测性、渐进发布与恢复机制的能力和边界。

控制复杂或生成式软件不能只靠逐行阅读，也不能只看测试是否通过。本文以转账系统为例，建立需求、契约、性质测试、实现分析、形式验证与运行监控组成的六层证据体系，说明每种方法各自能证明什么。

AI 生成代码可能让系统增长快于团队理解，但“不知道每一行”并不等于失控。本文把认知债定义为安全修改所需知识与团队实际可调用知识之间的缺口，区分技术债、理解债和意图债，并提出识别、度量与偿还方法。

AI 可以在短时间内生成大量实现，但代码产量不等于交付能力。本文结合开发者调查和生产率研究，把“生成拐点”重新定义为团队的生成能力持续超过澄清、审查、整合和运行验证能力，并给出识别这一落差的指标。

传统软件工程追求可理解性，却从未要求一个人理解全部系统。本文从结构化编程、信息隐藏、版本控制和大型系统协作出发，区分源码可见、局部可解释、全局可预测与系统可控制，重新界定所谓“白箱假设”。