Lark 对接内部讨论会纪要

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

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

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

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

Lion 加入后提出可以在支付系统内单独开商户承接。Addy Zhang 说明 DeePayment 可以实现全部功能但尚未接全部国家，因此至少开三个商户（DeePayment、JoogoPay 亚洲、JoogoPay 美洲），配一个看板，看板由技术加 AI 来写很快，前提是能接收 Lark 机器人传出的审批。

技术侧确认：U 的打款接到供应商后可以发起，供应商那边还有二次审批；法币支持支付平台已有的币种，不支持的记录后手动打款；Lark 开放了很多 API，接入问题不大。

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

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

Addy Zhang 要求老熊和方方再调研国际版安全性。Kael Guan 判断没有问题：Lark 国际版本质是美国公司架构，团队在海外，平台只是工具不监控用户数据；数据被调取只有所在国立案一种可能，且以微信为例，即便立案，一对一私聊数据也很难拿到、追溯期很短。

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 审批对接支付系统、薪酬按部门盘方案三条在本次进一步细化。