2025-2026 年，AI 编程经历了一场静默革命。从 Vibe Coding 到 Context Engineering，从"帮我写个功能"到"先分析方案再分阶段实现"，这场变革正在重新定义"编程"这件事本身。本文基于真实开发实践与行业数据，探讨 AI 编程的正确打开方式。

---

一、先看一个真实对比：30 小时 vs 9.1 小时

先讲一个来自技术社区的真实案例。一位开发者接到"用户权限管理系统"的需求：

❌ 模式 A：Vibe Coding（直接让 AI 写代码）

对 AI 说"帮我做个用户权限系统"，AI 生成了大量 if (role === 'admin') 的硬编码：

阶段	耗时	实际情况
第一版	2h	硬编码 8 处角色判断，能跑但不知道为啥能跑
第一次迭代（加审核员）	4h	战战兢兢找齐 8 处硬编码逐一修改
第二次迭代（支持权限组）	24h	user.role（字符串）无法扩展为 user.roles（数组），推倒重来
累计	30h	代码债台高筑，每次迭代都想离职

✅ 模式 B：Spec-Kit（先让 AI 写方案再编码）

第一步花 2 小时和 AI 一起定方案：User、Role、Permission 四张表，多对多关系，策略模式做权限检查。人工审核通过后再动手。

阶段	耗时	实际情况
第一版（方案+实现）	8h	架构清晰，扩展性好
第一次迭代（加审核员）	5min	Role 表插一条数据，代码一行不动
第二次迭代（加权限组）	1h	架构已支持，加张表即可
累计	9.1h	节省 20.9 小时，心态从容

结论：前期多花 6 小时想方案，后期省下 21 小时填坑。"慢就是快"。

---

二、我的真实实践：AI 编程的"方案先行"模式

过去大半年，我在多个项目中使用 AI 编程，逐渐形成了一套固定的协作方式。核心只有一点：先让 AI 出方案，审过再动手。

2.1 多租户诊所 SaaS（ruoyi-clinic）

这是一个基于 Spring Boot + MyBatis-Plus 的多租户预约系统，clinic 域涉及三个核心模块：排班模板（scheduleTemplate）、排班（schedule）、复核（review）。需求复杂度在于：

• 多租户数据隔离（tenant_id），不能有任何跨租户数据泄露
• 排班模板 → 实际排班 → 复核，三条链路的业务逻辑各不相同
• 集成 Spring AI + DeepSeek + ChromaDB 实现 AI 问诊，需要 MCP Function Calling 架构

我的做法：每次新模块开发，第一步不是写代码，而是把需求、技术约束、现有代码结构作为上下文喂给 AI，让它先出一份方案：

目标：实现排班模板 CRUD + 按周/月视图展示
约束：MyBatis-Plus TenantEntity 自动处理 tenant_id，不显式传参
现有：已有 scheduleTemplate 实体，字段见下方 Java 类
输出：1. 接口设计（RESTful） 2. 数据库是否需要加字段 3. 前端组件划分 4. 风险点

AI 输出方案后，我会逐条审核——接口路径是否符合项目规范？前端是否复用现有 dialog 模式？多租户隔离是否被正确处理？等方案确认了，再让 AI 分阶段生成代码：先数据层 → 业务层 → 控制器 → 前端页面。

这种方法下，一次迭代跑偏的概率大幅降低。因为 AI 不需要猜我的意图——方案就是约束，代码只是执行。

2.2 HarmonyOS 支付插件（tt-unionpay）

这个项目完美诠释了"让 AI 先想再干"的价值。

任务是在 uni-app X 的 UTS 插件中集成通联支付（AllinPay）SDK，需要同时支持 Android、iOS、HarmonyOS 三个平台。我先把 AllinPay 官方文档和现有的 UTS 插件结构给 AI，让它分析：

"分析 AllinPay SDK 的集成要求，结合当前 UTS 插件架构（interface.uts → Android/iOS/HarmonyOS 分别实现），给出三个平台各自的实现方案，特别注意 HarmonyOS 平台的 ArkTS 兼容性问题。"

AI 输出的方案直接点出了几个关键风险：

1. HarmonyOS 不支持 JNI，需要纯 ArkTS 桥接方式
2. 签名计算逻辑在不同平台上的实现差异（Java 端用 MessageDigest，Swift 端用 CryptoKit，ArkTS 端用 cryptoFramework）
3. TTUnionPayAllinPayParams 接口参数不完整，缺 validtime、trxreserve、schemeurl 等字段

如果没先做方案分析，直接让 AI 写代码，等编译报错再修，代价会大得多——尤其是在 ArkTS 编译错误排查本身就比较费时的情况下。

2.3 从"修补"到"重构"的节奏

我的另一个习惯是：初始实现先跑通，确认逻辑正确后，让 AI 提取公共逻辑重构到基类。

比如在做员工管理模块时，前后端都有大量重复的 CRUD 模板代码。第一版我自己和 AI 协作把功能跑通后，第二次会话专门把已完成的代码作为上下文给 AI：

"以下三个 Controller 的 CRUD 逻辑高度相似，提取公共基类 BaseController，子类只保留差异化逻辑。输出重构方案，我确认后执行。"

AI 分析出公共方法签名和差异化点，我确认后分文件执行重构。如果在第一版就追求"完美架构"，反而会因为对需求理解不足而导致过度设计。

---

三、行业共识：从 Vibe Coding 到方案先行

"先让 AI 写方案"不是个人偏好，它正在成为行业主流实践。

3.1 数据说话

• Y Combinator 2025 年孵化的创业公司中，25% 的公司 95% 的代码由 AI 生成（Andrej Karpathy 引用数据）
• GitHub 数据显示，全球代码中 AI 生成比例已达 41%
• Vibe Coding 用户中 63% 并非专业程序员，而是设计师、产品经理、创业者
• 45% 的 AI 生成代码包含安全漏洞（Snyk 2025 报告），其中 SQL 注入占比最高（33.1%）

这意味着：AI 让"写代码"的门槛降到几乎为零，但"写出对的代码"反而更难了——因为代码量爆炸式增长，审查难度成倍增加。

3.2 关键人物观点

Andrej Karpathy（Vibe Coding 提出者，前特斯拉 AI 总监）在 2025 年末自我反思：

"作为一名程序员，我从未感到如此落后。如果我能正确整合过去一年涌现的各种资源，我的能力可以提升十倍。"

Addy Osmani（Google Chrome 开发者体验负责人）提出经典的"70% 问题"：

"AI 能极速完成前 70%，但那只是样板代码。真正的挑战——调试、安全加固、性能优化、与旧系统集成——在消失的后 30%。只有具备批判性思维和系统能力的工程师，才能完成最后 30%。"

Jim Fan（英伟达高级研究科学家）：

"你的专业水平越高，AI 工具的效果越好。如果你无法完整解释一段代码，就不应该提交它。AI 极大降低了'起步'的门槛，但并没有降低'交付高质量生产系统'的门槛。"

3.3 范式转移：从"写代码"到"定义问题"

维度	传统开发	Vibe Coding（无方案）	方案先行模式
起点	学语法、搭环境	"帮我做个XX"	先和 AI 定方案
开发者角色	编码者	许愿者	设计者 + 决策者
代码质量	取决于个人能力	开盲盒	方案约束保障下限
迭代成本	中等	越来越高	越来越低
适用场景	所有	原型、一次性脚本	所有生产项目

---

四、可操作的工作流：7 步从方案到交付

综合行业最佳实践和亲身经历，我梳理了一套可落地的 AI 编程工作流。

步骤 1：问题定义与需求澄清（Proposal）

产出：doc/proposal.md

提示词框架（可直接复用）：

## 目标
[用"用户能够…"句式描述最终结果]

## 当前资源
[已有代码、数据模型、技术约束、不可更改的条件]

## 输出要求
生成 proposal.md，包含：
1. 核心用户故事
2. 功能边界（明确标注"不在范围内"）
3. 非功能需求（性能、安全、并发）
4. 已知风险与假设
5. 可量化的验收标准

## 步骤
1. 先列出你不确定的点，主动提问
2. 我确认后再撰写文档
3. 禁止猜测任何不明确的需求

关键动作：让 AI 先提问。这能消除"静默假设"——AI 不会随便猜你的意图，而会主动暴露模糊点。

步骤 2：方案决策（人人主导，AI 辅助）

⚠️ 方案决策是人的职责，不是 AI 的。 AI 提供分析，你做决定。

让 AI 输出 2-3 个备选方案，每个覆盖 5 个维度：

维度	说明
核心思路	一段话概括技术路线
优势/劣势	各 3-5 条
技术风险	标记高/中/低，说明具体风险点
实现难度	人天估算
长期可维护性	团队技能匹配度、社区生态

反模式：不要让 AI"推荐最优方案"。AI 倾向于选择"看起来最完整"的方案（过度工程倾向）。

步骤 3：架构设计（必须新建会话）

💡 上下文污染是导致 Agent 输出质量下降的首要原因。步骤 3 开始前，清空旧上下文，仅传入 proposal.md。

产出：doc/design.md，包含：

• 模块划分（Mermaid 图）
• 核心数据流
• 接口定义
• 错误处理策略

步骤 4：任务拆分

铁律：每个任务必须在 2 小时内独立实现和测试。

# 模块：排班模板 CRUD

- [ ] T1: 数据模型 + 数据库迁移（30min）
  - 验收：entity 字段校验通过
- [ ] T2: Mapper + Service 层（60min）
  - 依赖：T1 完成
  - 验收：单元测试覆盖基本 CRUD + 多租户隔离
- [ ] T3: Controller + API 测试（30min）
  - 依赖：T2 完成
  - 验收：5 个接口全部返回正确状态码

## 上下文边界（只允许修改以下文件）
- src/main/java/.../scheduletemplate/**
- src/test/java/.../scheduletemplate/**

为什么必须明确"上下文边界"：防止 AI 修改未被要求的文件——这是 AI 编程中最常见的"边界侵入"问题。

步骤 5：最小闭环迭代实现

MVP 优先：第一阶段只实现主链路。哪怕中间步骤用 hardcode，也比追求完整性更有价值——尽早发现设计缺陷。

每次提交的验证门禁：

• 代码规范检查（ESLint / ruff）
• 类型检查（TypeScript / mypy）
• 单元测试全绿

步骤 6：安全审查（独立强制阶段）

这是最容易被忽视的环节。45% 的 AI 代码含安全漏洞。必须检查：

检查项	工具示例	重点
SQL/命令注入	Bandit, Semgrep	所有接受外部输入的查询
硬编码密钥	detect-secrets	全项目搜索 api_key、password、secret
SSRF	人工审查	所有发起 HTTP 请求的代码
不安全依赖	safety, npm audit	第三方包漏洞扫描

以通联支付插件为例：我在让 AI 写支付代码时，额外要求它把签名计算逻辑的安全分析也输出到方案中——确认密钥不硬编码、签名不在客户端计算、敏感数据加密传输。这些规则我写进了项目的 CLAUDE.md，让 AI 每次生成代码时自动遵守。

步骤 7：验收与交付

对照 proposal.md 逐条验收，全绿才算完成：

• ✅ 需求验收标准逐条通过
• ✅ 测试全绿
• ✅ 类型检查无错误
• ✅ 安全检查无高级别问题

---

五、贯穿全流程的三大实践

5.1 CLAUDE.md：与 AI 的"持久契约"

在每个项目根目录创建行为规范文件，让 AI 不再每次都猜你的偏好。我的项目 CLAUDE.md 示例：

markdown

复制

# 项目行为规范

## 核心原则
1. 不做静默假设：遇到不确定之处，立即提问
2. 最简可用解：不添加未被要求的功能或抽象
3. 遵守边界：只修改被明确指定的文件
4. 交互风格：不废话，直接出方案或代码

## 技术栈与约定
- Spring Boot 3 + MyBatis-Plus 3.5 + JDK 17
- 多租户隔离通过 TenantEntity 基类自动处理
- 前端 Vue 3 Composition API + TypeScript
- Controller 返回统一 R<T> 格式

## 禁止行为
- 不硬编码 API Key 或密码
- 签名计算不在客户端执行
- 不未经要求升级依赖版本

5.2 上下文管理：何时必须新建会话

触发条件	操作
切换到不同模块的开发	必须新建会话
AI 开始重复已拒绝的建议	立即新建（上下文已严重污染）
方案阶段完成，进入实现阶段	必须新建（用文档传递状态）
AI 输出质量明显下降	新建会话

核心原则：关键信息通过文档传递（持久、结构化、可版本控制），而不是通过聊天记录。

5.3 提示词进化：从许愿到下命令

❌ 许愿式	✅ 命令式
"帮我实现这个功能"	"在 src/.../ScheduleController.java 添加 5 个 REST 接口，返回 R<T> 格式，验收：curl 测试全部 200"
"修一下这个 bug"	"ScheduleService.create() 在租户为空时抛 NPE，复现步骤见日志，期望返回友好错误码"
"优化一下代码"	"将 3 个 Controller 中重复的 CRUD 逻辑提取到 BaseController，保留差异化逻辑，输出重构方案"

---

六、写到最后

回顾过去大半年的 AI 编程实践，我最大的感受是：AI 编程最难的从来不是"让 AI 写代码"这件事本身，而是在写之前想清楚"到底要什么"。

我们处在一个奇怪的过渡期：

• AI 已经强到可以在几秒钟内生成几百行代码
• 但大多数人还没学会用"方案"而非"愿望"去驱动它
• 结果就是：代码产出的速度前所未有地快，技术债积累的速度也前所未有地快

Vibe Coding 的概念提出者 Karpathy 本人也在反思。那些曾经让人兴奋的"一句话生成一个 App"背后，是越来越难维护的代码库和越来越深的"方向盘焦虑"——简单任务全扔给 AI，复杂任务不敢放手。

真正有效的 AI 编程，不是放弃思考，而是把思考前置到方案阶段。

让 AI 写方案，你来拍板。方案对了，代码只是执行。

这才是人机协作的正确打开方式。

---

本文基于作者在 ruoyi-clinic（多租户 SaaS）、tt-unionpay（支付插件）、jzwm-app（HarmonyOS 应用）等项目的 AI 编程实践，以及 2025-2026 年行业公开数据与案例撰写。引用来源包括 Andrej Karpathy、Addy Osmani、Jim Fan 等公开发言，及 GitHub Spec-Kit、AICodeGuide 等工具理念。