这不是宣传稿，是工程规范，是你可以拿去：

• 发到 Outline / Wiki
• 作为技术文化基线
• 作为 Code Review、架构评审时的“共同语言”

公司工程规范

Vibe Coding 实战规范（Engineering Edition · v1.0）

适用对象：全体程序员 / 架构师 / 技术负责人
目标：提升整体工程效率、系统质量与工程幸福感

0️⃣ 核心原则（先统一思想）

原则一句话版

人负责决策，AI负责实现；人对结果负责，AI不背锅。

明确三点共识

1. Vibe Coding ≠ 不写代码
2. Vibe Coding ≠ AI 自动生成即可上线
3. Vibe Coding = 更高级的工程分工方式

1️⃣ 人与 AI 的职责边界（非常重要）

人（程序员）的职责

你必须亲自完成：

• 业务理解与问题定义
• 系统边界划分
• 架构选型（语言 / 框架 / 存储 / 通信）
• 安全、性能、可维护性判断
• 最终代码 Review 与合并决策

任何“我没看，是 AI 写的”都不可接受

AI 的职责

AI 被允许、且鼓励用于：

• 样板代码生成
• CRUD / DTO / Mapper / 配置类
• 单元测试、Mock、测试用例扩展
• 文档初稿、README、接口说明
• 重构尝试、替代方案推演

AI 是“超级实习生 + 编译器 + 搜索引擎”的合体

2️⃣ 标准 Vibe Coding 工作流（必须遵守）

Step 1：先写「意图文档」，再写代码

任何功能开始前，至少写清楚以下 4 点（可 10 行内）：

## Intent
- 我要解决什么问题？
- 为什么现在要做？

## Scope
- 本次做什么
- 明确不做什么

## Constraints
- 技术约束（语言/框架/版本）
- 性能/安全/兼容性要求

## Done Definition
- 什么状态算“完成”

这是给 AI 的，也是给未来的你和同事的。

Step 2：用自然语言“指挥”AI，而不是贴代码

不推荐：

“帮我写一个 XXX 的代码”

推荐：

“在以下约束下，设计一个可扩展方案，先给结构，再给示例实现”

“这个模块未来可能要支持多租户，请预留扩展点”

Step 3：AI 输出 ≠ 完成，必须人工校验

必须人工检查的点：

• 是否违反公司技术规范
• 是否引入多余复杂度
• 是否有安全 / 性能隐患
• 是否真的解决了最初的问题

AI 的第一版，默认是“草稿”。

Step 4：允许推翻，鼓励重来

Vibe Coding 的核心优势：

• 推翻方案的心理成本极低
• 不要“舍不得已经写好的代码”

一句标准心态：

“这版不对，换个 vibe 再来一轮。”

3️⃣ 代码规范（Vibe Coding 特有）

3.1 生成代码必须“可读、可解释”

禁止：

• 晦涩的黑魔法
• AI 自创的奇怪模式
• 没人看得懂的“炫技代码”

要求：

• 命名清晰
• 结构直观
• 注释解释「为什么」，不是「做了什么」

3.2 必须留下“人类痕迹”

以下至少满足一项：

• 架构说明注释
• 关键决策点的理由说明
• 与 AI 方案不同的人工修改痕迹

这不是给领导看，是给未来维护的人看。

4️⃣ Code Review 新规则（必须调整）

Review 不再关注：

“这行代码是不是你亲手写的？”

Review 必须关注：

是否符合设计意图
是否符合系统长期演进方向
是否存在被 AI 忽略的边界条件
是否可以更简单

一句话总结：

Review 的对象是“方案质量”，不是“作者是谁”。

5️⃣ 对个人能力的真实要求（说清楚，不画饼）

Vibe Coding 不会降低要求，反而更高：

你需要提升的是：

• 抽象能力
• 表达能力（对人 & 对 AI）
• 架构理解
• 系统思维
• 判断力

不会思考的人，用 AI 只会更快地产生垃圾。

6️⃣ 常见误区（明确禁止）

“AI 写的，应该没问题”
“先跑起来再说”
“我看不懂但能用”
“反正不是我写的”

责任永远属于合并代码的人。

7️⃣ 我们为什么要这样做？

不是为了：

• 追热点
• 显得先进
• 少招人

而是为了：

• 把有限的工程师时间，用在最有价值的地方
• 减少无意义的重复劳动
• 让工程师更多做“思考型工作”

8️⃣ 结语（可以原样引用）

Vibe Coding 不是捷径，而是把工程师从“体力劳动”中解放出来的一种新分工方式。

我们不降低质量标准，只提升效率上限。

AI 不是替代者，而是放大器。

最终负责系统成败的，仍然是人。