
> AI 编程工程化实践系列 · 卷一 · 认知 | 第 1 篇 / 共 8 篇
>
> 这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/0773687ef60c99e295d96b8a0192de23.png)

---

## 一、先看一个你一定经历过的场景

打开 AI 对话窗口，丢进去一句话：「帮我在用户模块加一个搜索接口，支持关键词搜索和分页」。

十几秒后代码回来了：Controller、Service、DTO，一应俱全。复制粘贴进项目，改几行 import，好像就能跑。

这种感觉确实很爽。

但真正的工作量在后面。你逐行读了一遍，发现排序不对；改完排序，又发现分页结构和项目里其他接口不一致；改完分页，一跑，另一个调这个 Service 的地方报错了。AI 不知道那个方法还有别的调用方。

你花了两个小时，自己改动的代码不到三十行。

AI 写代码用了十几秒，你收尾用了两个小时。这就是很多人的 AI 编程现状：AI 写得越快，你改得越多。

然后大多数人得出一个结论：AI 编程只能干点简单活，核心逻辑还是得自己写。我一开始也是这么想的。

这个结论不对。问题不在 AI 的能力，而在用法——你把它当成了一个"打字更快的实习生"，它要的是一份明确的任务书和一套验收标准。

## 二、Vibe Coding：凭感觉的编程

先给这种用法下个定义：**Vibe Coding，就是凭感觉跟 AI 对话，想到什么说什么，让 AI 自由发挥。**

这个说法不带贬义，它有自己适用的场景（文末会讲边界）。但项目稍微复杂一点，它的毛病会集中爆发，而且是三个。

## 三、致命问题一：信息缺失——AI 只能看到冰山一角

你的项目不是第一天建的。它可能跑了两三年，中间换过好几拨人，沉淀了大量隐式约定和隐式依赖。

举一个常见的例子。假设某个 Service 方法被 8 个 Controller 调用，其中 3 个在调用前做了特殊的数据转换，还有 2 个依赖了方法内部的隐含行为。这些事你自己也未必全记得，但代码记得。

你让 AI 重构这个方法。AI 只看到你贴过去的这一个文件，不知道那 8 个调用方的存在，更不知道那 3 处特殊转换。它改了方法签名，生成的代码看起来完全正确，编译也通过。

然后 3 个 Controller 当场挂掉。你排查了两个小时，最后发现是"改了方法签名但漏改了调用方"。

你怪 AI 不靠谱。AI 其实挺委屈：你从来没告诉过我这些。

这类坑我踩过不止一次，每次都栽在同一个地方——我脑子里有那张全景图，但没给出去。

这就是第一个问题，**AI 只能看到你当前对话框里给的上下文**，你没给的信息，对它来说等于不存在。

注意，本质不是"AI 记性差"，而是知识卡在两个断层之间：有些知识在代码里、人的脑子里没有；有些在人的脑子里、没进对话框。老工程师脑子里有一张项目全景图，AI 没有，除非你画给它。

## 四、致命问题二：行为不一致——你没说出口的约束，AI 会自己猜

第二个问题更隐蔽。

你让 AI 写一个查询接口。你知道结果应该按"更新时间倒序"，但没在提示词里说，因为在你看来这是常识。

AI 也没问你，因为在它看来，默认按 ID 排序就够了。

代码写完了，能跑，数据也出来了。上线一周后，产品经理发现排序不对，提了个 Bug。

谁的错？都不是。这是信息不对称的自然结果：**你知道的没告诉 AI，AI 猜的没告诉你，Bug 就埋在这个断层里。**

更深一层。同一个需求、不同轮次的对话，AI 给出的代码风格可能完全不同。第一次用了一种分页封装，第二次换了另一种；第一次异常走了统一包装，第二次直接往外抛。因为每一轮对话，它都在重新猜你的意图。

人写的代码有肌肉记忆，AI 没有。除非你把规矩写下来，让它每次都读。

## 五、致命问题三：质量无兜底——它不会"自动"写好测试

第三个问题最直接。

AI 生成的代码看起来对，但可能漏了边界条件、破坏了已有功能。你要怎么确认？

逐行看？三十个文件的改动，你看到第三十个的时候，前三个已经忘了。

跑测试？AI 默认不会主动给你补测试，更不会替你跑全量回归。没有自动化验证兜底，你只能靠肉眼和运气。

于是出现了一个荒诞的分工：AI 负责写，你负责发现它写错了。你成了人肉测试，而且是不带自动化脚本的那种。

## 六、三个问题，同一个根因

把三个问题放在一起看：

| 问题 | 表象 | 缺了什么 |
|---|---|---|
| 信息缺失 | AI 看不到隐式依赖 | 项目上下文 |
| 行为不一致 | 每轮对话风格漂移 | 行为规范 |
| 质量无兜底 | 靠肉眼验收 | 自动化验证 |

指向同一个根因：**Vibe Coding 缺少工程化基础设施**。AI 有能力但没有约束，有产出但没有验证。

这三个缺口，没有一个是靠"更好的提示词"能填上的。我试过把提示词越写越长，见效很短，很快就到顶了。因为提示词是一次性的，下一轮对话就失效。你需要的是持久的、每次自动生效的工程化设施。

## 七、Harness：AI 编码的"马具"

这套东西有个现成的名字：Harness，指 AI 编码的工程化基础设施。

打个比方。AI 模型像一匹好马，能力强、跑得快。但要让它稳稳跑在路上、不撞墙、不偏航，得给它套上缰绳和马鞍，还得有一条清晰的赛道。装备加环境，就是 Harness。

工程语言里是这么写的：

> **Coding Agent = AI 模型 + Harness**
>
> 模型是变量，一直在换代；Harness 才是能沉淀下来、跨代复用的资产。

这个拆分后面会反复用到。它带来一个很直接的判断：你能选的模型，和别人能选的模型，正在变得越来越像。真正拉开差距的是 Harness，也就是环境、约束、反馈、闭环这四样。

与其等下一代模型更强，不如把力气花在 Harness 上。攒提示词的经验，换个模型可能就得重来；搭 Harness 的功夫，模型换代之后照样有效。

## 八、从 Vibe 到 Spec：两条路径

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/100a010231514f0aa6ea32d576699b9d.png)

上面那条：需求 → 跟 AI 聊几句 → 生成代码 → 人看一遍改一改 → 勉强能跑。中间那个回环箭头，就是你的两个小时。

下面那条：需求 → 先写规范 → AI 照着规范生成 → 自动验证 → 一次到位。关键变化有三个：规范你说了算，AI 不用猜了，机器来兜底。

**Vibe Coding 是人跟着 AI 走，Spec Coding 是 AI 跟着规范走。**

这就是 SDD（Specification-Driven Development，规范驱动开发）的核心思想，也是后面七篇要展开的方法论。

## 九、同一个需求，两种结局

光说概念太空。同一个场景走两遍，看看差别。

场景：给一个内部管理系统的「需求池列表」加一个搜索接口，支持关键词搜索和分页。项目是常见的 Spring Boot + MySQL 单体，跑了两年多。

**凭感觉写：**

一句话丢给 AI，代码秒回，能跑。然后开始返工：

1. 排序不对。AI 默认按 ID 排，你要的是按更新时间倒序，这个"常识"你没说；
2. 软删除过滤漏了。项目里有个 `is_deleted` 字段的隐含约定，AI 不知道；
3. 分页结构不一致。项目统一的分页封装是现成的，AI 自己发明了一个新的。

改了三轮，每轮都是人工验收才发现问题。

**带规范写：**

1. 先查规范文件：接口必须用统一响应体、分页用项目统一的封装、软删除过滤在领域规范里有明文。这些全是现成答案，AI 直接读；
2. 把这些约束连同接口签名一起写进任务书，AI 按任务书生成；
3. 自动化验证兜底：编译、已有测试、规范检查，机器拦一道，再人工验收。

一轮通过。排序、软删除、分页这三个点，因为任务书里写得明明白白，AI 一个都没猜错。

同一个模型、同一台机器，差别只在：一个让它猜，一个让它读。

上面用到的"规范文件"怎么建、任务书怎么写，就是后面几篇的主题。

## 十、这个系列讲什么

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/98238b931b22ed9a79d4a5833cd9b8a6.png)

Harness 怎么落地？这个系列分五卷八篇：

- **卷一·认知**（本篇 + 第 2 篇）：为什么凭感觉不行，以及你一个人今天就能开始
- **卷二·建体系**：让 AI **看见**（理解层）、**听话**（约束层）、**可信**（验证层）。三层递进，缺一层都不稳
- **卷三·跑流程**：从需求到归档的六步工作流
- **卷四·实战**：批量修改与跨服务改动，两个真实场景走一遍
- **卷五·落地**：从一个人到全团队的推广路径

每篇末尾都有"可带走的东西"，复制就能用。

---

## 本文可带走的三件事

1. **三个问题的根因是同一个**：缺少工程化基础设施。改提示词没用，提示词是一次性的，下一轮对话就失效。
2. **Coding Agent = 模型 + Harness**：模型是变量，Harness 是资产。在 Harness 上花的每一分钟，模型换代之后依然有效。
3. **先写规范，再生成**：让 AI 不猜（规范说清楚），让机器兜底（自动化验证）。Vibe Coding 不是不能用，但它只适合低风险的小任务，项目级的活交给 Spec。

## 下一篇预告

**第 2 篇：《一个人也能开始：30 分钟建立你的第一份 AI 编程规范》**

不需要等团队达成共识，不需要任何人批准。30 分钟加一份模板，今天下班前就能让 AI 的产出质量上一个台阶。规范是写给 AI 看的，不是写给领导看的。


这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

AI 写得越快，你改得越多：Vibe Coding 的三个致命问题

AI 写代码只要十几秒，你收尾要两个小时。问题不在模型能力，而在用法：凭感觉跟 AI 对话，等于把项目的隐式约定、团队的编码规范、质量的验收标准全交给它猜。本文拆解 Vibe Coding 的三个致命问题——信息缺失、行为不一致、质量无兜底，指出三者指向同一个根因：缺少工程化基础设施。解法是先写规范再生成，让 AI 不猜，让机器兜底。

人工智能

编程语言

开发工具

AI编程工程化实践系列首篇，揭示VibeCoding三大致命问题：信息缺失、行为不一致、质量无兜底，根因在于缺乏工程化基础设施。提出Harness概念与SDD规范驱动开发方法，对比凭感觉与带规范两种路径的成效差异，强调模型是变量、Harness是资产，为后续八篇系列奠定方法论基础。

数据转换

Spring Boot

Vibe Coding

MySQL

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI 写得越快，你改得越多：Vibe Coding 的三个致命问题-腾讯云开发者社区-腾讯云

AI 写得越快，你改得越多：Vibe Coding 的三个致命问题

AI 写得越快，你改得越多：Vibe Coding 的三个致命问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐