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.5 万行 Rust 代码 和 几千行 C 代码。在此之前，我并不熟悉 Nginx内核模块开发，但在 AI 的辅助下，我不仅完成了开发，还通过高频的交互彻底掌握了这些代码。

DSL 虚拟机：用于处理高性能规则匹配，涉及编译原理、字节码执行、JIT 优化等。深度检测引擎：深度的 payload 检测，集成 AI 算法进行攻击识别。Nginx 内核模块开发实现底层流量转发：涉及复杂的 Nginx C 代码开发。

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

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 是连接“高熵值”（混乱的用户想法）和“低熵值”（工程化产出）的桥梁。


核心工具与工作流

Claude Code：后端 Agent 的标杆

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


轻量级 Skill： Superpowers

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

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

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 时代，依然只有能够驾驭工具的人才能生存。我们需要完成从“写代码”到“品味代码”的进化。

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

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


费曼名言的再诠释

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


管理者的回归

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

新一代效能度量

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

七、 结语

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

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