AI 编码的探索与思考

本文由 gemini 自动整理自 2026 年 1 月 16 日做的《AI 编码的探索与思考》分享的文字稿。

引言：打破刻板印象

AI 编码领域的变化可谓“一日千里”。很多开发者对 AI 编程的印象还停留在一年多前——试用了一下，发现效果平平，便束之高阁。然而，今天的 AI 编码能力已经远超大家的想象。

在这个时间点，企业端的 AI 渗透率依然严重不足，而个体开发者之间已经出现了巨大的分化。一部分“保守党”坚持古法编程，认为只有手敲的代码才可信；另一部分“激进党”则完全依赖 AI，生成了大量未经审查的代码。

真正的未来，属于那些能够驾驭 AI、在“控制”与“放权”之间找到平衡的开发者。

一、 行业巨变的信号：大神的转身

如果说普通开发者的体验还带有主观性，那么顶尖开发者的动态则清晰地预示了风向：

• Linus Torvalds 的新玩具： Linux 之父 Linus 最近分享了一个视频，他使用 Google 的“反重力”（Antigravity）编辑器（注：指 Google 的前沿 AI 辅助开发工具）开发了一个音频可视化的 Python 项目。 Linus 自谦说自己并不精通 Python，以前写 Python 是“先 Google，理解后再写”。而现在，他直接让 AI 生成代码，“中间商（我自己）被干掉了”。他直言，AI 写得比他自己好太多了。

• Redis 作者 Antirez 的爆发： Redis 的作者 Antirez 在过去一周内，基于 Redis 源码完成了四个非常复杂的项目，包括向量集支持和 FLUX 模型的实现。 他感慨道：“作为一个程序员，我比以往任何时候都更想编写代码。” AI 极大地缩短了从想法到交付的周期，让他重获了构建复杂系统的乐趣。

• Cursor CEO 的“300万行代码”奇迹： 这是一个更激进的案例。Cursor 的 CEO 分享说，他们利用 AI（GPT-5.2 Agent）在一周内生成了 300 万行代码，从零实现了一个可运行的浏览器。 想象一下，手搓一个 Chrome 的难度有多大？虽然目前的性能还不够完美，但在几乎没有人工深度介入的情况下完成如此庞大的工程，足以证明 AI 编码的上限已被推高到了惊人的程度。

• 我的实践：OpenWAF： 作为分享者，我自己开发了一个名为 OpenWAF 的项目，整个项目我使用 conductor 来开发，全程没有打开过 ide，通过小步迭代和代码 review 完成了基本的框架功能。这是一个对标阿里云 WAF 的硬核企业级 WEB 应用防火墙项目，包含三大核心模块：

  1. DSL 虚拟机：用于处理高性能规则匹配，涉及编译原理、字节码执行、JIT 优化等。

  2. 深度检测引擎：深度的 payload 检测，集成 AI 算法进行攻击识别。

  3. Nginx 内核模块开发实现底层流量转发：涉及复杂的 Nginx C 代码开发。 整个项目包含 1.5 万行 Rust 代码 和 几千行 C 代码。在此之前，我并不熟悉 Nginx内核模块开发，但在 AI 的辅助下，我不仅完成了开发，还通过高频的交互彻底掌握了这些代码。

二、 核心理念：编码即控制

AI 编码不仅仅是效率工具，它带来了一种全新的控制论视角。

1. 开发者角色的转变

在传统的软件工程中，我们是执行者（Worker）。但在 AI 时代，我们变成了控制器（Controller）。

• 被控对象：AI 模型、代码库、软件系统。
• 输入：我们的需求规格（Spec）、Prompt。
• 输出：可运行的软件功能。
• 反馈：编译报错、测试失败、Code Review 发现的问题。

2. 高增益系统的风险

AI 是一个高增益放大器。你输入一句简单的 Prompt（少量信息），AI 可能会生成几百行代码（大量信息）。 这种“高增益”带来了巨大的风险：熵增和失控。如果你缺乏有效的**负反馈（Negative Feedback）**机制，系统就会迅速发散，产生大量你无法理解、无法维护的“黑盒代码”。

3. 艾什比必要多样性定律 (Ashby's Law)

控制论中有一个重要定律：“只有多样性才能吸收多样性”。 简单来说，控制器的复杂度和状态数，必须至少等于被控系统的复杂度和状态数。

• 现状： 现代软件系统的复杂度（多样性）极高。

• 传统模式： 资深工程师通过多年的经验，在大脑中建立了足够复杂的模型（高 Variety）来匹配软件系统。

• AI 模式的陷阱： AI 编码充当了一个降维过滤器。

  • 开发者通过自然语言（低 Variety）指挥 AI。
  • AI 生成了复杂的逻辑代码（高 Variety）。
  • 危机： 如果开发者为了图省事，不再阅读和理解 AI 生成的代码，那么开发者大脑中的“多样性”就会低于代码库的“多样性”。
  • 结果： 系统一旦出现边缘情况（Bug），开发者将失去控制能力，因为他的心理模型已经无法覆盖系统的实际复杂度。这就是所谓的**“丧失控制权”**。

4. 熵（Entropy）与系统耗散

软件工程本质上是一个对抗熵增的过程。我们将无序的需求变成有序的代码。

AI 的双向作用：

• 减熵（理想情况）： AI 遵循最佳实践，生成结构清晰、命名规范的代码，帮助系统维持低熵状态。

• 增熵（实际风险）： AI 往往倾向于“堆砌代码”而非“重构抽象”。它更容易生成冗余的样板代码，而不是提取通用的函数（因为提取抽象需要跨文件的全局视野，目前 AI 的 Context Window 有限）。

结论： 如果没有强力的人类干预进行重构，AI 编码系统倾向于加速系统的热寂（Heat Death）——代码库迅速膨胀，直到没有任何人能理解，维护成本趋于无穷大。

5. 负反馈环的延迟与失效

一个健康的控制系统依赖于快速且准确的负反馈。

• 编译与测试（硬反馈）： AI 编码工具现在已经开始集成“自我修复”循环（生成 -> 报错 -> AI 修正）。这是一个非常高效的短路负反馈，能解决语法级错误。

• 逻辑与业务意图（软反馈）： 这是最危险的环节。当人类产生“Review 疲劳”时，对 AI 代码的检查会变得肤浅。

5. 二阶控制论：观察者的观察

二阶控制论关注的是“观察系统的观察者”。在 AI 编码中，开发者不再直接与代码交互，而是与“AI 代理”交互。

• 黑盒化： AI 模型是一个黑盒。代码库本身因为生成速度太快，对人类来说也逐渐变成了黑盒。

• 信任校准（Trust Calibration）： 开发者对 AI 的信任度是一个动态变量。

  • 过度信任（Over-trust）： 导致自满，忽略错误。
  • 信任不足（Under-trust）： 导致弃用，效率降低。

人机共生系统的演化： 未来的编程不是“写代码”，而是**“训练那个帮你写代码的神经网络”**。你的每一次修改（Refinement）、每一次采纳或拒绝，实际上都是在调整这个控制器的参数。

过去我们写代码，就像是在雕刻石头，每一刀都由我们精准控制（一阶）。现在用 AI 写代码，更像是和一位画师对话。我不仅要看画本身，还要观察‘我描述画的方式’是如何影响画师的。这种‘观察我们与 AI 互动过程’的思维，就是二阶控制论。它提醒我们：在 AI 时代，编程的本质变成了沟通与反馈的管理。

在 AI 时代，编程的本质演变成了**“沟通与反馈”。 我们在做什么？我们本质上是在训练**那个帮你写代码的神经网络。你给出的每一个 Prompt、每一个约束条件、每一个停止词，都是在收敛它的输出空间，将其引导到你预期的结果上。

三、 工程实践：规范驱动开发 (SDD)

为了解决 AI 编码的“幻觉”和“发散”问题，规范驱动开发（Spec-Driven Development, SDD） 成为了关键模式。

什么是 SDD？

传统的开发流程是：想法 -> 文档/PRD -> 编码。 SDD 的流程是：想法 (Idea) -> 规范 (Spec) -> 计划 (Plan) -> 实现 (Code)。 Spec 是连接“高熵值”（混乱的用户想法）和“低熵值”（工程化产出）的桥梁。

核心工具与工作流

1. Claude Code：后端 Agent 的标杆

   • Claude Code 是目前对 Agent 理解最深的产品。它支持 Sub-agent（子智能体） 模式。
   • 场景：当你需要对 N 个文件进行重构或清理时，可以开启 N 个 Sub-agent 并行处理，互不干扰，最后汇总。这极大地扩展了单人的作战半径。

2. 轻量级 Skill： Superpowers

   • 这是一个轻量级的 Skill 插件，非常适合做需求澄清。
   • 特点：它一次只问一个问题（避免了像 Claude 原生那样一次抛出 10 个问题带来的认知负担）。它会将大需求拆解为 2-5 分钟的微任务，并生成详细的文件路径规划。
   • 这种“小步快跑”的交互模式，能显著降低 Token 消耗并提高准确率。

万变不离其宗，不管是 SDD 和 superpowers，本质上都是一个提示词工程

3. Kiro (AWS)
   • AWS 开源的一个完全基于 SDD 理念的 IDE。
   • 它的第一入口不是代码编辑器，而是 Spec。你定义好 Spec，它会自动生成计划并执行。
   • 可视化：它的界面动效非常直观，任务执行时会有圆圈转动，完成后打钩，完美契合了 SDD 的流程。

四、 下一代 IDE 的设计

如果说 Cursor 和 VS Code Copilot 是 AI 辅助编程的“第一代”产品，那么现在的创业公司正在构建“下一代” IDE。它们的共同特征是：

• 不在开发自己的 coding agent，而是通过 SDK 或者 ACP 集成 Claude-code、OpenAI Codex、 Gemini
• 不再仅仅是补全代码，而是接管整个软件工程流程。
• 任务流并行：多 Git Worktree 编排、沙箱（容器、虚拟机、serverless 等），践行 best of N
• 多 Agent 编排是必然：Claude-code、OpenAI Codex、 Gemini 各有千秋

1. Conductor (Melty)：并行开发的指挥官

• 定位：开源的 AI 原生编辑器，专注于并行任务处理。
• 核心逻辑：它不仅仅是一个写代码的界面，更是一个任务调度器。它允许你同时开启多个 "Track"（轨道），每个 Track 对应一个独立的 Git Worktree。
• 特性：
  • 环境隔离：每个任务都在独立的文件系统和进程中运行，互不干扰。
  • 人类介入：它提供了一个类似终端的 Chat 界面用于下达指令，以及一个实时的 Diff 界面用于 Review。
  • 工作流：你可以同时指挥 3 个 Agent：Agent A 修 Bug，Agent B 写新功能，Agent C 做重构。你只需要坐在指挥台上进行 Code Review 和合并。

2. ZenFlow ：多模型编排的大师

• 定位：集成了 SDD（规范驱动开发）理念的全流程开发工具。
• 核心逻辑：它将软件开发拆解为“需求澄清 -> 计划生成 -> 代码实现 -> 测试验收”的标准流水线。
• 级特性：
  • 左右互搏：它内置了多模型编排引擎。你可以配置“用 Claude 写代码，用 GPT 来 Review”。这种机制在工具内部自动流转，无需人工切换。
  • 可视化看板：它将开发流程可视化为看板（Kanban），你可以清晰地看到每个 Agent 正在执行哪个步骤，进度如何。

3. Vibe-Kanban：从“心流”到“工作流”

• 概念来源：源自 Linus Torvalds 的 "Vibe Coding"（凭感觉编程）与敏捷看板的结合。
• 核心逻辑：这不仅仅是一个工具，更是一种新的人机协作形态。在 Conductor 或 ZenFlow 中，看板不再是给人看的静态任务板，而是 Agent 的活动区域。
• 特性：
  • 动态流转：任务卡片的状态流转（Doing -> Testing -> Done）是由 Agent 自动触发的。
  • 透明化：开发者通过观察看板的流动，就能掌握系统的“脉搏”（Vibe），而无需深入每一行代码的细节。这让“凭感觉编程”变得可控、可落地。

不要迷信单一模型。目前的最佳实践是**“左右互搏” (Adversarial Workflow)**。

• 生产 vs 审查：让擅长编码的模型（如 Claude）负责写代码，让擅长逻辑推理的模型（如 Gemini 或 GPT）负责Review 代码。
• 实战效果：我经常让 Claude 写完后，让 Gemini 给代码打分。Gemini 经常会打出“D-”的低分，并精准指出 Claude 忽略的边界情况或安全漏洞。
• 价值：利用 AI 的随机性和不同模型的“偏见”，能发现人工 Review 难以察觉的盲点。

五、 开发者需要具备的“新能力”

在 AI 时代，依然只有能够驾驭工具的人才能生存。我们需要完成从“写代码”到“品味代码”的进化。

1. 技术品味 (Taste) 是核心竞争力

   • 如果你的品味不够，无法判断什么是好的架构、什么是优雅的代码，那么 AI 生成的就是一堆“垃圾”。
   • 你是 AI 的把关人。你的 Prompt 决定了下限，你的 Taste 决定了上限。

2. 费曼名言的再诠释

   • 费曼曾说：“我不能创造的，我就不能理解。” (What I cannot create, I do not understand.)
   • 在 AI 时代，这句话可以辩证地看。对于我不懂的技术（如 Rust），我可以先让 AI 创造出来，然后我通过阅读、调试、向 AI 提问来反向理解。
   • 通过多轮的“生成-解释-修改”循环，原本不理解的东西最终也能被深刻掌握。

3. 管理者的回归

   • 很多管理者早已不写代码，这在 AI 时代是非常危险的。
   • 如果不亲自体验 AI Coding，你就无法理解现在的生产力变革，无法做出准确的排期，也无法识别团队中的“虚假繁荣”（只生成不 Review）。
   • No Moat：前端与后端的界限正在消失。只要有自然语言能力和良好的工程品味，全栈开发已是常态。

新一代效能度量

• Acceptance Rate：AI 建议的代码中有多少被人类未修改接受？(衡量质量)
• Task Autonomy: 多少任务在初始提示后无需人类干预即可完成？(衡量独立性)
• Review Time: 审查 AI 代码是否比人类代码耗时更长？(警惕生产力悖论)

七、 结语

创新没有鸿沟，如果你现在不上车，可能就永远被甩在身后了。

• 不要验证偏见：不要因为试了 5 分钟觉得 AI 很蠢就放弃。请给自己几周时间，用 AI 真正从头到一个完整项目。只有在复杂的真实场景中，你才能体会到它的颠覆性。
• 寻找乐趣：AI 让我们能够以极低的成本构建以前不敢想的复杂系统。找回构建事物的乐趣，去创造更多、更好的东西。