AI 写代码在前三个月确实很爽需求一句话自动补全一大段样板代码几分钟就能拼出来连单元测试、提交信息、接口文档都能让模型代劳。但三个月后很多人开始觉得不对劲代码能跑却越来越不敢改AI 生成的东西像一个黑盒看起来都合理运行一段时间后才发现边界条件全是洞。这篇文章不劝退 AI 编程而是要把“爽”转化成一种可持续的工程能力。适合正在使用 Cursor、Copilot、Qwen Code、Codex 等工具的开发者也适合团队里负责技术规范、代码审查、质量保障的人。读完后你会得到一套从工具链、提示词、验证闭环到长期维护的完整工作流避免“爽三个月维护三年”。1. 先看清“AI 写代码三个月”到底发生了什么1.1 前期为什么爽AI 辅助编程刚刚切入日常开发时收益非常直观。大量重复性劳动被压缩常见的 CRUD 接口、DTO 定义、配置类、测试桩代码几乎可以一键生成。IDE 插件还会在输入过程中给出整行补全减少翻文档、查 API 的时间。这等于把“从零开始写”变成了“从半成品开始改”。短期体验好的原因有三个一是任务足够小AI 在单文件、单函数场景下表现稳定二是错误被编译器和测试拦住AI 输出的问题不会立即暴露三是新鲜感会让人更愿意尝试各种提示词投入度高产出自然多。这个阶段最常见的状态是一个需求下来先打开 AI 对话框描述需求复制代码运行通过然后提交。整个链路看起来高效但问题也在悄悄积累。1.2 三个月后的典型症状三个月是一个分水岭。项目的代码量变大模块之间的依赖变多AI 生成的代码不再只影响一个文件了。这时常见的症状会集中出现症状表现深层原因不敢改代码改了 A 模块B 模块的 AI 生成代码跟着坏没有理解生成代码的内部依赖也没有测试保护风格混乱不同文件命名风格、异常处理方式完全不同每次对话上下文独立AI 不知道全局约定版本错位按旧知识生成代码依赖 API 已废弃模型训练数据有滞后性项目依赖版本没有被约束边界错误正常路径能跑空值、超时、并发场景出错提示词没有描述边界条件AI 按“最常见情况”补全注释失真注释写得很完整但实现已经改过AI 生成的注释和代码可能来自不同上下文上下文丢失前面要求了“不要改鉴权”后半程还是改了对话太长后模型弱化或忽略了早期约束这些症状单独看都能解决但叠加在一起会形成很强的挫败感。尤其是接手他人 AI 生成代码的时候看不懂当时为什么这样写也没有设计文档可查。1.3 问题不是 AI 变笨了而是工作流没有升级AI 模型不会在三个月后突然变差。真正变化的是项目复杂度以及你对代码质量的要求。前期写 Demo、写脚本错误可以被容忍后期写业务系统、写核心模块错误需要被穷尽。此时如果还停留在“复制粘贴、运行通过、立刻提交”的阶段问题必然爆发。所以核心判断是AI 写代码的问题从来不是“写得不够多”而是“验证不够强、所有权不够清楚、架构约束不够明确”。后续所有方法都要围绕这三个方向展开。2. 先搭工具链AI 编程不是只有聊天框2.1 常见 AI 编程工具定位AI 编程工具远不止一个对话框。不同工具适合不同场景选型之前要先想清楚自己的需求。工具类型代表工具典型场景注意点IDE 插件GitHub Copilot、通义灵码、CodeGeeX代码补全、单文件生成、内联问答对上下文长度敏感需要配合项目规则文件独立编辑器Cursor多文件编辑、跨文件重构、项目级问答刚上手容易把整个仓库丢给 AI成本高且易走神终端工具Codex CLI、Aider命令行触发、git 集成、批量任务适合有清晰任务的开发者不适合探索式开发模型 APIQwen-Coder、DeepSeek-Coder 类模型私有化部署、需要控制敏感数据需要自己处理模型版本、推理资源和评测集框架生态Spring AI、LangChain 等把模型能力嵌入业务应用本质是应用开发不是写代码辅助工具选型建议如果你的代码有强合规要求优先选择支持私有化部署或离线使用的方案如果你主要写业务代码优先用 IDE 插件而不是临时网页对话框如果你需要让模型理解整个仓库先确认工具是否能读取项目索引而不是把文件内容全部粘贴进提示词。2.2 环境准备与依赖对齐AI 生成代码能不能跑很大程度上取决于环境是否一致。先执行一组基础检查避免“我本地能跑、你本地报错”的问题git --version node -v npm -v python --version docker --version java -version mvn -version不同项目只保留自己需要的命令。关键是确认Node、Python、Java 等运行时版本包管理器版本以及是否有统一的锁文件。常见的坑是 AI 提示使用“最新版依赖”但项目实际用的是另一个大版本。在提示词里写清楚Spring Boot 3.2、Python 3.11、Node 20比让 AI 自己猜可靠得多。如果项目使用 Docker 开发环境还要确保Dockerfile和docker-compose.yml与本地版本一致。不要先让 AI 写代码再回头调环境要先把环境固定再让 AI 在这个边界内生成内容。2.3 仓库和目录规范要提前定好AI 缺少全局视角尤其缺少对目录规范和模块边界的理解。没有规范时它会在utils目录里塞业务逻辑在没有分层的地方强行分层造成结构混乱。更合理的做法是在项目根目录放一份团队约定文件很多 AI 编程工具支持项目级规则文件例如AGENTS.md或工具对应的规则文件。一个最小目录结构示例project-root/ README.md AGENTS.md docs/ architecture.md src/ main/ test/ scripts/ lint.sh test.sh .gitignore package.json # 或 pom.xml、pyproject.tomlAGENTS.md可以写这些内容# 项目约定 - 后端统一使用 Java 17 Spring Boot 3.2 - 所有对外接口必须有入参校验和错误码 - 禁止在 Service 层直接操作 HttpServletRequest - 单元测试使用 JUnit 5测试文件放在 src/test/java 下 - 新增依赖需要先在 issue 中说明原因 - 生成代码必须包含关键方法的注释但注释要描述行为不要复述代码把这类约定写进文件AI 在生成代码时才有可能遵守。只靠对话里说一次超过上下文长度后就会被遗忘。3. 把需求转成 AI 能执行的任务3.1 为什么提示词不能是“帮我写个登录”“帮我写个登录”是典型的模糊指令。AI 会自行决定用 Session 还是 JWT要不要验证码密码怎么加密是否要刷新令牌用户表字段怎么设计。这些决定看起来都合理但未必符合你的项目约束。更麻烦的是AI 会把它的默认假设写进代码让未来维护者误以为是业务要求。更好的方式是把 AI 当成一个能力很强、但完全不了解项目的结对开发者。你需要告诉它角色、任务、已知条件、约束和验收标准。提示词越具体生成结果越接近可提交状态。3.2 一个可复用的提示词模板下面这个模板适用于大多数后端功能生成场景角色: 你是熟悉 Java Spring Boot 的资深后端工程师 任务: 实现一个基于 Redis 的接口防重复提交注解 已知条件: - 项目使用 Spring Boot 3.2 - Redis 客户端已经引入 spring-boot-starter-data-redis - 已有基础响应体 ResultT - 需要指定 key 前缀、过期时间、提示消息 约束: - 不修改已有鉴权逻辑 - 不引入额外依赖 - 使用 AOP 实现避免侵入业务代码 - 正确处理并发场景使用 Redis 原子操作 - 生成内容包含: 注解类、切面类、单元测试示例 输出格式: - 每个类单独一个代码块 - 开头用一行说明文件路径 - 关键方法注释说明输入、输出和异常场景把这段提示词发给模型通常能得到比“写个登录”质量高很多的结果。关键在“约束”部分它让模型不要越界也让你后续审查有依据。如果 AI 仍然生成多余代码可以在提示词末尾追加一句“如果没有必要不要生成额外类或方法”。3.3 任务拆分与验收标准AI 适合处理边界清晰的小任务不适合一次性生成整个系统。一个常见的拆分原则是一个提示词只解决一个模块或一个功能点。任务类型是否适合 AI 直接生成人工必须做的事项目脚手架、目录初始化可以作为参考手动确认依赖版本和文件结构单个 CRUD 接口可以生成初版审查权限、校验、事务边界复杂状态机不适合直接生成先画状态转移表再让 AI 生成单步逻辑单元测试适合生成基础用例补充边界值和异常场景重构已有代码不适合先让 AI 分析代码提出重构方案人工确认每个任务都要有验收标准。例如“实现防重复提交注解”的验收标准可以是同一 key 在指定时间内重复请求返回错误码不同 key 可以并发通过单元测试覆盖正常、重复、并发三种情况。把验收标准写进提示词AI 生成后再逐条验证。4. 生成之后的验证闭环不是复制粘贴就能提交4.1 三道快速检查编译、静态检查、测试AI 生成的代码放在编辑器里看起来没问题是常有的事但提交前至少要过三道检查。不同技术栈命令不同这里以 Java Maven 和 Node.js 为例# Java / Maven 项目 mvn -q compile mvn -q verify# Node.js 项目 npm run typecheck npm run lint npm test三道检查分别对应三个问题代码能不能编译代码是否符合团队风格和静态规则核心逻辑是否有测试保护。只要有一道失败就不要提交。如果你的项目里还没有测试至少补充一条最核心路径的冒烟测试。对于接口类代码启动服务后用curl验证真实行为curl -X POST http://localhost:8080/api/submit \ -H Content-Type: application/json \ -d {title:test}正常情况会看到业务成功响应重复请求时应看到防重复提交的错误响应。没有运行验证只靠编译通过无法发现 Redis Key 设置错误、过期时间失效、事务未生效这类问题。4.2 代码审查清单每次提交 AI 生成代码前按以下清单过一遍检查点具体做法API 是否与现有接口一致对比 Controller 路由、请求方法、参数名异常是否被吞掉搜索空的 catch 块和printStackTrace是否重复造轮子搜索项目里是否已有类似工具类或注解是否有硬编码密钥检查代码和配置文件中是否出现明文密码、token是否处理边界输入传入 null、空字符串、超大值、重复请求时是否报错是否引入不必要依赖对比 pom.xml、package.json 的变更是否符合项目风格命名、日志、错误码、事务注解是否与旧代码一致注释是否失真对照注释逐行读实现不一致就改注释或改代码配合git diff查看变更范围比直接看 AI 生成的完整文件更有效。提交前运行git diff --stat git diff src/main/java/your/module/YourClass.java4.3 提交信息与变更记录AI 能生成格式标准的提交信息但它不知道这次提交的真实意图。建议让 AI 生成草稿然后人工修改feat(auth): add idempotent submit annotation for order creation - Add Redis-based idempotent annotation - Add AOP aspect to prevent duplicate submission - Add unit tests for normal and duplicate requests提交时不要git add .而是按模块逐个添加git add src/main/java/com/example/common/annotation/Idempotent.java git add src/main/java/com/example/common/aspect/IdempotentAspect.java git add src/test/java/com/example/common/aspect/IdempotentAspectTest.java git commit -m feat(idempotent): add order submit duplicate protection小步提交的好处是将来定位问题只需看一个提交如果某个功能不要了可以精准回滚Code Review 时也容易盯住一个逻辑单元。5. 三个月后仍然有效的工程习惯5.1 代码所有权不能交给 AIAI 可以生成代码但无法为代码负责。项目里每一行代码都应该有一个明确的人类 owner。原因是未来一定会有人问为什么这里要判断expireTime 0为什么这个接口不走缓存如果答案是“AI 生成的”项目就会陷入无人能解释的困境。实际操作上让 AI 生成初稿后自己至少手动改一遍关键逻辑。手动修改的过程就是理解代码的过程。提交后使用git blame查看每一行归属如果某个文件的关键行全部来自 AI 工具说明该文件的技术债风险偏高。5.2 保持小型可回滚提交AI 一次性生成的代码经常横跨多个模块如果整体提交后续很难定位问题。手动把一个大功能拆成多个提交是一种必要成本。一个建议的拆分顺序先提交工具类和公共配置比如统一响应体、异常码。再提交核心逻辑比如切面、校验规则。最后提交测试用例和文档。每步都要保证可以编译、可以运行。不要等全部代码写完再一次性提交那样既难审查也难回滚。5.3 对生成代码做“定期重构”AI 生成代码在短期可以运行但不代表长期可维护。两个典型问题一是重复代码多因为每个任务都在独立上下文中生成不会复用之前的实现二是抽象层次混乱因为 AI 倾向于把辅助方法放在调用处附近。建议每完成一个功能顺手做一轮小重构提取重复逻辑、统一命名、删掉未使用代码。如果重构范围较大可以让 AI 先生成重构方案再由人工执行。例如让 AI 分析一个类是否存在多个职责分析 src/main/java/.../OrderService.java 目标: - 找出超过 50 行的方法 - 找出同时处理校验、持久化、发送消息的方法 - 给出拆分建议但不直接生成代码 约束: - 只输出分析结果不要修改文件 - 每个建议说明对可测试性的影响这种用法把 AI 从“生成器”变成了“辅助分析器”对长期维护更友好。5.4 控制上下文窗口和成本很多 AI 编程工具按 credits 或 token 计费。把整个仓库粘贴进对话不仅成本高效果也差。上下文越长模型在中间部分出错的可能性越大。正确做法是每次任务只提供最小相关文件。如果需要让 AI 理解整个项目结构优先使用支持代码索引、语义检索的工具如果必须粘贴文件先删掉无关注释和空行再把关键类提取出来。一个实用的操作习惯每个新功能都开一个新会话。不要把“修改订单接口”和“新增用户列表”放在同一段长对话里。任务结束后主动关闭会话避免上一个任务的上下文干扰下一个任务。6. 常见问题与排查路径6.1 编译报错找不到符号或缺少依赖现象AI 生成代码后运行mvn compile或npm run build报找不到类、包、方法。排查顺序检查是否真的引入了对应依赖查看pom.xml或package.json的 diff。检查依赖版本是否和项目其他模块冲突优先使用项目已有的版本。检查包名是否正确AI 经常把com.example写错。检查 JDK 或 Node 版本是否满足库要求。解决方式基于项目现有依赖重新生成或在提示词里明确“只能使用pom.xml中已有的依赖”。6.2 程序能编译但业务结果不对这是最隐蔽的一类问题。AI 生成的代码逻辑看起来完整但真实运行后数据不对、超时、重复提交没有被拦住。排查链路先确认输入请求参数是否真的传进来了。再加日志在关键判断前后打印参数、缓存状态、返回结果。再写单测用最小输入固定期望输出观察哪个分支偏离预期。最后人工修复不要继续让 AI 扩大修改范围先定位缺陷再给提示词。常见原因是 AI 假设了业务规则。例如防重复提交只判断了 Redis Key 是否存在但没有设置过期时间或者缓存判断和业务更新不在同一事务中。这类问题必须通过测试暴露。6.3 AI 上下文丢失忘记之前的要求现象同一个会话里前面要求“不要修改鉴权”后一个请求却把鉴权代码改了。原因是模型注意力机制天然聚焦最近内容长对话早期约束容易被忽略。解决方式不是反复提醒而是把约束外置把“禁止修改鉴权”写进项目规则文件。把相关测试写进代码改坏了测试立刻失败。把关键约束写进提示词的最前面和最后面中间放次要信息。如果工具支持“项目记忆”优先使用而不是依赖对话上下文。6.4 安全与合规风险AI 编程工具会把对话内容发送到模型服务端生产数据、客户信息、私钥绝对不能粘贴进去。即使是使用企业私有化部署也要遵循最小必要原则。建议建立团队红线风险类型禁止行为合规替代密钥泄露在对话里粘贴数据库密码、API Key使用环境变量或密钥管理服务生产数据泄露把真实用户手机号、订单数据发给模型用脱敏数据或合成数据代码泄露把未公开的商业代码整体发给外部服务使用私有化模型或允许的合规工具依赖投毒直接采用 AI 推荐的新依赖核查依赖来源、版本、许可证6.5 提示词调优输出不满足要求时怎么办不要继续在原提示词上反复说“不对”更有效的是给出反面约束。比如“不要生成 Controller 层只生成 Service 和测试代码”。或者“不要使用 Lombok”。一般来说正面描述“要什么”和反面描述“不要什么”同时出现效果最好。如果 AI 生成的代码风格仍然不一致可以把项目中一个质量较高的文件作为示例粘贴进去让 AI 模仿现有风格。这比抽象描述“请遵守项目风格”更有效。7. 可复用的 AI 编程工作流模板7.1 任务拆解模板每次使用 AI 写代码前按下面的顺序走写需求一句话说清楚要解决什么问题。拆任务把需求拆成 30 分钟内能验证的功能点。给输入补充项目版本、相关文件、现有 API 约定。下约束禁止做什么、必须做什么、验收标准是什么。生成代码只让 AI 完成当前子任务。验证编译、静态检查、单元测试、接口测试。提交小步提交写清楚提交信息。重构顺手消除重复代码补关键注释。这套流程可以打印出来贴在工位上也可以在项目 README 里写一份简化版。7.2 每次提交前检查清单检查项完成标准代码能否编译构建命令无错误是否通过静态检查lint 或 checkstyle 无新增问题是否有测试覆盖至少覆盖正常路径和关键异常路径是否阅读过生成代码能说出每个主要方法的职责是否排除安全风险无密钥、无生产数据、无未知依赖是否拆分提交单个提交只包含一个逻辑变更是否可回滚回滚该提交不会影响无关功能是否更新文档对外接口变化有说明规则文件有同步7.3 每周复盘建议团队或个人都可以做一次轻量复盘记录这些问题AI 生成代码的返工率是多少哪些任务需要反复修改。最常见的错误类型是什么是边界条件、依赖版本还是项目约定。哪些场景让 AI 写代码反而更慢以后要不要改成人工。有没有新增 AI 无法理解的业务规则是否已经写进规则文件。现有测试是否覆盖了 AI 容易出错的地方不足就补测试。复盘的目的不是追求“AI 写得越多越好”而是找到人机协作的最优边界。三个月后还能让你感到“爽”的不是模型变得更强而是你已经拥有了一套能让任何代码都保持可维护的流程验证闭环、代码所有权、小步提交、持续重构。建议今天就从一个小任务开始按上面的提示词模板生成代码再走一遍提交前检查清单。你会发现真正值钱的不是 AI 生成的代码而是你能让这些代码稳定运行、随时修改的能力。
AI编程工作流指南：从代码生成到可持续维护的完整闭环
AI 写代码在前三个月确实很爽需求一句话自动补全一大段样板代码几分钟就能拼出来连单元测试、提交信息、接口文档都能让模型代劳。但三个月后很多人开始觉得不对劲代码能跑却越来越不敢改AI 生成的东西像一个黑盒看起来都合理运行一段时间后才发现边界条件全是洞。这篇文章不劝退 AI 编程而是要把“爽”转化成一种可持续的工程能力。适合正在使用 Cursor、Copilot、Qwen Code、Codex 等工具的开发者也适合团队里负责技术规范、代码审查、质量保障的人。读完后你会得到一套从工具链、提示词、验证闭环到长期维护的完整工作流避免“爽三个月维护三年”。1. 先看清“AI 写代码三个月”到底发生了什么1.1 前期为什么爽AI 辅助编程刚刚切入日常开发时收益非常直观。大量重复性劳动被压缩常见的 CRUD 接口、DTO 定义、配置类、测试桩代码几乎可以一键生成。IDE 插件还会在输入过程中给出整行补全减少翻文档、查 API 的时间。这等于把“从零开始写”变成了“从半成品开始改”。短期体验好的原因有三个一是任务足够小AI 在单文件、单函数场景下表现稳定二是错误被编译器和测试拦住AI 输出的问题不会立即暴露三是新鲜感会让人更愿意尝试各种提示词投入度高产出自然多。这个阶段最常见的状态是一个需求下来先打开 AI 对话框描述需求复制代码运行通过然后提交。整个链路看起来高效但问题也在悄悄积累。1.2 三个月后的典型症状三个月是一个分水岭。项目的代码量变大模块之间的依赖变多AI 生成的代码不再只影响一个文件了。这时常见的症状会集中出现症状表现深层原因不敢改代码改了 A 模块B 模块的 AI 生成代码跟着坏没有理解生成代码的内部依赖也没有测试保护风格混乱不同文件命名风格、异常处理方式完全不同每次对话上下文独立AI 不知道全局约定版本错位按旧知识生成代码依赖 API 已废弃模型训练数据有滞后性项目依赖版本没有被约束边界错误正常路径能跑空值、超时、并发场景出错提示词没有描述边界条件AI 按“最常见情况”补全注释失真注释写得很完整但实现已经改过AI 生成的注释和代码可能来自不同上下文上下文丢失前面要求了“不要改鉴权”后半程还是改了对话太长后模型弱化或忽略了早期约束这些症状单独看都能解决但叠加在一起会形成很强的挫败感。尤其是接手他人 AI 生成代码的时候看不懂当时为什么这样写也没有设计文档可查。1.3 问题不是 AI 变笨了而是工作流没有升级AI 模型不会在三个月后突然变差。真正变化的是项目复杂度以及你对代码质量的要求。前期写 Demo、写脚本错误可以被容忍后期写业务系统、写核心模块错误需要被穷尽。此时如果还停留在“复制粘贴、运行通过、立刻提交”的阶段问题必然爆发。所以核心判断是AI 写代码的问题从来不是“写得不够多”而是“验证不够强、所有权不够清楚、架构约束不够明确”。后续所有方法都要围绕这三个方向展开。2. 先搭工具链AI 编程不是只有聊天框2.1 常见 AI 编程工具定位AI 编程工具远不止一个对话框。不同工具适合不同场景选型之前要先想清楚自己的需求。工具类型代表工具典型场景注意点IDE 插件GitHub Copilot、通义灵码、CodeGeeX代码补全、单文件生成、内联问答对上下文长度敏感需要配合项目规则文件独立编辑器Cursor多文件编辑、跨文件重构、项目级问答刚上手容易把整个仓库丢给 AI成本高且易走神终端工具Codex CLI、Aider命令行触发、git 集成、批量任务适合有清晰任务的开发者不适合探索式开发模型 APIQwen-Coder、DeepSeek-Coder 类模型私有化部署、需要控制敏感数据需要自己处理模型版本、推理资源和评测集框架生态Spring AI、LangChain 等把模型能力嵌入业务应用本质是应用开发不是写代码辅助工具选型建议如果你的代码有强合规要求优先选择支持私有化部署或离线使用的方案如果你主要写业务代码优先用 IDE 插件而不是临时网页对话框如果你需要让模型理解整个仓库先确认工具是否能读取项目索引而不是把文件内容全部粘贴进提示词。2.2 环境准备与依赖对齐AI 生成代码能不能跑很大程度上取决于环境是否一致。先执行一组基础检查避免“我本地能跑、你本地报错”的问题git --version node -v npm -v python --version docker --version java -version mvn -version不同项目只保留自己需要的命令。关键是确认Node、Python、Java 等运行时版本包管理器版本以及是否有统一的锁文件。常见的坑是 AI 提示使用“最新版依赖”但项目实际用的是另一个大版本。在提示词里写清楚Spring Boot 3.2、Python 3.11、Node 20比让 AI 自己猜可靠得多。如果项目使用 Docker 开发环境还要确保Dockerfile和docker-compose.yml与本地版本一致。不要先让 AI 写代码再回头调环境要先把环境固定再让 AI 在这个边界内生成内容。2.3 仓库和目录规范要提前定好AI 缺少全局视角尤其缺少对目录规范和模块边界的理解。没有规范时它会在utils目录里塞业务逻辑在没有分层的地方强行分层造成结构混乱。更合理的做法是在项目根目录放一份团队约定文件很多 AI 编程工具支持项目级规则文件例如AGENTS.md或工具对应的规则文件。一个最小目录结构示例project-root/ README.md AGENTS.md docs/ architecture.md src/ main/ test/ scripts/ lint.sh test.sh .gitignore package.json # 或 pom.xml、pyproject.tomlAGENTS.md可以写这些内容# 项目约定 - 后端统一使用 Java 17 Spring Boot 3.2 - 所有对外接口必须有入参校验和错误码 - 禁止在 Service 层直接操作 HttpServletRequest - 单元测试使用 JUnit 5测试文件放在 src/test/java 下 - 新增依赖需要先在 issue 中说明原因 - 生成代码必须包含关键方法的注释但注释要描述行为不要复述代码把这类约定写进文件AI 在生成代码时才有可能遵守。只靠对话里说一次超过上下文长度后就会被遗忘。3. 把需求转成 AI 能执行的任务3.1 为什么提示词不能是“帮我写个登录”“帮我写个登录”是典型的模糊指令。AI 会自行决定用 Session 还是 JWT要不要验证码密码怎么加密是否要刷新令牌用户表字段怎么设计。这些决定看起来都合理但未必符合你的项目约束。更麻烦的是AI 会把它的默认假设写进代码让未来维护者误以为是业务要求。更好的方式是把 AI 当成一个能力很强、但完全不了解项目的结对开发者。你需要告诉它角色、任务、已知条件、约束和验收标准。提示词越具体生成结果越接近可提交状态。3.2 一个可复用的提示词模板下面这个模板适用于大多数后端功能生成场景角色: 你是熟悉 Java Spring Boot 的资深后端工程师 任务: 实现一个基于 Redis 的接口防重复提交注解 已知条件: - 项目使用 Spring Boot 3.2 - Redis 客户端已经引入 spring-boot-starter-data-redis - 已有基础响应体 ResultT - 需要指定 key 前缀、过期时间、提示消息 约束: - 不修改已有鉴权逻辑 - 不引入额外依赖 - 使用 AOP 实现避免侵入业务代码 - 正确处理并发场景使用 Redis 原子操作 - 生成内容包含: 注解类、切面类、单元测试示例 输出格式: - 每个类单独一个代码块 - 开头用一行说明文件路径 - 关键方法注释说明输入、输出和异常场景把这段提示词发给模型通常能得到比“写个登录”质量高很多的结果。关键在“约束”部分它让模型不要越界也让你后续审查有依据。如果 AI 仍然生成多余代码可以在提示词末尾追加一句“如果没有必要不要生成额外类或方法”。3.3 任务拆分与验收标准AI 适合处理边界清晰的小任务不适合一次性生成整个系统。一个常见的拆分原则是一个提示词只解决一个模块或一个功能点。任务类型是否适合 AI 直接生成人工必须做的事项目脚手架、目录初始化可以作为参考手动确认依赖版本和文件结构单个 CRUD 接口可以生成初版审查权限、校验、事务边界复杂状态机不适合直接生成先画状态转移表再让 AI 生成单步逻辑单元测试适合生成基础用例补充边界值和异常场景重构已有代码不适合先让 AI 分析代码提出重构方案人工确认每个任务都要有验收标准。例如“实现防重复提交注解”的验收标准可以是同一 key 在指定时间内重复请求返回错误码不同 key 可以并发通过单元测试覆盖正常、重复、并发三种情况。把验收标准写进提示词AI 生成后再逐条验证。4. 生成之后的验证闭环不是复制粘贴就能提交4.1 三道快速检查编译、静态检查、测试AI 生成的代码放在编辑器里看起来没问题是常有的事但提交前至少要过三道检查。不同技术栈命令不同这里以 Java Maven 和 Node.js 为例# Java / Maven 项目 mvn -q compile mvn -q verify# Node.js 项目 npm run typecheck npm run lint npm test三道检查分别对应三个问题代码能不能编译代码是否符合团队风格和静态规则核心逻辑是否有测试保护。只要有一道失败就不要提交。如果你的项目里还没有测试至少补充一条最核心路径的冒烟测试。对于接口类代码启动服务后用curl验证真实行为curl -X POST http://localhost:8080/api/submit \ -H Content-Type: application/json \ -d {title:test}正常情况会看到业务成功响应重复请求时应看到防重复提交的错误响应。没有运行验证只靠编译通过无法发现 Redis Key 设置错误、过期时间失效、事务未生效这类问题。4.2 代码审查清单每次提交 AI 生成代码前按以下清单过一遍检查点具体做法API 是否与现有接口一致对比 Controller 路由、请求方法、参数名异常是否被吞掉搜索空的 catch 块和printStackTrace是否重复造轮子搜索项目里是否已有类似工具类或注解是否有硬编码密钥检查代码和配置文件中是否出现明文密码、token是否处理边界输入传入 null、空字符串、超大值、重复请求时是否报错是否引入不必要依赖对比 pom.xml、package.json 的变更是否符合项目风格命名、日志、错误码、事务注解是否与旧代码一致注释是否失真对照注释逐行读实现不一致就改注释或改代码配合git diff查看变更范围比直接看 AI 生成的完整文件更有效。提交前运行git diff --stat git diff src/main/java/your/module/YourClass.java4.3 提交信息与变更记录AI 能生成格式标准的提交信息但它不知道这次提交的真实意图。建议让 AI 生成草稿然后人工修改feat(auth): add idempotent submit annotation for order creation - Add Redis-based idempotent annotation - Add AOP aspect to prevent duplicate submission - Add unit tests for normal and duplicate requests提交时不要git add .而是按模块逐个添加git add src/main/java/com/example/common/annotation/Idempotent.java git add src/main/java/com/example/common/aspect/IdempotentAspect.java git add src/test/java/com/example/common/aspect/IdempotentAspectTest.java git commit -m feat(idempotent): add order submit duplicate protection小步提交的好处是将来定位问题只需看一个提交如果某个功能不要了可以精准回滚Code Review 时也容易盯住一个逻辑单元。5. 三个月后仍然有效的工程习惯5.1 代码所有权不能交给 AIAI 可以生成代码但无法为代码负责。项目里每一行代码都应该有一个明确的人类 owner。原因是未来一定会有人问为什么这里要判断expireTime 0为什么这个接口不走缓存如果答案是“AI 生成的”项目就会陷入无人能解释的困境。实际操作上让 AI 生成初稿后自己至少手动改一遍关键逻辑。手动修改的过程就是理解代码的过程。提交后使用git blame查看每一行归属如果某个文件的关键行全部来自 AI 工具说明该文件的技术债风险偏高。5.2 保持小型可回滚提交AI 一次性生成的代码经常横跨多个模块如果整体提交后续很难定位问题。手动把一个大功能拆成多个提交是一种必要成本。一个建议的拆分顺序先提交工具类和公共配置比如统一响应体、异常码。再提交核心逻辑比如切面、校验规则。最后提交测试用例和文档。每步都要保证可以编译、可以运行。不要等全部代码写完再一次性提交那样既难审查也难回滚。5.3 对生成代码做“定期重构”AI 生成代码在短期可以运行但不代表长期可维护。两个典型问题一是重复代码多因为每个任务都在独立上下文中生成不会复用之前的实现二是抽象层次混乱因为 AI 倾向于把辅助方法放在调用处附近。建议每完成一个功能顺手做一轮小重构提取重复逻辑、统一命名、删掉未使用代码。如果重构范围较大可以让 AI 先生成重构方案再由人工执行。例如让 AI 分析一个类是否存在多个职责分析 src/main/java/.../OrderService.java 目标: - 找出超过 50 行的方法 - 找出同时处理校验、持久化、发送消息的方法 - 给出拆分建议但不直接生成代码 约束: - 只输出分析结果不要修改文件 - 每个建议说明对可测试性的影响这种用法把 AI 从“生成器”变成了“辅助分析器”对长期维护更友好。5.4 控制上下文窗口和成本很多 AI 编程工具按 credits 或 token 计费。把整个仓库粘贴进对话不仅成本高效果也差。上下文越长模型在中间部分出错的可能性越大。正确做法是每次任务只提供最小相关文件。如果需要让 AI 理解整个项目结构优先使用支持代码索引、语义检索的工具如果必须粘贴文件先删掉无关注释和空行再把关键类提取出来。一个实用的操作习惯每个新功能都开一个新会话。不要把“修改订单接口”和“新增用户列表”放在同一段长对话里。任务结束后主动关闭会话避免上一个任务的上下文干扰下一个任务。6. 常见问题与排查路径6.1 编译报错找不到符号或缺少依赖现象AI 生成代码后运行mvn compile或npm run build报找不到类、包、方法。排查顺序检查是否真的引入了对应依赖查看pom.xml或package.json的 diff。检查依赖版本是否和项目其他模块冲突优先使用项目已有的版本。检查包名是否正确AI 经常把com.example写错。检查 JDK 或 Node 版本是否满足库要求。解决方式基于项目现有依赖重新生成或在提示词里明确“只能使用pom.xml中已有的依赖”。6.2 程序能编译但业务结果不对这是最隐蔽的一类问题。AI 生成的代码逻辑看起来完整但真实运行后数据不对、超时、重复提交没有被拦住。排查链路先确认输入请求参数是否真的传进来了。再加日志在关键判断前后打印参数、缓存状态、返回结果。再写单测用最小输入固定期望输出观察哪个分支偏离预期。最后人工修复不要继续让 AI 扩大修改范围先定位缺陷再给提示词。常见原因是 AI 假设了业务规则。例如防重复提交只判断了 Redis Key 是否存在但没有设置过期时间或者缓存判断和业务更新不在同一事务中。这类问题必须通过测试暴露。6.3 AI 上下文丢失忘记之前的要求现象同一个会话里前面要求“不要修改鉴权”后一个请求却把鉴权代码改了。原因是模型注意力机制天然聚焦最近内容长对话早期约束容易被忽略。解决方式不是反复提醒而是把约束外置把“禁止修改鉴权”写进项目规则文件。把相关测试写进代码改坏了测试立刻失败。把关键约束写进提示词的最前面和最后面中间放次要信息。如果工具支持“项目记忆”优先使用而不是依赖对话上下文。6.4 安全与合规风险AI 编程工具会把对话内容发送到模型服务端生产数据、客户信息、私钥绝对不能粘贴进去。即使是使用企业私有化部署也要遵循最小必要原则。建议建立团队红线风险类型禁止行为合规替代密钥泄露在对话里粘贴数据库密码、API Key使用环境变量或密钥管理服务生产数据泄露把真实用户手机号、订单数据发给模型用脱敏数据或合成数据代码泄露把未公开的商业代码整体发给外部服务使用私有化模型或允许的合规工具依赖投毒直接采用 AI 推荐的新依赖核查依赖来源、版本、许可证6.5 提示词调优输出不满足要求时怎么办不要继续在原提示词上反复说“不对”更有效的是给出反面约束。比如“不要生成 Controller 层只生成 Service 和测试代码”。或者“不要使用 Lombok”。一般来说正面描述“要什么”和反面描述“不要什么”同时出现效果最好。如果 AI 生成的代码风格仍然不一致可以把项目中一个质量较高的文件作为示例粘贴进去让 AI 模仿现有风格。这比抽象描述“请遵守项目风格”更有效。7. 可复用的 AI 编程工作流模板7.1 任务拆解模板每次使用 AI 写代码前按下面的顺序走写需求一句话说清楚要解决什么问题。拆任务把需求拆成 30 分钟内能验证的功能点。给输入补充项目版本、相关文件、现有 API 约定。下约束禁止做什么、必须做什么、验收标准是什么。生成代码只让 AI 完成当前子任务。验证编译、静态检查、单元测试、接口测试。提交小步提交写清楚提交信息。重构顺手消除重复代码补关键注释。这套流程可以打印出来贴在工位上也可以在项目 README 里写一份简化版。7.2 每次提交前检查清单检查项完成标准代码能否编译构建命令无错误是否通过静态检查lint 或 checkstyle 无新增问题是否有测试覆盖至少覆盖正常路径和关键异常路径是否阅读过生成代码能说出每个主要方法的职责是否排除安全风险无密钥、无生产数据、无未知依赖是否拆分提交单个提交只包含一个逻辑变更是否可回滚回滚该提交不会影响无关功能是否更新文档对外接口变化有说明规则文件有同步7.3 每周复盘建议团队或个人都可以做一次轻量复盘记录这些问题AI 生成代码的返工率是多少哪些任务需要反复修改。最常见的错误类型是什么是边界条件、依赖版本还是项目约定。哪些场景让 AI 写代码反而更慢以后要不要改成人工。有没有新增 AI 无法理解的业务规则是否已经写进规则文件。现有测试是否覆盖了 AI 容易出错的地方不足就补测试。复盘的目的不是追求“AI 写得越多越好”而是找到人机协作的最优边界。三个月后还能让你感到“爽”的不是模型变得更强而是你已经拥有了一套能让任何代码都保持可维护的流程验证闭环、代码所有权、小步提交、持续重构。建议今天就从一个小任务开始按上面的提示词模板生成代码再走一遍提交前检查清单。你会发现真正值钱的不是 AI 生成的代码而是你能让这些代码稳定运行、随时修改的能力。
