🚦 快速筛选漏斗（代码级 · 从 SSOT 自动生成）

一条线索进来，按"最便宜的先筛"逐道过，全是便宜/快的信号；只有活下来的才进昂贵的详细审计。 此表从 core/leads/fast-filter.js（唯一真相源）直接渲染，不会和代码走偏。✅在用 · 🔄待前置(便宜但还没接进快筛) · 🔭观察。

━━━ 昂贵分界线 ━━━

• enqueueDetailedAudit → 此线之后: Playwright 全渲染 · Lighthouse · 视觉LLM · 39 规则详细审计 · 表单测试 · 全站爬 — 都贵，不在快速筛选里

仅作证据（不当门）：域名年龄 (WHOIS/Wayback · 老站=更可能想重做)

代码位置：1.core/leads/cheap-audit-queue.js · 2.core/scoring/cheap-audit-v2.js · 3.core/leads/exclusion-filter.js · 4.core/leads/cheap-audit-queue.js · 5.core/extractors/tinyfish.js · 6.core/scoring/site-quick-scan.js · 7.core/leads/cheap-audit-queue.js · 8.core/audit/pagespeed-insights.js · 9.core/scoring/cheap-audit-v2.js · 10.core/leads/exclusion-filter.js

Roofer 业务流程 6 阶段推进目标

2026-06-03。当前只考虑 roofer niche。目标不是手工做业务，而是把 lead 从进入系统到 Design / 建站可开工这条流程理顺、跑通、清掉冲突。

总目标

把 roofer lead 做成一条可重复的流水线：

发现客户
→ 判断入口是否已有可信官网 / Google Place / 基础身份
→ 有官网/Place：先便宜快速筛选
→ 无官网/Place：先搜索确认身份，找到官网再合流，找不到官网但是真公司就走无网站 starter
→ 分层采集和 audit
→ master.md 总档案
→ 销售资料 + Design / 建站资料包

这条线的硬原则：

• 只做 roofer。其他 niche 的旧资料、旧流程、旧文档要么归档，要么明确标成暂停。
• 所有 lead 进入系统后，都应该有 master.md。它是总档案，不是网站本身。
• 资料先进 master.md 分层保存，再从里面抽销售资料、audit report、Design / 建站资料包。
• 免费、快、低风险的检查先跑；贵的 API、深度 audit、完整抓取只给更值得的客户。
• 搜索不是固定早期或后期：入口没官网时，搜索是第一步；入口已有官网/Place 时，搜索主要是后期补背景。
• 搜索结果来源可以很宽：目录页、论坛、报价平台、评价站、社媒都能用。关键不是来源类型，而是它是不是同一个客户。
• 能给 Design 当事实的内容，必须来自更强证据；AI 只看标题和摘要判断出来的资料只能先做候选来源或销售参考。

双入口主线 · 2026-06-03 锁定

这个锁定解决一个旧混乱：搜索不是一个固定阶段。 它的位置由入口资料决定。

已核实依据

• 当前业务主线是澳洲 roofer 单页网站，见 docs/v3/BUSINESS-OVERVIEW-CN.md:7-11。
• 端到端主流程已经整理为入口、身份、筛选、采集、审计、master.md、资料包、网站、质检、发布，见 docs/v3/FLOW-END-TO-END-CN.md:8-22。
• master.md 是客户研究档案，后续建站和销售都要读，见 docs/v3/BUSINESS-OVERVIEW-CN.md:103-109。
• 当前身份判断仍有观察区，不能直接放开自动改最终客户档案，见 docs/v3/BUSINESS-OVERVIEW-CN.md:66-70。
• 搜索身份观察 runner 明确不写 entity、不发 Discord，见 scripts/cli/pl-observe-search-identity.js:3-8。
• 观察 runner 已限定 roofer、可跳过归档客户和纯行业词名称，见 scripts/cli/pl-observe-search-identity.js:37-77。
• 观察 runner 已支持压缩搜索结果、去重社媒语言参数、限制每轮判断量，见 scripts/cli/pl-observe-search-identity.js:126-158。
• 观察 runner 已加本地缓存，重复判断会复用旧结果，见 scripts/cli/pl-observe-search-identity.js:168-235。
• 观察 runner 已加保守并行，默认 1，可手动开到 2 扩大样本，见 scripts/cli/pl-observe-search-identity.js:275-287。

阶段 1 · 身份确认和背景资料归属

目标 先把“搜出来的这个页面是不是同一个客户”跑稳。没有这个，后面会把别人的官网、评价、社媒、论坛帖子混进客户档案。

要解决

• 同名不同城市、同名不同公司不能混。
• 目录页、报价平台、论坛、评价站不默认丢弃，但必须判断是不是唯一对应这家公司。
• Facebook / Instagram / LinkedIn 这种登录页要单独标出来，能读就读，不能读也不能当事实。
• AI 判断可以自动分层用，但不能把标题/摘要级判断直接写成正式事实。

当前完成

• 已有搜索结果身份队列：确认同一、AI 高信心同一、可能同一、不同公司、登录受限、抓取失败。
• 已有观察命令：npm run pl:observe-search-identity。
• 已加缓存：同一批结果第二次跑会复用判断。
• 真实样本验证：1 个 roofer、12 个链接；第一轮 AI 新判断 6 个，第二轮缓存命中 6 个。
• 真实样本验证：3 个 roofer、36 个链接；AI 高信心同一 9 个、可能同一 2 个、登录受限 14 个、不同公司 11 个；缓存命中 6 个、新判断 16 个。
• 真实样本观察：已汇总 20 个唯一客户、282 个链接；AI 高信心同一 95 个、可能同一 5 个、登录受限 65 个、不同公司 117 个。登录来源清单见 docs/v3/LOGIN-REQUIRED-SOURCES-CN.md。

本阶段验收

• 跑 20 个真实 roofer 样本。
• 输出每个来源分桶数量：确认、AI 确认、可能、不同、登录受限、抓取失败。
• 找出误判样本，调整提示词或规则。
• 明确哪些结果可以进 master.md 的哪个区域。

验收状态 · 2026-06-03

• 已跑 20 个唯一 roofer 客户、282 个搜索链接。
• 结果：AI 高信心同一 95 个、可能同一 5 个、登录受限 65 个、不同公司 117 个、抓取失败 0 个。
• 登录来源清单已写入 docs/v3/LOGIN-REQUIRED-SOURCES-CN.md，并发布到 SSOT 页面“登录来源 · OpenCLI准备”。
• 重要修正：登录来源只代表“需要账号后再读”，不代表已经确认是同一客户；OpenCLI 读到正文后要再做同一客户判断。

阶段 2 · master.md 分层写入

目标 每条 lead 的所有资料都进入 master.md，但不是混成一锅。要分清正式事实、外部背景、销售参考、待确认、丢弃原因。

要解决

• 没网站的客户：Google / DDG / 目录页查出来的资料怎么安全放进档案。
• 有网站的客户：官网、社媒、第三方背景、评价怎么归位。
• 登录受限来源：记录为“需要登录读取”，不阻塞流程。
• 不能让 Design 从候选资料里拿事实。

本阶段验收

• master.md 有固定的“来源归属记录”区域。
• 每个来源都带使用边界：能不能给网站用、能不能给销售用、是否需要后续确认。
• 至少用 3 个真实 roofer lead 生成样例，确认人看得懂。

当前进度 · 2026-06-03

• 已接入 data/leads/search-result-identity-queue/<key>.json → master.md 的“搜索来源归属记录”区域。
• 已锁住边界：AI 高信心同一只能做外部来源候选 / 销售参考；登录来源必须写成“需要登录后判断”；不同公司只保留丢弃原因。
• 已用 Ace Roofing Service 真实观察记录做内存预览：候选来源区域能渲染，Facebook 登录来源不会进入 frontmatter 正式字段。
• 已生成 3 个真实 roofer 正式 master.md 样例：

- clients/ace-roofing-service/v2/master.md：AI 高信心同一 5、需要登录后判断 3、不同公司 7。 - clients/adelaide-roofs/v2/master.md：AI 高信心同一 3、需要登录后判断 9、不同公司 6。 - clients/spalding-roofing/v2/master.md：AI 高信心同一 6、需要登录后判断 8、不同公司 1。

• 文件检查通过：三份都有来源归属区，登录来源都写明“还没确认是同一客户”，frontmatter 没有吃进候选 URL。
• 阶段 2B 已开始：pl:observe-search-identity --fetch-open-web 会只对 AI 高信心的非社交候选读取正文，然后再判断一次同一客户。
• 真实样本 A & J Roofing Solutions 已跑通：16 个搜索链接里 AI 高信心 4 个、登录后判断 7 个、不同公司 5 个；Tinyfish 只读 1 个非社交候选正文，正文确认同一客户 1 个，强证据是 owned_domain。
• A & J 的 master.md 已显示“已读正文后的验证（非社交候选）”；检查确认社媒和第三方候选没有进入 frontmatter，只有官网作为正式字段保留。
• 阶段 2C 已开始：OpenCLI live smoke 通过；当前连接 profile z3wvy2xe 可以只读 LinkedIn 页面。A & J 用 --opencli 跑真实样本后，登录待读从 7 条变 0 条，读取失败 0 条；Facebook 主页升级为 AI 高信心同一客户候选，3 条社交页保留为可能同一客户，3 条 Instagram 判为不同。
• 阶段 2C 小批量已补：A & J + Apex 两个含社交候选样本共读 15 条社交链接，读取失败 0、仍需登录 0；结果分桶为 AI 高信心同一 1、可能同一 6、明确不同 8。每次观察会输出 opencli-source-stats.md/json，用于看 Facebook / Instagram / LinkedIn 的读取效果。
• 已补 Design / 建站输入边界测试：搜索候选、目录页、社交候选、external_facts 不会流入 site-ctx.json、facts.json、coverage.json、reviews.json、single-page-brief。
• 已补 external_facts → Design 可参考素材 分级通道：身份确认过的外部服务、服务区、专长、项目线索、客户语言可以进入 site-ctx.external_material.design_usable_facts 和 handoff/od-package/content/external-material.json；电话、地址、牌照、ABN、老板名等硬字段仍不能被搜索资料覆盖。
• 真实 4 个无网站 starter 已重跑 site-ctx：当前 external_material 都是 0，说明通道已接好，但这些客户还没跑“抓正文 → 挖 external_facts”。下一步要对 4 个 starter 的搜索候选跑 pl:mine-background，让搜索资料真正产出可用素材。
• 真实 4 个 starter 已跑搜索身份观察：90 个链接里 AI 高信心同一 23、可能同一 2、需要登录 29、明确不同 36、读取失败 0。这个结果说明搜索的第一价值是排除不相关来源，其次才是找素材。
• Mr Roof Solutions 已做 OpenCLI 单客户回放：登录待读从 14 变 0；Instagram 4 条因正文里有电话升级为高信心同一，Facebook 多数仍只是可能同一；耗时 387 秒，所以 OpenCLI 只能放在后期深挖，不能放进快筛。
• Mr Roof Solutions 的 pl:mine-background dry 已证明能从已确认 Instagram 正文挖出服务、服务区等素材；同时发现 LLM 会吐 Not explicitly stated 这类空话，已补过滤和测试 test-mine-background（13 passed）。这类素材暂不写入，直到“客户自己的事实”和“合作产品/第三方品牌事实”分开。
• 已补“客户自己的事实 vs 合作产品/第三方品牌事实”分桶：external-material.json 现在有 context_only_facts。例如 iSwirl 安装、iSwirl 官方安装商、Australia Wide Delivery 这类只做背景/销售参考，不给 Design 写成客户自己的 claim；awards 从 Design 素材移到销售/人工核实。
• Mr Roof Solutions 写入尝试已暂停：OpenCLI 当前 profile 仍显示 connected，但浏览器连通性失败，Instagram live smoke 返回不可用；因此没有把 dry-run 结果手动写进客户资料。core-extract.brief.external_facts 仍为空，避免污染。

阶段 3 · roofer 初筛和排除标准

目标 把一直变化的筛选标准定成一张表：哪些直接排除，哪些只是观察，哪些会提高优先级，哪些进入人工少量复核。

要解决

• 没网站：可能是高价值，但需要更多搜索确认。
• 网站很好：不是目标客户。
• 网站很复杂、页面很多：我们当前单页网站不适合。
• 假公司、非 roofer、目录站、lead-gen 中介要排除。
• PageSpeed 慢不一定排除，可能反而是销售切入点。

本阶段验收

• 一张 roofer 筛选标准表。
• 每条标准标明：直接排除、只观察、加分、减分、进入深度 audit。
• 把免费快速工具放前面，把贵工具放后面。
• 用真实样本回放，看被排除的原因是否合理。

当前进度 · 2026-06-03

• 已核对现有代码主线：快速筛选顺序以 core/leads/fast-filter.js 为准，SSOT 页面“快速筛选漏斗”直接从这份代码生成。
• 已确认快筛执行链：cheap-audit-queue 先跑行业相关、GBP、排除预检、牌照观察、Tinyfish 首页、页面规模、PageSpeed、cheap audit、三层排除；活下来的客户进入 enqueueDetailedAudit。
• 已确认几个容易混乱的规则：

- 牌照风险只观察，不自动踢。 - PageSpeed 慢是销售证据，不是淘汰门。 - 页面规模是硬门：前端导航页太多会提前归档。 - 快筛幸存者统一 predict=C + audit_now=true；真正 A/B/C/D 在详细审计后给。

• 已退役旧说法：“predict A/B 才进详细审计”。对应代码注释已修，test:fast-filter 已加防回归。
• 成本分层文档已补“2026-06-03 代码核对结果”和下一段 L6/L7 触发条件。
• 已新增“目标客户识别”回放：npm run pl:target-fit-replay -- --sample --markdown。它不只看能不能 audit，而是判断 lead 是否属于“无网站强目标”或“有网站强问题目标”。
• 5 个真实样本当前结果：iFix = 有网站强问题目标；Ultra = 无网站强目标；A & J / Vicwest = 轻机会；Brisbane Roofing Solutions = 不适合当前产品。

阶段 4 · 分层 audit 和资料采集

目标 把 audit 拆成便宜快跑和贵的深跑。先用免费工具和本地工具筛出值得深挖的客户，再跑 PageSpeed、完整网站 audit、视觉审计、Places 付费接口等。

要解决

• Tinyfish、PageSpeed、域名检查、牌照检查、Google Map / Places、OpenCLI 分别在什么时候用。
• 哪些工具免费且快，适合初筛。
• 哪些工具耗时或花钱，只给通过前面关卡的客户。
• audit 结果怎么回到 master.md，并变成销售切入点。

本阶段验收

• 一张工具分层表：免费快速、免费慢速、付费、登录态、人工。
• 每个工具写清楚输入、输出、写到哪里、能不能给 Design 用。
• 跑 5 个真实 roofer，看耗时、失败率、有效信息量。

当前进度 · 2026-06-03

• 已核对 L6/L7 真实代码入口：

- Playwright 详细抓站：core/audit/site-fetch-full.js，本地免费但慢，用于 HTML、手机端、表单、性能、截图。 - Docker reviews：core/reviews/fetch-reviews-local.js，本地免费但 30-60 秒，适合 A/B 候选或高价值客户。 - Places reviews：core/reviews/fetch-reviews.js，付费少量评价，不作为每条 lead 默认动作。 - Places Details：scripts/cli/pl-places-enrich.js，手动或 grade ≥ B 触发，有额度保护。 - Firecrawl：core/audit/multi-page-crawl.js，默认不跑，只有免费抓取失败且明确开兜底才跑。

• 已把触发条件写进：

- docs/v3/COST-LAYERED-SCREENING-CN.md - docs/v3/MODULE-05-DEEP-AUDIT-CN.md - docs/v3/DATA-SOURCES-TO-MASTER-MD-CN.md

• 已锁住两个退役说法：

- “Firecrawl 默认抓多页”退役；现在默认免费优先。 - “每条 lead 都拉评论”退役；评论深挖只给 A/B 候选或人工指定。

• 已完成 5 个真实 roofer 样本触发回放：

- iFix Roofing：B/ready，Docker reviews + Places Details 已完成；下一步变成 Design / 建站资料包。 - A & J Roofing Solutions：C/outreach，不默认拉评论、不默认跑 Places。 - Ultra Roof Restorations：无网站但 93 reviews，Docker reviews + Places Details 已完成；继续走无网站资料补强，不跑 Playwright / Firecrawl。 - Brisbane Roofing Solutions：已归档 D，即使 118 reviews，也停止所有慢/付费工具。 - Vicwest Roofing：已有 Places + reviews，不重复跑。

• 回放结论：5 个样本里 Firecrawl 触发 0 个；它继续保持“免费抓取失败且客户值得继续”时才开。
• 已写回 master.md 的“筛选与去向记录”：entry_route、search_timing、next_step。打开 lead 档案就能看到搜索该早做还是后置、下一步该补资料 / 审计 / 轻触达 / Design / 归档。
• 小批量真实执行测试已完成：iFix 写入 87 条 Docker reviews + 10 个 Places photo refs；Ultra 写入 93 条 Docker reviews + 10 个 Places photo refs；两份 master.md 已用 --no-discord 重建。
• iFix Design 输入包已跑通：core-extract.json、site-ctx.json、handoff/od-package/content/reviews.json、handoff/od-package/content/coverage.json、single-page-brief.yaml 已生成；brief 验证通过。
• Ultra 的“无网站 starter”缺口已补完，并已和另外 3 个无网站强候选一起进入 starter 输入链：core-extract.json → site-ctx.json → single-page-brief.yaml。

阶段 5 · 销售资料和 Design / 建站资料包

目标 从 master.md 自动抽出两类资料：销售要用的说服材料，Design / 建站要用的开工材料。

要解决

• 销售资料要讲：客户旧站哪里影响转化、我们能解决什么、证据在哪里。
• Design 资料要讲：客户是谁、服务是什么、服务区、电话、地址、品牌素材、可用图片、不能编造的字段。
• 有网站和没网站的客户，资料包结构要一致，只是来源不同。

本阶段验收

• 固定 Design / 建站资料包清单。
• 每个字段都能追回 master.md 来源。
• 至少 3 个真实 roofer 生成资料包，检查是否足够让建站流程开工。

当前进度 · 2026-06-04

已新增一条只读回放命令，专门回答“快筛之后，哪些客户已经能给 Design / 建站准备资料，哪些还缺东西”：

npm run pl:design-material-readiness -- --all-roofers --markdown

它不联网、不调用 Docker、不调用 Places、不改客户档案，只读现有 entity、快筛判断、starter 资料判断、详细审计 fixture、截图、master.md 和 audit HTML。

当前 247 个 roofer 全量回放结果：

4 个无网站强候选已经全部从 starter_material_gap 升到 starter_material_ready，并且已经接入当前建站事实链。现在不再只是“资料够”，而是已经能生成 starter 版 core-extract.json，再进入 site-ctx.json 和 single-page-brief.yaml。

新增主线命令：

npm run pl:build-starter-core-extract -- --entity-key <entity-key>
npm run pl:extract-site-ctx -- --slug <slug> --force --write-content
npm run pl:build-single-page-brief -- --slug <slug>

边界：这条命令只读本地 entity / GBP / Places / confirmed licence，不联网、不调用 LLM、不读取搜索候选正文；弱牌照候选、搜索结果、需要登录的社交资料都不能进入 real_facts。

当前具体补法：

这条检查把阶段 3/4 和阶段 5 接起来：

前置快筛
→ 无网站候选：starter 资料够不够
→ starter core-extract：只把确认事实和带标记的 starter 默认内容接入主线
→ external-material：把身份确认过的搜索/enrich 正文分成 Design 可参考、销售参考、禁止使用
→ 有网站问题候选：详细审计、截图、master.md 是否够
→ 够了再给 Design / 建站资料包
→ 不够就只补缺口，不扩大乱搜

阶段 6 · 清理、退役和固定主路

目标 把冲突、过期、被证伪的文档和代码处理掉，让项目只剩一条清楚主路。

要解决

• 非 roofer niche 资料和流程退出当前主线。
• 旧筛选标准、旧入口、旧 OD 资料包、旧 audit 说法，如果已经不准，要标明退役或准备退役。
• 文档不能互相打架；代码不能有两套都在写同一个结果。

本阶段验收

• 核心文档索引只指向当前主线。
• 被证伪的文档加退役说明或移入 archive。
• 关键流程都有真实样本跑过，不只是文档写过。
• 从“发现 lead”到“Design 可开工资料包”能按清单走完。

当前推进点

现在继续阶段 2 的下半段。

3 个真实 roofer 的 master.md 样例已经接上：

data/leads/search-result-identity-queue/<entity-key>.json
→ npm run leads:build-master-md -- --entity-key <entity-key>
→ clients/<slug>/v2/master.md

下一步检查重点：

• 销售资料可以读哪些候选来源。
• Design / 建站资料包只能读哪些已核实事实。
• 登录来源读完正文后，怎么重新进入同一客户判断。
• core-extract.json 和 site-ctx.json 是否仍然只吃正式事实。

阶段 2B 的非社交正文验证命令：

npm run pl:observe-search-identity -- --limit 1 --niche roof --judge-provider ollama --route-result-limit 3 --max-candidates 18 --fetch-open-web --open-web-fetch-limit 1

这个命令仍然是观察模式：写观察报告和搜索来源队列，不改客户正式档案、不发 Discord。

阶段 2C 的社交登录验证命令：

ENABLE_OPENCLI_FETCH=1 AUTH_FETCH_PROFILE=z3wvy2xe npm run pl:observe-search-identity -- --limit 1 --niche roof --judge-provider ollama --route-result-limit 3 --max-candidates 18 --opencli --concurrency 1

这个命令同样是观察模式：OpenCLI 只读 Facebook / Instagram / LinkedIn 候选页，读完后重新判断是不是同一客户；读到的内容仍然先留在候选来源区，不直接进入 Design / 建站事实。

ProfitsLocal 客户筛选标准（中文）

2026-06-03 · 第一版。目的：把不断变化过的客户筛选逻辑重新分清楚。 核心问题不是“谁分数高”，而是“谁是我们这种单页网站产品真正能服务的客户”。

一句话

我们的目标客户不是所有本地商家，而是：

有真实业务、有转化机会、现有线上形象有明显问题，并且一个标准单页网站就能明显改善结果的客户。

所以筛选要分三层：

1. 先把所有便宜、快速、不花钱的工具前置跑一遍。
2. 能排除的先排除，先清资源。
3. 再从幸存者里判断谁是强目标。
4. 最后才决定是否投入慢工具、付费 API、深度审计和 Design 资料包。

这一层对应命令：

npm run pl:frontloaded-screening-plan -- --markdown

慢工具和付费工具不用于第一轮找客户。第一轮只用原始字段、GBP 字段、官网类型、Tinyfish / direct fetch 首页、页面规模、PageSpeed 免费额度、license/ABN/WHOIS/Wayback、搜索结果归属判断和 master.md 覆盖检查。

第一轮快筛的结果只允许进入这些桶：

对应命令：

npm run pl:frontloaded-screening-rules -- --sample --markdown

覆盖检查命令：

npm run pl:frontloaded-screening-doctor -- --markdown

当前不能把“工具存在”和“已经第一轮自动用上”混在一起。覆盖检查现在的结论是：

搜索结果归属判断现在的边界：

5 个真实样本当前快筛桶：

筛选的真正目的

筛选不是为了“减少 lead 数量”，而是为了在大数据里找出少数高把握客户。

当前要找的强目标只有两类：

不是强目标的客户也可能保留，但只走轻触达或观察，不默认消耗慢工具和付费工具。

目标客户识别回放

当前有一个 report-only 回放命令，用来检查 5 个真实 roofer 样本是不是被分到正确目标类型：

npm run pl:target-fit-replay -- --sample --markdown

它回答的不是“工具要不要跑”，而是：

• 这条 lead 是不是我们的强目标？
• 如果是，属于“无网站强目标”还是“有网站强问题目标”？
• 为什么值得继续？
• 卡点是什么？
• 下一步应该走补资料、详细审计、Design 资料包、轻触达，还是停止投入？

当前样本结果：

这个判断已经写回 master.md 的“筛选与去向记录”：target_fit、值得继续的证据、卡点 / 排除理由会和 entry_route、search_timing、next_step 放在一起。打开单个 lead 的总档案，就能知道它为什么继续、为什么轻触达、为什么停。

快筛之后怎么决定能不能给 Design

筛出来以后，不是马上建站。还要过一层“资料能不能开工”的只读检查：

npm run pl:design-material-readiness -- --all-roofers --markdown

这条命令回答：

• 无网站候选：公司名、联系、地区、服务类别是否够；ABN / 牌照 / 外部来源 / 商户照片这类硬证据是否够。
• 有网站问题候选：是否已经有详细审计、截图、master.md 和 audit HTML。
• 其他客户：为什么现在不能给 Design。

当前全 roofer 回放：

这个结果说明：第一轮筛选的核心不是“找到很多客户”，而是把 247 个 roofer 压到少数值得花设计/建站资源的客户；无网站客户虽然价值高，但必须先补硬证据，否则页面会变成 AI 猜测。当前 4 个无网站强候选都已补到 starter ready，并已通过 pl:build-starter-core-extract 接进当前事实链：core-extract.json → site-ctx.json → single-page-brief.yaml。

已跑通的 4 个无网站 starter：

补充进展：搜索/enrich 资料不再只是旁边放着。现在已新增一层 external_material：

• design_usable_facts：身份确认过的服务、服务区、专长、项目线索、客户语言，可给 Design / 文案作参考。
• sales_only_facts：老板名、成立年份、年限、团队规模等敏感背景，先只给销售参考。
• blocked_facts：电话、地址、牌照、ABN、官网等硬字段，不能被搜索资料覆盖。

当前 4 个 starter 已重跑 site-ctx，但 external_material 仍为 0；原因是这 4 个还没跑外部正文挖掘。下一步不是再定规则，而是对这 4 个的候选来源跑 pl:mine-background，把搜索结果变成可用素材。

2026-06-03 真实回放补充：

• 4 个 starter 搜索身份观察合计 90 个链接：AI 高信心同一 23、可能同一 2、需要登录 29、明确不同 36、读取失败 0。
• 这一步先用来排除不相关来源：NP / Ultra / Prime 都直接排掉了一批目录页、泛搜索页、其他行业页面。
• 需要登录的来源主要是 Facebook 和 Instagram；OpenCLI profile z3wvy2xe 可读，Mr Roof 单客户回放把 14 条登录待读降到 0，但耗时 387 秒，所以只放在高价值客户后期深挖。
• 普通公开抓取对 Oneflare / Word of Mouth 这类 Cloudflare 挑战页拿不到正文；这类来源先标“需要浏览器读取”，不能放在便宜快筛层。
• pl:mine-background 已从 Mr Roof 的已确认 Instagram 正文 dry-run 挖出服务和服务区素材，但也出现合作产品/第三方品牌内容，例如 iSwirl 奖项。写入前必须分清“客户自己的事实”和“合作产品事实”；没分清前只当销售参考，不进网站文案。
• 已补规则：context_only_facts 专门放合作产品/第三方品牌背景。带 iSwirl、Australia Wide Delivery、supplier、manufacturer 等语义的内容不能进入 Design 文案种子；awards 也不能从外部资料直接进网站文案，必须先人工/强来源确认是客户自己的奖项。
• Mr Roof 的真实写入没有完成：OpenCLI profile 当前显示 connected，但浏览器连通性失败，Instagram live smoke 不可用。系统保持 external_facts 为空，避免把 dry-run 结果当正式资料。

目标客户画像

我们想要的客户

我们不想要的客户

两条主路径

这里要先分清：搜索不是固定早期，也不是固定后期。

搜索放在哪里，取决于 lead 进来时有没有可信的官网 / Google Place / 基础身份。

合流规则：

所以真正的主线是：

入口已有官网/Place 基础资料
→ 先便宜初筛
→ 后期再搜索补背景

入口没有官网/Place 基础资料
→ 先搜索确认身份
→ 找到官网就合流到便宜初筛
→ 没官网但是真公司就走无网站 starter

路径 A · 没有网站

业务逻辑

没有网站的客户，理论上最容易说明价值：我们给他一个可打开、可提交表单、能介绍服务的站。

但它的问题是：资料更少。没有官网可抓，就要靠 Google Search、Places、GBP、评价、外部结果去确认这家公司到底是谁。

关键判断

适合继续的情况

• 有电话或地址。
• GBP 资料可信。
• 评价数不是 0，或者至少有照片 / 营业时间 / 类目。
• 行业明确。
• 不需要复杂页面，一个单页就能介绍清楚。

容易卡住的情况

• 只有名字，没有电话 / 地址 / 官网。
• 搜索结果里很多同名公司。
• 牌照结果和地图结果对不上。
• 没有足够内容写服务和信任块。

路径 B · 有网站

业务逻辑

有网站的客户，我们不能只说“你有网站”。我们要找到会影响转化的核心问题：

• 手机端不好用。
• 速度慢。
• 没有清楚 CTA。
• 服务和地区讲不清。
• 信任证据弱。
• 页面太旧。
• 表单不好用。

关键判断

适合继续的情况

• 网站看起来旧或转化差。
• 手机端有问题。
• CTA / 联系方式不明显。
• 页面数量不多。
• 主要业务可以被一个页面讲清楚。
• GBP 口碑好，但网站拖后腿。

不适合继续的情况

• 已经是成熟高质量网站。
• 页面很多，服务线复杂。
• 有电商 / portal / booking 深度集成。
• 很多广告追踪和归因系统，重建会破坏现有运营。

当前筛选层级

第 1 层 · 直接排除

这些情况不值得继续投入。

当前主要依据：core/leads/exclusion-filter.js、core/scoring/lead-grading.js。

第 2 层 · 只观察，不直接踢

这些信号有用，但不应该单独决定归档。

第 3 层 · 加权判断

这些决定客户优先级，不一定直接挡住。

A/B/C/D 和 ready-to-build 不一样

这里必须分清。

A/B/C/D · 销售优先级

当前依据：core/scoring/lead-grading.js。

A/B/C/D 回答的是：这个客户值不值得我们投入销售精力。

ready-to-build · 资料够不够开工

当前依据：core/scoring/qualification-scorecard.js 和 pl:data-checkpoint。

ready-to-build 回答的是：资料够不够给 Design / 建站用。

一个客户可以是 B，但资料不够开工。 一个客户也可以资料够，但销售优先级不高。

初筛之后 · 下一步怎么选

初筛结束后，不是直接跑所有工具。先把 lead 分到下一条路。

当前下一步只允许这些：

机器回放样本

工具视角回放用这个命令：

npm run pl:l6-l7-trigger-replay -- --markdown

业务资源阶段回放用这个命令：

npm run pl:resource-plan-replay -- --sample --markdown

全 roofer 本地回放用这个命令：

npm run pl:frontloaded-screening-rules -- --all-roofers --markdown
npm run pl:resource-plan-replay -- --all-roofers --markdown

它把“目标客户判断”和“工具是否可跑”合在一起，回答：这条 lead 现在应该停止、补身份、补无网站资料、进详细审计、高价值补强、准备 Design，还是轻触达。

当前资源阶段结果：

这个资源阶段已经写回 master.md 的“筛选与去向记录”：resource_band、现在可跑、暂缓 / 兜底、明确不跑，会跟 target_fit 放在一起。

这就是“初筛之后选择下一步”的标准，不是按工具顺序硬跑。

2026-06-04 · 全 roofer 回放结果

这次回放只读本地资料，不联网、不调用 Docker、不调用 Places、不写客户档案。

快筛桶结果：

资源投入结果：

这说明当前筛选线已经能先排掉大部分低价值线索，再把资源集中到 4 个无网站强候选、14 个有网站问题候选、以及少量已 ready 的客户上。

当前默认决定

这些先作为默认规则执行，后面如果真实样本证明误伤，再改阈值。

代码里的统一来源是 core/leads/screening-defaults.js。快筛、入口下一步、目标客户判断都从这里读。

页面规模标准

页面规模是最容易混乱的标准之一。

当前正确理解：

当前依据：core/audit/page-scale-gate.js。

重点：不再把 sitemap 噪音当成真实页面规模。真正看用户前端能点到多少页面。

我们要解决的问题类型

我们适合解决：

我们不适合解决：

本轮要统一的筛选表

下一步要把所有筛选信号归成 4 类：

最终目标：Matthew 一看就知道某个客户为什么留下、为什么被踢、为什么只是暂缓。

成本分层

筛选标准还要配合成本分层一起看。

原则是：免费、快、低风险的工具先跑；只有客户看起来值得，才跑耗资源审计或付费 API。

成本分层详见：

• docs/v3/COST-LAYERED-SCREENING-CN.md

ProfitsLocal 成本分层筛选（中文）

2026-06-03 · 第一版。目的：把“先用免费快工具筛，再决定是否进入耗资源审计 / 付费 API”这件事讲清楚。

一句话

筛选客户不能一上来就跑全套深度审计。正确顺序应该是：

免费 / 秒级
→ 免费 / 几秒到几十秒
→ 免费但慢一点
→ 付费 API / 视觉 / 深度审计
→ 建站资料整理

每往下一层，成本和时间都更高，所以必须先问：

这一层拿到的信息，能不能帮我们判断“他是不是我们的目标客户”？

分层总表

前置快筛原则 · 先清资源

从现在开始，顺序要改成：

所有便宜 / 快速 / 不花钱的工具
→ 先集中扫一遍
→ 能排除的先排除
→ 只把留下来的潜力客户交给慢工具 / 付费工具

对应命令：

npm run pl:frontloaded-screening-plan -- --markdown

第一轮清资源现在只用这些；搜索归属判断也已接到无官网 / 身份不稳的第一步：

第一轮不跑这些：

Docker reviews
Playwright full fetch / detailed audit
Places Details
Places photos
Firecrawl
视觉 LLM

这些只给通过前置快筛、仍然有潜力的客户用。

快筛结果分桶命令：

npm run pl:frontloaded-screening-rules -- --sample --markdown

这条规则把快工具结果统一变成 7 个桶：快速排除、先补身份、无网站候选、有网站问题候选、轻触达、太好或太复杂、值得深挖。后面的资源投入只看这些桶，不直接按工具顺序硬跑。

L0 · 免费秒级：基础排除

目的 先踢掉明显不值得看的。

看什么

现有依据

• core/leads/exclusion-filter.js
• core/leads/fast-filter.js

业务解释

这一层不解决“好不好”，只解决“是不是明显不该继续”。

L1 · 免费秒级：GBP / 地图初筛

目的 判断这个客户有没有基本业务价值。

看什么

现有依据

• core/scoring/cheap-audit-config.json
• core/scoring/cheap-audit-v2.js

怎么用

L2 · 免费快：Tinyfish / direct-fetch 首页快扫

目的 有网站的客户，先只看首页，不跑全站。

看什么

现有依据

• core/scoring/cheap-audit-config.json
• core/scoring/site-quick-scan.js
• core/leads/fast-filter.js

业务解释

这一层是“有网站客户”的关键初筛：不需要完整 audit，只要首页已经暴露明显转化问题，就值得继续。

L3 · 免费快：页面规模 / 产品适配

目的 判断这个客户是不是一个标准单页网站能服务的。

当前标准

现有依据

• core/audit/page-scale-gate.js

业务解释

这一步不是看客户有没有价值，而是看我们能不能交付。 如果他的网站太复杂，一个单页产品解决不了，就不是当前目标客户。

L4 · 免费但稍慢：PageSpeed / Lighthouse

目的 性能问题是很好的销售证据，但不应该作为单独否决门。

看什么

当前处理

• 已接进 cheap screen。
• 作为重做价值证据。
• 不因为快就排除，也不因为慢就直接通过。

现有依据

• core/audit/pagespeed-insights.js
• core/leads/fast-filter.js
• docs/v3/MILESTONES-CN.md

L5 · 免费：牌照 / ABN / 域名历史

目的 补信任事实，同时发现风险。

工具

怎么用

重点

牌照不能乱写。必须先确认是同一家公司，才能进建站事实。

L6 · 免费但慢：Docker reviews / Playwright 简审

目的 对 L0-L5 里看起来值得的客户，补更强证据。

工具

什么时候跑

只给通过前面免费快筛的客户跑，不给每条线索默认跑。

2026-06-03 锁定触发条件

代码核对：

• core/reviews/fetch-reviews-local.js:4-10：Docker reviews 免费但慢，适合高价值客户，能拉比 Places 更多评价。
• core/audit/site-fetch-full.js:4-10：Playwright 本地免费但慢，产出 raw HTML、手机端 HTML、性能、截图。
• scripts/leads/build-internal-report.js:112-121：--with-reviews 已按最终 A/B 限制，不给 C/D 默认跑。

L7 · 付费 / 耗资源：深度资料和深度审计

目的 只对值得继续的客户花钱或花大时间。

工具

原则

这层不是用来“找客户”的，而是用来“确认和丰富已经值得看的客户”。

2026-06-03 锁定触发条件

代码核对：

• scripts/cli/pl-places-enrich.js:5-9：Places enrich 是手动或 grade ≥ B 触发，并且有月额度保护。
• core/reviews/fetch-reviews.js:4-7：Places reviews 是付费少量评价，不是深度评价挖掘。
• core/audit/multi-page-crawl.js:344-349：多页 crawl 默认免费优先，Firecrawl 只有显式兜底才跑。
• core/audit/multi-page-crawl.js:383-387：实际执行时先 direct fetch；失败且 FIRECRAWL_LASTRESORT=1 才用 Firecrawl。

推荐的筛选顺序

1. Maps / Places / 手动入口拿到初始客户
2. L0 基础排除
3. L1 GBP / 地图初筛
4. 分叉：
   A. 没网站：免费搜索 + 身份确认 + 资料够不够
   B. 有网站：Tinyfish 首页快扫 + 页面规模
5. L4 PageSpeed 作为重做价值证据
6. L5 牌照 / ABN / 域名历史补风险和信任事实
7. 如果仍值得：Playwright 详细抓站 / 截图 / 表单 / 手机端证据
8. 如果最终看起来是 A/B 或人工指定：Docker reviews / Places Details / GBP extras
9. 如果确定要建站或免费抓取不足：Places photos / Firecrawl 兜底 / 视觉 LLM
10. 生成 master.md
11. 再判断资料够不够给 Design / 建站

跟筛选标准的关系

这份分层回答的是：先跑哪个工具，后跑哪个工具。

SCREENING-STANDARDS-CN.md 回答的是：拿到信号后怎么决定。

两者合起来才完整：

当前需要补清楚的决策

1. 没网站路径的最低资料门槛：没有官网时，至少要哪些字段才继续。
2. L6/L7 实跑样本：用 5 个真实 roofer 记录耗时、失败率、有效信息量。
3. 资料包抽取边界：哪些评价 / 图片 / 官网内容能进入 Design，哪些只能做销售参考。
4. PageSpeed 的使用方式：保持“销售证据 / 重做价值”，不要变成误伤客户的硬门。

2026-06-03 代码核对结果

这次核对后，可以先锁住以下现状：

快工具覆盖检查

命令：

npm run pl:frontloaded-screening-doctor -- --markdown

当前结论：

因此，现在真实说法是：13 个快工具都已经进入第一轮或明确观察使用；目前 12 个完整前置，1 个已跑但只观察。

本轮退役 / 修正的旧说法

2026-06-03 · L6/L7 5 个 roofer 样本回放

命令：

npm run pl:l6-l7-trigger-replay -- --markdown

这次是 report-only：只读本地 entity / fixture，不联网、不调用 Docker、不调用 Places、不发 Discord。

样本

回放结果

结论

1. B/ready 客户：可以触发 Docker reviews + Places Details；Places reviews 只做 Docker 失败时的补充。
2. C/outreach 客户：不默认拉评论，不默认跑 Places Details；已有 Playwright 详细抓站就不重复跑。
3. 无网站但高口碑客户：不跑 Playwright / Firecrawl；应该补 Docker reviews 和 Places Details，让 master.md 有足够事实和评价素材。
4. 已归档 / D 客户：即使评价很多，也停止所有 L6/L7 慢工具和付费工具。
5. Firecrawl 本轮 0 个触发；它仍然只是免费抓取失败后的兜底，不是常规步骤。

下一步要打通的判断

本段已把 L6/L7 触发条件锁成表，并完成 5 个 roofer 样本回放。

2026-06-03 追加完成：

1. 新增 pl:resource-plan-replay，把“目标客户类型”和“资源投入阶段”合并成一张业务判断表。
2. master.md 的“筛选与去向记录”已经写入 resource_band、现在可跑、暂缓 / 兜底、明确不跑。
3. iFix / Ultra 已完成 Docker reviews + Places Details 小批量实跑；iFix 进入 Design 资料包，Ultra 继续无网站 starter 素材缺口。

2026-06-04 追加完成：

1. pl:frontloaded-screening-rules -- --all-roofers --markdown 可以对本地全部 roofer 线索做只读快筛回放。
2. pl:resource-plan-replay -- --all-roofers --markdown 可以对同一批 roofer 线索做只读资源投入回放。
3. 当前本地数据：249 个 entity，247 个 roofer 相关；pl:master-md-coverage 通过，249/249 都有 master.md、筛选记录和下一步行动。

全 roofer 快筛结果：

全 roofer 资源投入结果：

这组数字说明成本分层已经有实际效果：先用 L0-L5 便宜工具把 149 条停掉，再把 Docker / Playwright / Places / Firecrawl 限制在少数有把握的客户上。

下一步要做的是：

1. 验证补回来的图片候选是否按边界进入 master.md / starter 素材区。
2. 继续找一个“免费抓取失败但值得继续”的真实案例，专门验证 Firecrawl 兜底路径。
3. slow_free_then_paid 的内部 id 暂时保留，中文统一叫“看缺口补强”，避免误以为所有这类客户都要立刻花钱。

当前默认决定

代码里的统一来源是 core/leads/screening-defaults.js。改阈值先改这里，再跑全 roofer 回放。

资料来源 → master.md 写回表（中文）

2026-06-03 · 目标 1 产物。 核心原则：任何 lead 进入系统后，都应该有 master.md；后续筛选、audit、销售、Design / 建站资料，都从 master.md 这份总档案抽。

一句话

master.md 是 lead 的总档案，不是建站后才有的文件。

所以所有资料都要回答 5 个问题：

1. 从哪里来？
2. 什么时候跑？
3. 免费还是付费？
4. 写进 master.md 哪一块？
5. 后面能不能用于客户网站？

写回分级

资料来源总表

L6 / L7 资料写回边界

这一段专门锁定“慢工具 / 付费工具”怎么进入 master.md，避免它们重新变成默认初筛。

代码来源：

• core/reviews/fetch-reviews-local.js:4：Docker reviews 免费但慢，适合高价值客户。
• core/reviews/fetch-reviews.js:4：Places reviews 付费，只返回少量评价。
• core/audit/site-fetch-full.js:4：Playwright 提供截图、手机端、表单、性能等证据。
• scripts/cli/pl-places-enrich.js:5：Places Details 手动或 grade ≥ B 后触发。
• core/audit/multi-page-crawl.js:344：Firecrawl 不是默认入口，是免费抓取失败后的显式兜底。

总边界

master.md 可以记录所有来源，但 Design / 建站资料包只能抽已核实事实、真实评价、真实图片、官网原文和明确来源的截图证据。搜索候选、AI 判断、风险观察、未确认社媒内容不能直接抽给 Design。

没网站路径

没网站的 lead 也必须有 master.md。

先写入

• 公司名。
• 入口来源。
• 电话 / 地址 / 类目 / 评分 / 评价数。
• website = null 或第三方页面状态。
• 为什么进入系统。
• 当前资料缺口。

然后补

关键判断

没网站客户不是自动通过。要看：

• 是不是真公司。
• 是否有联系方式。
• 是否有足够服务和地区信息。
• 是否有基础口碑或活动痕迹。
• 能不能不编造地写出一个页面。

有网站路径

有网站的 lead 也必须有 master.md。

先写入

• 公司基础资料。
• 官网 URL。
• 首页快扫结果。
• 页面规模。
• 初步旧站问题。

然后补

关键判断

有网站客户不是自动适合。要看：

• 问题是否影响转化。
• 问题是不是我们能用单页解决。
• 网站是不是太复杂。
• 是否已经做得很好，没有明显销售理由。

写入 master.md 的推荐结构

每个 master.md 应该逐步形成这些块：

哪些能抽给 Design / 建站

可以抽：

• 已核实公司名。
• 已核实电话、地址、服务地区。
• 已核实服务列表。
• 真实评价。
• 确认可展示的牌照 / ABN。
• 质量合格的真实图片。
• 已确认的业务信任信号。

不能直接抽：

• 未确认外部资料。
• 牌照候选但没确认同一家公司。
• AI 总结里的事实性说法。
• 归档原因。
• 风险观察。
• 搜索结果片段。

当前代码 / 流程缺口

这份表是目标状态。下一阶段需要核对真实代码是否已经做到：

1. lead 进入系统后是否一定生成骨架 master.md。
2. 免费初筛结果是否写进 master.md。
3. 成本分层 L0-L7 跑过 / 没跑是否写进 master.md。
4. 归档 lead 是否仍保留并更新 master.md。
5. 没网站路径是否有专门的 master.md 结构。
6. audit report 是否全部从 master.md 抽，而不是另起资料源。
7. Design / 建站资料包是否只从 master.md 和已核实事实抽。

第一目标结论

第一目标不是先改代码，而是先锁住主线：

lead 进入系统
→ master.md 骨架
→ 每个筛选 / 采集 / audit 结果写回 master.md
→ 销售、audit report、Design / 建站资料包都从 master.md 抽

这条线锁住后，再看哪些脚本没写回、哪些文档还在绕开 master.md。

需要登录读取的信息源

2026-06-03 · 来自 roofer 搜索身份观察 20 个唯一客户汇总 2026-06-03T10-15-20-757Z-combined-20。用途是给 Matthew 准备账号和 OpenCLI 登录态，不是正式客户事实。

结论

登录受限来源主要是社媒：

说明：

• facebook.com、id-id.facebook.com、ms-my.facebook.com 可以先按同一个 Facebook 登录态处理。
• linkedin.com、au.linkedin.com、ca.linkedin.com、id.linkedin.com 可以先按同一个 LinkedIn 登录态处理。
• OpenCLI 只读这些页面，用来判断是否同一个客户、挖背景资料候选；不能直接把社媒内容写成 Design 正式事实。
• 总登录受限是 65 条；当前机器生成的 URL 明细保留了 61 条。差值来自早期观察报告的展示截断，不影响账号准备结论。

OpenCLI 实测状态

2026-06-03 已做只读 smoke test：

真实 roofer 样本也已跑过一次：

这次真实样本里，社交来源读完后的归属结果：

对应观察报告：

data/leads/search-result-identity-observe-runs/2026-06-03T10-44-38-396Z

小批量读取结果

2026-06-03 又补了两个含社交候选的真实 roofer 样本：A & J Roofing Solutions、Apex Roofing。

按来源网站拆开：

对应报告：

data/leads/search-result-identity-observe-runs/2026-06-03T10-49-26-073Z/opencli-source-stats.md
data/leads/search-result-identity-observe-runs/2026-06-03T11-01-48-898Z/opencli-source-stats.md

阶段结论：

• OpenCLI 读取链路可用，至少这两个含社交候选的样本没有失败、没有卡人工。
• Facebook 主页最有可能读到强证据；Instagram 帖子更常用于排除同名/无关内容。
• LinkedIn 更像背景线索，不能当作 Design 正式事实。
• 社交读取后的信息仍然只进候选区；只有出现电话、官网、ABN、牌照、地址等强证据，才可能升级。

当前样本统计

原始来源清单

完整机器生成清单：

data/leads/search-result-identity-observe-runs/2026-06-03T10-15-20-757Z-combined-20/login-required-sources.md
data/leads/search-result-identity-observe-runs/2026-06-03T10-15-20-757Z-combined-20/login-required-sources.json

账号准备优先级

1. Facebook

先登录一个专用账号。当前样本里 Facebook 量最大，且很多 roofer 会把项目照片、评价、营业状态放在 Facebook。

1. Instagram

第二优先。Instagram 常见内容是项目照片、短视频、施工动态，适合做背景资料和图片线索。

1. LinkedIn

第三优先。LinkedIn 更常出现负责人、公司员工、职业背景；对 Design 正式事实帮助有限，但对销售背景调查有用。

使用边界

• 这些来源目前都属于 login_required，还不能写入正式客户档案。
• OpenCLI 读到内容后，还要走身份确认。
• 只有页面内容里出现强证据，例如同一电话、官网、ABN、牌照，才可能升级为确认来源。
• 标题、摘要、社媒帖子本身只能作为背景资料候选或销售参考，不能直接给 Design 当事实。

下一步

• 建议 Matthew 后续单独准备 Facebook / Instagram / LinkedIn 专用账号；当前 z3wvy2xe 可以做读取验证，但长期不要把日常浏览 profile 当生产读取 profile。
• 小批量继续跑 --opencli，观察 Facebook / Instagram / LinkedIn 的成功率和误判情况。
• 把稳定通过的社交来源留在 master.md 候选区；只有强证据来源才能升级，Design / 建站仍然不能直接吃社交候选事实。

🏗️ 我们怎么做一个网站（canonical 流程 · 用人话）

这是唯一的建站流程（pl:compose-editorial 模板渲染 · 免费 · 可重复 · 不靠外部设计团队、不靠 OD）。 老路（OD 守护进程 / V2 拼装 / 整页 LLM 渲染 / families 模板）已全部封死（32 个废命令一跑就报错）。

第一段：把客户研究透 → master.md

1. 抓客户（Google 地图 / 牌照库）→ 名字/电话/评分/有没有官网
2. 筛掉不合适的（太小/关店/连锁/同行）
3. 审老网站（程序爬 + 打分 12 维 + 视觉大模型看截图）
4. 定级 A/B/C/D（值不值得做、做哪种）
5. 出 master.md —— 客户研究档案，后面一切的源头

第二段：master.md → 真网站（5 步 · 全确定性 · $0 渲染）

模板：2 个 canonical —— editorial-newsletter(均分91) / trade-classic(均分84)，单页。

出网站之后：质检（见「网站审计」tab）

• copy-audit（诚实门：造假/堆砌）· persona-copy-audit（买家视角分）· audit-v4（视觉+结构，5 个 P0）

三条要记住的

1. 事实可靠、文案要打磨：电话/牌照/评分走确定性、锁死；真功夫在第③步把事实变成好文案。
2. 只有一条建站路：compose-editorial 模板渲染。
3. 老路全封死：32 个废命令一跑报错（PL_ALLOW_DEPRECATED=1 才能强行跑，仅供重测）。

当前架构的自由度（灵活模块系统 · R170-R184 · codex 全程签字 ✅）

2026-06-03 新增 · 配方 + 自动选 + 2个新模块（全 opt-in · 正在标定）： - 配方(recipe)：4套命名布局 —— editorial-default(不变) / trust-heavy(信任优先) / visual-first(视觉优先) / local-seo(本地优先)。--recipe <名> 选用。 - 自动选配方 --auto-recipe：系统按已核实数据自动挑布局（有质保+执照+口碑+团队→信任优先；真实工程照≥3→视觉优先；核实小镇≥12→本地优先；信号弱/打平→默认）。纯数据驱动、不用大模型。 - 2个新模块：团队（显示核实过的人·首字母头像·不编假脸）/ 服务区地图（覆盖区变体·核实小镇做成"中心+周边"视觉·不用iframe）。 - 守纪律：每套配方硬不变量（hero第一·联系/页脚收尾·不许两个数据条挨着）；新模块只读已核实数据；质保检测抽成一个共享源(detect-signals.js)compose和选配方共用。全 opt-in、默认行为没变、一致性 31/31。要设成自动默认得过标定A/B+你眼检。

积木式搭建：网站模块拆成了独立「积木」（templates/roofing/blocks/ + 登记表 index.json：哪个积木放哪个区、什么条件出现），排版大脑按客户数据自动拼装。

• 模块顺序：现在由排版大脑决定（pl:plan-layout 默认就智能拼装）。固定骨架仍在（hero 永远第一、联系/页脚永远收尾），可选积木插进对应区位；--base 可拿回纯净老顺序。
• 3 个可选模块（新增 · 默认不在老版顺序里 → 不破坏老页面）：

- FAQ 常见问题 — 有 ≥3 条真实问答才出现（放服务区后） - 质保承诺带 — 核实过有质保年限才出现（放评价区后）；只读已有质保数据、不新增任何信息源 - 施工流程 — 通用流程文案；默认关（配置 optional_blocks.include_generic_process），要开再开

• 模块出不出现：数据驱动 + 一处门槛（评价≥3、FAQ≥3、有质保…）。排版大脑只负责「摆位置」，真正「显不显示」由登记表里的门槛说了算 —— 一份规则、不打架。
• 诚实门槛（R177）：「全保险 / 不用外包 / 0外包」这类话，没核实就不显示（和质保条同一标准）。
• 模块文案：灵活（copy-builders / 准备好的内容）。
• 图片：hero 库存图 · 服务图按关键词匹配 · 相册「真实照片≥3 用真的」。Phase 2A（flag-gated）：可挑客户真实照片放 hero+服务（image-manifest.json 权威否决）。

安全底线：实时渲染仍走老的整页模板（compose --use-layout-plan 默认关）—— 智能拼装目前只改「计划文件」、没真正上线。一致性测试全程 31/31 绿（智能版 vs 老版逐字节一致）。审计同评委对比：智能版 67 ≥ 老版 66，零倒退（还略升）。

• 🔭 下一步（codex 建议 · 都独立 · 不急）：① 修首图（用真实屋顶照，审计唯一扣分点）② 再观察几个客户后，把智能渲染真正设为实时默认。

🔬 我们的网站审计（很牛 · 用人话）

建出来的网站不是"看着差不多就行"——每个网站过一套多层、可量化、带否决权的审计，分数低就不发。 标准源头：docs/v3/SOP-AUDIT-STANDARD-V2.md（canonical）。工具：pl:audit-v4 + pl:copy-audit + pl:persona-copy-audit。

一、5 个 P0（Matthew 钦定 · 综合分加权）

最终综合分 = 这 5 项加权：

二、三层检查（各管一段）

1. T1 确定性检测器（7 个 · GATE-A 硬门）：硬事实核对 · 出处追踪 · 套话泄漏 · 服务/信任/占位符检查。不靠大模型猜——能挂就挂。
2. T3 视觉大模型：看真实截图判 布局/字体/配色/可读性/文案厚度（受 vision 置信度把关）。
3. 移动端否决（mobile veto）：手机上点击区太小/排版崩 → 直接否决，分数再高也不发。这是 AU 本地生意的铁规。

三、为什么"牛"

• 诚实优先：造假牌照/身份是唯一的诚实硬挂项，确定性核对（绝不让大模型替身份事实背书）。
• 校准过：copy-audit --validate 必须先在金标准集上证明"能抓到人眼看到的问题"，才被允许给文案把关。
• 买家视角：persona-copy-audit 站在目标客户角度打分（参考分，不当批量硬门，留给人眼 + Matthew 拍板）。
• 防漂移：渲染阈值（module-render-policy.json）渲染端和审计端读同一个文件，不会两边对不上。
• 每个改动都有对账：标定客户（vicwest / a-j / mark-squire）任何模板/权重改动，三家都要 ≥ 基线才算数。

四、当前标定基线（editorial-newsletter）

vicwest 91 · a-j 89 · mark-squire 93（均分 91）。trade-classic 均分 84。

五、质检在流程里的位置

建站链 ⑤ 渲染出 editorial-output/index.html 之后跑：copy-audit（诚实）→ audit-v4（5 P0 + 移动否决）→ persona-copy-audit（买家分）。全过才算"可发"。

核心里程碑（中文）· 我们收集什么 · 用什么工具 · 成本 · 有什么用 · 用没用上

6 个里程碑，覆盖一条线索从数据采集到网站上线。每个标清楚：产出什么 · 内容结构 · 工具 · 免费/付费(成本) · 时间 · 用途 · 写手→读者 · 闸门 · 弱/没用时该怎么办。 数据使用状态：✅ 已接进流程 · 🔭 有工具但偏后置/默认不跑 · ❌ 建了但没被调用 · ⚠️ 花钱/贵。更新于 2026-06-03（模块 3 采集核对）。

⚠️ 数据使用状态总览（你最关心的"有没有用到流程里"）

可行动：Places 照片、OpenCLI 社媒抓取属于偏后置能力；继续核对它们什么时候该跑，避免一开始就增加成本。

里程碑 1 · 数据采集 / 富集（master.md 之前的输入）

• 产出什么：一个公司的多源原始资料（搜索结果 + 官网爬取 + GBP + 评价 + 工商/域名/历史）。
• 工具 / 成本：见上表（付费 = Places/照片 + 显式 Firecrawl 兜底 + 云 LLM；官网爬取默认免费优先）。
• 时间：每条线索约 10-40 秒（爬取最慢）。
• 写手→读者：pl:run-enrichment-batch / pl:enrich-entity / pl:places-enrich → 写 handoff/od-package/facts.json + multi-page-crawl/ + photos/ → 读者 = 核心提取 + 审计。
• 用途：给后面所有步骤喂料；AI 判断链接相关性 + 身份红线（不把同名冒牌混进来）。
• 闸门：无联系方式（enrich 后仍无）→ 排除。
• SoT：clients/<slug>/v2/handoff/od-package/facts.json。
• 弱/没用：Places 照片和社媒登录抓取有工具但偏后置；不是每条线索默认跑。

里程碑 2 · master.md · 汇总档案（漏斗底部的基石）

• 产出什么：一份客户的完整档案 = 背景 + 现状审计 + 建站素材（21+ 章）。
• 内容结构（真实章节）：① 店家现状速览 · ② 销售切入点 · 五、当前网站漏水点(关键/主要问题) · 七、推荐销售切入点 · 真实速度数据 · 图片优化 · YAML 头(business_id/audit_score/decision/grade/investment_level/pricing/deploy_url…)。
• 工具：buildCoreExtract(融合 GBP+爬取+评价+提及+图片) → core-extract.json → leads:build-master-md。LLM 走级联（本地优先）。
• 成本：本地 LLM 免费；云 LLM 订阅。时间：每条约 1-2 分钟（含视觉审计 + 渲染）。
• 写手→读者：pl:llm-extract-core/leads:build-master-md → 读者 = 渲染器 pl:compose-editorial + 销售。
• 用途：建站的"唯一素材源"；销售开场白。external_facts（外部资料）已可作为参考区进入 master.md，但不能混进正式事实。
• SoT：clients/<slug>/v2/master.md + core-extract.json（real_facts 带来源）。

里程碑 3 · 建站前审计 · 客户现状网站（筛选 + 销售角度）

• 产出什么：对方现有网站的体检分 + 重做决策 + 卖点。
• 内容结构：两段 —— 便宜 GBP 初筛(~11 规则·$0) → 详细审计(6 维 × ~39 规则)。6 维 = GBP(15%) · 技术(20%·HTTPS/LCP/手机) · 转化UX(25%·CTA/电话/表单) · 内容(15%) · SEO(10%) · 视觉(15%·目前 stub 50，视觉LLM待补)。
• 工具：Playwright + Lighthouse + sitemap-analyzer + (视觉)Ollama。成本：~$0.05-0.15/条。时间：~30-60 秒。
• 写手→读者：leads:run-pipeline → data/v2/fixtures/detailed-audit/<key>.json → 读者 = 分级 + master.md 卖点。
• 决策：strong_redesign / moderate / low / not_qualified。闸门：页面规模门(本会话改成前端导航≤20) · 无手机端/无HTTPS/无CTA → 强制重做。
• 用途：筛掉不值得做的；给销售"你网站哪里漏钱"的具体话术。

里程碑 4 · 能不能开工 · 数据就绪闸门 + 交付前审（codex 说这是最该补的里程碑）

• 产出什么：两道"开工前"检查 —— ① 数据够不够建站 ② 交付包合不合格。
• 结构：① checkpoint.json = RED/YELLOW/GREEN（GREEN 多页 · YELLOW 单页+提示 · RED 拦住不建）；② pl:audit-handoff = 建站前对 od-package 的 7 层检查（结构/manifest/品牌/内容/语言/事实/设计）。
• 工具/成本：确定性检查 · $0 · 秒级。
• 写手→读者：pl:data-checkpoint → checkpoint.json → 读者 = 渲染器（RED 直接拒渲染）。
• 用途：不在数据不全的客户上浪费渲染成本；保证交给设计的包是完整的。
• SoT：clients/<slug>/v2/checkpoint.json。

里程碑 5 · 交给设计 / 渲染的包（od-package · 锁定契约）

• 产出什么：一个"锁定契约"包，机器(渲染器) + 人(设计) 都读它。
• 内容结构（真实目录树）：

od-package/
  facts.json          ← 锁定事实(名/址/电话 · 逐字不改)
  brand/              ← logo 多变体 SVG + brand-tokens.css + brand-spec.json
  content/            ← services.json · about.md · hero-copy.json · faq.json · reviews.json (LLM抽取·带_source来源)
  structure/          ← page-map.json · header/footer/cta-system · seo-strategy.md
  assets/             ← 真实客户照片 + 缺图用图库兜底 + asset-prompts.md
  shared/             ← header.html · footer.html · shared.css(每页复用)
  DESIGN-MANIFEST.json← 机器读：family · read-order · factsPolicy(mustNotInvent 清单)
  DESIGN-HANDOFF.md   ← 人读：8 章(事实/品牌/内容/架构/图片/审计/边界/建站指令)

• 工具/管线：pl:build-handoff(脚手架) → pl:enrich-handoff(B1-B7 LLM抽真内容) → pl:assemble-handoff(打包成 od-package)。
• 谁消费：当前生产渲染器 = pl:compose-editorial（读 od-package 的 facts/content/brand + core-extract/master.md/checkpoint/照片/persona/模板）。pl:compose-site = 已废弃的旧全包消费者，别用。
• 锁定的：facts.json 逐字 · brand · page-map · mustNotInvent(牌照号/ABN/成立年/团队/价格/证言不许编)。可改的：文案措辞 · hero 候选 · 选图。

里程碑 6 · 建站后审计 + 上线（发布闸门）

• 产出什么：对我们生成的网站的出厂质检 → SHIP/修/拒；过了就发布上线。
• 内容结构（5 个 P0 能力）：文案质量(0.25) · 内容准确(0.25·0编造) · 内容丰富(0.15) · 设计一致(0.15) · 品牌还原(0.20)。两档：快(确定性·$0·CI) / 精(LLM·~$0.5-1.5·发布门)。
• 判定：composite≥80 → SHIP · ≥60 → 修(最多3轮) · 否则拒。手机否决(机械)：横向溢出/无吸顶CTA/点击区<44px → 直接拦。
• 附加（顾问性，不当硬门）：pl:copy-audit(诚实门·唯一硬否决=编造身份) · pl:persona-copy-audit(买家视角) · grid-balance。
• 工具/成本：Playwright + Cheerio(确定性) + Ollama/Claude(视觉)。SoT：editorial-output/audit-v4-*.json。
• 上线：过门 → pl:publish-dir --with-functions → CF Pages · 联系表单 → Resend 邮件（leads@profitslocal.com）。
• 用途：保证交付质量；红线 = 不发编造身份/手机端坏的站。

销售/外联（结账→Stripe→改稿→发布 · SALES_FUNNEL）是下游业务流，用上面这些产出，但不算"建站核心里程碑"，本页先不展开。

项目路线图（中文 · 实时维护）

这是我们按它推进的计划，也是 Matthew 唯一看的页面。状态：✅ 已实现（线上跑） · 🔭 已建·只观察（不真动手，等放行） · 🔄 计划中（还没建/没批）。 所有 SSOT 文档都在本页"文档索引"列出 + 在"锁定决策"tab 里能读。命令 npm run pl:publish-business-map 重新发布本页。更新于 2026-06-02。

📌 进展日志（最新在上）

• 2026-06-03 · ✅ 页面"搭配自由度"主线推进（配方骨架 + 2新模块 + 自动选 · codex R180-R184）：Matthew 主线"丰富模块+灵活搭配"。① 配方骨架：4套命名布局(editorial-default不变/trust-heavy/visual-first/local-seo)，排版大脑可按名选。② 2个新模块：团队(核实的人·首字母头像·不编假脸) / 服务区地图(覆盖区变体·核实小镇"中心+周边"视觉·不用iframe)。③ 自动选配方 --auto-recipe：按已核实数据自动挑布局(质保+执照+口碑+团队→信任优先；真实工程照→视觉优先；小镇多→本地优先；弱/平→默认)·纯数据驱动不用大模型·codex 保守兜底规则。④ SSOT 守门：质保检测抽成共享源(detect-signals.js)compose+选配方共用·不重复。全 opt-in·默认零改动·一致性31/31·8个测试套件全绿(配方38/团队14/服务区17/自动选16…)。codex 全程审/修(R181抓3问题+R182抓2问题已修)。正在跑配方标定 A/B(base=70)·过了+你眼检才设自动默认。首图支线(R179)：宽幅航拍替掉产品特写·视觉+4(66→69)·真实照片反而更差→保留库存(已收口)。
• 2026-06-02 · ✅ 灵活模块系统上线（Phase 1 + 2B + 推默认 · codex R170-R178 全程签字）：Matthew 要的"更多模块 + 灵活组装"。
• 2026-06-02 · ✅ 灵活模块系统上线（Phase 1 + 2B + 推默认 · codex R170-R178 全程签字）：Matthew 要的"更多模块 + 灵活组装"。① 积木化：模块拆成独立积木（templates/roofing/blocks/ + 登记表），渲染器按登记表拼装。② 3 个新可选模块：FAQ常见问题（≥3问答）/ 质保承诺带（核实有质保·只读不新增写手）/ 施工流程（默认关·配置开）。③ 排版大脑智能拼装（pl:plan-layout 默认 --smart）：自动把可选块摆到对应区位（质保后于评价、FAQ后于覆盖区），但显不显示由登记表门槛决定——排版只摆位置、门槛只一处、不重复。④ 诚实门槛：「全保险/不用外包/0外包」没核实就不显示。⑤ 审计可复现：锁定视觉评委模型 + 记录型号（之前换评委分数漂 13 分）。证据：测试 31+20+13+14+12 全过；智能版 vs 老版 同评委 67≥66 零倒退（还略升）；buyer文案审计 78分0诚实问题；Matthew 亲眼过截图。安全：实时渲染仍走老整页模板（--use-layout-plan 默认关）、智能拼装只改计划文件未上线、--base 可拿回纯净老版、一致性逐字节 31/31。下一步（codex 建议·独立）：修首图（真实屋顶照·审计唯一扣分点）→ 再观察几客户后把智能渲染设实时默认。
• 2026-06-02 · ✅ 建站"自由度" Phase 0 + 2A 上线（flag-gated · codex 审计签字）：建了"排版规划层"——一个独立步骤 pl:plan-layout 决定"用哪些模块 + 每个位置放哪张图"，写成可检查的 layout-plan.json，渲染器按它出图（默认关 --use-layout-plan·生产不受影响）。Phase 2A：规划层会真去挑客户的真实照片放 hero+服务（以 image-manifest.json 为权威否决层：必须真实照片·非logo·质量分达标 hero≥7/服务≥6·跨槽去重）。codex 抓出并修了一个 P0（logo 被当 hero）。A/B 同评委对账（vicwest）：用真实照片 vs 库存图 综合分都是 79（真实照片在视觉两维略高）→ 不掉分。codex 裁决：过关·保持 flag-gated 不默认启用·按客户人工眼检后再逐个开。顺带修了审计视觉卡死（加 LLM_SKIP_TO 切 codex/本地 ollama 视觉·守住"必须有本地 fallback"规矩）。待办（codex 归类·非阻塞）：质保标题截断 / 页脚太薄 / 文案差异化不足 / claude视觉健康后重测 canonical 基线。
• 2026-06-02 · 🔄 目标：把所有客户数据做到"能交给设计团队"（Matthew 指令 · codex R157/R158）。做了什么：

- 摸清现状（hard evidence）：交付流水线已建好且能全自动跑（6 个命令 build→enrich→设计文档→评分→打包→审计）。vicwest 已是 93/100「可发版」。 - 真测一个全新客户（apex-roofing）从头跑——证明流水线真能自动产出（hero/分章/图片绑定/fix-matrix 全自动，不靠人工），落在 56/100「需先修关键项」。 - 修了 codex 锁的 4 个 bug（每个都重跑 apex 验证）：① hero 按钮显示成 [object Object] ② 锁定电话没按"数字相等"判（格式不同被误杀）③ 页头/页脚/CTA 没自动生成（已接进流水线·§13/14/15 现在有了）④ 打包命令 --skip-checkpoint 失效。 - 建了一键编排命令 pl:build-complete-handoff：一条命令把 6 步串起来 + 算一个"能不能交付"总闸（设计文档✓ 评分=可发版 ✓ 校验✓ 打包✓ 7 层审计✓），每个客户产出一份 _complete-handoff-status.json 列出还差什么。这把"离能交付还有多远"变成机器可量化的清单。 - 深度审计（P1-P7）又暴露了更完整的差距：品牌包/logo 没生成（logo 技能还没接）、image-manifest 漏建一步、锁定电话格式过审计、模板 family 名对不上。这些 + 2 个待裁定（商家名要在哪些地方逐字出现 / 一个查空目录的废校验器要不要退役）都在等 codex（codex 暂时用量到顶·约 5:03pm 恢复）。 - 下一步：codex 回来→裁定 2 个问题 + 决定品牌包是否算"设计交付"硬门→补齐 apex 到「可发版」→试点 3-5 个→批量 ~74 个。Phase D/C 暂缓。

• 2026-06-02 · ✅ Phase 4 / Phase A · 免费爬虫上线，砍掉付费 Firecrawl（codex R155→R156 · 已审计签字）：爬网页的默认引擎从付费 Firecrawl 翻成免费方案——网页原始 HTML 用免费的 direct-fetch 抓（图片/logo 全保留），干净正文用免费的 tinyfish 补。关键过程：我先按 codex 锁的方案写，但先建了对账测试 + 用真 key 真跑才敢翻默认——结果当场抓出我方案的硬伤（tinyfish 的 html 其实是"清理过的正文"，把图片全删了，不能当原始 HTML 用）。拿真实证据回去找 codex 改方案：rawHtml 改用 direct-fetch（实测和 Firecrawl 98-100% 一致、甚至更全），tinyfish 只补正文。5 个真实客户对账全绿（含 2 个 Firecrawl 老基线）才翻默认。Firecrawl 留作兜底（要显式开 FIRECRAWL_LASTRESORT=1）。20 单测 + 5 客户对账。
• 2026-06-02 · ✅ Phase 2 · master.md 整合（外部资料 + 精选图片）上线（codex R154 · 已审计签字 · 复审又抓出 2 个边界 bug：引用泄漏未确认来源 / selected.json 损坏会崩构建，都修了）：master.md（建站素材唯一真相源）现在多两块——① 外部背景资料：mine-background 挖到的第三方信息（只收身份已确认的 R145·带来源链接·明确标注"仅供参考·未并入核心事实"，永不混进核心事实）；② 建站可用素材·精选图片：把本地 AI 视觉分类的图片（hero/gallery/service…按建站位置归类）汇进来，和 Cloudinary 交付资产分开。真实客户(Vicwest)实跑验证：图片块正常渲染、外部资料临时注入测试确认"已确认的显示·未确认的不漏"、其余 26 章节零回退。22 测试 + 既有 67 master-md 测试全绿。：页面规模修复救回的 24 个被错杀客户，现在 24/24 都跑完详细审计 + 出了 master.md（最后一个 iFix Roofing 评 B）。5 个 D、其余 B/C。等于验证了新筛选/归档逻辑在真实受影响客户上没问题。下一步：Phase 2 master.md 整合。
• 2026-06-02 · ✅ 页面规模 + 牌照 接进快速筛选（codex R153 · 已审计签字）：① 牌照死亡门 → 接进便宜筛选(免费查库·只观察·身份确认才标记)；② 页面规模(导航≤20) → 在便宜筛选抓 HTML 后即时归档 nav>20 的站，省掉整个昂贵详细审计（无HTML→交详细审计兜底）。快筛抓取改 HTML(给页面规模用)+派生文本(给快扫)。两个"待前置"现在 ✅ 在用。codex 审计抓出 3 个 bug（假HTML误判/归档前没存观察数据/归档失败会丢线索）全修，复审通过。下一步：先批量重审救回的 24 个客户（验证新筛选/归档逻辑），再做 Phase 2 master.md 整合。
• 2026-06-02 · ✅ 快速筛选漏斗结构（codex R152）：建了 core/leads/fast-filter.js（唯一真相源·声明 10 道便宜关卡的顺序 + 昂贵分界线），页面「🚦快速筛选漏斗」tab 直接从它渲染（代码改了表自动变·不走偏）。盘了所有审计项，把便宜的（页面规模nav·牌照状态）标为"待前置"。48 测试。下一步：把"待前置"的真接进快筛 + 让 cheap-audit-queue 消费这个 SSOT。
• 2026-06-02 · ✅ 快速筛选前置 PageSpeed（codex R151）：PageSpeed（免费·之前埋在贵的那层闲置）前移到便宜筛选层 —— 慢的站 = 更值得重做，抬高 redesign_need（不当否决门）；只对"有官网+相关+没被排除"的线索抓（移动端·25s·失败降级）；详细审计复用、不重复调。激活了之前闲置的免费 PageSpeed。 16 测试。
• 2026-06-02 · 加「核心里程碑」tab（codex R150）：6 个里程碑（数据采集/master.md/建站前审计/能不能开工/设计交付/建站后审计），每个标了 数据·工具·成本·用途·用没用上。发现并标红：牌照库建了没接进流程、PageSpeed 免费额度闲置、Places照片/OpenCLI 闲置（可行动：接上或砍掉）。
• 2026-06-02 · 页面成为唯一入口：SSOT 文档索引 + 锁定决策 tab 接进本页；INVENTORY/CANONICAL 补齐这次会话的全部改动（还清治理欠债）。
• 2026-06-02 · ✅ Phase B 页面规模修复上线 —— 改用"前端导航页 ≤20"，三道闸门统一；救回 24 个被错杀客户（正在批量重审，跑完它们都有 grade + master.md）。codex R149 签字。
• 2026-06-02 · ✅ 漏斗记账上线（--rollup）；第一次跑就发现 16/30(全库116) 死在旧页面规模 bug 上 → 直接催生 Phase B。
• 2026-05-31 · ✅ OpenCLI 登录态抓取清关（实测真实 LinkedIn）；✅ 身份红线修复（名字+州不够，必须硬证据）；🔭 牌照死亡门 + 外部内容挖掘（只观察）。
• 下一步 · 🔄 Phase 2：master.md 整合（外部资料/评价/图片 → 丰富建站素材）。

📚 文档索引（SSOT · 全部在 docs/v3/）

关键的两份已渲染进本页 tab（"锁定决策"=CANONICAL §0 · "漏斗清单/控制层"=技术细节）。完整源文件在仓库 docs/v3/：

• CANONICAL.md —— 主 SSOT：锁定决策 + 废弃路径 + 质量门 + 重测触发条件（本页"锁定决策"tab 是它的 §0）
• INFRASTRUCTURE-INVENTORY.md —— 全部已建模块/CLI/数据/发布流 + 路径 + 状态（开工前必读，别重造轮子）
• ROADMAP-CN.md —— 本文档（中文路线图 + 进展）
• HANDOFF-NEXT-SESSION.md —— 上一会话交接 + 下一步选项
• SPEC-FUNNEL-ORCHESTRATION.md —— 漏斗总控设计（阶段 1-7 · ADR-6..10）
• SPEC-GATHER-MODULE.md —— 采集骨干设计（阶段 5-6 · ADR-1..6 · 免费爬虫/页面规模/验证层）
• SPEC-IDENTITY-RESOLUTION.md —— 身份识别三层 + 金标准门
• FUNNEL-INVENTORY.md / AGENTS-SKILLS-DISCORD.md —— 漏斗清单 / 控制层（本页技术 tab）
• OPENCLI-SECURITY-REVIEW.md —— OpenCLI 安全审查 + 清关记录

一、整条漏斗（多入口 → 一个身份 → 成本分级筛选 → master.md → 建站）

入口（都收敛成"一个公司身份"）

• ✅ Docker 地图爬（pl:scrape-docker）
• ✅ Google Places API（pl:places-search-intake）
• ✅ 牌照数据库 42 万行（pl:license-lookup）
• ✅ 单个商家（电话/名字/地图链接 · pl:single-enrich）
• 🔄 你发一张图片（pl:ingest-image 有，但自动 OCR 还没做）
• 🔄 你发一个链接（还没接）

统一流程（所有入口共用）

• ✅ 多引擎搜索（Tinyfish + DuckDuckGo · 5 条线）
• ✅ AI 判断链接相关性（judgeEnrichmentMatches）
• ✅ 身份红线：确认"真是这家、不是同名冒牌"（身份判官 R143 · 已接进富集，🔭只看不写）
• ✅ 找官网 + 爬官网 + Google 地图 + 社媒
• ✅ 社媒登录态抓取（OpenCLI · 已实测拉到真实 LinkedIn · R138）
• 🔭 抓第三方链接正文 → 挖背景（pl:mine-background · R145 · 确认身份才挖 · 单独存 external_facts，不碰核心事实）
• 🔄 汇进 master.md（外部资料/评价/图片汇总 = Phase 2，下一步）

成本分级筛选（最便宜的先筛）

• ✅ 数据质量：无联系方式/已关店/测试名 → 排除（exclusion-filter 第1层）
• ✅ 业务类型：评价>200(连锁)/政府学校/同行/行业不符 → 排除（第2层）
• ✅ 时机：评价<5/评分太低 → 归档（第3层）
• ✅ 页面规模门（刚修，重点）：按前端导航页 ≤20 判断，不再用 sitemap 虚高页数。三道闸门统一（审计/分级/资格）。救回 24 个被错杀的客户（R149）
• 🔭 牌照死亡门：吊销/过期牌照 + 身份确认 → 排除（R144 · 只观察，没真删）
• ✅ 分级 A全攻/B预览/C批量/D跳过（lead-grading）
• ✅ 资格硬门（7 道 + 5维打分≥60 → ready-to-build）

深度采集 + 产出

• ✅ 全站爬 + 联系方式/logo/图片/技术栈/评价 提取
• ✅ master.md 生成（审计 + 视觉 + 评价汇总 · 21+ 章节）
• 🔄 把 external_facts + 评价 + 精选图片汇进 master.md（Phase 2）

二、身份识别 + 金标准（精度优先 · 误认率必须 0）

• ✅ 三层判官（死规矩 → 搜索LLM → 读正文LLM · resolve-identity）
• ✅ 红线修复：名字+州不够，必须有硬证据（电话/ABN/地址/域名）才认同一家（R143）
• ✅ 金标准 126 对 · 误认率 0 · 准确率 100% · 召回 81%（确定性下限，大模型层补）
• ✅ 出题 + 判卷工具（pl:mine-gold-candidates / pl:label-gold / 网页版）
• 🔄 扩到 300-500 对真人确认 → 才解锁"真写入客户档案"（你已暂停）

三、控制层（Discord / Agent / Skill · 模块化）

• ✅ Discord：#website-tasks（发命令）· #website-leads（每线索一帖）· #website-templates
• ⚠️ #lead-discovery-runs / #website-projects（代码有，没在发 → 待接）
• ⚠️ Hermes agent：本地有，未上线部署；只能调 1 个 skill
• ✅ 19 个 skill（说明书形式）· 🔄 没有 skill 运行器（agent 现在调 CLI，加新 skill 要改路由代码）
• 🔄 ADR-11：做一个 skill 运行契约，让 Hermes 统一调用（计划）

四、建造顺序（codex 定 · 我们按这个推）

1. ✅ 漏斗记账上线（pl:run-funnel --rollup · 看每层淘汰多少 · R148）
2. ✅ Phase B 页面规模修复（前端导航页门 + 救回 24 客户 · R149）—— 刚完成
3. ✅ Phase 2 · master.md 整合（外部资料 + 精选图片汇进建站素材 · codex R154 审计签字）—— 刚完成
4. ⏸ Phase 3 · 身份写入通道（先"提议+观察"，真写入等金标准 300-500 通关 · 你已暂停）
5. 🔄 Phase 4 · 采集骨干（SPEC-GATHER-MODULE）：✅ Phase A 免费爬虫已上线（默认翻成免费·砍 Firecrawl）；🔄 剩 Phase D 验证模型 + Phase C 统一采集接口
6. 🔄 重爬 83 个无抓取记录的被错杀客户（等下游稳定后批量做）

五、"新筛选逻辑"现状（你问的）

• 现在线上的筛选 = 老的 cycle-23 排除式漏斗（上面"成本分级筛选"那套）+ 这次修好的页面规模门。
• 这次新加的（身份红线 / 牌照死亡门 / 漏斗记账）都是 🔭 只观察、没真动手。
• 更彻底的重设计（成本/速度分级 + 牌照进初筛 + 没网站的客户也当目标）= 🔄 计划中 · 范围等你拍板（SSOT HANDOFF 里标着 "Matthew to approve scope first"）。

核心文档（中文）

业务过程中的核心文档，三类：C 从头梳理模块 + B 每个客户产出的文档链 + A 定义流程的 SOP（只列核实在用的，旧的/不确定的标清楚）。 状态：✅ 核实在用 · ⚠️ 代码在用但文档可能有偏差(待核) · 🗑️ 旧的别看。更新于 2026-06-03。

C · 从头梳理模块（当前推进用）

这组文档是为了把业务从 SSOT 页面往下拆清楚，再一层层推进：

• ✅ BUSINESS-OVERVIEW-CN.md —— 当前业务总览：roofing 线索 → master.md → 单页网站 → 审计 → 发布。
• ✅ BUSINESS-MODULES-CN.md —— 11 个业务模块拆分：入口、身份、采集、筛选、审计、master.md、建站、质检、发布、控制层。
• ✅ FLOW-END-TO-END-CN.md —— 端到端流程地图：入口、筛选、采集、Design / 建站资料包、质检、发布怎么串起来。
• ✅ ROADMAP-6-PHASES-ROOFER-CN.md —— 当前 6 阶段推进目标：只做 roofer，从身份确认一路走到 Design 可开工资料包。
• ✅ LOGIN-REQUIRED-SOURCES-CN.md —— 搜索/背景调查里需要登录读取的信息源：Facebook / Instagram / LinkedIn 账号准备清单。
• ✅ WORKPLAN-FROM-SCRATCH-CN.md —— 本轮从头梳理计划：先理流程，不先跑客户业务。
• ✅ MASTER-MD-SSOT-PRINCIPLE-CN.md —— master.md 总档案原则：所有进入系统的 lead 都应该有 master.md，所有报告/销售/建站资料都从这里抽。
• ✅ DATA-SOURCES-TO-MASTER-MD-CN.md —— 资料来源写回表：每类资料从哪里来、什么时候跑、写进 master.md 哪里、能不能给客户网站用。
• ✅ EXISTING-WORK-INVENTORY-CN.md —— 已有工作盘点：哪些在用、哪些半接上、哪些被证伪或准备退役，避免重复劳动。
• ✅ MODULE-IO-RETIREMENT-MAP-CN.md —— 模块输入/输出/去向/退役风险总表：逐模块推进用。
• ✅ NO-WEBSITE-VS-HAS-WEBSITE-FLOW-CN.md —— 无网站 / 有网站两条客户路径：starter 与 redesign 怎么分流。
• ✅ FIRST-CODE-CANDIDATES-CN.md —— 第一批最小代码改动候选：达到 95% 信心后怎么按测试先行推进。
• ✅ SCREENING-STANDARDS-CN.md —— 客户筛选标准：没网站 / 有网站两条路径，直接挡、只观察、加权参考、人工判断。
• ✅ COST-LAYERED-SCREENING-CN.md —— 成本分层筛选：免费快工具先跑，耗资源 audit / 付费 API 后置。
• ✅ DISCORD-404-CLEANUP-CN.md —— Discord 旧 thread/card 404 清理清单：只读盘点，不挡筛选主线。
• ✅ SSOT-PAGE-MAP-CN.md —— pl-business-map.pages.dev 每个 tab 从哪里来、改哪份源文件、怎么发布。
• ✅ MODULE-01-ENTRY-CN.md —— 模块 1 入口：Maps / Places / 单商家 / 牌照 / 图片 / 链接的真实状态。
• ✅ MODULE-02-IDENTITY-CN.md —— 模块 2 公司身份：怎么防同名误认、哪些结果只能观察、何时能写正式档案。
• ✅ MODULE-03-GATHER-CN.md —— 模块 3 采集：官网/Places/PageSpeed/牌照/外部背景/图片素材分别怎么进流程。
• ✅ MODULE-04-FAST-FILTER-CN.md —— 模块 4 快速筛选：哪些会归档、哪些只观察、活下来怎么进详细审计。
• ✅ MODULE-05-DEEP-AUDIT-CN.md —— 模块 5 深度审计：审什么、怎么分 A/B/C/D、D 级怎么停、哪些输出给 master.md。
• ✅ MODULE-06-MASTER-MD-CN.md —— 模块 6 master.md：资料总档案、正式事实/参考资料边界、建站如何读取。
• ✅ MODULE-07-WEBSITE-CONTENT-CN.md —— 模块 7 建站内容：事实线、文案线、打包线、最终事实锁。
• ✅ MODULE-08-WEBSITE-RENDER-CN.md —— 模块 8 网站渲染：默认模板、可选 recipe/block、输出和旧路封禁。
• ✅ MODULE-09-WEBSITE-QA-CN.md —— 模块 9 网站质检：发布硬门、事实检查、手机端、买家视角建议。
• ✅ MODULE-10-PUBLISH-DELIVERY-CN.md —— 模块 10 发布交付：Cloudflare Pages、表单邮箱、发布记录写回和 publish-doctor。
• ✅ MODULE-11-CONTROL-LAYER-CN.md —— 模块 11 控制层：Discord 任务、任务队列、Hermes、skills、doctors、漏斗总入口。

B · 每个客户产出的文档链（业务的实物产出）

一条线索走完流程，会沉淀这条链（clients/<slug>/v2/）。带 ★ 的是"数据之记录"（CANONICAL 认定的核心，其余多是实验/历史 churn，别被淹没）：

提醒：客户目录里还有 40+ 个文件（audit-a/b/c、core-extract-codex/ollama、comparison-* 等）= 实验/历史 churn，不是核心。核心就上面这 8 个（带 ★ 的 6 个是数据之记录）。

A · 流程 SOP（只列核实在用的 · 按阶段）

每份都对着代码核实过 CLI 是否还在、是否接进线上。✅ 才放，⚠️/🗑️ 标清楚。

发现 / 进件

• ✅ SOP-1-FLOW.md —— Discord 进件 → pl:places-search-intake → master.md 骨架（2026-05-14 验证 live）
• ✅ LEAD_PROFILE_SCHEMA.md —— 线索对象 schema（与 data/leads/entities/*.json 实际结构一致）

审计

• ✅ SOP-2-FLOW.md —— M2 审计管线（leads:run-pipeline → 22 章 master.md + 素材）
• ✅ SOP-AUDIT-STANDARD-V2.md —— 当前审计标准（CANONICAL 锁定），pl:audit-v4 实现它（T1-T5 + 5 个 P0 轴）

数据就绪 / 建站准备

• ✅ SOP-DATA-CHECKPOINT.md —— pl:data-checkpoint 写 checkpoint.json（RED/YELLOW/GREEN），schema 与脚本一致
• ✅ SOP-MASTER-MD-TO-WEBSITE.md —— master.md → 网站的 5 步内容管线（5 个 CLI 都在 · 2026-05-29）

渲染 / 建站

• ✅ SOP-3-FLOW.md —— M2 产出 → pl:build-from-reference → CF Pages（10 个客户 live · curl 200）

销售 / 运营

• ✅ SALES_FUNNEL.md —— 预览 → 结账 → Stripe → 审批/改稿 → 发布（34 个 funnel:* CLI 全接通）
• ✅ PROFITSLOCAL_OPERATING_RULES.md —— 产品边界（单页 $399/$799yr）+ GitHub SSOT + Cloudinary 资产

⚠️ 代码在用、但文档可能有偏差（待核对，先别全信文档）

• ⚠️ SOP-READY-TO-BUILD.md —— 资格 7 硬门 + 5 维打分。代码 qualification-scorecard.js 确实在用（本会话刚改过它的页面规模门），但文档是 D39 初版（2026-05-14 "awaiting validation"），细节可能与代码有偏差。
• ⚠️ LEAD_QUALIFICATION_ENGINE.md —— 筛选引擎。底层 exclusion-filter.js(cycle-23) + lead-grading.js 在用，但此文档较旧（2026-05-06），含部分构想，描述与现状可能脱节。

🗑️ 旧的 · 别看

• 🗑️ SOP-AUDIT-STANDARD.md（v1）—— 已被 V2 取代，仅作回归基线。
• 🗑️ CORE_BUSINESS_FLOW_SOP.md —— 高层概览、非操作手册，已被上面分阶段 SOP 取代（看本页"概览/路线图"即可）。

锁定决策（中文视图）

这是 CANONICAL.md §0 的中文版。锁定 = 没有实证 + codex 共识不能改。 权威源是英文 docs/v3/CANONICAL.md（codex/agent 读英文）。更新于 2026-06-02（v1.7）。

建站 / 渲染侧（已锁定）

• 渲染路径：pl:compose-editorial（V1 · 模板 + Mustache · 确定性 · $0）。要换得满足"审计提升≥5分 + token覆盖≥80 + 5次跑变动≤3分"。
• 模板：2 个已入库 —— editorial-newsletter（暖编辑风 · 均91）+ trade-classic（澳洲行业稳重蓝橙 · 均84）。只做单页。加新模板要走 SOP + 3 个标定客户都≥80分。
• 审计标准：SOP-AUDIT-STANDARD-V2（5 个 P0 能力 + 移动端否决 + 快/精两档）。
• 手机门：M1.1-1.3 机械检查 = 直接否决；M1.4-5 视觉 = 计入设计分。
• 多页渲染：Phase B 不支持，只做单页编辑风。
• 品牌注入：brand-tokens.css 必须放进 <style> 块内（D2.5 配色审计靠它读 hex）。
• 客户表单 → 邮件：每个客户站必须有联系表单 → /api/client-contact（Resend）。发件域名 leads@profitslocal.com（已验证）。
• Copy 诚实门：唯一硬否决 = fabricated_license_or_identity（确定性核对 牌照/ABN/电话/名字/地址 vs brief）。其它（项目数/评价/AI证言/吹嘘）= demo 占位，只提示不否决。身份事实绝不交给大模型判，只用确定性核对。
• Copy 质量（主观）：pl:persona-copy-audit 买家视角打分 = 顾问性质，不当批量门。确定性的当门，主观质量当参考 + Matthew 亲眼。
• 防编造：成立年份/保修年限/服务区 没核实就留空，绝不默认填数。
• 灵活模块系统（R170-R178 · 新锁）：模块拆成积木（templates/roofing/blocks/ + 登记表）。3 个可选块：FAQ（≥3问答）/质保条（核实有质保·只读不新增写手）/施工流程（默认关·配置开）。排版大脑 pl:plan-layout 默认智能拼装（摆位置）+ 登记表门槛决定显不显示（一处门槛不重复）；--base 拿回纯净顺序。实时渲染仍走老整页模板（--use-layout-plan 默认关），智能拼装只改计划文件、未上线。智能版 vs 老版 审计同评委 67≥66 零倒退、一致性 31/31。
• 审计锁评委（R177）：audit-v4 视觉打分锁定模型（AUDIT_VISION_MODEL·默认 sonnet）并记录 vision_model；分数只能和同一评委的基线比（之前 haiku→sonnet 漂移让 vicwest 79→66 但页面没变）。
• 信任话术诚实门（R177）：「全保险 / 不用外包 / 0外包」只在 realFacts 核实过才显示，绝不无依据断言。

管线 / 数据（已锁定）

• 7 阶段管线：发现 → 富集 → brief → wireframe → 渲染 → 审计 → 外联。每个产物只有一个 writer（SSOT 写手检查）。
• niche 范围：只做 Roofing（Phase B）。扩到电工/水管工 = 等 5+ 个 roofer 客户上线后。
• site-ctx.json：pl:extract-site-ctx（零 LLM · 确定性）= 所有下游 copy 工具的中间契约。
• 深度核心提取：buildCoreExtract（融合 GBP + 爬取 + 评价 + 提及 + 图片 + master.md → 一份 core-extract.json）。
• Skill 层：3 个 PL skill（pl-au-trade-voice / pl-local-trade-page-spec / pl-audit-rubric · build-artifact 模式）。加新 skill 要 codex round + §7 查重。
• Persona 模型：4 段（急修 / 计划升级 / 商业维护 / 首次买家引导）· 默认 planned-upgrade。

筛选侧（本会话新加 · 见路线图）

• 页面规模门（R149 · 线上）：用"前端导航页 ≤20"判断规模，不用 sitemap 虚高页数；nav 拿不到 → 内容页>10 兜底；内容页>500 → 一律归档（安全帽）。三道闸门（审计/分级/资格）共用同一函数 pageScaleGate。修这个救回了 24 个客户。
• 漏斗记账（R148 · 线上 · 只读）：pl:run-funnel --rollup 看每层淘汰多少。
• 筛选现状：线上还是 cycle-23 排除式漏斗 + 这次的页面规模门。新加的身份红线 / 牌照死亡门 = 只观察没动手。更彻底的重设计（成本分级 + 牌照进初筛 + 无网站客户）= 计划中 · 等 Matthew 批范围。

废弃路径（别复活 · 除非满足重测条件）

• OD（Open Design 守护进程）：13 个过夜变体 0 个达 85 分 · 9倍成本 · 已废。
• Path C（整页 LLM 渲染）：均 85.5 vs V1 91 · 变动大 · 已废。
• V2 模块库（pl:compose-site）：被 editorial-newsletter 取代。

控制层（中文）· Discord / Agent / Skill

漏斗怎么被触发、任务怎么排队、谁来执行、哪些检查负责发现“用户看不见”的失败。更新于 2026-06-03。更细拆解见 docs/v3/MODULE-11-CONTROL-LAYER-CN.md。

一句话

控制层现在是半自动：Discord 可以进任务，任务可以排队执行，检查器也不少；但从入口到上线还不是一个完整自动按钮。

当前主路径

flowchart TD
  A["Discord #website-tasks"] --> B["pl-task-listener"]
  B --> C["intent-router"]
  C --> D["data/tasks 任务文件"]
  D --> E["pl-task-dispatcher"]
  E --> F["目标 CLI"]
  F --> G["客户资料 / master.md / 审计结果"]
  G --> H["Discord 回写"]

对应代码：

• scripts/cli/pl-task-listener.js：监听 Discord 新 thread / reaction。
• core/tasks/intent-router.js：判断任务类型和要跑的命令。
• core/tasks/task-store.js：把任务写进 data/tasks/。
• scripts/cli/pl-task-dispatcher.js：领取任务、跑命令、回写结果。

Discord 入口

原则：Discord 上看不见，就不能只按任务文件 done 算完成。

任务队列

任务存在 data/tasks/，核心字段是：

• kind：任务类型。
• status：pending / running / done / failed / human。
• source：通常是 Discord。
• input：原始文字 / 附件。
• target.cli 和 target.args：要跑的 npm script 和参数。
• discord：thread / message 信息，方便回写。

模糊任务会进 human，不会硬跑。操作员可以用 reaction 做 retry / archive。

漏斗入口

pl:run-funnel 是获客漏斗的轻量入口。

它串联：

• discovery：pl:scrape-docker 或 pl:places-search-intake
• enrichment：pl:run-enrichment-batch
• audit + grade + master.md：leads:run-pipeline --all-audit-candidates

注意：

• 默认只演练，不真实跑。
• --execute 才会跑。
• --resume 可以继续中断的批次。
• --rollup 只看已有数据的淘汰账，不写数据。
• 它不是“从图片 / 链接到网站上线”的完整按钮。

容易混淆的命令

pl:pipeline-all 名字像“全流程”，但它不是获客漏斗。

它真正做的是：

• 给已有 clients/<slug>/v2/ 跑资料检查。
• 需要时补 inferred-data.json。
• 生成 pipeline.html 和 experiments/pipeline-index.html。

Agent / Hermes

当前状态：

• data/agent-tasks/<client>/*.json 任务包已经存在。
• Hermes 有方向，但不是完整自动发布员。
• 还没有 Hermes 可直接调用的 pl:compose-editorial 包装。
• 还没有 Hermes 可直接调用的 pl:publish-dir 包装。
• M3 发布没有原生 Discord kind。

Skill 层

现在真正进入运行时的 PL skills 主要是 3 个数据型 skill：

• pl-au-trade-voice
• pl-audit-rubric
• pl-local-trade-page-spec

它们由 scripts/cli/skills-build.js 从 SKILL.md 生成 JSON，给审计、文案口吻、页面结构使用。

其他 profitslocal-* skills 多数是说明书 / 工作流 / agent 提示，不是自动运行器。

Doctor 检查

本轮实测状态：

• pl:run-funnel -- --niche roofing --rollup ✅ 能读漏斗账：30 进入，7 进入深度，1 pending。
• pl:publish-business-map -- --dry ✅ 能生成 9 个 tab。
• test-cycle26-cross-file-integrity ✅ 15/15 通过。
• pl:intake-doctor -- --json ✅ 6/6 通过：Docker scraper、Places key、master.md backlog、router regex、batch thread 可见性都通过。
• pl:ship-customer 非 dry-run ✅ Vicwest Roofing 发布成功，写回 cf-pages-deploy.json 和 entity.deploy，表单 POST 返回 200。
• pl:publish-doctor -- --json ✅ alert_count=0，Vicwest URL spot-check 200。
• Discord publish 路由 ✅ publish vicwest-roofing to matthewkiata@gmail.com → kind=publish → pl:ship-customer；缺邮箱会转人工。
• skills:check ❌ pl-audit-rubric.json 和 SKILL.md 已漂移，需要重建或审查。
• pl:lead-journey-doctor --json ❌ 当前客户库有 38 个旧 key 前缀、1 个旧 phase。

当前最大缺口

1. 旧的“选错入口”问题已补三层。

已补：模型提示词不再暴露 pl:scrape-docker；执行器遇到 pl:scrape-docker 但没有 --batch-id 会直接失败并发可见提醒；intake-doctor 会检查最近 batch 是否有 Discord thread，且用 Discord API 抽查是否存在。

1. 发布已有最小 Discord 入口，但还没有完整 Hermes 外壳。

现在 Discord 可把 publish <slug> to <email> 路由到 pl:ship-customer；缺邮箱或 slug 会转人工。Hermes 可调用包装还没做。

1. 建站发布不是一个完整自动按钮。

还没有一条已锁定路线从“图片 / 链接 / 找客户”一路跑到“发布 + Discord 回写 + SSOT 更新”。

1. pl:ship-customer 交付写回已补，仍需非 dry-run 验证。

真实发布完成后会写 cf-pages-deploy.json 和 entity.deploy。下一步用一个客户跑非 dry-run，确认线上 URL、表单邮件、publish-doctor、Discord profile card 都同步。

下一步

1. 给 M3 发布补 Hermes 可调用外壳。
2. 处理 skills:check 漂移和 lead-journey-doctor 旧数据红灯。
3. 整理图片 / 链接入口到下游的实际接法。