架构先于语言：复杂代码的正确写法与 AI 时代的抉择

复杂代码的架构基石：四个原则

我在电子设计自动化软件里待了数十年，见过太多复杂系统在维护阶段轰然倒塌。倒下的原因几乎从不在某个算法写得不够聪明，而在底层数据模型从一开始就埋了雷。复杂软件需要的是一个一致的数据模型：每个事实只能有一个权威表示，对象之间的关系必须显式建立，构造与析构要完整闭环，算法之间靠共享词汇表沟通而不是偷看对方的实现细节 来源：CodeRhapsody。

这套原则早于语言模型能写代码的年代。它们首先是给人用的规则，其次才是给 AI 协作者用的。我把这些原则写进了论文，不是为了发明新东西，只是把数十年经验的教训固化下来 来源：CodeRhapsody。

语言特性如何帮助或阻碍架构表达

问题从来不是能不能在某种语言里实现一个图结构。足够执着的人能在任何图灵完备的语言里硬写出图来。真正的问题是语言能在多大程度上直接表达你的架构，还是让你把大量精力花在迁就语言本身而不是解决应用问题上 来源：CodeRhapsody。

C 的问题在于暴露内存表示，你的架构被内存布局绑架。C++ 把继承当作中心化的建模手段，结果架构被扭曲成类层次。Go 把方法耦合到声明 receiver 类型的包上，跨包架构变得碍手碍脚。Rust 要处理带反向指针和多父节点的可变图，需要动用大量机制才能让借用检查器满意 来源：CodeRhapsody。

C# 是另一个故事。普通对象引用、垃圾回收、编译时的部分声明与实现，加上成熟的标准库，它让架构得以直接表达。C# 并不完美，它是架构先行时的务实选型 来源：CodeRhapsody。

人类监督 vs 自主 AI：同一种语言，不同任务

监督式结对编程和自主执行 agentic codebook 是两种不同的任务。我在 Go 上持续有人类专家监督时用得不错，但这个成功经验不能推广到没有监督的 AI 身上 来源：CodeRhapsody。

对自主 AI，我现在更偏好 C#。更少的机制，更直接地表达意图架构，这意味着 AI 在自主执行时被语言本身绊倒的概率更低。这不是一个受控的语言基准测试，是基于经验、架构推理和具体项目片段的工程立场论文 来源：CodeRhapsody。

论文挂在 HN 上，拿到 1 点 0 评论 来源：Hacker News。我读了好几遍，觉得这个反差本身值得说一句：一个严肃的架构讨论，在社区里几乎无人问津。我不确定这代表什么，可能大家觉得架构问题早被讨论烂了，也可能论文标题太像教科书。

原文：

The Right Way to Write Complex Code · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月28日