如何用 AI 从我的旧系统中提取业务规则？

从旧系统中提取业务规则分 3 步：AI 读取代码，把每条规则写成一句清晰的话，并关联到它所在的代码行；流程负责人审阅后确认或更正；然后您用真实发票把它与系统的实际行为进行对比。像 面向大型机的 AWS Transform 这样的工具会把规则写成可审阅的需求；而在 Thought Machine 与亚马逊于 2026 年 9 月 29 日发布的公告 中，提取过程分为 4 个阶段，最后一步是人工签核。规则确认之前，不要写任何新代码。

在 第 3 部分 中，您已为每个系统完成盘点并作出初步决定。那些您决定重建或转换的系统，最先需要这一步。

为什么业务规则是旧系统中最有价值的部分

业务规则就是贵公司计算或决定某件事的方式：批发客户的折扣怎么算，什么时候加收滞纳金，超过一定额度的采购订单由谁审批，分期金额如何取整。这些规则在多年的修改中不断累积，其中很多从未写进任何文档。

• 在代码里：程序员多年前应一位早已离职的经理要求写下的条件和计算。
• 在数据库里：有人手工修改的价格表、费率和额度，却不知道哪些东西依赖它们。
• 在员工脑子里：因为系统不处理，会计只能手工处理的例外情况。
• 在电子表格里：弥补系统不足的公式，我们在 哪张表才是真正的系统 中讲过。

如果不带着这些规则就重建系统，您会得到一个计算方式不同的新系统，直到客户对发票提出异议时才会发现。真正需要迁移的是规则；旧的编程语言只是容器。

AI 如何读取代码并写出规则

提取规则过去是一项漫长的手工工作：程序员逐行阅读代码，记下自己的理解。如今的工具会读取全部代码，追踪每个数字从哪里来、到哪里去，再用易懂的语言写出发现的内容。举一个例子：亚马逊在 面向大型机的 AWS Transform 页面 上表示，该服务会从源代码中提取每一条业务规则并追溯到其出处，然后生成可供您的团队审阅、可直接用于开发的需求，每条需求都能追溯到其来源代码。这是亚马逊对自家服务的描述，并非有保证的结果。

规则用什么格式书写很重要。一种知名格式是 EARS，即 Easy Approach to Requirements Syntax（简易需求语法），由 Alistair Mavin 及其在劳斯莱斯的同事开发，于 2009 年首次发布。它的思路是每条规则都按固定顺序书写：先是状态，再是触发条件，最后是系统必须做什么。它有 5 种基本模式，以下是企业场景的示例：

这种格式的价值在于，流程负责人不懂编程也能读懂并判断。每条规则一句话，回答是、否或不完整即可。

银行业的例子：提取业务意图，而不是逐行翻译

最清楚的近期例子来自银行业：利息、手续费和还款规则几十年来一直存在于大型机上的 COBOL 代码中。COBOL 是一种古老的编程语言，至今仍在运行银行和保险业的许多系统。银行科技公司 Thought Machine 在 2026 年 9 月 29 日的公告 中表示，它正与亚马逊合作打造一条流程，不是逐行翻译代码，而是提取纯粹的业务意图。根据公告，该流程分为 4 个阶段：

1. 提取：AWS Transform 读取旧应用，把业务逻辑提取为用 EARS 格式编写的规格说明。
2. 整合：把同一产品的数百个冗余变体合并成精简的现代规格说明。
3. 合成：AI 智能体用 Python 生成金融产品及其测试。
4. 验证：人工审核，由银行的工程团队和风险团队拥有明确的签核权。

请注意两点启示：整合阶段说明旧系统里存在同一规则的许多副本；最后一个阶段完全由人来完成。这些是两家公司对其流程的说法，案例也来自银行，但这个方法适用于任何公司：先提取，再合并重复项，然后构建，在决策负责人签字之前不批准任何东西。

为什么每条规则都必须由流程负责人确认

AI 读到的是代码在做什么，而不是公司想要什么。两者之间的差距，正是现代化出错的地方：

• 废弃代码：它可能从一段多年未用的代码中提取规则，让它看起来像仍在生效的规则。
• 变成习惯的旧错误：系统对金额取整的方式是错的，员工一直手工更正。如果没人指出这是错误，提取出的规则会把错误一并带走。
• 代码之外的规则：会计手工处理的例外情况，永远不会出现在提取结果中。
• 相互矛盾的规则：两个不同位置有两套折扣计算方法。哪一套正确是业务决定，而不是技术决定。

因此，要为每条规则指定一位业务负责人签字确认：折扣规则由销售经理负责，滞纳金和审批规则由财务经理负责。确认后的规则将成为新系统需求文档的基础，如何编写我们在 软件需求编写指南 中讲过。还要注意，代码和数据库可能包含客户或员工数据，因此任何在王国境外读取它们的工具，都需要进行第 3 部分讲过的审查，并参考 沙特数据与人工智能管理局（SDAIA）的指引。

Origami 的观点

在为旧系统做现代化时，我们把业务规则而不是代码视为最需要迁移的东西。我们用 AI 工具读取代码，以过去无法实现的速度把规则写成清晰的句子，但在流程负责人阅读并签字之前，我们不会把任何一条规则视为定稿。

随后，在围绕规则构建新系统之前，我们会用旧系统的真实数据测试每条已确认的规则，让新系统按公司的预期计算，而不是按工具的猜测计算。如果想了解我们的工作方式，请查看 我们的服务。

本周练习：一条规则，三张发票

不必等工具就可以开始。选一条经常引起争论的规则，比如折扣或滞纳金，然后按以下步骤操作：

1. 请流程负责人用一句话写下这条规则，格式为：当……时，系统应……
2. 从系统中调出应用过这条规则的 3 张真实发票：一张普通的、一张处于临界值的、一张有例外的。
3. 用写下的这句话手工计算每张发票，并与系统输出的结果对比。

如果三张都一致，这条规则就有了记录。如果有一张不一致，您就发现了一条隐藏规则或一个旧错误，而这正是任何现代化之前必须知道的事。

下一部分

现在您已经有了经过确认的系统规则。接下来是重大决定：是把系统原样迁移，把代码转换到现代平台，围绕提取出的规则重建，还是用现成产品替换、只保留数据？在第 5 部分中，我们会用一张表对比这些路径：各自适用于什么情况、保留什么、有什么风险，以及需要谁参与。

资料来源

• 面向大型机的 AWS Transform：官方页面 — 可追溯到原始代码的业务规则提取、可审阅的需求和等效性测试。
• Thought Machine 与 AWS：2026 年 9 月 29 日公告 — 四个阶段：EARS 提取、整合、合成和人工验证。
• EARS：Alistair Mavin 的官方指南 — 该格式、五种模式及其 2009 年首次发布。
• SDAIA：个人数据保护。