1. 先给编程助手定个性它成不了架构师但能当个不错的高级码农1.1 那些越用越累的人问题出在哪最近这段时间团队里聊得最多的技术话题就是编程助手。有人把它夸成一个人顶一个团队也有人试用两周后默默卸载留下一句生成的代码看着挺像回事一跑就废。这两种极端我都见过而且说实话问题的根源不在AI工具本身而在大部分人还没找到正确的使用姿势。这篇文章不聊理论直接讲我自己带团队过程中真实发生的两个案例一个是用AI辅助生成功能测试用例把回归测试时间压掉了六成另一个是前端项目里用自定义Skill和Agent把重复组件开发从两天压缩到三小时。我先描述一个很常见的画面。团队里有人兴奋地装上编程助手把需求文档直接甩进去敲一句帮我实现这个功能然后等着AI吐出一大段代码。粘贴进项目编译报错来回改几轮最后发现AI生成的方案跟项目现有的架构风格完全不搭甚至引用了项目里根本不存在的依赖。折腾半天比手写还慢。我观察下来这类越用越累的用户几乎都有同样的三个毛病把AI当搜索引擎用。让AI写一个登录功能得到的是一段通用示例完全不理解项目里已有的权限框架、拦截器、统一返回结构。不提供约束条件。没有告诉AI这个模块不能用XX框架接口文档版本是v2兼容性要求是Chrome 90以上AI只能猜猜出来的东西当然不能用。不做产出验收。AI给什么就签收什么代码能编译就认为大功告成业务逻辑对不对、边界条件全不全完全不关心。这三个毛病的共同本质是把AI辅助编程理解成了外包开发——把需求扔过去期待成品。但实际AI辅助编程的工作方式更接近结对编程你出上下文、出判断、出验收标准AI出初稿、出枚举、出对比方案。谁负责上下文和验收谁就掌握了主动权这两件事如果都交给AI结果必然失控。1.2 我给团队定的三条使用原则在分享两个案例之前我先把这一年多实践下来沉淀的三条原则摆出来后面所有案例都是围绕这三条展开的你先记住它们后面会反复验证。原则一AI只能在你已理解的领域内帮你提效。你自己都说不清需求边界、不知道成功标准是什么那AI一定帮你写不出来。它擅长的是把表达清楚的需求快速翻译成质量合格的代码而不是替你做需求分析。原则二上下文的质量直接决定产出的可用率。同样一个编程助手给帮我写个接口和给这段代码基于Spring Boot 2.7遵守公司Result封装入参需要校验……得到的完全是两个档次的结果。喂给AI的上下文越接近一个靠谱同事接手前需要知道的全部信息产出质量越高。原则三AI产出必须进入评审流程而且标准不能放宽。我们团队对AI生成的代码执行和人工代码完全一致的Code Review标准。这不是不信任AI而是如果不建立验收习惯AI的一本正经胡说八道就会慢慢腐蚀代码质量。这三条原则听起来简单但落地时能坚持住的人不多。下面两个案例就是用实际行动验证这三条原则的过程。2. 案例一遗留订单服务的测试用例生成回归时间压掉六成2.1 项目痛点30个接口、三年历史、覆盖率不到四成第一个案例是一个典型的遗留订单服务。这个服务是公司电商业务的核心模块之一经过三年迭代积累了30多个对外接口业务规则极其复杂——订单状态机有七八种状态、十几种合法流转优惠计算涉及满减、折扣、会员价叠加库存扣减有预占、确认、释放三个动作还牵涉到超时自动取消等多张定时任务。这个服务最让人头疼的事情是回归测试。每两周一个迭代几乎每个迭代都会动到订单相关的代码而功能测试用例是早期业务同学手工整理的覆盖严重不足。我做过一次统计当时核心接口的自动化用例覆盖率不到四成很多分支——特别是异常分支——完全是盲区。测试同学加班补用例补到崩溃但效果依然有限线上还是时不时冒出优惠叠加计算错误订单状态流转异常这类低级问题。一开始我们的做法很原始让测试同学把接口文档和需求文档整理好逐条手写测试用例。但30个接口、平均每个接口几十个用例这个工作量根本排不过来按当时的节奏至少需要三周才能补齐。这种情况下我们决定试试用编程助手来生成测试用例——这才有了后面这套方法论。2.2 从帮我写用例到先读懂业务再看代码的提示词演进刚开始试AI辅助的时候我们也走过弯路。测试同学直接在对话框里输入帮我给订单创建接口写测试用例AI输出的内容看着很全面——正常的创建、参数缺省、类型错误、超长字符串……但仔细一看全是最基础的参数校验用例根本没有触及业务核心。因为AI对订单创建背后真正的业务规则一无所知。后来我调整了策略把AI当刚接手的新同事来培训分三步喂上下文。第一步喂业务规则。我把订单状态机定义、优惠计算规则、库存扣减流程整理成结构化的业务描述明确告诉AI哪些规则必须有正向用例、哪些必须设计异常用例。这一步是核心中的核心——AI只有理解了业务规则才知道用例要验什么。第二步喂接口契约。把接口的请求参数、响应结构、错误码定义喂进去重点是让AI知道每个参数的校验规则和业务含义而不是普通的是否必填。第三步喂历史缺陷。我筛出了过去一年这个服务发生过的30个真实线上bug按模块分类后告诉AI这个接口曾经出现过优惠叠加时折扣重复计算的问题请设计针对该问题的回归用例。这一步效果出奇地好AI能根据历史bug自动补齐很多我们潜意识里忽略的边界场景。下面是我当时实际用过的一个提示词模板精简版你可以对照自己的项目调整你是这个电商订单服务的资深测试架构师。你非常熟悉以下业务规则 1. 订单状态机待支付 - 已支付 - 已发货 - 已完成待支付可取消已支付不可直接取消需走退款流程。 2. 优惠计算满减与折扣不可叠加会员价优先于满减优惠金额不能超过订单总额的50%。 现在请为 createOrder 接口设计功能测试用例。接口契约见附录。请输出 - 用例编号、用例名称、前置条件、测试步骤、预期结果 - 必须覆盖状态机合法流转、非法流转、优惠边界满减临界值、折扣下溢、历史bug回归场景附缺陷清单 - 不要写与业务无关的通用参数校验用例除非它会影响业务正确性对比一下同一份接口文档没有业务上下文时AI生成的用例里业务相关用例占比不到20%有了上面的上下文之后业务相关用例占比直接到了75%以上而且很多用例的设计思路是我们人工整理时容易漏掉的。2.3 实测效果工作量、覆盖率、漏测数三维对比这个案例跑完一个迭代之后我让测试同学按三个维度做了对比数据非常直观对比维度纯手工方式AI辅助方式变化核心用例编写时间约3周约3.5天缩短约77%核心接口用例覆盖率不足40%约83%提升一倍以上当次回归漏测数迭代上线后两周内平均4~6个1个下降明显线上缺陷数平均2~3个/迭代1个以内明显下降这里要说明一下覆盖率提升并不完全是AI的功劳——AI辅助之后测试同学在用例评审上花的时间明显变多了但同样的人力投入下产出质量和覆盖度完全不在一个量级。AI最大的价值不是替代人写用例而是把用例设计的初稿成本降到了极低让人可以把精力花在评审、补漏和判断上这才是我理解中AI辅助的正确打开方式。2.4 这个案例里踩过的坑案例虽然成功但过程中踩过几个值得单独说说的坑都是真金白银换来的经验。第一个坑AI会编造业务规则。有一次AI生成的用例里出现了订单支付成功后自动进入已发货状态这样的用例看起来逻辑通顺但实际上这个业务里支付成功后还要经过风控审核审核不通过会进入退款流程。AI为什么会编因为它在训练数据里见过太多简化版电商状态机就默认套用了。解决办法也很直白所有AI生成的业务规则类用例必须回到真实业务文档里逐条核对。我把这条直接写进了团队规范。第二个坑上下文喂得太多也会坏事。业务规则文档、接口文档、历史缺陷一次性全塞进去AI经常会在回答中段开始丢失早期指令生成到后面的用例时已经忘了前面状态机的约束。我的处理办法是拆分成多次对话一次一个主题先对话设计状态机用例再对话设计优惠用例最后再汇总去重。单次对话的上下文越聚焦AI的专注度越高。第三个坑AI生成的用例有一个通病——不在乎重复。它会把同一个场景用不同的方式描述好几遍用例集合看起来非常多实际去重后水分不小。建议在流程中加入AI生成初稿 - 人去重 - 人补充 - AI复核查漏的循环而不是直接拿AI的初稿入库。3. 案例二前端中后台的Skill与Agent实战重复组件开发从两天到三小时3.1 为什么通用聊天模式解决不了中后台开发的重复劳动第二个案例来自前端团队。我们的前端同学负责一个典型的中后台管理系统什么概念就是一堆表单页、列表页、弹窗页、详情页长得都差不多顶部筛选区、中间表格、右侧操作按钮、底部或者抽屉里的表单。这类系统的高频痛点不是技术难度而是重复劳动太多了。举个例子一个标准的用户管理页从需求评审完成到能联调我们的前端同学通常需要两天。其中真正花时间的不是实现本身而是一堆固定动作根据后端接口文档生成TypeScript类型定义、封装API请求方法、写表格列配置、写表单校验规则、处理loading状态、处理错误提示、写空数据占位……每一步都不难但每一步都要重复而且不同页面的写法还不完全统一老代码里的惯例新人根本不知道。一开始我们尝试用通用聊天的方式来加速让AI帮我写一个带搜索、分页、新增、编辑、删除的用户管理列表页。AI确实能生成一版看起来完整的页面但问题很快就暴露了它生成的是理想的通用中后台页面而不是我们这个项目里的中后台页面。我们项目有自己的组件库二次封装过Ant Design有统一的请求封装axios实例里内置了token刷新、错误提示、权限判断有约定好的目录结构有eslint和stylelint规范……这些项目私有的知识通用对话里的AI一概不知。所以输出的代码看起来能用实际上到处都是错位组件引用的是原始的antd而不是我们封装的ProSearch请求用的是裸axios而没有走项目统一的request实例目录结构不符合团队约定。改这些错位的成本比手写还高。这个经历让我意识到想让AI辅助在真实项目里落地光靠通用对话是不够的必须把项目私有知识结构化地喂给它——这就是Skill和Agent的用武之地。3.2 我自建的页面开发Agent角色设定、流程编排与Skill挂载被通用聊天模式折磨了两周之后我决定换一条路不再和AI闲聊而是给AI编程助手配置一个自定义Agent专门负责中后台页面开发同时把项目里所有私有知识通过Skill挂载给它。设计这个Agent的时候我参考了日常工作流里新同事接到一个页面需求时的处理顺序把流程编排成下面六步理解需求把产品需求文档拆解出页面元素、交互逻辑、接口依赖。查询规范从Skill库中读取项目的组件规范、目录约定、命名规范。生成类型与接口层根据后端接口文档生成TypeScript类型定义和API方法。生成页面主体基于项目模板生成表格列、表单域、筛选区配置。自审清单Agent逐项检查自己是否遵守了组件规范、是否用了统一的请求封装、是否正确处理了loading和错误态。输出交付说明列出所有假设、未覆盖的场景、需要人工确认的点。这个流程很有讲究。其中第2步和第5步是我特别设计的。第2步的意义是让AI先查规范再动手相当于给新人一本入职手册第5步的意义是让AI交付前先自查大大减少了我在Code Review时挑出低级问题的概率。角色设定词system prompt的精华部分大致长这样你是中后台页面开发专家服务于XX管理系统的前端开发。你的工作准则是 1. 所有组件引用必须使用项目封装的Pro系列组件禁止直接引用antd原生组件。 2. 所有接口请求必须走 /utils/request 中导出的 request 方法禁止直接使用 axios。 3. TypeScript 类型定义必须放在 src/types/api/ 对应模块文件中并遵循后端接口字段命名。 4. 页面结构必须遵循 src/views/模块名/页面名/index.vue components/ 的目录约定。 5. 生成代码前必须阅读 Skill 库中的组件规范文档和命名规范文档。 6. 交付前必须逐项对照自审清单并在交付说明中列出未覆盖项。Skill库我挂载了三个一个是组件规范ProSearch、ProTable、ProDrawerForm等组件的props用法和最佳实践一个是接口层规范request封装的能力清单、错误码处理约定还有一个是页面模板一个标准的列表页表单页的完整代码模板。挂载之后AI在生成代码前的知识准备就完整了不会再出现引用错误组件、绕过请求封装这种低级问题。3.3 效果对比与适用边界这个Agent在前端团队跑了一个多月覆盖了6个迭代里的20多个页面效果是实打实的对比维度纯手工开发Agent辅助开发变化标准列表页开发时间约2天约3~4小时缩短约80%Code Review问题数平均8~10个/页平均2~3个/页大幅下降页面风格一致性依赖开发同学自觉模板保障基本统一明显提升新人上手成本需要一周熟悉项目半天可产出合格页面显著降低说句公道话这个Agent并不是所有场景都好用。我给它划了明显的边界只适合模式化、有明确模板的页面对于涉及复杂交互、需要深度产品判断的页面比如订单流程图、数据大屏我们还是坚持人写。另外Agent生成的代码在Code Review时依然会发现一些隐藏问题比如列表页有批量操作而模板里没加字段多语言漏配这类依赖具体业务判断的遗漏。所以它把我从写重复代码里解放了出来但没把我从审代码里解放出来——这恰恰是我想要的效果。4. 两个案例背后共同的规律上下文工程决定AI产出质量4.1 三份上下文业务上下文、代码上下文、约束上下文两个案例放在一起看你会发现核心逻辑惊人一致AI的产出质量几乎完全由你喂给它的上下文决定。我把这一年多实践下来认为最重要的上下文归成三类你可以对照检查自己的使用习惯。第一类是业务上下文。对应案例一里的业务规则、案例二里的页面需求拆解。AI需要知道这段代码要实现的业务规则是什么、有哪些边界条件、哪些分支必须处理。业务上下文缺失时AI会默认套用最常见情况的实现这在通用场景够了但一到业务复杂的系统里就会翻车。怎么喂不是把几十页需求文档整个塞进去而是自己先把文档读一遍提炼出关键规则再用结构化的方式告诉AI。第二类是代码上下文。对应案例一里的接口契约、案例二里的组件规范和请求封装。AI需要知道这个项目里同类代码是怎么组织的、有哪些既定的抽象和封装、什么写法是被允许的。代码上下文缺失时AI写出来的代码从语法到风格都和项目完全脱节。这类上下文最好通过Skill挂载而不是每次都手动粘贴——否则每个人的使用效果方差会大得惊人。第三类是约束上下文。包括技术栈版本、兼容性要求、禁止使用的依赖、性能约束、代码风格要求等。这一类最容易被人忽略但恰恰是AI最容易犯错的领域——它不知道你项目的Ant Design版本、不知道你们的目录结构约定对这些项目私有知识必须明确喂给它。约束上下文写得越明确AI踩雷的概率越低。4.2 AI产出的四级验收清单聊完输入再聊输出。AI生成的代码怎么验收我总结了一个四级验收清单团队成员照着这个清单做评审基本能避免AI生成代码带崩项目的惨剧。第一级工程验收。代码能不能编译依赖是不是都存在类型定义是否完整eslint是否通过这一级是底线AI生成的代码经常在这里出问题但修起来也最容易。我的习惯是让AI生成完之后先自己跑一遍构建报错先自己修减少人工来回改的时间。第二级逻辑验收。核心业务逻辑是否符合需求文档分支处理是否完整边界条件是否考虑这一级需要人真正读懂AI生成的关键代码不能只看看起来没问题。第三级项目规范验收。是否使用了项目统一的封装是否符合团队约定是否与周边代码风格一致这一级最容易被忽视但直接影响代码的可维护性。如果前面Skill挂载做得好这一级的问题会大幅减少。第四级架构验收。这个功能放在这个模块里是否合适是否有复用现有抽象而不是重新造轮子改动是否会影响其他模块这一级依赖对系统全局的理解我目前看到的AI还做不了。我的经验是第一二级AI完成度很高人只需要快速检查第三级依靠Skill和规范文档的完善程度第四级必须由人来严格把关绝对不能交给AI判断。这四级验收清单不是我拍脑袋想出来的是踩了好几次坑之后发现AI代码泄漏到线上的案例几乎都栽在第三四级上。4.3 什么场景坚决不用AI写了很多怎么用好AI也得说说什么时候别用AI这部分同样来自真实教训而且是很多人忽略的反向视角。第一种场景你自己没想清楚需求的时候。如果你自己都说不清这个功能要解决什么问题、有哪些边界条件AI给再多代码都没用反而会用看起来完整的实现掩盖需求本身的空洞。这种情况应该先做需求分析而不是打开编程助手。第二种场景对现有代码完全不熟悉的时候。如果你刚接手一个模块对它的架构、约定、依赖关系都还一头雾水这时候让AI生成代码就是给后续埋雷。正确做法是先花时间理解现有代码有了基本盘再让AI介入。这一点对新同事尤其重要——我见过太多新人一上来就用AI生成代码结果写出来的东西和模块格格不入反而拖慢了上手速度。第三种场景安全敏感代码。登录鉴权、支付回调、权限判断这类代码我坚持不交给AI生成。不是AI一定写不对而是这类代码一旦出错代价极高而且AI生成的安全代码经常存在看起来对但实际有漏洞的问题人工审查的成本甚至高于手写。5. 团队推广阶段我踩过的坑和最终沉淀的规范5.1 试点项目的选择逻辑两个案例跑通之后团队里不少同事开始主动问这个怎么用的。我把AI编程助手推给整个研发团队的时候特意选了一个试点项目而不是全员铺开。试点项目我选了业务规则清晰、成员意愿高、能快速看到效果的中后台管理系统原因有三个第一效果容易量化。页面开发时间、Code Review问题数这些都是现成的指标不需要额外埋点推广时最有说服力。第二风险可控。中后台页面即使AI生成代码有瑕疵修复成本低不影响核心链路。第三团队已经有了案例二里的Agent和Skill积累试点等于把已有的资产规模化使用而不是从零开始教大家什么叫上下文工程。试点跑了一个月我收集了一组真实数据参与试点的5个前端同学的AI辅助代码占比平均达到63%自评工作效率提升在40%~60%之间。更重要的是没有再出现用了AI之后代码质量下降的抱怨——因为试点成员都经过了一对一的提示词培训知道怎么给AI喂上下文。这个前期投入我认为非常值与其让全员低水平地瞎用不如让一小部分人先掌握正确的打开方式再以点带面。5.2 沉淀团队级提示词库和Skill库试点成功之后我做的第一件事不是扩大使用范围而是把实验性的提示词和Skill固化成团队资产。我们建了一个团队空间按类型维护了几类东西场景提示词模板测试用例生成、页面开发、接口对接、SQL编写、日志分析每种场景一团沉淀了经过验证的提示词结构和上下文清单。新同事来了不用自己摸索直接拿模板套。Skill库组件规范、接口层规范、页面模板、代码风格、常见业务规则文档全部以Skill形式挂载新同事入职后直接激活上手速度比看文档快得多。案例库每次踩坑之后我会把AI犯过的典型错误正确的上下文喂法写成小案例放进去相当于团队自己的AI使用避坑指南。这套资产跑起来之后有一个意外收获团队对上下文工程的理解明显加深了。以前大家觉得AI辅助就是对话框里聊天现在他们会主动想我这个需求要配什么上下文才能得到好结果这个思维方式的变化比学会某个具体技巧重要得多。同时我也立了一条规矩AI生成的代码进入代码库之前必须经过和人工代码一模一样的评审流程这条规矩至今没有松动过。5.3 一点个人体会最后说点我个人这一年多来的感受算是给同样在探索AI辅助编程的同行一个参考。AI编程助手给我的最大启发不是它让写代码变得多快而是它逼着我重新思考了研发提效到底提的是什么。以前提效靠加班、靠优化流程、靠人海战术现在多了一个杠杆——但杠杆撬动的前提是你自己得有清晰的业务理解、规范意识和评审标准。AI把从0到1的初稿成本打到了极低但从1到100的精度和正确性依然要人把关。所以我对团队的期待不是人人都会用AI写代码而是每个人都能成为AI的好教练——知道怎么给它上下文知道怎么验收它的产出知道什么时候该让它下场、什么时候该自己上。做到了这几点编程助手才是真正的翅膀而不是又一个花里胡哨的玩具。