聊到“一个人用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. 如果你也想单干一个SaaS，AI编程之外的那些真话
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跑出比预期更远的路。
