聊到“一个人用AI编程能不能从零上线一套SaaS系统”这件事我过去几个月算是踩了个比较深的坑也拿到了一个能放在简历上的结果从四月底决定动手到国庆前把一套报销系统正式部署上线中间没有找外援全靠我自己加几款AI编程工具前后差不多五个月目前系统内部已经处理了一千多张报销单审批、打款、对账、审计这些环节全部在线上跑。之所以想把这段经历完整复盘出来是因为网上讨论AI编程的信息两极分化太严重一边说AI已经能代替程序员了一边说AI写的东西根本不能上生产。这两句话单独拎出来都能找到证据但都不够准确。真实情况是你一个人带着AI做项目和一家公司里工程师用AI写需求完全不是同一种体验。尤其当你要交付的是一个SaaS系统不是demo、不是脚本、不是内部小工具而是带多租户、审批流、权限、财务数据审计、可配置表单的真实业务系统AI的能力边界会暴露得非常清楚。这篇文章我想用这套报销系统作为观察样本谈谈2025年这个时间点上AI编程的水位线到底在哪里什么级别的任务可以大胆交给它什么环节你如果不想死得很惨就必须自己兜住。1. 先交代清楚这套报销系统到底做了什么很多人一听“报销系统”就觉得是个CRUD小项目但实际上报销属于典型的企业级业务麻雀虽小五脏俱全。它不是一个“记录的增删改查”而是一个有状态流转、有资金安全要求、有审计责任的系统。如果你上来就把它当CRUD做后面一定会返工。1.1 为什么拿报销系统来“试水”AI编程我选择报销系统作为一个人AI编程的实验项目纯粹是冲着它的复杂度来的不是为了做一个看起来好看的玩具。报销系统天然包含几个SaaS项目的硬核模块。第一是多租户数据隔离。每个企业客户注册进来只该看到自己公司的员工和单据一个客户的数据绝对不能出现在另一个客户的报表里。这种需求看起来简单但它要求你在表设计、查询层、缓存层都把租户维度贯穿进去属于架构层面的约束不是靠某个插件能解决的。第二是有状态审批流。一张报销单从草稿、提交、审批通过、财务审核、出纳打款到归档中间还夹着驳回、撤回、作废这些异常分支。状态流转一旦在并发场景下出问题会出现同一张单子被两个人同时审批的脏数据。第三是财务数据的不可篡改要求。报销单里的金额是钱不是博客文章里的点赞数。谁在什么时间改了什么字段改之前的值是多少这些都必须有留痕。甚至更严格地说一张单子进入审批流之后就不该允许业务人员直接修改关键字段只能通过“作废重提”之类的正规流程来变更。第四是外部集成。报销系统要对接企业支付、发票识别、钉钉/企微登录这些外部能力每接一个第三方都是在和不可控的异常打交道。这四个模块加在一起覆盖了SaaS系统从数据模型到权限到审计到集成的典型复杂度。我用它来测试AI编程的水位比用“做一个待办事项App”测出来的结论要可信得多。1.2 最终上线的系统功能清单先说结果再说过程。当前在线的这套系统功能范围是这样的企业租户管理支持租户注册开通、套餐配置、用量统计和禁用回收组织与员工管理部门树、员工账号、入职离职状态管理角色权限RBAC权限模型员工、部门审批人、财务、超管四类角色菜单和数据范围双维控制报销单全流程员工提单、发票附件上传、明细费用项管理、审批流、驳回重提、财务复核、出纳打款登记多级审批策略可按金额阈值或部门配置审批链比如超过5000元需要第二审批人电子发票管理支持发票上传、票面信息自动识别、重复报销校验审计日志不可逆的流水记录记录每一次创建、提交、审批、修改和打款操作管理后台租户维度的数据看板、单据查询、异常单标记从合同上看这套系统大概覆盖了一个两三百人规模企业使用报销功能80%以上的需求距离拿出去商业化卖钱还有距离但作为MVP验证已经达标。1.3 项目的硬件配置一个人三款AI工具一台电脑工具配置这块我也统一说清楚后面聊经验时你们才知道我的结论是在什么环境下得出的。主力工具是Cursor编码过程中用到了GitHub Copilot做辅助补全另外在两个模型之间做了大量A/B对比分别是Claude的Sonnet系列和GPT-4o系列。国内模型我也试过后面单独有一段工具选型的实测结论这里不展开。服务器用的是云厂商最低配的2C4G实例起步数据库是云上的PostgreSQL对象存储放发票图片。前端的部署用了Vercel一类的平台后端服务则部署在国内云服务器上整体成本控制在一个比较低的水平。我自己的背景先交代一下我是有多年开发经验的工程师不是零基础小白。这点很重要因为AI编程对“有没有人来兜底”这件事的敏感度极高。同样的工具给一个资深开发者和给一个完全不会写代码的人产出的系统质量能差出十倍。后面我会反复强调这个观点。2. 实测下来的AI编程能力水位线哪几层活是真能干哪几层是重灾区先不给结论直接说我在这个项目里实测到的AI各项能力边界。我会把任务分成三层每层标记了AI的真实表现和容错空间。2.1 第一层脚手架和增删改查AI可靠程度接近成熟外包在报销系统的落地过程中重复性最高、AI完成质量最稳定的是业务系统中的标准CRUD模块。比如费用类型管理、部门管理、员工列表、字典配置这类页面。你给我一个标准的RESTful接口规范告诉AI对应的数据表结构它能稳定地输出前后端代码从列表查询、分页、筛选到新增、编辑、删除几乎不需要你改逻辑直接能跑。这个过程有个前提需求描述必须到位。你不能只说“帮我写一个部门管理页面”你要说清楚字段有哪些、列表需不需要分页、删除是有物理删除还是把状态置为禁用、名称重复时怎么办。你描述得越接近一个需求文档AI给出的代码越能用。如果你的描述本身就模糊AI只会给你一个模棱两可的通用实现最后你可能要花更多时间去改。这类任务的完成度在我实测中可以达到90%以上。它消耗的不是AI的能力而是你把它喂饱的耐心。以报销系统里的费用类型管理为例我只需要把规则用自然语言写清楚AI就能完成从数据库到界面到接口测试的整条链路这是一个人能做SaaS的底气所在。2.2 第二层业务状态流转和权限控制AI能搭骨架但不懂业务规则报销系统的审批流是另一个级别的复杂度。状态流的CRUD好写但状态流背后的业务规则很难。我用状态机的方式来管理审批流把每张报销单的状态变化定义成迁移表什么状态下允许执行什么动作动作发生后跳到哪个状态触发这个动作需要什么角色权限。让AI写状态机的代码结构没有问题。比如我定义几个状态、几个事件让它生成TypeScript的类型定义和状态迁移函数它写得又快又清楚。遇到难缠的场景比如“一张单子在审批中被撤回之后重新提交审批链应该重置还是按原路走”AI给出的代码逻辑就经常出现偏差。它是用一个概率模型在猜应该怎么处理但不理解报销场景里这些业务规则为什么是这样设计的。所以在这一层我给AI的角色定位是“听指令干活的开发”不是“帮你做业务设计的顾问”。状态迁移表必须我自己画清楚规则必须我逐条定义好AI只负责按规则翻译成代码。如果你自己都没想清楚业务规则AI会帮你“脑补”一套规则而且不会告诉你它帮你做了决定这才是最危险的地方。2.3 第三层多租户隔离和数据安全AI的代码不能盲信到了多租户和防篡改这一层AI的表现就开始明显飘了。也不是完全不能用但它给出的方案经常是“看起来在隔离但实际逻辑是漏的”状态你需要很敏锐地发现漏洞。举个例子。让AI写一个“查询当前用户的报销单列表”它可能会在SQL里写上WHERE approver_id 当前用户之类的条件。但如果表里还有租户字段它可能不会自动帮你加上tenant_id的过滤尤其是在复杂查询里几个表JOIN之后租户条件容易丢。数据安全问题我单独强调一次。传统开发中安全是层层设防的有鉴权、有参数校验、有数据权限过滤、有SQL注入防护。这些环节AI会做正面部分但它经常忘记异常和边界。比如文件上传功能它会帮你做文件类型校验但它可能不会校验文件内容是否和扩展名一致也可能没限制上传文件的大小更不会想到要把上传目录的执行权限关掉。这些不是AI的智力问题而是它没有“你可能被攻击”的危机感。我的原则是凡是涉及数据隔离、财务金额、权限校验这三个领域的代码AI生成的每一行我都要亲自审查而且会用攻击性思维去检查。我测试的时候会故意用另一个租户的账号去访问数据看看接口会不会越权。这个层面的问题AI自己发现不了只能靠人来兜底。2.4 没有AI参与这个项目要多久计算一下时间投入方便你做预期管理。这套系统如果回到三年前纯手写我按一个熟手工程师每天有效编码四小时来算从零到上线至少需要四到六个月。我做这个项目的实际投入是五个月其中工作日晚上和周末加起来平均每天三到四个小时总工时大概在450到500小时左右。其中AI帮我省掉的主要是纯编码时间和查资料时间。原来写一个列表页前后端加调试可能要三个小时用AI半小时能出一个能跑的版本我再花半小时Review和调整。但架构设计、业务梳理、安全审查、部署排错、第三方对接这些环节AI帮不上太多忙时间省不掉。这个账算下来我的结论是AI编程把一个人开发者的产能提升了两到三倍但没有网上说的“十倍效率”。而且这个前提还是你有能力判断AI输出质量如果没有这个能力项目很可能中途烂尾。3. 从零到一报销系统完整的AI辅助开发流程实录如果要给同样想“单干SaaS”的人一个参考光讲能力边界还不够得把实操链路拆开看。我会按我自己实际开发的顺序把每个阶段怎么用AI、哪些坑值得注意完整说一遍。3.1 技术栈选型为什么没用Python写了后端先回应一个比较多人问的问题为什么做SaaS报销系统我没选前后端分离也没用Python的FastAPI或Django写后端而是用了Next.js全家桶加上PostgreSQL和Prisma。原因之一是AI编程的训练语料分布。目前的主流AI模型在Next.js、TypeScript、React、TailwindCSS这套技术栈上的优质训练语料非常多因为它是最流行的前端全栈框架之一。AI写出来的Next.js代码在接口路由、服务端组件、数据获取这些设计模式上相对标准踩到AI“幻觉API”的概率会低很多。你用一个小众框架AI生成的代码需要人工纠偏的比例会大幅上升。原因之二是一个人开发需要尽量压缩技术栈跨度。前后端分离意味着要维护两套应用、两套部署、两套鉴权本质上是在给自己增加运维负担。Next.js的API Routes让我能把报销单相关的接口和页面放在同一个代码库一套代码走到底。第三是数据库选了PostgreSQL而不是MySQL原因是PostgreSQL在JSON字段、数组类型、约束和审计日志这些功能上更顺手。尤其在做不可篡改的数据快照时PostgreSQL的行级安全和触发器支持会给我们留出更多余地。这套技术栈并非适合所有SaaS项目比如你要做的是强实时在线协作工具那可能需要换方案。但对于报销这种以表单、流程、报表为核心场景的业务系统它非常合适。3.2 从零搭环境AI帮你写配置文件但你必须知道每项配置是干嘛的起步第一步是初始化项目这块用AI非常爽。装好Node环境后我会开一个终端对话把想做的事情给AI描述一遍一个支持多租户的SaaS报销系统前端用Next.js App Router后端接口也在同一个项目里用Prisma管理PostgreSQL认证用JWT部署目标是Vercel加一台云服务器。AI会给你一串命令包括创建Next.js应用、安装依赖、初始化Prisma、配置Tailwind。把命令一条条执行完一个能跑的前端加API骨架就出现了。这个阶段通常半小时内能完成。但有一个警告必须给到AI让你安装的每个依赖你都应该搞清楚它是干什么用的。我曾经因为图省事直接让AI安装它推荐的某个ORM插件结果这个插件的版本和主框架不兼容导致调试了一整天。不要把所有事情都信任AI尤其在依赖选择和版本管理这件事上AI对版本兼容性的记忆经常是过时的。3.3 产品原型先行AI生成页面草稿报销系统这种项目第一步不是写代码是把页面的样子定下来。我一个人做没条件请UI设计师所以我用了一个比较巧妙的办法用AI直接生成静态页面的草稿先把员工提单、审批列表、财务报表这几条主流程页面的低保真版本跑起来。这个阶段我是让AI用TailwindCSS和shadcn/ui风格组件直接生成页面。我只需要描述页面大概需要哪些区块AI会给我做出像模像样的样式。专业审视下当然是普通水平但作为一个人开发的项目它已经过了“不会让人觉得丑得离谱”的及格线。这一轮尝试下来我的体会是页面的UI布局AI能帮你搞定80%剩下的20%是需要人判断的业务表达清晰度。比如报销明细里一条费用记录的“费用类型”“金额”“发票号”“备注”这些字段怎么排能让录入的人不容易填错AI给出的默认排序往往不是最优的用户体验的直觉它仍然欠缺。3.4 数据模型设计这一步很重要我选择人肉主导数据模型是整个报销系统的地基也是我唯一没有让AI自由发挥的环节。我花了整整三天时间设计表结构、字段约束、索引和审计留痕机制AI只负责在我给出设计后帮我生成Prisma schema文件和初始迁移脚本。为什么不让AI直接设计表因为我试过一次它给出的表结构看起来完整但一旦落到真实业务场景就有漏洞。比如报销单和费用明细它懂得拆成两张表但当一笔报销单有多张发票、而发票金额和报销明细金额需要校验时它的表设计经常缺约束。设计这套数据模型时我重点画了几个核心实体。用户表需要绑定租户和部门还要挂一个状态字段标记是否离职因为离职员工不能登录系统但他的历史报销单必须可以被审计追踪。报销单主表包含单号、申请人、部门、费用总额、状态、当前审批节点以及提交、审批、打款等关键时间戳。报销明细行表记录每笔费用包含费用类型、金额、发票号、费用发生日期。审批记录表所有动作留痕写清楚谁在什么时间做了什么动作附带了什么意见。打款记录表记录实际支付信息包括打款金额、支付渠道流水号、打款人和打款时间。围绕这个模型我还加了两条约束报销单和明细行通过单号关联每一张发票在同一个租户内只能被报销一次防止重复报销。为做到后者我给发票号建了租户ID加发票号的唯一索引。这套设计完整落地之后我才让AI在此基础上开发具体功能。如果反过来让AI先设计你再去改返工成本会大到让你想把整个项目推翻重写。3.5 提示词不是玄学报销系统开发中真正有效的写法这个项目做下来对于“AI编程提示词”这件事我积累了很重要的一套心得。网上很火的那些魔法咒语式提示词什么“扮演一位全栈工程师”有用吗有一点点用但不是关键。真正影响AI输出质量的是信息密度和约束条件。先看一个典型的反面写法“帮我写一个报销单列表页面”。这种提示词拿到的输出通常是一个泛泛的骨架字段自行发挥样式随手糊一个表格没有分页、没有筛选、没有权限判断。一旦你再多要求几句它还会把之前生成的代码改坏。我要的写法是填空式的把需求文档拆成一个一个独立小任务每个任务都给出足够的上下文。拿“报销单审批列表”举例我的提示词结构大概是这样任务背景这是一个面向企业客户的SaaS报销系统当前登录用户是部门审批人。 页面需求审批人首页需要展示待自己审批的报销单列表。 功能要求 - 每行展示报销单号、提交人、部门、费用总额、提交时间和状态 - 需要一个“查看详情”按钮进入详情页完成审批操作 - 列表需要分页每页20条 - 查询字段包括单号关键字、提交人姓名、费用总额范围 技术约束使用Next.js App Router数据通过server action获取 - 数据库模型报销单表是Expense字段定义如下〔贴schema〕 - 审批人只允许看到提交给自己审批的单据判断条件是……〔写明规则〕 验收标准页面能正常编译、列表能展示数据、筛选条件生效、代码风格符合项目的ESLint规则这种提示词的效果和前面空泛版本完全不同。AI拿到的是一个没有二义性的任务包它不需要猜你要什么只需要翻译和执行。关于提示词我说几个可复用的经验不要在一段提示词里塞过多任务。让AI写一个页面就只写一个页面别同时要求它把详情页、审批接口、单元测试一起写了。大而全的提示词产出质量远低于小而准。重大改动不要直接面向满屏历史代码提要求要把相关代码块单独截取出来发过去然后告诉它要改哪个函数。上下文越干净出错越少。代码出错时直接把完整报错信息和相关代码贴给它。别描述“我页面上有个地方报错了”要给它原始材料。重要代码生成后让AI给每行关键逻辑写注释强迫它自己解释一遍。凡是解释不清的逻辑基本都是它编造的。对AI生成的代码保持怀疑涉及金额计算、状态同步的部分我会抽出几条边界条件让AI自测比如“如果报销单金额是0怎么办”“如果审批人就是提交人本人怎么办”。3.6 审批流实现用一张状态迁移表管住AI的乱发挥报销单审批流是核心中的核心我采用状态机来定义逻辑。把一张报销单当成一个状态机状态变化必须走合法的转移边非法的转移直接拒绝。这种设计还有个好处是状态机的规则特别好描述给AI也特别好做代码审查。它没有什么隐性的业务判断就是一张规则表。我定的状态包含草稿、已提交、审批中、财务审核、待打款、已打款、已驳回、已撤回、已作废。允许的转移规则大致是草稿可以被提交或者撤回已提交单子进入审批中或者被审批人驳回审批中可以通过进入财务审核也可以被驳回退回提交人财务审核通过进入待打款不通过则驳回待打款确认打款后进入已打款从审批中或财务审核阶段提交人还能撤回前提是撤回后单据作废不留待办已驳回单据只有提交人重新编辑后再次提交一条路不允许修改后变成“草稿”。这张状态迁移表我建议如果你也做类似系统第一版先用纸笔画清楚画的时候把每个状态下的可操作角色也标出来。我自己是先画在纸上想清楚了再把整张规则表交给AI生成代码实现。它一次性就把状态机定义文件写对了而我只需要写一组测试把状态迁移表中每一条合法路径和非法尝试都覆盖住。3.7 SaaS多租户每一种隔离方案的真实代价多租户隔离是SaaS区别于普通Web应用的标志也是设计上争议最大的点。当时我在方案评审里对比了三种主流方案。第一种是独立数据库每个客户一个库隔离最彻底但成本随客户数线性上涨运维复杂不适合我这种一个人的项目。 第二种是独立Schema共享同一个数据库实例每个租户一个Schema隔离性也不错但要求你对数据库的迁移工具、备份策略都很熟。 第三种是共享库加租户ID字段所有租户的数据在同一个表中靠行级字段区分归属成本最低开发最快但隔离安全需要代码层绝对保证。我最终选了方案三也就是共享表加租户ID字段。因为它最契合一个人SaaS项目前期的成本结构等真正做到一定客户量再考虑迁移。但选择方案三意味着必须在应用层面做强制隔离这是拿便利换安全性。实现上我给每张业务表都加了tenant_id字段所有查询都强制带租户条件。为了让这个约束不容易漏我在数据库访问层做了一个统一的封装所有查询方法都必须传入当前租户上下文如果某个方法没有显式声明使用租户过滤代码审查时就过不了。这个“接口设计强制约束”的思路要远比每个开发自己记得加where条件可靠。另外还用了PostgreSQL的行级安全策略作为兜底在数据库层配置按租户ID自动过滤的规则。这样哪怕应用层代码出现了漏洞漏了加租户条件数据库也会直接挡掉跨租户的数据访问。这是一道成本低但收益很高的保险。3.8 数据安全与“不可篡改”审计日志、权限收紧、哈希链三层防护关于“SaaS系统怎么确保数据安全不可篡改”这是报销类系统绕不开的问题我在这套系统里做了三层防护从产品层面限制了篡改的方式。第一层也是最重要的一层是产品流程上的不可篡改。报销单一旦提交进入审批流业务字段就全部锁定没有人可以通过界面去修改金额、发票号、明细行。如果填错了唯一的正规路径是撤回或驳回后新建一张单子重新提交。旧单据原样保留作为历史凭证存在。这个设计把绝大多数“篡改”在源头消灭了。我觉得凡是涉及财务单据的系统都应该做这个约束技术上把状态机和编辑权限绑死。第二层是数据库层面的审计日志。单靠产品界面锁死还不够因为能访问数据库的人依然能改数据。我在每一张核心业务表上做了审计跟踪每次UPDATE或DELETE操作触发器会把旧值、新值、操作人、操作时间、IP、会话信息写入audit_log表。一旦发现某条报销单记录在业务上不该被修改却出现了变更记录就能通过日志查到是谁、什么时候、做了什么。第三层是哈希链校验这也是我调研时花时间最长的部分。原理很简单审计日志每写一条记录就把这条记录的哈希值和前一条记录的哈希值拼接再算出一个新的哈希值串成链。如果有人改了中间某一条历史日志因为哈希链是环环相扣的存哈希的校验值就会立刻对不上。实现上我用了一个独立的hash_chain表每次插入审计记录时由应用层计算sha256(上一条记录的hash 本条记录的内容 操作时间)然后存进新记录里。校验时按顺序重算整个链条任何一条异常都会导致整条链断裂。这个方案的实际执行成本很低但能显著提升审计数据的可信度。金额字段还有一个额外的处理涉及钱的改动不走UPDATE而是走追加式记账。比如打款金额输错了系统不允许直接把金额改掉而是新增一条红冲记录把错误金额冲掉再新增一条正确的打款记录。所有账面变化都可以从一个初始状态一路推导到现在这比直接改数据库字段要安全得多。3.9 引入AI编码三阶段代码生成、人审修改、测试回归到了具体编码环节我的工作流基本形成了一套固定节奏分成三步。第一步是代码生成把需求拆解成AI能理解的任务让AI生成初版实现。第二步是代码审查这是整个流程里最不能省的部分。我会逐行审查AI生成的代码重点看四个地方数据查询是否带了租户隔离条件状态流转有没有走非法路径金额计算有没有精度问题权限判断有没有漏掉角色校验。第三步是测试回归。每完成一个模块就让AI按状态迁移表帮我生成测试用例然后跑测试。这个阶段AI也能帮上忙因为它的强项就是根据规则批量生成测试输入。就这样三步循环一个小模块一个小模块地推过去。整个过程表面上和传统开发很像但编码和测试的耗时明显缩短因为我更像是AI的架构师和代码审查员而不是打字员。4. 一个人用AI做项目的坑真实踩过的和帮你避开的4.1 AI的“伪自信”它会一本正经地编造不存在的配置项目中途最让我无语的一次场景是配置对象存储服务时AI自信地给出一段示例代码调用了某个API并说开了某个桶之后就能直接使用。结果我照做之后一直报签名错误。花了一个多小时排查最后看文档才发现这个功能API根本还没有开放那段代码是AI“看着像”存在的接口编出来的。这不是个例。AI很喜欢一本正经地编造不存在的API、不存在的配置项、不存在的依赖而且它编得上下文极其逼真。排查这类问题没有捷径就是养成“凡是涉及第三方服务的代码必须去翻官方文档核实”的习惯。不要对着AI给的代码反复研究先怀疑API不存在再去查证。4.2 上下文越长AI越容易“失忆”并改坏已有功能项目做到后期代码库变大了我经常在一个AI会话里贴大量代码要求它做一次多重修改。结果它修了A功能改出来的代码却把B功能破坏了而且A功能也未必真的修好。我的规避方案是一个会话只做一件有边界的事。如果要修改某个功能只把相关文件和函数贴进去不在会话里夹带其他话题。每完成一次修改就跑一次测试和编译确保没有破坏已有逻辑再进入下一个任务。另外重要的AI会话我基本不连续使用太久遇到表现出“忘了前面约定”的情况就新建会话重新组织上下文。4.3 让AI自主改代码会失控把它的权限收窄我一开始用过AI的自动执行模式让它自己找文件、自己改代码、自己跑测试。一开始很爽后来发生了一次特别惨痛的教训它为了修改一个页面上的字段校验自动扫描项目后把我们数据库的Prisma模型改动了并且生成了一个新的迁移脚本。如果不是我在数据库里看到了一个奇怪的迁移记录这个改动可能会在下次部署时把表结构弄乱。从那以后我基本只用diff模式和手动确认模式。AI给出的代码先以diff形式呈现我逐行确认后再决定是否应用。别嫌麻烦这个环节的谨慎程度决定了你的项目会不会在某个深夜突然爆炸。限制AI权限本身也要意识上收窄不要让它“顺手”改schema、改配置、升级依赖。“顺手”这两个字在传统开发里也会埋雷在AI协作中发生的概率更高因为AI判断“顺手”的标准是代码整洁而不是业务安全。4.4 数据型页面AI生成的快但不要让它“代表”你来思考性能报销单列表页到了后期有一天下班前我还收到朋友反馈说审批页面打开很慢排查后发现是AI在列表查询里没有加索引金额总和用到了全表扫一遍才聚合几百条报销单数据量不大所以看不出问题但放到真实租户上就会很卡。这次之后我定制了一个规矩凡是列表页、报表页、统计接口AI代码生成后我要检查是否用到了索引、是否在SQL层做了聚合、是否按需查询字段。千万不要让AI帮你优化“以后再说”。索引和查询设计应该在表设计的阶段就想好AI写代码时不会主动替你考虑这些性能问题。5. 工具选型实测Cursor、GitHub Copilot、Claude、GPT系列到底怎么搭5.1 编码主力Cursor为什么成为我这次项目的主力这次项目里Cursor是我打开时间最长的编辑器。它的核心竞争力是把AI能力和编辑器做了深度融合读代码库时不只是看你粘贴的那一小段而是能围绕项目做一定程度的全局理解。这意味着当我问它“某个审批流转逻辑在哪里触发”它能帮我在代码库中定位到对应文件而不是只能对着我手动贴过去的函数瞎猜。这个“看懂整个项目”的能力在一个人维护大型代码库时价值巨大。很多时候AI帮不上忙不是因为模型不够聪明而是因为它看不到足够的上下文。Cursor在读取代码库这一点上比传统的IDE插件模式有优势。5.2 辅助补全GitHub Copilot的低姿态作用项目后期GitHub Copilot更多作为第二层辅助存在。它擅长的是在函数体内做下一行代码的预测补全尤其是在写重复性代码时它知道你下一步想做什么。用过Cursor主打功能后再开回到Copilot会有种明显感觉Copilot像个安静的老员工在你需要的时候递工具但不会主动帮你重构整个项目。它的存在不是替代其他AI而是把编码过程中的微操效率提起来。5.3 模型对比Claude和GPT系列各有强项AI编程不能只看编辑器还要看背后接的模型。我这次项目里常在两个来源模型之间做对比。实测下来Claude的Sonnet系列在代码生成的质量上表现更稳定它写的代码结构更干净变量名更合理处理边界条件的意识更强。在生成复杂逻辑函数时我倾向于把任务交给Claude。GPT系列在另一个方向上有优势就是处理自然语言描述较模糊的需求时它的语义理解更细腻。有时候我自己没想清楚要什么描述得稀里糊涂GPT能通过提问帮我明确需求而不是直接开写。建议做法是拿同一个功能让两个模型分别写一遍然后对比取舍。这个工作看起来浪费实际长期下来能显著提升代码质量也会让你对每个模型的脾气摸得更清楚。5.4 国内模型和免费工具的使用体验国内模型我也试过几款包括几个最近热度比较高的AI编程工具和插件。可以给到结论它们在中文语义理解上确实有天然优势对国内开发者的本地化场景处理得更顺手注册和数据安全上也让人更放心。不过在长文件的上下文窗口、多文件重构能力和复杂代码生成一致性上跟Claude、GPT系列的顶尖闭源模型对比还有差距。目前我最常用的架构是把国内模型作为辅助问答和代码解读的渠道它帮你快速检索代码库、解释某段代码含义、给出技术选型的背景资料这些场景非常好用。但作为整个系统的编码主脑我暂时还没有把主力生产代码交给国内模型来独立完成因为在多文件联动的大型改动上它的出错率明显偏高。这类产品迭代非常快如果你有预算和环境可以接触多种工具建议保持关注。5.5 编程AI要不要付费算一笔经济账直接说结论如果你要用AI来正经做项目不是随便玩一玩付费的高级版本值得投资。Cursor Pro版本一个月20美元左右Copilot大约10美元一个月这笔投资换来的效率提升非常划算比请外包或找兼职要便宜几个数量级。但我要提醒一点订阅了付费AI不代表你就应该“高杠杆依赖”它。真正的高效组合是让AI实现你能秒懂的重复代码但你自己保持对系统全貌的把控。如果一个程序员长期不看AI生成了什么只是反复要求它改到测试通过他对系统的理解就会慢慢丢失。到某一天项目出了无法被AI诊断的疑难问题你会发现你已经不知道怎么修复自己的系统了。6. 如果你也想单干一个SaaSAI编程之外的那些真话6.1 MVP功能设计敢做减法比堆功能难十倍一个人做SaaS从零到上线产品设计上最重要的事是克制。我在开始阶段列过一份很长的功能清单里面有预算管理、费用分摊、多币种报销、移动端App、报表自定义导出、和钉钉审批打通。冷静下来之后我把这些全部砍掉了。最后上线的MVP只保留报销闭环最核心的那条线员工提单、审批流转、财务打款、审计留痕。这个闭环能让使用者顺利处理一笔报销的完整生命周期。那些后来被我砍掉的功能有的是客户可以等一等的有的是可以通过手工方式暂时承接的。砍功能时一定要问自己一个问题如果这个功能上线前不做用户会立即流失还是仅仅觉得“缺了点什么”如果答案是后者果断砍掉。一个人开发最稀缺的资源不是钱不是代码能力而是注意力。功能堆得越多你花在核心链路和系统稳定上的时间就越少最终所有功能都跑不稳。6.2 外部服务选型稳定比什么都重要做报销系统时我发现自己真正花时间的不是写业务代码而是和第三方服务打交道。实名认证、短信、文件存储、支付渠道以及企业微信和钉钉的登录对接。这个环节我的经验是一个人开发不要追新要追稳。第三方服务一定要选成立时间久、文档完善、社区活跃的成熟产品。新平台虽然有价格优势但文档缺胳膊少腿、API说变就变每次变动都要你去重新适配消耗极大。对接第三方时一定要把官方文档通读一遍再动手。不要拿着AI给的示例代码直接改因为AI的训练数据里塞了大量旧版API的写法很容易给你一个已经废弃的接口。6.3 关于部署、运维和灰度没有测试环境的单人项目怎么上线单人项目很容易因为人手不足而跳过测试环境直接在线上改但这样做是危险的。我自己搭了一套极简流程本地开发环境、线上测试服务器、正式生产环境三套配置通过Git分支管理环境。每次上线前先在测试服务器上把新代码部署一遍然后跑一次核心流程冒烟测试确认提交报销单、审批、打款和审计这几条主链路没问题后再操作生产环境发版。哪怕只是改了一个字段的显示文字我也会走这个完整流程因为线上系统崩一次丢掉的信任需要花很大代价才能补回来。数据库迁移是我单独提醒的雷区。单人项目的数据库经常是没有专职DBA来兜底的AI生成的Prisma迁移脚本我从来不敢直接在生产库上执行。每次迁移前都手动备份数据库迁移后立刻跑一遍关键数据的校验查询。这个习惯救过我很多次。6.4 数据备份策略账不能丢这是底线系统里跑的每一张报销单都是客户企业的财务凭据如果数据库丢了这是不可挽回的事故。我做了两层备份云数据库的自动快照加上每日凌晨的自动导出导出的备份文件存到另一个对象存储桶里。备份和主数据不能放在同一个云厂商或同一个可用区这是底线不是可选项。另外提醒一句别太依赖云厂商的自动备份。真实发生过云账号欠费导致快照被清除、数据库出问题需要回溯时找不到备份的情况。定期手动下载一份备份到本地磁盘或者另一个云平台成本很低但关键时刻能救命。最后关于AI编程水位线我想说的体感这套报销系统上线运行之后我持续观察了一段时间又复盘了整个项目才写下这些。我对AI编程的真实水位线有个比较清晰的判断而且这个判断写到这里时也没有改变。AI的能力下限已经很低了。即使一个不太会写代码的人目前也能借助AI工具搭出一个看起来像模像样的应用原型。但上线一个真正给人用、涉及资金和数据安全的系统能力下限并不能决定成败决定成败的是你的能力上限和判断力。你能不能在AI代码里发现它“编造”的逻辑漏洞能不能在它漏掉租户过滤条件的一刻拦下来能不能在它自信输出错误API时直接驳倒它这些才是决定项目能不能活下来的关键。我个人的体会是不要执着于判断AI“能不能替代程序员”这个命题在目前阶段没太大意义。更有意义的问题是“一个人的开发能力边界因为AI被扩展到了多远”。对我而言这个项目已经给出了清晰的回答一个人如果过去有扎实的工程功底现在借助AI工具确实有能力把一个传统意义上需要一个团队才能完成的SaaS系统从零推到上线。但前提是你必须把AI当成一个能力很强但需要严格审查的同事而不是一个可以甩手掌柜的自动程序员。如果你也准备启动一个类似的单人AI项目我最后再送你三条实操经验。一是有能力自己先把系统完整设计和拆解清楚再让AI进入编码这比让AI帮你做技术决策要稳得多。二是每次AI生成的代码都要带着审查意识去读尤其是涉及安全、权限、金额的地方AI的自信和它的正确率没有强关联。三是尽早搭好数据备份和部署流程越早越好不要等到系统上了真实用户之后才开始操心这件事。祝你能用AI跑出比预期更远的路。
