在实际开发中使用 AI 编程工具最典型的问题是拿到需求后直接让 AI 生成一整套代码再把报错信息原样丢回去让它自行修复。这样循环几轮后代码能跑了但没人能解释清楚它到底做了什么也没人敢保证下一次改动不会破坏现有功能。Matt Pocock 的 AI 编程速成课讨论的核心正是这一点问题不在于 AI 能不能写代码而在于你是否用一套工程流程去约束它。AI 编程的真正价值不在于“快速产出代码”而在于把程序员从重复样板代码和琐碎细节里解放出来。要做到这一点需要的不是更强的模型而是更严格的开发工作流。这套工作流包含需求拆解、上下文准备、提示词设计、代码审查、自动化验证和回滚机制。本文按这套流程展开先解释为什么不能“瞎用 AI 写代码”再给出一套可以直接落地的工程师级 AI 编程工作流。这套流程适合以下读者已经在用 Cursor、GitHub Copilot、Claude、ChatGPT 等工具写代码但经常改完一处坏掉另一处的人想从“让 AI 写小程序”过渡到“让 AI 参与正式项目开发”的人以及正在把 AI 编码能力引入团队但没有统一规范的工程负责人。1. 为什么“遇到问题就丢给 AI”反而会拖慢开发效率很多开发者的 AI 编程起步方式完全一样打开编辑器输入一段自然语言描述复制生成的代码到项目里运行报错再把报错日志贴回去让 AI 继续改。这种用法在最简单的脚本里有效但一旦进入真实项目就会频繁陷入“修改一个函数引发另一个文件报错”的循环。1.1 典型低效用法把 AI 当自动补全把提示词当搜索框低效用法有几个明显特征。第一提示词里没有约束条件只说“帮我写一个上传文件功能”既不说明框架版本也不说明文件大小限制、存储路径、是否需要断点续传。第二生成代码后不检查依赖直接复制到项目里遇到缺少包就跑npm install或pip install补齐。第三报错后不分析根因直接把终端日志完整粘贴给 AI让它猜测哪里出了问题。这种工作方式会带来两个后果。一是上下文丢失AI 只看到你贴出来的错误看不到完整项目结构于是只能给出一份“看起来很合理”的修复建议而这个建议很可能与项目的现有设计冲突。二是验证缺失AI 生成代码之后没有测试、类型检查、静态分析这些防线错误只能靠运行时发现越到后期修复成本越高。这里的关键认知是AI 编程工具再强大它也不了解你的项目。它不了解你的目录结构、命名规范、依赖锁定策略、错误处理约定。如果你不把这些信息主动提供给 AI它就只能基于通用知识输出代码而通用知识往往和你的项目冲突。1.2 从“让 AI 写代码”到“用 AI 完成一个工程步骤”的转变正确的使用方式不是“让 AI 写代码”而是“用 AI 完成一个明确定义的工程步骤”。这两者的区别在于任务边界。“让 AI 写代码”的任务边界非常模糊AI 需要自己做大量假设而假设最容易出错。比如“写一个登录功能”AI 需要猜测你用的是 Session 还是 JWT、密码要不要加密、登录失败要不要限制次数、数据库表结构是什么样的。这些假设里只要有一个错误生成的代码就无法在当前项目里运行。“用 AI 完成一个工程步骤”则不同你先把任务拆小再给 AI 提供足够上下文让它只负责其中一个环节。例如“在src/services/auth.ts中实现一个verifyPassword函数输入是明文密码和数据库中读取的哈希值使用bcryptjs的compare方法返回Promiseboolean如果参数为空则返回false并写日志”。这样 AI 不需要猜测整体架构它只需要实现一个函数而且函数的输入、输出、依赖、异常行为都被约束住了。把任务拆小的好处不仅是让 AI 更准确也让代码审查变得容易。一段 20 行的函数人可以逐行检查一段 500 行的全新模块几乎没有人会认真读完问题就这样混进了版本库。1.3 工程师级 AI 编程工作流的核心拆解、约束、验证、回滚工程师级的 AI 编程工作流可以简化为四个动作拆解、约束、验证、回滚。拆解是把一个完整需求拆成多个可独立验证的小任务。约束是在提示词中明确依赖、输入、输出、边界条件和代码风格。验证是对 AI 生成的代码运行类型检查、单元测试、lint 和必要的人工审查。回滚是指当验证失败且无法快速修复时放弃 AI 的修改回到上一个已知正常的版本而不是继续在错误代码上打补丁。这四个动作里验证和回滚是最容易被初学者忽略的。很多人觉得 AI 生成的代码已经能跑就说明没有问题。实际上“能跑”和“正确”之间还有很大距离代码是否处理了空值是否在并发环境下安全是否遵循项目现有风格是否引入新的依赖是否覆盖了异常分支这些都需要验证机制来回答。2. 环境准备先建立 AI 编码所需的上下文和验证工具链AI 编程不是打开一个聊天窗口就能做好的它需要一套环境和工具链来支撑。这套环境的价值在于让 AI 输出的代码能够立即被验证让错误能够被快速定位让修改可以被随时回滚。2.1 学习环境的最小搭配在本地学习时最少需要以下内容一个代码编辑器推荐 VSCode 或 Cursor安装对应 AI 插件。一个版本控制工具Git 是必须的每次 AI 修改前先提交或建分支。一个项目脚手架让项目结构规范可预期避免每次从零开始。一组验证命令至少包含构建、测试、lint 三类。以 TypeScript 项目为例最小搭配如下node -v npm -v git --version一个最小的 TypeScript CLI 项目结构可以是ai-workflow-demo/ ├── package.json ├── tsconfig.json ├── src/ │ ├── index.ts │ └── rename.ts └── tests/ └── rename.test.tspackage.json里至少需要以下内容{ name: ai-workflow-demo, version: 1.0.0, type: module, scripts: { build: tsc, test: node --test --experimental-strip-types tests/, lint: eslint src/ }, devDependencies: { typescript: ^5.5.0, types/node: ^20.0.0, eslint: ^9.0.0 } }学习环境下不需要把配置做得非常复杂关键是验证命令要短、要快、要可重复。任何 AI 生成的代码提交前都要能跑通这三条命令。注意学习环境的目标是快速验证工作流本身不要在一开始就引入复杂构建工具、微服务拆分、多环境部署。先在一个单仓库里跑通完整流程再迁移到更大项目。2.2 生产环境需要额外补充的能力生产环境不能照搬学习环境的做法。AI 生成代码进入生产项目前还需要额外补齐几类能力。第一依赖锁定。学习环境里可以随意npm install最新版本生产环境必须使用package-lock.json、pnpm-lock.yaml或等价的锁文件确保所有开发者的依赖版本一致。第二CI 集成。本地验证通过还不够提交代码后需要由 CI 在干净环境里重新执行安装、构建、测试和 lint避免“本地能跑别人拉下来跑不了”的问题。第三代码审查。AI 生成的代码必须经过有经验的人审查不能直接合并到主干。第四回滚机制。项目的部署方式必须支持快速回滚到上一个版本当 AI 修改引发线上问题时能立即恢复。这些能力并不完全是 AI 编程引入的它们是生产项目本来就应该有的工程基础。AI 编码只是把这些要求提到了更重要的位置因为 AI 修改代码的速度远高于人工代码评审的速度如果评审和验证跟不上风险就会成倍放大。2.3 示例项目结构一个可被 AI 修改的最小 TypeScript CLI下面用一个模拟场景作为全文示例实现一个批量重命名文件的 CLI 工具。这个场景足够小便于演示工作流又足够真实能展示函数拆分、错误处理和测试。src/rename.ts里先放一个核心函数AI 后续的所有改动都围绕这个函数展开import { readdir, rename as fsRename } from node:fs/promises; import path from node:path; export interface RenameRule { from: string; to: string; } export async function renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] { const files await readdir(dir); const results: { source: string; target: string }[] []; for (const file of files) { let newName file; for (const rule of rules) { newName newName.split(rule.from).join(rule.to); } if (newName ! file) { const sourcePath path.join(dir, file); const targetPath path.join(dir, newName); await fsRename(sourcePath, targetPath); results.push({ source: file, target: newName }); } } return results; }这个函数会读取目标目录下的所有文件按规则替换文件名并返回重命名记录。它在设计上有一个重要约束先把所有替换规则都应用到文件名上再执行重命名这样避免规则之间相互干扰。让 AI 修改时必须保证它理解这个约束。src/index.ts是 CLI 入口import { renameFiles } from ./rename.js; const dir process.argv[2]; if (!dir) { console.error(Usage: npm run cli -- directory); process.exit(1); } const rules [ { from: draft_, to: }, { from: final_, to: release_ }, ]; try { const results await renameFiles(dir, rules); for (const r of results) { console.log(${r.source} - ${r.target}); } } catch (err) { console.error(Rename failed:, err); process.exit(1); }这个最小项目就是后面所有提示词、验证、排错的载体。实际项目里文件名、目录结构、规则内容都会不同但工作流是同一个。3. 从需求到任务拆解把一句话需求变成可执行的开发步骤AI 编程最容易翻车的环节不在写提示词而在需求拆解。需求拆得越粗AI 的假设越多后续验证与修复的成本越高。3.1 需求拆解清单功能、输入、输出、异常、边界一个工程需求被交给 AI 之前至少需要回答五类问题问题类型需要明确的信息示例功能要做什么做到什么程度批量重命名文件支持多组替换规则输入输入从哪里来格式是什么目标目录路径规则列表输出返回值或副作用是什么返回重命名记录控制台输出日志异常哪些情况属于错误怎么处理目录不存在、文件不存在、权限不足边界空目录、重复文件名、超长路径怎么处理空目录返回空数组替换后同名文件覆盖前先确认可以用这个清单去检查 AI 生成的代码也可以反过来用同一个清单去写提示词。如果需求描述里缺少任何一项不要急着让 AI 写代码先补齐需求。3.2 一份可直接复制使用的任务卡片模板把需求拆解结果整理成任务卡片是让 AI 保持聚焦的有效方式。任务卡片的表达方式比随口一句“帮我写个功能”更有约束力。任务标题实现批量文件名替换功能 背景 项目是一个 TypeScript CLI 工具入口是 src/index.ts核心函数放在 src/rename.ts。 目录结构如下 src/index.ts src/rename.ts tests/rename.test.ts 任务描述 在 src/rename.ts 中实现 renameFiles 函数。 函数签名 renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] 输入 - dir需要重命名的目标目录 - rules替换规则列表每个规则包含 from 和 to 两个字符串 处理逻辑 - 读取 dir 目录下的所有文件名 - 对每个文件名依次应用所有替换规则 - 替换后的文件名与原文件名不同时执行重命名 - 返回所有重命名记录的数组 约束 - 使用 node:fs/promises 的 readdir 和 rename - 不修改文件内容 - 目录不存在时抛出错误由调用方处理 - 代码风格遵循项目现有 ESLint 规则 验收标准 - tests/rename.test.ts 中新增测试覆盖以下场景 1. 目录为空时返回空数组 2. 文件名包含规则中的字符串时被替换 3. 文件名不包含规则中的字符串时保持不变 4. 多组规则依次生效 - 运行 npm run build 和 npm test 全部通过任务卡片的核心是“把 AI 当作一个刚加入项目、不了解历史背景的新同事”。你提供的信息越多它的输出越贴近项目实际。3.3 拆解示例给“写一个文件名批量重命名工具”做拆分“写一个文件名批量重命名工具”是一个完整的项目需求直接交给 AI 会让它同时处理目录遍历、字符串替换、重命名、日志、错误处理、测试等多个问题。按任务卡片思路可以拆成四个原子任务任务一实现renameFiles核心函数接收目录和规则返回重命名记录。任务二实现 CLI 入口解析命令行参数调用renameFiles打印结果。任务三编写单元测试覆盖正常替换、空目录、无匹配、多规则等场景。任务四编写 README说明用法、参数和已知限制。每个任务都可以单独交给 AI也可以由人完成其中一部分。拆分后的任务各自都能被验证任务一需要测试通过任务二需要手动运行 CLI 观察输出任务三需要测试覆盖率任务四需要文档可读性。4. 编写提示词让 AI 在受限上下文里完成单个任务提示词不是越长越好但关键信息必须完整。一个工程级的提示词最少要覆盖角色、任务、输入输出、约束、验证方式这五个要素。4.1 提示词的五个基本要素要素说明示例角色告诉 AI 它在项目中承担什么角色“你是一名熟悉 TypeScript 和 Node.js 的工程师”任务说明要完成的具体工作“在 src/rename.ts 中实现 renameFiles 函数”输入输出明确输入参数、返回类型、副作用“返回 Promise{source,target}[]”约束指定依赖、风格、边界条件“使用 node:fs/promises不修改文件内容”验证告诉 AI 如何判断结果是否正确“npm run build 和 npm test 必须通过”这五个要素最容易被忽略的是“验证”。很多提示词不说明验收标准AI 自然无法自检只能凭感觉输出“看起来完整”的代码。加入验证方式后AI 会在生成代码时主动考虑测试用例是否通过。4.2 一段可复用的提示词模板下面是基于五要素设计的一段通用提示词模板适合用于修改或新增一个函数的情况。你是本项目的一名 TypeScript 工程师。项目是 Node.js CLI 工具使用 ESM 模块TypeScript 严格模式。 任务 在 src/rename.ts 中实现 renameFiles 函数。 上下文 - 项目目录结构 src/index.ts src/rename.ts tests/rename.test.ts - 已有代码使用 node:fs/promises路径拼接使用 node:path。 函数签名 renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] 要求 1. 使用 node:fs/promises 的 readdir 和 rename不要使用 child_process。 2. 对每个文件名依次应用所有规则。 3. 替换后的文件名与原文件名不同时执行重命名。 4. 目录不存在时抛出错误由调用方处理。 5. 不修改 tests/ 目录下的文件。 完成后会执行以下命令验证 npm run build npm test 在回答中先给出完整代码再用三到五行说明你的实现思路。这段提示词里项目背景、任务范围、技术约束和验证命令都是明确给出的。实际项目中可以把这段提示词保存为模板每次使用时替换项目背景、文件名和函数签名即可。4.3 提示词里常被忽略的约束依赖、目录、命名、兼容性除了功能描述工程约束往往才是决定代码能否合入的关键。依赖约束是最常见的坑。AI 经常会提议安装新依赖比如把字符串替换写成lodash的replace但项目中可能并不需要引入这个库。提示词里明确“禁止引入新依赖如果确有必要先说明理由”能显著减少这种问题。目录约束也很重要。AI 不清楚项目的模块边界可能把工具函数写到入口文件里也可能在src/services里实现一个本该放到src/utils的纯函数。在提示词里明确文件路径能够避免无预期的文件改动。命名约束影响代码审查成本。AI 生成的变量名、函数名可能风格不同比如项目里统一使用fetchUser、findUserByIdAI 却生成一个getUserData。这类不一致会在代码审查阶段占用大量时间。通常在提示词里给出一到两个命名示例AI 的命名会明显更贴近项目风格。兼容性约束与运行环境有关。Node.js 版本、浏览器支持范围、TypeScript 编译目标都会影响 AI 选用的语法和 API。提示词里写明Node.js 20、TypeScript strict mode、ESM这类信息可以减少代码生成后再做一遍适配的情况。5. 生成代码后的工程验证不能只问“能不能跑”AI 生成代码后第一个动作不应该是复制粘贴运行而是把代码放到验证流程里过一遍。验证流程可以分成四层每一层解决的问题都不同。5.1 验证分层静态检查、单测、手工验证、回归验证第一层是静态检查包括类型检查、lint、格式化检查。这类检查能在不运行代码的情况下发现大量低级错误比如类型不匹配、未使用的变量、违反代码风格的地方。npm run build npm run lint第二层是单元测试。单元测试验证的是函数级别的行为输入、输出、异常分支是否满足预期。对于 AI 生成的纯函数、工具函数单元测试是最可靠的验证方式。第三层是手工验证。手工验证的价值在于发现“测试没有覆盖到但实际使用会碰到”的问题。比如文件名包含空格、中文名、后缀大小写不一致这些在真实文件系统里很常见但在单元测试里容易被忽略。第四层是回归验证。AI 修改了一个函数后不能只看这个函数本身是否符合要求还要确认它没有破坏调用方的行为。回归验证依赖项目的现有测试体系和 CI没有 CI 的项目至少要在本地跑一遍全量测试。5.2 用最小测试验证 AI 生成的函数回到重命名工具示例。renameFiles函数接收目录和规则返回重命名记录。测试时要覆盖正常场景、空目录、无匹配、多规则四种情况。使用 Node.js 内置node:test的最小测试可以这样写import { test } from node:test; import assert from node:assert/strict; import { mkdtemp, mkdir, writeFile, readdir } from node:fs/promises; import os from node:os; import path from node:path; import { renameFiles } from ../src/rename.js; async function createTempDir(): Promisestring { return mkdtemp(path.join(os.tmpdir(), rename-test-)); } test(renameFiles replaces filename substrings, async () { const dir await createTempDir(); await writeFile(path.join(dir, draft_report.md), content); const results await renameFiles(dir, [{ from: draft_, to: }]); assert.equal(results.length, 1); assert.equal(results[0].source, draft_report.md); assert.equal(results[0].target, report.md); const files await readdir(dir); assert.deepEqual(files, [report.md]); }); test(renameFiles returns empty array for empty directory, async () { const dir await createTempDir(); const results await renameFiles(dir, [{ from: a, to: b }]); assert.deepEqual(results, []); }); test(renameFiles applies multiple rules in sequence, async () { const dir await createTempDir(); await writeFile(path.join(dir, draft_final_notes.txt), content); const results await renameFiles(dir, [ { from: draft_, to: }, { from: final_, to: release_ }, ]); assert.equal(results[0].source, draft_final_notes.txt); assert.equal(results[0].target, release_notes.txt); });这段测试使用了系统临时目录保证测试不会污染真实文件。测试断言既检查了返回值也检查了文件系统里的最终文件名这样能同时验证函数逻辑和实际效果。5.3 AI 产出代码进版本库前的人工审查要点自动化验证不能替代人工审查。AI 生成的代码通过测试不代表它一定适合合入版本库。人工审查时重点看以下几项命名是否与项目现有风格一致比如文件命名、变量命名、函数命名。错误处理是否符合项目约定比如是向上抛异常还是记录日志后继续。是否有不必要的新增依赖依赖是开发依赖还是生产依赖。是否存在于当前任务无关的代码改动。是否能处理极端输入比如空字符串、超长路径、特殊字符。如果 AI 在一次改动里同时修改了多个文件审查时更要警惕。理想情况下一次提交只解决一个问题AI 的改动范围应严格限制在任务卡片指定的文件内。6. 常见问题排查AI 生成代码跑不通时按这条链路查AI 生成代码报错时不要立刻把报错完整复制给 AI 请求重写。按下面的排查链路走一遍很多问题会更早暴露。排查顺序检查输入是否正确目录路径、参数名、环境变量是否真的传入了。检查文件路径和命名AI 生成的文件是否在预期位置文件名后缀是否匹配比如.tsvs.js。检查依赖版本新装的包和项目现有版本是否冲突。检查配置是否生效ESLint 规则、TypeScript 配置、打包配置是否被 AI 修改过。检查权限、端口、网络、环境变量本地测试和线上环境是否一致。检查日志中的异常根因不是看最后一行的 Error而是看完整堆栈。确认框架或工具自身的版本限制某些 API 在旧版本中不存在。6.1 现象一依赖缺失或版本冲突现象是运行时报Cannot find module或类型检查报找不到类型定义。可能原因通常是 AI 在代码里引用了新依赖但没有执行安装或者 AI 使用的是通用示例里的版本号跟项目实际版本不兼容。检查方式npm ls package-name如果没有安装先确认是否需要这个依赖。如果确实需要安装后检查版本范围。npm install some-package如果是版本冲突优先查看node_modules下该包的实际版本再对比项目里其他依赖的声明范围。6.2 现象二AI 改动了不该改的文件现象是 Git 工作区里出现大量无关文件改动或者代码审查时发现 AI 顺手调整了配置文件。原因通常是提示词里没有明确改动范围。AI 没有“只改某个文件”的意识它会在生成解决方案时顺手修改它能看到的文件。检查方式git diff --name-only这条命令能快速列出所有被修改的文件。如果列表里出现与任务无关的文件直接回退这部分改动不要把无关改动一起提交。git checkout -- unrelated-file6.3 现象三代码在本地能跑提交后 CI 挂掉现象是本地npm test全部通过推到远端后 CI 失败。常见原因有三个方向本地环境缺少锁文件导致 CI 安装的依赖版本不一致测试依赖了本地存在的文件或环境变量AI 生成的代码里包含平台相关的路径分隔符或命令。先检查锁文件是否被提交到版本库再检查 CI 日志中失败的测试是不是本地没有覆盖到的场景。如果测试使用了路径拼接优先使用path.join而不是手写反斜杠或正斜杠。6.4 现象四AI 出现幻觉写出了不存在的 API现象是代码里引用的某个函数、包、选项在官方文档里不存在但 AI 给出的代码看起来非常合理。AI 幻觉在处理冷门库、新版本、内部工具时更容易出现。它可能把两个类似 API 混在一起也可能从训练数据里生成了一个从未存在的函数名。遇到这类情况不要反复让 AI 修改同一段代码先到官方文档或对应包的类型声明里确认真实 API。比如在node_modules里搜索函数名或者查看库的 TypeScript 类型定义。grep -r someFunction node_modules/some-package/确认 API 不存在后放弃这段代码的修修补补改为用文档中的真实 API 重新编写并在提示词里附上文档链接。7. 学习环境与生产环境从“能跑”到“能上线”之间缺什么AI 编程工作流在不同环境的目标不同。学习环境的重点是快速验证流程是否正确生产环境则要考虑代码上线后的一切风险。7.1 学习环境快速试错重点验证流程学习环境里不需要追求一次写对。可以用最小项目反复练习提示词设计、任务拆解和验证流程目标是形成肌肉记忆任何任务先拆解再写提示词再验证最后合入。可以在本地准备一个专门的练习仓库每次 AI 改动前先建分支或打 tag保证随时能回到上一个可用状态。git checkout -b feature/ai-rename # AI 生成代码并验证通过后 git add . git commit -m feat: implement renameFiles with AI实践一段时间后你会形成自己常用的提示词模板、任务卡片模板、验证命令清单。这些模板比记住某个 AI 工具的具体用法更有长期价值。7.2 生产环境日志、监控、权限、回滚、审计一个都不能少生产环境里使用 AI 生成的代码前面提到的验证流程一样都不能少另外还要补充几项。日志与监控AI 生成的错误处理代码如果没有日志出问题后很难定位。在提示词里明确要求“所有 catch 分支必须包含 error 日志并携带关键上下文”。权限最小化AI 生成的代码可能请求过多权限比如一个只读文件的功能代码里却以写权限打开文件。生产环境要遵循最小权限原则。回滚方案每次 AI 生成的改动合入主干前都需要有对应的回滚方案。最简单的方式是使用 Git 版本回退和部署平台的上一版本切换功能确保线上出问题时可以在几分钟内恢复。审计与评审AI 生成代码的合并请求必须经过人工评审。对于涉及支付、权限、数据删除等敏感逻辑的代码建议不直接使用 AI 的最终输出而是把 AI 的代码作为草稿由有经验的工程师重写关键逻辑。7.3 速成课最值得复用的判断标准Matt Pocock 的课程里最有价值的部分不是具体的提示词而是判断标准一段 AI 生成的代码是否可以直接使用取决于三件事。第一你是否理解这段代码的每一行。如果理解不了就不要合入先让人解释清楚或重新写。第二这段代码是否在你的项目里经过了完整验证而不只是在某个示例项目里跑通过。第三这段代码是否遵循了项目现有约定包括目录结构、命名规范、错误处理和依赖管理。这个判断标准同样适用于人工编写的代码。AI 编程只是让“不经思考就提交代码”这件事变得更容易发生所以更需要用标准来约束。8. 落地实践清单把 AI 编程工作流变成团队习惯8.1 单人开发的前 30 分钟实验如果你是第一次实践这套工作流可以从下面这个 30 分钟实验开始找一个本地小项目或者新建一个最小 TypeScript CLI 项目。在 Git 上新建分支确保主分支可用。挑一个你完全理解的功能比如文件重命名、JSON 格式化、时间戳转换。先写任务卡片拆出核心函数和测试。用第 4 节的提示词模板让 AI 实现核心函数。运行npm run build、npm test、npm run lint。检查git diff --name-only确认改动范围。做一次人工代码审查按第 5.3 节的清单逐项检查。提交代码并记录这次实验中 AI 哪类输出最需要修正。这个实验的重点不是做一个完整项目而是体会“拆解、约束、验证、回滚”四个动作在真实项目里如何衔接。8.2 团队协作时的 AI 代码审查规则团队引入 AI 编程后代码审查规则要调整。最核心的一条是AI 生成的代码没有特权它和人工提交的代码适用同一套审查标准。团队可以约定以下规则所有 AI 生成的代码必须带有任务卡片或需求描述否则检查者无法判断实现是否偏离目标。AI 不得直接修改主干分支必须提交 Pull Request/Merge Request。依赖变更必须单独说明禁止在实现里夹带未经过讨论的新依赖。涉及敏感逻辑的代码建议在合并请求描述里标注“AI 生成”。测试失败时AI 不能通过反复修修补补绕过测试应先分析根因再修改实现。这些规则并不复杂但能显著降低 AI 编码带来的不可控风险。8.3 从速成课到长期能力下一步学什么AI 编程工作流不是学会一个工具就结束了。要把它变成长期能力建议按以下路径继续深入深入掌握你的主力语言和框架的类型系统这能帮你判断 AI 输出中的类型是否合理。学习测试设计尤其是边界条件和异常分支的测试设计这是验证 AI 输出正确性的基础。学习代码审查方法训练自己从命名、依赖、错误处理、性能、安全多个维度审查代码。学习项目架构理解模块边界和依赖方向。只有理解了架构才能真正判断 AI 的改动是否破坏了项目结构。把这些能力补起来之后AI 编程工具在你手里就不是一个自动生成代码的玩具而是一个可以放进正式工程流程的加速器。整个工作流的核心始终是人的判断该让 AI 做什么、不该让它做什么、它的输出能不能被信任。把这几个问题想清楚AI 编程就不会再让你陷入“跑得越快改得越久”的循环。 
长河君 · 2026/9/2 23:43:43 · 阅读 1.2k AI编程工作流：从需求拆解到代码验证的工程实践
在实际开发中使用 AI 编程工具最典型的问题是拿到需求后直接让 AI 生成一整套代码再把报错信息原样丢回去让它自行修复。这样循环几轮后代码能跑了但没人能解释清楚它到底做了什么也没人敢保证下一次改动不会破坏现有功能。Matt Pocock 的 AI 编程速成课讨论的核心正是这一点问题不在于 AI 能不能写代码而在于你是否用一套工程流程去约束它。AI 编程的真正价值不在于“快速产出代码”而在于把程序员从重复样板代码和琐碎细节里解放出来。要做到这一点需要的不是更强的模型而是更严格的开发工作流。这套工作流包含需求拆解、上下文准备、提示词设计、代码审查、自动化验证和回滚机制。本文按这套流程展开先解释为什么不能“瞎用 AI 写代码”再给出一套可以直接落地的工程师级 AI 编程工作流。这套流程适合以下读者已经在用 Cursor、GitHub Copilot、Claude、ChatGPT 等工具写代码但经常改完一处坏掉另一处的人想从“让 AI 写小程序”过渡到“让 AI 参与正式项目开发”的人以及正在把 AI 编码能力引入团队但没有统一规范的工程负责人。1. 为什么“遇到问题就丢给 AI”反而会拖慢开发效率很多开发者的 AI 编程起步方式完全一样打开编辑器输入一段自然语言描述复制生成的代码到项目里运行报错再把报错日志贴回去让 AI 继续改。这种用法在最简单的脚本里有效但一旦进入真实项目就会频繁陷入“修改一个函数引发另一个文件报错”的循环。1.1 典型低效用法把 AI 当自动补全把提示词当搜索框低效用法有几个明显特征。第一提示词里没有约束条件只说“帮我写一个上传文件功能”既不说明框架版本也不说明文件大小限制、存储路径、是否需要断点续传。第二生成代码后不检查依赖直接复制到项目里遇到缺少包就跑npm install或pip install补齐。第三报错后不分析根因直接把终端日志完整粘贴给 AI让它猜测哪里出了问题。这种工作方式会带来两个后果。一是上下文丢失AI 只看到你贴出来的错误看不到完整项目结构于是只能给出一份“看起来很合理”的修复建议而这个建议很可能与项目的现有设计冲突。二是验证缺失AI 生成代码之后没有测试、类型检查、静态分析这些防线错误只能靠运行时发现越到后期修复成本越高。这里的关键认知是AI 编程工具再强大它也不了解你的项目。它不了解你的目录结构、命名规范、依赖锁定策略、错误处理约定。如果你不把这些信息主动提供给 AI它就只能基于通用知识输出代码而通用知识往往和你的项目冲突。1.2 从“让 AI 写代码”到“用 AI 完成一个工程步骤”的转变正确的使用方式不是“让 AI 写代码”而是“用 AI 完成一个明确定义的工程步骤”。这两者的区别在于任务边界。“让 AI 写代码”的任务边界非常模糊AI 需要自己做大量假设而假设最容易出错。比如“写一个登录功能”AI 需要猜测你用的是 Session 还是 JWT、密码要不要加密、登录失败要不要限制次数、数据库表结构是什么样的。这些假设里只要有一个错误生成的代码就无法在当前项目里运行。“用 AI 完成一个工程步骤”则不同你先把任务拆小再给 AI 提供足够上下文让它只负责其中一个环节。例如“在src/services/auth.ts中实现一个verifyPassword函数输入是明文密码和数据库中读取的哈希值使用bcryptjs的compare方法返回Promiseboolean如果参数为空则返回false并写日志”。这样 AI 不需要猜测整体架构它只需要实现一个函数而且函数的输入、输出、依赖、异常行为都被约束住了。把任务拆小的好处不仅是让 AI 更准确也让代码审查变得容易。一段 20 行的函数人可以逐行检查一段 500 行的全新模块几乎没有人会认真读完问题就这样混进了版本库。1.3 工程师级 AI 编程工作流的核心拆解、约束、验证、回滚工程师级的 AI 编程工作流可以简化为四个动作拆解、约束、验证、回滚。拆解是把一个完整需求拆成多个可独立验证的小任务。约束是在提示词中明确依赖、输入、输出、边界条件和代码风格。验证是对 AI 生成的代码运行类型检查、单元测试、lint 和必要的人工审查。回滚是指当验证失败且无法快速修复时放弃 AI 的修改回到上一个已知正常的版本而不是继续在错误代码上打补丁。这四个动作里验证和回滚是最容易被初学者忽略的。很多人觉得 AI 生成的代码已经能跑就说明没有问题。实际上“能跑”和“正确”之间还有很大距离代码是否处理了空值是否在并发环境下安全是否遵循项目现有风格是否引入新的依赖是否覆盖了异常分支这些都需要验证机制来回答。2. 环境准备先建立 AI 编码所需的上下文和验证工具链AI 编程不是打开一个聊天窗口就能做好的它需要一套环境和工具链来支撑。这套环境的价值在于让 AI 输出的代码能够立即被验证让错误能够被快速定位让修改可以被随时回滚。2.1 学习环境的最小搭配在本地学习时最少需要以下内容一个代码编辑器推荐 VSCode 或 Cursor安装对应 AI 插件。一个版本控制工具Git 是必须的每次 AI 修改前先提交或建分支。一个项目脚手架让项目结构规范可预期避免每次从零开始。一组验证命令至少包含构建、测试、lint 三类。以 TypeScript 项目为例最小搭配如下node -v npm -v git --version一个最小的 TypeScript CLI 项目结构可以是ai-workflow-demo/ ├── package.json ├── tsconfig.json ├── src/ │ ├── index.ts │ └── rename.ts └── tests/ └── rename.test.tspackage.json里至少需要以下内容{ name: ai-workflow-demo, version: 1.0.0, type: module, scripts: { build: tsc, test: node --test --experimental-strip-types tests/, lint: eslint src/ }, devDependencies: { typescript: ^5.5.0, types/node: ^20.0.0, eslint: ^9.0.0 } }学习环境下不需要把配置做得非常复杂关键是验证命令要短、要快、要可重复。任何 AI 生成的代码提交前都要能跑通这三条命令。注意学习环境的目标是快速验证工作流本身不要在一开始就引入复杂构建工具、微服务拆分、多环境部署。先在一个单仓库里跑通完整流程再迁移到更大项目。2.2 生产环境需要额外补充的能力生产环境不能照搬学习环境的做法。AI 生成代码进入生产项目前还需要额外补齐几类能力。第一依赖锁定。学习环境里可以随意npm install最新版本生产环境必须使用package-lock.json、pnpm-lock.yaml或等价的锁文件确保所有开发者的依赖版本一致。第二CI 集成。本地验证通过还不够提交代码后需要由 CI 在干净环境里重新执行安装、构建、测试和 lint避免“本地能跑别人拉下来跑不了”的问题。第三代码审查。AI 生成的代码必须经过有经验的人审查不能直接合并到主干。第四回滚机制。项目的部署方式必须支持快速回滚到上一个版本当 AI 修改引发线上问题时能立即恢复。这些能力并不完全是 AI 编程引入的它们是生产项目本来就应该有的工程基础。AI 编码只是把这些要求提到了更重要的位置因为 AI 修改代码的速度远高于人工代码评审的速度如果评审和验证跟不上风险就会成倍放大。2.3 示例项目结构一个可被 AI 修改的最小 TypeScript CLI下面用一个模拟场景作为全文示例实现一个批量重命名文件的 CLI 工具。这个场景足够小便于演示工作流又足够真实能展示函数拆分、错误处理和测试。src/rename.ts里先放一个核心函数AI 后续的所有改动都围绕这个函数展开import { readdir, rename as fsRename } from node:fs/promises; import path from node:path; export interface RenameRule { from: string; to: string; } export async function renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] { const files await readdir(dir); const results: { source: string; target: string }[] []; for (const file of files) { let newName file; for (const rule of rules) { newName newName.split(rule.from).join(rule.to); } if (newName ! file) { const sourcePath path.join(dir, file); const targetPath path.join(dir, newName); await fsRename(sourcePath, targetPath); results.push({ source: file, target: newName }); } } return results; }这个函数会读取目标目录下的所有文件按规则替换文件名并返回重命名记录。它在设计上有一个重要约束先把所有替换规则都应用到文件名上再执行重命名这样避免规则之间相互干扰。让 AI 修改时必须保证它理解这个约束。src/index.ts是 CLI 入口import { renameFiles } from ./rename.js; const dir process.argv[2]; if (!dir) { console.error(Usage: npm run cli -- directory); process.exit(1); } const rules [ { from: draft_, to: }, { from: final_, to: release_ }, ]; try { const results await renameFiles(dir, rules); for (const r of results) { console.log(${r.source} - ${r.target}); } } catch (err) { console.error(Rename failed:, err); process.exit(1); }这个最小项目就是后面所有提示词、验证、排错的载体。实际项目里文件名、目录结构、规则内容都会不同但工作流是同一个。3. 从需求到任务拆解把一句话需求变成可执行的开发步骤AI 编程最容易翻车的环节不在写提示词而在需求拆解。需求拆得越粗AI 的假设越多后续验证与修复的成本越高。3.1 需求拆解清单功能、输入、输出、异常、边界一个工程需求被交给 AI 之前至少需要回答五类问题问题类型需要明确的信息示例功能要做什么做到什么程度批量重命名文件支持多组替换规则输入输入从哪里来格式是什么目标目录路径规则列表输出返回值或副作用是什么返回重命名记录控制台输出日志异常哪些情况属于错误怎么处理目录不存在、文件不存在、权限不足边界空目录、重复文件名、超长路径怎么处理空目录返回空数组替换后同名文件覆盖前先确认可以用这个清单去检查 AI 生成的代码也可以反过来用同一个清单去写提示词。如果需求描述里缺少任何一项不要急着让 AI 写代码先补齐需求。3.2 一份可直接复制使用的任务卡片模板把需求拆解结果整理成任务卡片是让 AI 保持聚焦的有效方式。任务卡片的表达方式比随口一句“帮我写个功能”更有约束力。任务标题实现批量文件名替换功能 背景 项目是一个 TypeScript CLI 工具入口是 src/index.ts核心函数放在 src/rename.ts。 目录结构如下 src/index.ts src/rename.ts tests/rename.test.ts 任务描述 在 src/rename.ts 中实现 renameFiles 函数。 函数签名 renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] 输入 - dir需要重命名的目标目录 - rules替换规则列表每个规则包含 from 和 to 两个字符串 处理逻辑 - 读取 dir 目录下的所有文件名 - 对每个文件名依次应用所有替换规则 - 替换后的文件名与原文件名不同时执行重命名 - 返回所有重命名记录的数组 约束 - 使用 node:fs/promises 的 readdir 和 rename - 不修改文件内容 - 目录不存在时抛出错误由调用方处理 - 代码风格遵循项目现有 ESLint 规则 验收标准 - tests/rename.test.ts 中新增测试覆盖以下场景 1. 目录为空时返回空数组 2. 文件名包含规则中的字符串时被替换 3. 文件名不包含规则中的字符串时保持不变 4. 多组规则依次生效 - 运行 npm run build 和 npm test 全部通过任务卡片的核心是“把 AI 当作一个刚加入项目、不了解历史背景的新同事”。你提供的信息越多它的输出越贴近项目实际。3.3 拆解示例给“写一个文件名批量重命名工具”做拆分“写一个文件名批量重命名工具”是一个完整的项目需求直接交给 AI 会让它同时处理目录遍历、字符串替换、重命名、日志、错误处理、测试等多个问题。按任务卡片思路可以拆成四个原子任务任务一实现renameFiles核心函数接收目录和规则返回重命名记录。任务二实现 CLI 入口解析命令行参数调用renameFiles打印结果。任务三编写单元测试覆盖正常替换、空目录、无匹配、多规则等场景。任务四编写 README说明用法、参数和已知限制。每个任务都可以单独交给 AI也可以由人完成其中一部分。拆分后的任务各自都能被验证任务一需要测试通过任务二需要手动运行 CLI 观察输出任务三需要测试覆盖率任务四需要文档可读性。4. 编写提示词让 AI 在受限上下文里完成单个任务提示词不是越长越好但关键信息必须完整。一个工程级的提示词最少要覆盖角色、任务、输入输出、约束、验证方式这五个要素。4.1 提示词的五个基本要素要素说明示例角色告诉 AI 它在项目中承担什么角色“你是一名熟悉 TypeScript 和 Node.js 的工程师”任务说明要完成的具体工作“在 src/rename.ts 中实现 renameFiles 函数”输入输出明确输入参数、返回类型、副作用“返回 Promise{source,target}[]”约束指定依赖、风格、边界条件“使用 node:fs/promises不修改文件内容”验证告诉 AI 如何判断结果是否正确“npm run build 和 npm test 必须通过”这五个要素最容易被忽略的是“验证”。很多提示词不说明验收标准AI 自然无法自检只能凭感觉输出“看起来完整”的代码。加入验证方式后AI 会在生成代码时主动考虑测试用例是否通过。4.2 一段可复用的提示词模板下面是基于五要素设计的一段通用提示词模板适合用于修改或新增一个函数的情况。你是本项目的一名 TypeScript 工程师。项目是 Node.js CLI 工具使用 ESM 模块TypeScript 严格模式。 任务 在 src/rename.ts 中实现 renameFiles 函数。 上下文 - 项目目录结构 src/index.ts src/rename.ts tests/rename.test.ts - 已有代码使用 node:fs/promises路径拼接使用 node:path。 函数签名 renameFiles(dir: string, rules: RenameRule[]): Promise{ source: string; target: string }[] 要求 1. 使用 node:fs/promises 的 readdir 和 rename不要使用 child_process。 2. 对每个文件名依次应用所有规则。 3. 替换后的文件名与原文件名不同时执行重命名。 4. 目录不存在时抛出错误由调用方处理。 5. 不修改 tests/ 目录下的文件。 完成后会执行以下命令验证 npm run build npm test 在回答中先给出完整代码再用三到五行说明你的实现思路。这段提示词里项目背景、任务范围、技术约束和验证命令都是明确给出的。实际项目中可以把这段提示词保存为模板每次使用时替换项目背景、文件名和函数签名即可。4.3 提示词里常被忽略的约束依赖、目录、命名、兼容性除了功能描述工程约束往往才是决定代码能否合入的关键。依赖约束是最常见的坑。AI 经常会提议安装新依赖比如把字符串替换写成lodash的replace但项目中可能并不需要引入这个库。提示词里明确“禁止引入新依赖如果确有必要先说明理由”能显著减少这种问题。目录约束也很重要。AI 不清楚项目的模块边界可能把工具函数写到入口文件里也可能在src/services里实现一个本该放到src/utils的纯函数。在提示词里明确文件路径能够避免无预期的文件改动。命名约束影响代码审查成本。AI 生成的变量名、函数名可能风格不同比如项目里统一使用fetchUser、findUserByIdAI 却生成一个getUserData。这类不一致会在代码审查阶段占用大量时间。通常在提示词里给出一到两个命名示例AI 的命名会明显更贴近项目风格。兼容性约束与运行环境有关。Node.js 版本、浏览器支持范围、TypeScript 编译目标都会影响 AI 选用的语法和 API。提示词里写明Node.js 20、TypeScript strict mode、ESM这类信息可以减少代码生成后再做一遍适配的情况。5. 生成代码后的工程验证不能只问“能不能跑”AI 生成代码后第一个动作不应该是复制粘贴运行而是把代码放到验证流程里过一遍。验证流程可以分成四层每一层解决的问题都不同。5.1 验证分层静态检查、单测、手工验证、回归验证第一层是静态检查包括类型检查、lint、格式化检查。这类检查能在不运行代码的情况下发现大量低级错误比如类型不匹配、未使用的变量、违反代码风格的地方。npm run build npm run lint第二层是单元测试。单元测试验证的是函数级别的行为输入、输出、异常分支是否满足预期。对于 AI 生成的纯函数、工具函数单元测试是最可靠的验证方式。第三层是手工验证。手工验证的价值在于发现“测试没有覆盖到但实际使用会碰到”的问题。比如文件名包含空格、中文名、后缀大小写不一致这些在真实文件系统里很常见但在单元测试里容易被忽略。第四层是回归验证。AI 修改了一个函数后不能只看这个函数本身是否符合要求还要确认它没有破坏调用方的行为。回归验证依赖项目的现有测试体系和 CI没有 CI 的项目至少要在本地跑一遍全量测试。5.2 用最小测试验证 AI 生成的函数回到重命名工具示例。renameFiles函数接收目录和规则返回重命名记录。测试时要覆盖正常场景、空目录、无匹配、多规则四种情况。使用 Node.js 内置node:test的最小测试可以这样写import { test } from node:test; import assert from node:assert/strict; import { mkdtemp, mkdir, writeFile, readdir } from node:fs/promises; import os from node:os; import path from node:path; import { renameFiles } from ../src/rename.js; async function createTempDir(): Promisestring { return mkdtemp(path.join(os.tmpdir(), rename-test-)); } test(renameFiles replaces filename substrings, async () { const dir await createTempDir(); await writeFile(path.join(dir, draft_report.md), content); const results await renameFiles(dir, [{ from: draft_, to: }]); assert.equal(results.length, 1); assert.equal(results[0].source, draft_report.md); assert.equal(results[0].target, report.md); const files await readdir(dir); assert.deepEqual(files, [report.md]); }); test(renameFiles returns empty array for empty directory, async () { const dir await createTempDir(); const results await renameFiles(dir, [{ from: a, to: b }]); assert.deepEqual(results, []); }); test(renameFiles applies multiple rules in sequence, async () { const dir await createTempDir(); await writeFile(path.join(dir, draft_final_notes.txt), content); const results await renameFiles(dir, [ { from: draft_, to: }, { from: final_, to: release_ }, ]); assert.equal(results[0].source, draft_final_notes.txt); assert.equal(results[0].target, release_notes.txt); });这段测试使用了系统临时目录保证测试不会污染真实文件。测试断言既检查了返回值也检查了文件系统里的最终文件名这样能同时验证函数逻辑和实际效果。5.3 AI 产出代码进版本库前的人工审查要点自动化验证不能替代人工审查。AI 生成的代码通过测试不代表它一定适合合入版本库。人工审查时重点看以下几项命名是否与项目现有风格一致比如文件命名、变量命名、函数命名。错误处理是否符合项目约定比如是向上抛异常还是记录日志后继续。是否有不必要的新增依赖依赖是开发依赖还是生产依赖。是否存在于当前任务无关的代码改动。是否能处理极端输入比如空字符串、超长路径、特殊字符。如果 AI 在一次改动里同时修改了多个文件审查时更要警惕。理想情况下一次提交只解决一个问题AI 的改动范围应严格限制在任务卡片指定的文件内。6. 常见问题排查AI 生成代码跑不通时按这条链路查AI 生成代码报错时不要立刻把报错完整复制给 AI 请求重写。按下面的排查链路走一遍很多问题会更早暴露。排查顺序检查输入是否正确目录路径、参数名、环境变量是否真的传入了。检查文件路径和命名AI 生成的文件是否在预期位置文件名后缀是否匹配比如.tsvs.js。检查依赖版本新装的包和项目现有版本是否冲突。检查配置是否生效ESLint 规则、TypeScript 配置、打包配置是否被 AI 修改过。检查权限、端口、网络、环境变量本地测试和线上环境是否一致。检查日志中的异常根因不是看最后一行的 Error而是看完整堆栈。确认框架或工具自身的版本限制某些 API 在旧版本中不存在。6.1 现象一依赖缺失或版本冲突现象是运行时报Cannot find module或类型检查报找不到类型定义。可能原因通常是 AI 在代码里引用了新依赖但没有执行安装或者 AI 使用的是通用示例里的版本号跟项目实际版本不兼容。检查方式npm ls package-name如果没有安装先确认是否需要这个依赖。如果确实需要安装后检查版本范围。npm install some-package如果是版本冲突优先查看node_modules下该包的实际版本再对比项目里其他依赖的声明范围。6.2 现象二AI 改动了不该改的文件现象是 Git 工作区里出现大量无关文件改动或者代码审查时发现 AI 顺手调整了配置文件。原因通常是提示词里没有明确改动范围。AI 没有“只改某个文件”的意识它会在生成解决方案时顺手修改它能看到的文件。检查方式git diff --name-only这条命令能快速列出所有被修改的文件。如果列表里出现与任务无关的文件直接回退这部分改动不要把无关改动一起提交。git checkout -- unrelated-file6.3 现象三代码在本地能跑提交后 CI 挂掉现象是本地npm test全部通过推到远端后 CI 失败。常见原因有三个方向本地环境缺少锁文件导致 CI 安装的依赖版本不一致测试依赖了本地存在的文件或环境变量AI 生成的代码里包含平台相关的路径分隔符或命令。先检查锁文件是否被提交到版本库再检查 CI 日志中失败的测试是不是本地没有覆盖到的场景。如果测试使用了路径拼接优先使用path.join而不是手写反斜杠或正斜杠。6.4 现象四AI 出现幻觉写出了不存在的 API现象是代码里引用的某个函数、包、选项在官方文档里不存在但 AI 给出的代码看起来非常合理。AI 幻觉在处理冷门库、新版本、内部工具时更容易出现。它可能把两个类似 API 混在一起也可能从训练数据里生成了一个从未存在的函数名。遇到这类情况不要反复让 AI 修改同一段代码先到官方文档或对应包的类型声明里确认真实 API。比如在node_modules里搜索函数名或者查看库的 TypeScript 类型定义。grep -r someFunction node_modules/some-package/确认 API 不存在后放弃这段代码的修修补补改为用文档中的真实 API 重新编写并在提示词里附上文档链接。7. 学习环境与生产环境从“能跑”到“能上线”之间缺什么AI 编程工作流在不同环境的目标不同。学习环境的重点是快速验证流程是否正确生产环境则要考虑代码上线后的一切风险。7.1 学习环境快速试错重点验证流程学习环境里不需要追求一次写对。可以用最小项目反复练习提示词设计、任务拆解和验证流程目标是形成肌肉记忆任何任务先拆解再写提示词再验证最后合入。可以在本地准备一个专门的练习仓库每次 AI 改动前先建分支或打 tag保证随时能回到上一个可用状态。git checkout -b feature/ai-rename # AI 生成代码并验证通过后 git add . git commit -m feat: implement renameFiles with AI实践一段时间后你会形成自己常用的提示词模板、任务卡片模板、验证命令清单。这些模板比记住某个 AI 工具的具体用法更有长期价值。7.2 生产环境日志、监控、权限、回滚、审计一个都不能少生产环境里使用 AI 生成的代码前面提到的验证流程一样都不能少另外还要补充几项。日志与监控AI 生成的错误处理代码如果没有日志出问题后很难定位。在提示词里明确要求“所有 catch 分支必须包含 error 日志并携带关键上下文”。权限最小化AI 生成的代码可能请求过多权限比如一个只读文件的功能代码里却以写权限打开文件。生产环境要遵循最小权限原则。回滚方案每次 AI 生成的改动合入主干前都需要有对应的回滚方案。最简单的方式是使用 Git 版本回退和部署平台的上一版本切换功能确保线上出问题时可以在几分钟内恢复。审计与评审AI 生成代码的合并请求必须经过人工评审。对于涉及支付、权限、数据删除等敏感逻辑的代码建议不直接使用 AI 的最终输出而是把 AI 的代码作为草稿由有经验的工程师重写关键逻辑。7.3 速成课最值得复用的判断标准Matt Pocock 的课程里最有价值的部分不是具体的提示词而是判断标准一段 AI 生成的代码是否可以直接使用取决于三件事。第一你是否理解这段代码的每一行。如果理解不了就不要合入先让人解释清楚或重新写。第二这段代码是否在你的项目里经过了完整验证而不只是在某个示例项目里跑通过。第三这段代码是否遵循了项目现有约定包括目录结构、命名规范、错误处理和依赖管理。这个判断标准同样适用于人工编写的代码。AI 编程只是让“不经思考就提交代码”这件事变得更容易发生所以更需要用标准来约束。8. 落地实践清单把 AI 编程工作流变成团队习惯8.1 单人开发的前 30 分钟实验如果你是第一次实践这套工作流可以从下面这个 30 分钟实验开始找一个本地小项目或者新建一个最小 TypeScript CLI 项目。在 Git 上新建分支确保主分支可用。挑一个你完全理解的功能比如文件重命名、JSON 格式化、时间戳转换。先写任务卡片拆出核心函数和测试。用第 4 节的提示词模板让 AI 实现核心函数。运行npm run build、npm test、npm run lint。检查git diff --name-only确认改动范围。做一次人工代码审查按第 5.3 节的清单逐项检查。提交代码并记录这次实验中 AI 哪类输出最需要修正。这个实验的重点不是做一个完整项目而是体会“拆解、约束、验证、回滚”四个动作在真实项目里如何衔接。8.2 团队协作时的 AI 代码审查规则团队引入 AI 编程后代码审查规则要调整。最核心的一条是AI 生成的代码没有特权它和人工提交的代码适用同一套审查标准。团队可以约定以下规则所有 AI 生成的代码必须带有任务卡片或需求描述否则检查者无法判断实现是否偏离目标。AI 不得直接修改主干分支必须提交 Pull Request/Merge Request。依赖变更必须单独说明禁止在实现里夹带未经过讨论的新依赖。涉及敏感逻辑的代码建议在合并请求描述里标注“AI 生成”。测试失败时AI 不能通过反复修修补补绕过测试应先分析根因再修改实现。这些规则并不复杂但能显著降低 AI 编码带来的不可控风险。8.3 从速成课到长期能力下一步学什么AI 编程工作流不是学会一个工具就结束了。要把它变成长期能力建议按以下路径继续深入深入掌握你的主力语言和框架的类型系统这能帮你判断 AI 输出中的类型是否合理。学习测试设计尤其是边界条件和异常分支的测试设计这是验证 AI 输出正确性的基础。学习代码审查方法训练自己从命名、依赖、错误处理、性能、安全多个维度审查代码。学习项目架构理解模块边界和依赖方向。只有理解了架构才能真正判断 AI 的改动是否破坏了项目结构。把这些能力补起来之后AI 编程工具在你手里就不是一个自动生成代码的玩具而是一个可以放进正式工程流程的加速器。整个工作流的核心始终是人的判断该让 AI 做什么、不该让它做什么、它的输出能不能被信任。把这几个问题想清楚AI 编程就不会再让你陷入“跑得越快改得越久”的循环。