AI编程真实水位线：一个人用AI辅助从零开发并上线SaaS报销系统

我先说个前提这次不是来吹“AI编程又多神”的也不是来劝退“AI写不了生产代码”的。我花了几周业余时间一个人靠AI辅助从零做了一套SaaS报销系统并且真实上线跑了业务。整个过程我记录了AI在哪个环节真给力、在哪个环节反复挖坑、在哪个环节彻底失能。这篇文章就是这份“实测报告”用报销系统这个不算复杂但五脏俱全的业务来量一量当下AI coding的真实水位线到底在哪。报销系统在技术圈眼里属于“业务不性感、逻辑不复杂”的典型项目但真正做过的人知道里面塞满了审批流、权限矩阵、金额精度、审计追溯这些要命细节。选它当试金石就是因为它的复杂度贴近真实企业应用又比电商、IM这类系统好收敛。如果你正纠结“一个人到底能不能靠AI把产品做上线”或者已经在用AI写代码但总觉得哪里不对这篇文章应该能给你一个比较实诚的坐标系。1. 为什么拿“报销系统”当AI编程的试金石1.1 报销系统看着简单实际上踩遍了SaaS的标配需求很多人觉得报销系统不过就是“填单子、传到领导那里点个同意”这认知和实际差得很远。一个能卖给企业的报销系统至少要吃下这些硬需求多租户隔离不同企业登录同一套系统数据绝对不能串角色权限员工、部门主管、财务、系统管理员各自能看的数据范围完全不同审批流多级审批、条件审批、金额阈值跳级审批、报销人不能审自己状态机草稿、审批中、已通过、已打款、已驳回、已撤回以及撤回和驳回之后的状态流转资金敏感金额字段的精度、并发提交时的幂等、历史单据不可篡改附件管理发票图片、PDF上传下载还要做防篡改校验这套需求拆下来基本覆盖了一个SaaS产品从数据模型到权限安全再到合规追溯的全部核心环节。它不涉及高并发高吞吐这些互联网极端场景但对业务正确性和数据安全的要求一点都不含糊特别适合用来测AI的真实水准。1.2 我的MVP范围是怎么圈的一个人做项目最怕的就是范围失控。我在动手之前做了一个很克制的MVP清单角色员工、部门主管、财务、管理员流程员工创建报销单 → 提交审批 → 部门主管审批超过设定金额自动升级到上级 → 财务审核 → 出纳打款 → 流程结束功能报销单CRUD、附件上传、审批操作、审批历史、简单统计报表、组织架构部门/用户管理不做预算控制、电子发票真伪查验、工资/总账对接、多语言、移动端App这个范围是我刻意设计过的。它既能覆盖“从零到上线”的完整链路又不会让文章演变成“我一个人做了一个财务中台”的离地故事。后面所有关于AI能力的判断都是在这个MVP范围内实测出来的。技术栈我也选了AI训练语料覆盖密度最高的那一套后端FastAPI SQLAlchemy PostgreSQL前端Vue3 Element PlusRedis做缓存和会话Docker Compose做本地编排云服务器加Nginx部署。选择这套组合有一个非常现实的原因AI在语料越密集的技术栈上表现越好同样的逻辑用冷门框架写AI的出错率会肉眼可见地上升。这本身就是AI水位线的一部分。2. 工具组合与提示词策略我把AI当结对程序员而不是搜索引擎2.1 我实际用下来的工具组合市面上AI编程工具一大堆我前后试了GitHub Copilot、Cursor、通义灵码、CodeGeeX还有几个对话型大模型。结论不是“谁最好”而是“每个工具在最合适的场景里都有不可替代的位置”。工具类型代表我用来干什么体验评价AI原生IDECursor日常主力开发跨文件改代码上下文感知最强能读整个项目IDE插件GitHub Copilot、通义灵码补全、小函数、临时重构适合在已有代码里快速填空对话型大模型Claude、GPT类架构设计、疑难排查、代码review思考深度最好但需要你自己喂上下文国内大模型通义千问、Kimi网络环境下的备案、部署类查询对国内云服务和合规场景更熟悉如果你用的是IntelliJ IDEA这类传统IDECopilot类插件的体验和VS Code差距不大但面对跨文件重构时AI原生IDE的优势非常明显。我最后固定成“Cursor写业务代码 对话型大模型做架构决策和代码审查 国内模型查国内云平台文档”的组合。工具不是越多越好关键是每个工具在什么环节服务你想清楚这一点效率会翻倍。2.2 提示词的三个层次一次性需求、迭代式对谈、代码审查很多人的提示词还停留在“帮我写一个报销系统”这种级别AI返回一堆玩具代码然后得出“AI编程不行”的结论。我实际测下来提示词的质量直接决定了AI输出的水位这是整个项目里最值得投入时间去练的部分。我把提示词拆成三个层次第一层一次性需求描述。当一个任务边界清晰时我用结构化方式下需求包含背景、输入、输出、边界条件和验收标准。举个例子让AI生成创建报销单接口时我不会说“写个接口”而是这么写需求报销单创建接口 背景用户在前端填写报销单包含费用明细列表和附件ID列表提交后状态为草稿 输入title, category, amount_total, expense_items[{category, amount, description, receipt_id}], attachments[{file_id, filename}] 要求 1. 总金额必须等于明细金额之和不一致则返回400 2. 所有金额字段使用Decimal禁止使用float 3. 使用事务写入主表和明细表 4. 写入成功后返回报销单完整信息包含生成的id 5. 校验当前用户必须登录且属于当前租户 请生成FastAPI的接口代码包含Pydantic模型这个层次的提示词AI返回的代码质量非常高CRUD接口基本一次就能跑通。我把核心秘诀归纳为不要让AI猜你的意图它猜不准的。第二层迭代式对谈。改代码时最关键的一条经验是“一次只让AI动一个文件而且只改增量”。我经常这样要求“不要重写整个文件只输出需要修改的部分用diff格式。”因为AI一旦重写整个文件经常会把前面改好的逻辑悄悄改坏这是AI coding最典型的隐形坑。用diff格式还有个好处我能清楚地看到它改了什么review成本大大降低。第三层代码审查。写完代码后我会让AI自己当reviewer“请检查这段审批流代码找出边界条件问题”“如果100个报销单同时提交这段代码有什么并发问题”。AI在挑错场景下的表现比它直接生成代码要好得多。这很反直觉但非常实用——AI当“挑刺者”比当“创造者”更可靠。我甚至养成了习惯每次AI写完代码必要它自己先review一遍再交给我。2.3 项目规则文件是AI协作的定海神针我在实测中踩过一个很深的坑AI会遗忘你之前说过的全局约束。项目进行到第二周我让AI新增一个接口它居然又用了float字段来定义金额导致和数据库Decimal列类型不匹配跑起来直接报错。原因很扎心——大模型的上下文窗口是有限的你第100次对话时它早就记不清第5次对话里定的规矩了。解决办法是我后来才发现的关键在项目根目录维护一个规则文件。我给它起名叫CLAUDE.md某些工具也读AGENTS.md或项目说明文件里面写清楚技术栈、全局约定、命名规范、典型的业务规则。比如# 项目全局规则 - 后端FastAPI SQLAlchemy 2.0 PostgreSQL - 所有金额字段必须用 Numeric(12,2)代码层用 Decimal - 所有表必须有 tenant_id任何查询不得遗漏租户条件 - 所有写操作必须写入审计日志包含操作前值和操作后值 - 状态字段用英文枚举值禁止中文存库 - 前端Vue3 Element Plus页面路由统一走 /src/views每次会话开始时我都会让AI先读这个文件再回答问题。规则文件彻底解决了AI的“记忆漂移”问题这是整套协作流程里性价比最高的一件事。之后AI生成的代码风格一致性和命中率都有了质的提升。3. 全程效率实录哪些环节AI给力哪些环节AI拉胯3.1 AI高光时刻数据建模、CRUD接口、前端页面生成先说结论AI在最“规范化”的环节表现惊人。第一个高光时刻是数据库建模。我把MVP里需要的二十来张表包括用户、角色、权限、部门、报销单、费用明细、附件、审批记录、审计日志全部交给AI生成。它按照我给的规则文件一次性产出了完整的SQLAlchemy模型字段类型、外键关系、索引设计基本合理我用navicat看起来至少不是“玩具水平”。尤其让我意外的是它自动给所有表都加了tenant_id字段并在模型层面做了声明——这正好呼应了我在规则文件里写的“所有表必须有tenant_id”的约定。第二个高光时刻是常规CRUD接口。FastAPIPydanticSQLAlchemy这套组合里的增删改查AI生成质量几乎可以到“免改”级别。我统计下来MVP里的基础接口大概60个其中70%以上AI一次生成就能通过联调剩下30%需要修的大多是业务边界条件比如某个字段是否允许为空、某个状态下能否删除之类。这类修修改改也很快基本就是我再提一句它再改一版的事。第三个高光时刻是前端表单页面。Vue3Element Plus的表单AI能根据后端模型直接生成可用的页面字段对齐、校验规则都有。对一些简单的列表页和详情页AI生成的代码甚至可以直接用。但这里也有个前提——我让它统一从规则文件里读取“前端常用组件封装”的约定并且先让它生成一个基准页面后续页面全部复制这个基准改。否则每个页面风格会五花八门。我实际体感是凡是“规则明确、输入输出清晰、业界有大量范式可循”的工作AI贡献度基本能到90%。这些工作也是普通程序员日常占比最高的部分所以AI确实把这部分时间压缩到了一个不可思议的尺度。原来写一个带校验的接口加页面人工要半天AI加微调半小时搞定。3.2 AI拉胯场景审批流状态机、多租户数据隔离AI真正拉胯的环节刚好是报销系统最核心的部分。这也是我标题里“真实水位线”的关键证据。第一个重灾区是审批流状态机。我最初的提示词是“实现一个报销单审批流支持按金额条件跳级审批”。AI第一次写的是一长串if-else逻辑审批状态写死在函数里扩展性几乎为零。我让它按状态模式重构它倒是很听话但重构之后的状态转移表里漏掉了“已撤回”状态——报销单在“审批中”被撤回后整个状态机就卡死了任何操作都返回“非法的状态转换”。最麻烦的是“报销人不能审自己”和“金额超过阈值自动跳级”这两个规则。AI要么漏掉前者要么把后者写成一个永远不触发的死条件。我用具体的测试数据去验证前前后后返工了三四次最后是我自己手动把状态转移表全部列出来重新给AI描述了一遍“每个状态下允许哪些操作、流转到哪个状态”它才给出正确实现。这部分工作时间AI省不了多少它把错误代码翻来覆去地改很多时候反而增加了工作量。第二个重灾区是多租户数据隔离。AI生成的单表查询通常都会带tenant_id条件但只要涉及联表查询或者子查询它就特别容易“忘记”租户条件。比如查询“某部门所有报销单包含审批人姓名”AI生成的SQL里经常是直接JOIN user没有加上user.tenant_id current_tenant_id结果就是A企业的员工在列表里看到了B企业的人名。这类问题是上线前必须逐条排查的因为测试环境数据量小、肉眼不容易发现一旦上线数据串租户就是重大安全事故。我的整改方案是把所有查询收口到一个BaseRepository基类里强制统一加租户条件不再允许散落的自由SQL。这个改造过程AI帮了忙但它生成的第一版代码反而增加了混乱度——因为它把原有查询里的where条件拼错了位置导致id字段冲突。最终是我手工梳理逻辑再把修改方案交给AI执行。第三个让我头疼的是并发和幂等。员工快速连续点了两次“提交报销单”系统生成了两条一模一样的单据金额double计算。AI一开始没有处理这类幂等需求我需要自己提“创建报销单接口要做幂等控制用唯一索引约束相同来源的重复请求”它才会去实现。这种“你不说它就不做”的问题在整个项目里反复出现。4. SaaS上线前绕不开的硬骨头权限、审计与数据不可篡改报销系统的数据涉及企业资金和员工隐私数据安全不是“功能”是“底线”。我在这部分花了很多精力也真实感受到了AI在安全敏感场景下的局限性。下面把核心设计拆开说。4.1 多租户权限模型AI容易写成“看起来对”的代码权限模型我采用的是经典RBAC但在多租户场景下需要叠加租户边界。核心表包括租户表、用户表、角色表、权限点表、用户角色关联表、角色权限关联表。AI能很顺畅地生成这六张表和基础的查询接口问题出在“行级权限”。举个例子财务角色可以查看所有部门的报销单但部门主管只能查看本部门的报销单。这个“本部门”的过滤条件AI在单表查询里没问题但在“查看某员工的报销单详情同时显示审批历史”这种联表场景里就很容易漏掉部门过滤。我让AI写一行查询“当前主管查看的报销单是否属于自己部门”它给出的代码是def can_view_expense(expense, user): return expense.department_id user.department_id看起来没问题对吧实际上它没考虑“财务角色有全量权限”这个例外。角色判断和部门过滤的组合条件AI经常漏掉一侧。最后我明确在规则文件里写死“行级权限方法必须先判断角色再判断部门顺序不可颠倒”并让AI统一调用一个PermissionService才把这个坑填上。这里要补充一个我实测下来很关键的建议权限相关代码每次生成后都要亲自用不同角色实际跑一遍测试。不要用“代码看起来对”来判断要用三种角色、两种数据范围本部门/跨部门、三种状态草稿/审批中/已通过去凑成组合测试矩阵。AI自己生成的单元测试往往只覆盖了“管理员能通过”这种最简单的路径远远不够。4.2 审计日志与防篡改设计在数据库层和对象存储层怎么做数据“不可篡改”是报销系统的高频热搜词也是财务合规的核心诉求。我采用的方案分四层每一层都是上线前必须落地的第一层操作审计日志。我在数据库里设计了一张audit_log表字段包括操作人、操作时间、操作类型新增/修改/审核/驳回/打款、业务表名、业务记录ID、变更前值JSON、变更后值JSON、操作来源IP和用户代理。关键一点是“变更前值”和“变更后值”必须同时记录。AI第一次生成的审计代码只记录了变更后值没有记录变更前值导致无法回溯“这个金额是谁从5000改成10000的”——这正是审计日志存在的意义。发现后我把它列入规则文件并让AI在写所有写操作时强制调用审计服务。第二层数据库级防删除。对核心业务表我禁止物理删除和物理更新。所谓“更新”在报销系统里其实是“作废旧版本写入新版本”。我在数据库层用PostgreSQL触发器拦截核心表的DELETE语句一旦检测到直接抛出异常。更新操作则通过应用层完成且更新前必须生成审计记录。这个触发器的原理很简单CREATE OR REPLACE FUNCTION prevent_delete_expense() RETURNS TRIGGER AS $$ BEGIN RAISE EXCEPTION 核心业务表禁止删除记录; END; $$ LANGUAGE plpgsql; CREATE TRIGGER trg_prevent_delete BEFORE DELETE ON expense FOR EACH ROW EXECUTE FUNCTION prevent_delete_expense();触发器本身是几行代码但配置Trigger、写测试验证“确实删不掉”、确认不影响正常业务操作这些工作AI没法替你完成因为它不知道哪些表属于“核心业务表”哪些可以删。这需要业务判断力。第三层行版本号乐观锁。写操作更新前必须校验版本号版本号不匹配说明有并发冲突。我用一个version整数字段更新时执行UPDATE expense SET ..., version version 1 WHERE id ? AND version ?受影响行数为0则抛并发异常。这用来防止两个财务同时审核同一张单子导致的“双认可”。第四层附件防篡改。发票和报销单附件我放在对象存储里开启不可变对象策略文件上传后不允许覆盖和删除同时在上传时计算MD5并存入数据库。审计时把附件重新计算MD5和库里存储的比对不一致就说明文件被动过。对象存储的权限策略也遵循最小权限原则对外只提供预签名URL临时访问不允许公开读。AI在这四层安全机制里的表现参差不齐审计代码它能写个大概但容易漏“变更前值”触发器它能写对语法但不知道加在哪些表上对象存储的WORM策略它只能给你参考文档链接具体配置还是得自己对着云厂商控制台点。安全是“水位线”最低的区域之一这里不建议完全依赖AI上线前的安全自查必须人肉做一遍一条条核对。5. 部署上线与真实运营AI能写代码但扛不住“生产环境”的毒打5.1 容器化部署和CI/CD哪些部分AI能接手从“本地能跑”到“线上稳定运行”中间的距离往往比从零到Demo还远。我用Docker Compose做本地编排线上用一台云服务器部署Nginx、后端容器、PostgreSQL和Redis。AI在这些环节的参与度同样是不均匀的DockerfileAI能生成能用的基础版本包括Python依赖安装、健康检查、非root用户启动等最佳实践这部分贡献不小。环境变量管理AI不会知道哪条密钥该放生产配置哪条放测试环境。它在docker-compose里暴露了我一个数据库密码我review时发现并改成了从.env文件注入。这类安全习惯不能指望AI自觉。GitHub ActionsAI生成的CI配置“看着很完整”但第一次跑就挂了——它把Python版本写成了当时不存在的版本号而且测试命令里漏掉了迁移步骤。这些小坑都是上线前必须自己跑一遍流程才能发现的。我体会最深的是AI能把部署脚本写到“在干净服务器上能跑起来”的程度但生产环境需要的日志轮转、备份策略、自动重启、监控告警它给的方案都很“教科书”要么缺少对数据量的考量要么没有预留故障恢复预案。这部分工作是“经验密集型”的也是AI水位线明显下降的区域。5.2 上线后第一周我处理的三个生产问题上线一周我就遇到了三个AI无法预判的真实生产问题每一个都值得单独说。第一个是时区错乱。测试阶段数据量小、操作时间集中没人在意时区。上线后有用户反馈他8月1日提交的单子在列表显示7月31日。排查后发现后端存储用的是UTC时间前端直接拿UTC字符串渲染没有转成中国时区。AI给出的修复方案是“前端用dayjs转时区”但改完之后导出的Excel又出现了时间偏移——因为导出时后端直接序列化了UTC时间。最后我手工把规范定为“后端统一存储UTCAPI层统一返回不带时区的本地时间字符串前端不做任何额外转换”才算彻底解决。这个问题AI只能给出点状修复系统性规范必须人来定。第二个是附件上传超时。正式使用时用户上传手机拍摄的原始发票图片一张十几MB默认网关超时时间根本不够上传到一半就断。我让AI改成前端分片上传它给出的方案分片大小和并发度没有结合服务器带宽导致分片并发一高就触发服务器CPU飙升。最后是我手动把分片大小调成2MB、并发限制为3才算稳定。这种性能调优AI缺少“真实环境反馈”没法凭空算准参数。第三个是Redis缓存穿透。我在审批人列表上加了缓存但没考虑这个大列表也被用于权限判断结果高并发审批时缓存失效瞬间大量请求直接打到数据库数据库连接被打满服务一度不可用。AI修复方式是“加空值缓存”但没解决“缓存雪崩”问题。最终方案是让缓存永不过期依赖审计日志和人工刷新机制保证数据新鲜度。这个方案对报销这个低频业务足够但对高频场景可能就不适用——这种取舍AI给不出。这三个问题说明一件事生产环境的问题从来不只是“代码bug”它是数据、网络、用户行为、资源限制交织在一起的结果。AI能帮你写修补代码但问题的定位、方案的选择、验证的手段依然依赖人的系统思维。这部分体验是我对“AI coding水位线”最清醒的认识。6. AI coding水位线的量化结论它到底帮了多少忙做了这么多实测最后肯定要回到数据上。我给每个环节打了一个“AI有效贡献度”的评分注意这里的贡献度不是“AI写了几行代码”而是“AI真正节约了我多少有效时间”研发环节AI有效贡献度我的体感说明需求梳理与范围圈定10%需要和真实用户聊AI只能帮忙列问题清单技术选型与架构设计40%能给出对比方案但业务正确性判断靠自己数据库模型设计70%常规表一次成型复杂关联需要人工修正CRUD接口/表单页面90%一次性生成的命中率极高基本就是粘贴改改审批流/权限等业务规则30%反复返工最终靠人肉梳理状态转移表单元测试50%能写“正确路径”测试边界场景需要人补部署运维/CI/CD30%生成能用但踩坑修复靠生产环境反馈线上问题排查20%定位主要靠人AI只能提供排查建议从代码产出量看整个项目大概70%的代码由AI直接生成或者基于AI生成代码修改完成。但你要问我“省了70%的时间吗”答案是没那么多——因为AI生成的代码需要review、需要调试、需要重构这部分隐性工作吃掉了很多“表面节省”。我的真实体感是整体工期大约缩短了50%-60%。举个例子如果没有AI这个项目我一个人预估需要14到16周其中大部分时间花在写CRUD、写页面、调样式这些“劳动密集型”工作。有了AI这些环节压缩得非常夸张总工期大概压到6周左右。但请注意这6周里我花在“搭权限框架”“修审批流”“补审计逻辑”“排查线上时区”这些硬骨头上的时间占比反而更高了。AI把“简单但量大”的事情做得又快又好但把“复杂且需要业务判断”的事情留给了你——一个项目里真正决定成败的恰恰是后者。再说宽一点“一个人AI做SaaS”这个模式目前可行的前提是这个人得具备完整的工程能力。AI可以帮你写出80分的代码但“为什么这个需求要实现”“这个方案有哪些风险”“线上出问题了从哪里查”这类问题AI无法替你回答。如果一个人完全不懂编程指望AI从零搭出生产级SaaS我的结论是不要信那些演示视频。如果一个人已经有独立开发能力AI的价值就是把你从“手写体力活”里解放出来让你有更多精力去思考那些真正有壁垒的事情。7. 给也想尝试“一个人做SaaS”的人几条实在建议如果你看完上面的实测还是决定要试一次“一个人AI”的项目下面这些建议是我真金白银踩出来的直接拿走能用。第一把规则文件当项目最核心的资产。第一次写项目时第一件事就是写CLAUDE.md把技术栈、全局约束、命名规范、典型业务规则全部写进去。每次会话先让AI读这个文件。我在前面吃过AI忘掉金额精度规范的亏自从规则文件生效之后这类问题出现的频率直线下降。规则文件要持续维护每次踩坑后把修复经验补进去把它当成项目的“宪法”。第二一次只让AI动一个文件。跨文件的“AI重构”目前看是一场灾难——它改完A文件经常会忘记了B文件里依赖A文件的接口。要它改跨文件的东西宁可分解成多个单文件的对话每步都验证可运行再走下一步。用diff格式输出变更这点也很重要防止它把无关代码改坏。第三AI生成的代码也要全量review重点盯四类问题金额字段精度、租户/权限条件、状态机流转、幂等控制。用小白的话说就是“跟钱有关、跟权限有关、跟流程状态有关、跟重复提交有关”的代码绝对不能闭眼信AI。这是整个项目里我唯一强调“必须人工把关”的地方。第四先写测试再让AI实现。这一点很反直觉但实测效果非常好。你先用自然语言描述测试用例“当员工提交超过2000元的报销单时审批流应自动跳到上级主管”然后让AI根据这个测试去实现代码。相当于先立标准再让AI交卷它会比自由发挥认真得多返工率大幅下降。第五安全底线不要交给AI把关。多租户隔离、审计日志、数据库防删除、附件防篡改、密钥管理这五件事必须你自己懂原理、自己检查线上配置。AI能帮你写代码片段但它不会知道你哪条数据最敏感、哪个接口最容易泄露。报销系统的数据安全不可篡改最终是靠人在架构层面设计出来的不是靠AI“顺手写对”的。最后聊点个人感受。这套系统上线后我已经让宜家帮我联系了朋友公司试用真实跑了两个月的报销流程。期间遇到过用户抱怨附件传半天传不上的问题也遇到过财务要求加“批量打款标记”的需求。每一次迭代AI都参与了但每一次决策都是我在输入法里打字敲出来的。AI coding的真实水位线既不在营销号的“五分钟做出一个App”里也不在悲观者的“AI写不了生产代码”里。它就在你对自己项目理解深度和工程能力的延长线上——AI能把你的能力放大很多倍但它没办法凭空给你能力。把它放在正确的位置上一个人做成一套SaaS报销系统是可行的而且这段经历的价值可能比系统本身更大。