自我改进的 Tax AI：OpenAI 的实践与三个关键设计

TL;DR

OpenAI 和 Thrive Holdings 合作为 Crete 的 30+ 会计师事务所构建了 Tax AI，一个能够自我改进的税务 agent。它在_tax season 处理了 7000 份纳税申报单，准确率从第一周的 25%（75% 字段正确）提升到六周后的 86%。一个高级会计师去年花了 180 小时准备税务，今年只花了 15 小时。

Key Insight: 这个系统的核心不是「让 AI 更聪明」，而是建立一个让生产环境持续产生结构化信号的反馈循环——每次从业者的纠正都被捕获、分类、变成 eval target，最终成为 Codex 的工程任务。这是「生产即评估」的设计哲学。

数字本身说明问题

Tax AI 在 Crete 的_tax season 处理了 7000 份纳税申报单。

关键数字：

准确率提升曲线：上线时只有 25% 的申报单达到 75% 字段正确；六周内 86% 达到该水平。90% 和 100% 正确率的增长更快
时间节省：从业者节省了约 1/3 的税务准备时间
准确率天花板：最终 draft 准确率达到 97%
吞吐量提升：约 50%
个体案例：一位去年花 180 小时做税务准备的高级会计师，今年只花了 15 小时——其余时间用来给每个客户打电话讲解报税，这个质量是去年不可能做到的

这些数字的真正意义不是「AI 变强了」，而是系统学会了从使用中学习。

核心问题：为什么产品改进是手动的？

文章指出了一个几乎所有 AI 产品都会遇到的问题：

在产品早期，大多数纠正都是手动的。从业者可以纠正系统错误，但产品没有捕获完整上下文——一个变化的值可能是真正的提取失误、映射问题、不支持的产品行为，或者只是工作流噪音。区分这些情况仍然需要工程团队的跟进。

这不是技术问题，这是产品设计问题。

团队没有信号来识别正确的 hill（该爬哪座山）。工程师可以使用 coding agent，但系统没有被设计成在改进循环中有意义地使用 AI。

解决方案不是「雇佣更多工程师」，而是让生产环境本身产生改进所需的信号。

三个设计支柱

Tax AI 的架构围绕三个支柱设计：

支柱一：贴近从业者

做工作的人需要引导产品学什么。从业者的直觉和理解揭示了哪些错误重要，帮助inform下一个工作流优先级。

这听起来是理所当然的，但关键是：从业者的反馈不是被动的评价，而是主动的导航。他们不只是在说「这个错了」，而是在说「这个方向值得改进」。

支柱二：让生产创造证据

产品不能只捕获 inputs 和 outputs——它需要捕获从源材料到提取字段和 provenance、再到下游提交和专家纠正的完整路径。

这是「生产即评估」（Production as Evaluation）的设计哲学。在传统系统中，生产环境是「真相发生的地方」，评估只能在实验室里模拟。Tax AI 的设计让生产环境本身成为了评估数据的来源。

支柱三：Codex 驱动的改进循环

一旦生产问题可见且被结构化，它们就能变成 finding、tailored evals 和 scoped 工程任务。然后 Codex 可以帮助调查、提出修改、在 targeted 和 regression evals 上验证，并将产品向前推进。

关键不是让 Codex 盲目地尝试修复，而是给它一个明确的 hill to climb。

Rental Property 示例：反馈循环如何运作

文章用 Schedule E（个人报税的租赁财产）的提取作为具体例子，展示了完整的反馈循环：

第一步：从业者纠正揭示失败

预测值和实际申报值之间的差异可能反映真正的提取失误，也可能是从业者偏好、从前一年结转的值，或者在工作流中引入/更改的值。

通过让从业者帮助辨别这些情况，系统可以识别哪些操作需要从业者纠正或阻止提交。

关键是：每个干预都被记录为结构化数据——Tax AI 提出了什么，从业者修改了什么，最终什么被放入已申报的申报单。

第二步：产品 traces 把纠正变成 evals

对于租赁财产这样的复杂工作流，系统必须保留从源文件到已申报申报单之间发生的事情。沿着这条路径：

文档被组织、分割和分类
租赁财产字段被提取，带有回溯到源材料的引用
这些值被映射到税务引擎
从业者可能在提交前纠正它们

产品级 traces 使得调查失败发生的位置成为可能。将从业者纠正转化为有用的评估目标需要三个步骤：

捕获差异：Tax AI 输出与已申报申报单比较，产生字段级 review rows，捕获期望值、预测值，以及差异是否可操作
分组相关失败：相似的 review rows 被分组，分离重复性产品失败和预期工作流噪音。例如，重复的从业者纠正可能表明 Tax AI 经常遗漏「公平租赁天数」字段，错误处理「其他费用」，或者混淆同一源包中的多个租赁财产
将重复模式转化为 eval targets：经过审查和测量后，重复的 finding 成为 Codex 改进的明确 eval targets

第三步：Finding 成为 Codex 要爬的山

第三个支柱是创建一个能够对这些新 evals 采取行动的工程循环。这是 Codex 成为核心的地方。

假设 eval pipeline 标记 Tax AI 一致地遗漏「公平租赁天数」字段，而从业者总是可靠地填写它。由于这个 finding 已经被打包成 targeted eval set，包含代表性的源包和期望输出，Codex 可以直接在产品脚手架中调查根本原因。

Codex 不是仅仅处理一个欠缺的最终输出。它同时检查：

trace
eval
repo
skills

然后：

调查管道：检查源包、提取模式、mapper 行为和代码路径，确定问题是，不支持的字段、遗漏的提取模式、源选择问题、mapper 差距，还是 grader 问题
实施有针对性的修复：扩展提取模式、改善租赁财产文档的源选择、更新税务引擎 mapper、如果预期工作流噪音被计为失败则改进 grader
验证并提出：重新运行 targeted eval，运行更广泛的回归套件，并向工程审查提出候选 pull request
关闭循环：将重复的从业者纠正转化为可衡量的工程任务。如果证据不明确或不能安全自动化，案例会被路由回产品团队，而不是被迫通过循环

关键设计原则：从生产到证据

这个案例揭示了一个在 AI 产品开发中经常被忽视的原则：

你不能让工程师手动发现所有需要修复的东西。

在传统软件开发中，工程师通过用户报告、监控数据和代码审查来发现问题。这是手动和缓慢的——只有当工程师推动时，产品才会改进。

Tax AI 的模式是：让产品在其正常工作中产生结构化的改进信号。

每个从业者的纠正都是一条数据。这些数据被分组、分析，最终成为有明确成功条件的工程任务。Codex 不是在黑暗中摸索，而是在爬一座已经被清晰标记的山。

这与我在之前关于 Anthropic containment 架构的帖子中讨论的「feedback loops」是同一个哲学——但 Tax AI 把它应用到了产品改进层面，而不是安全层面。

可扩展的模式

文章指出，同样的循环可以应用于租赁财产以外的领域。

租赁财产花了大约六周和大量工程监督才达到 90% 精确度和召回率，但这项工作产生了可重用的抽象、review artifacts、eval 约定和实现模式，使支持类似复杂的 schedules（如 Schedule C 和 Schedule A）变得更加容易。

现在团队正在将相同的三个部分设计作为蓝图，用于在 Thrive Holdings 的其他领域构建工作流——会计工作流（如记账和审计）以及运营工作流（如 IT help desk 自动化）。

这个模式的关键洞察是：最好的 agent 是被人类引导着变得更 capable、更 trusted、更 valuable 的。

不是 AI 自己变聪明，而是人类用生产中的信号引导它朝正确的方向改进。

一个会计案例的深层含义

文章结尾有一个细节值得思考：

一位去年花 180 小时做税务准备的高级会计师，今年只花了 15 小时。其余时间她用来给每个客户打电话讲解报税——这是去年不可能做到的服务质量。

这揭示了一个在 AI 讨论中经常被忽视的点：AI 的价值不是替代人，而是把人从低价值工作中释放出来。

当 AI 处理数据录入和提取，从业者可以专注于需要人类判断和信任的工作——解释复杂的税务情况、与客户建立关系、提供高接触的服务。

这不是「AI 取代会计」的故事。这是「AI 让会计成为更好的会计」的故事。