我先说个前提：这次不是来吹“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 Plus，Redis做缓存和会话，Docker Compose做本地编排，云服务器加Nginx部署。选择这套组合有一个非常现实的原因：AI在语料越密集的技术栈上表现越好，同样的逻辑用冷门框架写，AI的出错率会肉眼可见地上升。这本身就是AI水位线的一部分。
2. 工具组合与提示词策略：我把AI当结对程序员，而不是搜索引擎
2.1 我实际用下来的工具组合
市面上AI编程工具一大堆，我前后试了GitHub Copilot、Cursor、通义灵码、CodeGeeX，还有几个对话型大模型。结论不是“谁最好”，而是“每个工具在最合适的场景里都有不可替代的位置”。
| 工具类型 | 代表 | 我用来干什么 | 体验评价 |
|---|---|---|---|
| AI原生IDE | Cursor | 日常主力开发，跨文件改代码 | 上下文感知最强，能读整个项目 |
| IDE插件 | GitHub Copilot、通义灵码 | 补全、小函数、临时重构 | 适合在已有代码里快速填空 |
| 对话型大模型 | Claude、GPT类 | 架构设计、疑难排查、代码review | 思考深度最好，但需要你自己喂上下文 |
| 国内大模型 | 通义千问、Kimi | 网络环境下的备案、部署类查询 | 对国内云服务和合规场景更熟悉 |
如果你用的是IntelliJ IDEA这类传统IDE，Copilot类插件的体验和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接口。FastAPI+Pydantic+SQLAlchemy这套组合里的增删改查，AI生成质量几乎可以到“免改”级别。我统计下来，MVP里的基础接口大概60个，其中70%以上AI一次生成就能通过联调，剩下30%需要修的大多是业务边界条件，比如某个字段是否允许为空、某个状态下能否删除之类。这类修修改改也很快，基本就是我再提一句，它再改一版的事。
第三个高光时刻是前端表单页面。Vue3+Element 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在这些环节的参与度同样是不均匀的：
- Dockerfile：AI能生成能用的基础版本，包括Python依赖安装、健康检查、非root用户启动等最佳实践，这部分贡献不小。
- 环境变量管理：AI不会知道哪条密钥该放生产配置，哪条放测试环境。它在docker-compose里暴露了我一个数据库密码，我review时发现并改成了从
.env文件注入。这类安全习惯，不能指望AI自觉。 - GitHub Actions：AI生成的CI配置“看着很完整”，但第一次跑就挂了——它把Python版本写成了当时不存在的版本号，而且测试命令里漏掉了迁移步骤。这些小坑都是上线前必须自己跑一遍流程才能发现的。
我体会最深的是：AI能把部署脚本写到“在干净服务器上能跑起来”的程度，但生产环境需要的日志轮转、备份策略、自动重启、监控告警，它给的方案都很“教科书”，要么缺少对数据量的考量，要么没有预留故障恢复预案。这部分工作是“经验密集型”的，也是AI水位线明显下降的区域。
5.2 上线后第一周我处理的三个生产问题
上线一周，我就遇到了三个AI无法预判的真实生产问题，每一个都值得单独说。
第一个是时区错乱。测试阶段数据量小、操作时间集中，没人在意时区。上线后有用户反馈，他8月1日提交的单子，在列表显示7月31日。排查后发现：后端存储用的是UTC时间，前端直接拿UTC字符串渲染，没有转成中国时区。AI给出的修复方案是“前端用dayjs转时区”，但改完之后，导出的Excel又出现了时间偏移——因为导出时后端直接序列化了UTC时间。最后我手工把规范定为“后端统一存储UTC，API层统一返回不带时区的本地时间字符串，前端不做任何额外转换”，才算彻底解决。这个问题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/CD | 30% | 生成能用，但踩坑修复靠生产环境反馈 |
| 线上问题排查 | 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报销系统是可行的，而且这段经历的价值，可能比系统本身更大。
