1. 项目概述当AI成为你的全栈搭档最近我接到了一个紧急需求为一家小型商贸公司开发一套轻量级的进销存管理系统。时间紧任务重传统的开发模式显然来不及。于是我决定尝试一个全新的工作流全程使用AI助手WorkBuddy作为我的核心开发搭档挑战在10天内完成从需求分析到部署上线的全过程。这不是一个简单的“让AI写代码”的实验而是一次深度的人机协作探索看看在一位经验丰富的开发者主导下AI工具究竟能将效率提升到何种程度又会遇到哪些意想不到的“坑”。WorkBuddy并非一个简单的代码生成器它是一个集成了大语言模型能力的智能工作台能够理解复杂的上下文、执行多步骤任务、调用外部工具如代码解释器、文件系统并保持对话的连贯性。它更像是一个不知疲倦、知识渊博的初级开发伙伴。这次实战的目标很明确利用WorkBuddy快速完成一个包含商品管理、采购入库、销售出库、库存盘点、基础报表等核心功能的Web应用。最终我们不仅按时交付了可用的软件更沉淀出一套高效的人机协作方法论。如果你也面临快速原型开发、个人项目或者希望大幅提升编码效率那么这次“实录”中的每一个决策、每一次对话和每一个踩过的坑都值得你仔细琢磨。2. 核心思路与工具选型为什么是WorkBuddy轻量技术栈在项目启动前技术选型是决定成败的第一步。面对10天的极限工期任何重型的、需要复杂配置的框架都是奢侈品。我的核心思路是最大化利用AI的生成与推理能力最小化环境配置与底层架构的复杂度。因此选型必须满足几个条件1) 技术栈流行AI训练数据充足生成代码准确率高2) 架构简单能快速本地运行和部署3) 前后端分离清晰便于分工和AI理解。2.1 后端技术栈Spring Boot MyBatis-Plus H2 Database我选择了Java系的Spring Boot作为后端。原因有三首先Spring Boot是Java领域事实上的标准社区资源、教程和AI训练数据都海量这意味着WorkBuddy对Spring Boot的语法、常见问题解决方案“见识”最广生成代码的可用性最高。其次它的“约定大于配置”理念能帮我们省去大量XML和繁琐设置一个SpringBootApplication注解就能启动一个Web服务。最后搭配MyBatis-Plus这个强大的ORM工具单表CRUD操作几乎不用手写SQL通过它的代码生成器和条件构造器配合AI能飞速完成数据层开发。数据库方面为了极致简化部署在开发阶段我选择了H2内存数据库。它无需安装随应用启动和关闭特别适合原型开发和测试。WorkBuddy可以轻松编写出操作H2的SQL语句和配置。等到部署时只需修改几行配置就能平滑迁移到MySQL或PostgreSQL。注意选择AI“熟悉”的技术栈至关重要。如果你用一个非常小众的框架WorkBuddy很可能生成错误百出或过时的代码调试时间反而更长。Spring Boot和Vue是当前AI代码生成准确率的“安全区”。2.2 前端技术栈Vue 3 Element Plus Axios前端选择Vue 3而非React主要是出于开发速度的考虑。Vue的单文件组件.vue结构将模板、脚本和样式封装在一起对于AI来说这是一个非常清晰、易于理解和生成的单元。我可以通过指令让WorkBuddy“生成一个包含表单表格的.vue文件”它能够一次性输出结构完整、样式可用的组件。相比之下React的JSX和逻辑分散性对AI生成的整体性略有挑战。UI库选用Element Plus这是基于Vue 3的知名组件库。它的组件丰富、文档详尽AI在生成使用Element Plus的代码时参考的范例极多不容易出错。Axios用于处理HTTP请求这是一个简单直接的选择。2.3 WorkBuddy的角色与协作模式定位在整个项目中我没有把WorkBuddy当作一个“许愿机”输入“做一个进销存系统”就等待奇迹。相反我把它定位为超级搜索引擎代码片段生成器当我忘记某个注解的具体用法或MyBatis-Plus某个API的签名时直接提问比翻文档快得多。初级程序员负责实现我详细描述的具体功能模块比如“编写一个Service类实现根据商品名称模糊查询并分页”。代码审查员我将写好的代码片段丢给它让它检查潜在的错误、性能问题或代码风格建议。问题调试助手当遇到运行时错误将异常日志贴给它让它分析可能的原因和解决方案。这种“我主导架构和设计它负责填充细节和执行”的模式是效率最大化的关键。我始终掌握着方向盘而WorkBuddy是动力强劲的引擎。3. 实战开发全流程拆解与AI并肩作战的十天这十天是高度浓缩的冲刺。我将过程分为四个主要阶段每天都有明确的目标和交付物。3.1 第1-2天需求细化与项目骨架搭建这两天看似不写代码却决定了后续是否顺利。我的主要工作是和客户沟通将模糊的需求转化为AI能理解的精确指令。第一步用自然语言编写“产品需求文档PRD”我没有画复杂的UML图而是用Markdown写了一份简单的PRD直接作为与WorkBuddy沟通的基线文档。内容如下# 进销存系统PRD ## 核心模块 1. 商品管理商品信息编号、名称、规格、单位、成本价、零售价的增删改查。 2. 采购入库创建采购单关联供应商简易、商品、数量、单价、总金额审核后增加库存。 3. 销售出库创建销售单关联客户简易、商品、数量、单价、总金额审核后减少库存。 4. 库存管理查看当前库存列表商品、数量、成本总额进行库存盘点修正数量。 5. 报表中心销售毛利日报按日汇总销售额、成本、毛利。 ## 业务规则 - 库存数量不能为负销售出库时校验。 - 采购/销售单有“草稿”、“已审核”、“已完成”状态。 - 审核操作才触发库存变动。然后我将这份PRD发给WorkBuddy并给出指令“基于以上需求请为我设计一个简单的后端数据库表结构列出主要实体和字段并说明表间关系。”第二步基于AI设计生成数据库DDLWorkBuddy很快给出了包含product商品、purchase_order采购单、purchase_item采购明细、sale_order销售单、sale_item销售明细、inventory库存等核心表的ER图描述和建表SQL。我在此基础上进行了微调例如为所有表增加了create_time和update_time字段。接着我利用MyBatis-Plus的代码生成器功能。我手动编写了生成器的配置类这是需要精确控制的然后让WorkBuddy根据我提供的表名列表帮我补全生成Entity、Mapper、Service、Controller层代码的详细命令和配置。命令执行后基础的数据访问层代码就全部生成了。第三步初始化前后端项目后端通过Spring Initializrstart.spring.io生成一个基础的Spring Boot项目依赖选择Web, MyBatis, H2。将上一步生成的代码放入对应包。 前端使用Vite脚手架快速创建一个Vue 3项目并安装Element Plus和Axios。 这些初始化工作我手动完成因为涉及项目结构和构建工具手动操作更可靠。之后我将创建好的项目整体目录树粘贴给WorkBuddy让它对项目结构有一个全局认知方便后续在正确的路径下生成代码。3.2 第3-5天核心业务逻辑实现这是与WorkBuddy对话最密集的阶段。我采取“分模块击破”的策略。以“采购入库”模块为例我与WorkBuddy的协作流程如下我发出详细指令“现在需要实现采购入库的API。请先为PurchaseOrderController编写一个创建采购单的接口/api/purchase/create。请求体应包含supplierName供应商名、remark备注和一个items列表列表中每个对象有productId,quantity,unitPrice。需要校验商品是否存在并计算每个明细项的总价(quantity * unitPrice)和订单总金额。数据保存到purchase_order和purchase_item表初始状态为‘草稿’。请给出完整的Controller方法代码并提示我还需要哪些Service方法。”WorkBuddy生成代码它会生成一个带有PostMapping注解的Controller方法里面包含了参数校验使用Valid、业务逻辑调用。同时它会说“您还需要在PurchaseOrderService中实现一个createPurchaseOrder方法以及在PurchaseItemService中实现批量插入的方法。此外需要创建一个PurchaseCreateDTO来接收前端参数。”我进行审查和填充我会仔细检查生成的代码。例如我发现它可能漏掉了事务注解Transactional我会让它加上。或者它生成的DTO字段类型不对我会纠正。然后我会说“好的现在请根据你刚才的提示为我实现这个PurchaseOrderService.createPurchaseOrder方法的具体逻辑包括你提到的商品存在性校验和总价计算。”迭代与细化就这样我一个方法一个方法地“喂”指令WorkBuddy一段代码一段代码地“吐”实现。对于复杂的业务逻辑如“审核采购单并更新库存”我会拆解成更小的步骤“第一步根据订单ID查询订单和明细第二步校验状态是否为‘草稿’第三步遍历明细调用库存服务增加对应商品的库存数量第四步更新订单状态为‘已审核’。” WorkBuddy能很好地理解这种顺序逻辑并生成相应代码。实操心得给AI的指令必须具体、原子化、无歧义。说“实现采购功能”它会茫然说“编写一个POST接口路径是…接收JSON包含…需要做…校验然后调用…服务保存”它就能精准执行。把自己想象成一个严格的Tech Lead在给实习生分配明确到函数级别的任务。3.3 第6-7天前端页面与交互对接后端API基本完成后前端工作同样可以借助WorkBuddy加速。我的工作模式是我设计页面草图比如商品管理页面顶部是一个带“新增”、“搜索”、“导出”按钮的工具栏下面是一个表格表格有操作列编辑、删除。我对WorkBuddy说“请用Vue 3和Element Plus编写一个ProductManagement.vue组件。页面结构参考我上面的描述。表格需要绑定从后端/api/product/list接口获取的数据字段包括id, name, spec, unitPrice等。搜索框绑定商品名称点击搜索按钮调用接口查询。新增按钮弹出一个表单对话框表单字段包括……。请使用script setup语法和ref进行响应式数据管理。”WorkBuddy会生成一个结构非常完整的vue文件包括模板、脚本、样式。我只需要稍微调整一下样式细节并将API请求的URL替换为我实际的后端地址。对于表单验证、表格分页等常见功能直接要求即可如“为这个新增表单添加规则校验名称必填零售价必须为大于0的数字。”前后端联调启动后端Spring Boot应用和前端的Vite开发服务器。利用浏览器的开发者工具和Postman或类似的API测试工具进行调试。当遇到跨域CORS问题时我直接问WorkBuddy“Spring Boot如何配置全局CORS以允许前端本地开发服务器访问”它会给出标准的WebMvcConfigurer配置代码。3.4 第8-9天测试、调试与优化代码堆砌完了但bug和优化点才是重头戏。单元测试我让WorkBuddy为一些核心的Service方法生成单元测试。指令如“为InventoryService的increaseStock方法编写一个JUnit测试模拟正常增加库存和商品不存在的情况。” 它能生成带有Test注解、使用Mockito模拟依赖的测试类框架我只需填充一些具体的断言逻辑。问题排查实录问题1销售出库时库存扣减出现了并发问题导致库存扣减不正确。排查我将相关的Service方法代码和数据库表结构特别是inventory表贴给WorkBuddy。WorkBuddy分析“您的方法直接在内存中计算了新库存量然后执行updateById。这在并发场景下会导致更新丢失。建议使用乐观锁在inventory表中增加一个version字段更新时使用set stock stock - #{quantity} where id#{id} and stock #{quantity}这种原子操作或者使用version进行乐观锁控制。”解决我采用了它的第一种建议使用MyBatis-Plus的UpdateWrapper进行原子更新并在SQL条件中加入stock quantity的校验确保不会超卖。同时让WorkBuddy帮我重写了扣减库存的方法。性能与代码优化我会将一些复杂的查询语句丢给WorkBuddy问“这个查询有没有优化空间如何添加索引” 或者让它检查N1查询问题。对于前端我会让它检查是否有不必要的重复渲染或推荐更优的组件使用方式。3.5 第10天打包部署与文档编写后端打包使用mvn clean package生成可执行的JAR文件。我提前让WorkBuddy检查了application.properties中关于H2数据库的配置并将其改为生产环境使用的MySQL配置需要提前准备好MySQL的JDBC URL、用户名和密码。前端打包运行npm run build生成静态文件到dist目录。部署为了极致简单我采用了“后端JAR 前端Nginx”的方式。将后端JAR上传到服务器用java -jar命令启动。将前端dist目录下的文件放到Nginx的HTML目录下并配置一个简单的location /api代理将API请求转发到后端Spring Boot应用。最后我让WorkBuddy帮忙生成了一份简洁的用户操作手册和API接口文档基于代码注释生成完成了项目的最后闭环。4. 经验总结、避坑指南与未来展望经过这10天高强度的“人机配对编程”我对AI辅助开发有了更深刻、更务实的认识。它绝非银弹但确实是强大的“力量倍增器”。4.1 WorkBuddy的核心优势与局限优势惊人的代码生成速度对于样板代码CRUD、标准API、基础组件的生成速度是人类的十倍以上。上下文理解能力强在一个对话中它能记住之前讨论过的实体、字段、业务规则后续生成代码时一致性很高。多面手从设计、编码、测试到调试、文档它都能提供有价值的建议减少了在不同工具和网站间切换的成本。不知疲倦可以连续进行高密度的问答随时响应极大保持了开发思路的连贯性。局限与注意事项会“一本正经地胡说八道”这是最大的坑。它可能生成语法正确但逻辑完全错误或引用不存在的类、方法。你必须具备足够的专业知识来审查和验证它输出的每一行代码。不能无脑信任。对复杂业务逻辑的拆解能力有限它擅长实现你拆解好的步骤但不擅长从零开始进行高层架构设计。产品经理的活还是得人来干。知识截止性它的知识库可能不包含最新的框架版本特性或小众库的用法生成代码时可能过时。“幻觉”问题有时它会虚构一些不存在的配置属性或注解参数需要对照官方文档仔细核对。4.2 给开发者的实操建议从小功能开始不要一上来就让它生成整个系统。从一个简单的查询接口、一个表单组件开始熟悉它的“脾气”和指令方式。提供最大化的上下文在提问时尽可能粘贴相关的代码片段、错误信息、配置文件。上下文越丰富它的回答越精准。迭代式交互采用“你生成我审查你修改”的快速迭代循环。不要追求一次生成完美代码。善用“角色扮演”在发出指令前可以设定它的角色如“你现在是一个资深的Spring Boot后端开发专家”有时能提高回答的质量。核心业务逻辑自己把控涉及资金、库存、权限等核心业务规则的关键代码建议自己手写或至少进行极其严格的审查。4.3 未来工作流展望这次实验让我确信AI辅助开发将成为常态。未来的工作流可能演变为架构师/高级开发者负责系统设计、模块拆分和核心算法然后将一个个原子化的、描述清晰的开发任务“派发”给AI助手自己则专注于代码审查、集成测试和性能调优。开发者的核心价值将从“写代码”向“定义问题”、“设计架构”和“质量保障”迁移。回到这个进销存项目它已经稳定运行在小公司的日常业务中。这次经历与其说是我用10天开发了一个软件不如说是我用10天训练了一个高度适配我工作习惯的AI搭档。这个过程本身就是最大的收获。如果你还没尝试过深度使用AI编程我强烈建议你找一个自己的小项目亲自走一遍这个流程你一定会对“开发”这件事产生全新的理解。