Vibe Coding 实战规范（工程向 · v1.0）
WindSurf
1
帖子
1
发布者
1
浏览
1
关注中
-
《Vibe Coding 实战规范（工程向 · v1.0）》
这不是宣传稿，是工程规范，是你可以拿去：
- 发到 Outline / Wiki
- 作为技术文化基线
- 作为 Code Review、架构评审时的“共同语言”
公司工程规范
Vibe Coding 实战规范（Engineering Edition · v1.0）
适用对象：全体程序员 / 架构师 / 技术负责人
目标：提升整体工程效率、系统质量与工程幸福感
0️⃣ 核心原则（先统一思想）
原则一句话版
人负责决策，AI负责实现；人对结果负责，AI不背锅。
明确三点共识
- Vibe Coding ≠ 不写代码
- Vibe Coding ≠ AI 自动生成即可上线
- 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 不是替代者，而是放大器。
最终负责系统成败的，仍然是人。