如果你不知道什么是 UOP：UOP：面向理解编程 - 知乎（后称”原文“）

本文针对的是原文在 2026 年 2 月 25 日 20:55 分的版本。

本文中的“开发”和“编程”同义。

0. 前言

主核与 AI 创造了一种新的编程风格——面向理解编程（Understanding-Oriented Programming，UOP）。后文即用 UOP 来代指面向理解编程。这种编程风格的初衷是为了代码更加易读，然而，其使用可能会给工程开发带来一系列问题。所以，我决定写下这篇文章。

本文中的反驳仅针对内容，不针对作者的语法和标点符号规范进行反驳。

1. 驳《我为什么写这篇文章？》

《我为什么写这篇文章？》相当于原文的前言，其中已经存在一些问题。

1.1. 维护不只是读代码

如果规范是为了让代码更容易维护，那”大家都这么写”就不应该是唯一的衡量标准。”大家都能看懂”才应该是。

——原文

这句话里面便存在一个纰漏：维护不只是读代码。作为一个项目的维护者，你不仅要考虑让别人读你的代码，还需要保证别人能写出符合项目开发规范的代码。一个项目的开发风格应当是大体统一的，而 UOP 是一种与其他风格格格不入的编程风格。因此，如果将 UOP 定为开发风格，便不太能接受其他编程风格。而 UOP 是一种不适合写的编程风格，详情请见后文。

2. 驳《面向理解编程 是什么》

主核在这一章中给面向理解编程下了定义，并给出了检验标准，其中存在一些问题。这些问题在外行人看来可能没有什么问题，但对于内行人来说，个人认为是不利于开发的。

2.1. 为什么我们需要让外行人来看我们的代码？

它的检验标准也很简单，就一个问题：

“一个没学过编程的人，看着你的代码和注释，能不能大概说出‘这段在做什么’？”

——原文（对标点符号有修改）

这句话中说，UOP 的检验标准是“一个没学过编程的人”看代码。我承认实际项目开发中可能存在一些看不懂的代码的人来看代码，特别是职场项目开发。但主核明确说了，职场项目不是 UOP 的适用范围（见下图）。我们的考虑范围变成了开源项目（闭源非职场项目除了开发者之外按理来说没有外行人会看代码）。然而， 对于开源项目来说，外行人阅读代码仍然是极少数的情况。更多的情况下，阅读代码的仍然是开发者或者 AI。也因此主核说这不是针对经验丰富的程序员的规范。是针对小白的。这就是我们在下一章所要讨论的。

2.2. 真的能够提升协作效率吗？

但我认为：当你以这个标准去要求自己，写出来的代码，对所有水平的开发者都会更友好（向下考虑）。 零基础能读出大意，初级开发者能完全理解，高级开发者能快速定位和修改。这能大幅提高协作效率（至少对我来说是这样）。

——原文

主核在这里认为，UOP 对所有水平的开发者都更加友好，可以大幅提高开发效率。然而对于资历比较深、经验比较丰富的开发者来说，这绝对不能称的上是一个好的开发规范。正如本文 1.1 节中所说，”维护不只是读代码“，同样，协作也不只是读代码。你必须考虑和你协作的人能不能写出这样的代码，更多的在 1.1 节中已经说过，这里不再重复。

3. 驳《说说目标》

主核在这一章中介绍了 UOP 的目标，然而，这一章的目标是不利于开发者成长的。

3.1. 小白开发者更需要养成良好的开发规范和动手能力

主核在这一章中提到，面向理解编程要照顾的对象之一是协作开发者小白。然而，正如前文及原文所说，UOP 实在算不得一个通用的规范，也算不得一个好规范。既然如此，就不应该让小白接触这样的代码，而应该让小白接触符合普遍开发规范的代码。这样他们才能养成既不违反普遍开发规范，也有自己个性的代码风格。UOP 这种代码风格绝不是小白应该频繁接触的，这不利于他们形成良好的代码风格和开发规范。同时，频繁的 Vibe Coding 也不利于他们的动手能力。

3.2. 我们不能只 Vibe Coding

Vibe Coding 是编程的辅助，不应该用 Vibe Coding 的方式编写全部的代码。主核在这一章中说到：

vibe coding 的场景下，AI 生成代码，人类来接手。

——原文

然而这绝对不是好的编程习惯。正如 Copilot 的名字，AI/LLM 只是我们写代码的”副驾驶“，起辅助作用，绝不是”主驾驶“，编写全部的代码。

4. 关于《第一层：命名——名字即文档》

这一层的几条规则没有什么太大问题，但是举例有问题。

4.1. 举例不应当只针对一两条规则

尽管主核表示：

注：以下示例仅仅为了展示命名，实际像 getData() 这种模糊命名是不符合 UOP 规范的，因为还要考虑全局和非全局。

——原文

但是我还是想说：你的举例不能只针对一两条命名，因为这可能是和其他规则矛盾的，不利于阅读者理解整个体系。如果可以的话，希望能够换一些例子。

5. 驳《第二层：注释——每一行都翻译》

正如这一章的标题，主核认为每一行都该有注释，注释应该把每一行都翻译出来。这明显是不现实的。

5.1. 我不是 AI

正如 3.2 节所述，我们不应该用 Vibe Coding 的方式编写全部的代码，这是错误的。不能拿错误的行为当成一个规范的前提。因此，这一章的前提尽管真实存在，但不能认为是一个良好的前提。

作为人类，我自然不可能做到行行解释，行行都写注释。开发者不是作家，他们是来写代码的，不是来写注释的。更多信息应该参阅文档，而不是源代码。

5.2. 不要把开发者当傻子

洛谷在其文档的《题解排版指引》5.2 节中提到，要避免注释喧宾夺主。这不只是 OI 题解应当遵循的规范，也是工程项目开发应当遵循的规范。开发者不是傻子，他们也不是没有 AI 工具，他们也能问 AI。因此，我认为，段落注释是必要的，但一行行的注释则大可不必，是在浪费时间和你的 AI Token。

6. 关于《第三层：结构——看哪改哪》

主核在这一章中介绍了 UOP 理念下代码的结构。这一段没有太大问题。

7. 驳《第四层：调用——凭直觉就能用对》

主核在这一章中介绍了 UOP 理念下的函数用法。这一段中存在一些问题。

7.1. any 是危险的

在本章的规则一中，主核提到了参数宽容。然而，写 Typescript 等强类型语言的一个真理是：any 是危险的，因为你永远不知道调用函数的给你传进来了什么东西。如果是同一个 AI 一次性写的代码还好，但如果换一个 AI，或者中途清空了上下文，AI 很可能会写出驴唇不对马嘴的代码。由于使用了 any 类型，编辑器不会报错，你可能很难找出错误。

7.2. 不易读的默认参数

在本章的规则二中，主核提到了默认参数、零配置。这是 UOP 中为数不多利好开发者写代码的规范，然而却牺牲了可读性。函数是一个偏向封装的概念。从函数外不能知道函数的内部实现，自然地，你怎么知道默认值是多少。想要知道默认值，就必须去看函数实现。这无疑是与 UOP 的理念自相矛盾的。

8. 驳《第五层：视觉——代码要像诗一样整齐》

这一章是整个规范问题最大的部分，因为它涉及到代码运行是否正常、是否崩溃的问题，而且问题很严重且不易察觉。

8.1. 常量的命名问题

主核在规则一中提到常量应该用小驼峰命名法命名。这是一个大问题。第一，我无法通过名字直接判断它是否是一个常量，只会降低代码可读性。第二，对于 Python 这样没有 const 关键字的语言，这可能会使得常量被更改，导致不可见的运行问题。

9. 关于《第六层：流程控制——主干清晰，旁支自理》

这一章我暂且没什么好说的。

10. 总结

UOP 是一个只注重阅读，不注重写的开发规范。因此，这一规范非常注重 Vibe Coding。然而，一个项目组内不可能全是 Vibe Coding，这导致 UOP 的适用范围有限。如果强行使用（尽管 UOP 并不面向这些项目），可能会给开发带来一系列问题。然而，目前 AI 的水平尚不明确，暂不建议使用全 Vibe 进行开发。