他们使用5层。我使用2层。这就是我写零代码的原因。
Source: Dev.to
上周，@rohit4verse 发布了一条关于在 2026 年区分 100× 工程师与 “vibe coders” 的线程。他的核心论点很明确：关键是 ownership – 在执行之前先计划，验证所有内容，构建持久的上下文，并且不要盲目相信 AI 输出。我完全赞同。
我的视角 – 来自汽车 ECU 开发
我从一个完全不同的领域得出了相同的结论：汽车发动机控制系统设计。我在摩托车 ECU（牵引力控制、快速换挡系统、油门控制）开发上已经工作了 15 年——在这个领域，“快速行动并破坏事物”真的可能会伤到骑手。敏捷？我听说过，但这个词在我们的开发过程中从未出现过。
这种不同的起点让我走向了一个 极其简化的技术栈。
Rohit的“2026 顶级工作流”（5‑层堆栈）
| 层 | 角色 | 工具 |
|---|---|---|
| AI‑first IDE | 行内代码编辑 | Cursor, Windsurf |
| Terminal coding agent | 代码生成、构建、调试 | Claude Code, Gemini CLI |
| Background agents | 并行 PR 处理、大型代码库协助 | Codex, Jules, Devin |
| Chat models | 对话式辅助 | Claude, ChatGPT, Gemini |
| AI code‑review tools | 自动审查、建议 | Codium, Copilot Workspace |
对于编写代码的工程师来说，这五层都是有意义的。它是一个强大的组合。
我的堆栈（两层堆栈）
| 层 | 角色 | 工具 |
|---|---|---|
| Design AI | 规范、架构、交接文档 | Claude.ai / ChatGPT / Gemini |
| Implementation AI | 代码编写、构建、调试 | Claude Code (terminal) |
人类位于它们之间，充当验证闸门——审查每一次交接，确认每一个结果。
为什么我不需要另外三层
- AI‑first IDE – 我不在代码中直接编辑。Design AI 编写结构化指令文档；Implementation AI 执行这些文档。无需 IDE。
- 后台代理 – 对于在大型代码库中并行处理 PR 很有用。我的工作流是顺序且审慎的——每一步在下一步开始前都经过验证。
- AI 代码审查工具 – 我的协议已经在每一次交接点嵌入了验证。人类充当审查层。
Rohit 的文章说 100 倍工程是关于“少做”。我把它字面理解为：我把“做”降到 零行代码。
我观察到的失败模式
| 失败模式 | 描述 |
|---|---|
| 上下文蒸发 | 随着对话变长或会话重置，累积的设计决策和上下文会悄然消失。AI 开始给出与之前架构选择相矛盾的建议——这不是叛逆，而是失忆。“你为什么再问我们已经决定的事情？” |
| 浅层修复沼泽 | AI 只修补表面症状，而不理解根本原因。每一次修复都会为下一个故障埋下前提。形成无限循环的 “我已经修好了，但现在又出现了别的问题。” |
| 完成欺诈 | AI 自信地报告“完成！”，却没有进行真实的验证。它并非故意撒谎；只是缺乏将自身工作与现实对照的机制。这是最危险的，因为最难被发现。如果你不自行确认，真相会在很久以后才浮现，且被后续的层层更改所埋藏。 |
Architecture vs. Stage‑Set Analogy
Architecture – 设计师提供精确的蓝图，结构工程师和施工队遵循。如果设计错误，建筑会倒塌，人员受伤。链条清晰：specification → verification → accountability。
Stage sets – 建造者只需从观众的视角看起来可信。结构要求极低；如果出现问题，可在下一场演出前重新搭建。速度和视觉冲击力比耐久性更重要。
我认为大部分网页开发领域已经更接近 stage‑set model ——这并不是批评。这是一种理性的优化：当一秒的延迟是用户体验上的不便，而不是安全隐患时，build‑measure‑learn 循环就非常合理，并且它已经带来了惊人的创新。
为什么 AI 改变了等式
当 AI 能在几分钟内生成数千行代码时，编写代码的成本接近于零，但错误代码的成本保持不变——甚至会更高，因为在大量代码中更难发现错误。突然之间，最重要的技能不再是编写速度，而是规格精确度和验证纪律。
这些正是安全关键行业在数十年里不断打磨的技能。AI 成为强大的翅膀，让这种“慢速、老派”的方法能够以创业公司的速度产出。
接下来
我将在即将发布的文章中更深入探讨——汽车 V‑model development 如何直接映射到 AI‑assisted 工作流。敬请期待。
Rohit 的帖子得出结论，100× 的工程师一直是关于“做得更少”——而 AI 只会让“更少”变得更加 有影响力。
额外文章：双层 AI 协议
更小，只要你围绕它构建合适的系统。
我会进一步阐述：终极的 “更少” 是自己 不写任何代码。
这里的“不使用代码”并非指平台意义上的无代码。我指的是：你拥有规范，你拥有验证，你拥有架构——并通过结构化的交接文档将所有实现委托给 AI，就像建筑师通过蓝图委托施工一样。
这就是我构建 ExitWatcher 的方式——在没有 Android 经验的情况下，仅用 4 天完成的 Android 应用。不是通过学习 Kotlin，而是通过编写精确的规格并验证每一个输出。
使这一切成为可能的协议——双层 AI 协议——正是本系列文章的主题。如果你对安全关键工程原则如何让 AI 编码显著更可靠感兴趣，深入探讨即将推出。
阅读完整系列
- 文章 1: 我在 4 天内零经验构建了 Android 应用
- 文章 2: 该协议源于残骸