即刻App年轻人的同好社区
下载
置顶最近髂骨拉伤，去做运动康复，才知道自己一直以为的“骨盆前倾”，其实更复杂一点：右侧前倾、左侧后旋，连带着右侧吸气不足，右侧支撑也没有左侧稳定。
听到这个结论时，我原本以为自己会有一种“终于找到原因了”的惊喜。毕竟运动中右侧身体那些长期说不清的不稳定，终于有了解释。
但我仔细感受了一下，发现第一反应并不是惊喜，而是懊恼：怎么会这样？为什么我一直都没有发现？
更有趣的是，当我看见这份懊恼的时候，又立刻多了一层无奈：原来那个挑剔自己的声音还是这么快，一不注意，又成了第一反应。
几年前，我第一次真正看见这个严厉的超我时，很讨厌它。因为身体不舒服时，它从不说“你辛苦了”，而是说“你怎么又出问题了”；情绪失控时，它也不问“你是不是委屈了”，而是质问“你怎么又没控制好”。
直到后来有一次发火后，我想了很久都不明白原因，再一点点往回捋，才发现我其实不是在冲着面前的人发火，而是那个场景里的“被挑剔感”，一下子勾出了我积累很久的委屈。
在心里看见那个一边委屈、一边还很努力的小女孩的那一刻，可能是我这几年学习心理学后，最接近“开悟”的瞬间。
我开始把很多事情串联起来：原来自己这些年的许多选择，其实都在指向同一件事——人生的第一目的，正在从“我要做到什么、证明什么、得到什么结果”，慢慢转向“我能不能更支持自己一点”。
选择对自己抱有善意的环境，选择自己对自己多一点好奇，给自己耐心去看见每个情绪背后的需要，也开始学习给自己放松和放空的时间。
这次就很开心的点在于，不只是我终于知道了身体哪里不稳定，而是当那个挑剔的声音再次出现时，我没有立刻被它带走。
我已经开始能看见它，甚至能自嘲一下它，然后试着和它好好相处。
彻底消灭那个严厉的“超我”应该是不可能了，毕竟我今天达到的社会价值也都是它给的礼物。
但只要能在它出现的时候，不再只相信它，就是一件很美好的事啊！
听到这个结论时，我原本以为自己会有一种“终于找到原因了”的惊喜。毕竟运动中右侧身体那些长期说不清的不稳定，终于有了解释。
但我仔细感受了一下，发现第一反应并不是惊喜，而是懊恼：怎么会这样？为什么我一直都没有发现？
更有趣的是，当我看见这份懊恼的时候，又立刻多了一层无奈：原来那个挑剔自己的声音还是这么快，一不注意，又成了第一反应。
几年前，我第一次真正看见这个严厉的超我时，很讨厌它。因为身体不舒服时，它从不说“你辛苦了”，而是说“你怎么又出问题了”；情绪失控时，它也不问“你是不是委屈了”，而是质问“你怎么又没控制好”。
直到后来有一次发火后，我想了很久都不明白原因，再一点点往回捋，才发现我其实不是在冲着面前的人发火，而是那个场景里的“被挑剔感”，一下子勾出了我积累很久的委屈。
在心里看见那个一边委屈、一边还很努力的小女孩的那一刻，可能是我这几年学习心理学后，最接近“开悟”的瞬间。
我开始把很多事情串联起来：原来自己这些年的许多选择，其实都在指向同一件事——人生的第一目的，正在从“我要做到什么、证明什么、得到什么结果”，慢慢转向“我能不能更支持自己一点”。
选择对自己抱有善意的环境，选择自己对自己多一点好奇，给自己耐心去看见每个情绪背后的需要，也开始学习给自己放松和放空的时间。
这次就很开心的点在于，不只是我终于知道了身体哪里不稳定，而是当那个挑剔的声音再次出现时，我没有立刻被它带走。
我已经开始能看见它，甚至能自嘲一下它，然后试着和它好好相处。
彻底消灭那个严厉的“超我”应该是不可能了，毕竟我今天达到的社会价值也都是它给的礼物。
但只要能在它出现的时候，不再只相信它，就是一件很美好的事啊！
13 00
这个社会太奖励“看起来很强”的人了：奖励那些敢下判断的人，奖励说话笃定的人，奖励不懂也要装懂的人，奖励只看到片段却敢评价整体的人。
于是很多原本并不喜欢贬低他人的人，也慢慢被训练成了这种样子。
我有一个网球陪练，也有一个网球教练。最开始聊天时，陪练跟我说，这个教练教得不是特别好。
我当时有些半信半疑。毕竟他说得很确定，也像是比我更熟悉情况。
但相处久了以后，我慢慢发现，他的判断可能很片面。
他也许只是看到某个学员跟这个教练上过一两节课后，没有明显进步，就把“学员没打好”归因成“教练教得不好”。
可是他并不知道这个学员原本是什么水平，不知道教练当时在改什么问题，也不知道这个学员课后有没有练习。
他看到的只是一个片段，却得出了一个整体判断。
更微妙的是，这个教练并不是一个很强势、很会通过比较和压制来证明自己的人。他比较柔和，甚至在我鼓动他们俩对打时，会主动给对方喂球。
这样的人，在一个崇拜强势姿态的环境里，自然很容易被低估。
这其实只是件小事，却牵引住了我很多注意力和情绪。因为它和我长久以来的困扰太一致了。
在很多职场场景里，那些明明不真正懂的人，却很敢下判断、很敢评价整体，甚至一次又一次抢走话语权和功劳。
而真正做事、真正有能力、但不急着表现自己的人，反而容易被误解、被低估，甚至被错误叙事覆盖。
但后来，当我意识到这里面也有我个人经历的投射之后，我又开始有了更深一层的理解：
陪练真的是一个“坏的评价者”吗？
好像也不是。
他其实也有共情能力，也会照顾别人。只是他可能也和很多人一样，长期活在一个奖励强势、奖励确定感、奖励“看起来很懂”的环境里。
这种环境会塑造其中的每一个人。
尤其在竞争激烈的地方，你会越来越意识到：真实能力不会自动被看见。你不抢先表达，不用力呈现，不主动保护自己的叙事，就很可能会输。
可也正是在这个时候，我通过他的故事意识到，真正难的不是学会虚张声势。
真正难的是，在学会保护自己、表达自己、呈现自己的同时，不变成一个空心强势的人。
不变成那种明明不懂，却一定要表现得很懂的人。
不变成那种只看到片段，却急着评价整体的人。
不变成那种通过贬低别人，来证明自己有判断力的人。
真正的强势，应该是知道自己懂什么，也知道自己不懂什么；可以保护自己，但不靠压低别人证明自己。
所以或许，可怕的从来不是遇到一个虚张声势的人。
而是当你被这样的人伤害过之后，也开始认真研究：怎样才能看起来更像他。
这就是社会化最隐蔽的地方。
它不只是奖励某一种人。它还会让讨厌这种规则的人，也不得不学习这种规则。
所以我现在更想提醒自己的，不是“不要强势”。
而是别让自己为了不再输，慢慢长成自己曾经最讨厌的人。
于是很多原本并不喜欢贬低他人的人，也慢慢被训练成了这种样子。
我有一个网球陪练，也有一个网球教练。最开始聊天时，陪练跟我说，这个教练教得不是特别好。
我当时有些半信半疑。毕竟他说得很确定，也像是比我更熟悉情况。
但相处久了以后，我慢慢发现，他的判断可能很片面。
他也许只是看到某个学员跟这个教练上过一两节课后，没有明显进步，就把“学员没打好”归因成“教练教得不好”。
可是他并不知道这个学员原本是什么水平，不知道教练当时在改什么问题，也不知道这个学员课后有没有练习。
他看到的只是一个片段，却得出了一个整体判断。
更微妙的是，这个教练并不是一个很强势、很会通过比较和压制来证明自己的人。他比较柔和，甚至在我鼓动他们俩对打时，会主动给对方喂球。
这样的人，在一个崇拜强势姿态的环境里，自然很容易被低估。
这其实只是件小事，却牵引住了我很多注意力和情绪。因为它和我长久以来的困扰太一致了。
在很多职场场景里，那些明明不真正懂的人，却很敢下判断、很敢评价整体，甚至一次又一次抢走话语权和功劳。
而真正做事、真正有能力、但不急着表现自己的人，反而容易被误解、被低估，甚至被错误叙事覆盖。
但后来，当我意识到这里面也有我个人经历的投射之后，我又开始有了更深一层的理解：
陪练真的是一个“坏的评价者”吗？
好像也不是。
他其实也有共情能力，也会照顾别人。只是他可能也和很多人一样，长期活在一个奖励强势、奖励确定感、奖励“看起来很懂”的环境里。
这种环境会塑造其中的每一个人。
尤其在竞争激烈的地方，你会越来越意识到：真实能力不会自动被看见。你不抢先表达，不用力呈现，不主动保护自己的叙事，就很可能会输。
可也正是在这个时候，我通过他的故事意识到，真正难的不是学会虚张声势。
真正难的是，在学会保护自己、表达自己、呈现自己的同时，不变成一个空心强势的人。
不变成那种明明不懂，却一定要表现得很懂的人。
不变成那种只看到片段，却急着评价整体的人。
不变成那种通过贬低别人，来证明自己有判断力的人。
真正的强势，应该是知道自己懂什么，也知道自己不懂什么；可以保护自己，但不靠压低别人证明自己。
所以或许，可怕的从来不是遇到一个虚张声势的人。
而是当你被这样的人伤害过之后，也开始认真研究：怎样才能看起来更像他。
这就是社会化最隐蔽的地方。
它不只是奖励某一种人。它还会让讨厌这种规则的人，也不得不学习这种规则。
所以我现在更想提醒自己的，不是“不要强势”。
而是别让自己为了不再输，慢慢长成自己曾经最讨厌的人。
59 76
如本人所预期，我连题目都没看直接喂给模型，就完事儿了🫠服了
思南nan: 公司搞了一个ai挑战赛，第二关的任务是根据回答正确数+完成时间来排名。 但我其实很好奇，一个小时的三个任务，感觉就是比的顶配模型的能力，这里面能比出人的啥能力...
1 10
原来一直以为，数据分析师的工作里，产品埋点设计是最难被 AI 替代的部分之一。
就像研发可能会觉得，写代码可以让 AI 辅助，但架构设计很难完全交给 AI。因为架构设计不是简单堆代码，而是要理解业务目标、系统边界、模块关系、可扩展性和后续维护成本。
埋点设计其实也很像。它不是把 PRD 里的按钮和页面机械地整理成一张表，而是要理解：
这个功能真正想解决什么业务问题？
用户会经过哪些路径？
哪些状态变化会影响后续分析？
哪些事件需要新增，哪些应该复用历史？
哪些字段客户端拿不到，应该服务端上报或数仓落表？
哪些边界状态如果现在不记录，上线后就再也分析不出来？
所以我一开始并不觉得 AI 很适合做这件事。
我最初的尝试也确实失败了。
当时我直接把 PRD 和历史埋点文档一起发给 AI，让它按照原有格式生成一份新的埋点文档。结果生成出来的东西看上去很完整，但实际质量并不高，需要人工修改的部分非常多，甚至还不如自己从头设计。
后来我意识到，问题不是 AI 不能参与埋点设计，而是我把一个“需要设计过程的任务”，当成了“一次性生成任务”。
就像用 AI 做研发，不能直接说“帮我开发一个功能”，而是要先有需求理解、产品方案、架构拆解，再进入开发和 code review。
埋点设计也是一样。
不能一上来就让 AI 生成最终埋点表，而是要把它拆成一个稳定流程：
第一步，不生成埋点，先让 AI 结构化理解 PRD：功能目标、用户角色、页面入口、主路径、分支路径、异常路径、状态变化、数据分析目标。
第二步，让 AI 拆用户路径和状态流转：每一步是页面曝光、点击、弹窗、状态变化，还是服务端结果？如果不埋点，后续会缺失什么分析能力？
第三步，路径清楚后，再让 AI 生成事件和参数：事件名、触发时机、上报端、参数含义、枚举值、是否必填、设计原因。
第四步，让 AI 反向做 review：有没有历史事件可以复用？有没有参数冗余？有没有研发不可实现或测试不可验收的问题？
第五步，把人工反馈再喂回去，让 AI 二次迭代，最后输出埋点平台格式、研发注意事项和测试 checklist。
这样之后，AI 的角色就变了。
它不是直接替我“拍脑袋设计埋点”，而是变成了一个协作对象：拆结构，生成初稿，检查风险，最后根据人工反馈收敛方案。
这件事给我最大的启发是：
很多我们以为 AI 做不好的工作，可能不是因为它真的不能做，而是因为我们没有把专家经验拆成 AI 能执行的中间步骤。
如果只给 AI 一个终点，它很容易生成一个“看起来像答案”的东西。
但如果把任务拆成需求理解、路径拆解、方案生成、质量校验、反馈迭代，它就有机会参与真正的工作流。
所以我现在越来越觉得，AI 最值得落地的地方，未必是那些最简单、最重复的工作。
反而是那些过去高度依赖经验、又可以被拆成稳定流程的灰色地带，就像埋点设计。
这个自动化做好了之后，现在埋点设计助手设计埋点的时间，远小于我理解完prd review它设计合理性的时间🫠
就像研发可能会觉得，写代码可以让 AI 辅助，但架构设计很难完全交给 AI。因为架构设计不是简单堆代码，而是要理解业务目标、系统边界、模块关系、可扩展性和后续维护成本。
埋点设计其实也很像。它不是把 PRD 里的按钮和页面机械地整理成一张表，而是要理解：
这个功能真正想解决什么业务问题？
用户会经过哪些路径？
哪些状态变化会影响后续分析？
哪些事件需要新增，哪些应该复用历史？
哪些字段客户端拿不到，应该服务端上报或数仓落表？
哪些边界状态如果现在不记录，上线后就再也分析不出来？
所以我一开始并不觉得 AI 很适合做这件事。
我最初的尝试也确实失败了。
当时我直接把 PRD 和历史埋点文档一起发给 AI，让它按照原有格式生成一份新的埋点文档。结果生成出来的东西看上去很完整，但实际质量并不高，需要人工修改的部分非常多，甚至还不如自己从头设计。
后来我意识到，问题不是 AI 不能参与埋点设计，而是我把一个“需要设计过程的任务”，当成了“一次性生成任务”。
就像用 AI 做研发，不能直接说“帮我开发一个功能”，而是要先有需求理解、产品方案、架构拆解，再进入开发和 code review。
埋点设计也是一样。
不能一上来就让 AI 生成最终埋点表，而是要把它拆成一个稳定流程：
第一步，不生成埋点，先让 AI 结构化理解 PRD：功能目标、用户角色、页面入口、主路径、分支路径、异常路径、状态变化、数据分析目标。
第二步，让 AI 拆用户路径和状态流转：每一步是页面曝光、点击、弹窗、状态变化，还是服务端结果？如果不埋点，后续会缺失什么分析能力？
第三步，路径清楚后，再让 AI 生成事件和参数：事件名、触发时机、上报端、参数含义、枚举值、是否必填、设计原因。
第四步，让 AI 反向做 review：有没有历史事件可以复用？有没有参数冗余？有没有研发不可实现或测试不可验收的问题？
第五步，把人工反馈再喂回去，让 AI 二次迭代，最后输出埋点平台格式、研发注意事项和测试 checklist。
这样之后，AI 的角色就变了。
它不是直接替我“拍脑袋设计埋点”，而是变成了一个协作对象：拆结构，生成初稿，检查风险，最后根据人工反馈收敛方案。
这件事给我最大的启发是：
很多我们以为 AI 做不好的工作，可能不是因为它真的不能做，而是因为我们没有把专家经验拆成 AI 能执行的中间步骤。
如果只给 AI 一个终点，它很容易生成一个“看起来像答案”的东西。
但如果把任务拆成需求理解、路径拆解、方案生成、质量校验、反馈迭代，它就有机会参与真正的工作流。
所以我现在越来越觉得，AI 最值得落地的地方，未必是那些最简单、最重复的工作。
反而是那些过去高度依赖经验、又可以被拆成稳定流程的灰色地带，就像埋点设计。
这个自动化做好了之后，现在埋点设计助手设计埋点的时间，远小于我理解完prd review它设计合理性的时间🫠
37 414
今天再说我经常用的第二个ai工作流，是个只有跨语言跨国团队才会遇到的痛点：翻译报告。
翻译报告听上去很简单，但在科技公司这种短平快的项目组里，最痛苦的地方不是翻译，而是chatbot 能帮你翻一句话，却接不住一整套真实办公流。
比如经常会遇到的几个问题：
1. 丢给chatbot翻译后x文档格式乱掉，尤其是表格要手动重排；
2. 专业术语每次翻得不一样，留存、环比、活动口径，特别是一些活动名词一会儿一个说法，只看日语就会发现，两份翻译好的文档对照看会让人非常费解；
3. 中文原文改了之后，日语版本经常忘记同步更新；
4. 多次翻译后风格漂移，两次报告重新翻译，结果必然不同，增加日本同事的核对难度。
光是翻译就比写报告还磨人，所以我手搓了一个本地命令行翻译管线，不追求做一个“万能翻译产品”，只解决报告本地化里最耗人力、又每天都会发生的三件事。
第一，术语口径统一。
维护一份「中文,日本語」术语表，把它当成唯一权威。每次翻译前都强制套用这份术语表，避免同一个业务词这次被翻成平假名，下次又变成片假名，或者同一个指标在不同报告里出现不同说法。
第二，格式原样保留。
不是直接翻译整份文档，而是按文件结构逐段、逐单元格翻译。只改文字，原位写回。标题、表格结构、Excel 公式都尽量不动。
这一步其实就是把 chatbot 擅长的“语言能力”，嵌进文档处理流程里，而不是让模型重新生成一份不可控的新文档。
第三，改动后只翻变化部分。
给每段原文存一份翻译记忆。下次原文改了之后重跑，不是整份报告重新翻译，而是通过缓存和 diff 判断：没变的段落直接复用，新增和变动的段落才重新翻。
这样既快，也能减少同一段内容多次翻译后风格漂移的问题。
一句话总结就是：
把“每次都要手动重来的翻译”，“再翻一遍这份报告”变成“术语交给配置文件，格式自动保住，重跑只动改过的地方”。
当然现在还有很多粗糙的地方。
最大的问题还是卡在接口上。钉钉文档虽然有 OpenAPI，但需要企业应用和管理员权限。所以目前还是一个手动闭环：从钉钉下载 docx，本地跑一条命令，再把结果导回钉钉。
以及缺少一个真正理想的状态：原文一改，译文自动跟着更新。这个下一步得接 API 写回。
技术上其实很糙，术语表、拆分粒度、格式保留都还有很多可以继续打磨的地方。
但我觉得真正值得复用的不是这点代码，而是这个思路：
把翻译当代码来管。
术语 = 配置文件；
翻译记忆 = 缓存 + diff；
格式保留 = 只改文本、不重建文档；
AI = 被嵌进流程里的语言能力，而不是一个需要反复复制粘贴的聊天窗口。
这也是我最近越来越强烈的感受：很多工作不是 chatbot 不能做，而是不能只停留在“把内容发给 chatbot”。
真正提效的部分，往往发生在更工程化的一层：
把 AI 接进原来的文件、格式、缓存、规则和版本变化里。
说到底还是那句：
重复的脏活交给 AI，人把时间留给分析和判断。
翻译报告听上去很简单，但在科技公司这种短平快的项目组里，最痛苦的地方不是翻译，而是chatbot 能帮你翻一句话，却接不住一整套真实办公流。
比如经常会遇到的几个问题：
1. 丢给chatbot翻译后x文档格式乱掉，尤其是表格要手动重排；
2. 专业术语每次翻得不一样，留存、环比、活动口径，特别是一些活动名词一会儿一个说法，只看日语就会发现，两份翻译好的文档对照看会让人非常费解；
3. 中文原文改了之后，日语版本经常忘记同步更新；
4. 多次翻译后风格漂移，两次报告重新翻译，结果必然不同，增加日本同事的核对难度。
光是翻译就比写报告还磨人，所以我手搓了一个本地命令行翻译管线，不追求做一个“万能翻译产品”，只解决报告本地化里最耗人力、又每天都会发生的三件事。
第一，术语口径统一。
维护一份「中文,日本語」术语表，把它当成唯一权威。每次翻译前都强制套用这份术语表，避免同一个业务词这次被翻成平假名，下次又变成片假名，或者同一个指标在不同报告里出现不同说法。
第二，格式原样保留。
不是直接翻译整份文档，而是按文件结构逐段、逐单元格翻译。只改文字，原位写回。标题、表格结构、Excel 公式都尽量不动。
这一步其实就是把 chatbot 擅长的“语言能力”，嵌进文档处理流程里，而不是让模型重新生成一份不可控的新文档。
第三，改动后只翻变化部分。
给每段原文存一份翻译记忆。下次原文改了之后重跑，不是整份报告重新翻译，而是通过缓存和 diff 判断：没变的段落直接复用，新增和变动的段落才重新翻。
这样既快，也能减少同一段内容多次翻译后风格漂移的问题。
一句话总结就是：
把“每次都要手动重来的翻译”，“再翻一遍这份报告”变成“术语交给配置文件，格式自动保住，重跑只动改过的地方”。
当然现在还有很多粗糙的地方。
最大的问题还是卡在接口上。钉钉文档虽然有 OpenAPI，但需要企业应用和管理员权限。所以目前还是一个手动闭环：从钉钉下载 docx，本地跑一条命令，再把结果导回钉钉。
以及缺少一个真正理想的状态：原文一改，译文自动跟着更新。这个下一步得接 API 写回。
技术上其实很糙，术语表、拆分粒度、格式保留都还有很多可以继续打磨的地方。
但我觉得真正值得复用的不是这点代码，而是这个思路：
把翻译当代码来管。
术语 = 配置文件；
翻译记忆 = 缓存 + diff；
格式保留 = 只改文本、不重建文档；
AI = 被嵌进流程里的语言能力，而不是一个需要反复复制粘贴的聊天窗口。
这也是我最近越来越强烈的感受：很多工作不是 chatbot 不能做，而是不能只停留在“把内容发给 chatbot”。
真正提效的部分，往往发生在更工程化的一层：
把 AI 接进原来的文件、格式、缓存、规则和版本变化里。
说到底还是那句：
重复的脏活交给 AI，人把时间留给分析和判断。
3 31
每天被老板追问“大盘为什么波动”，但真的没时间每天手动拆一遍。
所以手搓了一个最小化 DAU 异动诊断看板 demo，只解决业务老板最常问、又要消耗人力的两个问题：
第一，今天 DAU 到底是哪里变了？
DAU 拆成三层：
DAU = DNU + 老用户 DAU
老用户 DAU = 留存 DAU + 回流 DAU
留存 DAU = 新增留存 DAU + 老用户留存 DAU
这样大盘一波动，拆清楚之后，老板至少能快速判断：今天该追问市场、产品、运营，还是先别急着追问任何人。
第二，这个波动到底值不值得追？
很多时候指标上下波动，并不代表业务真的出了问题，只是正常波动。
所以加了一个很朴素的判断方式：近 30 日均值+ 方差（当然也可以搞个预测来看差值），判断今天核心指标处在什么区间。
主要是为了回答一句话：“今天这个变化，是正常波动，还是值得立刻拉人看？”
比较遗憾的是，实现方式非常原始。
因为中台数仓不开放数据接口 API，没法真正自动拉数。现在只能每天打开电脑，让 Claude 在内网下载数据到本地 data.json，再更新本地 html。最后再通过每日定时提醒使用者授权更新数据。
半天时间做出来，技术实现很粗糙，指标还可以继续拆分，但我觉得这里面真正值得复用的还是 mvp 这个思路：
把老板每天最焦虑的问题，压缩成一个最小可用的判断链路，例如我们就是从“今天 DAU 怎么了？”，变成：是哪一层指标在变？这个变化是否超出正常波动？如果要追，应该先追哪个业务方？
工作起来还是要靠 ai 解放分析师。
所以手搓了一个最小化 DAU 异动诊断看板 demo，只解决业务老板最常问、又要消耗人力的两个问题：
第一，今天 DAU 到底是哪里变了？
DAU 拆成三层：
DAU = DNU + 老用户 DAU
老用户 DAU = 留存 DAU + 回流 DAU
留存 DAU = 新增留存 DAU + 老用户留存 DAU
这样大盘一波动，拆清楚之后，老板至少能快速判断：今天该追问市场、产品、运营，还是先别急着追问任何人。
第二，这个波动到底值不值得追？
很多时候指标上下波动，并不代表业务真的出了问题，只是正常波动。
所以加了一个很朴素的判断方式：近 30 日均值+ 方差（当然也可以搞个预测来看差值），判断今天核心指标处在什么区间。
主要是为了回答一句话：“今天这个变化，是正常波动，还是值得立刻拉人看？”
比较遗憾的是，实现方式非常原始。
因为中台数仓不开放数据接口 API，没法真正自动拉数。现在只能每天打开电脑，让 Claude 在内网下载数据到本地 data.json，再更新本地 html。最后再通过每日定时提醒使用者授权更新数据。
半天时间做出来，技术实现很粗糙，指标还可以继续拆分，但我觉得这里面真正值得复用的还是 mvp 这个思路：
把老板每天最焦虑的问题，压缩成一个最小可用的判断链路，例如我们就是从“今天 DAU 怎么了？”，变成：是哪一层指标在变？这个变化是否超出正常波动？如果要追，应该先追哪个业务方？
工作起来还是要靠 ai 解放分析师。
11 47