从 Vibe Coding 到工程化 AI 编程

Vibe Coding 指用自然语言描述想法，让 AI 快速生成软件原型，再根据运行效果继续调整。它降低了开始做软件的门槛，但如果只停留在“感觉对了就接受”，项目很快会遇到维护、测试、架构和责任边界问题。

更准确的理解是：Vibe Coding 是入口体验，不是完整工程方法。长期项目需要把提示词、上下文、工具、验证和团队流程逐步补齐。

几个阶段

Vibe Coding

这一阶段重在快速表达想法。用户描述页面、功能或流程，模型产出初版，用户看效果后继续调整。

适合：

• 验证产品想法。
• 做低风险原型。
• 探索 UI 或交互方向。
• 临时脚本和小工具。

风险：

• 代码结构可能散。
• 边界用例没有覆盖。
• 依赖和安全配置可能随意。
• 人不理解生成物，后续难维护。

提示词工程

提示词工程解决“任务怎么说清楚”。好的任务说明至少包含目标、范围、限制、输出形式和验收标准。

比较稳定的表达方式是：

• 改什么。
• 不改什么。
• 先读哪些上下文。
• 完成后怎样验证。
• 最终说明哪些风险。

提示词能减少误解，但它不能弥补缺失的项目资料。

上下文工程

上下文工程解决“让模型看到什么”。在代码任务中，模型需要看到相关源码、测试、配置、错误日志、项目规范和运行命令。

好的上下文像一份资料包：

• 只放当前任务相关内容。
• 长材料先摘要。
• 决策和约束写进文档。
• 不同任务隔离上下文。
• 工具结果要短而准。

上下文太少会让模型猜；上下文太乱会让模型抓错重点。

工具与 Agent 工程

当 AI 能读文件、改文件、运行命令、打开浏览器、查日志时，它从“回答建议”进入“执行任务”。

关键变化是闭环：

1. 读取项目。
2. 制定计划。
3. 修改文件。
4. 运行验证。
5. 根据错误继续修复。
6. 汇报变更和风险。

没有验证命令的 Agent 只能声称完成；有验证闭环的 Agent 才能证明完成。

Harness 工程

Harness 是围绕 Agent 的工程化外壳，包括规则、工具、沙箱、测试、日志、回滚和评审。它的目标不是让 AI 随便跑得更快，而是让 AI 在边界内稳定工作。

常见组成：

• 仓库说明：技术栈、目录、命令、禁区。
• 可执行检查：测试、lint、类型检查、构建。
• 隔离环境：分支、worktree、容器、沙箱。
• 可观测性：日志、截图、trace、接口响应。
• 评审机制：Agent 自查、人类 review、CI 阻断。
• 恢复机制：checkpoint、回滚、任务拆分。

Harness 像轨道和护栏。没有它，AI 速度越快，风险也越快放大。

组织流程工程

当团队开始大量使用 AI 编程后，真正稀缺的不是生成代码，而是判断标准。团队需要把架构原则、质量红线、发布流程、安全规则和用户体验标准写进系统。

有效做法：

• 把重复 review 意见变成规则、测试或 Skill。
• 把需求拆成规格、验收和回归用例。
• 把高风险动作设置人工确认点。
• 定期清理过时文档，避免 Agent 学到旧规则。

一个功能从原型到交付

以“后台新增订单导出”为例：

阶段	关注点	产物
Vibe	先做出按钮和导出流程原型	初版页面和接口草稿
提示词	限定只改订单模块，不改权限体系	明确任务说明
上下文	提供现有导出代码、权限规则、文件格式	相关资料包
Agent	改代码、补测试、跑构建	可审查 diff
Harness	CI、权限测试、文件大小限制、失败回滚	验证闭环
流程	产品验收、运维监控、发布说明	可上线变更

这条链说明：AI 编程不是不用工程，而是把工程关注点前置得更明显。

个人使用建议

• 原型阶段可以快，但长期项目要尽早补测试和目录约束。
• 大任务拆成小任务，每一步都能看 diff 和验证。
• 让 AI 先读相关文件，再动手改。
• 把常用命令写进项目文档。
• 两次以上重复出错，就把规则写成 Skill 或测试。
• 对鉴权、支付、数据迁移、生产配置保持人工 review。

团队使用建议

• 先改善仓库可理解性，再追求更多自动化。
• 让测试更容易运行，错误信息更容易定位。
• 让文档成为系统事实来源，而不是聊天记录。
• 给 Agent 最小权限，不给不必要的生产写权限。
• 让 CI 检查代码、文档、生成物和架构边界。
• 人类 review 聚焦需求、风险、架构和用户体验。

总结

Vibe Coding 适合点燃想法，工程化 AI 编程负责把想法变成可维护软件。提示词让任务说清楚，上下文让模型看对资料，工具让模型能行动，Harness 让行动可控可测，组织流程让人的判断可复用。越是长期项目，越不能只依赖“感觉对了”。