一、项目背景：物业系统为什么适合 AI 编程
物业管理平台有几个典型特点：
-
业务链路长：报修、账单、缴费、投诉、访客、停车位、公告、论坛等模块并行演进。
-
角色复杂：`super admin / property admin / staff / owner / tenant` 权限边界细。
-
需求改动频繁：字段变化、流程变化、权限变化几乎每个迭代都在发生。
-
回归成本高：一个接口改动，可能牵动前端页面、鉴权中间件、数据库迁移和测试用例。
这类项目天然适合 AI 参与，因为"样板型工作 + 高频变更 + 规则密集"。
二、homex 实际技术栈
后端
-
`Go 1.24`
-
`Gin`（路由与 HTTP 框架）
-
`GORM + MySQL`（数据层）
-
`Redis`（缓存与部分性能优化）
-
`JWT`（认证）
-
`Swagger`（接口文档）
-
中间件：`CORS / Rate Limit / Tenant / Permission / Recovery / Validator`
前端
-
`Vue 3 + Vite`
-
`Pinia`（状态管理）
-
`Vue Router`
-
`TailwindCSS`
-
`Axios`
-
`Vue I18n`（中英繁/Tagalog 等多语言）
架构特征
-
子域名 + 属性映射的多租户隔离（property 级数据边界）
-
RBAC 权限模型
-
Cloudflare Turnstile 风控接入
三、我们如何把 AI 用进开发流程
1）需求结构化，再让 AI 生成
先给 AI 输入结构化需求，而不是一句"帮我写接口"：
-
业务目标
-
角色权限
-
状态流转
-
数据约束
-
异常分支
-
验收标准
这样能显著减少"看起来能跑、但不符合业务"的输出。
2）按分层生成，避免一口气"全自动"
在 homex 后端，我们按以下顺序让 AI 参与：
-
`models`/DTO 字段草案
-
`repository` 查询与分页
-
`service` 业务规则
-
`handler` 参数校验与响应结构
-
`routes` 注册与权限挂载
-
Swagger 注释补齐
前端同理：先 `api` 层，再 `store`，最后 `view` 页面。
3）AI 重点投入在"测试和回归"
相比直接写核心业务，AI 在测试补齐上更稳：
-
为 handler/service 生成基础单测
-
按历史 bug 反推回归用例
-
生成边界值与异常输入测试
结论：AI 写测试的性价比通常高于 AI 一次性写核心业务。
4）把 Prompt 模板做成团队资产
我们沉淀了几个高频模板：
-
Gin Handler 标准模板（参数绑定 + 错误码 + response）
-
GORM Repository 模板（分页、筛选、排序）
-
RBAC 权限校验模板
-
Vue 页面 CRUD 模板（列表/详情/新增/编辑）
-
迁移脚本审查模板（字段兼容、索引影响、回滚策略）
四、一个真实场景：账单模块迭代
以账单模块为例，一次迭代通常包含：
-
MySQL 字段调整与迁移脚本
-
GORM Model/Repository 更新
-
Service 账单状态流转逻辑修改
-
Handler 接口与 Swagger 更新
-
Vue 页面和筛选条件联动
-
回归"我的账单 / 管理端账单 / 支付记录"链路
AI 在这个流程中主要承担"重复且容易遗漏"的部分，人重点盯业务规则和数据正确性。
五、落地后最明显的变化
-
新需求首版交付速度明显提升。
-
接口层风格更统一（参数校验、错误响应、文档注释）。
-
回归测试覆盖更完整，线上回滚次数下降。
-
新同学上手成本降低，代码结构更可预测。
六、踩过的坑与规避策略
- AI 不了解"租户边界"
- 规避：在 Prompt 显式声明 tenant 规则与数据隔离约束。
- AI 容易遗漏权限判断
- 规避：把权限清单当输入的一部分，不靠"默认理解"。
- 一次生成代码过大，review 困难
- 规避：按分层小步生成，小步提交，小步验证。
- 迁移脚本风险高
- 规避：AI 只给草案，人必须做 SQL 审核和灰度方案确认。
七、我的结论
AI 编程在 homex 这类业务系统里，真正价值不是"替代开发"，而是：
-
降低机械劳动占比
-
提高交付一致性
-
把工程师时间释放到业务决策和架构演进
一句话总结：
**把 AI 当成团队的"加速器"和"规范放大器"，而不是"自动写代码按钮"。**