Cursor 写了个挺漂亮的前端页面，Copilot 帮我补完了那个一直卡着的排序算法，组里也有人用 Trae 五分钟搭了个内部小工具——听起来很美，对吧？但真把这些代码往主干合的时候，问题全来了：格式乱得没法 review，边界条件一堆漏，测试根本没写，连依赖都装得稀里哗啦。我最近半年跑了三四个 AI 辅助开发的落地小组，最深的感受就是：AI 编程早就过了“能不能写出代码”的 demo 阶段，现在真正卡住团队的，是“能不能交出可用、可合、可维护的东西”。说白了，就是标题里这个“交付竞争”阶段。这篇就围绕 AI 编程、交付、团队产能这三个词，把我踩过的坑、验证过的方法、以及几个主流助手的打通经验，完整写一遍。
1. 交付竞争的本质：AI 编程从“写代码”转向“交代码”
1.1 会写代码的 AI 已经不值钱了
两年前我推 Copilot 的时候，大家的新鲜感还停留在“AI 居然能自动补全一条 SQL”。到现在，随便一个模型都能把 LeetCode 中等题写得像模像样，三个前端框架的语法张口就来。模型能力的提升当然是好事，但它直接带来一个幻觉——很多人以为让 AI 写出来的代码就等同于交付物，其实两者差了十万八千里。
我拿自己的团队做过一次统计：在允许使用 AI 助手的前提下，开发者的代码产出速度确实提升了大约 40% 到 60%，但代码评审不通过率、返工率、以及在联调阶段暴露出来的问题数量，几乎没怎么降。原因很简单：AI 生成代码擅长解决“局部正确”，比如一个函数、一个组件、一个查询；但交付是一个系统工程，它包含依赖管理、异常处理、兼容性测试、日志规范、性能验收，甚至还要考虑代码将来的维护者是不是能看懂。
所以我觉得“交付竞争”的说法非常准确。AI 让“写代码”这个动作变得廉价了，廉价到几乎免费；但“交付”反而变得更贵了，因为你要在更快的生成速度下，做同样严格——甚至更严格——的质量把关。谁能在高速度下仍然守住交付质量，谁的团队产能才是真实的，否则那不过是虚假的“手速提升”。
1.2 “个人效率”和“团队产能”之间有一条巨大鸿沟
个人效率是什么？是你今天用 Cursor 多写了两个组件，任务提前半天完成。团队产能是什么？是这些组件能被别人顺畅地接手、被测试覆盖、被 CI 正确构建、被部署到目标环境后依然正常工作。
我见过太多团队踩同一个坑：每个人都在自己的分支里用 AI 疯狂产出，分支一合并，集成测试直接红掉一片。大家第一反应是“AI 生成的代码质量不行”，但我后来复盘发现，问题根本不是代码质量，而是团队根本没有为 AI 交付制定统一的标准和接口契约。A 用 Copilot 生成的工具函数风格是 ES5，B 用 Windsurf 生成的是箭头函数风格；C 让 AI 自己选了依赖版本，D 让 AI 用了完全不同的日志方案。单拎出来每个分支都没问题，合在一起就是灾难。
一句话总结这个鸿沟：个人用 AI 看到的是“我写完了”，团队用 AI 需要的是“它交付了”。“写完”和“交付”之间隔着的，是代码规范、测试策略、评审机制、文档契约，以及一套可复用的 AI 辅助流程。本文后面所有内容，都是在为填平这条鸿沟服务的。
2. 规模化 AI 编程前，先解决这四个绊脚石
2.1 上下文失控是最大的隐形杀手
让 AI 写一个单点功能很容易，但让它写出的代码符合整个项目的架构约束、命名规范、异常处理习惯，就难得多。原因在于，主流 AI 编程工具默认的上下文窗口是有限的，你贴给它一个文件它能处理一个文件，但一个真实的业务模块往往横跨十几个文件，还有数据库表结构、接口文档、配置中心里的开关。
我做团队落地时，通常会强制要求两个动作：一是用 AGENTS.md 或 CLAUDE.md 这类项目级说明文件，把核心架构约定写死；二是开发任何 AI 辅助功能前，先用自然语言描述“输入-处理-输出”的完整链路，再让 AI 生成代码。为什么是两个动作而不是三个？因为少一个都不行——没有项目级说明，AI 每次都是“局部视角”；没有链路描述，AI 根本不知道这个功能在真实系统里处于什么位置。
另外补充一个很容易被忽略的细节：上下文不是越多越好。我见过有人把整个项目的代码都塞给 AI，结果它愉快地开始模仿一个早已废弃的老模块的写法。有效的上下文是“与本次任务强相关的那 20%”，而不是“整个仓库的 100%”，这一点在接入了大上下文窗口的团队里尤其要反复强调。
2.2 代码质量的评估体系需要前置到生成阶段
传统开发流程里，质量检查发生在代码写完之后——评审、测试、扫描。但 AI 编程的特点是生成速度极快，如果你还等在生成完之后做质量检查，返工成本依然很高。正确的做法是把质量要求“前置”到提示词中。
我整理了一套自己的提示词模板，核心原则叫“约束前置”。比如，我不会只说“帮我写一个 Redis 缓存工具类”，而是会说“帮我写一个 Redis 缓存工具类，要求：1. 使用 Spring Data Redis 规范；2. 所有方法必须处理连接失败异常；3. 返回值统一封装为 Result ；4. 不引入额外的第三方依赖；5. 每个方法给出 5 行以内的注释”。这样 AI 生成的代码基本一次就能过评审，而不是给你出一个还要大改的初稿。
这个习惯需要刻意练习。很多人用 AI 编程觉得“不靠谱、还要大改”，八成是因为给的提示词就没什么质量约束。**AI 默认的“正确”和你们团队约定俗成的“正确”，本来就是两码事。**你不在开始前定义好，就只能事后花时间改。
2.3 技术债在 AI 编程时代被加速放大了
手写代码时，技术债的产生速度约等于你的打字速度；用 AI 编程后，技术债的产生速度约等于你的提示词提交速度。这意味着一个偷懒的决定，可能在一天之内就复制到十几个文件里。
我举个例子。有一次组里需要做一个文件上传功能，某同事用 AI 快速实现了一个版本，当时的 AI 用了 MultipartFile 的本地存储方案，并没有考虑后续的 OSS 迁移。功能上线当天没问题，但一个月后要做存储迁移时，才发现那个“快速实现”已经渗透到了三个微服务里，全部要重写。技术债就是这样被加速放大的。
所以，AI 编程团队里必须有一个“技术债守卫者”的角色。他不是不让你用 AI，而是每次 AI 生成关键逻辑时，先问一句：这个方案在未来的架构演进中还能站稳吗？如果 AI 给出的方案只解决眼前问题，就立刻干预，而不是等它扩散。很多团队没有这个角色，AI 编程越快，欠债越多，这个因果我观察过太多次了。
2.4 安全和合规检查不能省，AI 生成代码更需要
AI 是概率模型，它可能“学到”不安全的加密算法、不规范的 SQL 拼接、或者把内部服务的 IP 写死在配置里。我见过一个非常典型的案例：有成员让 AI 写一个“生成 JWT 的工具类”，AI 给出的方案直接用了 HS256 加上一个硬编码密钥，在代码评审时差点被漏掉。这类问题人工评审确实难以察觉，所以在 AI 编程流程里，我强烈建议把静态安全扫描（SAST）和依赖漏洞扫描接入到 CI 流程的最前面。
顺便提一句，AI 也会“一本正经地胡编依赖”。你以为它引入了一个稳定版本的工具库，实际那个版本号根本不存在，或者存在但已停止维护。解决方式就是让 AI 在生成代码时，必须标注依赖来源和版本选择理由，否则要求重写。这个过程看似繁琐，但能挡住绝大多数供应链风险。
3. 可交付内容的定义：从“代码能跑”到“整包交付”
3.1 一个完整交付包应该包含什么
我见过很多团队把“让 AI 把代码写出来”当成“让 AI 把活干完”，这是对“可交付内容”最大的误解。以我对交付竞争阶段的理解，一份合格的 AI 辅助交付物必须具备六个要素：
- 可运行的代码，且能在标准环境下一键启动，而不是只贴了一个核心函数；
- 必要的测试覆盖，至少覆盖主流程和关键异常分支；
- 迁移/部署脚本，涉及数据库变更的要留好 SQL 脚本或迁移文件；
- 环境配置说明，包括依赖版本、配置项、外部服务依赖；
- 模块级文档，说明这个模块的边界、输入输出、已知限制；
- 变更记录，也就是标准的 CHANGELOG 或类似的更新说明。
可能有人觉得这些太“重”了，让 AI 干活不就是为了省事吗？但我想说一个反直觉的结论：AI 编程时代，文档和测试的成本反而变低了。因为你可以让 AI 自己根据代码生成文档雏形、自动写基础的单测，你只需要做审查和补漏。省下来的时间不是用来跳过交付物，而是用来做更严格的验收。
我自己的实践中，会把上面的六要素做成一个“AI 辅助交付检查清单”，每次任务结束后逐项打钩。打钩不是形式主义，而是防止 AI 生成的“局部正确代码”掩盖了“整体未交付”的真相。每缺一项，这个任务就不算完成，不管代码写得有多天花乱坠。
3.2 Git 交付文件框架的最佳实践
很多团队的项目仓库结构混乱，这直接导致 AI 生成的代码经常放错位置。我后来强制团队采用一套标准化的“git 交付文件框架”，效果非常明显。
简单说就是把项目里与 AI 相关的交付物集中放置和管理：
- 根目录下放
docs/ai/目录，里面包含AGENTS.md、PROMPTS.md、ARCHITECTURE.md，分别定义 AI 行为规范、常用提示词模板、系统架构图； - 每个功能模块下，要求必须存在
README.md（说明模块职责）、tests/（测试目录）、migrations/（数据库变更目录）； - 所有 AI 生成的关键代码，必须在提交信息中标记
[ai-generated]，这样后续回溯时能一目了然地知道哪些代码是 AI 写的，哪些是人工修改的。
有一点要提醒：标记“AI 生成”不是为了区别对待，而是为了让评审者格外注意审查 AI 生成的逻辑。AI 写的代码出错的模式和人类不同，它会在边界条件和异常处理上表现得尤其不稳定，所以这类代码需要更细的 review。
我还设计了另外一个细节：给 AI 的“可交付定义”也要放在仓库里。也就是说，每次给 AI 下任务时，把定义完成的 5 个标准一起写进去，比如“必须通过单测”“必须处理空指针”“必须兼容 IE11（如果你们还要兼容的话）”。AI 只有在开始前就知道“完成”的标准，才可能生成一个真正“可交付”的代码。
3.3 让 AI 自己补齐文档和测试并不丢人
我知道很多开发者对“让 AI 写测试”这件事有抵触，觉得那是自欺欺人。但我的观点是：AI 写测试的价值不在“测试的正确性”，而在“测试的覆盖意识”。你让 AI 给一个函数写单测，它大概率会覆盖主路径和一些常见的边界值——而那些边界值恰恰是人最容易漏掉的。
我实际用下来觉得，AI 生成测试的流程应该是这样的：先让人写好“测试计划”（也就是列出这个模块有哪些关键行为需要覆盖），然后让 AI 把具体的测试代码生成出来，最后人再补充几个 AI 想不到的异常场景（比如权限不足、数据为空、并发冲突）。这样做的好处是，测试框架和基础用例是 AI 干掉的，人可以集中精力做最有判断力的那部分工作。
文档同理。AI 生成的文档存在两个问题：一是容易啰嗦，二是容易“幻觉”——把代码里根本不存在的接口写进去。我的做法是，所有 AI 生成的文档必须经过“技术写作审查”，重点看有没有和代码不一致的描述。这个环节不需要花很长时间，但能避免一个巨大的坑：团队成员照着 AI 生成的错误文档调用接口，然后浪费一整晚排查一个不存在的问题。
4. 主流 AI 编程助手大比拼：选型是团队产能的杠杆
我一直觉得，AI 编程工具的选型问题不该是“谁最强”，而该是“谁最适合你们团队的交付流”。这里分享我实际用过一段时间的四款主流 AI 编程助手：Cursor、Windsurf、VS Code 的 Copilot，以及字节的 Trae。下面的结论都来自我自己的项目实践，不构成绝对的“谁好谁坏”诊断，建议大家根据团队现状做小范围试用再决定。
4.1 定位和生产力的关系
首先明确一下四者在我眼中的定位差异。Cursor 是“可配置的强智能体”——它对代码库的理解深度是最强的，适合需要跨文件重构、理解整个项目的场景，而且它的规则系统（.cursorrules）非常灵活。Windsurf 的强项是“工作流的连贯性”，它对一个任务的上下文维护做得比较好，在连续多轮修改中表现稳定。VS Code Copilot 对我来说更像“安静的结对程序员”，它不会抢你控制权，但在你写代码的时候精准地补全下一行、下一个函数，和 VS Code 生态的融合度最高。Trae 的优势是“低门槛和本土化”，对中文提示词理解得更好，内置了很多符合国内开发习惯的模板，很适合新手团队上手。
如果非要说谁有绝对优势，我觉得不如反过来想：你们团队卡在哪个环节？如果卡在“跨模块改动容易漏逻辑”，Cursor 这类全局理解能力强的工具更有用；如果卡在“AI 生成的东西总离预期差一点”，Windsurf 的多轮交互式工作流更合适；如果团队已经重度依赖 VS Code 生态和严格 lint 规范，Copilot 跟 IDE 的深度集成会让体验更顺滑；如果团队里不少人英语不顺畅、需要快速上手，Trae 的中文自然语言交互会更友好。
4.2 各工具在“可交付内容”上的实际表现对比
我拿一个“从零开始能用的 AI 编程”任务做了横向对比：让四个工具分别写一个带账户系统和 CRUD 接口的 Demo 应用，然后从可运行性、错误率、测试覆盖、文档完整性四个维度打分。
| 工具 | 可运行性 | 边界错误率 | 测试覆盖 | 文档完整度 |
|---|---|---|---|---|
| Cursor | 高 | 低 | 中 | 中 |
| Windsurf | 高 | 中 | 中 | 高 |
| VS Code Copilot | 中 | 中 | 低 | 低 |
| Trae | 高 | 中 | 中 | 中 |
这个表只能代表我自己的测试结果，但它反映了一个共同趋势：没有哪个工具能天然达到“开箱即交付”的水平。所有工具的“测试覆盖”和“文档完整度”都只在中低档次，需要人工补强。所以我的结论很清晰：工具选型解决的是“生成速度快不快、准不准”，但“交付完整不完整”永远要由团队自己定义流程来兜底，这个话题没有标准答案，适合自己的才是最好。
补充一句踩坑提示：不同工具的规则文件互不兼容。Cursor 用.cursorrules，Copilot 用.github/copilot-instructions.md，Windsurf 用.windsurf/rules.md。团队里多人混用不同工具时，会带来规则维护上的负担。所以我在团队里的建议是：主推一到两种工具，其余可以自用，但项目级 AI 规则必须统一维护，否则 AI 行为会迅速分裂。
4.3 有没有必要“免费 AI 编程”替代商业工具
热搜里有个词是“免费的 AI 编程写代码”，我理解这种需求——团队预算有限，让大家先用免费的跑一跑。但我想说一个非常现实的观察：AI 编程工具的钱，和它帮你省下的时间比起来，通常占比很小。而且商业工具的计费模式大多是按量包月，你完全可以一个团队只买 2~3 个高用量席位，其他人用免费版的补全功能，这种组合方式成本非常可控。
免费替代的真正成本不在钱，而在团队的注意力和流程一致性。免费版通常意味着更弱的上下文理解、更短的对话历史，这会导致 AI 给出的代码经常需要返工。所以我的建议是：预算不足可以从免费版开始，但别让免费成为默认，因为一旦团队习惯了“AI 生成的内容都要大改”的预期，大家就不愿意用了。第一印象很重要，宁可少买几个席位，也要保证团队成员第一次用 AI 编程工具时的体验是“它真的帮我省了事”，而不是“它给的代码和我自己写差不多还一堆错”。
5. 从提示词到工作流：把 AI 效率转化为团队产能
5.1 提示词工程的核心是“交付约束”
很多人觉得提示词工程就是“把需求描述得详细一点”，这句话说对了一半。在团队协作场景下，提示词工程的重点不是让 AI 更聪明，而是让 AI 的输出更符合团队的交付标准。
我自己的做法是给团队建了一个“提示词模板库”，按任务类型分类：从零创建新模块、修复一个 bug、补一个单测、重构一个函数、写数据库迁移、生成接口文档……每种模板里都内置了交付约束。以“修复 bug”为例，我要求至少包含：1. 描述问题现象和复现步骤；2. 让 AI 先给出根因分析（不急着给方案）；3. 要求同时修改相关测试；4. 禁止为修复引入新的依赖；5. 输出必须包含测试结果。这套模板用下来，bug 修复的一次通过率明显提升——因为 AI 不再只是“给出答案”，而是在“完成一个交付物”。
这里给一个容易踩的坑：提示词模板要放在团队共享空间，而不是个人笔记里。我见过有的团队把提示词写成个人收藏，结果不同人写的提示词天差地别，AI 交付的风格也随之混乱。让提示词模板成为团队资产，是 AI 编程落地过程中成本最低、收益最明显的一件事。
5.2 AI Agent 在编码之外的交付场景：PLC 与工控的启示
热搜词里还有个很有意思的方向：“AI Agent 与 PLC 编程”，以及“TIA Portal Openness MCP 完整交付包”。我虽然不是专业的工控开发者，但最近和几位做自动化集成的朋友聊过，发现 AI 编程正在向工业领域渗透，而且路径很有代表性：在 PLC 这类传统工业环境里，AI 的价值不是帮你从零写梯形图，而是帮你把“交付包”整体生成出来——包括程序块、HMI 变量表、设备文档、接线说明。
这给我们一个重要启示：真正的交付竞争是跨领域的，不只是互联网写代码。任何领域的 AI 编程，价值都不在于“生成代码片段”，而在于“生成一套可交付的专业内容包”。在 PLC 场景里，这套内容包必须符合 IEC 61131-3 标准、遵循项目命名规范、连注释风格都要和团队历史一致。能做到这一点的 AI 工作流，才是真正把效率转化成了交付能力。
所以，如果你所在的团队正在评估 AI 编程工具，建议你多问一句：“它能不能生成符合我们行业交付规范的完整包？”而不是“它能不能写几行代码给我看”。这个问题的答案，往往直接决定了 AI 编程的落地价值。
5.3 用 DORA 指标度量“真实产能”
前面讲到很多流程和工具上的细节，但团队管理者最关心的永远是：“这些投入到底带来了多少真实产能的提升？”我的回答是：别只盯“代码行数”和“任务完成数”，要看 DORA 指标的四类核心项：部署频率、变更前置时间、变更失败率、服务恢复时间。
AI 编程对 DORA 指标的影响非常有意思。部署频率通常会有明显提升——因为开发者产出速度变快了；变更前置时间也会缩短——因为很多重复性编码工作被 AI 消解了；但变更失败率才是真正考验流程的指标。如果 AI 编程没有配套的交付规范、测试策略、评审机制，变更失败率大概率会上升；反过来，如果把这些机制落实了，变更失败率可以持平甚至下降。服务恢复时间则考验团队的调试验证熟练度——AI 快速生成的代码，出问题时定位起来更费劲，所以一定要强调“生成阶段就把日志和监控指标打好”。
我建议团队按双周维度跟踪这四项指标，持续观察三个月。不要用“我感觉效率高了很多”来代替数据。AI 编程是实打实的生产力工具，它的效果就应当用实打实的数据来回答。“感觉”这个词在团队管理场景里毫无说服力。
6. 常见问题的排查指南与团队落地避坑手册
6.1 问题速查表（团队实战版）
| 现象 | 根因 | 解决方案 |
|---|---|---|
| AI 生成的代码格式和团队规范不一致 | 项目级 AI 规则缺失，或提示词未声明格式要求 | 根目录统一维护 AGENTS.md / .cursorrules / copilot-instructions.md，把格式规范、命名规则、注释风格全部写进去 |
| AI 频繁引用不存在的依赖或过时 API | 模型训练数据滞后于最新依赖版本 | 提示词中强制要求“只使用项目已有依赖，新增依赖需申明理由”，并开启依赖漏洞扫描 |
| 同一功能，AI 每次生成的结构差异很大 | 缺少上下文锁定，AI 在猜测架构意图 | 先让 AI 阅读关键文件（接口定义、数据模型、现有模块），再给出任务描述，并注明“遵循 src/utils/request.ts 中的既有写法” |
| 分支合并后测试大面积红掉 | 各分支 AI 生成的代码相互冲突 | 建立共用提示词模板和接口契约文件，要求所有 AI 生成的关键接口必须先核对契约文档 |
| AI 生成的代码通过评审却仍出问题 | 评审者被 AI 代码的“表面完整”欺骗 | 评审重点转向边界条件、异常路径、并发场景，并要求 AI 为每个函数标注“输入假设、输出保证、失败行为” |
| 团队开始依赖 AI 后，新人成长变慢 | 新人只看 AI 生成的代码，不理解设计意图 | 要求 AI 生成代码时附带“方案说明”，解释为什么这样实现；新人先 review 方案说明再 review 代码 |
这个速查表我建议直接打印出来贴在工位上，或者放到团队 wiki 的第一页。里面每一条都是真实踩过的坑，不需要再交一次学费。
6.2 团队落地 AI 编程的实操顺序
很多人问我：如果团队现在要从零开始引入 AI 编程，应该怎么排优先级？我给的答案通常是一个“三阶段路线图”：
第一阶段（1~2 周）先做工具统一和规范初始化：选定主推工具，制定项目级 AI 规则目录，建立提示词模板库，让大家自由试用并记录问题。这个阶段的目的是让大家敢用、会用。
第二阶段（1~2 个月）重点做流程嵌入：把 AI 辅助编码流程和代码评审流程深度结合，要求所有 AI 生成的关键逻辑必须经过特定规则审查，同时引入测试覆盖指标和静态扫描，把“AI 不可控”的部分用流程挡住。
第三阶段（持续）做团队产能度量：用 DORA 指标开始监控，建立 AI 辅助交付检查清单，定期复盘哪些类型的任务适合 AI 干、哪些不适合。到这一步，AI 编程才算真正转化为团队产能，而不是浮在表面的“工具试用”。
这里有一个非常重要的提醒：没有“完全不用 AI”的团队成员。我见过一些团队强行要求统一使用 AI 编程工具，结果老员工抵触情绪很大，新员工过度依赖 AI，两类人的沉默成本都被忽视了。更好的做法是让 AI 编程成为可选手段，但交付标准是强制的。“你可以不用 AI，但你的交付物必须满足同样规范”，这才是 AI 落地最和谐的姿态。
6.3 与 AI Agent 相关的新角色：交付工程师的价值
我还注意到一个热搜词叫“FCP-报表交付工程师”，单看这个名词有点陌生，但它其实勾勒了一个新趋势：AI 时代诞生了一种“交付工程师”角色，他不一定负责最核心的架构设计，但负责把 AI 生产出的内容包装成可交付的成果。报表场景尤其典型——AI 能快速生成报表代码，但对接数据权限、处理性能问题、确保报表口径正确，这需要专门的人来把关。
我身边确实已经有一些朋友的公司，开始设立类似“AI 交付工程师”的岗位了。他们做的事情包括：把 AI 生成的内容按交付规范做二次加工、补充测试和文档、处理 AI 输出与现网环境的差异、维护提示词模板。这个角色在未来可能会比“写代码最快的人”更抢手，因为他掌握了把 AI 产能转化为团队交付能力的桥梁技能。
如果你在团队里暂时没有这个角色，我建议可以让自己先承担一部分这样的职责。方法也很简单：在每次 AI 辅助任务结束后，花十分钟把 AI 生成的内容“翻译”成团队的交付标准。这十分钟的投入会显著提升整个团队的 AI 采纳率和交付质量。
7. 最后再分享几个实战总结和一个小技巧
前面写了这么多，其实都是围绕同一个主题：AI 编程进入交付竞争阶段之后，效率这个词的内涵已经从“写得快”变成了“交得稳”。我自己在带团队落地 AI 编程的这半年里，最大的体会是：真正拉开差距的，不是谁用了更贵的工具或更聪明的模型，而是谁愿意花时间把“交付标准”刻进 AI 工作流的每一个环节里。
这里再把最核心的几个动作重复一遍，因为它们是真正经过验证的产能杠杆：第一，给项目建立一套规则文件，让 AI 在写代码之前就“知道”你们的规范；第二，把提示词模板沉淀为团队资产，而不是个人的“魔法词”；第三，用 DORA 指标度量有效性，别靠感觉拍脑袋；第四，将安全和质量检查前置到生成阶段，而不是事后补救；第五，正视“交付工程师”这个新角色，为团队建立 AI 产出的二次加工流程。
最后一个实用的小技巧，是我近期做项目时发现的：让 AI 每次生成完代码后，附带一个“自检结果”——告诉你在它看来，这段代码目前有哪些边界条件未覆盖、哪些异常分支未处理、哪些依赖属于“临时方案”。这一招不要太好用。它相当于让 AI 自己给自己“留作业”，把压力从评审者身上转移到生成者身上。虽然一开始你需要多花几秒钟写这条提示词，但它能帮你减少大量的评审返工时间。如果你只准备采纳本篇的一个建议，我会建议你先试试这个。
AI 编程的下半场已经来了，能写代码的人会变得很多，能交代码的人会变得很贵。做团队里的那一个，别做随大流的那一群。
