Lark 对接内部讨论会纪要

分类：三、产品与技术（另见一、集团治理与资本 · 财务） 文件属性：集团内部文件，仅限授权人员阅知 会议时间：2026 年 9 月 21 日 12:13—12:42（北京时间），约 29 分钟 会议形式：线上 主持人：Addy Zhang 参会：Kael Guan、Lion（中途加入）、老熊（Julio Xiong）〔待确认〕、方方（Effie Li）〔待确认〕、其他产品技术与人力人员〔待确认，会中未报名〕 记录依据：会议录音、Whisper 自动转写、09-15 本地合伙人会议纪要第四节、09-20 产品技术部制度中心讨论会纪要 录音原件：../01_录音原件/2026-09-21_Lark对接内部讨论会.m4a 转写文字稿：../02_转写文字稿/2026-09-21_Lark对接内部讨论会.txt

转写为单声道自动转写，未做声纹区分，说话人按语境判断，不确定处标〔待确认〕。录音前 1 分钟为线上会议室等待期的杂音，已忽略。

一、会议结论

1. Lark 的用途边界定为两件事：审批和通知。全部审批统一放到 Lark，不再使用 Telegram 审批群；通知走邮件加 Lark，全员通知由 Addy Zhang 发出。JoogoPay 体系同样进入 Lark 做审批和通知，但不在 Lark 上讨论业务。
2. Lark 审批通过后，由机器人输出一条代付款进入集团自有财务系统，形成排队打款队列。U 与支付平台已支持国家的法币自动发放（供应商侧仍有二次审批），人民币不做自动发放，必须由人工点确认打款并留人工记录。
3. 自有财务系统收缩为一个功能：接收 Lark 审批出来的付款，区分自动发放与排队人工确认；配一个审批看板与按月、按年、按部门、按区域的统计功能；在支付系统内至少开三个商户（DeePayment、JoogoPay 亚洲、JoogoPay 美洲）。看板由技术加 AI 快速实现。
4. 报销打款节奏沿用新规：15 日前报销当月 15 日打款，15 日后报销次月 15 日打款。审批通过即进入队列，付款计划（含未来房租、薪酬）由此可提前规划。
5. 薪酬发放按部门盘方案：工资拆分为社保、人民币、U、红包等构成，人力资源部只对接每个部门的总金额与去向（对公、个人、支付宝红包），细节由部门方案确定。人民币对接只找一个对接人且三个月轮换一次，不再固定同一批人；U 兑换人民币由公司统一出口承接。个人收款环节不可能全部消除，通过 U 卡与支付宝红包只能解决一部分。
6. 这套"Lark 审批到各国法币与加密自动发放、人民币由客户自己解决"的通路，同时作为面向出海中国企业的对外产品场景设计，先把内部走通，再对白名单客户开放。
7. Lark 国际版安全性由老熊与方方再做调研评估；Addy Zhang 的判断是即使有风险也要用 Lark 完成审批和通知。Kael Guan 的观点：Lark 国际版为美国公司架构，个人数据被调取需所在国立案且难度高，公开群数据与一对一私聊数据的保护层级不同。
8. 审批群的数量和结构由 Kael Guan 统一调度；按部门制定流程、报销制度与薪酬制度，一个部门一个部门推进，技术部已盘完先用，下一个财务部。
9. 先用起来：Kael Guan 与 Amanda 已开始用 Lark 开会，审批流程立即启用，迁移是一个过程。Lark 开放 API 充分，可接外部自动化；国内飞书使用经验证明上述需求均为成型能力。
10. 商户账户被攻击等安全问题由自有系统统一处理，不在本次范围内另行设计。

二、讨论过程

1. Lark 上做什么、不做什么

Addy Zhang 开场说明早上与 Kael Guan 沟通的两个问题。第一，审批必须在 Lark 上做，否则又回到人工审批、没有记录；JoogoPay 也要压进来做审批，可以只放审批和通知，强调不在上面聊工作。Kael Guan 认可，并提出全员通知也不要在 Lark 群发，Addy Zhang 说明通知走邮件加 Lark，全员通知由他自己发。

2. 审批出口与财务系统

第二个问题是 Lark 审批完成后的出口。Addy Zhang 说明审批完成后钱要不要发、发 U 还是法币还是人民币，可以变成机器人通知到群，之前设计的系统可以对接这些审批完成的记录并排单，例如报销 15 日前报的 15 日打款，之后的次月 15 日打款，审批成功后机器人进入排队打款。

Kael Guan 问人民币怎么打，Addy Zhang 答人民币肯定手动，但必须有人点确认，工资也是部门确认打款；技术部方案会写清底薪、红包、U 各发多少，手动加自动并行，U 和某些国家法币可以自动，例如巴西报销没有理由人工。Kael Guan 确认流程可行，但提出通过机器人对接的安全性要技术评估。

Addy Zhang 进一步说明：把最难的审批环节交给 Lark，Lark 审批完成后输出一条代付款进自有系统，财务后续只看代付款队列，三个月后的房租、薪酬都能提前规划。财务系统不再发散，收缩为"接收 Lark 审批出来的钱，哪些自动发放、哪些排队人工确认"一个功能，最终环节只在财务端。

Lion 加入后提出可以在支付系统内单独开商户承接。Addy Zhang 说明 DeePayment 可以实现全部功能但尚未接全部国家，因此至少开三个商户（DeePayment、JoogoPay 亚洲、JoogoPay 美洲），配一个看板，看板由技术加 AI 来写很快，前提是能接收 Lark 机器人传出的审批。技术侧确认：U 的打款接到供应商后可以发起，供应商那边还有二次审批；法币支持支付平台已有的币种，不支持的记录后手动打款；Lark 开放了很多 API，接入问题不大。Addy Zhang 确认只需要一个审批看板加自动与手动两条路；Kael Guan 补充加统计功能，按月、年、部门、区域分类。

3. 薪酬按部门盘方案与风险分散

Addy Zhang 说明昨晚已与人力沟通：每个部门的报销和工资都要有独立解决方案，国内用什么主体发社保、什么人发人民币或红包、多少人收 U。人民币对接未来只找一个人并三个月一换，因为现在固定四五个人已经做了一年，风险更大。人事只管对接部门总金额和去向，细节部门自己定。

有参会者问打给个人还是对公、以后是否仍有个人发放。Addy Zhang 说明个人收款不可避免，劳务派遣与全职的差别只在社保，税一样；工资拆成社保、人民币、U、红包几段，五万元工资全部走社保口径不现实，所以让技术部先盘；U 兑人民币由公司解决，统一风险出口。U 卡和支付宝红包只能解决一部分，永远解决不了全部。

4. 对外产品视角

Addy Zhang 提出这不只是风险考虑，也是产品设计：如果客户是非常白的电商企业且同样用 Lark，集团可以提供"各国法币与加密由我们解决、人民币客户自己解决"的方案，先把内部通路走通，风险落在具体部门去考虑。

5. Lark 国际版安全

Addy Zhang 要求老熊和方方再调研国际版安全性。Kael Guan 判断没有问题：Lark 国际版本质是美国公司架构，团队在海外，平台只是工具不监控用户数据；数据被调取只有所在国立案一种可能，且以微信为例，即便立案，一对一私聊数据也很难拿到、追溯期很短。Addy Zhang 的结论是即使有风险也要用 Lark 完成审批和通知，审批这一环全部放上来，不再自己搞 Telegram 审批群。

6. 群治理与推进顺序

Addy Zhang 提出审批要建多少群、部门群和工作组群如何设，需要 Kael Guan 统一调度，现在 Telegram 审批群太多太乱。按部门定流程、报销制度、薪酬制度，一个部门一个部门来，技术部已盘整完先开始，再到财务部，全部盘完整条通路就通了。Lark 审批机器人要到自有可打款财务系统，U 和已支持国家法币自动打款，法币不支持的手动打款并人工记录。

有参会者说明在国内一直用飞书，会上提到的需求都是成型能力，接外部自动化只需接一个应用，开放度很高。Kael Guan 提出先用起来，他与 Amanda 前两天已开始用 Lark 开会，审批流程也先用，迁移是过程，Lark 成熟度很高。有参会者问开多个商户后的账户安全问题，Addy Zhang 答自有系统统一处理，不必额外操心。

三、后续安排

四、与既有决议的衔接

• 09-15 本地合伙人会议第四节：双体系隔离原则不变。本次明确 JoogoPay 体系进入 Lark 仅限审批与通知，不做业务讨论，与"独立组织或独立空间"方向并行；待议清单第 19 项（Lark 双体系组织图、账号规则、权限矩阵与安全评估）与本次第 1 项安全调研合并推进。
• 09-15 财务边界：财务申请、账目复核、资金审批、薪资发放进集团统一财务治理。本次将审批环节落在 Lark、付款环节落在自有财务系统，均由 Kael Guan 及财务团队按权限管理。
• 09-20 产品技术部制度中心讨论会：报销 15 日打款节奏、Lark 审批对接支付系统、薪酬按部门盘方案三条在本次进一步细化。