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第二周就为团队搭建了这个日志体系，后续新人上手这个项目时，直接读这份日志就能快速进入状态——它对团队协作的价值，不亚于任何一份代码文档。
