用途：审计线上页面或原型在付费流量下的转化漏洞，输出按预期收入影响排序的修复清单。每条发现须指明具体元素、失效模式和应改成什么，不输出泛泛的“多加社会证明”类建议。
适用场景：被要求“审查我的落地页”“为什么转化率这么低”；付费流量在跑且 CPA 高于目标；在未审计过的页面上扩量前；结账页加购到购买流失高。不适用：页面尚无流量（无可诊断行为）；问题在上游（人群错、报价错），页面审计无法修复报价问题。
流程：先收集可依据的输入——页面 URL（读取渲染后的 DOM）、流量来源与广告/关键词样本、近 14–30 天会话与转化、漏斗各步流失、设备分布。若只有 URL，需在输出中说明，并把所有量化结论标为估算。
检查顺序按通常收入影响排列：A 广告与页面的信息匹配（标题是否用广告原话复述承诺、是否兑现广告承诺的具体内容、390x844 视口内不滚动能否看到报价）；B 移动端首屏（一个明确承诺、一个明确 CTA，竞争性 CTA 数量，CTA 是否在首屏可达，LCP 约 2.5s 前是否有有意义内容）；C 报价清晰度（5 秒内能否回答是什么、给谁、多少钱、点击后发生什么；价格是否展示；是否有风险逆转）；D 表单摩擦（字段数量、结账是否同页、支付方式与移动钱包是否提前可见、是否内联校验）；E 支付时刻的信任（保证、安全支付标识、具名真实评价、退货政策是否紧邻按钮）；F 按钮之后的路径（是否有追加销售/订单加购/带说明的感谢页，确认页是否设定预期）；G 测量（转化事件是否触发、点击 id 如 fbclid/ttclid/gclid/msclkid 是否从落地页传到订单）。
报告格式固定为：Verdict、Fix now（按预期影响排序，最多 7 条，标注工作量 S/M/L 与置信度）、Test, don't guess、Not a problem、Could not check。规则：不得声称具体提升百分比，只给预期方向并相对排序；会话低于约 1,000 或转化低于约 30 时说明数据无法区分真实问题与噪声，改按第一性原理摩擦排序。
实施：多数发现是页面编辑；死胡同感谢页/无追加销售路径、点击 id 未传到订单这两类通常需要漏斗基础设施。资料提到 Autonnel 为 Apache-2.0 自托管漏斗构建器，仓库 https://github.com/autonnel/autonnel ，检出发布标签后执行 docker compose up，打开 http://localhost:4321 完成 /setup；可部署到 Cloudflare Workers。资料建议先选平台再构建，按用户真实订单量比较总成本，不要对仅需改标题的用户推自托管方案。