今日日报 ／ 欧登 · 2026-07-24 周五
今日主要工作
支付宝 · 赶车闹钟 × 收藏整合方案成稿
  • 新建 `docs/P02-功能文档/赶车闹钟与收藏整合/` 系列四份文档（产品 221 行、埋点 127 行、验收 83 行、数据分析 88 行）。当前状态：方案仍在确认中，未发出评审。
  • 数据支撑先立住：近 30 天 8,394 条闹钟记录中，93.9% 的用户一条线只订 1 个候车站、96.7% 只订 1 个方向 —— 闹钟的自然最小单元与收藏项的数据结构一致，这是两个功能能整合的前提。
  • 核心决策（产品侧我方拟定，待确认）：设置界面沿用现有全屏设置页、不做半屏（只维护一套 UI，且 push 落地页依赖该页无法删除）；闹钟绑定在收藏项上、继承收藏的候车站，改候车站 = 新建闹钟 + 新增收藏；存量无对应收藏的历史闹钟，由服务端在用户首次进入收藏页时补全一条收藏。
  • 本期砍掉收藏页引导气泡：核对代码发现线路详情页已有同规则气泡（`alarm_tip_record`，最多 3 次、间隔 ≥7 天），收藏页再做一套是重复建设。本期只把入口摆上去，不新增任何气泡与计数存储，老气泡原样不动。
  • 取消收藏联动定为二次确认：该收藏项有闹钟时弹框点名具体候车站与时间，且只删这一条收藏对应的那个闹钟，同线其它方向的闹钟必须保留。
  • 指标按需求目的倒推分三层：核心（闹钟开启成功周均较上线前 4 周 +30%、收藏页入口贡献 ≥30%）、过程（收藏页链路开启成功率 ≥50%）、护栏（线路详情入口成功率不低于基线、存量迁移 100%）。
支付宝 · 「去设置 PUSH 召回」埋点方案与文案定稿
  • 产出埋点方案文档（152 行）。前端 2 个埋点（落地页曝光、保存成功，均以 `src=push_goset` 判定），分别是既有 ①/⑥ 埋点的子集，可互相校验；后端 3 个事件（召回命中、被闸门/频控拦下未发、发送结果）—— 这三件事发生时用户不在小程序里，前端埋不了，是限制不是选择。
  • 闹钟取消 / 删除不做前端埋点，改由后端保存时记 `source=push_goset`、事后查表：跨设备、任意路径关掉都算得上，也省一次埋点申请与录入。
  • 文案定稿：确认平台模板的开头「您关注的线路」与结尾「点击查看详情」由平台写死、不可自定义，收藏 / 查看两类人群在文案上无法区分，改为只保留为数据维度 `recall_tier`。keyword1 按有无实时车况分两档，总长对齐既有实发 push 的 52 字；更完整的一版 CTA 因超长 6 字、且与兜底档语义重复，作为「备选（暂不采用）」连同启用条件写入文档。
  • keyword2（候车站）来源定优先级：收藏候车站 > 用户坐过的站；两者都没有的这批人本轮不发，不借用服务端的「就近补站」—— push 发送时拿不到用户实时位置，猜错反伤信任。
抖音 · 相关功能上线与三端 stage 预览码支持
  • 赵苓邮件通知抖音小程序相关功能（涉及 openali、app-bus 两个系统）已上线、报钱金蕾审批，我方被抄送。当前状态：待跟进上线后验证。
  • 按测试需要向赵苓提供抖音、微信、支付宝三端 stage 环境预览码。支付宝侧出自 `feat/push_strategy` 分支；微信侧因开发者工具 Nightly 版命令行出码有 bug，改走工具界面「预览」按钮出码，流程已跑通并记入备忘，本地仓库环境已还原为 release、工作区干净。
  • 赵苓反馈扫码无权限：微信预览版只有项目成员可打开，需在微信公众平台「成员管理 → 项目成员」加开发者权限并由本人确认邀请。我方承接微信侧权限添加，抖音侧权限一并跟进。
协作 · 会议
  • 参加产品设计周会（陈阳发起，10:30–12:07，10 人）、周沟通会议（李东煜发起，14:00–14:30）。
业务功能进展
支付宝 · 赶车闹钟三期（订阅转化埋点）
  • 6 个埋点的上报代码与取消订阅归类修复已在 `release/0.3.1`，代码侧完成。上线预期：随 0.3.1 发版，发版时间待排期。
支付宝 · 赶车闹钟四期（收藏整合）
  • 迭代表已挂接四期，状态记为「方案设计中，后端接口待确认」；系列四份文档新建完成，尚未纳入版本管理。
  • 上线预期：待排期。前置是后端删除粒度与批量闹钟查询两项确认，未确认前不进开发。
支付宝 · 去设置 PUSH 召回
  • 产品文档按新口径整体重写（+364 / −330 行），埋点方案与验收用例同步；本轮改动仍在工作区未提交。
  • 两处形态变更：问题定义由「九成用户未设置」改为「已开启消息通知、但当前无有效闹钟的约 1.79w 人」；落地页由落线路详情页改为直落闹钟设置页锁定模式（线路 + 站点预填，需前端新增带参直落能力）。
  • 上线预期：待排期，取决于后端实测真实可发人数 N；前端可先行的 `src` 透传与带参直落不受此阻塞。
抖音 · 相关功能上线
  • openali、app-bus 两个系统的抖音相关功能已上线（赵苓邮件通知、报钱金蕾审批），我方为抄送方。上线预期：已上线，下一步是上线后验证，目前验证卡在测试权限（见待进行）。
其他
  • 本人今日无代码提交，产出集中在文档。支付宝 `feat/push_strategy` 分支今日另有同事提交的 JL 插屏广告修复，非本人改动。
问题与处理
  • 目标人群 1.79w 存疑，直接决定这个策略值不值得做：支付宝口径「订阅赶车闹钟模板 2.77w」与我方「累计设置过闹钟 1.1w」差 1.67w；而纯用我方数据能圈出的「设过、现在没有」只有约 1,000 人，两个量级差 18 倍。处理：把可达性问题整理成三点向支付宝对接方确认——openId 与闹钟状态我方自有，真正缺的只是「这个 openId 现在还能不能收到消息」的批量查询能力；同时按我方可查口径准备第一轮，保证不被这个缺口卡死。
  • 取消收藏的删除粒度是硬卡点：若后端 `del.action` 只按线号删除、无法精确到「线 · 方向 · 站」，取消一行收藏会连带删掉同线其它方向的收藏与闹钟，整合方案的联动规则无法正确实现。处理：该卡点确认前不进开发，待与后端确认删除接口能否按「线 · 方向 · 站」精确删除。
  • push 文案无法按人群区分开头，收藏 / 查看两档的差异化触达失效。处理：降级为数据维度，灰度后用 `recall_tier` 回看两类人群的转化差异，再决定是否值得另申请模板。
待进行
感悟 · 工作方法
  • 向外部要东西之前，先把需要的信息按归属拆一遍。push 圈人本来准备向支付宝要 userId，拆开看：用户是谁（openId）我方自有、有没有设过闹钟我方自有，真正缺的只有「这个 openId 现在还能不能收到消息」一条。一个大而含糊的请求拆完只剩一个小问题，对方好答、我方也不用等一整包数据。
  • 教育用户的动作可以往后放，先把入口摆上去看有没有人用。气泡、介绍框这类都是在赌「用户不知道」，但如果入口本身没人点，加多少引导都没用；先上入口拿到真实点击率，再决定要不要教育，顺序反了就是拿功能量级的成本去验证一个假设。
感悟 · 个人成长
  • 通过和邵博沟通深刻体悟用户调研的重要性，要以用户为中心，做贴近用户的产品，去实地感受。以及更加坚定秉持定好目标，尊重共识的理念。
  • 和东煜哥沟通，对下次沟通需要聊聊好产品的理解，自己有什么优缺点，我也很期待，喜欢自己做这样的复盘。
往期日报
2026-07-22 周三
今日主要工作
支付宝 · 赶车闹钟订阅埋点方案定稿
  • 方案两度重构后定版：由昨日「1 埋点 + field1 区分」→「两事件五埋点」→ 终稿 6 个实采埋点（页面曝光、已授权订阅成功、新授权订阅成功、弹窗放弃、拒绝不再询问、订阅成功总量），按用户类型分组成一张表，含平台录入卡片与开发要点。
  • 三条边界由真机实测确定：`show` 字段实测存在，可据以区分新 / 老授权用户；一级弹窗「取消」与二级弹窗「暂不订阅」回执完全一致（fail、`behavior:cancel`、`errorCode:11`），确认不可拆分，合并为「放弃」；打开页面时无接口可查授权状态，故曝光不分新老。
  • 决策：埋点范围由产品侧（我方）拍板，以平台实采能力实测结果为准——期望采集但支付宝回执给不出的点位（两级弹窗各自的同意 / 取消）不录入平台；push 归因与取消闹钟埋点本期不做，随 push 下一版提。
  • 当前状态：文档已入库 `docs/P02-功能文档/赶车闹钟/赶车闹钟-埋点.md`；6 张埋点卡片已在运营平台「埋点管理 → 新增」录入并提交审核，待审核通过后取 action_id 进入开发。
支付宝 · 首页白屏问题闭环（含回归修复）
  • 昨日修复后回归出新表现：新用户同意隐私协议后首页停在加载动画，需手动下拉才出内容。真因是首次修复只搬了 `loadStates` 初始化，遗漏同样位于提前 `return` 之后的 `ctx.firstEnter`，导致 `loadData` 将刷新类型判成 BACK，而该分支既不写 stations 也不写 load_state。
  • 补搬 `firstEnter` 仍无效（`onShow` 会在用户点「同意」之前将其置 false），故改为不依赖标志位推断：`loadData` 增加可选参数 `overrideRefreshType`，`onAgree` 显式传入 INIT，其余调用方行为不变。顺带修复新用户 `my.setTabBarItem` 从未执行、底部 tabbar 图标与文案未设置的问题。
  • 复盘文档与验收用例已归入 `docs/P11-issues/` 并补入 README 索引。
支付宝 · 「去设置 PUSH 召回」指标体系重写
  • 依据运营提供的 7.22 快照建立基本盘：订阅 2.79w、订阅赶车闹钟模板 2.77w、累计设置闹钟 1.1w、现存生效 1.0w、日均发送 UV 6k、DAU 22.1w，模板订阅渗透率 12.5%。
  • 指标表按「主指标 / 过程 / 背景 / 护栏」四层重写，主指标只留一个——召回净新增设置人数（2 个月 200–300 人）。点击率 ≥4%、落地转化率 ~15% 均注明是历史值打折的上线前预估、非承诺，灰度第一轮实测后回填。护栏改为灰度期看绝对数（单轮退订 ≥5 人或投诉 ≥1 例即人工复盘），量级过千后再切比率。
业务功能进展
  • 首页白屏 / 加载态问题已修复完毕，提交并推送 release/0.3.1（`pages/main/controller.js`），随 0.3.1 发版；单测与构建通过，复盘 + 验收文档同批入库。
  • 赶车闹钟埋点文档当日四次提交迭代至终稿（6 个埋点 + 录入卡片 + 开发要点 + 8 步后续清单）；终稿提交尚未推送远端。
  • 埋点开发前置缺陷已记入方案：现有 `subscribe.js` 把 `errorCode 2001` 当用户放弃，真机实测实为 `11`，当前后果是用户点「取消 / 暂不订阅」被归为 error 并误提示「授权失败，请重试」；不修则「放弃」埋点无法上报，需随埋点开发一并修。
  • 「去设置 PUSH 召回」产品文档与验收用例的本轮改动仍在工作区，未提交。
问题与处理
  • 埋点粒度受平台能力限制：想单独统计两级授权弹窗各自的取消，实测两条路径回执完全一致。处理：先按「期望埋点 + `*` 标记」保留过一版，最终确认无法验证后删除，只录入平台能真实记录的 6 个，并在文档里写清每条采不到的原因。
  • 「拒绝，不再询问」路径无法用自有账号验证（点完该账号永久不再弹窗）。处理：留到开发阶段用测试账号验证该埋点归类，先不阻塞方案定稿。
  • 埋点 `project` 字段硬编码为 1，测试数据会进正式库 `[临时]`。处理：本期用平台「埋点测试」按用户动作验证，暂不阻塞；正式方案是改为读 buildconfig env 并在 release 脚本加断言。
  • 白屏一次没修干净、以「一直加载中」的形式回归。处理：本轮把该提前 `return` 之后被跳过的初始化整段盘清（loadStates、firstEnter、tabbar 设置），排查与复现路径写进 P11-issues 复盘文档。
待进行
感悟 · 工作方法
  • 一个 bug 修完，要回头把同一段结构性错误影响到的其他变量都盘一遍。昨天只搬了报错那一行的初始化，`firstEnter` 还留在提前 return 之后，今天就以「一直转圈」的形式冒出来——同一处跳过，跳过的从来不止一个东西。
  • 埋点能不能采到，只有真机回执说了算。文档上两级弹窗看着是两个独立动作，实测回执一模一样，凭推断设计的表全得推倒重来。定埋点表之前先花十分钟把每条路径真机跑一遍、把回执打出来，比设计完再返工省事。
  • 指标要分层，主指标只留一个。四个指标并列等于没有主指标，出了问题不知道先看哪个；分成主 / 过程 / 背景 / 护栏之后，端到端掉了一眼就知道是 push 没吸引力还是落地掉链子。同理也别替自己的功能背不属于它的目标——这个策略压根不产生新订阅，就不该去背订阅渗透率。
感悟 · 个人成长
  • 想要的和平台能给的对不上时，别硬留一个自己明知拿不到数的口子。今天几次想把采集不到的埋点先留着、加个星号，其实是把「验证不了」推到上线之后；承认限制、把为什么采不到写进文档，比留个空位让人以为有数据强。
2026-07-21 周二
今日主要工作
支付宝 · 首页白屏线上问题定位
  • 张振锋转来用户白屏反馈。原 AI 日志分析结论（插屏广告 `createInterstitialAd` 持续 61002 阻塞 Render）被推翻——广告报错是页面被重复加载后的结果而非原因。
  • 真因在我方代码：首页加载状态初始化被放在隐私协议弹窗的提前返回之后，且异常兜底引用同一对象导致二次抛错、兜底失效。触发需同时满足三条件（新用户 + 从带城市参数的外部入口进入 + 点「同意」），这也是常规测试一直复现不了的原因。
  • 已在开发者工具用带城市参数的冷启动稳定复现，报错行号与线上日志吻合；修复后同路径复验正常。已向张振锋更正口径，另请其协助确认广告位 61002 填充是否正常、日志中「冷启动 6473s~8568s」的统计口径。
支付宝 · 「去设置 PUSH 召回」文档与接口权限
  • 产品规范与验收用例定稿入库（633 行），并从 0.2.1 目录归位至 0.3.1；目标与埋点两节按「一个动作一个数」重新精简。
  • 厘清消息能力的两条链路是配套而非二选一：链路 A 由车来了用自建模板主动推（默认只进支付宝消息盒子），链路 B 回传订阅关系、由支付宝在用户有乘车行为时投送。
  • `alipay.commerce.transport.message.send` 无自助开通入口，控制台任何配置都不会让它出现——只能由支付宝对接人（苔雨）在服务端加白名单权限位，并为模板开通 PUSH 特别通道。我方可先自行完成的两项：补应用网关、启用 openid 配置管理。
  • 赵苓反馈 stage 环境需先加权限才能调用支付宝接口，加完后回告赵苓。
支付宝 · 赶车闹钟订阅埋点方案定版
  • 方案由「四点漏斗」收敛为一个埋点 + 一个字段：`alipay_赶车闹钟设置页_订阅成功`，`field1` 区分首次订阅 / 再次设置，首次判定用小程序本地标记（不依赖平台字段，省去真机验证）。
  • 决策依据：`field1` 是九章默认可查维度，分子分母同源、一条 SQL 出结果；埋点规范只可下线不可改名，先简后加比先全后改安全。代价是暂无失败归因，后续需要时新增埋点即可，不影响历史数据连续性。
  • 向刘胜确认申请流程：需自行按规范新建埋点，审核通过后数据在九章平台查看。需求文档已成稿，待发数据侧审核。
数据 · 赶车闹钟周期分析（已交付张振锋）
  • 8394 条闹钟 / 7430 名用户，周期呈明显双峰：工作日五天 44.8%、单天 30.7%，2–4 天合计仅 4.5%；91.2% 的用户只订 1 条。
  • 单天闹钟中 88.9% 选的就是创建当天；周六创建的有 74% 只勾周六，周一创建的仅 9% 只勾周一——工作日进来的用户会主动改成通勤周期，周末进来的不改默认值，约 1900 条属一次性使用，是明确的流失口。
  • 结论落到两个动作建议：周末创建时调整默认值或加引导；单天闹钟到期后做一次召回。
支付宝 · 闹钟 × 收藏合并入口方案
  • 与产品侧共同确定版本 B：收藏页行内放开关 + 首次进入的引导气泡，点开跳转到原有的唯一一套设置界面，不再维护两套 UI；已产出网页原型供评审。← 决策：产品侧拍板。
  • 同步排查出 8 项待定，其中 1 项是硬门槛（收藏项站序缺失，见「问题与处理」），确认前不动工。
城市 · 对外城市与行政区划代码映射表（已交付赵苓）
  • 按后端要求从小程序全量城市列表整理对外城市与行政区划代码映射（216 城），逐条核对同名歧义项（沙湾=新疆、东兴=防城港、滨海=盐城、甘孜为县等）。
  • 已发赵苓，并备注涠洲岛、洋浦、宁东三个非标准行政区的处理方式。
业务功能进展
  • 首页白屏修复已完成本地验证——加载状态初始化提前至隐私弹窗返回之前，并清理一处历史遗留调试代码（数组越界，一直在污染线上日志）；单测、Lint、完整构建均通过。改动目前仍在工作区未提交，复盘文档待写。
  • 「去设置 PUSH 召回」产品文档 + 验收用例（488 + 145 行）、赶车闹钟埋点文档更新（一期方案 + 测试用例）两次 docs 提交入库。
  • 抖音《抖音小程序UI设计》规范核对后入库并推送 0.1.0。
问题与处理
  • 白屏根因两度误判（先归因插屏广告、再归因弱网）。处理：三轮收敛——读代码得出「新用户 + 点同意」，再由「IDE 里测不出来」这个反例挖出被城市守卫绕开的第三个条件，最后用带城市参数的真实冷启动坐实。排查路径将写进复盘文档，供下次遇到同类日志少走弯路。
  • 闹钟 × 收藏合并存在硬门槛：闹钟接口必须传站序，而非灰度城市的收藏项站序会被清空。处理：先找后端确认覆盖率——若大面积缺失，方案需改为「收藏行上只放入口、进设置页再选站」；另需后端提供批量闹钟查询接口（尚未排期），两项确认前不动工。
  • 版本号异常：`package.json` 在会话外被来回改动（0.2.0 ↔ 0.3.1）。处理：已确认磁盘与提交均为 0.3.1，注意编辑器中若残留旧版本，保存会再次覆盖。
  • 已上传的 0.3.1 体验版是 stage 包，而分支代码是 release 配置，两者后端环境不同，验收时需区分。⚠️ 待补：本次体验版的验收对象与验收范围。
待进行
感悟 · 工作方法
  • 判断一个根因成不成立，先看它能不能解释「为什么只有部分用户中招」。今天那份 AI 日志分析把广告持续报错说成根因，听着完整，但它解释不了差异——所有人都在加载广告，白屏的只有一小撮。解释不了差异的原因，多半是结果不是原因。
  • 复现不出来通常不代表没问题，而是测试路径正好绕开了。新用户没有城市会先被守卫跳去城市选择页，缺陷就被挡住了；只有构造出带城市参数的冷启动，才走到那条真正出问题的分支。所以复现前先找「什么条件下会绕开」，比反复重试有用。
  • 「这个东西在哪、怎么开通」这类问题，先翻自己手里的资料再往外搜。今天找接口开通路径搜了开放平台、搜了全网、翻了 SDK 源码，最后发现答案 6 月 18 号就归档在自己仓库的 `docs/inbox/` 里，写得清清楚楚。
  • 埋点设计先想清楚要看哪个数，再决定拆几个。四个埋点看着信息全，实际是把同一个动作的四种结果谎报成四件事，算转化率还得手动把分母拼回去；一个埋点加一个默认可查的字段就够回答「多少人订阅成功」。埋点只能下线不能改名，先简后加比先全后改稳。
感悟 · 个人成长
  • 设定新功能/新方案之前的指标预期和埋点需求对应好，也是想清楚这个功能设置的重要一步。
2026-07-20 周一
今日主要工作
支付宝 · 「去设置 PUSH 召回」PRD 与验收定稿
  • 自行重写 PRD 与验收用例并入库，明日评审。核心纠偏：0706 立论的「触达率 9.77%、九成用户没设置」口径不成立——该值是日均触达÷订阅，内部数据显示设置页→订阅转化 22%、近一月新订阅 89.5% 有生效闹钟，订阅链路本身健康。
  • 据此改掉成功指标：主指标由「触达率」换成召回设置转化率（灰度起步 ~15%），点击率不低于现有到点提醒的 4.16%，退订/投诉率不劣化为硬约束。
  • 定稿文案四档（收藏·有候车站带「最近一班还有 N 站到站」、≤2 站退兜底、收藏·无站、查看），并补齐三级发送闸门（免打扰 > 线路运营 > 个性化）、单线 3 次递增冷却频控、闸门拦截不扣配额的重试语义。
  • 消息模板与字段沿用此前赶车闹钟已确认的口径，未另找人对接。厘清三方分工：主体在后端（圈人、选线定时、过闸门、调发送 OpenAPI），前端只做落地承接、补 bus-alarm 埋点与 src 归因透传。
抖音 · UI 设计规范反推与城市加载确认
  • 与首帅沟通，由他指导用 AI 反推 UI 设计规范的做法，据此从支付宝代码反推产出《抖音小程序UI设计》文档。
  • 赵苓确认抖音城市加载正常，此前上海线路全显示「等待发车」的疑点排除，不是「实时数据城市集合」未生效。
  • 确认铺开全部城市主体是运营配置动作而非开发：需在 h5 渠道城市配置与实时数据城市集合两处放开，每放开一批由我方用契约测试抽查验证。
支付宝 · 福利页体验修复
  • 福利页左上角标题由「福利」统一为「车来了」，与首页 / 我的一致；修复加载失败态图标被拉伸变形。已在 IDE 验证并提交推送 release/0.2.1。
业务功能进展
  • 支付宝 release/0.2.1 今日 2 个提交并推送远端（PRD/验收文档 633 行、福利页修复 3 个文件），按惯例日常只在 release 分支提交、版本收尾再整条合入 master。
  • 福利页修复具体口径：`defaultTitle` 改为「车来了」；失败态图标补 `aspectFit` 且盒子由 200×200 改为 320×180，匹配 16:9 原图，消除拉伸。
  • 抖音《抖音小程序UI设计》规范文档覆盖全局色彩字号体系、9 个页面逐页结构、14 个组件规范、9 条平台适配差异、6 项待定 UI。当前为内部整理，已入库 docs/，待核对后单独提交。
问题与处理
  • bus-alarm 模块当前 0 埋点，即便落地页带上 src 也没有「设置成功」事件可归因。处理：一期先用「落地 src 曝光 + 类比现有到点提醒 4.16% 召回率」粗估效果，精确归因随补埋点一起做；灰度建议先只发收藏侧（不依赖查看埋点）跑通转化。
  • 抖音上海线路实时数据全部显示「等待发车」。处理：经赵苓核查确认城市加载正常，非配置问题，该疑点已排除。
  • 福利页失败态难以在开发者工具直接触发（弱网/离线入口找不到）。处理：[临时] 改代码强制进入失败态验证图标比例，验证通过后已还原，确认 welfare.js 无残留改动。
待进行
感悟 · 工作方法
  • 策略的颗粒度得有数据托底。本来想按收藏次数分强弱信号，一跑画像发现 83% 的人只收藏 1 条线、同线双向 0 人，这个分层根本没有对应的人群——数据撑不住的分层不是精细，是自欺，砍掉比留着强。
  • 文案不要替用户描绘狼狈。「别眼睁睁看车开走」「帮您盯着」这类强损失框架和拟人化，在用户没主动求助的召回场景里像说教，平实地讲清楚这功能能帮你干什么反而更容易被接受。
感悟 · 个人成长
  • 遇到跨方需求先问一句「这事跟我这边到底有什么关系」。今天把发送链路的职责边界问清楚，才发现主体虽然在后端、但真正的卡点在我方——bus-alarm 一个埋点都没有，不问就会以为自己没事、到验收才发现归因不了。
2026-07-17 周五
今日主要工作
微信 · 3.12.2 体验版发布
  • 走通体验版发布全流程（合并 feat/ai-skills 到 release/3.12.2、version bump、切体验版白名单内部试用、真机验收），整理成可复用 runbook「微信小程序-体验版与正式版发布流程.md」（含踩坑清单 + 两条回退路），放桌面备下次直接用。
  • 完善 wx-agent 流程文档：流程图改为微信同款泳道分栏 SVG。
抖音 · 迁移文档与环境
  • 补齐实施计划：运行时冒烟层 + 环境矩阵 + 抖音坑 checklist。结论沉淀：抖音渠道要「两张表都要配」（h5 渠道配置管理 + 城市白名单），只配一张接口会报「渠道号未绑定城市配置」。
支付宝 · 「去设置 PUSH 召回」文档研读
  • 研读产品文档，厘清召回触达的职责边界：发送主体在后端（定时调度器 server-to-server 主动调支付宝发送 OpenAPI、带签名触发），前端仅落地页中转与归因透传。为后续前端接入方案打底。
数据 · 广告收入周增长复盘
  • 改版后广告收入：第 1 周（7.2–7.8）¥312.48（+11.7%）、第 2 周（7.9–7.15）¥375.00（环比 +20.0%、对比改版前 +34.1%），两周合计 ¥687.48，增长在加速，主要由福利页 / 首页信息流驱动。同步梳理新增长期订阅用户数变化（表 + 图）。
团队 · 会议与协同
  • 按张振锋要求重新梳理工作进展、归档进团队文档。
  • 参加《产品设计周会》（10:30–13:14）、《每周沟通》（13:15–13:45）。
业务功能进展
抖音 · 登录、收藏页与渠道独立
  • 抖音静默登录接线（1.7 登录）、收藏页迁移（2.1 收藏页）落地；dev 环境 authBaseUrl 对齐至 dev.chelaile.net.cn。
  • 撤销开发期 mp_alipay 渠道借用 `[临时]`，全仓还原 mp_douyin 正式渠道号（cf4449e）；契约测试 2/2 通过（城市列表返上海、上海公交数据 88KB），tsc / eslint 全绿。埋点 / 数据从此归抖音自己的渠道、不再串支付宝；当前城市白名单仅上海，真机测试需手选上海。
  • 修复收藏页打不开、UI 灰底 / 白底不一致；用户协议按产品决策直接改为「抖音」（先不走法务）。← 决策：产品侧拍板。
  • 本次抖音先不上线，先梳理上线前待办去和对应的人核对。
问题与处理
  • 抖音城市列表报错 99「渠道号未绑定城市配置」：定位为渠道城市配置未生效；配置生效后 ncitylist 已返真实数据，控制台残留的 99 系旧编译缓存，清缓存重编即消。
待进行
感悟 · 工作方法
  • 反复需要用到的操作流程，别每次重新捋——抽象成一个心智模型（比如「线上版 / 体验版是两个互不影响的指针，谁也不会自动动」），再落成一份 runbook，下次拿来就能用，也不容易误操作。
感悟 · 个人成长
  • 发布、切体验版这种不可逆的操作，动手前先把原理和回退路问清楚（会不会覆盖、码转发会不会泄露、切错能不能一秒切回），确认了再点，比先点了再补救稳。
2026-07-16 周四
今日主要工作
支付宝 · 「去设置」PUSH 召回方案
  • 完成「已订阅未设置提醒」用户召回方案设计：拉取活跃用户 list → 经 subscribe.query 逐一核对订阅状态 → 对「已订阅未设置」用户按活跃/早晚高峰前时段推送，文案结合收藏线路/浏览历史推具体线路。方案已落仓库（未提交），尚未拍板——「无收藏无浏览」用户的文案取舍与预期指标随评审一并确定。
  • 明确分工：后端落实用户 list 与按用户维度的近期线路查询；PUSH 文案、发送时间与触发发送代码由我方实现。
微信 · AI 接口
  • 接口口径收敛：query 承载身份、不用 payload，删除 components 数组；今日完成代码部署，待微信侧联调。当前仍为我方单方定稿，下一步联调前争取微信侧书面预期确认。
  • 听取首帅对微信侧接入我方整体框架的讲解，理清接入全貌。
抖音 · 接口联调与城市配置
  • 收藏/取消收藏接口联调走通：OAuth 部署至 api.chelaile.net.cn，openId 登录链路验证通过，后端 AppSecret 配置到位。
  • 城市配置已完成（陈阳侧配好，当前只配上海）。
数据 · 周会材料整理
  • 将「闹铃×收藏关联分析」「赶车闹钟站点与方向订阅行为」两份网页报告按「目标—问题—指标—结果—结论」结构整理成 Word 文档，作为周会材料。
  • 与多姐交流产品观察方法。
业务功能进展
  • 抖音收藏/取消收藏接口联调走通、城市配置完成（先只配上海）；微信 AI 接口改动完成代码部署（微信仓库）。支付宝仓库今日无提交。
问题与处理
  • 抖音收藏接口联调一度卡在后端 AppSecret 未配置。处理：主动提供 AppSecret 催配，配置到位后接口走通。
  • 昨日提示的「多个 P0 解冻压在 7.16」今日盘点：城市配置✅、微信代码部署✅、抖音渠道码权限✅，支付宝 PUSH 方案已成稿但未拍板——四项中三项如期解冻，未出现连锁阻塞。
待进行
感悟 · 工作方法
  • 设身处地从人、空间、时间三个维度去理解用户行为，而不是只盯着页面和数字。
感悟 · 个人成长
  • 提醒自己增强对产品的敏锐度，多观察、多主动觉察产品的问题。
2026-07-15 周三
今日主要工作
微信 · AI agent 接口方案
  • 微信 agent 接口改动文档已定稿：明确不再用 payload（用户点进小程序可重填查询、公交实时信息本就会变），保留 query；目标是保证用户落地 `pages/linedetail`、`pages/stop-detail` 时看到正确状态。
数据 · 闹钟订阅站点与方向行为分析
  • 分析目的：为「把闹钟与收藏收进同一个入口」判定可行性。核心结论：94% 用户一条线只订 1 个站；订≥2 站的用户里 54% 是往返（去1站+返1站）、46% 单方向多站。
  • 产出分析报告网页，先不入库、上传成链接，已分享给肖平原（含昨日「闹钟×收藏关联复盘」）。
数据 · 收藏页转化率与支付宝留存
  • 微信收藏卡片曝光→收藏详情页打开转化（7.6–7.14 排除周末）：判断 7.14 详情页打开下降主因是进入入口变少，而非用户意愿下降。
抖音 · openId 与城市配置对接
  • 明确抖音用独立 openId（不沿用支付宝 userId），城市配置从渠道号绑定 `mp_douyin`；对接口径定为「参数名 + 后端认 openId」，区分 dev / stage 环境。
  • 城市配置落地路径：咨询赵苓，赵苓建议转陈阳处理，已主动约陈阳当面沟通确认操作。
业务功能进展
  • 今日以接口方案、数据分析为主，引导功能设计前期方案，无代码提交。
问题与处理
  • 微信 AI 接入依赖微信侧协作，车来了无法在开发者工具独立验证。处理：先按定稿方案改好接口（去 payload、保 query、保证落地页状态正确），等微信侧联调。
  • 数据口径易误读：96.7%「单方向」若与「94% 单站」并列会被误当成独立聚焦信号，实为只订 1 站没机会订两方向。处理：拆开口径、「用户×线」改名「用户-线」、报告开头加解释。
待进行
感悟 · 工作方法
  • 数据分析先定「目标—问题—假设—预期」再动手，别拿到数就开跑。先想清楚要验证什么、指标是什么、预期什么样，跑出来的结论才站得住、也知道该信到几分。
  • 数据结论要防误读：同一个数字换个口径就变味。96.7%「单方向」看着像聚焦信号，其实只是大家只订了 1 个站、根本没机会订两个方向。命名（用户×线→用户-线）和口径（含不含取消）都得在报告里写死，别让人自己脑补。
感悟 · 个人成长
  • 首帅教给我做数据分析报告的核心思路，非常受用。
2026-07-14 周二
今日主要工作
支付宝 · 到站提醒优化排期
  • 对《0706 For 车来了》2.1–2.6 逐条给出采纳情况与档期，产出排期表回复支付宝。
  • 关键取舍：2.1「去设置」PUSH 列 P0（7.14–7.17）；2.3 已由气泡提频至 3 次 + 闹钟介绍页覆盖（7.8 已上线）；2.6 时间设置改滑动选择采纳，上车提醒纳入评估，下车提醒本期不做。
数据 · 闹铃订阅 × 线路收藏关联分析
  • 核心结论：防流失的关键不是「让用户去收藏」，而是「把闹钟设在他收藏过的线上」——收藏线取消率 11.9%、非收藏线 17.3%（p≈0.009，显著）。
  • 收藏是闹铃的上游鱼塘：收藏用户 43,879 人中仅 2.3% 设了闹铃，是扩大闹铃盘子最近的入口。
  • 闹铃不会自动反哺收藏（设闹钟者并未收藏更多），需在设闹钟成功页加一键收藏引导才接得上。
抖音 · 技术对接
  • 向赵苓交付抖音小程序 AppID 与 Appsecret（密钥单独提供，不落文档），当前等渠道码生成。
  • 与首帅沟通，理清用户登录与后台服务器之间的 openid 形成链路。
其他沟通与产出
  • 微信 AI agent：与首帅沟通后明确修改技术方案。结论：payload就不要了，query可以保留。
  • 收藏页广告位答疑（张振锋）：广告位改为二级页面后仍保留，两个 banner 轮流切换，收入不受影响。
  • 支付宝小程序接入 PM 工作区：只读克隆代码到本地，产出基线版本登记表与 PRD-实现差异台账。
业务功能进展
  • 抖音小程序迁移推进至阶段 3（今日 7 个提交）：广告位统一开关整链；真机修复首页实时到站不自动刷新（根因：支付宝的 createIntersectionObserver(this) 写法在抖音组件版签名不同，曝光观察器失效）、my-map 地图适配（白色底图与重复地名）；清理脚手架残留页，阶段 3 收尾。
  • 新增接口契约测试样例（旁路、手动触发）：直打 stage 后端断言响应结构与字段类型，补齐单测覆盖不到的「后端契约漂移」一层，不进 CI 与打包，随时可删。
问题与处理
  • 抖音真机与开发者工具表现不一致（首页不刷新、地图崩）。处理：以真机为准逐项定位根因并回归验证；沉淀通用坑——支付宝组件里的 createIntersectionObserver(this) 迁抖音必须去掉 this 参数。
  • 抖音渠道参数未就绪，开发期暂借支付宝渠道（代码内已标 TEMP）。处理：等渠道码生成后由后端绑定抖音渠道再替换。
  • 数据分析口径重合（收藏与闹铃分母交叉）。处理：改用精确 lineNo join 替代早前的站序启发式，结论标注硬 / 软可信度。
待进行
感悟 · 工作方法
  • 对于例如openid，userid，AppID等这些和平台登录相关的信息，也需要多深入问一下是什么？怎么来的？因为这样会更好理解用户的登录信息，我们怎么根据什么身份标识提取这些数据。
  • 相关性不是抓手。「收藏的用户更不容易取消闹钟」不成立，成立的是「闹钟设在他收藏过的线上更不容易被取消」——同一份数据，切法不同结论相反。做增长要找那个真能动的变量。
  • 契约测试是可以进行的。
感悟 · 个人成长
  • 可以通过日报的形式更好回顾今天一天的进展，以及日报的形式可以有更量化的进展和结论，可以使分类更清楚。
2026-07-13 周一
今日主要工作
  • 微信 AI agent 接入方案调研与决策：向张振锋确认微信小程序 AI 技术更新指南，明确当前首要任务是调整小程序接入 agent 的格式（适配性）、后续再补功能原子接口；对比「skill + 原子接口」与「hand-off 推送小程序卡片」，原子组件暂不上线、改由 hand-off 承接；与海牛张、王冬平同步方案。
  • 支付宝侧方案排期：基于支付宝《0706 For 车来了》建议和首帅确认整理排期表（支付宝建议+目的 / 我方取舍方案 / 决策考虑点 / 排期），覆盖已订阅未设置用户 PUSH、订阅关系回传、赶车闹钟提频等项。
  • 用户行为数据分析：向赵苓获取支付宝小程序收藏线路与订阅赶车闹钟的联动数据（近一月收藏 / 订阅闹铃记录及统计 SQL），明确数据匹配口径（收藏表 h5id 与闹钟表 udid 对应、去 ali_ 前缀）；分析取消闹钟(status=0)用户与其收藏线路的关联行为并做校验，产出数据分析报告。
  • 接收并查看青岛琴岛通乘车码引导任务（王冬平提供文档）；和爱香姐沟通。
业务功能进展
  • 抖音小程序迁移开发推进(阶段 1.3–2.2)：完成首页、搜索页、web-view 容器页、线路详情页（页面+控制器+路线视图+叶子组件）、站点详情（station 模块+页面+组件+地图 spike）迁移，并做真机适配排障；修复 search.scss 残留 .less 导入导致的编译挂起。
问题与处理
  • 支付宝侧建议不全盘接纳。处理：逐条列出建议、目的与我方取舍原因，加「决策考虑点」列（如订阅关系及内容回传支付宝，需评估用户数据合规），按需排期。
待进行
感悟
  • 抖音迁移按阶段小步提交（1.3→2.2 每批组件独立提交），改动可追溯、出问题好回退，比一次性大提交稳。
  • 面对支付宝、微信给的方案别全盘照收：先列清对方目的，再列我方取舍和决策考虑点，涉及用户数据回传这类还要评估合规，想清楚再排期。
  • 和爱香姐沟通之后，收获能量，我需要之后多提醒自己要更主动和勇敢一些，多行动和尝试。
  • 关注精力，更好提升工作效率。协调能力还涉及目标明确性，能帮助自己和团队合作效率更高。
2026-07-10 周五
今日主要工作
  • 上午 10:30–12:24 参加陈阳发起的《产品设计周会》，同步团队周进展、讨论后续业务安排。
  • 继续学习 B 端产品交付的 AI native 框架(harness)：理解 8 个 agent(生成/审核交替) + 人工 Gate 的编排，及发号器 / 状态机 / 交付包、「机械归脚本、判断归 prompt」的落地方式。
  • 分析支付宝小程序赶车闹钟与收藏功能的效果数据。
业务功能进展
  • 推进抖音小程序迁移部署准备：拉取抖音项目仓库(mp-douyin-chelaile)到本地、配置 SSH，按 docs 新手指南搭建开发环境，注册抖音开放平台；就技术栈（原生 JS/TS vs Taro 多端）做初步比较。
问题与处理
  • 抖音仓库技术选型待定（原生 JS/TS vs Taro / uni-app 多端）。处理：先按现有仓库框架把本地环境跑通，选型结合迁移清单后续再定。
待进行
感悟
  • 抖音从 0 起步，先按官方新手指南把环境、SSH、开放平台这些基础跑通，再谈框架和迁移，顺序理顺了后面少返工。
  • 想给周报也搭个自动 agent，把每周的进展、思考、疑问自动收集留痕，少些手动整理；方向和日报这套一样，先小步搭起来。
2026-07-09 周四
今日主要工作
  • 抖音小程序功能迁移：从 0 梳理支付宝→抖音的功能迁移清单，含迁入优先级判定；调研抖音开放平台要求，并就工程形态（独立原生仓 vs Taro / uni-app 多端统一）做取舍。11:53 向首帅发出《抖音小程序功能迁移清单》。
  • 学习 B 端产品交付的 AI native 框架(harness)：理清「机械的归脚本、判断的归 prompt」思路，及发号器 / 状态机 / 泄漏扫描下沉脚本、每个 agent 一个 markdown 等要点；定下试点期双轨——试点需求按框架原样跑、日常小改走五阶段轻流程，互不干扰。18:00 参加吴林洁发起的《harness 培训-契约交付》。
  • 规划 AI 数据看板：延续数据清单地图，设计可每日自动更新、只看关键结果的看板方案。13:30 与李东煜沟通。
业务功能进展
  • 完成抖音小程序功能迁移清单，明确各功能迁入优先级（乘车码考虑优先，平台正大力推广）。
问题与处理
  • 抖音迁移工程形态待定（独立原生仓 vs 多端统一框架）。处理：先按 A 方案原生起步、跑通核心功能，后续视情况再转码做多端统一。
待进行
感悟
  • 今天的 harness 分享会很受用；想明天再深入理解一下 hook、workflow 这些是怎么结合编排的，以及前期环境搭建的顺序。
  • 功能迁移还要考虑平台架构、技术选型等；先把功能清单明确好，后续可以让 AI 分步骤推进。
2026-07-08 周三
今日主要工作
  • Agent 形态推进：调研支付宝阿宝与微信 AI agent 接入小程序的逻辑及 MCP / Skill / Agent 封装范式差异，整理好阿宝接入样式与已接入商家案例，备好商务 Q&A。
  • 规划数据清单地图：按页面 / 功能梳理采集清单与路线，设计自动化采集分析器，先落核心页面。
  • 撰写二维码 / 文本 / 链接映射与浏览器分流说明文档：理清解码链路，及浏览器、微信、支付宝各自的打开 / 拦截动作。
业务功能进展
  • 赶车闹钟引导气泡提频改版今日上线：提醒次数由 1 次提至 3 次(每次间隔 7 天)，设置页新增功能说明与介绍页，配套 PRD 与验收用例。
问题与处理
  • 上线前将版本记录连同 Claude Code 的疏漏点一并写入 claude.md，做版本留痕，避免遗漏。
待进行
感悟
  • 探索性的东西先在本地跑通再进公共仓库，没验证就合风险大。
2026-07-07 周二
今日主要工作
  • 下午 1:20 参加邵博发起的沟通会，围绕组织形式变革、质量管理过程、角色分工（例如，同一角色的不同职责）、工作流与 SOP 调整、agent 分工与采集等展开;14:30与首帅沟通赶车闹钟气泡提频和介绍功能设计；15:00 参加张振锋发起的《Agent 形态讨论》(参会:王冬平、张振锋)。
  • 设计好赶车闹钟气泡提频和功能介绍的设计，撰写好实施文档和代码，待上线。
业务功能进展
  • 澄清赶车闹钟引导气泡改版需求:气泡提醒由每用户 1 次调整为最多 3 次(触发一次后间隔满 7 天再次触发,累计 3 次),并按优先级梳理优化策略——P0/P1 为增加提醒、控频、触达时机、兜底文案,及对已订阅线路用户的提醒设置触达;P2 为收藏页新增提醒、将用户订阅状态变更数据回传支付宝。
  • 明确两项关联设计:① 该入口后续将与收藏功能合并,气泡逻辑需一并考虑;② 拟新增赶车闹钟介绍页,提升用户对功能的认知。同时明确埋点目的:追踪气泡"曝光→点击→关闭"全链路转化,用于评估改版效果。
问题与处理
  • claude无法自行记录支付宝平台的数据。解决方式-需要自行下载数据，再让claude处理。
  • 记录 AI 应用中待解决的问题:Claude Code 多窗口共享历史背景、工作区隔离、幻觉、agent 管理、封闭知识库搭建等。
待进行
感悟
  • 数据分析需制定适合自己功能的每日看板，减少人为拉取并单个看分析的情况。
  • 多agent协同机制，不再是只分任务进行，而是可以分角色和过程梳理，agent之间互相监督，人最后负责agent的结果产出。从自己需要的事情出发搭建这个agent协同系统。
2026-07-06 周一
今日主要工作
  • 围绕"赶车闹钟"功能开展数据分析与订阅机制研究：向首帅发送《赶车闹钟引导-增加频率》设计文档，在和首帅的讨论中学习了功能和页面设计链路。
  • 抓取支付宝广告变现后台近 7/30 天基线数据（广告收入、曝光、CTR、CPM），梳理 16 个广告位收入结构，线路详情页banner 为收入主力。
  • 与赵苓沟通申请支付宝小程序后台数据接口权限。
业务功能进展
  • 梳理赶车闹钟订阅提升的两条路径（增加页面曝光、留住设置页停留人数）及订阅机制四层级（功能开关→消息模版权限→订阅权限→通知权限）。
  • 规划赶车闹钟与收藏功能相关文档。
问题与处理
  • 排查"累计订阅 1.6 万 vs 发送用户数 3k+"的数据差异，澄清统计口径。请教振峰哥后总结用户未收到赶车闹钟消息的可能原因：消息接受途径关闭（功能未开启/订阅权限关闭）、发送时间与订阅时间窗口存在差异。
  • "发送用户数"仅指订阅消息推送人数，与闹钟引导气泡为间接因果关系，已澄清统计口径。
待进行
感悟
  • 用户增长策略和功能之间的关联。可以通过用户点击闹钟设置页面和用户设置闹钟两个动作（即转化率），设计增加用户对闹钟订阅的方式，就是增加进入页面的频率，增加设置闹钟的概率。未来相关用户转化的策略也可以用这样的方式思考。
2026-07-03 周五
今日主要工作
1. 参与会议
  • 参加《产品设计周会》，时间为10:30至11:00，持续约30分钟。
2. 编辑在线文档
  • 在《2026年Q2产品周进展-详版》文档中，欧登于7月3日编辑了“支付宝小程序”版本更新内容（7.1日上线0.3.1版本，调整收藏页和福利页等、更新赶车闹钟引导气泡数据对用户留存的影响）。
3. 学习数据分析·九章平台
  • 学习埋点管理、埋点查询、支付宝平台订阅数据查询等。
4. 规划赶车闹钟和收藏功能
  • 厘清二者功能逻辑和要素，整理相关数据。
  • 梳理并确认「赶车闹钟」（5 份）与「福利页/收藏改版」（3 份）功能文档已齐全入库，无需重复撰写。
  • 理清「收藏 × 赶车闹钟」联动策略：以“闹钟反哺收藏”为主方向，借高活跃的闹钟订阅激活用户收藏线路意图。
5. 制作日报流程梳理
业务功能进展
  • 今日以产品定位与指标梳理为主，无文件/代码提交。
问题与处理
  • 日报改用「速记 + git + 企微会话」三源兜底。
  • 数据指标对应以及含义，对应目的需要再次理解。
待进行