上周我用AI写了一个数据处理模块，从需求描述到代码生成，总共花了8分钟。然后我花了3个小时review它写的代码。

这不是段子，这是我的真实经历。

相信很多程序员都有类似的体验——AI写代码一时爽，review AI代码火葬场。你盯着屏幕上那些”看起来挺对”的代码，心里总有个声音在问：这玩意儿真的靠谱吗？

问题出在哪儿？不是AI不够聪明，而是我们没给它画好边界。

大多数人还在”凭感觉”用AI编程

有个词叫Vibe Coding，翻译过来就是”氛围编程”——凭感觉决定什么交给AI，什么自己写。

听起来很随性很酷对吧？但实际操作起来，大概是这样的：

过度依赖派：什么都扔给AI，从业务逻辑到数据库设计全让它来。写的时候觉得效率高得飞起，三个月后技术债堆成山，重构的时间比当初手写还长。

过度谨慎派：只敢让AI帮忙补全个变量名，写个注释。AI工具的订阅费照付，效率提升约等于零。你问他为什么不多用用，他说”怕出问题”。

这两种人的共同特点是：没有一套清晰的判断标准，来决定哪些任务适合交给AI，哪些不适合。

有意思的是，连AI工具的开发者自己，都在反思这个问题。

Claude Code团队的”反直觉”操作

最近技术圈有个挺有意思的事：Claude Code团队宣布，他们的提示词模板从Markdown格式切换到了HTML格式。

这看起来是个技术细节，但背后的逻辑值得琢磨。

Markdown的特点是什么？灵活、简洁、自由度高。但正是这种自由度，让AI在生成内容时有了太多”发挥空间”——格式不统一、结构不可控、输出质量参差不齐。

换成HTML之后呢？标签是刚性的，结构是确定的，AI的自由度被大幅压缩了。

本质上，他们是在主动收缩AI的自由度，来换取更高的产出质量。

这给了我一个启发：用AI编程也是一样的道理。不是所有任务都应该给AI同样的自由度。有些任务，你应该放手让它跑；有些任务，你得在旁边盯着；还有些任务，你最好自己来，让AI打下手就行。

基于这个思路，我总结了一套”三色分层法”。

AI编程三色分层法

绿区：放手让AI飞

绿区任务的特点：输入输出明确、有标准答案、错了容易发现。

具体包括哪些？拉个清单：

  • 模板代码：CRUD接口、数据模型定义、配置文件生成。这些代码有固定模式，AI闭着眼都能写对。
  • 单元测试：给AI一个函数签名和行为描述，它生成的测试用例覆盖率经常比你手写的还高。
  • 文档生成：API文档、代码注释、README。AI最擅长的就是把结构化信息变成人类可读的文本。
  • 格式转换：JSON转YAML、SQL转ORM、一种代码风格转另一种。纯体力活，不需要动脑子。
  • 正则表达式：说真的，谁愿意手写正则？让AI来，又快又准，还帮你加注释解释每段的含义。

绿区任务的效率提升是最明显的。根据我自己的记录，这类任务交给AI之后，平均节省70%以上的时间。而且因为输出结果容易验证，review成本也很低——跑一遍测试就知道对不对。

绿区的核心原则：大胆用，但要有自动化验证兜底。

给这些任务建一个prompt模板库，标准化输入格式，让AI每次都走同一条路。别让它”发挥创意”，创意不是这里需要的东西。

黄区：人定骨架，AI填肉

黄区任务的特点：有正确方向但没有唯一答案、需要业务理解、错了不容易马上发现。

这是最需要技巧的区域：

  • 业务逻辑实现：你定好接口签名、数据流、边界条件，让AI来填写具体实现。你是建筑师，AI是施工队。
  • API设计：你确定资源模型和核心端点，AI帮你补全参数校验、错误处理、分页逻辑这些标准化的部分。
  • 性能优化：你定位到瓶颈（比如某个SQL慢查询），让AI提供优化方案。但最终选哪个方案，你来拍板。
  • 重构：你决定重构的方向和目标结构，AI来执行具体的代码搬迁和改写。
  • 代码迁移：框架升级、语言版本迁移这种。你把迁移规则讲清楚，AI来做具体的文件级改动。

黄区的关键在于分工明确。我见过最多的翻车场景，就是在黄区任务上甩手不管——把一个模糊的需求直接扔给AI，然后对着一屏幕不知道对不对的代码发呆。

正确的姿势是：你先把”骨架”搭好。接口定义、数据结构、核心流程、异常处理策略——这些是你的工作。然后把”填肉”的活交给AI。

黄区的核心原则：给AI一个框架，而不是一个愿望。

为黄区任务建一份review checklist：

  1. AI的实现是否偏离了你定的接口契约？
  2. 边界条件处理了吗？
  3. 错误路径合理吗？
  4. 有没有引入你没预期到的依赖？

每次review就照着这个清单过，别凭感觉。

红区：你来开车，AI当导航

红区任务的特点：出错代价高、需要全局视野、涉及系统性决策。

这些任务你必须亲自主导：

  • 安全关键代码：认证授权、加密解密、支付逻辑、数据脱敏。AI写的安全代码可能”看起来对”，但安全这个领域，”看起来对”和”真的对”之间可能隔着一个数据泄露事故。
  • 架构决策：选什么技术栈、怎么拆分服务、数据库怎么选型。这些决策的影响是长期的、系统性的，需要你对业务全景有深刻理解。
  • 跨系统集成：多个服务之间的协调逻辑、分布式事务、消息队列的消费策略。AI看不到你的系统全貌，它给的方案大概率是”技术上可行但业务上不对”。
  • 数据模型设计：核心业务实体的关系建模。这直接决定了系统未来的演进方向，搞错了迁移成本极高。

但”人类主导”不等于”不用AI”。在红区，AI是你的高级搜索引擎和方案对比工具：

  • 让AI帮你搜索”JWT vs Session在微服务场景下的利弊对比”
  • 让AI帮你生成”三种数据库分库分表方案的对比表格”
  • 让AI帮你review你自己写的安全代码，列出潜在风险点

红区的核心原则：AI提供信息，你做决策。

一张图看清三个区

怎么判断一个任务属于哪个区？问自己三个问题：

判断维度 绿区 黄区 红区
出错了容易发现吗？ 跑个测试就知道 需要仔细review 可能上线才暴露
有标准答案吗？ 有，且唯一 有方向，多种实现 没有标准答案
需要业务上下文吗？ 不需要 需要部分 需要全局理解

记住这张表，下次再打开AI编程工具的时候，先花10秒钟想一想：我现在要做的这个任务，是绿色、黄色还是红色？

10秒判断：你的任务属于哪个区？

落地三步走

光有框架不够，得落地。这是我建议的三步走：

第一步：记一周任务日志

从明天开始，每次用AI写代码的时候，在旁边开个记事本，记录三件事：任务内容、你的分区判断（绿/黄/红）、实际效果（节省了多少时间/翻车了没有）。

一周之后你会发现一个有趣的现象：你的绿区任务可能比你想象的多得多，你的红区任务也可能比你以为的少得少。大多数人高估了红区、低估了绿区。

第二步：为绿区建prompt模板库

把你高频使用的绿区任务，做成标准化的prompt模板。比如：

请为以下TypeScript函数生成单元测试，使用Jest框架，覆盖正常路径和以下边界条件：[条件列表]。测试文件命名为xxx.test.ts。

模板越标准，AI的输出越稳定。这就是Claude Code团队从Markdown换到HTML的同一个道理——用结构约束换质量保证。

第三步：为黄区建review清单

别信自己的”感觉”，用清单。上面那四条review问题，打印出来贴在显示器旁边。每次AI交付黄区代码，逐条核对。

做完这三步，你跟AI编程的协作效率至少能翻一倍。不是因为AI变聪明了，而是因为你学会了把它放在正确的位置上。

写在最后

AI编程的终极形态不是”AI替代程序员”。

如果你今天还在纠结”AI会不会抢我饭碗”，那你可能问错了问题。更好的问题是：我怎么当好AI的产品经理？

想想看，产品经理做什么？定义需求、划定边界、分配资源、把控质量。这不就是三色分层法在做的事吗？

你的价值不在于写代码的速度——这个AI迟早会超过你。你的价值在于判断力：什么该让AI写，什么该自己写，什么时候该喊停。

这种判断力，恰恰是AI最不擅长的东西。

所以别再Vibe Coding了。给你的AI画好三条线，然后享受真正高效的人机协作。