share

AI 辅助编程实战手册：从 Prompt 工程到 Agent 工作流的效率跃迁

2026-06-29 11 阅读 0 评论
✎ -- 字 🕐 -- 分钟
字号

AI 辅助编程实战手册：从 Prompt 工程到 Agent 工作流的效率跃迁

过去两年，AI 编程工具从"玩具"变成了"生产力"。但很多开发者仍然停留在"让 AI 写一段代码，然后自己改"的初级阶段。这篇文章不讲概念，只讲实操——从 Prompt 工程到 Agent 工作流，覆盖我在日常开发中验证过的 10+ 个高效实践。

一、Prompt 工程：别让 AI 猜你的意图

很多人抱怨 AI 生成的代码质量差，本质上是 Prompt 写得不好。把 AI 当成一个"懂所有语言但不知道你项目上下文的新同事"，你就能写出更好的 Prompt。

1.1 上下文是 Prompt 的灵魂

一个好的 Prompt 应该包含以下要素：

要素说明示例
角色设定定义 AI 的身份和专业领域"你是一个 Vue3 全栈开发专家"
技术栈明确使用的框架、库、版本"Vue 3.4 + Element Plus + Pinia"
约束条件代码风格、命名规范、性能要求"使用 Composition API，不要用 Options API"
输出格式指定返回格式"只输出代码，不要解释" 或 "先解释思路，再给代码"
正例/反例给参考示例"像这样处理错误…不要直接 console.log"

来看一个实际对比。先看一个"菜鸟" Prompt：

帮我写一个用户登录功能。

再看一个"老手" Prompt：

你是一个 Vue3 全栈开发专家。请帮我实现一个用户登录功能：

技术栈：Vue 3.4 + Composition API + Element Plus + Pinia
后端：Express + JWT + MySQL

要求：
1. 前端：登录表单包含用户名、密码、记住我复选框
2. 表单校验：用户名 3-20 位字母数字，密码 6-20 位
3. 登录成功后存储 token 到 localStorage，跳转到 /dashboard
4. 登录失败显示 Element Plus 的 ElMessage 错误提示
5. 后端：密码使用 bcrypt 验证，JWT 有效期 7 天
6. 错误处理：区分"用户不存在"和"密码错误"
7. 使用 async/await，不要用 .then()

请分别输出前端 Login.vue 和后端 auth.js 的完整代码。

差距一目了然。好的 Prompt 让 AI 一次生成可用代码，差的 Prompt 需要反复沟通。

1.2 分步提问法：把大任务拆成小步骤

不要试图让 AI 一次性完成整个功能。我的经验是：先让 AI 帮你设计方案，再让它逐模块实现。

# 第一步：设计方案
我正在开发一个天然气安装工程管理系统，需要实现"多公司用户切换"功能。
请帮我设计技术方案，包括：
- 前端如何存储当前选中的公司 ID
- 后端 API 如何根据公司 ID 过滤数据
- 权限如何在不同公司间隔离
只输出方案，不要代码。

# 第二步：实现具体模块
根据上面的方案，帮我实现后端中间件，在每次请求中注入当前公司 ID。

这种"分步提问法"的好处是：每一步 AI 的注意力都集中在单一任务上，输出质量明显更高。我实测下来，分步提问比一次性提问的代码可用率高出 40% 以上。

1.3 纠错式对话：把 AI 的错误变成学习机会

AI 写的代码有问题时，不要直接说"不对"，而是用以下模式：

# 错误做法
❌ "你写的代码不对，重写。"

# 正确做法
✅ "你这段代码在处理并发请求时会有竞态问题，因为第 23 行的全局变量
没有加锁。请用 Redis 分布式锁来解决，并解释为什么这样更安全。"

这种反馈方式有两个好处：一是 AI 能精准定位问题，二是你在纠正的过程中也在加深理解。把每次纠错当作 Code Review，你获得的不仅是修复后的代码，还有背后的原理。

二、AI 驱动的代码审查：让 AI 做你的 Reviewer

2.1 提交前自查清单

每次 git commit 之前，我都会用 AI 跑一遍自查：

请帮我审查以下代码，从这几个维度检查：

1. 安全漏洞：XSS、SQL 注入、敏感信息泄露
2. 性能问题：不必要的重渲染、内存泄漏、N+1 查询
3. 边界情况：空值处理、并发安全、超时处理
4. 代码规范：命名是否清晰、是否有冗余代码
5. 可维护性：是否有足够的注释、逻辑是否过于复杂

以下是代码：
[粘贴你的代码]

请按优先级（P0/P1/P2）列出发现的问题，并给出修复建议。

这个 Prompt 模板我已经用了半年，帮我在提交前拦截了不少低级的 NPE（空指针异常）和未处理的 Promise rejection。

2.2 用 AI 写单元测试

写测试是很多开发者的"痛点"，但这恰恰是 AI 最擅长的事。给 AI 一个函数，它能瞬间生成覆盖各种边界情况的测试用例：

// 源函数
function calculateProjectCost(items, discountRate = 0) {
  if (!Array.isArray(items)) throw new Error('items must be an array');
  const subtotal = items.reduce((sum, item) => {
    if (item.quantity < 0) throw new Error('quantity cannot be negative');
    return sum + item.price * item.quantity;
  }, 0);
  if (discountRate < 0 || discountRate > 1) throw new Error('invalid discount rate');
  return subtotal * (1 - discountRate);
}

给 AI 这个函数，让它用 Vitest 写测试，输出如下：

import { describe, it, expect } from 'vitest';

describe('calculateProjectCost', () => {
  it('应该正确计算无折扣的总价', () => {
    const items = [{ price: 100, quantity: 2 }, { price: 50, quantity: 3 }];
    expect(calculateProjectCost(items)).toBe(350);
  });

  it('应该正确应用折扣率', () => {
    const items = [{ price: 100, quantity: 1 }];
    expect(calculateProjectCost(items, 0.2)).toBe(80);
  });

  it('传入非数组参数应抛出异常', () => {
    expect(() => calculateProjectCost('invalid')).toThrow('items must be an array');
  });

  it('数量为负数应抛出异常', () => {
    const items = [{ price: 100, quantity: -1 }];
    expect(() => calculateProjectCost(items)).toThrow('quantity cannot be negative');
  });

  it('折扣率超出范围应抛出异常', () => {
    expect(() => calculateProjectCost([], 1.5)).toThrow('invalid discount rate');
  });

  it('空数组应返回 0', () => {
    expect(calculateProjectCost([])).toBe(0);
  });
});

我现在的习惯是：写完一个工具函数，直接把代码喂给 AI 让它生成测试，然后一键粘贴到 __tests__ 目录。覆盖率从之前的 40% 提升到了 85%。

三、Agent 工作流：让 AI 自己跑完一整套任务

3.1 什么是 Agent 工作流？

传统 AI 对话是你一句我一句。Agent 工作流则是：你给一个目标，AI 自己规划步骤、执行操作、检查结果、修正错误，直到任务完成。整个过程你只需要看最终结果。

一个典型的 Agent 工作流包含四个阶段：

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  规划     │ → │  执行     │ → │  验证     │ → │  修正     │
│ Plan      │    │ Execute   │    │ Verify    │    │ Fix       │
│ 分解任务   │    │ 调用工具   │    │ 检查结果   │    │ 重试/调整  │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
      ↑                                                  │
      └──────────────────────────────────────────────────┘
                        反馈循环

3.2 实战：用 Agent 工作流自动部署项目

以下是我在 FinBoost 项目中实际使用的 Agent 工作流 Prompt：

你需要完成以下部署任务，按照步骤逐一执行，每步成功后继续下一步，
失败则分析原因并重试（最多 3 次）：

任务：将 FinBoost 项目部署到生产服务器

步骤：
1. cd /e/workbuddy && git pull origin main
   - 检查是否有冲突，有冲突则列出冲突文件
2. npm run build
   - 检查构建输出是否有错误
3. 将 dist/ 目录通过 scp 上传到服务器 154.23.185.226:/www/wwwroot/finboost/
   - 上传前备份旧版本到 /www/backups/finboost-YYYYMMDD-HHmmss/
4. SSH 连接服务器，执行 pm2 reload finboost-api
   - 检查 pm2 status 确认进程状态为 online
5. curl http://154.23.185.226:3004/api/health 验证服务可用
   - 期望返回 {"status":"ok"}

每完成一步，用 ✅ 标记。遇到错误，用 ❌ 标记并描述错误信息。

这种工作流的核心价值在于：你不需要盯着屏幕看 AI 一步步操作，而是给它一个明确的流程和验证标准，让它自己跑。我现在的部署操作已经从"手动 15 分钟"缩减到"一条指令 + 喝杯咖啡回来看结果"。

3.3 Agent 工作流的设计原则

通过大半年的实践，我总结了设计 Agent 工作流的四条黄金法则：

原则说明反面示例
原子化步骤每步只做一件事，结果可独立验证"构建并部署并测试"——出了问题不知道哪一步挂的
显式验证每步都要有明确的成功标准"检查一下是否正常"——什么叫"正常"？
失败重试设定重试次数和退避策略一次失败就放弃，实际上可能只是网络抖动
可观测性每步输出结构化日志只输出"成功"或"失败"，看不到中间状态

四、AI 编程工具的选型与搭配

4.1 主流工具对比

工具定位强项弱项适合场景
GitHub CopilotIDE 内联补全上下文感知强，补全精准不理解项目全局架构日常编码、写样板代码
CursorAI-first IDE多文件编辑、Agent 模式学习曲线、稳定性复杂重构、跨文件修改
Claude Code / Copilot Chat终端 Agent自主执行、工具调用需要清晰指令部署、调试、文件操作
WindsurfAI IDEFlow 模式、级联推理生态较新全栈开发、项目搭建
通义灵码国内 IDE 插件中文理解好、免费英文代码生成弱国内开发者、中文项目

4.2 我的日常搭配

经过一年多折腾，我目前的 AI 编程工具栈是：

主力 IDE：VS Code + GitHub Copilot（内联补全）
复杂任务：Cursor（多文件 Agent 模式）
终端操作：Claude Code CLI（部署、日志分析、批量操作）
文档/翻译：ChatGPT（技术文档润色）
中文项目：通义灵码（作为 Copilot 的补充）

一个典型的工作流是：在 VS Code 里写业务代码，Copilot 实时补全；遇到需要跨多个文件重构的任务，切到 Cursor 用 Agent 模式批量处理；部署时在终端用 Claude Code CLI 一键执行。

五、AI 辅助编程的常见陷阱与规避

5.1 陷阱一：盲目信任 AI 的代码

AI 生成的代码看起来专业，但可能包含以下隐患：

  • 过时的 API：AI 训练数据有截止日期，可能使用已废弃的 API
  • 虚构的库：AI 会"编造"不存在的 npm 包或函数
  • 安全漏洞：AI 倾向于生成"能跑就行"的代码，忽略安全实践
  • 许可证问题：AI 生成的代码可能借鉴了 GPL 协议的代码

规避方法：永远用 npm docs 或官方文档验证 AI 引用的 API；对安全敏感代码（认证、加密、支付）必须人工审查；关键模块不要直接用 AI 生成的代码，而是让它给方案、自己写实现。

5.2 陷阱二：过度依赖导致能力退化

我见过一些初级开发者，离开 Copilot 就不会写代码了。这是最危险的陷阱。

规避方法：

# 正确的 AI 使用节奏

周一~周五：正常工作，AI 辅助（占编码量 60-70%）
周六上午：关掉所有 AI 工具，纯手写 2 小时代码
每周复盘：回顾这周 AI 帮了哪些忙、哪些地方应该自己多想

保持"脱离 AI 也能独立开发"的能力，这是底线。

5.3 陷阱三：忽视代码审查

AI 生成的代码如果不审查直接合并，相当于让一个"不懂你业务逻辑的实习生"直接提交到主分支。

规避方法：建立 AI 代码审查 Checklist：

□ 业务逻辑是否正确（AI 不理解你的业务规则）
□ 错误处理是否完善（AI 倾向于写 happy path）
□ 是否有硬编码的配置（数据库连接、API Key 等）
□ 日志记录是否充分（出问题时能快速定位）
□ 是否引入了不必要的依赖
□ 性能是否可接受（AI 可能会写 O(n²) 的循环）

六、效率提升的真实数据

最后分享一组我自己的数据。从 2025 年初开始系统化使用 AI 辅助编程，对比前后的效率变化：

指标使用前使用后提升
新功能开发速度平均 3 天/功能平均 1.5 天/功能50% ↑
Bug 修复时间平均 2 小时平均 45 分钟62% ↑
单元测试覆盖率~40%~85%112% ↑
代码审查通过率~70%~90%28% ↑
技术文档产出~1 篇/月~3 篇/月200% ↑
新技术学习时间平均 1 周平均 2 天70% ↑

数据不会说谎。AI 辅助编程不是替代开发者，而是把开发者从重复劳动中解放出来，让我们有更多时间思考架构、设计模式和业务逻辑。

七、结语：AI 时代开发者的核心竞争力

有人说 AI 会让程序员失业。我不同意。AI 淘汰的是"只会写 CRUD"的开发者，而真正有价值的能力——系统设计、业务理解、技术决策——AI 在可预见的未来都无法替代。

我总结 AI 时代开发者的三层竞争力：

第一层：会用 AI 工具               ← 入门（3 个月可达）
第二层：会设计 Agent 工作流         ← 进阶（6 个月可达）
第三层：知道 AI 该做什么、不该做什么  ← 核心（持续积累）

大部分人停留在第一层，少数人进入第二层。而真正的护城河在第三层：你比 AI 更清楚项目的业务上下文，更理解用户的真实需求，更能在模糊的需求中做出正确的技术取舍。

这篇文章分享的是我自己的实战经验，希望能帮你从第一层跨入第二层。如果你也有好用的 AI 编程技巧，欢迎在评论区交流。

后端开发