如果你最近在看 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. 核心要点速览能力项说明内容类型AI 编程方法论 / 工程师开发工作流核心观点AI 写代码不等于复制粘贴要建立完整的工程工作流主要工具Cursor、GitHub Copilot、Claude Code 等 AI 编程工具关键环节需求拆解、上下文准备、提示词设计、代码审查、测试验证、提交适合人群前端/全栈开发者、TypeScript 使用者、想系统使用 AI 编程的团队不适合场景零基础学编程、完全不看生成代码、敏感生产环境无审查部署输出目标建立一套“AI 生成 人工审查 自动化验证”的开发闭环这套课程不是让你记住几个 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 提交和回滚。IDEVS 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 --version3.2 选择 AI 编程工具市面上的 AI 编程工具主要分三类类型代表工具特点IDE 内联补全GitHub Copilot与 VS Code / JetBrains 集成补全、对话、内联编辑AI 原生编辑器Cursor基于 VS Code 的编辑器可以加载整个项目作为上下文支持 Composer 多文件编辑终端 AgentClaude Code、Gemini CLI直接操作文件系统、执行命令、运行测试适合重构和批量修改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 ViteUI 组件库是 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 --noEmit9. 常见问题与排查方法问题现象可能原因排查方式解决方案AI 生成代码报类型错误上下文里缺少类型定义文件查看报错文件是否引用了未提供的类型把类型定义文件加入上下文重新生成AI 生成代码不符合项目风格提示词缺少代码风格约束对比已有代码的命名和组件写法在提示词中增加“遵循现有代码风格”测试一直跑不过AI 对业务逻辑理解错误检查失败用例的描述是否清晰拆细任务补充验收标准AI 修改了无关文件上下文过大或依赖导入错误git diff --stat查看改动范围回滚无关文件重新限定上下文修复一个 bug 引出新 bug缺少回归测试运行完整测试集先补测试再修复测试覆盖核心路径生成代码包含安全隐患提示词未强调安全约束审查输入校验、依赖版本、密钥处理增加安全要求必要时让 AI 做安全审查生成的代码涉及版权风险训练数据中可能包含受限代码对照项目许可证评估生产代码使用前做代码溯源审查10. 最佳实践把 AI 编程工作流固定下来看完整个工作流你会发现它并不复杂难的是坚持执行。这里给几个容易落地的建议。第一第一次实践时不要选太难的任务。建议从“写一个纯函数 单测”开始先跑通“生成 - 审查 - 测试 - 提交”这个闭环。跑通之后再逐步加入重构、多文件功能开发等场景。第二把提示词模板放进项目仓库。在项目根目录创建docs/ai-prompt-template.md所有人开发前都可以参考。团队里提示词保持一致生成的代码风格差异会小很多。第三批量任务要分批验证。如果你需要 AI 一次性生成多个模块比如五个 API 接口不要让它一口气写完。每次只做一个接口验证、测试、提交再进入下一个。这样出问题时定位成本很低。第四保留“最小可运行提交”。每次迭代都保证代码能在现有测试下通过。不要出现“AI 生成了 2000 行代码但整个项目跑不起来”的状态。分步提交永远有一个可回滚的基线。第五注重代码审查和授权边界。AI 生成代码不是“作者已死”关键的业务逻辑、认证授权、涉及用户数据的代码务必人工审查。生产环境使用 AI 生成代码前需要确认项目许可证和版权合规。11. 下一步实践建议如果你打算把这套工作流用起来推荐按这样的顺序尝试用 Cursor 或 Claude Code 打开一个已有项目先让 AI 读完项目的 README 和目录结构。从一个小功能开始按照第 5 节的提示词模板写一段完整的、包含验收标准的提示词。生成代码后强制自己先做 Code Review再运行测试。测试通过后检查git diff确认 AI 没有改掉无关代码。提交信息用 Conventional Commits 规范保留清晰的变更记录。连续实践两周后再回头对比哪些环节最花时间、哪些错误是 AI 反复犯的、提示词模板还需要补哪些内容。这套方法能不能发挥价值取决于两个点一是你的工程基础是否扎实二是你愿不愿意在 AI 生成之后继续做审查和测试。工具只能缩短编码时间不能替代工程判断力。别瞎用 AI 写代码核心就是把 AI 当成流程里的一个高效协作者而不是把你的判断力外包出去。Matt Pocock 这套课程最有价值的地方就是提醒开发者回到工程本身上下文管理、代码审查、测试验证、迭代提交。真正值得长期投入的不是记住某个神奇的提示词而是养成一套稳定的工程化工作流。