有哪些传统理论和方法，在 Vibe Coding 或 AI Coding 中可能会失效？

《Python 之禅》(The Zen Of Python) 有十九条警句，可以完整过一轮：

1. 优美胜于丑陋 (Beautiful is better than ugly)
🟢 升值。但啥叫美？这个定义很有可能有变化。在 AI 时代其实大家都在强调「技术审美」，这对结果的影响至关重要。

2. 显式胜于隐式 (Explicit is better than implicit)
🟢 升值。显式意味着可以 grep 、意味着可以作为注意力机制的杠杆。

3. 简单胜于复杂 (Simple is better than complex)
🟢 升值。AI 可以轻松生成大规模的复杂代码，然后把人和 AI 一起搞晕。只要代码需要维护，那么有效控制复杂度至关重要。当然，日抛型代码另论。

4. 复杂胜于凌乱 (Complex is better than complicated)
🔵 存活。复杂的代码 AI 依然能够读，但凌乱的却可能反向带来大量脏上下文，把 AI 推理能力也都拖累；

5. 扁平胜于嵌套 (Flat is better than nested)
🔵 存活。不过，这更多影响的可能是 AI 的探索成本，过深嵌套对于 AI 理解来说压力不算特别大；

6. 稀疏胜于稠密 (Sparse is better than dense)
🟢 升值。稠密的、炫技式的代码一直都是难以维护的代码。

7. 可读性至关重要 (Readability counts)
🟢 升值。而且需要兼顾「AI 可读」：可预测、可验证、可被 grep。甚至，把逻辑包装为 cli 来输出 stdout 信号也是可读性的一环；

8. 特例不足以特殊到可以打破规则 (Special cases aren't special enough to break the rules)
🟢 升值。AI 喜欢复读机式地去学习使用其他文件的模式，特例也很容易被学过去，这就会是灾难；所以，一旦有特例，就需要注释声明别学；

9. 实用性胜过纯粹性 (Although practicality beats purity)
🔵 存活。无用的纯粹性依然站不住脚。

10. 错误绝不应被默默放过 (Errors should never pass silently)
🟢 升值。尤其是 AI 加速了的代码生产速度，很容易把 Bug 变成 Feature，后面就很麻烦。

11. 除非明确需要静默 (Unless explicitly silenced)
🔵 存活。仅仅作为逃生窗口吧，有时错误的确很难搞，明确地声明能稍微降低风险。

12. 面对歧义, 拒绝猜测 (In the face of ambiguity, refuse the temptation to guess)
🟠 变质。这是个很好的愿景，但实际上和 Vibe Coding 有点背道而驰 —— 人的意图描述往往就是有歧义的，更好的 AI 其实只是做了更好的意图猜测、甚至可以说 AI 推理与输出的过程本身就是猜测。如果真的拒绝猜测，那就是全面应用「Grill Me(拷问我)」那套 Skill 的思路：频繁地打断让用户明确信息，但这个也有争议性——市场最终的选择是 YOLO。

13. 应该有一种——最好只有一种——显而易见的做法 (There should be one—and preferably only one—obvious way to do it)
🔵 存活。AI 本来就是概率机器，他自然会找出根据用户输入 Prompt 意图最好的一种方案，而问题还是在于用户意图的完备性与审美、或者可能加上 AI 训练集与奖励管线的审美。

14. 尽管那种做法一开始未必显而易见, 除非你是荷兰人 (Although that way may not be obvious at first unless you're Dutch)
🔵 存活。Python 作者就是荷兰人的梗，他有他独特的技术审美。

15. 现在就做胜过永远不做 (Now is better than never)
🔴 阵亡——唯一的阵亡, 以示警醒。其实这条只能算一半一半：在「探索域」很有用，比如做一些 Demo、原型、验证、工具等等。但是在稍微严肃的环境让 AI 来「现在就做」成本太低了，但后果却可能很惨痛。

16. 尽管「永远不做」常常胜过「立刻就做」。(Although never is often better than right now)
🟢 升值。在 AI 时代「做点什么」的诱惑太大了，反衬出「不做什么」的更高价值。

15, 16 其实是一对对冲原则，只是在原来古法时代，15 的动手执行更有价值；但我认为这种「先动手再说」现在的诱惑以及爆仓风险都太大了。

17. 如果实现难以解释, 那它是个坏主意 (If the implementation is hard to explain, it's a bad idea)
🟢 升值。在 AI 时代相当于正名了 Prompt 的重要性。模糊的指令只能靠 AI 猜测，风险很大。

18. 如果实现容易解释, 那它可能是个好主意 (If the implementation is easy to explain, it may be a good idea)
🔵 存活。上下文与 Prompt 的语义足够清晰，那执行就不容易出问题。

19. 命名空间是个绝妙的主意——让我们多搞一些!(Namespaces are one honking great idea—let's do more of those!)
🟢 升值。可能可以理解为上下文隔离——这依然是 AI 模型应用的最佳实践。

最终情况：10 条升值、7 条存活、1 条变质、1 条阵亡。其中：

  • 变质那条争议性比较大；
  • 阵亡那条仅仅只是因为需要警示其中的风险，而非完全阵亡。

这份 1999 年的时候就列出来的清单，在现在几乎全仓上涨 —— 因为这就是关于如何对抗复杂性和不确定性的问题。

AI 并不能让复杂度消失、复杂度只会转移；而且 AI 会让复杂度以几倍速甚至几十倍速地扩大。

另外我可以再列举一些可能失效了的：

  • 手撸才算了解：基本失效。手撸现在的效益远低于 AI 编码；
  • 语法 / API 熟练度：基本失效。虽然原本这部分也没有特别推崇；
  • 「DRY」(Don't Repeat Yourself 别重复你自己)：部分失效。AI 生成冗余代码的成本几乎为零，过去很多的模块复用意图来自于研发成本而非一致性，而且原本就有「不要过早抽象」的最佳实践，所以这条规则松动了；但需要一致性的时候依然奏效；
  • 「约定优于配置」：一半失效。其中约定性的部分是依然奏效的，但「隐式机制」却是深坑，需要用文档或者注释来填补，否则很容易出错；
  • 以人日为单位的研发周期评估：需要重构，现在更多需要从需求确信度、复杂度管理、风险导向来评估研发周期；
  • 用代码量/提交量评估绩效：本来就糟糕透顶，现在更是有巨大的屎山风险；

Comments

Post a Comment

Popular posts from this blog

How to turn off Sass warning prompts in Nuxt.js projects

Background of the Issue When developing projects with Nuxt.js, it’s common to encounter a large number of Sass-related warning messages in the console. These warnings mainly include: Warnings about the order of mixin declarations. Warnings about the use of Legacy JS API. Although these warnings do not affect the operation of the program, they can degrade the development experience by cluttering the console. Today, we will explore how to elegantly address this issue. Solutions 1. Disable Warnings via Configuration In the nuxt.config.js file, we can modify the Sass configuration to suppress these warning messages: export default { build: { loaders: { scss: { sassOptions: { quietDeps: true , // Suppress warnings from dependencies logger: { warn: function ( message ) { return null ; // Silence warning messages }, debug: function ( message ) { return null ; // Silence ...
Read more

Configuring SSH Access to a Docker Container via an Alternative Port

Configuring SSH Access to a Docker Container via an Alternative Port If you want to configure SSH access to a Docker container using an alternative port, such as port 6666 , follow the steps below carefully. This guide assumes that you have administrative access to your Docker host and are familiar with basic Linux commands. Step 1: Run the Container with SSH Service Start by running a new container from your image with port 6666 on the host mapped to port 22 inside the container: sudo docker run -it -p 6666 : 22 --name ssh-container testimage Make sure to replace testimage with the actual name of your Docker image. The --name option gives the container a specific name for easier management. Step 2: Install OpenSSH Server in the Container Once inside the container, update the package list and install the OpenSSH server: apt-get update && apt-get install -y openssh-server Step 3: Set the Root Password Set a password for the root user, which will be required when l...
Read more

Quickly Set Up a Cloud Database Using MongoDB Atlas

Quickly Set Up a Cloud Database Using MongoDB Atlas MongoDB Atlas is the official fully managed cloud database service from MongoDB, simplifying the deployment, management, and scaling of MongoDB in the cloud. This article will guide you on how to quickly create a MongoDB Atlas cluster and set up basic connection configurations. Creating a MongoDB Atlas Cluster Sign Up & Log In If you do not have a MongoDB Atlas account yet, head over to MongoDB Atlas to sign up. After logging in, click on “Build a Cluster” to start creating a new cluster. Select Cluster Configuration To meet the needs of most development and testing scenarios, you can choose the free tier (M0) shared cluster, which is usually sufficient for small applications or personal projects. When choosing a cloud provider, select based on your preference. Here we chose Azure, but AWS and GCP are also great choices. Specify Geographic Location For geographic location selection, choose according to your u...
Read more