从一句“现成 ERP 不合适”，到用 AI 做出一套财务软件

我媳妇在外贸公司做财务。她接触过的 ERP，有些价格太高，采购和维护成本都难以接受；有些虽然简单便宜，实际流程又贴不上外贸公司的财务要求。找人定制意味着反复沟通、长期等待，后续修改同样麻烦。她干脆把问题丢给我：能不能用 AI 开发一个试试？

我不懂代码，也没有财务知识。这个起点反而迫使我先抓住真正重要的事情：弄清业务、确定边界、拆出系统结构，再让 AI 在明确约束下完成实现。最后落地的“财务软件”，已经形成一套面向外贸业务的进销存财务应用，覆盖从账套、采购、销售、库存到收付款、核销和报表的主要链路，并具备桌面端安装、数据备份和后续升级能力。

这次实践让我更确定，AI 时代做项目的关键能力，是把一个模糊想法持续推进成可以交付的产品。

先把财务语言翻译成业务链路

刚开始时，我面对的最大障碍并非技术选型，而是连很多财务概念都不熟悉。如果直接让 AI“写一个财务系统”，它很容易生成一堆看似完整的页面，页面之间却缺少统一的数据关系。

我先把媳妇提出的问题放回日常工作场景中理解。外贸公司的业务不会停留在“记一笔收入、记一笔支出”：前面有客户、供应商和商品，中间有采购、入库、销售与出库，后面才形成应收、应付、收款、付款、核销以及利润结果。外贸场景还会涉及币种、汇率、运输方式、单号和日期等信息。

这样一来，需求就从“做个财务软件”变成了几条能够落地的业务链路。我把基础资料视为源头，把采购和销售视为单据主线，把库存变化和资金往来视为结果，再让报表从这些已发生的数据中汇总。这个顺序很重要，它决定了后续模块能否互相衔接，也避免 AI 把每个页面做成孤立的小工具。

我在项目里的角色更接近一名 FDE：媳妇提供真实业务判断，我负责把这些判断整理成系统规则，并控制每一轮实现的范围。

用结构化拆分控制 AI 的发挥范围

需求主线确定后，我没有一次性生成整套系统，而是按依赖关系组织任务。

第一层是账套、用户和基础资料。系统需要先知道当前处理哪家公司的数据、谁在操作，以及客户、供应商、商品和仓库分别是什么。第二层是采购、销售和库存，因为订单、入库、出库、退货、调拨、盘点之间存在连续关系。第三层才是收付款、应收应付、预收预付、费用、对账和核销。最后再处理采购报表、销售报表、利润分析、账龄分析和汇兑损益等汇总结果。

这种拆法给 AI 建立了明确的上下文。每次任务都包含当前模块依赖什么、会修改哪些数据、完成后应该影响哪里。AI 可以快速生成界面和实现方案，我负责检查它有没有破坏前面已经确定的业务关系。

例如，增加一个销售相关字段，不能只看表单是否多了输入框，还要继续追问：数据保存在哪里，旧账套升级后是否还能打开，相关查询和报表是否需要读取它，桌面端与其他运行方式是否保持同一套行为。通过这类追问，我把 AI 的产出从“页面能显示”推进到“系统内部能够闭环”。

把跨端差异收进统一的工程边界

产品逐渐变复杂后，一个现实问题出现了：桌面软件可以直接访问本地数据库和文件目录，浏览器环境没有这些原生能力；如果以后通过服务端使用，还会多出接口、会话和访问边界。

我让 AI 把这些差异收敛到统一的平台层。上层页面只表达“查询数据、执行事务、选择账套、备份数据”等意图，底层再根据 Electron、Web 或 Server 模式选择具体实现。这样业务模块不需要各写一套，后续调整运行方式时也不用推翻已有页面。

目前桌面端采用 Electron 承载应用，数据保存在 SQLite 账套文件中；前端使用 Vue 组织页面和状态。项目同时保留了浏览器存储与服务端接口的适配结构。技术栈本身很常见，真正有价值的是边界清楚：业务层尽量稳定，平台差异集中处理，AI 新增模块时可以沿用同一规则。

这也成为我约束 AI 的一种方式。遇到文件选择、备份目录或数据路径之类的需求，我会先判断当前平台是否具备相应能力，再决定界面如何呈现，而不是让所有环境假装拥有完全相同的功能。

验证重点放在数据连续性上

财务类产品最怕“看起来能用，数据却接不上”。因此，我关注的不只是页面是否打开，还包括单据之间的变化能否延续、账套之间是否隔离，以及升级后已有数据能否继续使用。

项目采用独立账套文件保存不同公司的数据。切换账套时会关闭旧连接并打开新的数据库，删除、备份和恢复也围绕账套边界处理。恢复过程中还会先检查文件是否具备有效的数据结构，降低把错误文件导入系统的风险。

迭代过程中新增了商品分类、客户信用额度、订单运输信息、费用关联和商品图片等字段。对此，我让 AI 使用数据库迁移机制：启动账套时检查字段是否存在，只补充缺失部分。旧版单一数据库也保留了迁移到新账套结构的路径，并在迁移后留下原文件备份。这样每次扩展功能都无需清空数据重来。

数据安全同样进入了交付范围。软件支持手动备份和恢复，也包含按日期执行的自动备份与过期文件清理逻辑。服务端形态则补充了登录会话、请求体限制、健康检查和冒烟验证入口。这些设计不会让界面显得更华丽，却决定了软件能否长期迭代。

最终交付的是一套能继续生长的产品

回头看，这个项目最有意义的部分，并非我突然学会了多少代码语法。我的主要工作始终是理解媳妇提出的业务问题，把财务概念整理成数据流和操作链路，给 AI 建立稳定的任务边界，再检查实现有没有遗漏跨模块影响。

当 AI 给出一个局部方案时，我会继续追问它与账套、权限、库存、资金和历史数据的关系；当功能从桌面端延伸到其他运行方式时，我会先抽象能力边界；当数据库结构发生变化时，我会把兼容旧数据列入同一个任务。正是这些判断，让多个 AI 生成的模块逐渐组合成同一套产品。

“财务软件”目前已经具备可构建的前端、可安装的 Windows 桌面应用、独立账套数据、服务端运行结构以及备份迁移机制。它依然可以根据实际工作继续调整，这种可持续修改的能力，正是当初选择自己借助 AI 开发的原因。

我从这次项目中得到的经验很直接：面对陌生行业，先找到真正懂业务的人和真实流程；面对复杂系统，先建立边界和依赖；面对 AI 产出，用数据一致性、平台约束和交付条件持续验收。即使不以逐行手写代码见长，也可以领导 AI 完成一项有业务背景、有工程结构、能够落地运行的复杂项目。