一个人对着屏幕从数据库建表写到前端页面再从权限模型调到部署上线最后真把一套 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 严格按表实现。比如当前状态操作允许角色目标状态副作用draft提交申请人pending创建审批实例通知第一节点审批人pending通过审批人approved / next_pending创建审批记录若已到最后节点状态改为 approvedpending驳回审批人rejected创建审批记录通知申请人rejected重新提交申请人pending创建新的审批实例保留原履历approved打款财务paid创建打款记录通知申请人这种方式的效果立竿见影。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 里写。整个项目整体耗时记录如下阶段主要工作实际耗时参照我过去纯手写的预估耗时需求与数据模型业务流程梳理、表结构设计2 天2 天API 与数据库迁移脚本、模型、CRUD 与基础查询3 天7 天审批流引擎状态机、审批链配置、历史记录5 天7 天前端页面登录、报销单填写、审批列表、报表页6 天14 天权限与安全多租户过滤、审计日志、加密3 天4 天测试与修复自动化测试、联调 Bug、边界场景4 天4 天部署上线域名、备案、Nginx、Docker、HTTPS1 天1 天合计投入大约 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 能替代。