作者：yuezu1026 平台：CSDN

一、缘起：硬盘里躺着一个"裸代码"老项目

前阵子整理硬盘，翻出一个 2018 年前后的老项目：跨境电商 VAT（增值税）计算与报告系统。

技术栈一看就很有年代感：

类别	技术
框架	Spring Boot 1.5.6 + MyBatis + PageHelper
安全	Apache Shiro 1.2.5
数据库	MySQL（tax_computing，17 张表）
视图	FreeMarker + JSP + JSTL + jQuery
报告	iText（lowagie）生成带水印 PDF
其他	Druid 连接池、ehcache 缓存、阿里云短信、ZXing 二维码

更"酸爽"的是它的状态：

• 204 个 Java 文件，几乎没有注释，类名全靠猜；

• 没有 README、没有需求文档、没有接口文档；

• 大量 Map 裸传参、硬编码路径（E:/vat_computing/...），根目录还躺着重复的 mapper XML；

• 两个子项目（vat_computing 主项目 / vat_computing_test 精简版），差异要靠逐文件 diff 才知道。

放着是垃圾，扔了可惜——因为它背后是一套真实的跨境税务算法：A/B/C 计税分型、价内税反算、多币种汇率折算。这些业务规则到今天对做财税 / 对账系统的同行仍有参考价值。

于是我决定：用 AI 对它做一次完整的逆向工程，再把成果开源。

二、逆向的价值：老代码里藏着"不会过时"的业务逻辑

很多人觉得老项目没价值，其实恰恰相反。这个系统解决的痛点是跨境电商卖家手动申报 VAT 的困境：

• 平台订单按"业务活动周期"（月）核算，月销几万单，Excel 手工算不现实；

• 不同申报国家税率不同，且 VAT 是价内税——税已含在售价里，申报时要反算；

• 订单币种五花八门（USD / GBP / EUR…），要按申报当月汇率折算；

• 申报需要正式报告（报告编号、计算日期、水印），要可追溯。

技术会过时，但"价内税反算公式"和"A/B/C 分型口径"不会过时——这就是逆向老项目最大的收获：用今天的 AI 工具，把沉淀在代码里的业务经验挖出来。

三、逆向工程方法论：三步走

第一步：让 AI 通读代码，先画"代码地图"

204 个文件不可能人肉读完。我的做法是让 AI（GitHub Copilot）先做"代码地图"：

• 梳理目录结构与模块划分（action / bean / config / dao / service / util / ...）；

• 归纳技术栈与两个子项目的差异；

• 提取核心业务流程与数据表清单（17 张表）；

• 输出 doc/代码分析.md，作为后续一切逆向工作的索引。

心得：先让 AI 建立全局索引，再逐点深入，比直接钻进细节高效 10 倍。

第二步：从三个锚点反推业务

代码的"骨架"其实藏在三个地方，按顺序逆向：

1. SQL → 数据模型：mapper XML 里的 SQL 是最诚实的文档。order_header、vat_computing_middle_result、vat_computing_result 三张表一出来，业务主链路就清晰了；

2. Controller → 接口清单：所有 .do 接口就是功能清单（注册 / 导入 / 计税 / 下载报告 / 管理后台）；

3. Service → 业务规则：计税公式、汇率折算、导入幂等，全在 ServiceImpl 里。这是逆向的核心产出。

第三步：让 AI 把代码"翻译"成需求文档

逆向的终点不是看懂，而是让别人也能看懂。我用 AI 把代码反推成两份文档：

• doc/原始需求.md：业务视角（痛点、目标用户、功能清单、业务规则）；

• doc/需求文档.md：软件需求规格说明书（SRS，FR / BR / 数据 / 接口 / 验收标准）。

心得：AI 逆向的最大价值不是"逐行翻译代码"，而是"从代码中提取意图"——把"代码做了什么"提升到"业务为什么要这么做"。

四、逆向出的高光：核心计税算法

以下内容全部是从老代码里逆向出来的，也是全系统最值钱的部分。

4.1 三种计税类型（A / B / C 型）

VAT 计税不是简单"销售额 × 税率"，要区分发货国与到达国：

• A 型：发货国 ∈ 征税国家名单——货从征税国发出，销售额全额纳入计税；

• B 型：到达国 ∈ 征税国家名单，且不在用户勾选的申报国家内——跨境远程销售场景；

• C 型：到达国 ∈ 征税国家名单——"发货国交税模式"的汇总口径。

对应 SQL（A 型示例）：

SELECT t.transaction_currency_code AS currencyCode,
       SUM(t.total_activity_value_amt_vat_incl) AS vatAmount
FROM order_header t
WHERE t.user_id = #{userId}
  AND t.activity_period = #{activityPeriod}
  AND t.sale_depart_country = #{needComputingCountry}
  AND t.sale_arrival_country IN (SELECT c.country_code FROM tax_no_country c)
GROUP BY t.transaction_currency_code;

4.2 价内税反算（最容易写错）

英国等国家 VAT 是价内税，total_activity_value_amt_vat_incl 字段是含税销售额，申报时要先反算不含税金额、再算税金：

不含税金额 = 含税销售额 / (1 + 税率)
税金       = 含税销售额 / (1 + 税率) × 税率

但用非标准税率（英国初始税率 init / 低税率 low）时直接乘：

税金 = 含税销售额 × 税率

同一个"税率"字段两种算法——价内税 / 价外税不跟业务确认清楚，申报金额会差一个数量级。这是逆向时 AI 帮我标注出的最大业务风险点。

4.3 多币种汇率折算

订单 USD 结算、申报国英国（GBP）时：汇率表 exchange_rate 维护"目标币种 ↔ 订单币种"的当月汇率，目标币种为 from 取 1 / rate，为 to 取 rate，按申报月份取数保证口径一致。

五、技术心得总结（老项目逆向实战篇）

这次逆向还暴露了一堆老项目的共性问题，每个都是实战经验：

1. 异步导入是"老但经典"的架构：老代码用 ExecutorService + ImportOrderTask 异步解析 Excel，import_batch 表记录批次 / 进度、前端轮询。今天做大数据量导入，依然逃不出"上传即响应 + 后台执行 + 进度可查"三板斧；

2. PDF 中文字体是永恒之坑：iText 默认字体不支持中文，必须显式注册中文字体，且路径不能硬编码 Windows 路径（Linux 服务器上没有）；

3. 编码是最隐蔽的坑：老文件常带 UTF-8 BOM（解析出 锘? 乱码）、GBK / UTF-8 混用——批量处理必须显式按 UTF-8 读写，否则中文注释全变问号；

4. 批量改造要用脚本：给 300 个文件加 license header，人肉不可能，一个 PowerShell 脚本搞定，还顺手修掉了 BOM；

5. 逆向 ≠ 翻译：AI 帮我产出的代码分析、原始需求、SRS 三份文档，价值远超"代码注释"——它把 8 年前开发者的业务决策重新显性化了。

六、开源分享

逆向成果已全部开源，Apache License 2.0，每个文件都带完整的 license header，可放心参考：

📦 GitHub：https://github.com/yuezu1026/dataReport 📖 文档：doc/ 下含代码分析、原始需求、SRS 需求规格说明书 📧 邮箱：yuezu1026@163.com（技术交流 / 商务合作均可）

如果你也在做跨境电商或财税类系统，欢迎 star、提 issue，或来评论区聊聊价内税反算和汇率折算口径——逆向老代码的价值，就在于这些不会过时的业务经验。

---

本文首发于 CSDN，转载请注明出处。