1) 概念与边界：你到底在做什么
Vibe coding通常指一种高度依赖大模型的编程方式：你用自然语言描述目标与约束，让模型生成代码，然后通过运行结果/报错反馈迭代，而不是逐行阅读与手写实现。这个术语由 Andrej Karpathy 在 2025 年 2 月提出，并用"几乎忘记代码存在、接受生成结果、用错误信息继续驱动"的方式来描述其体验。
关键边界：
-
如果你认真审阅、理解、测试模型写的每一行，那更像"AI 辅助工程"；
-
如果你倾向于"Accept all，不读 diff，靠运行结果修修补补"，那更贴近 vibe coding。
作为工程实践，vibe coding 的价值在于把"写代码"变成"驱动代码生成+验证" ；风险在于可维护性、可解释性与安全性会显著下降。
2) 适用场景：什么时候该"开 vibe"
更适合：
-
原型/验证：想快速验证交互、流程、数据模型、Demo（"周末项目"式）。
-
脚手架与样板：CRUD、页面骨架、接口封装、迁移脚本、测试样例生成。
-
探索性改动：不确定方案时，用生成+运行快速收敛。
不适合直接"全 vibe 上线"：
-
高可靠/高合规：支付、权限、审计、资金、隐私、关键链路。
-
长期演进的核心域：代码需要团队理解、可控演进、稳定重构。
3) 标准工作流：Vibe-to-Verified（先快后稳）
把 vibe coding 变成可交付工程的关键，是把流程切成两段：
A. Vibe 阶段（速度优先）
-
一句话产品目标：用户是谁、要解决什么、成功标准是什么。
-
约束先行：技术栈、目录结构、编码规范、性能/安全底线。
-
小步生成：一次只让模型改一个"可验证"的点（一个接口、一个组件、一个用例）。
-
用运行结果驱动：报错、日志、截图、接口响应直接喂回模型继续迭代。
B. Verified 阶段（工程质量优先）
-
读 diff + 归因：关键模块必须人类理解（至少能解释"为什么这样设计"）。
-
补齐测试：单测/契约测试/回归用例；覆盖关键路径。
-
静态与安全扫描：Lint、SAST、依赖漏洞、密钥泄漏。
-
架构固化：写 ADR（架构决策记录）、接口契约、数据字典，把"氛围产物"固化为团队资产。
4) 提示词（Prompt）写法：把模型当"可编排的工程师"
参考业界对提示策略的总结，最有效的不是"让它更聪明"，而是让它更可控：
推荐 Prompt 模板（可直接复用）
-
角色：你是资深后端/前端/测试工程师
-
目标：实现 X（可验收）
-
上下文：现有目录结构/关键代码片段/依赖版本
-
约束：
-
不新增无关依赖
-
不改动未提及模块
-
必须包含测试与边界处理
-
输出变更列表（文件级）+ 关键设计说明
-
-
验收标准：给出可运行命令、预期输出、失败时如何定位
两个强约束技巧
-
"先计划后改动"：要求模型先输出计划与影响面，再输出 patch。
-
"失败必须可解释"：要求模型在给出方案时列出可能失败点与诊断方法（日志点、断言点）。
5) 工程防线：让 vibe 不至于"越写越玄学"
把以下机制当作"护栏"，否则 vibe coding 很容易变成不可维护的代码堆：
-
版本控制强制化：每次生成都落到分支；提交信息写"意图+验收"。
-
质量门禁 ：CI 至少包含
test + lint + build，失败不允许合并。 -
可观测性先行：关键链路必须有结构化日志、指标、trace（否则模型修 bug 会越来越随机）。
-
"接口契约"优先于"实现细节"：先定 DTO/Schema/错误码，再让模型填实现。
-
依赖治理：模型爱加依赖；你要用白名单/审批机制限制。
6) 常见坑与对策
-
坑：Accept All 导致架构漂移
- 对策：锁定目录结构与分层边界；新增模块必须写 ADR。
-
坑：修一个报错引入三个隐患
- 对策：把"报错修复"变成"新增一个回归测试+修复实现"。
-
坑：安全问题被忽略（注入、鉴权绕过、越权、敏感信息日志）
- 对策：在 Prompt 中显式声明威胁模型与安全清单；CI 加安全扫描。
-
坑：对开源生态的"注意力抽离"（只用不参与）
- 对策：团队层面保留对关键 OSS 的反馈/贡献机制，避免"只消费不回流"的长期风险。
7) 趋势判断：vibe 会留下，但岗位会重构
近期讨论里，一个很一致的判断是：AI 编码工具正在改变工程师的工作配比------从"手写实现"转向"用自然语言编排、验证与集成"。
因此，未来更值钱的能力会更偏向：
-
需求表达与约束建模
-
验证体系（测试、观测、安全）
-
架构治理与演进控制
-
将"生成"纳入可复制的交付流水线