先说结论：周报的产出是决策，不是数字
从 9 月 21 日起，我们给自己的官网运营写周报，每周一期，到 11 月 2 日连续写了 7 期。上周把这 7 期翻回去盘账，盘的不是「抓出了几个问题」，而是另一个更硬的问题：这 7 期里，有多少期的结论真实改变了下一周的动作？
答案是有，而且比「修了几个 bug」值钱得多：选题方向被数据改写了 2 次、统计口径定型 1 次、根因定位与止损 1 次、验收标准制度化 1 次。同时也盘出一条不体面的时间线——最大的问题从被发现到真正生效，拖了 21 天，中间烂在「已修」的错觉里整整一周。
本篇结论一句话：周报的产出不是数字、也不只是修复，是「改变了下周动作的决策」。衡量一份周报只看一条：这期的结论，有没有让下一周少做什么、多做做什么。数字是证据，修复是副产品，动作改变才是产出。
统计边界先交代：这是单站、7 期、小流量的自我复盘，每周外部真人只有两位数，我们不把自家的经验外推成行业规律；但每一条「决策被改变」的记录都有当期周报可查、可复算，这是本篇能给读者的部分。全文 4 分钟。
决策账本：7 期周报改掉了什么
先把产出摆在一张表里，全部来自当期周报原文，每一行都能回答「如果没写周报，这件事会不会发生」：
| 期次 | 数据发现 | 改变的决策 |
|---|---|---|
| 09-21（第 1 期） | 自测漏斗 96% 断崖；埋点未修 | 先修埋点再谈增长；动手改首页入口 |
| 09-28（第 2 期） | 外部真人行为只集中在产品实测区，内容页 71% 看一眼就走 | 选题弃「泛方法论」转「产品实测」 |
| 10-05（第 3 期） | 自家流量占 54/97 = 56%；新落地页零转化埋点 | 三档统计口径定型（全量→剔程序→剔自家）；转化埋点制度化 |
| 10-12（第 4 期） | Demo 线索落库异常 | 48 小时查清链路 + 补兜底（预警，未及时闭环） |
| 10-26（第 6 期） | 线索被静默吞 12 天，根因定位到代码行 | 修复三件套；跟进 2 位真实客户；Demo 额度 1→3 |
| 11-02（第 7 期） | 上周的修复「改完未生效」；复核表连续两周全红 | 「重启+探活+兜底表见行」定为修复验收标准；拉起服务加自启看门狗 |
注意 10-19（第 5 期）没进表——那期的建议多数没有落地，这就是周报的另一半真相：写了不等于做了。所以第 7 期的复核表才会「连续两周全红」，也是它逼出了本篇最重要的教训（见 s4）。
改打法：选题方向被数据改写了两次
决策账本里最值钱的一类，是打法级的改动。我们自己的选题方向就被数据改写过两次：
第一次，09-28 期。当期数据显示：外部真人仅有的真实行为集中在 AI 应用中心（登录成功 5 次、问数跳转 3 次，2 个人走通了登录→问数全程），而内容页 71% 的访客看一眼就走、搜索来源只有 3 人。当期的结论很直白：继续产泛行业方法论是「用内容赌搜索」，写产品实测是「接住现有的真实兴趣」。选题方向就此从方法论转向实测。两个人、7 次行为，样本小到不值一提——但它是当时唯一「真人用脚投票」的证据，比任何选题灵感都硬。
第二次，10 月下旬。盘近期文章时发现复盘类题材反复在讲同一组判断（埋点、分发、转化断点），自我重复。决策：把这组判断列入选题禁区，内容确立四类轮转（行业观察→方法论→政策解读→实测复盘），并定下三条写作纪律：结论前置、一屏给数字、每篇只讲一个判断。
这两次的共同点是：选题决策的依据从「作者的兴趣」换成了「读者的真实行为」。而这个证据只有一个来源——每周把行为数据摊开看。灵感不能复盘，行为数据可以。
最贵的一课：发现≠修复，修复≠生效
现在讲那条不体面的时间线。它是 7 期周报里最贵的产出，因为每一周的延迟都是真金白银的线索：
| 时间 | 发生了什么 | 间隔 |
|---|---|---|
| 10-08 | 域名迁移，埋雷：线索转发代码仍指向旧域名 | — |
| 10-11 起 | 线索开始 100% 静默丢失（301 把 POST 降级 GET，异常被 except: pass 吞掉，页面仍显示提交成功） | — |
| 10-12 | 第 4 期周报预警「落库异常，48 小时查清」 | 发现→定位：2 周 |
| 10-26 | 第 6 期两表对账，定位到具体代码行 | |
| 10-26~28 | 修复完成：改域名、去静默吞、加兜底表和双通道通知 | — |
| 11-02 | 第 7 期复核发现「改完未生效」——服务宕机，修复代码从未运行；同周拉起服务，真实浏览器三层证据闭环 | 修复→生效：1 周 |
从线索开始丢失到链路真正恢复，21 天。拆开看，浪费不是发生在「不知道」的阶段——10-12 就预警了——而是发生在两个错觉里：第一个错觉是「预警了迟早会修」（拖了 2 周），第二个更危险：10-28 代码改完，所有人都以为问题解决了，实际修复代码在宕机的服务里躺了一周，一行都没跑过。
第 7 期由此立了新规矩：修复的验收标准不是「代码改完」，而是「重启 + 打静态资源探活 + 兜底表见行」；每期周报开头先复核上期待办，未生效不销账。「改完未生效」比「没做」更毒——它会让后面所有判断建立在错误前提上。这句话已经写进了我们的交付流程，也写在这篇复盘里。
证据层：决策的前提是数字可信
决策账本里每一条「改变」都依赖数字，所以还有一层必须交代：数字本身也被周报纠过错。
10-05 期发现自家办公流量占当周事件 56%（54/97）——不剔除，「外部访客」虚高近一倍，所有漏斗结论作废。由此定型三档口径：全量 → 剔程序流量 → 剔自家流量，分析一律用第三档。后来又补了爬虫这一课：会执行页面脚本的浏览器级爬虫会以访客身份入库，近 7 天曾占到事件的三分之一以上，剔除名单按月对账更新。再往前，还修过「凌晨点击」的假象——容器日志是 UTC 时区，不换算就把上午的集中点击读成凌晨，顺着错误时间去查「用户为什么半夜点链接」，结论全是鬼故事。
这一层的定位要说清楚：口径修复不是周报的目的，是周报的地基。决策层的错误可以用下一期追回来，证据层的错误会让每一期的决策都建立在错分母上。我们的做法是把口径检查做成周报的固定动作：三档口径、剔除名单、时区换算，每周取数前过一遍——地基每周对一次账，决策才有资格谈方向。
模板：把周报写成「结论→动作→验收」
7 期迭代下来，周报结构收敛成三段，报数压缩到最短：
| 段 | 内容 | 纪律 |
|---|---|---|
| 结论 | 本周最重要的一件事 + 打法是否有效的判断 | 判断必须带数据依据，写不出依据的降级为观察 |
| 动作 | 下周做什么 / 停什么 / 加倍什么，标优先级 | 必须是可检验的动作，「持续关注」不许上表 |
| 验收 | 逐条复核上期动作的落地状态 | 未生效不销账，全红也要原样公开 |
两条执行纪律：一是每期至少产出一个改变动作的决策——没有新发现时，就复核一次口径或宣判一个打法无效，只报数不复盘的周报等于没写；二是数据好的沉淀为固定打法，数据差的给出实验假设，下一期验证。回头看，7 期里真正值钱的，就是账本里那 2 次改写、1 次定型、1 次止损和 1 条 21 天的时间线。
微信内识别二维码分享此文
