AI编程实战复盘：一人三周建成SaaS报销系统，哪些活AI能扛？

一个人对着屏幕，从数据库建表写到前端页面，再从权限模型调到部署上线，最后真把一套 SaaS 报销系统跑起来——这事放在两年前，我一个人想都不敢想。但这次借着 AI 编程，我用大约三周业余时间把整套流程走完了。这篇不是 AI 工具评测，也不是鼓吹“程序员要失业”的焦虑文，而是我作为一个实际干活的开发者，从零到一做完这个报销 SaaS 后，想认真聊聊当下 AI coding 的真实水位线：它能帮你做到哪一步、在哪里会卡住、哪些地方必须靠人兜底。

我做的这套系统不是玩具 Demo，而是包含多租户隔离、角色权限、审批流、发票识别、费用报表、对公付款申请这些模块的可用系统。数据模型有 30 多张表，接口有 80 多个，前端页面 40 来个。整个过程里我用了 AI 编程辅助，也走了不少弯路。如果你正打算用 AI 辅助做类似的中小型业务系统，这篇内容应该能帮你省下不少试错时间。我会把 AI 真正能扛的活、干不了的活、以及怎么和它配合效率最高，一五一十拆开讲。

1. 为什么我敢一个人用 AI 去啃一套 SaaS 报销系统

先交代背景。我本身是后端出身，以前写 Java 和 Go 多一些，前端属于“能看懂但写得丑”的水平。市面上现成的报销 SaaS 很多，但要么定制成本高，要么数据模型太重，小团队根本用不起来。我当时的想法很简单：想要一套足够轻、能自己控制字段和审批流的报销工具，顺便验证一下 AI 编程到底能帮我省多少事。

开头直接用 AI 生成代码其实是心里打鼓的。早些年我用 AI 补全代码，生成的函数经常要改半天，上下文一长就胡说八道。但最近 Cursor 这类工具把“AI 补全”升级成了“AI 结对编程”，可以基于整个代码仓库的上下文来生成跨文件改动。这个变化很关键——它意味着 AI 不再只是帮你写一个函数，而是能帮你完成“从接口定义到数据库迁移再到前端调用”这种链路式开发。

这套报销 SaaS 的核心定位，我一开始就定得很死：

• 多租户：每个企业一个独立空间，租户间数据隔离；
• 可配置审批流：不同费用类型走不同的审批链；
• 发票处理：支持拍照上传、OCR 识别关键字段；
• 报销单状态机：草稿、审批中、通过、驳回、打款、关单；
• 权限模型：企业管理员、部门主管、财务、普通员工四种角色。

选这个领域做试验田是有私心的。报销系统是典型的“看着简单、做起来全是细节”的业务系统。它既要有标准 CRUD，又要处理审批流的状态迁移、金额的精度校验、权限的边界判断、文件存储的集成。这种复杂度刚好能测试 AI 在多大程度上理解“业务规则”，而不是单纯翻译需求。

项目启动前我给自己定了一条红线：AI 写的代码，每一行我都必须看懂并 review 过。这条红线在后面救了我好几次，后面细说。

2. AI 编程最擅长的是“搭骨架”，不是“做决策”

我实测下来，AI 编程目前最舒服的使用方式，是让它做“低保真实现”：你给出明确的技术选型和数据模型，它负责把架子搭出来。比如我要建 expense_reports 表，只需要给 Cursor 一段自然语言描述字段和约束，它能直接生成带索引、外键和 updated_at 触发器的迁移脚本，而且命名风格基本能跟项目保持一致。

有一个很典型的场景：报销单的编号生成规则。传统做法是“RC + 年月日 + 四位流水号”。我让 AI 生成带数据库锁的编号生成器，它给出了基于 Redis 原子自增和数据库唯一索引双保险的方案。这种已经被无数项目验证过的普通模式，AI 生成质量很高，基本不需要改。原因不难理解：这类逻辑在开源代码里太常见了，训练数据足够多。

但它做不了真正需要业务决策的事。比如报销单驳回后，财务能不能修改金额？修改后是重新走审批流还是保留原审批记录？这种“业务规则到底该怎么定”的问题，AI 很难替你想清楚。它最多能帮你实现“驳回后可编辑并重置流程”这个表面逻辑，但对于“为什么重置流程而不是生成新版本”“历史审批记录是否需要留痕”这些深层产品问题，它没有判断力。

还有一个容易被忽略的点：AI 在搭骨架时经常会过度设计或遗漏边界。例如让它设计权限中间件，它可能会同时加上角色继承、数据范围、字段级权限控制，但其实你的场景只需要按钮级权限。过度设计会让代码复杂度膨胀，后面维护起来又费劲。反过来，让它处理金额分配这种需要精确校验的场景，它又会漏掉“两张报销单同时引用同一张发票”这种重复报销检查。

所以我的使用策略很简单：AI 负责把确定性的代码写出来，我负责把不确定的业务规则定下来。在开始编码前，我会把所有状态机流转、权限矩阵、重复性校验规则先写在文档里。这一步不能省，越复杂越不能省。有了这份文档后，AI 生成的代码准确率会高很多，因为它不再需要“猜”业务逻辑。

3. 从零搭起：模型设计、接口生成和前端联调的真实分工

我说的“从零到上线”不是形容词。第一周我主要在做数据模型和 API 层。这恰好是 AI 编程生产价值最大的阶段。

数据模型层面，我先手写了一张大表：租户、用户、部门、角色、费用类型、发票、报销单、报销明细、审批实例、审批节点、审批记录、打款记录。然后让 AI 对照这张表把 Sequelize ORM 模型全部生成出来。这一步明显比手写快，因为它能根据字段名自动推断类型和关联关系，比如 hasMany、belongsToMany 这类关联，几乎不需要手动指定外键。

接口层我用了类似的方式：先把 RESTful 规范告诉 AI，让它为每个模型生成 CRUD 接口。但这个阶段开始暴露问题。AI 对“当前用户只能查自己提交的单据”这个需求容易偷懒，经常只生成 SELECT * FROM expense_reports 这种无差别查询。如果你不检查，等做到前端联调时就会出现数据越权。后来我总结出一个规律：必须在提示词里明确“列表接口必须带 tenant_id 和 user_id 过滤条件，不能返回全量数据”，它才会老老实实把 where 条件写好。

前端是我这次最意外的收获。我原本以为自己要花大量时间调表格和表单，结果 AI 在生成 Ant Design 页面的效率远超预期。我只需要描述“报销单列表页：左侧筛选区，右侧表格展示单据编号、申请人、费用类型、金额、状态，支持分页”，它生成的代码开箱即用程度达到了 70%。剩下 30% 需要改的主要是业务细节，比如状态标签的颜色映射、金额千分位格式化、驳回原因的弹窗展示。

但是“联调”这件事，AI 目前帮不上太大的忙。接口返回结构和前端期望不一致、字段命名一个用下划线一个用驼峰、日期格式没对齐——这类问题 AI 很难通过读代码发现，因为它的“视野”是碎片化的，不会像人一样同时盯住前端传参和后端接收的完整链路。我统计了一下，第二周大约 70% 的报错都是在联调阶段暴露的，AI 能做的只是帮我更快地定位报错堆栈，而不是避免错误发生。

4. 审批流是最难啃的硬骨头，也是 AI 最容易翻车的地方

报销系统的核心，不是增删改查，而是审批流。这也是我这次项目里进度最慢、AI 返工最多的地方。如果你打算用 AI 编程做任何带流程性质的系统，这块值得你先有个心理准备。

先说我采用的方案：轻量级状态机 + 独立的审批实例表。每张报销单提交时创建一个审批实例，根据费用类型和金额路由到对应的审批链上。例如普通报销的链是“部门主管审批 → 财务审核”，超过 5000 元的报销中间多插一个“企业负责人审批”节点。这是很经典的审批流设计，网上资料一大把。

但 AI 在处理状态流转时容易出现“条件覆盖不全”的问题。比如同一级审批人有多个时，只要其中一人通过就进入下一节点，还是需要所有人都通过？拒绝后是直接结束流程，还是允许申请人修改后重新提交？这两个问题 AI 经常没有保持逻辑一致性。我遇到过它生成的代码里，“驳回后重新提交”走的是新建审批实例的逻辑，导致历史审批记录全部丢失。这个 bug 在业务上相当严重，财务审计时连“上一次是谁驳回的”都查不到。

另一个 AI 翻车点是审批历史和操作权限的绑定。比如财务打款操作只能发生在“审批通过”状态，AI 生成的代码可能会允许在“审批中”状态下就发起打款；而前端按钮也缺少状态判断。这种跨模块的强约束，AI 很难自行推理出来。它更擅长做的是：你明确告诉它“只有状态为 approved 的单据才允许调用打款接口”，它能很规矩地在前端和后端都加上判断。

所以到了审批流这个阶段，我的工作方式彻底转变：不再让 AI 自由发挥，而是把每个状态的流转规则用表格列出来，让 AI 严格按表实现。比如：

这种方式的效果立竿见影。AI 生成的代码终于能和我的业务预期对齐了。我个人的体会是：当业务规则能被明确枚举时，AI 编程的效率极高；但当业务规则需要靠“悟”的时候，AI 就只是一个比较聪明的代码生成器，而不是产品经理。

5. 数据安全与多租户隔离：AI 提示词救不了的合规问题

标题相关热搜里有一条“saas系统怎么确保数据安全不可篡改”，这恰好是我在整个开发过程中始终悬在心头的问题。报销系统里全是员工姓名、手机号、发票金额、银行账号，一旦数据泄露或者被篡改，后果非常严重。AI 编程可以帮你写加密工具类、加签名逻辑，但它没法给你判断“这套系统的信任边界应该画在哪里”。

我的做法分三层。第一层是传输和存储加密，所有外部请求走 HTTPS，数据库里的敏感字段如手机号和银行账号用 AES-256 加密存储，密钥放在环境变量里，不落库。这些功能 AI 生成的速度很快，因为它很熟悉“加密工具类”这种常见的代码模式。第二层是审计日志，每一笔审批操作、每一次打款动作都要记录操作人、操作时间、操作前后的数据快照。这一块 AI 也能帮忙把表结构和记录逻辑生成了，但难在哪些操作需要记录、记录到什么粒度需要人来定。

第三层是最关键的多租户隔离。这里我不建议完全依赖 AI 的建议。AI 常见的多租户实现思路有三种：独立数据库、独立 Schema、共享表 + 租户 ID 过滤。它会把三种方案都列给你，但不会告诉你哪种适合你的场景。因为报销系统的数据敏感度高，但租户数量预期不会特别大，我选择了共享表 + 租户 ID 过滤 + 数据库行级安全策略的组合。这个组合的好处是部署成本低、迁移方便，但缺陷是一旦某个查询漏加了租户过滤条件，就会造成跨租户数据泄漏。

为了防住这个缺陷，我做了两件事。第一件，所有查询入口强制走一个基础 Repository，这个 Repository 会自动附加 tenant_id 条件，不允许业务代码裸写 ExpenseReport.findAll() 这种不带租户条件的查询。第二件，我写了一个自动化测试脚本，模拟两个租户的账号互相访问数据，确保任意接口返回的数据都不包含其他租户的信息。这两件事 AI 都没有主动帮我做，是我在代码 review 时发现它生成的某几个接口存在漏过滤问题后，决定用机制去兜底的。

不可篡改这个需求，我用的是关键操作双写策略：业务状态更新时，同时往 audit_logs 表里写入一条带哈希链的记录。每一条日志的哈希值由“上一条哈希 + 当前操作内容 + 操作人 + 时间戳”计算得到，这样如果有人偷偷改了历史日志，哈希链就会断裂，审计时能立刻发现。这个逻辑看起来复杂，其实代码量不大，AI 完全可以生成。但“为什么要用哈希链而不是简单记录一条日志”这个问题，AI 只有在你明确告诉它之后才会去实现。

6. AI 编程的实际效率：我的耗时记录和成本账

我知道很多人最关心的是：AI 编程到底能快多少？我没法做严格的对照实验，但可以把自己的实际耗时记录分享出来。我的开发环境是 Cursor + Claude 模型侧生成，辅以 GitHub Copilot 做补全，前后端同时在这一个 IDE 里写。

整个项目整体耗时记录如下：

合计投入大约 24 天。注意，这里的“天”不是整天，我是在业余时间开发的，每天大概投入 4 到 6 个小时。真正挤出来的时间是 API 层和前端页面，这两块 AI 的效率提升非常明显，大约是 2 到 2.5 倍。审批流和测试修复环节的 AI 加成很小，因为这些环节要求的不是“生成代码”，而是“理解业务全貌”。尤其是测试修复，AI 能帮你生成单测代码，但当测试失败时，它经常无法判断是测试代码写错了还是业务代码写错了，最后还是要人来看。

费用方面，我用了 Cursor 的 Pro 订阅和 Claude API，一个月合计大约 200 元人民币左右。相比请外包开发动辄几万的报价，这个成本几乎可以忽略。但隐形成本并不低，就是“人的注意力”。AI 生成的代码量越大，你需要 review 的代码就越多。我粗略算过，大约每接受 AI 生成的 1000 行代码，我需要花 30 分钟到 1 小时做 review 和修改。这个过程没法跳过，否则 bug 成本会翻倍转移到调试阶段。

7. 调试与兜底：AI 生成的代码，Bug 藏得更深

第三周开始进入折磨人的调试阶段。因为不是所有 AI 生成的代码都容易排查问题，尤其是那些多层嵌套的异步调用，AI 生成的 Promise 链一旦报错，堆栈信息绕得你头晕。我需要坦白说，AI 编程并没有减少调试时间，它只是把写代码的时间压缩了，bug 该有的还是有。

举一个具体例子。报销单列表页有个“导出 Excel”功能。AI 生成的后端代码用 ExcelJS 里的样式对象写表头，由于它对单元格样式对象的数据结构理解有偏差，写出的样式代码在某些场景下会抛异常。但这个异常只在导出包含特殊字符（比如手机号里的 + 号）时触发，普通数据根本测不出来。一直到我自己拿真实数据测试才发现这个问题。这种 bug 属于典型的“AI 以为它做对了，但实际对 API 的理解是错觉”，你如果只是看代码，很难看出问题；必须靠真实场景测试才能暴露。

这个案例让我定了两条规矩。第一条，关键业务代码必须有测试覆盖。我专门为审批流和金额计算写了测试脚本。第二条，AI 生成的涉及外部库调用的代码，我会额外留意库的文档是不是和 AI 生成的代码对得上。AI 很擅长把旧版本 API 的用法套在新版本库上——Cursor 某些模型的知识截止日期决定了它对很多库的最新版本了解是滞后的。这种情况最坑人，因为报错信息看起来像是你的代码写错了，实际上是 API 已经变了。

我自己对付这类问题的方法，是让 AI 读它自己生成的代码并解释一遍。这个操作听起来有点绕，但很有效。当我发现一段代码有嫌疑时，我会在对话里圈中这段代码，然后问它：“这段逻辑在某个边界下会出问题吗？”大多数情况下它能说出潜在问题并给出修复。也就是说，AI 编程的调试不是靠它主动发现错误，而是靠人提出问题、它来验证和修复。这是一种“人机互相 review”的工作模式，效率比我一个人死磕要高，但人的问题意识依然是核心驱动。

8. 部署上线的最后一公里：AI 帮不上太多忙

系统开发完，接下来是部署。我用的是阿里云服务器加 Docker Compose 部署前后端和 MySQL、Redis。这一块 AI 确实能帮我生成 Dockerfile 和 docker-compose.yml，但到了真实的服务器环境，问题就变得非常琐碎。

比如域名 HTTPS 证书的自动续期脚本，AI 生成的 Shell 脚本第一版就有问题，cron 任务没有加执行权限导致续期失败。这个坑不大，但排查起来耗时间，而且 AI 很难远程看到你服务器上的实际状态。再比如前后端分离部署时，Nginx 需要把 /api 路径反向代理到后端容器，同时还要处理前端 history 路由的 try_files 配置。AI 生成的配置在本地跑没问题，放上服务器就 404。原因是本地访问路径和线上路径不一样，这种环境差异 AI 是看不见的。

所以我的体会是，部署上线环节，AI 编程的“水位线”明显低于开发环节。它能给你一份合理的配置文件模板，但最终调通还是得靠人懂 Linux 基础、懂 Nginx 路由、懂 Docker 网络。如果你是完全不会运维的纯前端或纯后端开发者，想靠 AI 把系统部署上线，这一公里可能会卡你很久。

上线之后还有一堆脏活累活：数据备份、日志轮转、监控告警。这些 AI 都能生成脚本模板，但需要你根据自己服务器的实际路径、内存大小、业务量去调整参数。我的建议是别在这上面省时间，把备份脚本写好后，一定要实际做一次数据恢复演练。我见过不少开发者的备份脚本每天都在跑，但恢复出来发现数据根本不全，等于没有备份。这个坑 AI 永远不会替你踩，因为它不会主动判断“你这个备份策略是不是真的可靠”。

9. 如果让我重新做一遍，哪些步骤我会调整

项目收尾后我复盘过几次。如果现在再让我从零做一套类似系统，至少有三个地方我会调整。

第一，先花更长时间设计数据模型和状态机，不要急着让 AI 写代码。第一版数据模型里，我把“费用类型”设计成了固定枚举，后来发现不同企业的费用类型差异极大，改成可配置表后又连带改了五六张表的结构，浪费了不少时间。如果一开始就把“哪些是固定项、哪些是配置项”想清楚，后续能省掉大量返工。AI 编程再强，也帮你弥补不了“表结构设计不合理”的坑。

第二，前端页面的开发顺序应该从“核心业务链路”开始，而不是从“列表页”开始。我先做了报销单列表，再做报销单填写，最后做审批页，这个顺序导致我在写报销单填写页时反复改列表页的状态逻辑。正确顺序应该是先把“填写→提交→审批→通过→打款”这条主链路完整跑通，再去补列表、筛选、统计这些外围功能。这一条建议对所有中小型业务系统都适用，不只是 AI 编程项目。

第三，尽早引入模拟数据。AI 编程项目很容易陷入“代码生成得爽，但没有数据可测”的状态。我应该在做完数据模型后立刻写一个 seed 脚本，填充两个租户、十几个用户、几十张报销单的模拟数据。这样在 AI 生成前端页面时，我能立刻看到实际渲染效果，也能更早发现字段映射错误。模拟数据对 AI 编程的帮助是隐性的，但非常关键，它让 AI 的代码始终有“可验证的真实输入”。

10. 关于 AI coding 水位线，我的最终判断

回到最开始的问题：当下 AI 编程的真实水位线到底在哪里？经过这套 SaaS 报销系统之后，我的判断是：AI 已经能覆盖中小型业务系统大约六到七成的编码工作量，尤其擅长 CRUD、表单页面、基础接口这类“模式化”工作。但在流程引擎、权限模型、数据一致性、合规安全这些需要全局视野和业务判断的地方，AI 的能力仍然只是辅助。

它更像一个记忆力和执行力都很强的初级开发，而不像资深架构师。你可以把“怎么做”的细节交给它，但“做什么”和“为什么做”必须自己拿主意。如果你本身没有足够的技术判断力，AI 编程给你带来的不是效率提升，而是代码库的失控。反之，如果你能像带新人一样给它清晰的任务边界和验收标准，AI 编程能让你产生“一个人活成一支队伍”的错觉——其实是错觉，因为你身后站着一个永不休息的初级开发，而你变成了那个既要定需求、又要做 review、还要负责兜底的 tech lead。

这次经历之后，我个人的工作习惯也变了。以前遇到一个不熟悉的库或者新框架，我的第一反应是找文档、翻示例。现在我会先让 AI 生成一个最小可用示例，跑通后再回到文档里确认细节。这个模式省时间，而且能逼着我更快建立对陌生技术栈的“手感”。

最后说点实在的。这套报销系统目前已经在内部小范围使用，跑了两周，没有出过大问题。但我心里清楚，它能稳定运行不是因为 AI 生成的代码质量有多高，而是因为我在关键节点上花了足够多的时间去 review 和补测试。AI 编程的确把 SaaS 系统的开发门槛拉低了，可“从零到上线”这件事，真正值钱的从来不是代码怎么敲，而是你知道系统应该长成什么样，以及在它出问题时知道去哪里查。这个判断力，现在还没有任何 AI 能替代。