一个人用AI编程从零开发SaaS报销系统的实战拆解：架构、安全与提示词方法

三个月前我给自己定了一个有点“不切实际”的目标一个人不花一分钱外包费只靠AI编程工具从零到上线一套SaaS报销系统。选定报销系统当试金石不是因为它简单恰恰相反——它比大多数网红级CRM、待办清单类Demo复杂得多多租户、RBAC权限、审批流状态机、发票信息抽取、金额精度、审计日志、财务导出样样都是企业级痛点可业务逻辑又足够清晰透明不怕AI“自由发挥”出花活。这三个月跑下来我对当下AI编程的真实水位线有了远比道听途说更具体的认知哪些环节AI能一天干完哪些环节它会一本正经地给你埋雷哪些设计决策只能人脑拍板。这篇文章不打算写成“我用AI做了个项目真厉害”的流水账。我会尽量把项目从头到尾的拆解思路、每一步的技术选型、每一次让AI翻车的细节都摊开讲尤其会把SaaS系统绕不开的数据安全、租户隔离和防篡改设计单独拿出来说。如果你正打算一个人做SaaS或者想评估自己要不要上AI编程这趟车这篇应该能帮你省掉不少本不用踩的坑。1. 为什么拿报销系统当AI编程的“试金石”1.1 一套报销系统到底藏了多少复杂度很多人一听“报销系统”第一反应是“不就是填个单子、走个审批、导出个Excel吗”。等真动手拆需求才发现这玩意儿是个标准的“麻雀虽小五脏俱全”。我梳理MVP时盘出了六个核心模块登录认证与租户管理、报销单创建与发票信息提交、审批流多级、可驳回、财务复核与打款状态管理、审计日志与操作留痕、数据导出与统计报表。光是“审批流”这一个模块就涉及草稿、待审、已通过、已驳回、已支付、已归档等状态还可能要支持按金额阈值自动跳转不同审批人。更别说“发票”这件事背后还有税号校验、抬头校验、金额一致性比对、连号发票风控等一堆细节。这些复杂度叠加在一起让报销系统成了测试AI编程能力的优质样本它既有大量重复性CRUD代码供AI高速产出又有一套状态流转逻辑要求代码的严谨性远高于“能跑就行”。我判断如果AI编程能把报销系统这套流程拿下来那市面上大部分内部管理系统、行业SaaS的常规功能它大概率也撑得起来。1.2 一个人加AI在2025年是个什么状态先说结论一个人加AI做SaaS在技术上完全可行但在产品定义和工程决策上AI替代不了人。这里不卖焦虑只说我的实际体感。过去一个三人小团队从零开发一个SaaS后端加前端保守估计要两到三个月。我用AI编程从数据库建模、接口开发到前端页面和部署上线核心周期压缩到了五周左右后面剩下的时间全用在改Bug、补边界条件、做安全加固和数据迁移上。换句话说AI真正省掉的是“从无到有”的编码时间而“从有到稳”的工程时间省得有限甚至因为AI引入的隐蔽问题还要额外花精力去排查。我的判断是当下AI编程的真实水位线处于“高级实习生到中级工程师之间”的状态。它写CRUD、搭页面、写单元测试、做数据模型草案效率远高于人类但涉及全局架构、异常分支、安全边界、性能优化这些需要系统思维的环节它经常给出看起来很合理、实则经不起推敲的方案。所以“一个人AI”的黄金组合不是让AI独立开发而是让AI当高强度执行者人当架构师、审查者和最终责任人。这个定位想清楚后面所有工作流都会顺很多。2. 技术选型和SaaS安全设计不能省2.1 我的技术栈选型与理由关于AI编程最厉害三个软件之类的问题网上吵得不可开交。我不打算站队只说我自己的配置主力IDE用VS Code加GitHub Copilot复杂模块的生成会话用Cursor配合Claude模型国产模型我也试过通义灵码用于写单元测试和注释补全体验还行但代码生成的长链路推理能力还是跟国际第一梯队有差距。工具本身不重要重要的是你要有一套跟AI协作的流程这我会在第四章详细展开。技术栈方面我选了Next.js TypeScript Prisma PostgreSQL。这套组合的优点有三个第一TypeScript的类型系统能帮AI生成的代码提前暴露一批低级错误比如字段名拼错、类型不匹配第二Prisma的schema定义非常直观AI很容易生成规范的数据模型而且数据库迁移流程清晰出问题可以回滚第三Next.js前后端一体一个人维护时心智负担最小不用同时维护两个代码库。这里想特别提一句如果你是完全的新手我不建议直接上手这套组合。至少要把TypeScript基础语法、REST API基本概念、数据库表关系搞明白否则AI生成的报错信息你也看不懂。AI编程能放大你的能力但不能凭空创造你没有的工程认知。2.2 多租户隔离AI最容易犯迷糊的地方SaaS和普通项目的最大区别就是多租户。每个企业客户是一个租户租户之间的数据必须严格隔离。我在给AI下达数据模型任务时第一版它就犯了一个经典错误所有表都加了userId字段却没有统一的tenantId设计一旦不同企业下存在同名用户数据就串了。多租户隔离在业界主要有三种方案独立数据库、独立Schema、共享表加租户ID字段。独立数据库隔离性最强但成本最高适合大客户共享表成本最低但风险最高需要对每一行SQL都做租户条件约束。我采用的是“共享表tenantId字段底层强制过滤”的折中方案Prisma中间件里统一注入租户过滤条件应用层再对关键查询二次校验。这样即使AI生成的某个查询漏了租户条件数据库层也会兜底拦住不让数据跨租户泄露。这个设计必须人工把关AI不会主动给你加。我当时在提示词里明确写“所有查询必须包含tenantId条件”结果它只在明显的地方加了嵌套查询和关联查询里照样漏。后来逼着AI生成了一个Prisma扩展在中间件层统一处理才彻底堵住这个漏洞。2.3 数据安全防篡改与审计日志怎么落地热搜里有人问“SaaS系统怎么确保数据安全不可篡改”这个问题正好是我开发时较真过的。说实话要做到绝对不可篡改任何软件层面方案都做不到我们做的只是让篡改行为可发现、可追溯、可举证。报销系统涉及财务数据审计合规是刚需我落地了三个层次的防篡改机制。第一层是操作留痕。所有关键操作包括创建报销单、修改金额、审批通过、驳回、打款状态变更全部写入独立的审计日志表记录操作人、操作时间、操作前后数据快照、IP地址和操作类型。这一层实现简单AI就能写但它只防君子不防小人数据库管理员还是能改。第二层是哈希链校验。我给每一条报销记录增加了一个hash字段计算规则是当前记录哈希值 哈希算法(上一笔记录哈希值 当前记录核心字段拼接)。这样任何人对历史数据的修改都会导致哈希链断裂定期跑校验脚本就能发现异常。这个思路借用了区块链的技术理念但实现成本很低AI在明确提示下也能完成。第三层是定期对账与导出归档。每周自动生成一次全量数据快照通过邮件发送到指定邮箱留存同时把核心财务数据生成PDF归档。这种线下备份方式看起来原始但恰恰是最难被篡改的——攻击者就算黑进数据库也改不了邮件里的历史快照。设计这三层方案的时候我深刻体会到让AI写代码容易让AI设计安全方案很难它不会主动思考“如果数据库被入侵怎么办”这种问题。3. 从零到上线核心模块开发实录3.1 第一步把需求拆成AI能理解的最小单元跟AI协作最大的教训是你给它一个笼统任务它就会还你一个笼统而“正确”的废物。我第一次让AI“生成报销单创建页面”它输出了一个字段只有金额和备注的精简版连发票号、费用类型、报销事由这些基础字段都没有。不是AI能力不行是我的需求描述不达标。后来我把需求拆成“AI提示词模板”角色定义、业务背景、输入输出、数据字段清单、界面要求、必须处理的边界情况。比如创建报销单这个功能我给AI的提示大致是系统是面向中小企业的SaaS报销系统需要实现报销单创建与保存草稿功能报销单字段包括报销单号系统生成、费用类型、费用金额两位小数、发票张数、发票信息列表、报销事由、关联项目、备注必须校验金额大于0且小数点后不超过两位发票信息必须包含发票代码、发票号码、不含税金额、税额保存草稿不做金额校验提交时做完整性校验页面展示当前用户所属租户的可用项目列表。这种结构化提示下AI生成的代码可用性直接提升了一个档次至少首次生成就能达到60分的水平。剩下的40分靠的是第三章要讲的代码审查和边界补全。3.2 认证与权限这里必须人工盯登录认证这块我没让AI从零造轮子而是直接用了NextAuth框架让AI基于官方文档写集成代码。这算是我总结出来的一个经验凡是成熟框架已有最佳实践的领域不要让AI自由设计让它当文档翻译器就好。AI对NextAuth这种框架的API记忆通常比较准确生成的代码基本能跑通注册、登录、Session管理、邮箱验证这些基础流程。但到了权限控制这里AI就开始暴露出问题。我设计的权限模型是三层的平台管理员、企业管理员、普通员工同时还有数据范围控制——普通员工只能看自己和下属提交的单据企业管理员能看到全公司数据平台管理员只能看运营数据不能看财务明细。这种RBAC加数据范围的组合权限AI经常把“接口返回了数据”当成“用户有权限看数据”把权限判断写在按钮上却没在接口层做拦截。后来我要求AI把权限校验做成一个统一的高阶函数部署到所有API路由上同时在后端重新校验前端传递的权限参数。那段代码几乎是我一行行和AI对着改出来的前后花了三天。每次有人问我“AI能不能替代程序员”我脑子里第一个反例就是这里——权限模型漏一个校验点轻则越权访问重则整个SaaS的数据安全出问题这不是AI能替你担责的事。3.3 审批流与状态机AI写出过的最贵Bug审批流是整个项目里让AI消耗最多代币的模块。我盘了一下前后为这个模块写了大概三十多次提示词迭代生成的代码被推翻重写了三轮原因都是状态流转逻辑不可靠。最典型的一个BugAI在审批驳回后直接把状态置为“已驳回”但用户重新编辑提交后新生成的记录状态没有正确回到“待审批”导致审批人列表里永远看不到这条重新提交的单据。排查半天后发现AI没有在状态流转方法里做前置状态校验任何状态下都能调用“提交审批”方法把状态机活活写成了“状态变来变去”的混沌机。解决办法是让AI先只生成状态枚举和流转表不写业务代码。我在提示词里给了它一个五乘五的状态迁移矩阵明确标注了每个状态下允许执行的操作和下一个状态。等它把状态机的核心逻辑单独抽成一个类、每个流转方法都接收当前状态参数并校验合法性之后才让它接入业务代码。经历了这个阶段我更加确信越是有明确状态流转规则的业务越要让人先把规则定义清楚AI只负责把你定义的规则翻译成代码而不是替你定义规则。3.4 发票识别、金额校验与财务导出发票信息抽取我用了现成的OCR云服务没有让AI自研。原因很简单OCR识别涉及图像处理、版式分析、数电票解析这是大厂积累多年的技术壁垒一个人加AI在这个方向上死磕投入产出比极低。我做的核心工作是设计“AI解析结果人工确认校验”的双轨流程OCR把发票代码、发票号码、开票日期、购买方名称、不含税金额、税额、价税合计抽取出来填到表单里但用户提交前必须逐项核对关键字段的修改会记录在日志里。AI在这个模块里承担的任务是写校验逻辑金额必须等于不含税金额加税额误差不能超过一分钱发票号码必须符合票种编码规则同一张发票号码不能重复报销价税合计不能超过报销单申请金额。财务导出模块倒是AI表现不错的地方。按Excel模板导出报销单明细、按月度汇总统计、按费用类型生成柱状图这些功能逻辑简单、格式固定AI生成的代码几乎一次通过改动很少。我的感受是AI对“输出固定格式的文件”这类任务掌握得很好但对“判断业务数据是否合理”这类语义理解任务水平还差得远。3.5 部署上线和灰度策略一个人部署SaaS系统我的选择是一台2核4G云服务器Docker Compose编排Nginx反向代理PostgreSQL数据库跑在独立数据卷里。这个配置撑个几十家小企业的报销量问题不大真到性能瓶颈再上K8s不迟。部署过程本身没有太多悬念Dockerfile和compose配置AI能写个八九不离十我要做的只是调好环境变量、配好HTTPS证书、设置好数据库自动备份定时任务。真正麻烦的是上线前的灰度策略——我采用的是“注册制邀请”方式第一批只放10家客户进来提前告诉他们是体验版有问题随时反馈。这10家公司在两周内帮我发现了三个重要问题手机端上传发票图片偶尔超时、审批通知邮件进了垃圾箱、导出Excel在WPS里打开时金额列显示成了文本格式。如果没有这批种子用户这些问题可能到现在还埋在生产环境里。4. AI编程提示词与代码审查的实战方法4.1 让AI少废话多出活的提示词模板先回应一下热搜里的问题ai提示词到底怎么才能写得好我试了十几个风格最终固定下来的模板分四块角色与背景、任务目标、约束条件、输出要求。角色与背景一般是“你是一名有五年经验的Node.js全栈工程师”任务目标我会尽量用验收标准来描述比如“实现一个报销单列表接口支持按状态筛选、按提交时间倒序、分页返回每页20条”约束条件是最要紧的比如“必须使用Prisma访问数据库所有查询必须带tenantId条件金额字段使用Decimal类型禁止使用any类型”输出要求明说“先给出代码文件列表然后逐个文件输出完整代码不解释技术背景不加总结”。这套模板我用了整个项目生成代码的一次通过率从乱问时期的不足20%提升到了接近50%。剩下的一半靠审查和迭代消掉。另外我发现AI编程最厉害的三个软件之间的差异在常规编码任务上其实不大真正拉开差距的是它们对长上下文的理解能力和对复杂指令的遵循程度这也是我建议复杂任务用Claude系模型、常规任务用Copilot的原因。4.2 AI代码审查的“人肉扫描清单”AI写代码速度快但它的错误模式其实很固定。我审查AI生成代码时基本只盯四个方向安全问题、权限问题、数据一致性问题、异常处理问题。安全方向重点看SQL注入和XSS虽然Prisma天然防注入但AI偶尔会生成直接执行原始SQL的代码这个必须看见一个改一个。权限方向看API路由是否有统一鉴权AI最喜欢把权限校验写在组件里结果是接口裸奔。数据一致性方向看事务使用AI生成多表更新代码时往往不包事务报销单主表更新了、明细表没更新数据库就脏了。异常处理方向看它兜底逻辑AI遇到非预期输入时倾向于抛出500错误而不是返回友好的错误提示。我给自己定了一条铁律AI生成的代码不审查不能合入主分支。哪怕是一个简单的查询我至少要过一眼确认没有明显的逻辑问题。三个月下来我估计自己砍掉的“AI美丽废物”代码大概有七八千行但留下来的代码质量至少我自己敢在上面继续加功能。4.3 应对AI自产的技术债AI写代码有个让人头疼的习惯为了通过眼前的需求它会制造隐性的技术债。最典型的是接口设计脏乱差同一个接口在不同页面里要传输不同的参数组合AI就生成一堆可选参数导致接口越改越复杂最后没人能说清每个参数什么时候是必须的。还有直接在组件里写业务逻辑、复制粘贴相似代码而不是抽取公共函数、后端返回的数据结构不统一等问题。我的处理办法是每两周做一次“AI技术债清理日”把过去两周AI生成的代码里重复度高的部分抽取成公共函数统一接口参数结构删掉无用的兼容逻辑。这活儿本身也是AI干的——我让它先扫描整个项目找出重复代码和可疑结构生成一份重构建议报告我在报告基础上决策再让AI执行重构。体验下来AI做“代码清洗工”比做“代码建筑师”合格得多。5. 常见问题与避坑实录5.1 并发重复提交AI代码的经典翻车现场上线第一周就遇到一个始料未及的问题有财务人员在极短时间内双击了“通过审批”按钮系统生成了两条审批记录报销单状态被更新了两次好在业务上没有造成实质损害但审计日志里出现了两条本不该存在的操作记录。这个Bug的根源是AI生成的接口没有做幂等性处理。用户在界面上双击一次前端发了两个请求后端两个请求都正常处理了没有去重判断。解决办法是给审批接口加了一个请求唯一ID参数后端用数据库唯一索引约束同一个审批行为只能执行一次同时前端在按钮提交后立即禁用。这类并发问题AI很难自己考虑到因为它在生成代码时默认“每次请求都是独立的”不会主动去想“同一个请求被调用了两次怎么办”。5.2 金额精度与小数位一分钱也不能错的教训财务系统里金额精度问题是最敏感的坑。AI第一次生成的金额字段用的是JavaScript的Number类型存储用PostgreSQL的float类型测试阶段就发现0.1加0.2会变成0.30000000000000004这在财务计算里是绝对不可接受的。我的处理方案分两层数据库层金额字段全部改成DECIMAL(10,2)类型应用层使用Decimal.js库进行所有金额计算。AI生成的计算代码里如果直接使用原生加减乘除我的审查清单里一律标红。还要求AI在做报表统计时先取整到分再计算避免浮点误差累积。这个坑来得早多亏在测试环境就暴露了如果带着浮点误差上线到月底财务对账时绝对是一场灾难。5.3 上下文管理项目大了AI为什么“变笨”项目跑到第三周代码量到了两万多行我发现AI的表现开始下滑给它一个任务它经常会生成与现有代码风格不一致的代码有时甚至重新定义了已存在的函数导致编译报错。刚开始我以为是自己提示词写得不清楚后来才意识到是上下文窗口装不下整个项目的关键信息了。解决思路是“拆上下文”。我把项目拆成多个独立领域每个领域维护一份面向AI的上下文文档包括数据库schema、核心函数列表、接口约定、代码风格要求。每次给AI下任务时把这篇文章和任务描述一起发过去。效果立竿见影——AI生成的代码跟现有工程风格的匹配度大幅提升。这个经验说明AI本身的能力没变变的是你喂给它的信息质量项目的知识管理能力决定了一个人和AI协作的天花板。6. 关于AI编程真实水位的三点判断项目跑完三个月我从实际体感上对当下AI编程的真实水位线有了三个比较明确的判断。第一个判断AI编程的舒适区是“范式明确的代码生成”。CRUD接口、表单页面、固定格式报表、单元测试、Docker配置、类型定义这些有大量开源样本和固定套路的领域AI的效率至少是人工的三到五倍质量也基本在线。拿我这事儿举例光表单和列表页面这一块AI替我至少省了两周时间而且它生成的样式统一性比我手写还好。第二个判断AI编程的翻车区集中在“业务语义理解和系统边界设计”。审批流的状态约束、租户数据隔离、并发幂等、金额精度、合规审计这些需要根据业务上下文做推理的地方AI目前只能做到“看起来合理”离“实际可靠”还有距离。尤其在涉及数据安全的关键环节绝不能抱着“AI写了我审一下就行”的心态你得自己先把方案设计出来再让AI去执行。第三个判断一个人加AI做SaaS最大的瓶颈已经不再是写代码本身而是需求定义能力、领域知识和责任心。AI把编程的门槛拉低之后一个人能做的事变多了但要真做出一套能收费、敢承担企业客户数据责任的系统你需要比过去任何一个时代的独立开发者都更懂业务、更懂安全、更懂怎么把一个模糊想法变成严谨的产品边界。如果你也准备用AI编程启动自己的SaaS项目我的建议是别从最复杂的模块开始先做一个最小闭环比如报销系统里的“提交报销单—管理员可以看列表—导出Excel”这一个完整的链路让它跑通之后再开始叠加审批流、租户隔离、审计日志这些复杂度。每加一层都要回到最基本的问题——这个环节如果出错最坏的结果是什么AI能把成本降到零附近的是你试错和迭代的代价而不是你对业务理解和对最终体验负责的替代。这套打下来你心里对AI编程能做什么、不能做什么会比看一百篇评测文章都清楚。