我最近在复盘团队几个月的AI编程实践越看越觉得一个现象值得单独拿出来说说AI代码生成量越来越大但开发效率的提升却远远没有跟上。打开Pull Request看AI生成的代码动辄三五百行Review的人满头问号——“这段代码为什么这么写”“这个边界情况是谁补的”“性能有人测过吗”。AI编程确实火了从免费的编程助手到Codex这类付费AI编程软件各种工具层出不穷但不少人正陷入一个“越帮越忙”的怪圈工具越强大返工越多。这篇文章想聊聊我观察到的现象、背后的原因以及我目前摸索出来最有效的解法——垂直深耕。不管你是正在用AI编程的个人开发者还是想带团队落地AI辅助开发的负责人这篇内容都值得看完。先说结论AI编程本身没问题问题出在我们把它当成了“什么都能干的通用助手”却没有给它建立属于你项目的上下文和边界。垂直深耕本质上是把AI从一个博而不精的杂工训练成只懂你这摊业务、只写你这套代码的专职工程师。接下来我会从现象拆解、底层逻辑、实操方法、工具选型到常见问题排查一条一条讲清楚。1. AI编程的“越帮越忙”现象到底哪里出了错1.1 从“爽快代写”到“返工地狱”的真实经历先讲几个我真实遇到过的场景你大概率也踩过类似的坑。第一个场景是“代写一时爽返工火葬场”。让AI生成一个数据导出功能它刷刷刷给你写了200行看起来逻辑完整、注释齐全。结果Review时发现边界情况完全没处理文件为空怎么办、特殊字符转义、大文件内存溢出一个都没考虑。你只能一边补代码一边骂骂咧咧。这种事发生三五次之后你会下意识怀疑是不是我自己写反而更快第二个场景是“测试地狱”。AI说自己已经加了单元测试打开文件一看——断言写的是恒真表达式Mock裸奔或者干脆测了一个永远通过的快乐路径。这种代码比不写测试更危险因为它制造了“我有测试保护”的假象让后面所有改动都踩在流沙上。第三个场景是“上下文记忆的薛定谔”。同一个PR里AI在前半段还老老实实按你架构约束用Zustand管理状态后半段就开始自己发挥给你引入Redux Toolkit。你问它为什么它说“这是更常见的做法”。那一刻你就懂了它不是记忆差而是压根没有把你的项目规范当成硬约束。第四个场景更隐蔽叫“代码所有权转移”。当AI生成大量代码后开发者对代码的理解程度会明显下降。我见过不止一个同事面对AI生成的代码改一个参数要试半天因为他不理解这段代码的结构。这其实是“越帮越忙”最可怕的后果——代码在仓库里但你的团队已经没有能力维护它了。1.2 为什么通用大模型“不靠谱”要理解这些问题得先搞清楚大模型生成的本质是什么。说白了大模型做的事情是“根据已有文本预测下一个最可能的Token”。它见过天文数字级别的开源代码知道“一段React组件代码通常长什么样”“一个类型定义大概怎么组织”所以它能生成看起来像模像样的代码。但它不知道的是你的业务规则、你的性能底线、你的安全红线、你上周刚在评审会上拍板的架构方案。这些信息不在它脑中也不在标准Prompt里。于是它就会基于通用的“平均经验”来做预测产出一份“看起来合理”但“在你的项目里不合理”的代码。打个比方。让一个读过一万本菜谱、但从没进过你家厨房的厨师做菜。他脑海中有一套“标准做法”但他不知道你家酱油是咸口的还是甜口的、灶台火力是大是小、你老婆不吃香菜。他做得再熟练端上来的菜也大概率不合你的口味。AI编程工具面临的困境一模一样——它懂代码但不懂“你的代码”。1.3 “长上下文”是解药还是安慰剂有人会说那我把整个项目塞进上下文不就行了现在很多付费AI编程软件上下文窗口已经从4K、16K涨到了128K甚至200K以上看起来足够装下整个代码库。但实测下来这个思路的效果远没有想象中好。首先是注意力稀释问题。模型在超长上下文里对前面信息和后面信息的关注度是不均匀的。当你塞进几万行代码后模型对“项目规范”这类前置约束的遵循程度会明显下降。你可以把它理解成开长途车——刚出发时还记得导航路线开到第500公里你可能连第一个路口在哪都忘了。其次是成本与延迟问题。上下文越长单次请求的消耗越大、响应越慢。如果你为了“让AI更懂项目”而把仓库所有代码都塞进去结果是钱花了、速度慢了、效果反而更差。长上下文从来不是根本解法。真正有用的是让模型的注意力集中在“高密度、高相关的信息”上而不是“尽可能多的信息”。这就引出了垂直深耕的核心思想。2. 垂直深耕的底层逻辑从“通用助手”到“领域专家”2.1 垂直深耕的三个层次既然通用模型不靠谱、长上下文也是安慰剂那怎么办我的答案是垂直深耕。它不是一个抽象概念而是可以拆成三个具体层次来落地。第一层是场景垂直。团队固定技术栈AI只处理这个技术栈内的问题。比如我们团队是React TypeScript Node.js我就只让AI写这个技术栈内的代码。它不用懂Java、不用懂C、不用懂嵌入式我也不让它写。这就大幅度缩小了模型的“搜索空间”生成结果明显更收敛。第二层是上下文垂直。在仓库里沉淀一份项目级的AI说明文件把架构约束、编码规范、禁止事项都写清楚。AI每次回答前先读这份文件相当于给它做了一次“项目入职培训”。这块我后面会详细讲也是整个垂直深耕落地最关键的抓手。第三层是流程垂直。把AI嵌进“测试先行、小步验收、自动检查”的研发流水线里不给它自由发挥的空间。AI生成代码不是终点而是起点——后续必须跟着静态检查、自动化测试和人工评审。也就是说你要从流程上保证AI的输出是“被校验过的”而不是“直接合入的”。这三层是有顺序的先定场景让AI只在你的主场作战再建上下文让AI懂得你的规矩最后锁流程让AI的错误在合入之前就被拦住。2.2 为什么垂直深耕能解决“越帮越忙”垂直深耕之所以有效背后的机理很简单它让AI从“预测通用代码”变成“预测符合你项目约束的代码”。当一个模型的输出空间被精确约束时它的犯错率会显著下降。打个比方通用AI像是一个什么都修的杂工——通下水道、刷墙、修插座他都能上手但你真要他干某一样时总是不太放心。而一个专职电工虽然只懂强电布线但他在你工地上的每一根线、每一个接线盒的做法你都心里有底。垂直深耕能解决“越帮越忙”还有几个很实际的原因。第一目标对齐。当AI知道你的验收标准时它生成代码的收敛性会好很多。比如你明确要求“不新增依赖”“不出现any类型”它生成时就会主动避开这些红线。第二检查成本下降。因为AI的输出高度可预期你Review时就不需要从头到尾逐行看重点看它有没有遵守已知约束、有没有遗漏边界情况就行了。这比看一幅“灵感之作”舒服太多。第三上下文利用率最大化。垂直深耕不要求你塞进所有代码而是只放“高价值的决策信息”。比如架构方向、禁止事项、测试要求。这些信息密度高、与AI输出质量强相关模型也更容易抓住重点。第四驯化模型。当你用一套固定的规范持续投喂AI模型的输出会逐渐往你的风格靠拢。用久了你会发现它生成的代码越来越像你们团队自己人写的连命名风格都接近了。这才是真正把AI从一个通用工具变成了团队的一员。3. 实操落地三招把AI从“帮倒忙”变成“真提效”理论说再多不如直接给方案。下面三招是我实际用下来最有效的组合拳缺一不可。3.1 第一招建立项目级AI上下文文件这是我认为最最重要的一步也是垂直深耕的地基。目前行业里比较通用的做法是维护一份AGENTS.md文件放在仓库根目录让AI编程工具在每次生成代码前自动读取。不同工具有不同的命名习惯比如CLAUDE.md、.cursorrules、.github/copilot-instructions.md但思路是一样的——把项目的长期约束沉淀成文件让AI每次干活前先“读规矩”。我贴一份我们团队目前用的精简版示例# AGENTS.md ## 项目技术栈 - React 18 TypeScript 5 Vite - 状态管理Zustand禁止引入 Redux - 样式Tailwind CSS禁止 styled-components - 后端Node.js 20 Fastify Prisma ## 架构约束 - 业务逻辑写在 /src/domainUI组件禁止直接调用API - API调用统一走 /src/api/gateway.ts禁止散落 fetch - 所有异步操作必须处理 loading / error / empty 三种状态 - 状态提升优先于引入新依赖 ## 编码规范 - 文件名统一 kebab-case - UI组件使用函数组件禁止 class 组件 - 错误信息统一通过 src/i18n 处理禁止硬编码 - 禁止使用 any如遇未知类型先查源码再定义 ## 测试要求 - 新代码必须包含 Vitest 单测 - 组件测试优先 testing-library禁止测试实现细节 - Mock数据统一放在 __mocks__ 目录 ## 禁止事项 - 不新增状态管理库 - 不生成与现有风格不一致的代码 - 如果某个依赖的接口不确定先查源码或先说明假设不要自己发明接口你可能会问AI真的会遵守这份文件吗实测经验是大部分主流AI编程工具都支持通过项目内文件注入上下文比如Cursor会默认读取.cursorrules而agent类工具会在执行时读取AGENTS.md。只要模型看得见这份文件它对约束的遵循率会从“随缘”变成“大概率”。这份文件的价值在于它把你的团队经验、踩坑记录、架构决策变成了一种AI每次生成代码前都必须“签到”的硬约束。它不需要很长但必须高密度、强指向。越具体越好不要写“代码要清晰”这种废话要写“禁止在组件里直接调用API”这种可以自动检查的红线。3.2 第二招垂直化提示词别再用“帮我写个XX”了有了项目级上下文文件后还需要配合垂直化的提示词。我见过太多人用AI编程时只丢一句话“帮我实现用户列表页。”然后AI就自由发挥了生成什么都是惊喜更多是惊吓。垂直化的提示词不是越长越好而是要包含四个要素角色设定、背景约束、具体任务、验收标准。我平时常用的模板长这样你是这个 React TypeScript Zustand 项目的资深前端开发。 任务实现用户列表页 /users。 背景约束 1. 数据从 src/api/gateway.ts 暴露的 fetchUsers 获取禁止直接写 fetch 2. 使用 Zustand 管理列表状态store 放在 src/stores/userStore.ts 3. 处理 loading、error、empty 三种状态错误提示使用 src/i18n 的 t() 方法 4. 列表项组件单独放在 src/components/user/UserListItem.tsx 5. 每个组件和 store 补 Vitest 单测测试数据 mock 放在 __mocks__/userMock.ts 验收标准 - 不新增任何依赖 - 不出现 any 类型 - 输出格式先列出文件清单再逐个给出完整代码最后给测试要点 - 如果某个接口不确定先说明你的假设不要自己发明接口注意这里的几个设计意图。“角色设定”是让模型切换到专业模式“背景约束”是给它限定边界防止自由发挥“验收标准”是给它自检清单让它在输出时就知道自己要做成什么样“假设声明”是防止AI幻觉出根本不存在的API。还有一个很关键的分工技巧长期约束放AGENTS.md短期任务约束放提示词。比如“禁止用Redux”属于长期约束放AGENTS.md就够了“这次要用Zustand写userStore”属于任务级约束放在提示词里更合适。这样分工提示词不会变得臃肿模型也不容易抓不住重点。3.3 第三招把AI锁进“可验证的流程”里垂直深耕的最后一招是流程设计。我的核心观点是AI生成代码永远只是中间产物绝不能跳过验证直接进主干。所以我把AI的使用流程改成了一个“多级校验漏斗”AI生成阶段先读取AGENTS.md再按提示词生成代码。静态检查阶段CI里自动跑Lint、类型检查、复杂度检查。比如eslint、tsc --noEmit、import-sort检查。这一步能拦住很多低级错误。自动化测试阶段跑单测、组件测试。如果测试挂了直接把失败信息贴回给AI让它自己修。注意这一步不要替代开发者的判断AI修完必须重新跑一遍。人工评审阶段由开发重点审查边界情况、业务逻辑、交互细节。反馈闭环评审意见如果涉及长期问题沉淀回AGENTS.md或规范文档里让AI下一次不会再犯。这套流程看起来多了几个环节实际上是省时间的。因为AI最常见的错误——风格不一致、引入多余依赖、类型错误、边界漏处理——全部能在静态检查和自动化测试环节被拦住不会拖到人工Review阶段。这里还要补充一个非常重要的实操心得让AI做小任务不要让它做“大工程”。很多“越帮越忙”的根源是让AI一口气生成一个完整模块。一旦模块足够大约束就容易失效、错误就容易指数级增加。正确做法是把大功能拆成十几个小任务每个任务提交一次、验收一次。就像装修你不能让工人把水电、木工、油漆一次全干了你得分阶段验收发现问题及时返工整体反而更高效。4. 工具选型与成本付费AI编程软件比如Codex值不值得买说到AI编程绕不开工具选型这个话题。尤其是现在市面上出现了Codex这类付费AI编程软件很多人都在纠结值不值这个钱我用了免费版是不是不够这里我说说自己的真实看法。4.1 免费工具和付费工具差在哪先理清楚差异我用表格对比一下维度免费工具基础版付费AI编程软件如Codex基础模型能力相对较弱更强复杂推理表现更好上下文长度通常较短更长支持更多文件内容Agent能力弱多为单文件补全强可以自主读代码、执行命令、跑测试多文件改动少不敢改全局支持系统性重构集成度依赖IDE插件与仓库、CI、终端深度集成费用免费订阅制通常按月或按量付费这个差异是真实存在的。免费工具在“函数级补全”“单文件生成”这种小场景里已经够用但如果你希望AI自己跑测试、自己修bug、自己协调多个文件的改动那就得上到付费工具了。Codex这类产品的核心卖点就是“agent”——它不只是帮你写东西而是像一个初级工程师那样去操作仓库读代码、找问题、执行命令、看测试结果然后迭代修复。4.2 什么样的人适合付费但我想强调一个容易被忽略的事实付费工具的能力只有在垂直深耕的项目里才能真正发挥出来。为什么因为agent自动跑测试、自动改bug依赖的是项目有清晰的规范和足够的测试覆盖。如果项目一团乱麻没有测试没有文档没有约束规则那agent跑着跑着就迷路了——它不知道该往哪个方向修只能自己发明规则然后“越帮越忙”。所以我的建议是先建立好AGENTS.md、完善测试体系、把代码库整理结构化再考虑付费。顺序千万别反。不然你花了大价钱买工具得到的不是效率提升而是一个可以自动写烂代码的加速器。具体来说适合付费工具的人长这样技术栈相对固定长期在一个领域内开发项目有自动化测试且测试覆盖度比较好团队有明确编码规范和架构约束并且已经主动沉淀到文档里工作内容包含较多“多文件重构”“跨模块改动”的活儿反过来如果你还在拿AI生成一次性脚本或者项目本身没有任何约束那你先用免费版就够了。付费工具的钱砸下去大概率赚不回来。4.3 我的经验垂直深耕反而能省钱这里分享一个我实际感受到的细节垂直深耕不仅能提升效果还能降低使用成本。AI编程软件不管是按订阅还是按Token计费成本都和上下文长度强相关。如果你在提示词里塞进一堆和当前任务无关的仓库代码、历史聊天记录那就是真金白银在烧钱。而垂直深耕项目AGENTS.md 短小精悍提示词直奔任务上下文占用少、有效信息密度高。效果更好费用反而更低。我实测下来把提示词精简、规范下放文件之后同一个功能的生成成本大约下降了30%—40%生成质量还更稳定了。所以别迷信“更贵的工具更好”先把你手上的工具用垂直比什么都强。5. 常见问题与排查技巧实录最后这一章我把实操过程中高频踩坑的问题整理成了一张速查表每个问题都附上排查思路和解决建议你可以直接当成手册用。问题现象排查思路解法AI不遵守项目规范又引入了Redux、又用class组件检查AGENTS.md是否存在、是否被工具读取规范文件放仓库根目录并在提示词里显式说“先读取AGENTS.md”AI生成假接口调用了不存在的API方法看报错信息里的来源定位在提示词里声明“接口不确定先假设”并在项目上下文里补上关键接口定义上下文太长反而忘事生成到一半开始偏离约束检查塞给AI的内容量是不是过大按需精简上下文只放当前任务相关文件生成代码风格不统一一半kebab-case一半camelCase检查规范文件是否覆盖命名规则在AGENTS.md里写死命名规则并加静态检查工具AI的测试是“假测试”断言恒真、没Mock、快乐路径看测试文件里有没有覆盖失败场景在提示词里明确要求“测试必须包含失败路径断言”AI自行修改无关文件一个任务改动了十几个文件检查任务拆得是不是太大拆小任务每次只让AI改一个模块用Git diff做隔离AI陷入死循环改不对修了3次还是同一个错检查是不是上下文里没有报错详情把完整报错、堆栈、测试失败信息直接贴回提示词里代码评审变成AI代码审核Reviewer变成翻译机检查是不是缺少人工逻辑判断环节恢复人工评审重点看边界情况和业务逻辑不要只看语法挑两个最常见的多说几句。第一AI不遵守项目规范。很多时候不是它不想遵守而是它根本不知道有这份规范。所以第一步永远是检查AGENTS.md在不在、有没有被工具读取。如果你用的是Cursor注意看看是否正确识别了.cursorrules如果用的是agent类工具可以在提示词开头加一句“先阅读根目录的AGENTS.md再回答问题”。实测这样做之后规范遵循率能提升一大截。第二AI陷入死循环改不对。这种情况通常是信息闭环断了。你只告诉AI“这里有问题”但没告诉它具体是什么问题。正确做法是把报错信息、测试输出、相关代码片段原样贴进去让AI有足够信息做判断。这就像你让一个远程同事修bug只发一句“系统崩了”那他只能瞎猜。你给他完整堆栈他才能对症下药。我个人在实际操作中的体会是AI编程最危险的地方不是它把代码写错而是它让你误以为自己懂了。当代码不是自己写的理解成本就悄悄地转移到了你身上。垂直深耕这套方法本质上不是给AI画圈而是给你自己的工作建立边界——把AI限定在你的主场上让它的每一次输出都可预期、可验证、可维护。做到这一步你才能真正从“越帮越忙”里走出来体会到什么叫“如虎添翼”。如果你正在被AI生成的烂摊子折磨别急着换工具、换模型。先回去看看你的项目有没有规范的上下文文件有没有明确的验收标准有没有用流程把AI的产出约束住。这三件事做到位了AI编程才真正开始为你工作。