Figma 财务团队开始自己构建工具，如何守住数字与判断的可靠性

一、嘉宾背景

Praveer Malani 是 Figma 首席财务官。这场约五十分钟的访谈围绕财务自动化、工具构建和经营领导展开：当财务人员可以自己连接数据、制作应用、改造流程，负责人如何组织团队、判断成果，并参与经营。Malani 讲述了自己及团队的实践，其他参与者补充了招聘、投资组合公司和财务工具方面的观察。

Malani 回忆，加入 Figma 早期，他曾用约四百至五百行 SQL，将产品使用情况与 Stripe 财务信息连接起来，生成标准数据表，再由数据科学人员纳入 ETL 定时任务，输送给 Salesforce、Marketo 等业务系统。他对构建工具的理解由此有了具体起点：把分散的数据接起来，为业务讨论和行动提供共同基础。

他也通过日常数据了解客户。入职初期，每天约有三十人购买付费计划，他会逐条查看个人或企业邮箱，寻找可以联系的对象，逐步积累对客户的认识。如今，他查看小时级看板和每日指标，也鼓励团队频繁关注变化，主动处理异常、识别机会。这些经历贯穿财务、数据与业务，也构成了他讨论团队能力和经营责任的背景。

二、本期主要内容

Malani 在访谈中介绍了财务人员如何直接改造日常工作。信用与催收团队的 Kajal 重建了发票跟踪、催收和 NetSuite 核对流程，随后又将自动化延伸到信用检查和分散的数据集。按 Malani 的解释，这让员工能够把注意力转向回收天数及更重要的问题，同事也可以复用这些工具。访谈没有提供应收账款回收天数或工时的实际降幅，因此能够确认的是流程发生了变化，收益仍缺少量化结果。

企业发展团队则把构建用于尽调：尝试重建目标产品，以形成对技术难度和护城河的直觉。具有财务背景的团队成员继续与产品团队合作，原型为双方讨论提供了具体依据。他们还把领导者反复提出的问题和反馈习惯编码成人格或技能，用于预审投资及并购备忘录，找出论证不足和需要继续尽调的部分。Malani 称，团队共同评审的周期因此缩短，但没有量化这一变化。

这些尝试使用了多种工具，包括 Codex、ChatGPT 智能体技能及工作流工具，以及开始用于创建和托管应用的 Figma Make。员工能够围绕自身需求动手，也使招聘更重视对成果的理解。Malani 强调好奇心、数据能力、结构化提问和沟通能力；在财务副总裁案例面试中，候选人可以使用现有工具，但必须解释模型结构、敏感变量及其背后的业务判断。

构建和生成材料的便利，也带来了新的工作要求。Malani 说，Figma 已有标识 AI 写作内容的政策，作者需要先自行阅读、理解、总结并简化材料，再交给同事阅读。学习则通过领导示范、同伴分享、黑客松和外部交流展开。他认为，理解数据集、系统架构，以及哪些地方可以接受推断，有助于更快取得进展。他还转述，有员工把探索空间与工作乐趣、愿意留下联系起来；他也开始在招聘中讨论技术使用条件，其他参与者则强调，要让候选人看见实际的构建文化。这些反馈尚不足以量化留任效果。

Malani 希望，自动化能让支持自助业务的财务人员从反复核对上周、上月的数据，转向研究实验、趋势和新增预算的投向。他说，定期材料的生成已经更快、质量有所改善，团队因而能更专注于注释和理解。不过，这些进展没有量化结果，业务复杂度也仍在持续占用团队的时间。

三、核心观点：推理、例子与边界

构建工具要转化为经营能力，首先得接上可靠的数据。Malani 早期用 SQL 连接产品使用情况与财务信息，建立标准数据表；后来，AI 降低了连接和分析数据的操作门槛，数据含义上的分歧却仍需团队解决。另一位参与者提到，一家公司的客户成功人员分别搭建看板，得到的数字彼此冲突。生成界面变得容易，并不意味着业务事实已经统一。

为二〇二七年规划准备的差旅及招待费用评审，具体呈现了数据整理的难度。团队需要合并多个来源，并通过模糊匹配判断活动地点、居住地点与出行之间的关系：同样是参加异地活动，参与者是否本来就住在那里，会影响费用归类。Malani 估计，这个案例约百分之九十五的挑战在于数据准备；他还提到，一次可视化修改在收到反馈后约三十分钟完成。前者是他对这项工作的估计，后者是一次修改的耗时，都不足以作为财务自动化的通用效率基准。

这项评审接受方向上的准确，以便找出费用政策中值得进一步检查的地方，因此可以容忍部分推断。会计数据的要求则更严格。Malani 认为，有会计经验的数据科学人员更容易理解退款、无法收回的款项和检查制衡机制，也更清楚哪些结果必须准确。对于业务关键系统，他承认，产出达到审计要求的结果仍有很高门槛，需要与审计师讨论认可条件。探索分析中可以接受的误差，不能直接沿用到正式核对与披露。

工具承担更多执行工作，也要求使用者更清楚地理解结果。Malani 的案例面试允许候选人使用现有工具，但生成模型只是开始；能否解释模型结构和最敏感的变量，才体现其理解与业务判断。企业发展团队尝试重建目标产品，也是为了形成对技术难度和防御能力的直觉，仍需与产品专家合作。复刻原型不能单独证明目标公司是否拥有护城河，把领导反馈编码成审阅技能，也不能替代真实的投资判断。

个人工具进入共享流程后，维护责任随之增加。Malani 看到，内审追补工单、GRC 收集审计资料、应付账款处理应计项目，都包含信息收集、跟进、分流和核对。他希望把这些共通需求整合成可复用的系统：业务专家发现需求、制作原型，CIO 组织负责上游依赖、托管、人员离职后的延续性以及跨团队复用。这种分工保留了业务探索的速度，也为工具的长期使用安排责任。不过，Figma 的集中化仍未完成，部分工作集中管理，部分仍由团队自行推进。

正式指标的一致性，是这套分工必须守住的边界。Malani 表示，财务团队负责正式指标输出，董事会、管理层和财报沟通应保持一致，历史数字与指标定义也需要稳定。代码更容易获取，并不意味着指标可以随意改写。他所说的财务创造力，是从新的角度理解业务、提出经营意见。要推动这些意见落地，CFO 仍需具备会计与规划基础、经营责任感和运营严谨性，也需要沟通、建立关系、发挥影响力，并获得他人的信任与支持。Malani 承认，自己起初低估了这些能力的重要性。

评估自动化时，还要区分试验数量与持续成果。一位参与者转述，另一家公司在一两个月内做出四十至五十个智能体，又明确猜测其中约九成可能已不再使用。试验有助于培养面对重复劳动时优先考虑自动化的习惯，但仅凭构建数量，无法判断持续使用情况和业务收益。Malani 关于一年后可能需要更少人员的设想，同样以业务复杂度不变为前提；新产品、收购和业务演进仍在增加 Figma 的支持需求。人员需求如何变化，取决于自动化进展与业务复杂度的共同作用。

四、学习与应用

将这些经验用于实际工作，可以先从要改善的业务决策倒推流程。若目标是改善催收，就找出发票、收款和核对之间反复需要人工衔接的位置，再判断工具能否帮助员工更早处理影响回款的问题。Kajal 的案例提供了选题思路，却没有收益基线。实施时需要分别记录核对耗时、异常处理和回收表现，才能判断变化，也应避免把流程建成直接等同于回款改善，或一次铺开所有相邻流程。

数据与定义需要先于报告成形。访谈末段，一位参与者建议，先建立数据完整性、访问能力和基础追踪，再逐步形成严谨的报告、指标和业务叙事。他提到，有些收入算法并不适合相应的商业模式，并批评了在 ARR 上玩弄口径的做法。落实到工作中，基础事件尚未可靠记录，就应先修复追踪；多个系统对同一概念理解不同，就应先明确映射关系。自然语言界面无法补回缺失的记录，收入定义也仍需团队依据业务作出判断。

执行流程还应区分确定性处理与允许推断的分析。费用探索可以参考访谈中的模糊匹配做法，同时保留有歧义的分类供人检查；正式核对则需要更严格的验证。Malani 的采购取向也提供了一条边界：核心记录系统以及不能承受错误的环节采用采购方案，内部构建主要用于重复性日常流程。采购本身并不免除验证责任；业务关键输出仍需明确检查机制，并及早与审计师讨论可接受的条件。

验收分析成果时，可以先要求作者说明模型结构、输入、敏感变量，以及哪些变化会影响业务判断，再通过直接操作模型核查。Malani 看重 Excel 的直接操作如何帮助建立直觉与信任，也会让 AI 从包含二十个工作表的模型中识别关键驱动因素和敏感项。他把这些结果作为审阅起点，后续仍需返回模型检查。一位投资者参与者提到，有些工具会随结果提供审计轨迹；Malani 对总账跨期波动分析的定位则是先生成解释和调查线索，帮助继续追查，而非保证结论正确。

当原型开始被其他人依赖，就需要明确维护负责人、托管位置、上游系统、共享范围和交接安排。业务人员可以先验证需求，再由系统团队判断哪些部分值得共用。这会增加协调工作，也有助于减少重复建设和对个人的依赖。推广时，内部展示可以围绕数据连接、失败条件和使用边界展开，并分别观察试建、持续使用与业务结果。Malani 所描述的领导示范和同伴学习，可以支持这一过程；另一家公司大量试建智能体、许多可能已停用的转述，也提醒团队持续检验使用情况，其中停用比例仍只是参与者的猜测。

释放出来的时间，也需要有明确用途。支持自助业务的财务团队可以把固定材料的生成交给工具，将人工注意力投入实验解释、趋势研究和增量预算讨论，前提是材料经过验证，团队也有时间和权限推动行动。业务复杂度上升可能抵消节省，因而无法预先承诺人员削减。判断成效时，应继续追问：团队是否更早发现值得调查的变化，能否解释原因，以及是否将这些认识转化为经过讨论的经营选择。

来源

• 原始节目：How AI Is Turning Figma’s Finance Team Into Builders