人月神话 - SkyWalker Blog

Fred Brooks在《人月神话》中揭示了一个关于软件工程的重要观点，软件开发的复杂度分为本质复杂度和偶然复杂度两个部分。

偶然复杂性是人为引入的：手写机器码容易出错，高级语言解决了；手动管理内存容易泄漏，GC 解决了。每一代工具消灭上一代的偶然复杂性。而本质复杂性是问题固有的。这个系统到底该做什么？需求之间有没有矛盾？用户说的和想要的是不是一回事？本质上软件开发者对于整体spec和具体业务的SOP的理解。某种程度上，借用信息论的观点，我认为本质复杂性是软件工程不可被压缩的最小信息。

Brooks指出：”不存在任何单一的技术或管理上的进展，能够独自承诺在十年内让生产力、可靠性或简洁性获得哪怕一个数量级的提升。“没有银弹——工具消灭不了本质复杂性。

有趣的是，这个观点在vibe coding时代依旧起着指导性的作用。

AI 几乎完美解决了偶然复杂度的问题，但是本质复杂度 AI 现在很难解决，你有一个已经写好的软件，你有一个商业目标，那怎么决定后续的开发流程？哪几个关键目标来匹配这个商业目标？又或者你手底下有非常充分的工程产能，100 个可做的目标中，你怎么挑选出最有价值的三个目标？…软件工程不只是技术和理论，相反它链接现实的需求和场景，而这件事情关乎需求分析的本质。

它同时关联到另一个视角，就是软件工程的过程中底层的熵增和不确定度。

所以我进行了一些尝试——受到我朋友的影响。我们很自然将软件工程项目视为一个复杂系统。系统熵增随着规模的扩大，需求的扩张而不断进行，而我们希望构建一种对抗系统熵增的底层方法论——SVP（Semantic Voxel Protocol，语义体素协议）是面向AI时代的意图驱动型软件编译范式，一种重塑人机协作边界的设计哲学。SVP将离散的软件设计转化为机器可读的中间表示（IR），并建立了严密的五层架构（L5意图层 → L4架构层 → L3逻辑层 → L2骨架层 → L1实现层）来确保开发者的意图得到实行。它模仿了经典编译器原理，只允许自顶向下的单向编译，绝对禁止反向修改底层来同步上层。

然而在参与到 SVP 项目的过程中我渐渐意识到另一件事情，在Brooks的理论框架下，我们似乎还是没有跳出这个桎梏，比如我们似乎仍在偶然复杂性优化的怪圈里打转。事实上，我现在更加能意识到的一件事情是。通用方法存在一个上界，这个上界似乎跟bitter lesson所揭示的一个深刻道理相关：把人类的思考方式硬编码进入系统是行不通的，正如早期人工智能研究者经常试图将知识构建到他们的智能体中。这在短期内总是有效，并且对研究者来说具有个人的满足感，但从长期来看，这种方法会达到瓶颈，甚至阻碍进一步进展。而突破性的进展最终来自相反的方法，即通过搜索和学习扩展计算规模。

我有的时候甚至在质疑通用方法本身——在人工智能的发展历程中它是搜索和学习，是scaling law；而在经典的软件工程的视角上它可能是摩尔定律。人月神话其实是对于这种规模扩展的反思：上界永远存在，上界本质上来自人类的先验，或者说是一种归纳偏置，人类的认知或许永远不能正确认识世界，这在我们提出归纳模型时或许就已经注定结果…

不过值得宽慰的是我们至少还在人为的偏差中做一些什么，甚至这一片本身也有很大的空间等待有志者们大有作为。正如SVP的背景是之前spec驱动开发例如spckit，openspec这种思路在实践中很难跑通。因为通常在项目设计阶段往往最终都需要改动。做不到在真正开发前了解100%的信息，没有上帝视角。一点需求改变，状态同步是最困难的。那么我们就希望能通过SVP的方法论来改进状态同步的偏差。再比如说我正在做的一个IDE的企划，现在的IDE对于coding场景下有些死板和落后了，有必要尝试对于coding agent的状态控制延伸到IDE的设计环节，作为一种产品的延伸。我们设计的一种可能的产品形态目前是一个ide来帮助人更好理解人工智能在做什么，理解每一个动作影响了什么，并且能主观介入其中和ai一起协作并且知道自己在做什么。

唉，我个人的想法是ai时代的大型项目的业务需要一种更高层的封装，从第一性原理的角度来看，降低不确定度或许是llm时代vibe coding的第一性原理。至少这种现状已经带来了一批亟需解决的问题，至于未来的事情，等未来的人再说吧。