1. 这不是标题党Demo繁荣与生产落地的冰火两重天过去这一年AI编程的话题几乎被炒成了显学。打开任何一个技术社区都能看到我用Cline十分钟写了个管理系统Cursor自动撸完了整个前端之类的帖子评论区一片沸腾。我自己也试过坦白说第一次看到AI唰唰唰生成几百行代码的时候确实有一种程序员要失业了的错觉。但当我真正把一个所谓的AI生成项目拿去做生产验证时发现完全不是那么回事——页面能跑、接口能通但一接真实数据、一上并发、一碰权限边界问题就像雨后春笋一样冒出来。这个现象背后藏着一个很现实的行业问题绝大多数AI编程实践停留在了Demo层面距离真实业务系统还有一道巨大的鸿沟。Demo是什么是验证这条路能不能走通的最小化样本。而真实业务系统是什么是承载着用户数据、业务流程、异常处理、权限管控、审计追溯、性能容灾的复杂体。两者之间的差距不是代码量的问题而是思维方式和工程标准的差距。我最近用AI辅助做了一个名叫HomeX的物业管理平台就是在这种撕裂感中走过来的。HomeX要解决的是小区物业管理的数字化问题业主端报修、物业端派单、缴费账单、月卡续费、巡检任务、访客管理等一整套真实业务流程。这个项目一开始的定位就很明确——不要Demo要一个能真正让物业公司拿去上线试运行的系统。正是因为抱着这个目标AI写出来的每一段代码都要经过业务校验、边界测试和代码审查整个过程中踩坑无数也实实在在验证了一件事AI编程的真正价值不在于替你写完整个系统而在于帮你把那些重复性的、模式化的编码工作快速干掉让你把精力集中到AI最不擅长的业务判断和架构决策上。这篇文章我会把HomeX从AI生成骨架到真实业务系统跑通的完整过程拆开讲包括架构设计、提示词工程策略、代码审查机制、以及我在真实部署过程中踩过的那些坑。如果你也在用AI编程做正经项目或者正准备从写Demo迈向做产品这篇文章应该能帮你少走不少弯路。2. 两份代码之间隔着的是真实业务逻辑先说一个很容易被忽视的基本事实AI生成代码的能力并不弱但AI理解业务的能力非常弱。这不是AI的错是我们使用方式的问题。大多数时候我们给AI的输入是帮我写一个报修工单模块它输出的是一个看起来五脏俱全的CRUD代码但你仔细一推敲会发现它缺失了大量真实业务系统必须有的东西——工单状态机的合法性校验呢超时未处理的自动升级机制呢操作审计日志呢并发派单时的数据一致性呢这些都不是AI故意偷懒而是它根本没有足够的上下文来理解报修工单在真实物业场景里到底意味着什么。HomeX这个项目的核心业务可以拆成五个模块业主端App支持报修提交、账单查询、访客邀请、物业工作台工单处理、巡检任务、通知公告、后台管理系统房屋绑定、车位管理、人员权限、支付网关月卡续费、账单缴费、押金管理、以及一个消息中心站内信、短信通知、公众号模板消息。听起来跟市面上大部分SaaS系统差不多对吧但就是这种差不多的系统里面埋着大量只有在真实场景里才会暴露的细节。举个例子光是月卡续费这个看似简单的功能真实业务里就有至少五层逻辑要处理续费金额计算原月卡剩余天数怎么折算、支付通道回调微信/支付宝异步通知的幂等处理、车辆道闸联动续费成功后要实时同步到停车场系统、发票开具状态物业公司是要开票的不是个人开发者那种支付成功就完事的逻辑、以及退款流程用户续错月份了怎么办钱原路退回还要把道闸权限撤销。你让AI裸写一个续费接口它能写吗能写但大概率只能覆盖第一层。这就是Demo与生产系统的本质差距——真实系统的复杂性不在于功能多而在于每个功能背后都挂着一串业务约束和异常分支。另一个典型差异是权限模型。Demo里的权限通常是一个简单的管理员/普通用户角色区分但HomeX作为一个真实业务平台权限至少要覆盖四种角色业主、前台客服、工程维修主管、系统管理员而且权限粒度要精确到操作级别举个例子客服可以创建工单但不能删除工单可以查看缴费记录但不能修改金额可以发起退款但超过五百元需要主管二次审批。这种规则如果靠AI猜它是猜不出来的必须由人来定义清晰后再让AI去实现具体校验逻辑。我在做HomeX的过程中最大的感悟是AI编程能不能落地取决于人能不能把隐性业务知识显性化。你越是能把模糊的需求变成明确的、可验证的规则AI的输出质量就越高。反之你越是把AI当全能助手你看着办它就越会给你一个看起来正确但实际不可用的结果。后来我为团队总结了一套提示词四要素方法论后面会详细讲这里先提一句所有成功的AI编程项目本质上都是人机协作中的人部分做得足够到位AI只是放大镜不是发动机。3. 为什么AI写的代码总在Demo阶段就毕业了我在做HomeX之前做过一个小实验分别让三种主流AI编程工具Cursor类的IDE集成工具、纯对话式大模型、以及带Agent能力的新一代工具独立去实现一个简单的物业管理后台结果很有意思——三个工具都成功跑通了一个看起来能用的Demo但放进真实的业务测试集里跑一遍通过率最高的也只有四成左右。这个实验让我开始认真思考一个问题AI编程到底在哪个环节出了问题导致它总是止步于Demo水平的循环里出不来3.1 缺了上下文AI就只能生成代码而不是实现功能第一层原因是信息断层。AI写代码时你给了它什么上下文它就基于什么输出。但一个真实业务系统的上下文是极其庞大的数据库表结构有几十张表、字段约束散落在各个模块、已有的代码风格惯例、第三方SDK的版本兼容性、甚至公司内部的接口命名规范……这些信息如果不在AI的可见范围内它输出的代码就只能是无根之木。我在HomeX的早期开发中犯过一个典型错误让AI直接生成一个业主缴费账单的数据库模型它给出了一个挺漂亮的表结构但漏掉了两个关键业务字段——账单所属期因为物业费是按月缴的账单必须关联到具体的费用月份和滞纳金状态因为欠费超过十五天要自动计算滞纳金。这两个字段如果后期补需要同步修改至少六处代码逻辑性价比极低。3.2 AI的自信幻觉在业务规则上被无限放大第二层原因是错误模式。大模型生成代码时的自信幻觉在通用编程场景下往往无害因为编译器或运行时很快会暴露错误但在业务规则层面这种幻觉会变成隐性炸弹。最典型的例子就是AI在处理边界条件和异常分支时倾向于乐观简化——支付回调不处理重复通知、文件上传不限制大小、状态流转不校验前置状态、批量操作不做部分失败回滚。这些代码在Demo里看起来没毛病因为Demo只跑正路径Happy Path不跑负路径但生产系统百分之八十的故障恰恰发生在负路径上。我在HomeX的工单模块中就遇到过一次典型的AI幻觉问题。AI生成的工单状态流转代码里直接从待分配跳到已完成是合法的这在Demo场景下无伤大雅但在真实业务里就是个大坑——因为没有维修师傅的接单、开始维修、完成维修这几个中间态物业公司根本没法考核维修响应时效也没法在客户投诉时提供完整的时间链。这种业务规则上的错误编译器查不出来、测试也大概率测不出来只能在代码审查阶段靠人肉经验去识别。3.3 跑通不等于上线工程化清单是硬门槛第三层原因是工程化缺失。真实系统要上线必须过一道清单单元测试覆盖率、接口文档、环境配置管理开发/测试/生产三套配置、日志规范结构化日志、TraceId链路、监控埋点关键业务指标、数据迁移脚本尤其是存量数据的清洗和映射、部署脚本Dockerfile/CI/CD流水线。这些工程化要素AI单独生成时往往是零输出的——它默认我只负责写业务代码。但一个系统缺了这些工程化支撑上线第一天就可能因为一个环境变量差异直接崩溃。我在HomeX项目里验证过一个结论AI生成代码的工作量大概只占项目总工作量的三到四成剩下六成是需求澄清、代码审查、缺陷修复、性能调优、联调测试和部署上线。这不是说AI没用而是说AI的作用被高估了——它更像一个效率极高的初级工程师能快速产出内容但产出内容的正确性、完整性和健壮性需要一位有经验的工程师来把控。因此用AI编程做真实业务系统本质上是组织一场高效的代码生产线——AI负责批量生产零部件人负责质检、组装和整机测试。4. HomeX实战拆解让AI吃透业务再从骨架长成系统讲完理念说点落地的东西。HomeX这个项目的完整开发周期大约是六周左右其中AI参与编码的比例很高但真正决定成败的是我在前面讲的需求显性化和工程审查。下面我把整个过程中的关键环节拆开来讲尽量还原真实的操作路径而不是只给一个漂亮的结论。4.1 数据模型先行先让AI看见业务全景在写第一行业务代码之前我先花了三天时间做了一件事把整个HomeX的数据模型梳理清楚并且让AI深度参与这个过程。注意这里不是让AI直接设计数据库——而是我先把业务规则写成文档然后让AI基于业务规则生成ER图、字段清单和索引建议然后由人做最终裁决。具体来说我在需求文档里明确了十七张核心表的业务含义和关系包括用户表区分业主/物业/管理员三种登录主体、房屋表小区-楼栋-单元-房号四级结构、房屋绑定表业主与房屋的关系支持一户多人和一房多业主、报修工单表包含报修类型、图片、位置描述、紧急程度、超时节点、工单流转历史表每一次状态变化的操作人、时间、备注、账单表关联房屋、费用项目、账期、金额、滞纳金、缴费流水表关联账单、支付渠道、交易号、回调状态、月卡表关联车牌、房屋、有效起止时间、自动续费标记、停车记录表进出场时间、道闸联动记录、巡检计划表周期规则、巡检点位、负责人、巡检执行记录表、访客邀请表二维码、有效期、单次/多次通行、公告表发布范围、已读回执、审批记录表针对退款、改单等需要审核的场景、操作审计日志表记录所有写操作的操作人、IP、时间、旧值/新值、配置表系统参数比如滞纳金利率、超时升级阈值、以及消息推送任务表消息类型、接收方、发送通道状态。这个数据模型一旦确定下来后续AI生成所有业务代码时就有了坐标系——它不会再凭空猜测字段而是严格根据表结构来写DAO层、Service层和接口参数。我用了一个小技巧把数据模型文档作为提示词的一部分每生成一个模块的代码之前先把与该模块相关的表结构完整贴给AI同时附上字段的业务含义说明。实践证明这个操作对AI输出质量的提升是立竿见影的字段命名不一致的问题几乎消失了连外键关联逻辑都处理得干净利落。4.2 提示词四要素把业务规则变成AI的工作手册很多人在用AI编程时有一个误区觉得提示词就是把需求说得清楚一点。其实远不止于此尤其是在真实业务系统的开发中AI的输入必须是一份结构化的工作手册而不是一句模糊的口头需求。我在HomeX项目里总结了一套提示词四要素的方法论每次让AI写代码或改代码时都会带上这四部分信息效果非常明显。第一个要素是角色与背景。不是简单地说你是一名Java开发工程师而是要给它足够充分的业务上下文比如你是物业管理系统的开发工程师该系统服务于中大型住宅小区业主通过小程序端发起报修、缴费和访客邀请物业员工通过管理后台处理工单、巡检和公告。你需要熟悉物业行业的常见业务流程包括但不限于报修工单的状态流转待分配、已接单、处理中、待验收、已完成、已关闭、物业账单的账期规则按月出账支持预缴和欠费滞纳金、月卡车辆的进出场联动逻辑。这段上下文的价值在于它把AI的通用编程能力收敛到了一个具体行业的知识框架里让AI的猜测有据可依。第二个要素是任务描述与验收标准。任务描述要具体到实现哪一个接口、输入什么、输出什么、调用哪个服务。更关键的是验收标准要先行。以提交报修工单接口为例我的验收标准写了一大段创建工单时校验用户身份和房屋绑定关系校验房屋是否在服务范围内如果上传了图片校验图片大小不超过5MB且格式为jpg/png/webp创建成功后要写工单流转历史要触发消息中心给对应的物业片区管理员发送新工单通知整个操作要记录操作审计日志并发重复提交时基于幂等键防重。这个验收标准既是给AI的约束也是后续代码审查的检查清单。第三个要素是技术与约束条件。这部分要写明技术栈Spring Boot MyBatis Plus MySQL Redis RabbitMQ、代码风格统一返回格式ResultVO、统一异常处理用BusinessException、Service层接口必须加方法注释、以及关键的非功能约束比如所有写接口必须具备幂等性、金额相关计算使用BigDecimal、禁止使用double、时间统一存储为UTC时间戳展示层再转本地时区。将这些约束作为提示词的固定组成部分后AI生成的代码整体规范度会明显提升审查成本大幅度降低。第四个要素是输入输出示例。尤其是接口定义部分我会给出具体的请求JSON和响应JSON示例让AI照着这个契约来生成。这个做法对前后端联调的效率提升非常关键——AI写出的Controller参数定义、校验注解、返回结构会与接口文档完全一致后续不需要花大力气做字段名的对齐和转换。4.3 上下文工程解决AI记不住项目全貌的问题提示词写得好只是第一步。真实项目中还有一个更大的痛点AI在单次对话中的上下文窗口有限而一个完整业务系统的代码量远超它的记忆范围。如果每次让AI改一个文件都要把相关的十几个文件的代码都贴进对话里既不现实也会吞掉大量上下文空间。HomeX项目里我用的是上下文工程的方式来对抗这个问题核心有三招。第一招是建一个项目知识库仓库。把数据模型文档、接口契约文档、架构设计文档、部署文档、以及一些关键模块的业务规则说明放到一个专门的docs目录下并同步到AI可检索的范围里。我在实践中发现让AI先查文档再写代码比直接凭记忆写的效果要好得多。不过要注意普通的对话工具并不会自动去查你的文件系统所以更有效的做法是把与当前任务相关的文档片段直接作为提示词输入而不是指望AI自己主动查找。第二招是模块化的上下文切分。不要试图让AI一次处理整个系统而是把项目按业务模块切分成若干个开发单元。比如开发的是报修工单模块那上下文里只需要包含与工单相关的表结构、核心流程规则、相关的API定义、以及与该模块有交互的周边的接口。其他无关系统的代码一概不提。这个做法的好处是每个AI对话的上下文窗口都被高效利用AI的输出也不会因为信息过载而出现严重偏离。第三招是把老代码变成一种上下文提示。当AI需要修改一段已有代码时我倾向于把涉及的相关代码贴出来并且用注释的形式告诉AI这段代码里哪些地方不要动、哪些地方需要改、改了之后的调用方在哪里。有一次我让AI调整月卡续费逻辑把续费成功后立即推送道闸系统改为续费成功后进入待同步队列由定时任务批量同步如果只贴一个Service文件AI很容易漏掉Controller层的调用点但把Controller、Service和消息消费者三个文件的片段一起贴上去它就能全面理解改动的影响范围。4.4 从骨架到血肉AI负责批量生产人负责定向打磨用上述方法HomeX的代码生产速度确实惊人。第一周结束整个项目的骨架就出来了——包括完整的数据库建表脚本、所有实体类、Mapper接口、以及大部分Service接口和Controller层的CRUD代码。如果按照传统开发方式这一周的工作量大概是一个三人团队十五天的工作量。但请注意骨架出来了和系统能用了是两回事接下来才是真正考验人的阶段。骨架之后的打磨工作主要集中在这几个方面第一个是业务规则的补全。AI生成的Service方法通常只完成了基础的增删改查但真实业务的大量规则逻辑是缺失的比如创建工单时的超时节点计算紧急工单要在15分钟内响应普通工单4小时内响应超时自动升级、缴费账单的滞纳金计算月结后第16天开始按日利率万分之五计算、月卡到期前的自动提醒到期前3天、1天分两次发送短信。这些规则我都是在AI生成的代码基础上通过二次编写或让AI按补充规则重新修改来实现的。第二个是数据一致性的处理。这部分是AI编程最容易出问题的领域。最典型的是支付模块支付回调是异步的用户可能在支付成功的瞬间又申请了退款或者重复点击支付按钮导致创建了多笔订单。为了处理这些问题我设计了订单号去重、回调幂等表、以及状态校验状态机订单从待支付到已支付必须是单向流转不允许回跳。这些逻辑AI写起来很吃力因为需要非常细致的并发思维我最终的实现方式是先自己手写一个核心处理类再让AI基于这个类的模式补全其他模块的类似逻辑。第三个是联调中的契约修正。前后端联调是真实项目中无法绕过的一环。AI生成的后端接口和前端的调用代码经常出现字段名不一致、返回结构不符合预期的问题。我在HomeX中引入了一份接口契约文档作为联调的仲裁标准一旦出现前后端不一致不是互相扯皮而是对照契约文档来确定哪边需要修改。AI在这个过程中可以做大量高效的批量修改——比如前端调用的字段名从houseAddress改成houseFullAddress这种跨文件的修改让AI执行反而比人肉改更高效。4.5 用AI生成测试把质量防线前置代码审查和测试往往是AI编程实践中最容易被跳过的一环。很多人让AI写完功能代码就直接上线结果出了问题再去排查耗时耗力。HomeX项目里我把测试作为一道强制的质量防线而且测试代码也尽量让AI来生成。我的做法是每完成一个业务模块先让AI根据该模块的接口契约生成一套单元测试代码测试框架用JUnit Mockito覆盖核心Service方法的主流路径和异常分支。注意AI生成的测试代码往往比较粗糙——它倾向于只验证调用成功了和参数校验生效这两类场景对于复杂的状态流转测试和并发场景测试覆盖很弱。所以我不会让AI的测试代码直接进代码库而是先人工审查一遍补齐关键边界场景再让AI补充遗漏的测试用例。比如工单状态机的测试我会明确告诉AI请针对从待分配到已分配、已分配到处理中、处理中到已完成这三个正向流转以及从已完成非法回退到待分配、从待接单非法跳转到已完成这两个逆向流转各写一个测试用例这种定向补测的效果相当好。经过这个流程HomeX在第三周末期实际上就达到了一个可以被内部试用团队进场实测的状态而真正暴露问题的阶段也从开发中转移到了试用期——后者才是检验真实业务系统的终极考场。5. 真实项目中的AI编程踩坑记录三条完整排查链路前面讲的都是方法论但真正让一个团队在AI编程实践中成长的往往是那些让人抓狂的线上故障。下面这三次排查我尽量完整还原当时的分析链路和最终的根因希望你能从中获取排查类似问题的思路。5.1 支付回调场景的幂等键悬挂问题AI考虑了却没用对现象模拟真实支付场景做压测时自动续费订单出现大量重复到账记录——同一笔月卡续费在用户端被扣款两次但后台关联的支付通道回调记录却是正常的。初步排查时我的第一反应是订单创建接口没做幂等导致同一个支付单号生成了多笔本地订单。代码一看AI确实生成了幂等逻辑但它的幂等写法是用支付单号去订单表里查查到了就直接返回老订单。问题在于它在查询和创建之间没有做任何锁或唯一约束并发场景下两个线程同时查都查不到就各自创建了一笔新订单——典型的先查后写竞态条件幂等键成了一个摆设。修改方案不复杂给订单表的支付单号字段加唯一索引创建订单时直接基于唯一索引冲突来做幂等返回而不是先查后写。这里有一个实操建议在让AI生成任何涉及防重、幂等、库存、余额这类并发敏感逻辑时提示词里必须明确要求使用数据库约束兜底不能只依赖应用层判断。这也是我在HomeX项目中后续所有写接口的强制标准。5.2 工单状态机的幽灵流转AI把状态校验漏在了业务层之外现象客服反馈在管理后台把一张已完成的工单重新打开时系统居然允许操作状态直接跳回了处理中而工单的完成时间、维修人员的评价数据都还在导致统计报表和客户账单出现逻辑矛盾。问题本质上是状态机校验的缺失。AI生成的工单更新接口只校验了工单是否存在没有校验当前状态是否允许目标状态。因为不同操作对应的状态流转路径不同——客服可以重新打开已完成未超时的工单但不能重新打开已关闭的工单。AI把允许重新打开的宽松逻辑写到了通用的状态更新方法里一放行就放行到了所有场景。这次我做的不是简单补一个if判断而是给工单模块画了一张状态流转矩阵行是当前状态列是目标状态单元格标注可执行的角色和条件然后把这张矩阵直接作为提示词输入让AI重构状态校验逻辑并且为每一次操作生成独立的校验方法。这张矩阵后来成了HomeX所有状态机模块的标准模板——月卡状态、缴费状态、审批状态都按这个模式来处理。5.3 巡检任务的定时漏跑AI生成的Cron表达式只能看不能用现象生产环境上线后的第一周巡检任务出现了一天漏跑的情况——原本应该每天凌晨3点自动生成的巡检执行记录那天只有部分小区生成了其他小区一片空白。排查过程很有趣。日志显示定时任务当天确实被调度了但执行到一半就抛异常退出了——原因是AI生成的任务生成逻辑里写了一个时间边界判断判断今天是否为该小区巡检计划的执行日而它用的是本地时间和一个凌晨边界换算结果在夏令时切换那天部分地区的服务器配置了自动夏令时产生了边界错误导致当天被判定为非执行日。更深层的问题是AI生成的调度逻辑把多种定时策略做了过度耦合同一个任务里既判断了每两周执行的周期规则又判断了指定星期几执行的日期规则还嵌入了节假日跳过的逻辑。一旦其中一个判断出错整个链路就断了。我的修复方案是把调度判定拆成独立的策略接口日期策略按周期生成、时间策略按时刻生成、排除策略节假日/特殊日然后让AI为每种策略单独生成实现类最后用策略编排器统一汇总执行日的清单。这样即使某一个策略挂了也只是影响当天的部分生成不会让整个任务崩盘。这次排查给我的教训是AI生成的代码尤其是定时逻辑、状态判断、时间日期处理是幻觉重灾区。不要信任它的看起来正确一定要通过大量边界场景的实际数据去验证。6. 从片段到系统如何把AI提供的代码片段缝合成完整架构当AI生成的代码开始多起来之后一个更高维度的问题浮现出来每个模块单看都还不错但拼在一起时却到处漏水。各模块之间的数据不一致、调用链断裂、异常处理风格不统一让项目陷入一种什么都写了但什么都没完全接上的混乱状态。这个阶段最考验的是系统性思维而不是编码能力。6.1 用接口契约作为各个模块之间的缝合点我在HomeX中做了一件费力但极有价值的事在写任何业务代码之前先用一份接口契约文档把系统内部所有模块之间的交互方式固定下来。比如报修工单创建后需要通知消息中心这个消息是通过RabbitMQ异步发送还是通过Feign同步调用如果消息中心挂了工单创建是否要继续走完这种跨模块决策不能让AI来选因为AI每次只会基于当前对话的上下文来权衡做不了一致性的架构判断。接口契约文档的做法是用一个统一的表格模板管理所有内部依赖关系内容包括调用方模块、被调方模块、接口名、入参出参JSON示例、调用超时时间、失败降级策略、是否需要消息幂等。这份文档直接放进项目仓库作为系统宪法级的参考文件。后续AI补全代码时只要在提示词里指定按照接口契约文档中XX接口定义来实现Feign客户端就不会出现各个模块各写一套调用方式的问题。6.2 用评审Agent过滤AI代码的结构性问题代码量大了之后人工审查每个文件的细节是不现实的但完全依赖AI自审又会陷入自己检查自己的作业的盲区。我的做法是搭建一个三级评审机制。第一级是静态检查工具在CI流水线中接入Checkstyle和SpotBugs自动拦截常见的代码规范问题和潜在空指针、资源未关闭等低级缺陷。这一级能过滤掉大概两成的明显问题。第二级是评审Agent。我会在每周的代码评审日把本周AI生成的所有代码的关键文件汇总起来让AI按照一份审查清单逐项做专项审查。清单包含八项必查内容数据库字段命名与数据模型文档一致性、外部API调用的异常处理与超时设置、敏感操作是否记录审计日志、金额计算是否使用BigDecimal、状态机流转是否合法、权限校验是否在Service层而非只在Controller层、批量操作是否考虑部分失败的回滚、以及是否存在先查后写的并发安全漏洞。这个审查Agent并不会替代人工评审但能帮人工把注意力集中到高风险区域。第三级是人工抽审。每周挑三到五个核心业务文件的实现人工完整review一遍重点看业务逻辑是否与需求一致。这三级的比例大致是AI自查能发现三成问题评审Agent能发现五成问题剩下两成隐藏较深的问题必须靠人工抽审。定价这套机制后HomeX的代码质量在进入联调阶段时已经有一定的及格线而不是裸奔状态。6.3 让AI生成适配多环境的部署脚本与迁移策略真实业务系统的部署永远不是本地能跑就行的。HomeX采用了标准的Docker Compose本地环境 云服务器Test环境 生产环境三套部署方案。每套环境的基础配置不同数据源、Redis地址、消息队列地址、对象存储桶名而且配置项不能写死在代码里。AI在这个环节的贡献主要是根据我提供的环境清单生成Dockerfile、docker-compose.yml和一套基于Spring Profile的环境配置模板。我花了些精力让它理解三套环境的差异点以及哪些配置项属于每次上线必须检查的关键项——比如短信服务商的AppKey、支付网关的商户号、以及消息队列的VHost隔离。数据迁移是另一个AI容易翻车的地方。HomeX初期有一部分历史数据是从Excel表格导入的比如存量业主信息、历史缴费记录。AI生成的导入脚本在处理空值、格式不一致、重复记录这些脏数据时策略过于粗暴——直接插入导致数据库报错或者静默丢弃造成数据缺失。我的方案是设计一个数据清洗外挂层让AI生成的导入代码先过一个规则引擎把未通过清洗规则的数据放入异常队列生成一份带原因说明的Excel由业务人员人工核对后再重新导入。这个方案虽然比一键导入麻烦但在真实数据的迁移场景中是唯一稳妥的做法。6.4 灰度发布与回滚预案真实上线前的最后一道锁HomeX不是从零到一直接全量上线的。我的计划是先选一个小型小区约500户做灰度试点跑一个月验证核心流程稳定后再扩展到更多小区。这个策略要求在代码层面具备灰度能力——配置中心里存一套功能开关配置可以单独关闭某个模块的入口或切换某个服务到新版本。AI在这个环节帮了不少忙根据我的要求它生成了功能开关的后台管理页面和接口逻辑虽然页面的UI比较简陋但功能是可用的以及一套基于Nginx 网关层的灰度路由配置模板可以按小区ID做流量分流。真正重要的是回滚预案我要求AI为每一个核心服务生成一版可回滚的上线清单包括当前版本的数据库变更脚本、需要回滚的代码变更点、回滚后的数据一致性处理步骤。这份回滚文档的实战价值在灰度过程中第三周真正体现了一次——某个版本引入了消息消费的重复处理BUG导致公告推送出现了少量重复回滚预案文档让我们在15分钟内完成了版本回退和重复消息清理。7. AI编程的边界与下一阶段经过HomeX验证的几件事HomeX从立项到灰度运行到目前为止我感受到的AI编程的实际状态是它的确让开发效率获得了碾压级的提升但同时也把做决策和做审查这两件事的权重无限放大了。团队里如果没有人能清晰地定义业务规则、识别AI输出的缺陷、能够把它们从浩瀚的代码中挑出来AI编程带来的不是效率红利而是技术债雪崩。经过实践我认为有几条边界是短期内AI编程突破不了的第一AI无法替你做真正的架构权衡。用微服务还是单体、消息队列选RabbitMQ还是Kafka、数据库分库分表的时机、缓存与数据库的一致性策略这些决策影响的是整个系统的十年生命周期AI给出的答案往往只是基于大多数项目会这么选而不是基于你这个项目的具体约束。这也是为什么HomeX没有采用AI建议的微服务架构而是选择了模块化单体——因为项目的规模、团队的技术栈和运维能力都还撑不起一套完整的微服务治理体系。第二AI无法替你理解隐性业务规则。为什么物业公司要求同一房屋可以绑定多个业主但一个业主只能绑定一个主账号为什么退费申请超过五百元需要审核为什么夜间报修工单必须同时给值班经理发短信这些规则背后是行业的运营逻辑和人情世故AI不懂需要有人把规则输入进去。与其抱怨AI写的代码不符合业务要求不如反思自己有没有把业务要求讲清楚。第三AI生成的代码必须过真实性验证。所谓真实性验证就是让代码面对真实的数据、真实的并发、真实的异常场景而不是在Demo环境里跑通一次。HomeX做了两件很有价值的事一是在灰度阶段引入了操练日让物业公司的真实客服人员高频输入各类极端场景半夜的报修、早高峰的月卡续费、一笔金额异常的缴费看系统会不会出错二是把所有核心接口的响应时间落在监控大盘上设定阈值告警。这些真实世界的反馈远比AI自认为写完了更有说服力。至于AI编程的下一阶段我的判断是多智能体协作会在两到三年内从玩具走向实用——一个AI负责写代码另一个AI负责审查第三个AI负责补测试第四个AI负责性能分析彼此通过任务队列协作。我在HomeX中还尝试了一个非常初步的多智能体方案路由Agent将任务分发到不同的子Agent代码生成、代码审查、测试生成、文档编写每个子Agent的输出再回到路由Agent做汇总。效果有一些但距离自主闭环还有相当长的路要走主要原因在于Agent之间的上下文传递会指数级消耗Token而且业务规则在传递过程中的失真无法避免。所以如果你问我AI编程能不能用来做真实业务系统我的答案是能前提是你把自己的角色从写代码的人升级为系统架构师和代码审查者。AI负责让代码以快十倍的速度出现在屏幕上你负责保证这些代码不会在真实业务的天平上被压垮。HomeX这个项目对我最大的意义不是最终上线了多少功能而是它让我把对AI编程的期待从一个炫技式的Demo转变成了一批经得起真实业务检验的、可持续迭代的系统能力。最后分享一个实操层面的小建议如果你正在用AI编程做自己的项目从第一天起就建立一份AI辅助开发日志每次让AI做了什么、AI做错了什么、你是怎么修正它的都记录下来。这份日志既是你的提示词迭代依据也是你和AI协作经验的积累库。我在HomeX第二周就为团队搭建了这个日志体系后续新人上手这个项目时直接读这份日志就能快速进入状态——它对团队协作的价值不亚于任何一份代码文档。