1. 为什么我们需要一个“分层模型”来看AI编程最近和不少朋友聊起AI编程大家普遍的困惑是工具都装了提示词也会写但项目一复杂就开始失控。小需求跑得飞快大需求改几轮就崩最后得出的结论往往是“AI编程只适合写玩具”。这个判断我不同意但我也承认它反映了一个真实的瓶颈——我们缺的不是更强的模型而是把AI编程这件事组织起来的框架。我想把这个框架叫作“分层模型”英文就是AI Programming: A Layered Model。它不是什么玄学理论而是我在大量实操里总结出来的一个观察当AI编程在一个项目里稳定地产生价值的时候它的工作方式并不是一个黑盒在变魔术而是像传统软件工程一样有清晰的层级划分。每一层有自己的职责、输入、输出和质量标准。如果你能把这些层理清楚AI编程从“碰运气”变成“可管理的工程行为”其实没那么难。这套模型适合谁适合已经在用AI辅助写代码、但觉得效果不稳定的人适合想带团队落地AI编程、却不知道怎么定规范的技术管理者也适合那些对AI编程既好奇又怀疑、想搞清楚它边界在哪的同学。下面我用实际项目和踩坑经历把每一层拆开讲。2. 分层模型的整体设计从“一条提示词”到“一个系统”2.1 传统编程和AI编程的本质差异先说一个我常用来打比方的例子。传统编程好比请一个厨师你给他一份固定菜谱他严格按照步骤执行火候、调料都精确到克。而AI编程更像把一个帮厨直接推到主厨的位置他能做菜但他并不知道你今天想做的是宴席还是快餐。决定权完全在你怎么布置厨房、怎么拆解任务、怎么验收结果。传统软件工程里有经典的层次划分UI层、业务逻辑层、数据访问层每一层向下依赖、向上提供服务。这套思路其实完全可以迁移到AI编程里。区别在于传统代码里的层与层之间靠函数调用、接口协议来连接而AI编程里的层与层之间靠的是上下文、提示词、工具调用和反馈回路来连接。当我把一次完整的AI编程过程拆开来看它的工作链条大概是这样的意图层你想做什么最终目标和约束条件是什么规划层这个目标可以被拆成哪些步骤每一步的验收标准是什么上下文层AI需要了解哪些项目背景、历史决策、现有代码才能正确行动执行层AI直接生成代码、调用工具、修改文件的具体动作。验证层如何确认AI生成的结果是对的编译、测试、人工审查反馈层发现错误之后如何把问题抛回给AI让它自我修正这六个层次串在一起才是一次完整的AI编程。大部分人的习惯是把所有东西揉在一起写一大段提示词让AI一口气完成。这在简单任务里没问题就像让帮厨做一道西红柿炒蛋他闭着眼也能做。但一旦任务复杂煮糊的概率就急剧上升。2.2 为什么要按层拆而不是追求“一句话搞定”有人会问AI编程最大的卖点不就是自然语言直接出代码吗为什么要把它搞得像系统工程一样复杂我理解这种想法但实际经验告诉我越是追求“一句话搞定”越容易在复杂项目里翻车。原因有三点。第一AI的上下文窗口是有限的你把所有需求、背景、细节塞进一条提示词里超过一定量之后它就开始“忘事”。分层可以把上下文管理的焦点集中在当前真正需要的部分。第二AI生成的代码是否正确需要逐层验证。如果不分层错误就像埋在混凝土里的钢筋表面看不出问题等要改的时候才发现烂透了。第三分层给了你一个定位问题的锚点。项目出了问题你能判断是意图理解错了、规划不合理、上下文不完整还是执行出错了而不是笼统地骂一句“这AI太笨了”。我这套分层模型的雏形是在一个真实项目里被逼出来的。当时我用AI做一个内部数据报表系统一开始图省事所有需求都堆在几个长提示词里。前两周还好后面每次改动都像拆雷AI改一个地方就把另一个地方弄坏了。后来我痛定思痛把项目按层整理了一遍建立了规范的工作流情况立刻好转了。后面我会详细拆这个项目的实操过程。3. 六层模型逐层拆解每一层都在解决什么问题先给一张总览表后面逐层展开。注意表格的作用是帮你建立整体认知真正的手感还是要靠实操去磨。层级职责核心产出常见失败模式意图层定义目标和约束需求描述、验收标准目标模糊做出来不是想要的规划层任务拆解与排序步骤清单、依赖关系任务太大AI难以独立完成上下文层提供必要背景信息项目背景、代码结构、历史决策信息缺失导致AI自由发挥执行层生成代码与调用工具代码diff、文件修改生成了但跑不通或风格不统一验证层判断结果是否正确测试报告、审查意见只看“能跑”没看“对不对”反馈层把错误信息送回AI修正修正后的代码、更新后的计划反馈含糊AI原地打转3.1 意图层AI编程的地基也是被忽视最多的地方意图层是所有层的基础但它恰恰是被忽视最多的。很多人在AI编程工具里直接敲一句“帮我写一个用户登录模块”这就是典型的目标模糊。你认为自己表达清楚了但对AI来说“帮我写一个用户登录模块”这句话的信息量约等于零。我在意图层总结出来的写法是四段式背景 目标 约束 验收标准。不需要写长篇大论但四个要素必须齐全。举个例子我接一个需求要开发一个登录功能我交到意图层的描述是这样的背景系统是面向企业内部的CRM现有用户体系基于企业微信。目标实现一个Web端登录功能支持企业微信扫码登录以及账密登录作为备用。约束前端框架用Vue3后端用Go认证协议用OAuth2不引入新的用户表复用现有账户体系。验收标准扫码登录端到端不超过3秒账密登录错误提示要区分用户不存在和密码错误安全方面要求登录失败连续5次锁定15分钟。这四条写下来其实不需要多久但它决定了AI后续所有工作的边界。没有这些约束AI大概率会自由发挥给你设计一套注册、登录、找回密码、邮件验证全都有的系统——听起来很完整但不是你要的东西。3.2 规划层让AI当一个会拆任务的项目经理意图明确之后下一步是规划。这里要区分两种情况。如果你用的是ChatGPT这类通用对话模型规划任务通常需要你自己做或者明确要求AI先输出方案再动笔。如果你用的是Copilot、Cline这类深度集成IDE的工具工具本身已经内置了一些规划能力。我在规划层坚持一个原则一个任务要让AI在30分钟内能完成主体工作。超过这个粒度就继续拆。这个数字不是拍脑袋定的而是从大量实践中观察出来的。任务粒度越小AI的完成质量越稳定出错了也更容易定位和重做。规划层的输出是一份清晰的步骤清单每步要有独立的验收条件。比如做登录功能我会拆成五个步骤后端实现企业微信OAuth2授权对接验收标准是用测试账号能走通完整回调流程。后端实现本地账密认证逻辑验收标准是单元测试覆盖正确密码、错误密码、用户锁定三个场景。后端用户表结构确认与迁移脚本验收标准是迁移脚本能反复执行而不报错。前端登录页UI实现和表单校验验收标准是边界输入空值、超长输入、特殊字符不触发报错。联调两个登录方式的端到端测试验收标准是主流浏览器全部通过。拆得这么细的好处是任何一步失败了AI失败的影响范围被限制在一个很小的区域内。它不需要重新理解整个项目只需要修复这一个步骤里出问题的文件。3.3 上下文层AI的记忆决定它是在帮忙还是在添乱上下文层是决定AI编程体验优劣的关键但也是最少被讨论的。你可以把AI想象成一个很聪明但只有七秒记忆的实习生。它每次响应你的时候都像刚睡醒一样。你给它的上下文越充分它表现得越像一个资深的同事实习生梦游。我在实操中维护上下文的常用手法有四种第一种在项目仓库里维护一份CONVENTIONS.md或AGENTS.md文件。这份文件里记录了项目的技术栈、目录结构、代码风格、命名规范、测试要求、禁止事项比如“不要修改xxx文件”“不要使用xxx依赖库”。AI编程工具大多支持自动读取这类文件比如Cursor的Rules、Cline的规则设置。每次会话开始时AI会自动加载这份文件作为长期记忆。这相当于给AI发了一本员工手册。第二种写一份模块级的README说明。很多人在项目里为每个复杂模块维护一份简短的说明描述这个模块是干嘛的、核心数据流是什么样的、有哪些历史坑。AI要改这个模块之前先让它读一遍这份文档效果比直接丢给它一堆源码好太多。第三种把“对话压缩”当习惯。当对话上下文变得很长AI开始答非所问的时候不要再继续往下聊。停下来新开会话把项目背景、当前进度、遇到的问题压缩成一段新的提示词重新开始。这个习惯能救回很多即将崩掉的会话。第四种善用“代码引用”。好一点的AI编程工具支持file、folder这种代码引用功能。我在提示词里永远会显式引用相关文件而不是指望AI自己去找。AI连项目结构都不清楚的时候让它自己在几千个文件里翻找目标代码纯属碰运气。3.4 执行层AI动手写代码的地方也是矛盾最集中的一层执行层就是AI实际生成代码、生成diff、修改文件的地方。这里最大的争议点是AI生成的代码到底应不应该被信任我的答案是不信任但也不用视为洪水猛兽。用流程来管理风险而不是用态度。执行层的核心原则是让AI改对能改的守住不能动的边界。具体操作上有三件事。第一件事明确告诉AI哪些文件可以改、哪些不能碰。用Cline这类带文件读写权限的工具时我通常会先把不能动的文件加入忽略列表。AI闲不住你越不限制它它越喜欢顺手给你“优化”一下无关代码这是最常见的翻车原因。第二件事严格执行“小步提交”。让AI完成一个小任务之后立刻测试通过后提交再进入下一个任务。我在项目里经常看到有人图方便一口气让AI完成五六个模块最后跑起来发现到处都是错又难以定位每个错误对应哪个修改只能全部回滚重来。这完全是自讨苦吃。第三件事风格约束要写在规则文件里不要靠每次对话临时叮嘱。临时叮嘱一是容易忘二是消耗上下文窗口。我在规则的代码风格部分通常会写清楚的包括缩进用几个空格、注释语言用中文还是英文、变量命名用驼峰还是下划线、是否允许使用lodash这类工具库、组件文件组织方式。当AI生成的代码风格和项目原有代码风格一致的时候Code Review的心理压力和实际工作量都会小很多。3.5 验证层别被“能跑”骗了“对不对”才是关键很多人在AI编程里的验证方式就是AI生成代码运行一下程序没报错好了。这是极大的误区。“能跑”只说明语法正确、资源能加载完全不代表逻辑正确、边界处理得当、性能达标。我见过最典型的翻车案例是AI生成了一段导出Excel的代码运行起来确实导出了文件但只在数据量小的时候正常。数据量一大单元格数量超过Excel单表上限程序直接崩了。语法没有错逻辑看起来也对但边界条件没考虑到。所以验证层必须有超越“能跑”的标准。我的验证层分四个等级等级一编译通过无报错。等级二核心功能的人工冒烟测试通过。等级三关键逻辑的自动化测试通过单元测试、集成测试。等级四极端情况验证通过大数据量、并发场景、异常输入、安全测试。等级越高对AI编程结果的信任度越高。反过来说如果所有验证都只能停留在等级一说明你压根不该让AI碰这个项目的核心逻辑。这里还有一个实操心得让AI自己写测试代码但不要让它自己验证自己。AI写测试用例的价值很大因为它能快速覆盖大多数正常路径和常规边界。但AI写的测试有一定的“路径依赖惯性”经常测试没跑到特别极端的情况比如大量并发这种需要真实环境才能暴露的问题。所以让AI补测试代码、用测试结果反馈修正代码这个流程可以跑起来。最终的质量责任必须由人兜底。3.6 反馈层AI编程能力提升的真正按钮前面所有层次做得再好也不能保证一次就对。AI编程真正强大的地方在于它能利用反馈进行快速迭代。这个反馈层的设计直接影响一次任务从失败到成功需要多少轮对话。反馈层最常见的错误是含糊的抱怨“这个不行功能没实现好”“还是有bug”。这种反馈对AI来说约等于没有。它只能瞎猜然后改出另一个错误版本你再反馈它再猜陷入死循环。高效的反馈格式我总结成一个公式期望行为 实际行为 错误信息 相关文件。举个例子当我发现AI生成的登录接口有问题时我给出的反馈不是“登录还是不对”而是期望行为用户输入正确账号密码后接口返回200并带上token。实际行为接口返回401提示密码错误。错误信息控制台输出“invalid credentials, expected hash length 60, got 32”——这说明密码hash格式有问题。相关文件/backend/service/auth.go。这样的反馈AI几乎一次就能定位问题。因为它不需要猜测、不需要全局搜索只需要看着明确的信息去修改具体文件。在复杂项目里这种反馈习惯能把问题解决速度提升数倍。4. 一个真实项目走下来内部报表系统改造为了让你把这套模型串起来我拿一个真实的项目来讲。这个项目我之前提过是给公司内部做的数据报表系统技术栈是React Node.js PostgreSQL。系统原本是手动维护的一个月要花不少时间在导出、汇总、发邮件这类琐事上。我打算用AI编程把整个流程自动化。当时我还没形成清晰的分层意识只是觉得AI写代码快想全速往前冲。结果前期多少个晚上都在给AI“收拾烂摊子”。后来我停下来重新用分层模型把整个项目梳理了一遍才真正体会到这个框架的价值。4.1 意图层落地把“做个自动化报表系统”翻译成可执行的需求最初我对AI说的话是“帮我做一个报表自动化系统。”结果AI给我输出了一整套完整的SaaS平台设计——用户权限、多租户、计费模块都有。我只想要一个内部工具它给我设计了一堆用不上的功能。后来我在意图层花了一个小时把真正需要的东西写清楚了背景市场部每周需要从业务数据库导出订单数据按区域、产品线汇总生成Excel报表并发送到指定邮箱。目标实现一个Web应用让市场部同事选择报表周期和区域系统自动生成Excel并发送邮件。约束数据库只读访问无用户系统仅限内网访问部署在公司现有的Docker服务器上。验收标准一次完整的报表生成从点击到收到邮件不超过5分钟支持最大50万行订单数据邮件内容包含报表摘要和附件。这段描述写完AI的设计方案立刻从“通用SaaS平台”收敛为“内部工具”。后续所有工作都围绕真实需求展开没有跑偏。4.2 规划层落地项目从“一次搞定”到“五天迭代”有了明确意图下一步是规划。我用AI辅助做了任务拆解同时在关键节点做了人工干预。最终形成了这样的规划清单第一阶段页面原型骨架React路由、布局、表单组件。第二阶段后端API数据库查询、汇总计算、Excel生成。第三阶段邮件服务SMTP发送、附件处理。第四阶段报表页面打磨筛选条件、导出记录、错误提示。第五阶段Docker化部署。每个阶段下面再拆出若干个小任务每个小任务都对应独立的验收标准。整个项目分五天完成每半天处理一个任务包。这个节奏对AI编程来说刚刚好既能快速看到成果又有充足的时间处理意外情况。工具选择上我主用Cline配合Claude模型IDE用的是VS Code。选择Cline的核心原因有两个一是它的文件读写能力比较强适合处理多文件项目二是它的执行过程有清晰的diff展示我能看到AI每一步改了哪些文件。这一点比那种黑盒式的一键生成体验要安全得多。4.3 上下文层落地一份AGENTS.md一套项目笔记项目推进到第二天的时候我意识到一个严重的问题AI每次新会话开始都像失忆了一样不记得之前做了什么决策、为什么这个模块要这么写。同一个问题第一天它给了一个方案第二天又给了完全不同的方案。解决方案就是给项目建上下文文件。我在项目根目录建了一个AGENTS.md内容包括项目技术栈和目录结构说明。数据库只读约束的强调任何代码都不得执行写操作这是底线。Excel生成逻辑中关于数据量上限的约束超过多少行必须分Sheet。代码风格要求前端组件用函数组件Hooks命名以use开头后端路由处理函数统一放在routes目录。已知问题清单比如PostgreSQL连接池默认配置在并发高时会报错需要在代码中显式配置上限。这份文件写完后AI的“失忆”问题明显缓解。每次新会话开始AI自动读取这份文档后再动手生成的代码风格和约束遵循度大幅提升。我还在项目的docs目录下维护了一个“决策日志”文件记录每次重要决策的来龙去脉。比如“为什么不用定时任务而是手动触发”“为什么用Excel而不是CSV”。这些历史决策上下文在项目后期改代码时特别重要它防止AI“好心办了坏事”——比如自作主张把手动触发改成定时任务因为它觉得那样更自动化但业务上并不需要。4.4 执行与验证落地生成的代码不直接合并先看diff再测试在执行层我坚持一个规矩AI生成的所有代码先看diff再运行测试最后才允许合并到主干。不要觉得这一步多余。AI编程最舒服的地方就是它大大解放了生产力最危险的地方也是它能在几秒钟内改动大量文件而你对这个改动的审视速度永远跟不上它的产出速度。我记得项目第三天AI要加一个“按时间范围筛选订单”的功能。它正确地修改了后端API但顺手在数据库连接配置里改了连接池大小。这个修改不在我的任务范围内虽然不一定会引发故障但无意义的改动增加了排查问题的复杂度。我没有接受这次合并而是让AI把连接池配置改回去。从那以后每次让它改代码我都会加一句“只修改与本次任务直接相关的文件不要顺便重写、优化或调整无关键码。”验证层的执行上我让AI先给Excel生成模块写了单元测试覆盖了数据格式、空数据处理、大数据量分Sheet几个场景。这个测试本身写得还靠谱帮我发现了一个真实的bug当订单数据里出现空值的时候AI生成的时间格式化代码会直接崩溃。没有测试兜底这个bug大概率要在生产环境被用户发现。人机协作的节奏是上午给AI分配任务让它独立工作输出diff和测试报告下午我集中做代码审查和业务验收把问题以反馈层的形式抛回给AI修复。这样一个周期循环下来项目推进得比预期还要顺利。4.5 反馈层落地从“低级AI”变成“团队协作者”的秘密项目前半段效率低很大原因是我不知道怎么跟AI打交道。我在反馈层踩过不少坑也总结出了几个特别有用的技巧。第一个技巧是给AI“划句子”。就是在长段的反馈里用编号把几个独立的问题分开让它逐条处理这样它会按照逻辑依次修复不会漏掉任何一个。比如1. 报表导出时日期格式不符合中国习惯请改为YYYY-MM-DD2. 当选择“全部区域”时查询速度大幅下降请检查是否漏掉了索引3. 邮件标题中请加上报表周期否则收件人不好区分。第二个技巧是合理利用“再想想”策略。当AI给出的方案明显复杂或绕路时先别急着用。直接告诉它“这个实现太绕了重新想一个更简单的方案。”大多数时候它换一个思路后给出的方案反而更干净利落。第三个技巧是遇到连续两轮修复不成功时马上停手。不要继续在同一会话里纠缠。正确做法是新开会话把项目的AGENTS.md、当前任务的说明、最近的错误日志、此前尝试过的方案和失败原因一次性浓缩给新会话。很多时候换个“状态的AI”反而能改出来。这个现象背后的原因比较复杂但操作层面很实用。4.6 这个项目的最终结果和反思整个项目做完市场部的同事反馈很好原来每周要花半天做的事现在几分钟就完成了而且不再担心漏发、错发。整个开发周期比原计划还缩短了两天。让我更感慨的是AI编程的真正价值不是“替代程序员”而是把程序员从大量琐碎低效的编码劳动中解放出来让你有更多精力放在真正需要判断力的事情上——需求定义、架构设计、代码审查、业务理解。而这些事情的共同点恰恰是判断什么是正确的目标什么路径是合理的。分层模型并不是层层加码增加你的工作量它其实是帮你把最有价值的判断力用在正确的地方。5. 分层模型日常实操的常用配方与避坑指南如果你读完前面的内容想直接把分层模型用起来我整理了一份最小可行的操作配方你可以直接抄作业。5.1 新项目从零到一的启动清单一个全新的项目我会按这个顺序来打基础建立项目仓库初始化目录结构。写AGENTS.md把技术栈、代码规范、目录说明、禁止事项一次性写清楚。把需求意图用四段式背景 目标 约束 验收标准写成REQUIREMENTS.md。用AI辅助起草任务拆解人工复核后生成PLAN.md按阶段排列。开始第一阶段的任务每完成一个子任务就测试并提交。每天晚上统一处理反馈把当天遇到的问题和解决方案追加到决策日志里。这套流程跑几个来回即使项目换人接手新人也只要读三个文件REQUIREMENTS、PLAN、AGENTS.md就能快速进入状态。5.2 各层的常见问题和定位口诀分层模型还有一个好处就是自带排障能力。项目出问题你可以按层定位快速找到病因。做出来的东西根本不对路或者AI总是“想当然”——意图层出问题的概率最大。重新审视目标描述补全约束和验收标准。任务太重AI一次完成不了经常做到一半就乱——规划层太粗糙把任务继续切小。AI问你一堆基础问题或者答案自相矛盾——上下文层供给不足。喂AGENTS.md喂决策日志喂相关代码。生成的代码跑不起来或者风格跟项目格格不入——执行层的边界没守好。查看diff禁用核心文件的修改权限加强代码风格约束。程序能跑但结果不对——验证层缺失补测试补边界值检查。同一个问题反复改不好AI原地打转——反馈层的表达方式有问题检查反馈是否具体到“期望行为 实际行为 错误信息 相关文件”。这套口诀我在团队内部做了分享效果还不错。很多同事说以前项目崩了只能唉声叹气现在至少能像分析普通bug一样给AI编程中的问题定位心态也不那么容易崩了。5.3 两个容易被忽略的细节最后补充两个容易被忽略的实操细节。第一个是关于AI编程工具的选择。网上流行观点是“工具不重要模型才重要”这话大方向没错但不同工具在不同层级的能力侧重点不一样。比如有些工具对执行层的控制力强能精确控制文件修改范围验证层的集成也做得好有些工具在规划层表现更好擅长自动拆解任务。我的建议是根据你的项目类型和团队习惯选工具选定之后把规则沉淀到项目的AGENTS.md里。只要上下文层的下游规则固定了工具切换的成本是可控的——真正昂贵的从来是项目规则混乱导致的无效沟通。第二个是关于提示词仓库的管理。很多人只在写提示词的时候很用心写完用完就扔。我更推荐在项目里建一个prompts目录按使用场景保存高复用的提示词模板。比如代码审查提示词、测试用例生成提示词、bug定位提示词、任务拆解提示词。下次做同类任务直接套用微调上下文层的建设成本会随着项目累积逐渐下降AI的表现也会越来越稳定。6. 一些心里话AI编程分层模型对我意味着什么写这篇文章复盘整个项目的时候我越来越确定一个感受AI编程分层模型最大的价值不是提供了什么神奇技术而是给了我们一套理性对话的框架。技术圈有个现象AI编程讨论到一定程度就会走向两个极端。一个极端是无限吹捧好像AI马上要取代所有程序员了另一个极端是极度抵触觉得AI写的代码都是垃圾。两个极端都忽略了最基本的现实AI编程的真实能力很大程度上取决于使用者的系统性水平。同样一把电钻有人用来打一排整齐的孔有人能把墙打穿。差别不在于电钻本身而在于使用者懂不懂测量、定位、换钻头、控力度。分层模型这套框架本质上是把“用AI编程”从一门手艺活变成了一门可以分解、可以管理、可以复盘的工程活。它让每一条提示词的编写都对应到一个清晰的层级目标让每一次AI输出都有明确的验证標準让每一次错误反馈都成为模型的养料而不是无效争吵。我现在带新人做AI编程相关项目时第一课永远不会讲提示词的写法而是先让他们花时间理解这套分层模型。先把问题拆清楚再谈优化先把验证链路搭起来再谈效率。很多新人觉得这一步太麻烦想直接冲进编码环节。这个时候我都会劝一句前期麻烦的点恰恰是后期省时间的点。工程师面对一个新工具最大的专业素养不是追求手速而是追求可控。AI编程分层模型就是我目前找到的实现可控的最佳路径。最后再分享一个实操中的小技巧。如果你接触过Cline这类提供“计划 执行”模式的AI编程工具你可能会发现它经常会在执行前先生成一份计划然后让你确认。很多人在这一步忙着点确认根本不好好读计划结果就是AI按它自己的想法执行了一堆你并不需要的操作。我从这跌过几次之后养成了严格审计划的习惯计划里列出要改的文件我会逐个确认是否合理不该动的文件出现直接拒绝执行并把理由写进反馈。多养成几次这个习惯AI的自觉性会显著提高。它慢慢学会了你的边界在哪里。套用分层模型的话说这个细节本质上是从执行层入手倒逼反馈层和上下文层的同步优化。它很不起眼但对工作流稳定性的提升是实打实的。