别瞎用AI写代码：建立可落地的AI编程工作流指南

如果你最近在看 AI 编程工具，大概会刷到不少“让 AI 写一个 xxx 项目”的视频。但这类内容看多了容易形成一种错觉：AI 编程就是把需求丢给大模型，然后复制粘贴。真正的问题在于，复制粘贴出来的代码，能不能进生产环境？能不能通过 Code Review？出 bug 的时候，AI 能不能帮你定位？

这次聊的主题，和 Matt Pocock 的 AI 编程速成课有关。它的核心观点很直接：别瞎用 AI 写代码。Matt Pocock 是 Total TypeScript 的创始人，长期做 TypeScript 和前端工程化内容，在这套课程里他重点讲的不是某个模型的 prompt 技巧，而是一套工程师级的完整开发工作流：从需求拆解、上下文准备、AI 生成代码，到 Code Review、自动化测试、重构和提交，每一环都给出了可落地的做法。

这篇文章会把课程里最有价值的工作流思路整理出来，结合本地开发环境，给出可以照着操作的步骤、提示词模板和验证方法。如果你已经在用 Cursor、GitHub Copilot 这类 AI 编程工具，但感觉效率没有明显提升，或者生成的代码总是改了又改，那这篇内容应该能帮上忙。

1. 核心要点速览

这套课程不是让你记住几个 prompt，而是让你把 AI 编程放进现有的开发流程里。换句话说，AI 只是把编码速度提上去了，工程规范、测试意识、审查能力依然是开发者自己的核心竞争力。

2. 为什么“别瞎用 AI 写代码”

很多人用 AI 编程的日常是这样的：打开 Cursor，输入一句“写一个待办事项应用”，然后把生成的代码直接粘进项目。这样做的结果往往是：代码能跑，但看不懂；改一行，另一个地方崩了；上线之后，没人敢动这块逻辑。

这不是 AI 工具的问题，而是使用方式的问题。AI 编程工具有几个很明显的局限：

第一，AI 没有项目全局意识。它只能基于你提供的上下文来生成代码，如果你不把项目结构、依赖关系、代码规范告诉它，它就会按照自己的理解“自由发挥”，生成的代码很可能和现有架构不一致。

第二，AI 不会主动做设计决策。遇到需求模糊的地方，它会默认选择一个最常见的实现方式，但这个方式不一定适合你的业务场景。

第三，AI 生成的代码不一定安全。依赖版本过旧、SQL 注入、敏感信息硬编码，这些问题在 AI 输出里都可能出现，而且看起来还很合理。

所以 Matt Pocock 这套课程的方法论核心是：把 AI 当成一个“能力极强的初级工程师”，而不是“全知全能的神”。你需要给它足够的上下文，给它明确的验收标准，并且在它输出之后，进行代码审查和自动化测试。

把这个思路转化成工作流，其实就是下面这张图：

需求分析 → 任务拆解 → 收集/整理上下文 → 编写提示词 → AI 生成代码 → 人工 Code Review → 自动化测试（单元/集成） → 修复问题 → 提交合并 → 复盘沉淀

每一步都有对应的操作方法和注意事项，下面逐个展开。

3. 环境准备：搭建可复用的 AI 编程工作链

在开始实践这套工作流之前，需要先确认本地的工具链是完整的。AI 编程不是“装一个 IDE 就完事”，它依赖的是一整套开发环境。

3.1 基础开发环境

按照通用工程实践，建议准备以下环境：

• 操作系统：Windows / macOS / Linux 均可，macOS 和 Linux 在 shell 命令兼容性上更好。
• 包管理器：Node.js 环境建议安装 pnpm、npm 或 yarn 其中之一，用来安装依赖。
• Git：必须安装，AI 生成的代码需要通过 Git 提交和回滚。
• IDE：VS Code、Cursor、JetBrains 系列都可以。Cursor 是基于 VS Code 的 AI 编辑器，对 AI 工作流支持更完整，建议优先体验。
• TypeScript 工具链（如果做前端/Node 开发）：Node.js 18+、TypeScript 5.x。

安装完成之后，建议先确认命令可用：

node -v npm -v git --version tsc -v

如果tsc没有全局安装，可以项目内安装：

npm install -D typescript npx tsc --version

3.2 选择 AI 编程工具

市面上的 AI 编程工具主要分三类：

Matt Pocock 的课程里比较看重的一个能力是“给 AI 足够的项目上下文”。从这个维度看，Cursor 和 Claude Code 这类 Agent 型工具在理解整个项目结构方面有明显优势。

3.3 建立最小项目骨架

为了验证工作流，可以先新建一个简单的 TypeScript 项目。这样后面测试提示词和验证流程时，不会污染真实项目。

mkdir ai-workflow-demo cd ai-workflow-demo npm init -y npm install -D typescript vitest @types/node npx tsc --init

再创建一个最小入口文件：

// src/index.ts export function add(a: number, b: number): number { return a + b; } console.log(add(1, 2));

工作流验证的核心路径就是：让 AI 在已有项目上下文里生成新功能，然后通过测试确认它没有破坏现有逻辑。

4. 需求分析与任务拆解：先想清楚再让 AI 动手

这是整套工作流里最容易被跳过的一步。很多人一上来就让 AI“写一个登录功能”，然后得到一份方向不确定的代码。正确做法是先把需求拆解成 AI 能理解的小任务。

4.1 用验收标准描述需求

比如需求是“实现用户注册功能”，不能就这么扔给 AI。要拆成可验证的子任务：

1. 创建 RegisterForm 组件，包含 username、email、password 三个字段 2. 添加前端校验：用户名 3-20 个字符，邮箱格式正确，密码至少 8 位 3. 调用 POST /api/register 接口，成功跳转登录页，失败展示后端错误 4. 编写单元测试，覆盖验证失败和表单提交两种情况

把这个列表交给 AI 之前，先用自然语言写清楚验收标准。你的提示词里应该包含“输入是什么、输出是什么、成功条件是什么、失败怎么处理”这四类信息。

4.2 任务拆解的原则

拆解任务时参考这几个原则：

• 单一职责：每个子任务只做一件事，便于 AI 生成和人工审查。
• 依赖明确：指出这个任务依赖哪些已有模块。
• 可验证：每个任务都有对应的测试或手动检查方式。
• 粒度适中：单个任务的工作量控制在几十分钟内，方便检查。

4.3 让 AI 参与拆解

如果不知道需求怎么拆，也可以先让 AI 帮你拆。比如：

当前项目是一个 Express + TypeScript 的 API 服务。我需要实现用户注册功能， 包括数据库存储、密码加密、邮件验证、前端页面。 请把需求拆成可独立实现的子任务，每个任务包含输入、输出和验收标准。

这里的关键是先告诉 AI“项目是什么技术栈、有哪些约束”，再让它拆解。它给出的拆解可能不完美，但可以作为讨论起点，避免你从零开始列清单。

5. 提示词设计：从“写一个 xxx”到“完成一件具体的事”

提示词是很多人最关心的问题，但 Matt Pocock 的工作流里，提示词只占一部分。真正的重点是“如何让 AI 在你项目的上下文里工作”。

5.1 提示词的最小要素

一个合格的编程提示词至少包含五个部分：

【角色】你是一个熟悉 TypeScript 的资深前端工程师 【任务】在 src/components/ 下创建 RegisterForm 组件 【上下文】项目使用 React 18 + TypeScript + Vite，UI 组件库是 Ant Design 5， 已有 apiClient 实例位于 src/api/client.ts，导出 post 方法 【约束】使用函数组件，不引入额外依赖；表单校验使用 react-hook-form； 错误信息显示在表单底部 【验收】npm run test 中新增的测试全部通过；组件可独立渲染

对比一下两种写法的差别：

普通写法：写一个注册表单组件

工程化写法：在 React 项目中创建 RegisterForm 组件，使用 react-hook-form 实现用户名、邮箱、密码三个字段的校验，提交时调用 src/api/client.ts 的 post 方法请求 /api/register，成功后跳转 /login，失败展示错误信息。 不引入额外 UI 依赖，组件风格与现有 LoginForm 保持一致。

第二种写法看起来复杂，但它把“上下文”“约束”“验收标准”都说清楚了。AI 生成的代码不需要你反复修改。

5.2 上下文管理技巧

Cursor 和 Copilot 都支持多文件上下文，但上下文不是越多越好。直接把整个项目丢给 AI，它反而会被无关代码干扰。

推荐做法：

• 只把任务涉及的文件加入上下文，比如组件文件、类型定义文件、API 客户端。
• 用@引用具体的文件，而不是让 AI 自己猜。
• 如果项目有 README 或者贡献指南，可以把关键规范片段粘贴到提示词里。
• 项目较大时，先让 AI 读取目录结构，再聚焦具体文件。

5.3 复用一个可沉淀的提示词模板

建议把常用提示词结构保存成项目里的docs/ai-prompt-template.md，每次开发前复制一份填写。模板可以参考：

## 任务描述 一句话说明要做什么。 ## 项目上下文 - 技术栈： - 相关文件： - 依赖模块： ## 功能要求 1. 2. 3. ## 约束条件 - 不引入额外依赖 - 遵循现有代码风格 - 输出 TypeScript 类型定义 ## 验收标准 - [ ] 单元测试通过 - [ ] 类型检查通过（tsc --noEmit） - [ ] 手动验证通过

这样做的价值在于：提示词不再是一次性的对话，而是可复用的团队规范。新人拿到模板也能快速上手。

6. 从 AI 生成到代码提交：打造开发闭环

有了提示词模板和任务拆解，接下来就是循环执行“生成 -> 审查 -> 测试 -> 修复 -> 提交”。

6.1 让 AI 生成代码

在 Cursor 里可以用 Composer 或 Chat 模式。

如果是在终端使用 Claude Code：

# 把任务描述保存为文件，然后让 agent 按文件执行 claude -p "阅读 docs/task-register-form.md，并按照要求实现代码"

如果直接用命令交互：

claude "创建 src/components/RegisterForm.tsx，参照 docs/task-register-form.md 的需求"

6.2 代码审查：不要在没看过的代码上偷懒

AI 生成代码之后，最重要的一步是 Code Review。Matt Pocock 的课程里强调的是“让 AI 写代码，但由你负责质量和安全”。具体的审查点：

• 类型安全：有没有使用any，有没有因为类型不完整导致运行时错误。
• 错误处理：网络请求失败、输入校验失败是否都有处理。
• 安全：有没有硬编码密钥、有没有 SQL 拼接、有没有不安全的eval。
• 性能：有没有不必要的循环、重复渲染、大对象拷贝。
• 架构一致性：命名风格、组件划分、状态管理方式是否和项目现有代码一致。

如果审查过程中觉得理解成本太高，说明 AI 生成的代码不够清晰，可以让 AI 补充注释或直接重构：

请对这段代码做 Code Review，列出潜在 bug、安全隐患和可读性问题， 并给出修改后的版本。

6.3 自动化测试验证

代码审查看的是静态问题，动态问题要靠测试。在 TypeScript 项目中，单元测试和类型检查是最低门槛：

# 类型检查 npx tsc --noEmit # 运行测试 npx vitest run

如果现有项目没有测试框架，可以先用一个最小用例验证 AI 生成的功能。以src/index.ts为例：

// src/index.test.ts import { describe, it, expect } from 'vitest'; import { add } from './index'; describe('add', () => { it('should add two numbers', () => { expect(add(1, 2)).toBe(3); }); it('should handle negative numbers', () => { expect(add(-1, -2)).toBe(-3); }); });

提交代码前，把测试结果贴在 AI 对话里，让它知道哪些用例失败，再让它修复。

6.4 提交与合并

AI 生成的代码也需要走常规的 Git 流程。建议让 AI 生成 commit message，但提交前确认它没有把无关文件加进来：

git add . git diff --cached git commit -m "feat: 实现用户注册表单组件"

提交信息建议遵循 Conventional Commits 规范，格式是type(scope): subject。这样后期回滚和生成 changelog 都很方便。

7. 测试优先：让 AI 先写测试再写实现

Matt Pocock 的课程里有一个值得借鉴的实践：先让 AI 写测试，再写实现代码。这样做的好处很明显，测试本身就是“验收标准”，AI 在实现时会对照测试来调整行为，生成的代码更可控。

具体步骤：

第一步，把测试需求描述清楚：

为 src/utils/formatDate.ts 中的 formatDate 函数编写测试。 函数签名：function formatDate(date: Date, format: string): string 支持格式：YYYY-MM-DD、YYYY/MM/DD、HH:mm:ss 要求： - 覆盖日期和时间的正确格式化 - 覆盖无效日期输入 - 使用 vitest

第二步，让 AI 先输出测试文件，运行测试确认失败（因为实现还不存在）。

第三步，让 AI 根据测试实现功能，直到所有测试通过。

这样做的额外好处是：测试文件本身就是文档，后面其他开发者接手时，通过测试就能了解函数的行为。

8. 重构与修复：AI 在老代码上的正确用法

对已有代码，AI 编程工具同样能大幅提升效率，但要遵循比新功能开发更严格的流程。

8.1 让 AI 重构时要保留行为

重构的核心是“不改变外部行为，只改善内部结构”。所以提示词里必须强调这一点：

对 src/utils/price.ts 中的计算逻辑做重构，目标是提升可读性和可维护性。 要求： 1. 不改变函数签名和返回值 2. 不改变任何外部行为 3. 适当拆分过长的函数 4. 重命名语义不清晰的变量 5. 重构后用现有测试验证行为不变

如果项目没有测试，第一步先让 AI 补测试，再做重构。没有测试保护的重构，风险很高。

8.2 让 AI 解释而不是直接修 bug

遇到报错时，建议先让 AI 解释错误原因，再决定怎么改。这样做能帮你判断 AI 的理解是否准确，也避免它把一个问题修成另一个问题。

运行 npm test 时出现以下报错： Error: expect(received).toBe(expected) // Object.is equality - Expected: "2024-01-01" + Received: "2024-1-1" 请先分析可能原因，再给出修复方案。不要直接修改代码。

课程里强调了一个点：AI 对常见的开箱即用问题修复得很好，但对拼接式、状态相关的 bug 容易做出错误判断。因此，只要修复涉及多文件协作，一定要让 AI 解释思路，再由你确认。

8.3 修复后的回归检查

每一次修复，都应该跑一次完整的测试和类型检查。工作流闭环看起来像这样：

# 1. 跑测试，定位失败用例 npx vitest run # 2. 把失败信息提供给 AI，让它修复 # 3. 再跑测试，确认通过 npx vitest run # 4. 类型检查 npx tsc --noEmit

9. 常见问题与排查方法

10. 最佳实践：把 AI 编程工作流固定下来

看完整个工作流，你会发现它并不复杂，难的是坚持执行。这里给几个容易落地的建议。

第一，第一次实践时不要选太难的任务。建议从“写一个纯函数 + 单测”开始，先跑通“生成 -> 审查 -> 测试 -> 提交”这个闭环。跑通之后，再逐步加入重构、多文件功能开发等场景。

第二，把提示词模板放进项目仓库。在项目根目录创建docs/ai-prompt-template.md，所有人开发前都可以参考。团队里提示词保持一致，生成的代码风格差异会小很多。

第三，批量任务要分批验证。如果你需要 AI 一次性生成多个模块，比如五个 API 接口，不要让它一口气写完。每次只做一个接口，验证、测试、提交，再进入下一个。这样出问题时定位成本很低。

第四，保留“最小可运行提交”。每次迭代都保证代码能在现有测试下通过。不要出现“AI 生成了 2000 行代码但整个项目跑不起来”的状态。分步提交，永远有一个可回滚的基线。

第五，注重代码审查和授权边界。AI 生成代码不是“作者已死”，关键的业务逻辑、认证授权、涉及用户数据的代码，务必人工审查。生产环境使用 AI 生成代码前，需要确认项目许可证和版权合规。

11. 下一步实践建议

如果你打算把这套工作流用起来，推荐按这样的顺序尝试：

1. 用 Cursor 或 Claude Code 打开一个已有项目，先让 AI 读完项目的 README 和目录结构。
2. 从一个小功能开始，按照第 5 节的提示词模板写一段完整的、包含验收标准的提示词。
3. 生成代码后，强制自己先做 Code Review，再运行测试。
4. 测试通过后，检查git diff，确认 AI 没有改掉无关代码。
5. 提交信息用 Conventional Commits 规范，保留清晰的变更记录。
6. 连续实践两周后，再回头对比：哪些环节最花时间、哪些错误是 AI 反复犯的、提示词模板还需要补哪些内容。

这套方法能不能发挥价值，取决于两个点：一是你的工程基础是否扎实，二是你愿不愿意在 AI 生成之后继续做审查和测试。工具只能缩短编码时间，不能替代工程判断力。别瞎用 AI 写代码，核心就是把 AI 当成流程里的一个高效协作者，而不是把你的判断力外包出去。

Matt Pocock 这套课程最有价值的地方，就是提醒开发者回到工程本身：上下文管理、代码审查、测试验证、迭代提交。真正值得长期投入的，不是记住某个神奇的提示词，而是养成一套稳定的工程化工作流。