破局 Vibe Coding

“自由放养的 AI 编码，写得越快，烂尾越彻底。”

随着 Cursor、Claude Code、Trellis 等 Agent 工具的普及，“Vibe Coding”（凭感觉让模型自由写代码）成为热潮。但在实际工程中，团队很快会撞上一堵无形的墙。

---

一、传统 Vibe Coding 的四大绝境

1. 上下文截断导致历史失忆

长周期交互中，随着 Token 上限逼近，会话历史必须被不断摘要和截断。模型很快就会遗忘：

• 上周为什么不用方案 A 而选了方案 B？
• 数据库里这个字段的唯一约束背后的业务边界是什么？
• 结果：模型在新的会话里重新质疑已定方案，或者凭“通用常识”把精心设计的边界悄悄抹杀。

2. “伪完成”幻觉 (False Pass)

大模型最擅长的事情之一就是“宣称自己完成了”：

• 前端画了个按钮，点击弹出了一个绿色的 Toast 提示框，模型就宣称“用户删除功能已就绪”；
• 实际上数据根本没有写入数据库，也没有刷新后的状态对账。黑盒运行的无头脚本或者 Agent 自言自语的自检，充斥着伪通过。

3. 单源事实坍塌

在没有机器门禁的系统里：

• 接口契约在代码里；
• 需求写在 Issue 里；
• 测试写在脚本里；
• 三者没有任何确定性关联。开发者修了 A 模块，暗中破坏了 B 模块的依赖，系统在一次次所谓“优化”中迅速滑向失控与腐败。

4. 形式主义自审

“请检查你刚才写的代码是否有 Bug？” —— 让生成代码的同一个 Agent 自己审查代码，审查结果永远是你好我好大家好，毫无意义。

---

二、Atlas 的破局哲学

Atlas 并非一个简单的辅助脚本，而是一套践行 Project Harness 的应然资产治理引擎与机器硬门禁系统：

                    传统模式                      Atlas 模式
                  ┌──────────┐                 ┌──────────┐
                  │ 提新需求  │                 │ 提新需求  │
                  └────┬─────┘                 └────┬─────┘
                       │                            │
                       ▼                            ▼
                  ┌──────────┐                 ┌──────────┐
                  │ 直接写代码│                 │ 编译应然 │ ◄── 先更新 PRD / E2E
                  └────┬─────┘                 └────┬─────┘
                       │                            │
                       ▼                            ▼
                  ┌──────────┐                 ┌──────────┐
                  │ 事后补测 │                 │ 对照应然 │ ◄── 依据用例写代码
                  └────┬─────┘                 └────┬─────┘
                       │                            │
                       ▼                            ▼
                  ┌──────────┐                 ┌──────────┐
                  │ 盲目上线 │                 │ 机器门禁 │ ◄── 严格双向对账
                  └──────────┘                 └────┬─────┘
                                                    │
                                                    ▼
                                               ┌──────────┐
                                               │ 有头验收 │ ◄── 控制台眼见为实
                                               └──────────┘

1. 应然资产先行 (Spec-Driven)：需求在动手实现前，必须先编译为机器可校验的“应然资产”（PRD 的业务验收准则 AC + E2E 页面分片用例）；
2. 机器替代人眼：凡是“两边必须一致”的逻辑（testid 埋点集合、影响面预测、用例覆盖），全部由 Python 校验器给出 0/1 判定；
3. 眼见为实的验收：通过 E2E 控制台拉起真实浏览器慢动作回放，只有真实执行通过才解锁人工签字；
4. 两层正交与决策留痕：项目级应然与需求级任务完全解耦；代码库只存“当前真相（What）”，跨需求的技术取舍沉淀为项目内 ADR（product/adr/）留痕“为什么这么定（Why）”。