1. 从“能跑就行”到“敢上生产”AI编程的第二道坎上一篇聊了AI编程入门阶段那些事主要说的是怎么让AI帮你写点小脚本、补全函数、解释报错。那会儿的诉求很简单——能跑就行。但真正把AI编程往日常工作流里塞尤其是往生产环境靠的时候你会发现事情远没有那么简单。这一篇就是来填这个坑的。过去大半年我几乎把市面上主流的AI编程工具轮了一遍Cursor、Windsurf、VS Code Copilot、Trae还有各种基于API自己搭的方案。踩过的坑包括但不限于AI生成的代码在本地跑得好好的一上CI就挂让AI改一个bug它顺手把三个不相关的模块重构了用Agent模式自动执行任务结果它把测试数据库给清了。这些经历让我意识到AI编程的“下半场”不是比谁生成的代码多而是比谁生成的代码可控、可验证、可维护。这篇文章适合两类人一类是已经用过AI编程工具、但还没敢把它用在正式项目里的开发者另一类是在团队里推动AI编程落地、需要一套可复制方法论的技术负责人。我会从工作流设计、工具选型、提示词工程、Agent安全边界、代码审查这几个维度把“AI编程下半场”的实操经验拆开讲。不聊虚的全是能直接抄作业的东西。2. 工作流重构AI编程不是“加个插件”那么简单2.1 为什么“补全式AI”和“Agent式AI”是两套逻辑很多人把AI编程等同于“代码补全”这其实只覆盖了最浅的一层。补全式AI比如Copilot的inline suggestion本质上是概率性文本生成它根据上下文猜你下一行要写什么。这种模式的好处是快、无感坏处是它没有全局视野不知道你的项目架构、不知道你的业务约束。Agent式AI比如Cursor的Composer、Windsurf的Cascade则是另一套逻辑它接受一个高层任务描述然后自主规划步骤、读写文件、执行命令、甚至跑测试。这玩意儿的能力上限高得多但风险也大得多。我试过让Agent“给用户模块加一个软删除功能”它确实加了但顺带把数据库迁移脚本写成了直接删列——这要是上了生产数据就没了。所以工作流设计的第一原则是补全式AI用于“写”Agent式AI用于“改”和“查”但“改”必须有边界。具体来说补全式AI适合写新函数、写测试、写文档Agent式AI适合重构、修bug、迁移代码但每次任务范围要尽可能小且必须有人工审查环节。2.2 我的日常AI编程工作流拆解我现在的工作流大概长这样需求拆解阶段用ChatGPT或Claude把需求拆成可独立验证的小任务每个任务不超过一个文件的改动量。这一步不用AI编程工具用对话式AI就行。编码阶段在Cursor里用补全式AI写新代码同时用Agent模式处理跨文件的修改。关键技巧是Agent任务描述里必须包含“只修改X文件”“不要动Y模块”“修改后运行Z测试”这类约束。验证阶段AI生成的代码必须过三道关——本地跑通、单元测试覆盖、静态检查通过。我习惯让AI自己写测试但测试代码必须人工审查因为AI写的测试经常是“为了通过而通过”。审查阶段用另一个AI比如另一个模型来审查第一个AI生成的代码。这招叫“AI互审”后面会细说。这套流程跑下来AI编程的效率提升大概在30%到50%之间取决于任务类型。纯CRUD接口能到50%以上涉及复杂业务逻辑的可能只有20%。但关键是返工率大幅下降。以前让AI直接改代码十个里有三个要回滚现在加了约束和验证回滚率降到不到一个。2.3 工具选型Cursor、Windsurf、Copilot、Trae到底怎么选这四个工具我深度用过至少两个月说几个真实感受工具核心优势主要短板适合场景CursorAgent能力强Composer模式成熟大项目索引慢偶尔卡顿中小项目全流程开发WindsurfCascade流程流畅UI响应快生态插件少部分语言支持弱前端和全栈项目VS Code Copilot与VS Code无缝集成补全质量高Agent能力相对弱已有VS Code工作流的团队Trae免费额度大中文支持好复杂任务规划能力一般个人开发者、学习用途我的建议是主力工具选一个辅助工具选一个。比如我用Cursor做主力因为它Agent模式最成熟用Copilot做辅助因为它的补全在写重复代码时特别顺手。Windsurf我用来做前端原型它的Cascade在改CSS和组件时体验很好。Trae我推荐给刚入门的朋友免费额度够用中文提示词理解也到位。注意不要同时开多个AI编程工具的Agent模式。我试过Cursor和Windsurf同时跑Agent结果两个工具互相改文件最后代码冲突到没法合并。一个项目同一时间只用一个Agent。3. 提示词工程让AI编程从“抽卡”变成“定向爆破”3.1 AI编程提示词和普通对话提示词的区别很多人把跟AI聊天的提示词直接拿来写代码结果发现效果很差。原因很简单代码生成对精确性的要求远高于文本生成。你跟AI说“写一个用户登录功能”它可能给你返回一个带JWT的完整实现也可能给你返回一个伪代码。差别在于提示词里有没有包含足够的约束。AI编程提示词的核心要素我总结为五个上下文、任务、约束、示例、验证。缺一个输出质量就下一个台阶。上下文告诉AI当前项目的技术栈、目录结构、相关文件。Cursor和Windsurf会自动索引项目但你还是要在提示词里点明“参考src/services/user.ts里的写法”。任务一句话说清楚要做什么。不要写“优化一下”要写“把getUserById的查询从N1改成JOIN”。约束这是最容易被忽略的。比如“不要引入新依赖”“保持现有函数签名不变”“只修改这一个文件”。示例给一个输入输出示例或者给一段现有代码作为风格参考。AI在模仿方面很强给例子比给描述有效得多。验证告诉AI怎么验证结果。比如“修改后运行npm test -- user.test.ts确保全部通过”。3.2 一个真实案例用提示词把接口生成准确率从60%提到95%我之前让AI生成REST接口一开始的提示词是“写一个用户注册接口”。结果AI给我返回了一个Express路由但我项目用的是Fastify它还自己加了bcrypt依赖但我项目里用的是argon2。返工了三次之后我把提示词改成了这样上下文项目使用Fastify TypeScript Prisma参考src/routes/auth.ts的现有写法。 任务在src/routes/user.ts中新增POST /user/register接口。 约束 - 使用现有的hashPassword工具函数src/utils/crypto.ts - 请求体校验用zod参考src/schemas/auth.ts - 不要引入新依赖 - 只修改src/routes/user.ts这一个文件 示例参考src/routes/auth.ts中/login接口的结构 验证写完后运行npm test -- user.test.ts改完之后AI一次生成就能直接用准确率从大概60%提到95%以上。核心差别就是约束和示例。AI不是不会写代码是不知道你的项目里已经有什么、不允许做什么。3.3 提示词模板我常用的三种场景我整理了三套模板分别对应新功能开发、bug修复、代码重构。直接抄就行新功能开发模板上下文[技术栈] [相关文件路径] [现有类似功能的实现位置] 任务在[文件路径]中实现[功能描述] 约束 - 使用[已有工具/库] - 不要引入新依赖 - 保持[函数签名/接口定义]不变 - 只修改[指定文件] 示例[参考代码片段或输入输出示例] 验证[运行什么测试/命令]Bug修复模板上下文[报错信息] [相关文件] [复现步骤] 任务修复[文件:行号]中的[问题描述] 约束 - 只修改[指定文件] - 不要重构无关代码 - 修复后保持现有测试通过 验证运行[测试命令]确认[具体断言]代码重构模板上下文[当前实现的问题] [目标架构描述] 任务将[文件/模块]从[当前模式]重构为[目标模式] 约束 - 保持所有公开接口不变 - 分步骤执行每步修改不超过[数量]个文件 - 每步完成后运行测试 验证运行[测试命令]确保全部通过实操心得提示词里的“不要”比“要”更重要。AI天生喜欢“帮忙”你不说“不要动X”它就会顺手把X也改了。我现在的提示词里约束部分的字数经常比任务部分还多。4. Agent安全边界别让AI把你数据库删了4.1 Agent模式的风险到底在哪Agent模式最危险的地方在于它有执行权限。补全式AI只生成文本你不接受它就不生效Agent式AI可以直接读写文件、执行终端命令、调用API。我踩过的最狠的一次坑是让Agent“清理项目中的无用文件”它把migrations目录里它认为“重复”的迁移脚本删了。幸好那是本地环境要是生产环境数据库迁移历史就断了。Agent的风险可以归为三类文件系统风险误删、误改、命令执行风险跑了危险命令、外部调用风险调了不该调的API。这三类风险对应三种防护策略范围限制、命令白名单、人工确认。4.2 我的Agent安全配置清单每次开Agent模式之前我会检查这几项工作目录限制确保Agent只能在项目根目录下操作不能访问上级目录或系统目录。Cursor和Windsurf都支持配置workspace范围一定要设。命令白名单只允许Agent执行npm test、npm run lint、git diff这类安全命令。禁止rm、drop、truncate、curl防止外发数据。Windsurf的Cascade支持命令审批每个命令执行前弹窗确认这个功能一定要开。文件修改审批Agent修改文件前必须展示diff人工确认后才写入。Cursor的Composer模式默认是自动应用的要在设置里改成“手动确认”。版本控制兜底Agent操作前先git commit操作后如果结果不对直接git reset --hard。这是最后一道防线也是最有效的。环境隔离Agent只在本地开发环境跑绝对不在生产环境或预发环境开Agent模式。数据库连接串用本地库不要连远程。4.3 一个真实的Agent翻车案例复盘上个月我用Windsurf的Cascade做一个数据库迁移任务任务是“把users表的name字段拆成first_name和last_name”。我给的提示词里写了“写迁移脚本”但没写“不要执行迁移”。结果Cascade不仅写了脚本还直接跑了npx prisma migrate dev。更坑的是它跑的迁移脚本里有一个DROP COLUMN name而我的种子数据里name字段有值直接丢了。复盘下来问题出在三个地方第一提示词没有明确“只写脚本不执行”第二Windsurf的命令审批我关了因为嫌弹窗烦第三我没有提前commit导致回滚只能靠数据库备份。后来我改了流程Agent任务描述里必须包含“只生成代码不要执行任何命令”除非我明确说“可以执行测试”。命令审批永远开着宁可多点几次确认。每次Agent任务前必须commit这已经成了肌肉记忆。注意不同工具的Agent权限模型不一样。Cursor的Agent默认可以执行命令Windsurf的Cascade默认需要审批Copilot的Agent能力最弱但最安全。选工具的时候要把权限模型考虑进去。5. AI互审用魔法打败魔法5.1 为什么AI写的代码需要另一个AI来审AI生成的代码有一个特点它自己觉得没问题。你让同一个AI审查自己写的代码它大概率会说“看起来没问题”。这不是它偷懒而是它的训练目标就是生成“合理”的代码它很难跳出自己的生成逻辑去挑刺。但换一个AI来审效果就完全不一样。我用Claude写代码用GPT-4审或者用Cursor生成用Copilot审。不同模型的训练数据、架构、偏好都不一样一个模型忽略的问题另一个模型往往能发现。我实测下来AI互审能多发现大概20%到30%的问题尤其是边界条件处理和错误处理。5.2 AI互审的实操流程我的AI互审流程分三步生成方AI用主力工具比如Cursor生成代码同时让它写一段“实现说明”解释它做了什么、为什么这么做、有哪些假设。审查方AI把代码和实现说明一起丢给另一个AI比如Claude或GPT-4提示词是“审查以下代码重点关注边界条件、错误处理、安全性、性能、与现有代码的一致性。列出所有问题按严重程度排序。”人工裁决审查方AI列出的问题我逐条判断是否成立。成立的让生成方AI修不成立的忽略。这一步不能省因为审查方AI也会误报。5.3 审查提示词模板和常见发现审查提示词我一般这么写审查以下代码重点关注 1. 边界条件空值、极值、并发情况是否处理 2. 错误处理异常是否捕获、错误信息是否清晰 3. 安全性是否有注入风险、权限校验是否完整 4. 性能是否有N1查询、不必要的循环 5. 一致性是否与项目现有代码风格一致 6. 可测试性是否难以写单元测试 对每个问题给出文件行号、问题描述、严重程度高/中/低、修复建议。实测下来审查方AI最常发现的问题是空值处理缺失比如user.address.city没判空、错误吞没catch了异常但没log也没抛、硬编码配置把超时时间写死在代码里。这些问题生成方AI经常忽略因为它们“看起来能跑”。实操心得AI互审的最佳组合是“强模型生成 强模型审查”但两个模型要不同。我用Claude 3.5 Sonnet生成用GPT-4o审查效果比同模型自审好很多。如果预算有限至少用同一个模型的不同会话来审也比不审强。6. 常见问题与排查技巧实录6.1 AI编程高频翻车场景速查表问题现象可能原因排查方法解决方案AI生成的代码本地能跑CI挂环境差异、依赖版本不一致对比本地和CI的Node/Python版本、依赖lock文件在提示词里指定版本或让AI读lock文件Agent改完代码后测试全红Agent改了无关文件或接口git diff查看所有改动回滚重新给更严格的约束AI写的测试永远通过测试断言太弱或mock了核心逻辑人工审查测试代码看断言是否覆盖边界要求AI写“会失败的测试”再修补全的代码风格和项目不一致AI没读到项目配置检查.eslintrc、.prettierrc是否被索引在提示词里指定参考文件Agent执行了危险命令命令审批关闭或白名单缺失查看Agent执行日志开启审批配置命令白名单AI重构后性能下降AI选了低效实现跑benchmark对比在提示词里指定性能约束6.2 三个我踩过的坑和解决方法坑一AI把环境变量写死在代码里。有一次让AI写一个API调用它直接把API key写在了代码里。后来我在提示词里加了一条“所有敏感配置必须从环境变量读取参考.env.example”这个问题就没再出现过。坑二AI生成的数据库查询有N1问题。AI写ORM查询时经常在循环里查关联表。我的解决方法是在提示词里明确“避免在循环中执行数据库查询使用JOIN或预加载”并且在审查阶段专门检查这一点。坑三Agent把测试数据库和生产数据库搞混。有一次Agent跑测试时连了生产库因为.env里没区分。后来我强制要求测试环境用独立的.env.testAgent任务描述里必须写“使用测试环境配置”。6.3 关于“免费AI编程工具”的实话热搜里经常有人问“免费的AI编程写代码哪个好用”。我的实话是免费额度适合学习和原型不适合正式项目。原因有三第一免费版通常限制Agent能力或命令执行次数第二免费版的模型版本往往落后生成质量差一截第三免费版的数据隐私政策通常不如付费版明确。如果预算有限我的建议是主力工具买一个付费版Cursor或Copilot辅助工具用免费版Trae或Codeium。一个月20美元的投入换来的效率提升远超这个数。但如果你只是学习Trae的免费额度完全够用中文支持也好。7. 从工具到习惯AI编程的长期主义7.1 建立自己的AI编程检查清单工具会变模型会升级但检查清单是能沉淀下来的。我现在的清单大概有十几项每次AI生成代码后过一遍[ ] 是否引入了新依赖是否必要[ ] 是否有硬编码的配置或密钥[ ] 边界条件是否处理空值、极值、并发[ ] 错误处理是否完整捕获、日志、抛出[ ] 是否有N1查询或不必要的循环[ ] 是否与现有代码风格一致[ ] 测试是否覆盖了核心逻辑和边界[ ] 是否修改了任务范围外的文件这份清单我放在项目根目录的AI_REVIEW.md里每次审查时对照着看。时间长了就变成条件反射AI生成的代码扫一眼就知道哪里可能有问题。7.2 团队协作中的AI编程规范如果你在团队里推动AI编程光自己用得好不够还得让团队用得好。我们团队的做法是统一工具主力工具统一用Cursor避免协作时格式和配置不一致。共享提示词库把常用的提示词模板放在团队Wiki里新人直接抄。AI代码审查所有AI生成的代码必须经过人工审查审查人不能是生成者。Agent权限管控Agent模式默认关闭需要时申请且必须在独立分支上操作。定期复盘每两周开一次AI编程复盘会分享翻车案例和好用的提示词。这套规范跑了一个季度团队整体开发效率提升大概25%但更重要的是代码质量没有下降。AI编程最大的风险不是效率不够高而是效率上去了、质量下来了。规范的作用就是守住质量底线。7.3 我对AI编程未来的判断说几个我个人的判断不一定对但都是基于实际使用得出的第一Agent模式会成为主流但权限模型会越来越严。现在的Agent太自由了未来一定会出现更细粒度的权限控制比如“只能改测试文件”“只能读不能写”。第二AI互审会变成标准流程。就像现在代码必须过CI一样未来AI生成的代码必须过另一个AI的审查。这不是信任问题是效率问题——人工审查AI代码太累了让AI先筛一遍能省很多时间。第三提示词工程会逐渐被工具内置。现在写提示词是个技术活未来工具会提供模板和引导让普通开发者也能写出高质量的提示词。但理解提示词原理仍然重要因为工具内置的模板不一定适合你的项目。最后分享一个我最近在用的技巧让AI在生成代码前先写“实现计划”。比如提示词里加一句“先列出实现步骤我确认后再写代码”。这招能提前发现AI的理解偏差避免它写了一堆代码才发现方向错了。实测下来返工率能再降一半。这个系列写到这儿差不多了。AI编程的下半场拼的不是谁用的工具多而是谁的工作流更稳、谁的检查清单更细、谁的翻车复盘更认真。工具会过时但这些习惯不会。
