1. 先搞清楚什么是真正的强制复用成熟方案很多人第一次接触Vibe Coding时会觉得AI写代码就像魔法一样神奇。但真正在项目中落地后最头疼的问题不是AI写不出代码而是AI写出来的代码风格混乱、架构不一致甚至把已有的成熟方案改得面目全非。强制复用成熟方案的核心不是让AI创造而是让AI模仿。具体来说就是让AI按照你项目中已有的代码规范、架构模式和最佳实践来编写新代码而不是每次都重新发明轮子。为什么这比单纯的功能实现更重要新代码与现有代码库风格一致降低维护成本避免引入新的技术债务和架构混乱团队成员接手时不需要重新适应新的编码风格减少代码审查和合并时的冲突我一般会先让新人看项目里写得最好的几个核心文件比如UserController、OrderService这些让AI先学习项目的代码DNA再开始写新功能。2. 用Git为AI编码划定安全边界AI改错一行代码不可怕可怕的是它一口气改了20个文件等你发现方向不对时已经不知道哪些该留、哪些该扔了。Git不是事后补的仪式而是AI动手前的必备检查点# 开始前先检查工作区 git status --short # 如果有未提交的改动先处理干净 git stash # 或提交到临时分支 # 为当前任务单独开分支 git switch -c feat/order-export即使是再小的任务我也建议开单独分支。在主分支上直接Vibe Coding心理负担会越来越大分支隔离之后AI就算写废了也只是当前任务分支的问题。AI改完代码后不要急着看它的总结先看仓库自己怎么说# 看影响面 git diff --stat # 看具体改动 git diff # 交互式暂存控制提交粒度 git add -p # 小步提交 git commit -m feat: add order export一个提交只做一件事。能分块提交就分块提交后面的Review、回滚、定位问题都会轻松很多。3. 用Spec驱动替代模糊需求你对AI说帮我实现订单导出功能这句话太宽泛了。AI不知道每次导出几条、导出什么格式、导出哪些字段、字段顺序怎样。信息没给够它就会自己猜。猜出来的结果能跑但未必是你想要的。不如在开工前花几分钟写轻量Spec通常比后面返工更划算## 目标 实现订单导出接口支持按时间范围导出CSV。 ## 约束 - 单次最多导出5000条 - 时间范围不能超过31天 - 只能导出当前租户的数据 - 查询必须走order_tenant_time_idx索引 - 导出失败要记录失败原因不能只返回unknown error ## 验收 - 正常导出CSV字段顺序为order_no、amount、status、created_at - 超过5000条返回明确错误 - 越权租户数据不能被导出 - 单元测试覆盖无数据、越权、超过条数、超过时间范围4种情况这份东西不用写得像方案评审文档。小任务写清楚目标、约束和验收就够了中等任务再补接口格式、错误码、表结构大一点的需求再拆成requirements.md、design.md、tasks.md。4. 让AI学习项目里的好代码代码要优雅、可维护、符合最佳实践这种话放在Prompt里看着很认真实际约束力很弱。模型更擅长模仿具体样板。你让AI看一段项目里真正合格的代码它反而更容易写出同一套风格的代码。具体做法先阅读UserController、UserService、UserRepository和对应测试。参考它们的分层方式、异常处理、返回体包装、日志风格和测试写法。然后实现OrderExportController。关键约束要明确不要引入新的响应格式不要新增全局异常处理器不要绕过现有权限校验逻辑把项目痛点写成规则文件长期项目可以把这些规则放到AI工具能稳定读取的位置。比如Claude Code: CLAUDE.mdCodex: AGENTS.mdCursor: Project Rules、.cursor/rules/*.mdGitHub Copilot / VS Code: .github/copilot-instructions.md千万别写成项目说明书应该写技术栈版本、常用命令、架构取舍、团队约定和项目痛点别套空话、默认行为和大段文档。5. 善用Skill把套路沉淀下来规则文件和Skill解决的问题不太一样。规则文件更适合放这个项目一直要遵守什么比如技术栈版本、启动命令、目录结构、错误码格式、哪些文件不能碰。Skill更适合放遇到某类任务时应该怎么做。比如做代码审查、写测试、改前端页面、网页调研、写技术文章这些任务每次流程都差不多就没必要每次都在聊天里重新提醒一遍。我之前写过两篇相关的文章《Agent Skills是什么和Prompt、MCP到底差在哪》和《AI编程必备Skills推荐》。简单说Skill就是一份能被Agent按需加载的任务说明。它不是插件也不是MCP工具本身而是把某类任务的流程、约束、检查项和避坑经验写进SKILL.md。比如这些事情就很适合沉淀成Skill写功能前走TDD先写失败测试再实现做代码审查时固定检查安全、事务、性能、边界条件和项目约定写前端页面时固定检查响应式、hover状态、可访问性和设计系统做网页调研时固定选择搜索、抓取、浏览器自动化这些工具的顺序写技术文章时固定检查事实来源、引用、标题层级和AI味为什么要用Skill因为这些流程每次靠聊天提醒都很烦。你今天提醒它先写测试明天换个会话它又忘了你这次让它Review权限风险下次它可能只看命名和格式。Skill的价值就在这里把重复提醒变成可复用的工作手册。不过Skill也别写成README。README是给人看的可以讲背景、原理和安装说明Skill是给Agent执行任务时看的重点是什么时候用、按什么顺序做、哪些情况别做、失败了怎么兜底。6. 贵模型定方向便宜模型干脏活不要什么都扔给最贵的模型。请了一个资深架构师结果天天让他改字段名、补getter、调CSS钱花了不少价值没出来。反过来也一样为了省钱把系统设计、安全边界、复杂重构全交给便宜模型硬扛最后返工成本可能更高。我更常用的是贵模型定方向便宜模型干活最后再让贵模型验一遍第一步让Claude Opus 4.6/4.7这类顶级模型读需求和代码库。只让它做方案、列风险、拆任务不让它急着写代码。第二步方案确认后把一个Task扔给DeepSeek V4-Pro/GLM5.1或同级低价模型。让它按任务编码、补测试、跑命令做完之后给出diff摘要。第三步把git diff交回Claude Opus 4.6/4.7。这次只让它ReviewBug、越权风险、事务边界、性能问题、测试缺口。代码审计也可以这么干。先让便宜模型扫一遍项目把疑似问题列出来再让强模型复核这些问题到底成不成立。直接让高价模型全量扫当然也不是不行就是钱烧得快收益未必成比例。7. 用验证代替信任用数据代替承诺AI最爱说已修复已优化没问题。听听就行别直接信。我更愿意看三样东西测试、命令输出、diff。比如你让它修一个订单导出Bug不要只问修好了吗。可以直接这样要求先不要改实现。 先根据Spec补测试覆盖正常路径、参数非法、权限不足、无数据、并发重复请求。 测试一开始应该失败。 我确认测试合理之后你再改实现直到测试通过。这个做法有点像TDD但不用搞得很教条。重点是别让AI一边改代码、一边补一个永远会通过的测试。先让测试失败再让实现通过心里会踏实很多。不想完整TDD至少也要让它列清楚验收项[ ] 新增接口有权权限校验[ ] 错误返回符合统一格式[ ] 数据库查询命中指定索引[ ] 空值、越界、重复请求都有测试[ ] 日志不打印token、password、api key[ ] 所有测试通过还要让它贴运行过的命令和结果mvn test npm test go test ./... pnpm lint没跑就写未运行并说明原因。比如依赖没装、数据库没起、测试环境缺配置都可以接受最怕的是它没跑但写一句已验证糊弄过去。性能优化更不能只听它说。速度提升明显你就让它把优化前后的SQL、EXPLAIN、测试数据量、P95/P99或接口耗时证据贴出来。没有真实压测结果就只写预期收益和待验证项别让它编数字。8. 管理好上下文别让AI迷失在信息海洋中上下文窗口大不等于效果好——窗口能装更多东西但模型能不能稳定找到重点是另一回事。一个会话里先写登录再改支付又重构缓存最后问为什么测试挂了模型早把旧约束、失败尝试和废弃方案混在一起了。你以为给了它完整历史它拿到的可能是一堆噪声。Vibe Coding里上下文要管三件事。第一别把仓库一股脑塞进去。当前任务只需要Spec、相关文件、报错日志、验收命令和少量参考实现。其他内容先用路径、文件名、目录结构钩着等需要时再让Agent去读。Claude Code分析大仓库时也是这种思路先用搜索和目录定位再逐步读具体文件而不是上来吞全部代码。第二长任务要及时压缩。Claude Code可以用/compact压缩上下文用/clear清空上下文Codex或其他Agent也有类似的摘要、压缩、重启机制。压缩是为了保留重点比如架构决策、已改文件、未解决问题、失败命令和下一步任务丢掉重复对话和已经消化的工具输出。第三关键进展要落地到文件里。比如让Agent在长任务中维护一份NOTES.md或任务handoff记录## 已完成 - 修改了哪些文件 - 哪些测试已经跑过 - 哪些问题已确认不是Bug ## 剩余任务 - 还没修的失败用例 - 还没确认的边界场景 - 下一个Agent需要先读哪些文件这样就算开新会话也不用重新解释半天。聊天记录会变长、变乱、变旧结构化笔记反而更稳定。我的习惯是一个会话只处理一个任务超过两次矫正还不对就开新会话新会话只带当前Spec、相关文件、失败日志、验收命令和上一轮handoff。对多数编码任务来说3000到8000 tokens的高质量上下文通常比几十万token的杂乱对话更可靠。上下文可以写得很朴素## 当前任务 实现订单导出接口。 ## 必读文件 - src/main/java/.../UserController.java - src/main/java/.../OrderRepository.java - docs/spec/order-export.md ## 禁止修改 - 数据库已有字段名 - 全局异常格式 - 登录鉴权逻辑 ## 验收命令 - mvn test - mvn -DtestOrderExportServiceTest test文档也可以当上下文用。AI改了多个模块后让它补一份变更说明新增了什么接口改了哪些表或索引关键业务规则是什么如何验证如何回滚。这样下次继续开发时就能直接喂给AI。9. 多Agent先串行再并行用任务边界控制协作成本多Agent分工协作的玩法确实很酷但不建议大家上来就尝试多Agent并行比如一个写代码一个补测试一个做Review一个写文档很容易把项目搞乱。你刚开始就串行着跑就好了Plan Agent只读代码输出方案和任务拆分Code Agent只负责一个Task不碰其他任务Test Agent补测试并运行验证Review Agent只看diff找问题不直接大改一定不要让多个Agent同时改代码让它们在同一个feature分支上按顺序提交git commit -m [plan] add order export design git commit -m [code] implement order export api git commit -m [test] add order export tests git commit -m [review] fix tenant permission check等流程跑顺之后也比较熟练了再考虑worktree并行、Agent View这类玩法。并行最怕的不是Git冲突那种至少能看到。真正麻烦的是不冲突——两个Agent同时改同一个公共DTO一个为了导出加字段一个为了查询删字段合并时看起来没问题但接口语义、序列化结果、前端依赖可能已经变了。所以多Agent不能靠运气要靠任务边界、分支隔离和验收项管住。哪些文件能改、哪些模块不能碰、改完要跑哪些测试、哪些diff必须人看都要提前写清楚。10. 权限控制要前置不能只靠Prompt提醒AI Coding不能只靠Prompt里写一句请您谨慎一点别做危险操作。Claude Code这类工具已经不只是回答问题它会读文件、改代码、执行命令也可能通过MCP调内部工具或外部服务。风险自然也不再只是代码写错更严重的可能是误删文件、改错配置、跑错迁移、推到远程甚至碰到密钥、证书、生产配置这类敏感信息。所以权限要提前收住。.env.production、密钥、证书这类文件默认就不该让AI读取或修改删除文件、数据库迁移、推远程、改CI配置这类操作必须人工确认登录、支付、权限、上传、Webhook这类模块改完要单独做安全Review。Claude Code官方其实也提供了对应的权限机制。比如可以用/permissions查看和管理工具权限权限规则里可以配置allow、ask、deny分别表示允许执行、执行前询问、直接拒绝。像git diff、跑单测这种低风险命令可以放得宽一点git push、删除文件、读.env、访问secrets/**这类操作就应该放到ask或deny里。如果只配置权限规则还不放心可以继续加Hooks和Sandbox。Hooks可以在工具调用前后执行自定义检查比如拦截危险命令、检查是否改了敏感路径、在提交前跑格式化和测试Sandbox则更偏向执行环境隔离用来限制Bash命令能访问的文件系统和网络范围。举个例子假设Claude Code准备执行rm -rf /tmp/buildPreToolUse Hook会先拿到这次Bash调用判断它是不是危险命令如果命中规则就返回denyClaude Code会取消这次工具调用并把拒绝原因反馈给Claude。更稳的做法是把这些规则固化到工程里哪些命令可以自动执行哪些命令必须人工确认哪些路径禁止读取或修改哪些MCP工具不能随便调用哪些CI任务必须人工审批哪些测试不过就不能合并。这里还有一个容易忽略的点权限规则不是万能的。比如你只拦了rm *不代表一定拦得住/bin/rm、find -delete这类变体。所以高风险操作不能只靠一条命令黑名单兜底最好结合路径限制、Hooks、Sandbox、CI和人工Review一起管。工程上的谨慎肯定不能写在Prompt里要落到命令、脚本、权限、测试、CI和审批流程里。11. 我的日常实战流程日常写需求时我一般按这个节奏走新建分支先确认工作区是干净的。写一份轻量Spec把目标、约束、验收标准说清楚。看看有没有合适的Skill比如TDD、Code Review、前端设计、网页调研。先让顶级模型出方案只讨论方案不让它急着写代码。方案确认后再把一个个Task扔给低价模型。让它按任务编码、补测试、跑命令做完之后给出diff摘要。每完成一个Task就跑测试、看diff然后小步提交。当前diff稳住后再让顶级模型做一次Review。修掉Review里合理的问题再跑一遍测试。合并前人工看关键diff。涉及数据、权限、支付、定时任务这类改动时再补一下文档、回滚方案或灰度说明。这个流程比一句话生成代码慢一点。但慢的这点时间通常会在后面赚回来。至少能少很多返工、回滚和线上排错。短期原型可以大胆Vibe先把东西跑起来再说但只要代码要长期维护还是得回到工程流程里。GitHub Flow本身也是围绕分支、Pull Request、Review和合并来组织协作不是让人直接往主分支莽代码。Codex这类工具也支持通过AGENTS.md放项目级规则让AI按仓库里的约定做事而不是每次都靠聊天临场提醒。说白了AI写代码越快Git、测试、Review、Spec这些老东西越不能丢。以前它们是为了约束人现在还得顺手约束AI。