尧图网站建设 
Omi EXP-001 Day-3 重新参与邮件实验全解析从预注册契约到随机对照实现【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend本文基于 Omi 开源仓库中的实验契约文档 EXP-001-day3-reengagement.md 展开。该文档定义了一项针对 macOS 新用户流失召回的随机对照实验用户在注册并产生内容后停止使用第 3 天收到一封展示 Omi 捕获结果的邮件观察其是否回归。文章不仅完整还原文档中的资格谓词、分配机制、指标与功效设计还结合仓库源码utils/experiments.py、utils/email/day3_reengagement.py、utils/email/lifecycle.py 等与单元测试讲清为什么必须随机化、如何保证对照组永不消失、如何用值信号而非活动信号判定回归这些核心工程决策。读完本文你将掌握一套可复用的预注册 随机对照 意图治疗分析实验设计范式以及它在一套真实批量邮件系统中的落地细节。一、实验概览一份先承诺、后执行的分析契约EXP-001 的状态标记为pre-registered预注册尚未启动not yet started注册日期为 2026-08-30归属growth / churn增长 / 流失工作流。文档开篇即点明其核心定位This file is the analysis contract.本文件即分析契约。所谓预注册有一个非常具体且可验证的标准它必须在第一批用户入组之前提交到仓库且作业入口 backend/modal/day3_reengagement_email_job.py 的常量PRE_REGISTRATION直接指向该文档路径见 backend/utils/email/day3_reengagement.py 第 59 行。代码与文档形成双向锁定的契约EXPERIMENT_ID EXP-001-day3-reengagement CAMPAIGN day3_reengagement PRE_REGISTRATION backend/docs/experiments/EXP-001-day3-reengagement.md这份契约还施加了一条硬性纪律一旦入组开始主指标或资格谓词的任何变更都必须启用新的实验 id。原因在于实验的分配盐salt就是实验 id 本身——详见下一节分配机制——修改契约而沿用 id 意味着无法在事后重建名册roster历史分配将不可解释。为什么要承诺在先实验中最大的统计风险不是做错了分析而是做了很多次分析直到出现显著结果。预注册把主指标、资格条件、分析方法、读数时间点全部冻结在入组之前杜绝了结果驱动的选择偏差researcher degrees of freedom。这套思想贯穿本文后面每一节资格谓词有固定优先级、中间读数只报置信区间、对照组永远不会被条件化剔除。二、研究假设一封展示Omi 捕获了什么的邮件能否召回流失用户文档给出的假设Hypothesis原文为A macOS user who signed up, produced something on day 0, then stopped, will return more often if they receive one email on day 3 showing them what Omi captured, than if they receive nothing.即一位在 macOS 上注册、第 0 天产生了内容、随后停止使用的用户如果在第 3 天收到一封展示 Omi 捕获成果的邮件比什么都收不到时更有可能回归。注意假设的措辞刻意限定了人群特征——第 0 天产生过内容这与后面的资格谓词、邮件文案分支个性化 vs 通用严格对应。三、为什么必须随机化观察性数据的显著且无意义实验文档用一整节回答了为什么不直接上线然后看留存这背后是 2026-08-26 的一次同队列cohort研究教训该研究发现四个行为杠杆如录音使用、通知接收、聊天使用其粗留存风险比高达 1.9–2.2但经 Mantel–Haenszel 方法按第 1 周活跃天数调整后每一个都塌缩到约 1.05–1.11。这说明这些杠杆只是潜在参与度latent engagement的标记物而非成因。在 Omi几乎所有做了 X 的用户 vs 没做 X 的用户的观察性对比都被这一个潜在参与度变量主导而任何干预的资格都与参与度相关。因此不做随机化的上线会得到一个真实、统计显著、却完全无意义的数字。这一教训被完整复刻在 backend/utils/experiments.py 的模块 docstring 中作为该模块存在的根本理由。四、实验单元、分配机制与 50/50 分桶4.1 单元与分配单位单元Unit已认证的 Firebaseuid。分配单位 分析单位即同一用户不会被拆成多个观测。分配Assignment调用 backend/utils/experiments.py 的enroll对sha256(EXP-001-day3-reengagement:uid)做确定性哈希并把结果持久化到 Firestore 集合experiments/EXP-001-day3-reengagement/assignments/{uid}。4.2 确定性哈希如何工作utils/experiments.py的核心实现第 86–103 行_BUCKET_RESOLUTION 10_000 # 分桶分辨率万分位 def bucket_of(experiment_id: str, uid: str) - int: digest hashlib.sha256(f{experiment_id}:{uid}.encode(utf-8)).digest() return int.from_bytes(digest[:4], big) % _BUCKET_RESOLUTION def assigned_variant(experiment_id: str, uid: str, *, treatment_share: float 0.5) - str: if not 0.0 treatment_share 1.0: raise ValueError(treatment_share must be within [0, 1]) return TREATMENT if bucket_of(experiment_id, uid) round(treatment_share * _BUCKET_RESOLUTION) else CONTROL关键设计点实验 id 即盐哈希输入是实验id:uid。好处是新实验天然重新随机化某个用户在一个实验里运气差不会在下一个实验里系统性倒霉坏处是一条铁律——绝不能重命名正在运行的实验否则全体人群会被悄悄重新打散。万分位分辨率_BUCKET_RESOLUTION 10_000使分桶可精确到万分之一basis point比当前流量下任何可检测的效果粒度都细且桶算术保持为整数运算。持久化而非重算纯哈希看似优雅但存在两个致命问题任何人改盐都会导致全体静默重随机化更关键的是对时间窗实验注册后 72–96 小时、且未回归而言资格是一个时刻的属性——窗口前不成立、窗口后也不成立事后没有任何状态可以反推名册。因此每个入组用户落地为一个 Firestore 文档同时让批处理作业的重试天然幂等。4.3 两臂同路径入组对照组在构造上不会消失enroll第 124–187 行对两臂走完全相同的代码路径、在同一时刻写入并在治疗投递之前向 PostHog 发出Experiment Enrolled事件两臂都发。这对邮件实验不是锦上添花而是生死攸关对照组用户可能再也不打开应用任何客户端侧机制都无法观测到他们。只有入组先于投递、两臂同路径对照组才在构造上留在分母里。enroll还做了两件防御性的事幂等已入组用户返回原变体且newly_enrolled False调用方据此避免重投治疗写失败 硬失败分配无法持久化时返回None调用方不得投递治疗——一次未投递的治疗只是丢失一个数据点而一次已投递却未记录的治疗会静默污染对照组直到实验结束。五、资格谓词五条规则与值信号的哲学文档定义资格须同时满足全部 5 条All ofmacOS 注册signup_os∈ {macos,mac,mac os x}。注意这不是signup_platform——后者只有与 Windows 共享的粗粒度desktop桶且signup_os是客户端原始 header 小写化而非规范值所以要用集合匹配。裸desktop被排除因为 Windows 客户端也会写入该值。注册时间窗signup_platform_at距离运行时刻 72–96 小时每天恰好一个 24 小时注册队列。第 0 天窗口之后零条真实会话第 0 天 自signup_platform_at起 24 小时。真实discarded False且状态非in_progress。Firebase Auth 记录上有可投递的邮箱。未退订生命周期邮件且此前未收到过 EXP-001 邮件。5.1 为什么不用last_active_at也不用App Launched两者都被开机自启launch-at-login污染record_user_platform会在每次认证请求上盖last_active_at时间戳所以自动启动的桌面应用会让该字段一直温热而用户其实什么都没得到App Launched有同样的缺陷——这正是流失研究报告严格 14.1% 留存与27.4% 头条留存并存的根源。如果以两者之一判定是否回来就会系统性排除本邮件要触达的未参与但机器仍在跑的用户。因此规则 3 改用值信号value signal。5.2 为什么裸会话数也是同一个错误会话文档不是用户输出桌面监听 socket 在每次会话开始和每次重连时都会写入一条in_progress会话所以一台仅仅开着的 Mac 就会制造出带新鲜created_at、却毫无内容的文档空会话结束时被标记discarded。统计它们会让是否回来对每一台通电的安装都为真——这是换了一顶帽子的 launch-at-login 污染最终会把合格集剥离到只剩机器关机的用户与目标人群恰好相反。5.3 为什么status completed是相反方向、且更糟的错误直觉上收紧到 completed更安全但对本队列反而更危险_store_deferred_conversation会把 freemium/Neo 用户的桌面录音以deferred True、status processing持久化直到用户打开它。这些是真实的已录制会话永远不是completed而它们恰好属于本实验瞄准的新 macOS 用户人群。要求completed会把这些人报告成什么都没产出、再也没回来。所以规则 3 统计的是discarded False且状态除in_progress外任意的文档——一段已经结束的会话无论后续增强处理做了什么。它刻意不是get_conversations的默认行为后者只过滤discarded会把 stub 留在结果里。5.4 源码中的落地显式 allow-list 而非! in_progressbackend/utils/email/day3_reengagement.py 第 82–95 行把该谓词实现为显式允许列表MACOS_SIGNUP_OS_VALUES frozenset({macos, mac, mac os x}) ENDED_CONVERSATION_STATUSES tuple( status.value for status in ConversationStatus if status is not ConversationStatus.in_progress )两个实现细节值得注意signup_os不经过_normalize_platform的别名表database/users.py只规范化粗粒度桶原始 header 值会原样到达因此匹配一个字面量会静默丢掉真实 macOS 用户——测试 test_day3_reengagement.py 中test_every_macos_signup_os_spelling_is_eligible专门钉死了macos / mac / mac os x / MacOS / Mac OS X全部拼写都必须合格。状态用 allow-list 而非! in_progress除了语义清晰还有一个 Firestore 层面的原因in过滤器可以与等值、范围共用同一个复合索引被服务而!不能。从ConversationStatus枚举派生则意味着新增状态会在此处成为一个显式可见的决策而非被静默排除。5.5 决策函数的固定优先级漏斗是分区而非重叠计数evaluate_candidate第 139–170 行按固定优先级逐条判定每个候选者精确归属到它失败的第一条规则not_macos → no_signup_timestamp → too_early → too_late → returned → already_sent → opted_out → no_email这使得漏斗计数RunSummary.ineligible字典是一个无重叠的分区。测试test_rejection_reasons_partition_by_fixed_precedence验证了多因同时命中时只记首个原因。候选收集端collect_day3_candidates以limit(500)MAX_USERS_PER_RUN分页且第 0 天后是否回归用limit(1)布尔化——只取一条即可判定第 0 天产出数封顶 11因为文案只会报告较小的 N。5.6 Firestore 查询的两个字段陷阱record_user_platform写入两个粒度不同的平台字段signup_platform是粗桶macOS 和 Windows 都写desktopsignup_os是细粒度 OS 串。于是显而易见的查询signup_platform macos永远匹配零个文档且静默失败——实验会一个都不入组而没有任何报错。源码因此用实际写入的值desktop做索引等值查询把 macOS 收窄留给evaluate_candidate对signup_os的判定Windows 注册者会被取出再以not_macos拒绝每轮略有浪费但受同一分页上限约束。三个查询均以注册规范登记在 backend/database/firestore_index_registry.pyDAY3_REENGAGEMENT_SIGNUP_COHORT_QUERY、DAY3_REENGAGEMENT_DAY_ZERO_CONVERSATIONS_QUERY、DAY3_REENGAGEMENT_RETURNED_CONVERSATIONS_QUERY并用 AST 级覆盖率检查器确保实际查询与声明的索引规格一一对应。5.7 边界测试与固定优先级的边界测试test_72h_96h_window_boundaries精确钉死窗口边界语义age 72h→too_early72h age 96h→ 合格age 96h→too_late恰 96.0 小时即算过期。测试test_in_progress_stubs_and_discards_do_not_count_as_coming_back验证了整支目标队列都依赖的判定in_progressstub 与discarded空会话都不能算回归test_every_ended_status_counts_as_real_output则参数化验证processing / merging / completed / failed四种结束态都算真实产出。文档将此定位为覆盖性选择coverage choice而非效度威胁——它只改变谁合格且对两臂完全相同。六、治疗方案一封邮件、两个文案分支、同一治疗臂治疗 第 3 天发送一封邮件文案按第 0 天是否产出内容分支第 0 天产出邮件主题源码实测内容有产出Omi captured something on your first day个性化展示 Omi 在第 0 天捕获的会话数并说明 Omi 的价值往往在连续运行数天后显现无产出Getting the most out of Omi通用首值提示保持后台运行一整个工作日、开启通知以便 Omi 告知发现实现函数build_reengagement_email第 173–213 行有两个值得单独说明的安全决策所有用户输入被转义_escape对display_name做 HTML 实体转义测试test_copy_escapes_a_hostile_display_name用scriptalert(1)/script验证不插值任何会话内容文案只用会话数这个数字绝不把转写派生的标题放进邮件——把转录内容送进邮件是一个尚未被任何人做出的隐私决定。测试test_copy_has_no_parameter_that_could_carry_conversation_content通过检查函数签名直接钉死这一边界。两个分支属于同一个治疗臂随机化会平衡两分支在臂间的分布因此合并估计是对异质人群的平均治疗效果ATE的有效估计。第 0 天产出分层只作为探索性exploratory切分报告绝不提升为结论——这是把 Mantel–Haenszel 教训向前应用。对照组不收到任何东西、也绝不被联系。七、指标设计主指标、次要指标、护栏与意图治疗7.1 指标分层主指标Primary入组后第 3–9 天≥1 个活跃日。合格人群的实测基线12.1%43/355PostHog 项目 302298查询于 2026-08-30。次要指标Secondary监测而非确证第 30–44 天留存采用规范队列契约的两个定义任意显式事件 / 严格非启动。实测第 14–23 天代理基线约13.2%。护栏Guardrails因伤害而停止生命周期邮件退订率、垃圾投诉率、硬退信率。纯描述性Descriptive only已发送、已送达、退信、已打开。7.2 为什么打开率永远不能进入比较分析是意图治疗intention-to-treat比较绝不以打开为条件。打开者是参与度高的用户以打开过滤会重新引入随机化本想消灭的混淆因子何况 Apple Mail 隐私保护已让打开率在很大程度上成为虚构数字。7.3 退订端点的 GET/POST 动词拆分一个被链接扫描器逼出来的设计文档指出退订率只有在退订端点拆分动词时才可读GET /email/unsubscribe只渲染确认表单、不写入任何状态POST才执行退订。原因企业链接扫描器Outlook Safe Links 等网关会在收件人看到邮件之前抓取正文中的每个 URL——如果写操作挂在GET上扫描器就会制造出无人想要的退订抑制真实收件人并把护栏指标从伤害抬高成扫描流量邮件客户端发起 RFC 8058 一键退订List-Unsubscribe-Post本身就是POST因此该路径保持真正的一键。该端点实现在 backend/routers/email_preferences.pyGET渲染带确认按钮的 HTML 表单按钮把 token POST 回同一路径POST校验签名 token 后写入email_preferences.lifecycle_opted_out。退订 token 由 backend/utils/email/lifecycle.py 的mint_unsubscribe_token用 HMAC-SHA256 签署uid:purpose而成刻意永不过期——过期的退订链接是暗黑模式和可访问性失败邮件在归档里存放数年点击两年前链接的人恰恰是最有资格被移除的人。八、统计功效诚实的边界流量基线约160 个 macOS 注册/周Onboarding Completed去重最近 8 个完整周171, 136, 163, 191, 150, 151, 158, 172。经过资格、邮箱可用性与抑制后规划约100 个入组/周。基于会话的规则 3 尚未被直接测量因此作业会记录完整资格漏斗第一周的真实数字将取代此估算。功效公式双比例、双侧 α0.05、power 0.80、50/50n/arm 7.85 × [p₀(1−p₀) p₁(1−p₁)] / Δ²指标基线效果n/臂总计按100/周入组成熟期结论重新激活12.1%12pp2×157314~3周9天~1个月——可行重新激活6pp5541,108~11周9天~3个月——可接受上限重新激活4pp1,1812,362~24周9天不可行D30–44 留存~13%8pp345691~7周44天时间线可行但一封邮件 8pp 不现实D30–44 留存5pp8271,654~17周44天~6个月D30–44 留存3pp2,1834,366~44周44天不可行文档给出的结论非常直白This experiment cannot be powered for day-30–44 retention at any plausible single-email effect size (1–3pp) in a reasonable timeframe.这正是主指标选择重新激活的原因它位于通往留存的因果路径上、9 天即可成熟、且真实可检测。如果一封邮件连重新激活都推动不了它更不可能推动留存而且能廉价地被淘汰。常驻 50/50 分桶让留存问题可以在约 4–6 个月后用累积名册作答而无需把发布押在它上面。九、读数时间表与停止规则中期读数Interim达到 314 入组目标的 50% 时只报置信区间。仅因护栏伤害而停止。不是成功读数。确证读数Confirmatory314 个入组时只统计 9 天窗口已完全过去的用户assigned_at now() - INTERVAL 9 DAY。留存读数Retention不早于 6 个月且已成熟assigned_at now() - INTERVAL 44 DAY。没有看仪表盘就拍板的决策通道。这很容易遵守主指标在每次发送后第 9 天才存在。十、分析方案无协变量调整分析的分母是experiment_id EXP-001-day3-reengagement的Experiment Enrolled事件左连接后续活动。报告两比例检验的绝对百分点差与 95% 置信区间。无协变量调整——随机化已经做了那份工作确证读数中不做亚组分析。十一、Kill Switch 与部署架构11.1 默认关闭、fail-closed 的权威开关文档规定DAY3_REENGAGEMENT_EMAIL_ENABLED必须显式为 true作业才做任何用户工作缺失、畸形或不可读的值一律fail closed——新部署的作业默认黑暗dark。源码把这一纪律实现为双层开关backend/utils/email/day3_reengagement.py 第 98–115 行ENABLED_ENV DAY3_REENGAGEMENT_EMAIL_ENABLED KILL_SWITCH_ENV DAY3_REENGAGEMENT_EMAIL_KILL_SWITCH class Day3Authority: enabled: bool False kill_switch_active: bool False property def may_send(self) - bool: return self.enabled and not self.kill_switch_active作业入口 day3_reengagement_email_job.py 在触碰任何用户数据之前先解析权威authority_from_environment并用getattr(authority, may_send, False) is True做防御——权威提供者不可用时同样失败关闭而不是让新部署的作业顺带执行用户工作。未打开时作业在候选选择之前就退出。11.2 部署形态Cloud Run Job 每日 Scheduler镜像Dockerfile.day3_reengagement_email_job 基于 Python 3.11 slim 镜像先安装依赖、再把backend/整体拷入入口为python day3_reengagement_email_job.py。定时scripts/provision_day3_reengagement_scheduler.py 以gcloud scheduler创建/更新名为day3-reengagement-email-daily的 HTTP 触发器指向 Cloud Run Jobday3-reengagement-email-job计划为0 15 * * *UTC 每天 15:00。注释解释了每日节奏的选择资格窗口每个运行正好覆盖一个 24 小时注册队列低于每日的节奏只会重查同一个基本为空的窗口高于每日则会漏掉整个队列。脚本通过describe → update/create → resume保证描述失败可回退到 create而认证/权限失败必然让部署失败。十二、工程纵深批量邮件的可靠性细节12.1 三层防重入组幂等、发送账本、提供方幂等键批量邮件最可怕的失败是重复发送backend/utils/email/lifecycle.py 为此堆了三道闸入组幂等enroll对已入组用户返回原变体不重复计数发送账本claim ledgerclaim_lifecycle_send以create()原子占位users/{uid}/lifecycle_email_sends/{campaign}——文档已存在则创建失败天然防并发。release_lifecycle_send只在确定未发出时释放提供方幂等键send_lifecycle_email以sha256(flifecycle:{campaign}:{uid})作为 Resend 的Idempotency-Key即使重试快过 Firestore 账本也有第二道锁。12.2 异常三分法未知投递结果必须保留 claimlifecycle.py定义了三种异常run_day3_reengagement对它们的处置截然不同异常语义claim 处置LifecycleEmailSuppressed选中与发送之间用户退订释放 claim记录suppressed用户保持入组ITTLifecycleEmailNotConfigured凭证或签名密钥缺失释放 claim中止整轮LifecycleEmailDeliveryUnknown请求到达提供方、响应未读到claim 必须保留——重复比漏发更糟其他异常发生在触达提供方之前Firebase Auth 读取、模板构建等释放 claim让 Cloud Run 重试可恢复测试 test_day3_reengagement.py 中的test_a_treatment_user_whose_send_failed_is_retried_on_the_next_run提供方不可达→释放→重试成功与test_an_unknown_delivery_outcome_keeps_the_claim读超时→保留→不再重发把这条不对称规则钉成契约。12.3 入组是分析锁claim 是发送锁两者不可混同一个看似幂等的优化——已入组就直接跳过——实际上是永久性发送失败治疗用户第一次尝试在入组与投递之间死亡后后续每一轮都会跳过它永远不发信却仍被计为治疗组静默稀释实验想测的效果。因此run_day3_reengagement对newly_enrolled False的处理是继续走 claim 流程由 claim 账本决定是否真的发见test_rerunning_with_the_same_candidate_does_not_double_send与test_send_claim_blocks_a_second_send_after_a_crashed_first_attempt。12.4 发送前最后一刻重读退订状态生命周期邮件的三项义务见lifecycle.py模块 docstring抑制状态每次发送前即时重读、绝不跨批次缓存09:00 退订的用户不得收到 08:59 被选中的邮件每封邮件携带可用退订一键链接 List-Unsubscribe/List-Unsubscribe-Post头让 Gmail 与 Apple Mail 渲染原生退订控件发送先记录再尝试。测试test_opt_out_between_selection_and_send_suppresses_the_email验证了候选快照与实时文档不一致时以实时为准。12.5 汇总日志与无内容回执RunSummary被刻意设计为内容无关回执只计数considered / enrolled_treatment / enrolled_control / sent / failed / ineligible从不记录 uid 或邮箱地址每轮结束时以单行日志输出完整漏斗这正是文档承诺的作业记录完整资格漏斗、第一周真实数字取代估算。十三、测试体系把契约变成可执行断言backend/tests/unit/test_day3_reengagement.py 覆盖了本文涉及的几乎每条决策且刻意无网络、无真实 Firestore——用FakeFirestore替代数据库、用 patch 掉的httpx.post替代邮件提供方因为批量邮件器最有趣的失败全部是决策失败重复发送、发给退订者、发错队列而这些只有在决策不依赖 Firestore 时才便宜可测。关键用例包括资格分区与优先级test_each_rejection_reason_fires_on_its_own、test_rejection_reasons_partition_by_fixed_precedence窗口边界test_72h_96h_window_boundariesmacOS 拼写与desktop排除test_every_macos_signup_os_spelling_is_eligible、test_bare_desktop_signup_os_is_not_assumed_to_be_macos值信号语义test_in_progress_stubs_and_discards_do_not_count_as_coming_back、test_every_ended_status_counts_as_real_output、test_the_only_status_that_does_not_count_is_the_listen_stub文案与转义test_copy_escapes_a_hostile_display_name、test_copy_has_no_parameter_that_could_carry_conversation_content编排test_closed_authority_performs_no_user_work、test_failed_enrollment_prevents_a_send、test_control_arm_candidate_is_enrolled_and_never_sent、test_eligible_treatment_candidate_is_sent_with_working_unsubscribe幂等与重试test_rerunning_with_the_same_candidate_does_not_double_send、test_a_failure_before_the_provider_releases_the_claim、test_an_unknown_delivery_outcome_keeps_the_claim、test_a_treatment_user_whose_send_failed_is_retried_on_the_next_run。另有 test_day3_reengagement_email_job.py 覆盖作业入口层的权威解析行为。十四、总结这套实验设计对同类系统的复用价值EXP-001 的价值不在一封邮件而在于它示范了一套可搬运的决策框架预注册契约先行实验 id 作盐、契约路径进常量、入组后改指标必须换 id随机化是唯一解当资格与潜在参与度相关时观察性对比产出显著且无意义的数字对照组在构造上不消失两臂同路径入组、入组先于投递、ITT 分析值信号优于活动信号用结束的真实会话而非活跃时间戳/启动事件判定回归既避免开机自启污染也不误伤 deferred 用户功效诚实不为不现实的效应量配不现实的时间线把主指标放在因果路径上、让长周期问题用常驻分桶慢慢累积批量邮件的工程护栏fail-closed 权威开关、三层防重、异常三分法、发送前即时重读抑制、GET/POST 动词拆分对抗链接扫描器。这套预注册 随机对照 ITT 护栏指标的组合可以直接迁移到任何需要评估无提示干预邮件、推送、通知效果的系统中。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Omi EXP-001 Day-3 重新参与邮件实验全解析：从预注册契约到随机对照实现
Omi EXP-001 Day-3 重新参与邮件实验全解析从预注册契约到随机对照实现【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend本文基于 Omi 开源仓库中的实验契约文档 EXP-001-day3-reengagement.md 展开。该文档定义了一项针对 macOS 新用户流失召回的随机对照实验用户在注册并产生内容后停止使用第 3 天收到一封展示 Omi 捕获结果的邮件观察其是否回归。文章不仅完整还原文档中的资格谓词、分配机制、指标与功效设计还结合仓库源码utils/experiments.py、utils/email/day3_reengagement.py、utils/email/lifecycle.py 等与单元测试讲清为什么必须随机化、如何保证对照组永不消失、如何用值信号而非活动信号判定回归这些核心工程决策。读完本文你将掌握一套可复用的预注册 随机对照 意图治疗分析实验设计范式以及它在一套真实批量邮件系统中的落地细节。一、实验概览一份先承诺、后执行的分析契约EXP-001 的状态标记为pre-registered预注册尚未启动not yet started注册日期为 2026-08-30归属growth / churn增长 / 流失工作流。文档开篇即点明其核心定位This file is the analysis contract.本文件即分析契约。所谓预注册有一个非常具体且可验证的标准它必须在第一批用户入组之前提交到仓库且作业入口 backend/modal/day3_reengagement_email_job.py 的常量PRE_REGISTRATION直接指向该文档路径见 backend/utils/email/day3_reengagement.py 第 59 行。代码与文档形成双向锁定的契约EXPERIMENT_ID EXP-001-day3-reengagement CAMPAIGN day3_reengagement PRE_REGISTRATION backend/docs/experiments/EXP-001-day3-reengagement.md这份契约还施加了一条硬性纪律一旦入组开始主指标或资格谓词的任何变更都必须启用新的实验 id。原因在于实验的分配盐salt就是实验 id 本身——详见下一节分配机制——修改契约而沿用 id 意味着无法在事后重建名册roster历史分配将不可解释。为什么要承诺在先实验中最大的统计风险不是做错了分析而是做了很多次分析直到出现显著结果。预注册把主指标、资格条件、分析方法、读数时间点全部冻结在入组之前杜绝了结果驱动的选择偏差researcher degrees of freedom。这套思想贯穿本文后面每一节资格谓词有固定优先级、中间读数只报置信区间、对照组永远不会被条件化剔除。二、研究假设一封展示Omi 捕获了什么的邮件能否召回流失用户文档给出的假设Hypothesis原文为A macOS user who signed up, produced something on day 0, then stopped, will return more often if they receive one email on day 3 showing them what Omi captured, than if they receive nothing.即一位在 macOS 上注册、第 0 天产生了内容、随后停止使用的用户如果在第 3 天收到一封展示 Omi 捕获成果的邮件比什么都收不到时更有可能回归。注意假设的措辞刻意限定了人群特征——第 0 天产生过内容这与后面的资格谓词、邮件文案分支个性化 vs 通用严格对应。三、为什么必须随机化观察性数据的显著且无意义实验文档用一整节回答了为什么不直接上线然后看留存这背后是 2026-08-26 的一次同队列cohort研究教训该研究发现四个行为杠杆如录音使用、通知接收、聊天使用其粗留存风险比高达 1.9–2.2但经 Mantel–Haenszel 方法按第 1 周活跃天数调整后每一个都塌缩到约 1.05–1.11。这说明这些杠杆只是潜在参与度latent engagement的标记物而非成因。在 Omi几乎所有做了 X 的用户 vs 没做 X 的用户的观察性对比都被这一个潜在参与度变量主导而任何干预的资格都与参与度相关。因此不做随机化的上线会得到一个真实、统计显著、却完全无意义的数字。这一教训被完整复刻在 backend/utils/experiments.py 的模块 docstring 中作为该模块存在的根本理由。四、实验单元、分配机制与 50/50 分桶4.1 单元与分配单位单元Unit已认证的 Firebaseuid。分配单位 分析单位即同一用户不会被拆成多个观测。分配Assignment调用 backend/utils/experiments.py 的enroll对sha256(EXP-001-day3-reengagement:uid)做确定性哈希并把结果持久化到 Firestore 集合experiments/EXP-001-day3-reengagement/assignments/{uid}。4.2 确定性哈希如何工作utils/experiments.py的核心实现第 86–103 行_BUCKET_RESOLUTION 10_000 # 分桶分辨率万分位 def bucket_of(experiment_id: str, uid: str) - int: digest hashlib.sha256(f{experiment_id}:{uid}.encode(utf-8)).digest() return int.from_bytes(digest[:4], big) % _BUCKET_RESOLUTION def assigned_variant(experiment_id: str, uid: str, *, treatment_share: float 0.5) - str: if not 0.0 treatment_share 1.0: raise ValueError(treatment_share must be within [0, 1]) return TREATMENT if bucket_of(experiment_id, uid) round(treatment_share * _BUCKET_RESOLUTION) else CONTROL关键设计点实验 id 即盐哈希输入是实验id:uid。好处是新实验天然重新随机化某个用户在一个实验里运气差不会在下一个实验里系统性倒霉坏处是一条铁律——绝不能重命名正在运行的实验否则全体人群会被悄悄重新打散。万分位分辨率_BUCKET_RESOLUTION 10_000使分桶可精确到万分之一basis point比当前流量下任何可检测的效果粒度都细且桶算术保持为整数运算。持久化而非重算纯哈希看似优雅但存在两个致命问题任何人改盐都会导致全体静默重随机化更关键的是对时间窗实验注册后 72–96 小时、且未回归而言资格是一个时刻的属性——窗口前不成立、窗口后也不成立事后没有任何状态可以反推名册。因此每个入组用户落地为一个 Firestore 文档同时让批处理作业的重试天然幂等。4.3 两臂同路径入组对照组在构造上不会消失enroll第 124–187 行对两臂走完全相同的代码路径、在同一时刻写入并在治疗投递之前向 PostHog 发出Experiment Enrolled事件两臂都发。这对邮件实验不是锦上添花而是生死攸关对照组用户可能再也不打开应用任何客户端侧机制都无法观测到他们。只有入组先于投递、两臂同路径对照组才在构造上留在分母里。enroll还做了两件防御性的事幂等已入组用户返回原变体且newly_enrolled False调用方据此避免重投治疗写失败 硬失败分配无法持久化时返回None调用方不得投递治疗——一次未投递的治疗只是丢失一个数据点而一次已投递却未记录的治疗会静默污染对照组直到实验结束。五、资格谓词五条规则与值信号的哲学文档定义资格须同时满足全部 5 条All ofmacOS 注册signup_os∈ {macos,mac,mac os x}。注意这不是signup_platform——后者只有与 Windows 共享的粗粒度desktop桶且signup_os是客户端原始 header 小写化而非规范值所以要用集合匹配。裸desktop被排除因为 Windows 客户端也会写入该值。注册时间窗signup_platform_at距离运行时刻 72–96 小时每天恰好一个 24 小时注册队列。第 0 天窗口之后零条真实会话第 0 天 自signup_platform_at起 24 小时。真实discarded False且状态非in_progress。Firebase Auth 记录上有可投递的邮箱。未退订生命周期邮件且此前未收到过 EXP-001 邮件。5.1 为什么不用last_active_at也不用App Launched两者都被开机自启launch-at-login污染record_user_platform会在每次认证请求上盖last_active_at时间戳所以自动启动的桌面应用会让该字段一直温热而用户其实什么都没得到App Launched有同样的缺陷——这正是流失研究报告严格 14.1% 留存与27.4% 头条留存并存的根源。如果以两者之一判定是否回来就会系统性排除本邮件要触达的未参与但机器仍在跑的用户。因此规则 3 改用值信号value signal。5.2 为什么裸会话数也是同一个错误会话文档不是用户输出桌面监听 socket 在每次会话开始和每次重连时都会写入一条in_progress会话所以一台仅仅开着的 Mac 就会制造出带新鲜created_at、却毫无内容的文档空会话结束时被标记discarded。统计它们会让是否回来对每一台通电的安装都为真——这是换了一顶帽子的 launch-at-login 污染最终会把合格集剥离到只剩机器关机的用户与目标人群恰好相反。5.3 为什么status completed是相反方向、且更糟的错误直觉上收紧到 completed更安全但对本队列反而更危险_store_deferred_conversation会把 freemium/Neo 用户的桌面录音以deferred True、status processing持久化直到用户打开它。这些是真实的已录制会话永远不是completed而它们恰好属于本实验瞄准的新 macOS 用户人群。要求completed会把这些人报告成什么都没产出、再也没回来。所以规则 3 统计的是discarded False且状态除in_progress外任意的文档——一段已经结束的会话无论后续增强处理做了什么。它刻意不是get_conversations的默认行为后者只过滤discarded会把 stub 留在结果里。5.4 源码中的落地显式 allow-list 而非! in_progressbackend/utils/email/day3_reengagement.py 第 82–95 行把该谓词实现为显式允许列表MACOS_SIGNUP_OS_VALUES frozenset({macos, mac, mac os x}) ENDED_CONVERSATION_STATUSES tuple( status.value for status in ConversationStatus if status is not ConversationStatus.in_progress )两个实现细节值得注意signup_os不经过_normalize_platform的别名表database/users.py只规范化粗粒度桶原始 header 值会原样到达因此匹配一个字面量会静默丢掉真实 macOS 用户——测试 test_day3_reengagement.py 中test_every_macos_signup_os_spelling_is_eligible专门钉死了macos / mac / mac os x / MacOS / Mac OS X全部拼写都必须合格。状态用 allow-list 而非! in_progress除了语义清晰还有一个 Firestore 层面的原因in过滤器可以与等值、范围共用同一个复合索引被服务而!不能。从ConversationStatus枚举派生则意味着新增状态会在此处成为一个显式可见的决策而非被静默排除。5.5 决策函数的固定优先级漏斗是分区而非重叠计数evaluate_candidate第 139–170 行按固定优先级逐条判定每个候选者精确归属到它失败的第一条规则not_macos → no_signup_timestamp → too_early → too_late → returned → already_sent → opted_out → no_email这使得漏斗计数RunSummary.ineligible字典是一个无重叠的分区。测试test_rejection_reasons_partition_by_fixed_precedence验证了多因同时命中时只记首个原因。候选收集端collect_day3_candidates以limit(500)MAX_USERS_PER_RUN分页且第 0 天后是否回归用limit(1)布尔化——只取一条即可判定第 0 天产出数封顶 11因为文案只会报告较小的 N。5.6 Firestore 查询的两个字段陷阱record_user_platform写入两个粒度不同的平台字段signup_platform是粗桶macOS 和 Windows 都写desktopsignup_os是细粒度 OS 串。于是显而易见的查询signup_platform macos永远匹配零个文档且静默失败——实验会一个都不入组而没有任何报错。源码因此用实际写入的值desktop做索引等值查询把 macOS 收窄留给evaluate_candidate对signup_os的判定Windows 注册者会被取出再以not_macos拒绝每轮略有浪费但受同一分页上限约束。三个查询均以注册规范登记在 backend/database/firestore_index_registry.pyDAY3_REENGAGEMENT_SIGNUP_COHORT_QUERY、DAY3_REENGAGEMENT_DAY_ZERO_CONVERSATIONS_QUERY、DAY3_REENGAGEMENT_RETURNED_CONVERSATIONS_QUERY并用 AST 级覆盖率检查器确保实际查询与声明的索引规格一一对应。5.7 边界测试与固定优先级的边界测试test_72h_96h_window_boundaries精确钉死窗口边界语义age 72h→too_early72h age 96h→ 合格age 96h→too_late恰 96.0 小时即算过期。测试test_in_progress_stubs_and_discards_do_not_count_as_coming_back验证了整支目标队列都依赖的判定in_progressstub 与discarded空会话都不能算回归test_every_ended_status_counts_as_real_output则参数化验证processing / merging / completed / failed四种结束态都算真实产出。文档将此定位为覆盖性选择coverage choice而非效度威胁——它只改变谁合格且对两臂完全相同。六、治疗方案一封邮件、两个文案分支、同一治疗臂治疗 第 3 天发送一封邮件文案按第 0 天是否产出内容分支第 0 天产出邮件主题源码实测内容有产出Omi captured something on your first day个性化展示 Omi 在第 0 天捕获的会话数并说明 Omi 的价值往往在连续运行数天后显现无产出Getting the most out of Omi通用首值提示保持后台运行一整个工作日、开启通知以便 Omi 告知发现实现函数build_reengagement_email第 173–213 行有两个值得单独说明的安全决策所有用户输入被转义_escape对display_name做 HTML 实体转义测试test_copy_escapes_a_hostile_display_name用scriptalert(1)/script验证不插值任何会话内容文案只用会话数这个数字绝不把转写派生的标题放进邮件——把转录内容送进邮件是一个尚未被任何人做出的隐私决定。测试test_copy_has_no_parameter_that_could_carry_conversation_content通过检查函数签名直接钉死这一边界。两个分支属于同一个治疗臂随机化会平衡两分支在臂间的分布因此合并估计是对异质人群的平均治疗效果ATE的有效估计。第 0 天产出分层只作为探索性exploratory切分报告绝不提升为结论——这是把 Mantel–Haenszel 教训向前应用。对照组不收到任何东西、也绝不被联系。七、指标设计主指标、次要指标、护栏与意图治疗7.1 指标分层主指标Primary入组后第 3–9 天≥1 个活跃日。合格人群的实测基线12.1%43/355PostHog 项目 302298查询于 2026-08-30。次要指标Secondary监测而非确证第 30–44 天留存采用规范队列契约的两个定义任意显式事件 / 严格非启动。实测第 14–23 天代理基线约13.2%。护栏Guardrails因伤害而停止生命周期邮件退订率、垃圾投诉率、硬退信率。纯描述性Descriptive only已发送、已送达、退信、已打开。7.2 为什么打开率永远不能进入比较分析是意图治疗intention-to-treat比较绝不以打开为条件。打开者是参与度高的用户以打开过滤会重新引入随机化本想消灭的混淆因子何况 Apple Mail 隐私保护已让打开率在很大程度上成为虚构数字。7.3 退订端点的 GET/POST 动词拆分一个被链接扫描器逼出来的设计文档指出退订率只有在退订端点拆分动词时才可读GET /email/unsubscribe只渲染确认表单、不写入任何状态POST才执行退订。原因企业链接扫描器Outlook Safe Links 等网关会在收件人看到邮件之前抓取正文中的每个 URL——如果写操作挂在GET上扫描器就会制造出无人想要的退订抑制真实收件人并把护栏指标从伤害抬高成扫描流量邮件客户端发起 RFC 8058 一键退订List-Unsubscribe-Post本身就是POST因此该路径保持真正的一键。该端点实现在 backend/routers/email_preferences.pyGET渲染带确认按钮的 HTML 表单按钮把 token POST 回同一路径POST校验签名 token 后写入email_preferences.lifecycle_opted_out。退订 token 由 backend/utils/email/lifecycle.py 的mint_unsubscribe_token用 HMAC-SHA256 签署uid:purpose而成刻意永不过期——过期的退订链接是暗黑模式和可访问性失败邮件在归档里存放数年点击两年前链接的人恰恰是最有资格被移除的人。八、统计功效诚实的边界流量基线约160 个 macOS 注册/周Onboarding Completed去重最近 8 个完整周171, 136, 163, 191, 150, 151, 158, 172。经过资格、邮箱可用性与抑制后规划约100 个入组/周。基于会话的规则 3 尚未被直接测量因此作业会记录完整资格漏斗第一周的真实数字将取代此估算。功效公式双比例、双侧 α0.05、power 0.80、50/50n/arm 7.85 × [p₀(1−p₀) p₁(1−p₁)] / Δ²指标基线效果n/臂总计按100/周入组成熟期结论重新激活12.1%12pp2×157314~3周9天~1个月——可行重新激活6pp5541,108~11周9天~3个月——可接受上限重新激活4pp1,1812,362~24周9天不可行D30–44 留存~13%8pp345691~7周44天时间线可行但一封邮件 8pp 不现实D30–44 留存5pp8271,654~17周44天~6个月D30–44 留存3pp2,1834,366~44周44天不可行文档给出的结论非常直白This experiment cannot be powered for day-30–44 retention at any plausible single-email effect size (1–3pp) in a reasonable timeframe.这正是主指标选择重新激活的原因它位于通往留存的因果路径上、9 天即可成熟、且真实可检测。如果一封邮件连重新激活都推动不了它更不可能推动留存而且能廉价地被淘汰。常驻 50/50 分桶让留存问题可以在约 4–6 个月后用累积名册作答而无需把发布押在它上面。九、读数时间表与停止规则中期读数Interim达到 314 入组目标的 50% 时只报置信区间。仅因护栏伤害而停止。不是成功读数。确证读数Confirmatory314 个入组时只统计 9 天窗口已完全过去的用户assigned_at now() - INTERVAL 9 DAY。留存读数Retention不早于 6 个月且已成熟assigned_at now() - INTERVAL 44 DAY。没有看仪表盘就拍板的决策通道。这很容易遵守主指标在每次发送后第 9 天才存在。十、分析方案无协变量调整分析的分母是experiment_id EXP-001-day3-reengagement的Experiment Enrolled事件左连接后续活动。报告两比例检验的绝对百分点差与 95% 置信区间。无协变量调整——随机化已经做了那份工作确证读数中不做亚组分析。十一、Kill Switch 与部署架构11.1 默认关闭、fail-closed 的权威开关文档规定DAY3_REENGAGEMENT_EMAIL_ENABLED必须显式为 true作业才做任何用户工作缺失、畸形或不可读的值一律fail closed——新部署的作业默认黑暗dark。源码把这一纪律实现为双层开关backend/utils/email/day3_reengagement.py 第 98–115 行ENABLED_ENV DAY3_REENGAGEMENT_EMAIL_ENABLED KILL_SWITCH_ENV DAY3_REENGAGEMENT_EMAIL_KILL_SWITCH class Day3Authority: enabled: bool False kill_switch_active: bool False property def may_send(self) - bool: return self.enabled and not self.kill_switch_active作业入口 day3_reengagement_email_job.py 在触碰任何用户数据之前先解析权威authority_from_environment并用getattr(authority, may_send, False) is True做防御——权威提供者不可用时同样失败关闭而不是让新部署的作业顺带执行用户工作。未打开时作业在候选选择之前就退出。11.2 部署形态Cloud Run Job 每日 Scheduler镜像Dockerfile.day3_reengagement_email_job 基于 Python 3.11 slim 镜像先安装依赖、再把backend/整体拷入入口为python day3_reengagement_email_job.py。定时scripts/provision_day3_reengagement_scheduler.py 以gcloud scheduler创建/更新名为day3-reengagement-email-daily的 HTTP 触发器指向 Cloud Run Jobday3-reengagement-email-job计划为0 15 * * *UTC 每天 15:00。注释解释了每日节奏的选择资格窗口每个运行正好覆盖一个 24 小时注册队列低于每日的节奏只会重查同一个基本为空的窗口高于每日则会漏掉整个队列。脚本通过describe → update/create → resume保证描述失败可回退到 create而认证/权限失败必然让部署失败。十二、工程纵深批量邮件的可靠性细节12.1 三层防重入组幂等、发送账本、提供方幂等键批量邮件最可怕的失败是重复发送backend/utils/email/lifecycle.py 为此堆了三道闸入组幂等enroll对已入组用户返回原变体不重复计数发送账本claim ledgerclaim_lifecycle_send以create()原子占位users/{uid}/lifecycle_email_sends/{campaign}——文档已存在则创建失败天然防并发。release_lifecycle_send只在确定未发出时释放提供方幂等键send_lifecycle_email以sha256(flifecycle:{campaign}:{uid})作为 Resend 的Idempotency-Key即使重试快过 Firestore 账本也有第二道锁。12.2 异常三分法未知投递结果必须保留 claimlifecycle.py定义了三种异常run_day3_reengagement对它们的处置截然不同异常语义claim 处置LifecycleEmailSuppressed选中与发送之间用户退订释放 claim记录suppressed用户保持入组ITTLifecycleEmailNotConfigured凭证或签名密钥缺失释放 claim中止整轮LifecycleEmailDeliveryUnknown请求到达提供方、响应未读到claim 必须保留——重复比漏发更糟其他异常发生在触达提供方之前Firebase Auth 读取、模板构建等释放 claim让 Cloud Run 重试可恢复测试 test_day3_reengagement.py 中的test_a_treatment_user_whose_send_failed_is_retried_on_the_next_run提供方不可达→释放→重试成功与test_an_unknown_delivery_outcome_keeps_the_claim读超时→保留→不再重发把这条不对称规则钉成契约。12.3 入组是分析锁claim 是发送锁两者不可混同一个看似幂等的优化——已入组就直接跳过——实际上是永久性发送失败治疗用户第一次尝试在入组与投递之间死亡后后续每一轮都会跳过它永远不发信却仍被计为治疗组静默稀释实验想测的效果。因此run_day3_reengagement对newly_enrolled False的处理是继续走 claim 流程由 claim 账本决定是否真的发见test_rerunning_with_the_same_candidate_does_not_double_send与test_send_claim_blocks_a_second_send_after_a_crashed_first_attempt。12.4 发送前最后一刻重读退订状态生命周期邮件的三项义务见lifecycle.py模块 docstring抑制状态每次发送前即时重读、绝不跨批次缓存09:00 退订的用户不得收到 08:59 被选中的邮件每封邮件携带可用退订一键链接 List-Unsubscribe/List-Unsubscribe-Post头让 Gmail 与 Apple Mail 渲染原生退订控件发送先记录再尝试。测试test_opt_out_between_selection_and_send_suppresses_the_email验证了候选快照与实时文档不一致时以实时为准。12.5 汇总日志与无内容回执RunSummary被刻意设计为内容无关回执只计数considered / enrolled_treatment / enrolled_control / sent / failed / ineligible从不记录 uid 或邮箱地址每轮结束时以单行日志输出完整漏斗这正是文档承诺的作业记录完整资格漏斗、第一周真实数字取代估算。十三、测试体系把契约变成可执行断言backend/tests/unit/test_day3_reengagement.py 覆盖了本文涉及的几乎每条决策且刻意无网络、无真实 Firestore——用FakeFirestore替代数据库、用 patch 掉的httpx.post替代邮件提供方因为批量邮件器最有趣的失败全部是决策失败重复发送、发给退订者、发错队列而这些只有在决策不依赖 Firestore 时才便宜可测。关键用例包括资格分区与优先级test_each_rejection_reason_fires_on_its_own、test_rejection_reasons_partition_by_fixed_precedence窗口边界test_72h_96h_window_boundariesmacOS 拼写与desktop排除test_every_macos_signup_os_spelling_is_eligible、test_bare_desktop_signup_os_is_not_assumed_to_be_macos值信号语义test_in_progress_stubs_and_discards_do_not_count_as_coming_back、test_every_ended_status_counts_as_real_output、test_the_only_status_that_does_not_count_is_the_listen_stub文案与转义test_copy_escapes_a_hostile_display_name、test_copy_has_no_parameter_that_could_carry_conversation_content编排test_closed_authority_performs_no_user_work、test_failed_enrollment_prevents_a_send、test_control_arm_candidate_is_enrolled_and_never_sent、test_eligible_treatment_candidate_is_sent_with_working_unsubscribe幂等与重试test_rerunning_with_the_same_candidate_does_not_double_send、test_a_failure_before_the_provider_releases_the_claim、test_an_unknown_delivery_outcome_keeps_the_claim、test_a_treatment_user_whose_send_failed_is_retried_on_the_next_run。另有 test_day3_reengagement_email_job.py 覆盖作业入口层的权威解析行为。十四、总结这套实验设计对同类系统的复用价值EXP-001 的价值不在一封邮件而在于它示范了一套可搬运的决策框架预注册契约先行实验 id 作盐、契约路径进常量、入组后改指标必须换 id随机化是唯一解当资格与潜在参与度相关时观察性对比产出显著且无意义的数字对照组在构造上不消失两臂同路径入组、入组先于投递、ITT 分析值信号优于活动信号用结束的真实会话而非活跃时间戳/启动事件判定回归既避免开机自启污染也不误伤 deferred 用户功效诚实不为不现实的效应量配不现实的时间线把主指标放在因果路径上、让长周期问题用常驻分桶慢慢累积批量邮件的工程护栏fail-closed 权威开关、三层防重、异常三分法、发送前即时重读抑制、GET/POST 动词拆分对抗链接扫描器。这套预注册 随机对照 ITT 护栏指标的组合可以直接迁移到任何需要评估无提示干预邮件、推送、通知效果的系统中。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考