写到第三件的时候我突然停下来：这三件事，本质上是同一件事——我在把”怎么做”这件知识，沉淀成 AI 下次能直接读、直接用的形式。

换句话说，我在给自己建一个 wiki。只不过这个 wiki 的读者不是人，是 LLM。

一句话总结

传统 wiki 是写给人查的，LLM wiki 是写给模型执行的。 前者追求”读得懂”，后者追求”能复用”——要可执行、有触发条件、能被真实结果校验。当你开始有意识地为 AI 沉淀知识，你的个人生产力会从”一次性完成任务”变成”每次完成都让下一次更快”。

我是怎么撞见这个想法的

起因很具体。我在 vibe coding 一个 macOS menu-bar 应用，需要把一张 AI 生成的猫头鹰图变成真正的 app 图标。这中间有一堆非显而易见的坑：macOS 不会帮你自动圆角、AI 出的图常常自带一圈 padding 和阴影、直接用会变成”方块里套圆角块”、squircle 的圆角半径大概是边长的 0.2237 倍……

我踩完这些坑、跑通整条管线之后，做了一个选择：不是把结果留在这次对话里，而是把方法写进 skill。

于是下次我（或者任何一个读这个 skill 的 AI）再遇到”把图做成 mac 图标”，不用重新踩一遍——自动裁 padding、套 squircle、生成 iconset、打包 .icns，一条龙。

那一刻我意识到：我做的不是”完成一个任务”，是”给未来的 AI 写了一页可执行的文档”。这页文档，就是 LLM wiki 的一条词条。

LLM wiki 的三种载体

我目前的知识沉淀，落在三个地方，各有分工：

CLAUDE.md 是常驻规则。 它每次都进上下文，所以只放最高优先级、最稳定的东西：比如”博客每篇至少 3 张插图””性能规则不能回退””发布流程怎么走”。它贵，所以要克制——不该把操作细节全塞进来。

skill 是按需加载的操作手册。 它平时不占上下文，只有当任务命中触发词（”做 mac 应用图标”、”.icns”）才被拉进来。这意味着 skill 可以写得很详细、很长，因为它不是常驻成本。我那条 macOS 图标管线就适合放这儿。

博客是给人也给 AI 的深度页。 它存的是”为什么这么做”的判断，而不只是”怎么做”的步骤。而且它是公开的——别人的 AI 也能检索到、学到。这层是前两层的”公共版”。

LLM wiki 和传统 wiki 差在哪

关键区别只有一个：读者变了。

传统 wiki 写给人，人会脑补、会容错、会举一反三。所以传统文档可以模糊——“把图标处理一下”，人能懂。

LLM wiki 写给模型，你得假设读者不会脑补、只会照做。所以三条硬要求：

1. 可执行，不是描述。 别写”记得处理透明背景”，直接给能跑的脚本 + 参数 + 兜底分支。我那条图标 skill 里直接嵌了一段 Python，模型抽出来就能运行。
2. 有触发条件。 人会自己判断该翻哪一页；模型需要你明确写”什么时候用我”。skill 的 description 和触发词就是干这个的——写不好，该被加载时它不出现。
3. 能被 ground truth 校验。 这是我今天最深的一课。

最痛的一课：不要相信”我以为做了”

今天我在提交一个 skill 改动时，中间的工具输出显示”已提交、已推送”，我就信了、往下走了。后来用 git rev-parse HEAD 和 git show 一核对——根本没提交成功，那几步是我基于未经核验的中间状态脑补出来的。

这件事放在 LLM wiki 的语境里特别有意思：模型（包括我这个 AI）会基于”我以为的状态”往前跑，而不是”真实的状态”。 所以一条好的 LLM wiki 词条，必须内建”用真值校验”这一步。

我后来把这条也固化了：涉及提交推送，一律以 git rev-parse、git status、git show 的真实输出为准，绝不用中间回显下结论。这就是一条为 AI 写的”自我校验规则”。

传统 wiki 不需要教人”提交完要确认真的提交了”——人有直觉。但给 AI 写的 wiki 需要，因为模型的失败模式和人不一样：它不是不会，是会一本正经地跑偏。

怎么让沉淀真的被复用

沉淀不等于复用。我踩过的坑：

• 写了没触发词 = 白写。 skill 描述里不写”mac 应用图标 / .icns”，下次问”帮我做个应用图标”时它根本不会被加载。触发词是 LLM wiki 的”索引”。
• 写太细放错层 = 变负担。 把一次性的操作细节塞进 CLAUDE.md，每次会话都要为它付上下文成本。分层很重要：常驻的极简、按需的详尽。
• 只存结果不存判断 = 不可迁移。 “这次用了方案 A”没价值；”因为 X 约束所以选 A、代价是 Y”才能迁移到下一个场景。这也是为什么博客这层不可替代——它存的是判断框架。

要不要这么干 / 我的判断框架

我越来越确信一件事：在 Agent / AI Infra 时代，超级个体的护城河不是”会用 AI”，而是有没有为 AI 持续建一个高质量的知识库。工具谁都能用，但你喂给它的上下文、你沉淀的判断框架，是别人复制不走的。

判断框架负责决定”做什么、不做什么、底线在哪”，AI 负责把执行力拉满。而 LLM wiki，就是把你的判断框架，翻译成 AI 每次都能读到的形式。

写到这我就明白了：这篇博客本身，也是我 LLM wiki 里的一页。它遵守我今天刚写进 CLAUDE.md 的规则——至少配 3 张插图。

挺自洽的，也挺酷的。

如果只看投放后台，很容易把它理解成「是不是受众太窄」「是不是预算没有花满」「是不是素材还可以优化」。这些都可能对，但第一步不是调后台，而是先做一遍反推。增长问题最后都要落到单位经济模型上，尤其是广告套利这种业务，数学先于手感。

一句话总结

100 元预算拿 2000 个成效，要求单次成效成本降到 0.05 元。 如果当前单次成本是 0.33 元，那就意味着还要再降 85%。这不是常规优化能稳定做到的目标。真正可执行的路径是：先扩受众让 100 元预算稳定花满，再在 0.33 元成本附近逐步放量到约 660 元/天。

先算目标单次成本

这个问题的第一行公式非常简单：

1
2

目标单次成效成本 = 总预算 / 目标成效数
100 / 2000 = 0.05 元

也就是说，如果一天只花 100 元，还要拿 2000 个落地页浏览或类似成效，每一次成效最多只能花 5 分钱。

再对比当前数据：

这里的关键判断是：0.33 元并不是一个明显偏高的落地页浏览成本。 在 Facebook 上跑冷流量，尤其是内容站、小说站这种非强交易场景，0.33 元已经属于相当低的区间。素材、受众、地域、设备、落地页速度都继续优化，当然可能还能降，但把长期稳定成本压到 0.05 元，不应该作为计划基线。

这不是「单次成本太高」的问题

很多人看到「2000 成效没达成」，第一反应是单次成效费用太高。但这句话要拆成两种情况。

第一种是真的高。比如目标是 0.3 元，当前跑到 2 元，那就是素材、受众、出价或落地页承诺不匹配，要从投放质量上修。

第二种是目标本身不现实。比如目标是 0.05 元，当前是 0.33 元，而且 0.33 元已经在低成本区间，那就不是「优化一下」能解决的问题。继续追 0.05 元，只会把团队带进错误动作：频繁换受众、频繁改预算、过早切换转化目标，最后学习期不断重置，成本反而上升。

我更愿意把它叫做 目标成本错配：预算目标、成效目标、市场真实成本不在同一个平面上。

为什么前面还会说「先扩受众」

在原始数据里还有一个信号：覆盖人数只有 939，展示 1019。这个量级太小了。

如果一个广告组一天只覆盖不到 1000 人，就算单次成本看起来不差，也不能直接判断它有放量能力。原因有三个：

1. 样本太小，CPC/LPV 容易被少量点击扰动。
2. 受众太窄，预算提高后频次会快速上升，CTR 下滑。
3. 算法探索空间不足，Facebook 没法找到更多相似人群。

所以「先扩受众」不是为了让 100 元直接变成 2000 成效，而是为了验证两件事：

扩受众的动作可以很直接：

这里的阶段目标不是「立刻 2000 成效」，而是「100 元预算能稳定花完，同时成本没有明显劣化」。

真正的预算应该是多少

如果当前单次成本是 0.33 元，目标是每天 2000 次成效，那预算反推是：

1
2

所需预算 = 目标成效数 * 当前单次成本
2000 * 0.33 = 660 元/天

所以答案很直接：要稳定拿 2000 成效/天，预算基线不是 100 元，而是约 660 元/天。

这不是说马上把预算从 100 拉到 660。Facebook 的学习期对预算变化很敏感，突然大幅加预算会让系统重新探索，成本可能被放大。更稳的方式是按 20%-30% 的步长放量：

每一步只看一个问题：成本有没有保持在可接受范围内。 如果从 0.33 元涨到 0.6 元甚至更高，就说明当前素材或受众承载不了这个预算，需要回头补素材、扩受众或拆广告组，而不是继续硬加。

对小说站投流尤其要克制

小说站这种 AdSense / AdX 变现场景，收入不是一次点击立刻发生，而是由后续阅读页数和广告 RPM 慢慢摊出来。简单写就是：

1
2

单次访问价值 = 平均阅读页数 * 页面 RPM / 1000
利润 = 单次访问价值 - CPC

这意味着 Facebook 端的 CPC 只是上半场。真正决定能不能套利的，还有两个站内指标：

如果站内阅读深度和 RPM 还没稳定，盲目追求低到不现实的 CPC，会让投放策略变形。比如为了便宜点击去投低质量受众，短期 CPC 降了，但用户进站 3 秒就走，最后广告收入更差。

所以我现在更关心的是三层漏斗：

便宜点击不是目标，便宜且会读的点击才是目标。

我的判断框架

以后遇到类似问题，我会按这个顺序判断。

第一步，先算目标成本。

1

目标单次成本 = 预算 / 目标成效

如果目标成本低到明显脱离市场区间，先改目标，不要急着改广告。

第二步，看当前成本是不是异常。

1

当前成本 / 目标成本 = 需要优化的倍数

如果只差 20%-30%，素材和受众优化可能有效。如果差 80% 以上，就要高度怀疑目标不现实。

第三步，看预算有没有花满。

预算花不满，优先扩受众、放宽地域、检查审核和出价。预算能花满但成本上升，说明放量承载能力不足。

第四步，再决定是降本还是加预算。

1

目标预算 = 目标成效 * 可稳定维持的单次成本

用稳定成本反推预算，而不是用愿望预算反推不现实的成本。

要不要用 / 我的判断框架

这次结论很明确：

我的最终判断是：当前任务不是把 0.33 元硬压到 0.05 元，而是验证 0.33 元能否在更大受众池里稳定复现。 复现成功，再用预算换量；复现失败，再回头修素材、落地页和读者质量。增长不是许愿，先把单位经济模型算清楚，后面的动作才不会跑偏。

直觉上觉得应该不排，覆盖更多用户嘛。但实际想清楚之后，我做了一个反直觉的决定：只投 Android，最低 Android 9，iOS 暂时全排除。

这个决策背后有技术原因，不是玄学。

一句话总结

iOS 14.5+ 的 ATT 政策让 Meta Pixel 无法回传事件，广告系列的优化方向会跑偏；在没有 CAPI（Conversions API）的情况下，投 iOS 等于把预算喂给算法噪音。

iOS 信号丢失：不只是归因问题

先讲技术机制。

iOS 14.5 之后 Apple 推出了 ATT（App Tracking Transparency），要求所有应用在追踪用户行为前必须显式获得授权。绝大多数用户选择「不允许追踪」。

这对 Meta Pixel 的影响是致命的：

1. 用户在 FB 上看到广告，点击进入小说站
2. 小说站的 Pixel 代码触发 ViewContent 事件，准备回传给 FB
3. iOS 系统层面直接拦截，事件永远到不了 Meta 服务器

结果是：FB 的广告系列认为这批 iOS 用户点了广告之后「什么都没发生」。算法会把这批流量标记为低质量，调整投放方向——但这个调整方向是错的，因为信息本身就是残缺的。

更严重的问题是：这不只是归因断裂，而是优化方向整体跑偏。

你以为广告系列在学习「哪些人喜欢看小说」，实际上它在学习「哪些 Android 用户点击了广告」（因为 Android 的 Pixel 信号是完整的）混合「哪些 iOS 用户不知道为什么点了」（信号丢失的噪音）。两个群体混在一起喂给算法，学习效率会被拉低。

为什么选 Android 9 作为最低版本

排除 iOS 之后，还需要设一个 Android 的最低系统版本。我选了 Android 9（Pie），原因很具体：

技术侧：我的小说站用 Next.js 静态导出，前端依赖了几个关键的现代 Web API：

• IntersectionObserver：AdSense 懒加载和 ChapterPixel 的章节完成检测都依赖这个 API，Android 8 以上才稳定支持
• CSS Grid / Gap / Aspect-ratio：Android 9 以上渲染稳定，Android 8 的 WebView 有已知 bug

运营侧：Android 8 发布于 2017 年，2026 年在用 Android 8 的用户基本是 5 年以上没换机的存量，购买力和活跃度都很低。排除掉这批人不影响核心受众覆盖，还能减少无效曝光。

实际覆盖：最低 Android 9 能覆盖 约 98% 的活跃 Android 用户。

只投 Android 对费用的影响

信号质量之外，设备选择还直接影响投放成本。

CPM（千次曝光成本）：iOS 广告主竞争密度更高，因为多数广告主默认认为 iOS 用户消费力强。实际测下来，仅投 Android 的 CPM 通常低 15–40%，同预算能买到更多曝光。

单次成效费用（CPR）：这个才是核心指标。CPR 低不只因为 CPM 低，更因为归因完整——算法清楚知道哪次点击带来了 ViewContent，出价越来越精准。iOS 混进来后，算法收到的是残缺信号，出价逻辑会变得保守且不稳定。

学习期：Facebook 广告系列需要积累 50 次转化事件才能脱离学习期。Android 信号完整，50 次的门槛更快达到；iOS 混进来后，部分转化事件丢失，学习期被拉长，预算在不确定状态下消耗更多。

什么时候 Android 反而更贵：如果落地页在 Android 低端机上加载慢（碎片化严重），跳出率高会把 CPR 拉上去。这也是为什么要设最低 Android 9——过滤低端慢机，间接保住落地页体验。

操作路径

在 FB 广告管理工具里，广告组层级配置：

1
2
3
4
5

广告组 → 版位 → 手动版位

设备类型：仅限移动设备
操作系统：仅限 Android（选移动设备后出现）
操作系统版本：最低 Android 9 / 最高：无

注意：这个设置在「手动版位」里，先切换到手动版位才能看到 OS 筛选项。「进阶赋能型版位（推荐）」模式下无法手动指定 OS。

什么时候回开 iOS

当前排除 iOS 是因为没有 CAPI，信号丢失没有补救手段。有两个条件满足任意一个，就可以考虑回开：

条件一：CAPI 上线。Conversions API 是服务端事件回传，绕过 iOS 的浏览器层拦截，直接从服务器把事件推给 Meta。上了 CAPI 之后，iOS 用户的 ViewContent 等核心事件可以正常回传，算法能重新学习这批用户。

实现门槛不低——静态站（Next.js output: ‘export’）没有运行中的 Node.js 服务器，需要额外部署一个 API 服务（Vercel Function / Cloudflare Worker / AWS Lambda 都可以）。当前日耗 <$50，性价比不足，等规模上来再搞。

条件二：GA4 数据证明 iOS 质量更高。接入 GA4 后，可以按操作系统分组看读者质量指标：人均阅读章节数、平均停留时长、跳出率。如果 iOS 用户这些指标显著优于 Android，那即使信号丢失，从流量质量角度也值得回开——只是归因会不准，但读者是真实的。

我的判断框架

当前我的判断：可以再等。先把 GA4 接进来，有了读者质量数据之后再决定 iOS 是否值得回开。

这个决策不是永久的，是阶段性的——在信号不完整的情况下，优先喂给算法干净的数据，比追求覆盖面更重要。

后来想清楚了，这是在做一件很蠢的事。

一句话总结

Facebook Pixel 事件分两层——转化事件（优化广告用）和参与度事件（诊断 + 建受众用）——用错层等于给算法喂错信号，Facebook 会去找”爱滚动”的人，不是”爱读小说”的人。

两层事件，本质是信号质量问题

先看 Facebook 优化目标是怎么工作的：

你在 Campaign 里设置”优化 ViewContent”，Facebook 就会把你的广告展示给最可能触发 ViewContent 的人。算法本质是在学习：哪些人口特征、行为特征的人，最容易产生这个事件。

所以核心问题是：你希望 Facebook 去找什么样的人？

这就是事件分层的本质——不同事件代表不同的用户行为，代表不同质量的人群信号。

AEM 的 8 个槽，是资源，不是垃圾桶

iOS 14+ 之后，苹果的隐私政策让大部分 iOS 用户的广告追踪失效。Facebook 的解决方案是 AEM（Aggregated Event Measurement）：你预先申报最多 8 个事件，按优先级排列，Facebook 用差分隐私的方式帮你归因。

关键：只有 8 个槽，而且优先级顺序决定归因逻辑——当一个 iOS 用户触发了多个事件，Facebook 只把转化归因给其中优先级最高的一个。

正确的 AEM 配置应该是：

1

ChapterCompleted (1) > ChapterRead50 (2) > ViewContent (3) > PageView (4)

ScrollDepth25、ScrollDepth75 不应该在这个队列里。原因：

1. 它们不是转化信号，是过程信号
2. 浪费宝贵的 AEM 槽位
3. 如果 ScrollDepth75 的优先级高于 ViewContent，iOS 用户触发了两个事件，归因会错误地落在 ScrollDepth75 而不是 ViewContent

ScrollDepth 有用，但用法不是”优化”

有用，但用法是数据诊断 + 受众分层，不是优化目标。三个具体用途：

1. 诊断广告质量

投一批广告 → 看落地章节的 ScrollDepth75 触发率：

• ScrollDepth75 率高 = 这批人真的在读 → 广告找对人了
• ScrollDepth75 率低但 ViewContent 高 = 人进来了但不读 → 广告文案/封面和内容不匹配

没有 ScrollDepth，你只知道”有人进来了”，不知道”有没有人在读”。这个区别决定了你该换素材还是换受众，解法完全不同。

2. 建高质量 Lookalike

1

ScrollDepth75 的人 → 建自定义受众 → Lookalike 1%

比用 PageView 或 ViewContent 建的 Lookalike 质量高得多——这批人是确认的真读者，Facebook 会去找特征相似的人，带来的也更可能是真读者。

3. 归因分析

对比 ScrollDepth25 vs ScrollDepth75 的转化漏斗：

1

100 人进章节 → 60 人到 25% → 30 人到 75%

留存率 50%，说明内容前段吸引力还行，后段掉人。这是内容问题，不是广告问题——没有 ScrollDepth 数据，这个判断很难做到。

简单说：ScrollDepth 是侦察兵，不是士兵。

它不直接打仗（优化 Campaign），但告诉你谁在认真读、广告找的人对不对、内容哪里在掉人。没有它，你做投流决策是靠猜的。

一个反直觉的坑：PageView 不是越多越好

初期容易有个误区：PageView 数量越多，数据越充分，广告就越精准。

实际上 PageView 的信号质量是最低的——包含了点进来 1 秒就关掉的人、误点广告的人、爬虫（如果 Pixel 没做过滤的话）。用 PageView 做优化目标，Facebook 学到的是”什么样的人最容易点广告”，而不是”什么样的人最容易读小说”。

PageView 的唯一价值是数据量积累——新账号冷启动阶段，用它帮 Facebook 快速建立人群基础，之后该切的时候要切。

当 ViewContent 积累到 500 次，就应该把 Campaign 优化目标从”落地页点击”切换到”ViewContent”。这一步是投流的质变节点。

我的判断框架

遇到一个新事件，用两个问题判断它的定位：

问题 1：这个事件代表的用户，是我真正想要找到的人吗？

• ChapterCompleted 的人 = 读完整章 = 是我想要的人 ✓
• ScrollDepth25 的人 = 滚了一点 = 不确定，太模糊 ✗

问题 2：如果 Facebook 去找更多”触发这个事件的人”，找来的人符合预期吗？

• 优化 ChapterRead50 → 找来的人更可能认真读小说 ✓
• 优化 ScrollDepth → 找来的人更可能”爱滚动”，不代表会读完 ✗

通过这两个问题的事件 → 放进转化层，可以用作 AEM 和优化目标。
不通过的事件 → 放进参与度层，用来建受众和做诊断。

具体到我们的小说站，最终实现的事件体系：

• 布置在 layout（全局）：PageView
• 布置在章节页 mount（进章节触发）：ViewContent
• 布置在章节页 scroll（读的过程触发）：ChapterRead50、ChapterCompleted、ScrollDepth25、ScrollDepth75

前两层进 AEM 配置和 Campaign 优化目标，后面的 scroll 事件全部留在参与度层做受众和诊断用。这个分层是当前最合理的实现，不过随着数据积累，ChapterCompleted 进 AEM 的时机还需要观察。

PageView 的语义是「有人来了」，而不是「有人读了」。Facebook 算法拿这个信号去优化，会找到「擅长点广告」的人群，而不是「愿意读小说」的人群。结果就是 CTR 看着不错，但用户进来翻一页就走，AdSense 会话 RPM 极低，ROAS（Return on Ad Spend，广告花费回报率 = 广告带来的收入 / 广告花费）算下来根本不打平。

一句话总结

在章节页实装 3 个 Pixel 事件：ViewContent（进入即触发）、ChapterRead50 和 ChapterCompleted（scroll depth 事件），让 Facebook 算法学会找「真正读完一章」的人，而不是「会点广告」的人。

为什么 PageView 是最差的优化信号

小说站的盈利公式：

1

Profit/visit = (会话 RPM × 翻页数/session) / 1000 − Facebook CPC

CPC 固定的情况下，唯一能拉高 ROAS 的是「翻页数/session」。而翻页数取决于用户是不是真的在读——这正是 PageView 衡量不到的。

Facebook 的优化逻辑是：给我 50 个「转化事件」的样本，我帮你找更多像这批人的用户。用 PageView 做样本，找到的是「会点广告的人」；用 ChapterCompleted（读完整章）做样本，找到的是「深度读者」。

Pixel 事件层级设计

我给章节页设计了 6 层事件，覆盖从「进来了」到「读完了」的完整漏斗：

为什么用 90% 而不是 100%？ 章节页底部有广告位、推荐书目、Share 栏。读完正文后用户视线就停了，不会继续滚到绝对底部。90% 才是实际的「读完」代理指标，100% 在现实中几乎永远不触发。

实现：ChapterPixel 组件

一个轻量的 client component，挂在 chapter page 里，用单个 passive scroll listener + useRef 防重复触发：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

'use client'
import { useEffect, useRef } from 'react'

interface Props {
  chapterTitle: string
  chapterOrder: number
  bookSlug: string
}

export default function ChapterPixel({ chapterTitle, chapterOrder, bookSlug }: Props) {
  const fired25 = useRef(false)
  const fired50 = useRef(false)
  const fired75 = useRef(false)
  const fired90 = useRef(false)

  useEffect(() => {
    const fbq = (window as Window & { fbq?: (...args: unknown[]) => void }).fbq
    // ViewContent 进入即触发 — 区分「进来了」和「立刻离开」
    fbq?.('track', 'ViewContent', {
      content_type: 'chapter',
      content_name: chapterTitle,
      content_ids: [`${bookSlug}-ch${chapterOrder}`],
    })

    const payload = { content_name: chapterTitle, chapter_order: chapterOrder }

    const onScroll = () => {
      const total = document.body.scrollHeight - window.innerHeight
      if (total <= 0) return
      const ratio = window.scrollY / total
      const fire = (window as Window & { fbq?: (...args: unknown[]) => void }).fbq

      if (!fired25.current && ratio >= 0.25) {
        fired25.current = true
        fire?.('trackCustom', 'ScrollDepth25', payload)
      }
      if (!fired50.current && ratio >= 0.5) {
        fired50.current = true
        fire?.('trackCustom', 'ChapterRead50', payload)
      }
      if (!fired75.current && ratio >= 0.75) {
        fired75.current = true
        fire?.('trackCustom', 'ScrollDepth75', payload)
      }
      if (!fired90.current && ratio >= 0.9) {
        fired90.current = true
        fire?.('trackCustom', 'ChapterCompleted', payload)
      }
    }

    window.addEventListener('scroll', onScroll, { passive: true })
    return () => window.removeEventListener('scroll', onScroll)
  }, [chapterTitle, chapterOrder, bookSlug])

  return null
}

chapter page 里直接挂上去：

1
2
3
4
5
6

// app/book/[slug]/chapter/[n]/page.tsx
<ChapterPixel
  chapterTitle={chapter.title}
  chapterOrder={chapter.order}
  bookSlug={slug}
/>

几个设计细节值得注意：

• useRef 防重复：scroll 事件高频触发，必须用 ref 确保每个深度只上报一次
• passive: true：不阻塞渲染线程，对 Core Web Vitals 无影响
• fbq optional chaining：Pixel 加载有延迟，防止脚本未就绪时报错
• ViewContent 在 mount 而非 scroll：「进入章节」本身就是有效的意图信号，不需要等到用户滚动

FB 后台还需要手动配置

代码侧搞定后，还有两步后台操作才能真正用上这些信号：

1. 创建自定义转化（ChapterRead50 / ChapterCompleted）

Events Manager → 自定义转化 → 新建，选择「自定义事件」→ 选对应事件名。PageView 和 ViewContent 是 Facebook 标准事件，不需要这步。

2. 配置 AEM（聚合事件衡量）

iOS 14+ 之后大部分 iOS 用户拒绝追踪，Facebook 的解法是「申报最多 8 个事件 + 优先级」，信号丢失时归因到优先级最高的可用事件。

路径：Events Manager → 你的 Pixel → 聚合事件衡量 → 配置网络事件

推荐优先级：

1

ChapterCompleted (1) > ChapterRead50 (2) > ViewContent (3) > PageView (4)

ScrollDepth25 和 ScrollDepth75 不加进 AEM——它们是漏斗分析用的，不是广告优化目标。AEM 只配置你真正用于 Campaign 优化的事件。

要不要做 / 我的判断框架

值得立刻做： 任何在跑 Facebook 流量的小说站都应该实装。几十行代码，对投流效果的影响是系统性的——算法找的人不一样，后续所有优化都站在更好的基础上。

可以再等： CAPI（Conversions API，服务端回传）。iOS 信号丢失严重时 CAPI 能补回 30%+ 的归因，但实现复杂（静态导出站需要额外部署 serverless function）。当前阶段流量体量不大，先把浏览器 Pixel 跑稳，等 ViewContent 积累到 500+ 再评估是否上 CAPI。

重点关注： ViewContent 积累到 500 次后，把 Campaign 优化目标从「落地页点击」切换为「ViewContent」，这是整个链路里 CPM 下降最明显的节点。

我以前的做法是忍着不问，或者开一个单独的 Claude 窗口。直到我发现了 /btw。

一句话总结

/btw = 不留痕的侧问（有上下文，无工具，答案不进历史）；f to fork = 把这个侧问升级成有完整工具的新主战场。

一、/btw 是什么

/btw 是 “by the way”（顺便问一句）的缩写，在 Claude Code v2.1.72（2026-03-10）引入。

它的核心设计哲学：快速提问，不污染历史。

执行 /btw 你的问题 之后，Claude 会在一个浮层面板里回答，这条问答不会作为 turn 添加到对话历史。主任务继续，上下文保持干净。

与 subagent 的镜像关系

官方文档有一句非常精准的描述：

/btw is the inverse of a subagent: it sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context.

二、结果面板：6 个键盘快捷键

/btw 的答案出现后，浮层面板支持以下操作：

三、c to copy：为什么不用鼠标选？

按 c 会把答案以原始 Markdown 格式复制到剪贴板。

这不是废话——终端渲染文本时会做”硬换行”（hard wrap），鼠标选中复制出来的是被截断的版本，粘贴到 Notion / Obsidian 之后格式全乱。

c 键直接拿的是 Claude 返回的源文本，代码块、标题、列表全部保留，粘贴即用。

四、f to fork：把侧问升级成主战场

这是整个 /btw 功能里最强的一个操作。

按 f 之后，Claude Code 会：

1. 把完整的主对话历史 + 这条 /btw 问答作为 transcript 继承
2. 在此基础上开一个新的独立 session
3. 新 session 有完整的工具访问权限（可以读文件、运行命令、编辑代码）
4. 原始 session 通过 /resume 可随时返回

典型工作流：

1
2
3
4
5
6
7
8
9
10

# 正在做大型重构，Claude 还在工作
/btw 这个 API 的响应格式对吗？

# Claude 回答：不对，应该是 { data: [], total: number }
# 你觉得需要深入修复，不想打断主任务

f    # Fork 成新 session，继承完整上下文 + 有工具
# 新 session 里：帮我修复这个 API 的响应格式

# 修完之后 /resume 回主任务

Fork vs Branch

五、与直接在主对话输入的区别

关键点：/btw 可以在 Claude 还在处理响应时插入，不需要等它完成。

六、5 个最有价值的实战场景

场景 1：长任务中途确认设计决策

Claude 正在做 30 分钟的大型重构，你突然想想起来一个细节：

1

/btw 我们之前说的是用 React Query 还是 SWR 管理数据缓存？

快速得到答案，主任务继续，历史不受影响。

场景 2：对话已很长，快速找回前面的信息

50+ turns 的长 session，需要确认一个早期决策：

1

/btw 我们在第几步决定不用 Redux 的？原因是什么？

成本低（命中 prompt cache），不会因为问这个让后续对话偏题。

场景 3：上下文检查，防止 Claude 跑偏

1

/btw 目前你对这个项目的技术栈理解是什么？列一下

用来”探针”Claude 当前的理解是否和你一致，不对就及时修正，而不是等出了 bug 再发现。

场景 4：侧问 + fork 的黄金组合

1
2
3
4
5

/btw 这个 SQL 查询有没有 N+1 问题？

# Claude 回答：有，在 getUserOrders 里
f
# 新 session 里处理这个问题，有完整文件访问权限

场景 5：多 subagent 并行时的状态检查

后台跑着几个 subagent，不想打断主对话：

1

/btw 目前正在运行的 subagent 有哪些任务？

七、配合个人工作流的实践建议

我目前在 fwork（飞猪 Cloud GUI Agent）开发中的用法：

• 任何”确认类”问题优先 /btw，而不是直接问——问完即走，不留污染
• 每隔 20-30 turns 用 /btw 你对当前任务状态的理解是什么 做一次”探针”
• 发现侧问答案值得深入时，立即 f fork，不要在主对话里展开
• 长对话结束前用 /btw 整理关键决策，再用 c 复制到 Obsidian 存档

要不要用 / 我的判断框架

现在就该用：

• 你经常在长 session 中途想问一个细节，但又担心影响后续上下文
• 你有”问完发现要深入处理”的场景，f + fork 是完美解法
• 你在跑多个 subagent，需要快速旁问而不中断主流

注意这些限制：

• /btw 没有工具——它不能帮你读文件、运行命令。只能基于已在上下文里的信息回答
• 如果问题本身需要 Claude 去查代码，还是得在主对话问（或者 fork 出去处理）
• ←/→ 切换历史侧问需要 v2.1.187+，旧版本没有

重点关注：

• f to fork 是 /btw 价值密度最高的功能，但大多数人不知道——记住这个键
• 复制答案永远用 c，不要鼠标选，格式更干净

排查了两天，发现根本问题是：我的关键行为事件没有喂给 Meta。读者翻了多少章、停留多久、是否完成了阅读——这些数据 Meta 完全不知道，自然没法找到”高价值读者”来投。

这让我认真研究了一遍 Events Manager。以下是我拆解后的完整认知。

一句话总结

Events Manager 是 Meta 广告的”数据大脑”——你告诉它用户做了什么，它帮你找更多做同样事情的人。

数据质量越高，算法学得越精准，广告效率越高。反过来，数据残缺或质量差，钱就烧在错误的人身上。

Events Manager 是什么

Meta Events Manager（事件管理工具）是 Meta Business Suite 下的一个模块，入口在 business.facebook.com/events_manager。

它做三件事：

1. 管理数据源：Pixel（网站追踪代码）和 Conversions API（服务端追踪接口）
2. 监控事件质量：帮你发现事件丢失、重复、匹配质量低等问题
3. 配置自定义转化：把原始事件组合成广告优化目标

你在这里配置好事件，投放时就能选”以 ViewContent 优化”或”以 Purchase 优化”——Meta 算法会去找最可能完成该行为的用户。

两条数据通路：Pixel vs Conversions API

这是 Events Manager 最核心的架构概念。

Pixel（浏览器端）

Pixel 是一段 JS 代码，运行在用户浏览器里。用户访问页面时，浏览器向 Meta 服务器发送事件请求。

1
2
3
4

fbq('track', 'ViewContent', {
  content_type: 'article',
  content_ids: ['chapter-5'],
});

优势：部署简单，实时触发，能捕捉页面行为。

劣势：

• 被广告拦截器屏蔽（iOS Safari、uBlock Origin 等）
• iOS 14+ ATT 隐私限制，匹配率下降
• 浏览器关闭后事件丢失

Conversions API（CAPI，服务端）

CAPI 是从你的服务器直接向 Meta API 发送事件，绕过浏览器限制。

1
2
3
4
5
6
7
8

// 服务端（Node.js 示例）
const serverEvent = new bizSdk.ServerEvent()
  .setEventName('Purchase')
  .setEventTime(Math.floor(Date.now() / 1000))
  .setUserData(userData)
  .setCustomData(customData);

new EventRequest(PIXEL_ID, [serverEvent]).execute();

优势：不受广告拦截、iOS 限制影响，数据更完整可靠。

劣势：需要后端开发；用户隐私数据需要哈希处理后发送。

最佳实践：两者并用 + 去重

Meta 官方建议 Pixel + CAPI 同时部署，同一个事件从两条通路都发送：

• 广告拦截器屏蔽了 Pixel？CAPI 兜底
• 服务端延迟高？Pixel 先到

但两条通路都发，意味着同一个事件 Meta 会收到两次，必须加 event_id 去重：

1
2
3
4
5

// Pixel 端
fbq('track', 'ViewContent', eventData, { eventID: 'chapter-5-view-1720051200' });

// CAPI 端（传同一个 event_id）
serverEvent.setEventId('chapter-5-view-1720051200');

Meta 看到同一 event_id 的两条记录，只计一次。

标准事件 vs 自定义转化

标准事件（Standard Events）

Meta 预定义的 17 个事件，算法天然理解其含义：

用标准事件的好处：Meta 算法直接懂你在优化什么，不需要额外学习。

对我的小说站，我这样映射：

• PageView — 所有页面
• ViewContent — 每个章节页
• Lead — 模拟”深度阅读”（翻了 3 章以上触发一次）

自定义转化（Custom Conversions）

当标准事件粒度不够时，自定义转化可以组合条件。

示例：想优化”读完第 5 章的用户”

在 Events Manager → Custom Conversions 里配置：

• 事件：ViewContent
• 条件：URL 包含 /chapters/ch-005

这样 Meta 会专门找”最可能读到第 5 章”的用户来投放，而不是泛泛地找”会浏览内容的人”。

自定义转化的本质是在标准事件上加筛选漏斗，让算法优化目标更精准。

Event Match Quality：决定你的钱烧得值不值

EMQ（事件匹配质量）是 Events Manager 里最容易忽视但最重要的指标，1–10 分制。

它衡量什么：Meta 能把多少比例的事件匹配回真实用户账号。

提高 EMQ 的核心手段：发送更多用户标识符（都需要 SHA-256 哈希后传）：

小说站的匿名访客没有邮箱，我的做法是至少传 IP + UA + fbp，EMQ 能维持在 5–7 分。如果有登录体系，传邮箱哈希能直接拉到 8 分以上。

Event Testing Tool：上线前必跑

入口：Events Manager → Data Sources → 选你的 Pixel → Test Events。

输入网页 URL，打开浏览器模拟用户行为，右侧会实时显示 Meta 收到的每个事件，包括：

• 事件名是否正确
• 参数是否完整
• 是否被去重
• 匹配到了哪些用户标识符

这是 Debug 神器。每次部署新事件，必须先在 Test Events 里验证，再推生产。

常见问题排查：

要不要用 / 我的判断框架

要不要上 CAPI？

自定义转化值得配吗？

当你的标准事件粒度不够精细，或者想区分”浅度访问”和”深度参与”时，自定义转化值得投入 15 分钟配置。成本极低，收益是算法优化目标的精度。

EMQ 多少够用？

5 分以上可以跑，7 分以上才算健康。低于 5 先排查是不是 IP/UA 没传，再考虑引入登录体系收集邮箱哈希。

Events Manager 本质上是 Meta 算法的”喂料接口”。数据喂得越准、越完整，算法的学习曲线越陡，广告效率越高。作为开发者，这是我们能直接控制的少数几个广告变量之一，值得认真对待。