企业官网建设流程全解析

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的功劳——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的时候，我参考了日常工作流里"新同事接到一个页面需求"时的处理顺序，把流程编排成下面六步：

1. 理解需求：把产品需求文档拆解出页面元素、交互逻辑、接口依赖。
2. 查询规范：从Skill库中读取项目的组件规范、目录约定、命名规范。
3. 生成类型与接口层：根据后端接口文档生成TypeScript类型定义和API方法。
4. 生成页面主体：基于项目模板生成表格列、表单域、筛选区配置。
5. 自审清单：Agent逐项检查自己是否遵守了组件规范、是否用了统一的请求封装、是否正确处理了loading和错误态。
6. 输出交付说明：列出所有假设、未覆盖的场景、需要人工确认的点。

这个流程很有讲究。其中第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并不是所有场景都好用。我给它划了明显的边界：只适合"模式化、有明确模板"的页面；对于涉及复杂交互、需要深度产品判断的页面（比如订单流程图、数据大屏），我们还是坚持人写。另外，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的好教练"——知道怎么给它上下文，知道怎么验收它的产出，知道什么时候该让它下场、什么时候该自己上。做到了这几点，编程助手才是真正的翅膀，而不是又一个花里胡哨的玩具。