🚦 快速筛选漏斗（代码级 · 从 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

ProfitsLocal 核心业务 8 个 Milestone

2026-06-04。当前只考虑 roofer niche。目标不是多做工具，而是把一条可复制的业务闭环跑通：找到好客户，确认值得做，生成可信资料，做出网站样本，再把它卖出去。

总目标

把 roofer lead 做成一条稳定流水线：

lead 进入系统
→ 快速排除
→ 找出高潜客户
→ 背景调查和身份确认
→ master.md 总档案
→ 建站资料包
→ 一页网站样本
→ audit 和事实检查
→ 销售材料
→ outreach
→ 结果回写

商业判断：

• 筛选客户约占成功的一半。筛选错了，后面建站和销售都会浪费。
• 建站和销售约占另一半。网站样本不是终点，能变成销售材料才有商业价值。
• master.md 是每个 lead 的总档案。搜索、audit、评价、图片、ABN、牌照、销售话术、建站资料，都要能追溯回这里。
• 免费、快速、低成本的检查必须尽早使用，用来排除大多数不适合客户。
• 慢工具、登录读取、付费 API、深度 audit，只给已经值得继续的客户。
• 搜索结果可以来自官网、目录页、论坛、报价平台、社媒、评价站。关键不是来源类型，而是它是不是同一个客户。
• Design / 建站不能直接使用搜索候选和 AI 猜测。能写进网站的事实必须有更强来源。

Milestone 1 · 业务现状盘点清楚

目标

把当前 roofer lead 池讲清楚：谁已经排除，谁值得继续，谁缺资料，谁可以进入建站资料包，谁只能做内部概念。

当前依据

• 现有路线图已锁定 roofer-only，总线是发现客户、判断入口、快筛、采集、audit、master.md、销售资料和建站资料包。
• 当前无网站 starter 状态：Mr Roof Solutions 发布前事实锁 PASS；NP Roof Repairs、Ultra Roof Restorations、Prime Roof Restorations 都已有 starter 概念包，但发布前缺 ABN。

产出

• 一张 lead 状态表。
• 每个 lead 至少有四个字段：当前状态、为什么继续或排除、下一步动作、当前卡点。
• 非 roofer、重复、旧标准、冲突资料准备归档或标成暂停。

完成标准

• Matthew 打开 SSOT 页面或文档时，能一眼看出当前客户池真实状态。
• 每个重点 lead 都有明确下一步，不再散落在不同文档里。

Milestone 2 · 快速筛选规则定死

目标

把便宜、快速、不花钱的检查提前，用它们排除大多数不适合客户。

优先使用的快工具 / 快信号

• 是否有官网。
• 官网是否能打开。
• Google Place 基础信息。
• 电话、地址、服务区是否清楚。
• 页面加载是否很慢。
• 首页是否缺电话、CTA、服务区、本地信任信号。
• 页面规模是否太大，超出当前一页网站能力。
• 网站是否已经做得不错，例如结构完整、SEO 够好、有广告 tracking、有成熟转化路径。
• ABN / 牌照是否能低成本确认。
• Tinyfish / direct fetch 是否能快速读首页。
• PageSpeed 是否能给出明显销售切入点。

筛选结果

• 直接排除：不是 roofer、假公司、目录站、中介 lead-gen、网站已经很好、页面太复杂。
• 继续观察：资料不足、身份没完全确认、ABN / 牌照有风险但还不能判死。
• 加优先级：没有网站、网站很差、速度慢、缺强 CTA、服务区清楚、评价多、电话清楚。
• 进入深挖：我们有把握用一页网站解决明显问题，并且客户可以被联系到。

完成标准

• 每个快筛信号都写清楚：排除、观察、加分、减分，还是进入深挖。
• 快筛后能明显减少需要深度 audit 的客户数量。

Milestone 3 · 搜索和身份确认流程跑稳

目标

解决核心风险：搜出来的结果到底是不是同一个客户。

两条入口

• 入口已有官网 / Google Place：先做快筛，搜索放到后期补背景资料。
• 入口没有官网：搜索放在第一步，用来找官网、Google Place、电话、地址、社媒、目录页、报价平台等。

AI 判断重点

• 公司名是否匹配。
• 电话是否匹配。
• 地址或服务区是否匹配。
• logo / 品牌是否匹配。
• 行业是否匹配。
• 页面内容是否指向同一个客户，而不是同名公司。

搜索结果分层

• 可用于网站事实。
• 可用于销售参考。
• 只做背景理解。
• 需要登录后再读。
• 明确不是同一个客户，保留丢弃原因。

完成标准

• 搜索结果不会直接污染客户正式档案。
• AI 可以自动判断大多数来源，但每个来源都有使用边界。
• 登录来源有清单，Matthew 可以后续注册账号，OpenCLI 再读取。

Milestone 4 · master.md 分层写入

目标

所有进入系统的 lead 都有 master.md，但内容不能混成一锅。

master.md 要承接

• 入口信息。
• 快筛结果。
• 官网和 Google Place 信息。
• 搜索和身份判断。
• ABN / 牌照观察。
• 评价、图片、服务区、服务项目。
• audit 发现。
• 销售切入点。
• 建站资料来源。
• 不确定资料和丢弃原因。

分层规则

• 核心事实：可以进入建站资料。
• 外部背景：可以帮助理解客户，但不能直接写成网站承诺。
• 销售参考：可以用于 sales angle，不能当硬事实。
• 待确认：保留，但不进入网站。
• 已排除来源：保留原因，避免下次重复误用。

完成标准

• master.md 是真正的总档案。
• audit report、销售材料、建站资料包都从 master.md 和已核实事实抽取。
• 不再出现另起一套资料源绕开 master.md。

Milestone 5 · 建站资料包跑通

目标

从 master.md 抽出 Design / 建站能直接使用的资料，而不是让模型随便读一大坨资料乱写。

当前稳定路线

core-extract.json
→ site-ctx.json + facts.json
→ handoff/content/*
→ handoff/od-package/content/*
→ single-page-brief.yaml
→ 网站文案和页面

必须保护的事实

• 公司名。
• 电话。
• 地址。
• ABN。
• 牌照。
• 服务项目。
• 服务区。
• 评价和真实客户语言。
• brand tokens / logo 来源。

完成标准

• Design 拿到的是清楚的开工包，不是杂乱 research dump。
• 搜索候选、社媒候选、目录页候选不会直接进入网站事实。
• 有 logo 的客户走 existing logo 路线；没 logo 的 starter 走 demo brand kit，但必须标清可替换。

Milestone 6 · 第一个完整客户样本跑通

目标

拿一个真实客户跑完整闭环，验证不是纸面流程。

推荐样本

Mr Roof Solutions。

原因

• 已有 master.md。
• 已有建站资料。
• 已有 brand kit。
• 发布前检查已通过。
• 仍有 licence 冲突需要在销售和公开文案前处理，正好验证事实边界。

产出

• 一页网站样本。
• 网站事实检查。
• 不确定资料清单。
• 可展示截图。
• 内部说明：哪些能公开说，哪些只能销售参考，哪些不能用。

完成标准

• 从 master.md 到网站样本可以走通。
• 网站内容没有编造 ABN、牌照、电话、地址、评价。
• 这个样本可以作为后续客户的模板。

Milestone 7 · 销售材料和 outreach 包跑通

目标

网站做好之后，要变成能卖的材料。

销售包至少包括

• 客户现状问题。
• 我们能解决什么。
• before / after 叙事。
• 新网站截图。
• audit 证据。
• 简短 presentation。
• cold email / DM / 电话话术。
• 客户可打开的页面链接。
• 风险说明：哪些资料需要客户确认后才能上线。

完成标准

• 销售材料能直接解释“为什么这个客户应该买”。
• 销售材料里的每个关键 claim 都能追溯回 master.md 或 audit 证据。
• 网站样本不只是内部 demo，而是能服务成交。

Milestone 8 · 批量复制和结果回写

目标

把单个样本变成可重复系统。

批量动作

• 从当前 ready lead 里筛 Top 5。
• 每个 Top lead 都有下一步动作。
• 对高潜客户才跑慢工具和深度资料。
• 对不适合客户记录排除原因，不再重复花资源。
• outreach 结果回写到 master.md 和客户状态。

排序标准

• 客户身份是否确认。
• 联系方式是否清楚。
• 是否没有网站，或网站有明显大问题。
• 我们做一页网站是否能明显改善。
• 资料是否足够生成网站。
• 销售理由是否强。
• 发布前风险是否可控。

完成标准

• 系统能持续告诉我们：下一个最值得做的客户是谁。
• 每个客户都有状态、证据、下一步。
• 筛选、建站、销售、回写形成闭环。

推荐推进顺序

1. 先完成 Milestone 1：把当前 roofer lead 状态表锁清楚。
2. 再补 Milestone 2：把快筛排除规则变成可执行清单。
3. 然后推进 Milestone 6：用 Mr Roof Solutions 跑第一个完整样本。
4. 样本跑通后，回头用 Milestone 7 生成销售包。
5. 最后进入 Milestone 8：批量挑 Top 5，开始复制。

当前下一步

下一步不是再讨论大方向，而是进入 Milestone 1：

盘点当前 roofer lead
→ 标出排除 / 保留 / starter / website-ready / sales-ready
→ 每个重点 lead 写下一步动作
→ 把状态同步到 SSOT 页面

Milestone 1 · 当前 roofer lead 状态盘点

2026-06-04。只读本地资料生成，不联网、不调用 Docker、不调用 Places、不写客户档案。来源命令：node --env-file-if-exists=.env.local scripts/cli/pl-design-material-readiness-replay.js --all-roofers --examples-per-status 999 --json。

目标

先把当前 roofer lead 池讲清楚：哪些已经排除，哪些值得继续，哪些能给 Design / 建站，哪些只是内部 starter 概念。

这一阶段不做新客户网站，不跑慢工具。先把状态表锁住，避免后面 Top 5 被错误客户、重复客户、非 roofer 客户污染。

当前总数

快筛分布

当前可进入建站资料准备的客户

无网站 starter ready

有网站 material ready

需要先清理的风险点

1. ready 列表里有疑似非 roofer

C.J Honeysett Plumbing 当前被算进 website_material_ready，但名字明显像 plumbing。它需要进入 roofer-only 清理队列，不能直接进入 Top 5。

2. ready 列表里有重复客户

这些客户至少出现过两条 ready 记录，需要先合并再排序：

• Ace Roofing Service。
• L.J. Ellery Roofing Pty Ltd。
• Geraldton Roofing。

3. “资料 ready”不等于“最值得卖”

website_material_ready 只说明资料够准备 Design / 建站，不等于它一定是最好的销售对象。

进入 Top 5 前还要再看：

• 是否真是 roofer。
• 是否重复。
• 网站问题是否足够大。
• 我们的一页网站能不能明显解决问题。
• 客户是否容易联系。
• 销售理由是否清楚。
• 发布前事实风险是否可控。

Milestone 1 结论

当前客户池不是空白，已经有一批可以继续推进的对象：

• 4 个无网站 starter ready。
• 24 个有网站 material ready。

但进入下一步前，必须先做两件事：

1. 清理 ready 列表里的非 roofer 和重复客户。
2. 把 28 个 ready 候选重新按商业价值排序，挑出 Top 5。

下一步

进入 Milestone 2 前，先补一张 Top 5 候选排序表：

28 个 ready 候选
→ 去掉非 roofer
→ 合并重复客户
→ 按“没有网站 / 网站大问题 / 联系清楚 / 资料够 / 销售理由强 / 发布风险低”排序
→ 选出 Top 5

Milestone 1 · Top 5 候选初版

2026-06-04。基于当前本地 ready 候选做的只读排序。不联网、不调用慢工具、不写客户档案。这个表是“下一步优先级”，不是最终销售名单。

排序原则

优先级不是只看“资料 ready”。真正要看商业价值：

1. 没有独立官网，或者入口没有官网且资料足够。
2. 有网站但问题很明显，我们的一页网站能明显改善。
3. 客户能联系到。
4. 评分和评价数量足够支撑销售。
5. Design / 建站资料已经够用。
6. 发布前风险可控，例如 ABN、牌照、官网身份冲突。
7. 不是重复客户，不是非 roofer。

先清理

当前 28 个 ready 候选里：

• 去重后大约 25 个候选。
• C.J Honeysett Plumbing 需要先从 roofer Top 5 排序里拿掉。
• Ace Roofing Service、L.J. Ellery Roofing Pty Ltd、Geraldton Roofing 有重复记录，进入 Top 5 前要合并。

Top 5 初版

Top 5 下一步资源投入表

备选梯队

如果要优先验证“有网站但问题很大”的路线，可以从这些里选：

Milestone 1 完成判断

Milestone 1 的业务状态已经清楚：

• 不是没有客户，而是需要从 ready 候选里挑最值得投入的少数。
• 当前最适合跑完整闭环的是 Mr Roof Solutions，因为资料链最完整。
• 当前最适合验证“真正无网站 starter”的是 Ultra Roof Restorations。
• 当前最适合验证“有网站强问题”的是 Triple C 或 iFix。

下一步建议

进入 Milestone 2 时，先把快筛规则和 Top 5 选择规则对齐：

快筛排除大多数
→ ready 候选去重 / 去非 roofer
→ 按商业价值排 Top 5
→ Top 1 跑完整闭环
→ Top 2-5 只准备下一步，不立刻花慢资源

第一条完整闭环我仍建议用 Mr Roof Solutions，因为它最接近“能从 master.md 到网站样本再到销售材料”的完整演示。 但销售叙事要写准确：它不是纯粹“没有网站”，而是“入口没有官网，后期确认了官网，因此要把官网现状也纳入对比”。

Milestone 2 · 快筛规则到 Top 5 选择

2026-06-04。目标：把“便宜快速筛选”真正接到商业决策。不是筛完就完，而是决定下一步花多少资源。

一句话

快筛的目的不是找到所有可能客户，而是尽早排除大多数客户，把资源集中到少数最可能成交、最适合一页网站产品的 roofer。

当前快筛桶怎么用

快工具优先级

这些工具 / 信号要尽早用：

Top 5 进入条件

进入 Top 5 前必须先过这几步：

1. 是 roofer，或者至少主营 roofing。
2. 不是重复客户。
3. 能联系到。
4. 身份基本可信。
5. 没有网站，或者网站有明显大问题。
6. 一页网站能明显帮到他。
7. 建站资料够，或者补资料成本很低。
8. 销售理由讲得清楚。

直接排除

这些不进入 Top 5：

• 非 roofer。
• 目录站、报价站、中介 lead-gen。
• 明显假公司或身份不稳。
• 网站已经很好。
• 页面规模太大，当前一页网站产品不适合。
• 业务太复杂，需要多页、多产品、多系统。
• 评价差到问题不在网站，而在服务本身。

只保留，不深挖

这些可以保留，但不花深度资源：

• 有一点网站问题，但评价数太少。
• 身份还不稳。
• 能联系，但销售理由不强。
• 快筛没有看到大问题。
• 可能适合群发轻触达，但不适合单独做网站样本。

值得深挖

这些才允许进入 Top 5 或慢工具：

• 无官网入口，评分高、评价多、电话和 Place 身份清楚。
• 有官网，但 audit / 快筛显示明显旧、慢、缺 CTA、缺信任、缺服务区。
• 资料已经能支持建站，或者只差一个低成本补项。
• 销售说法能很直接：我们能修什么、为什么这会带来更多咨询。

当前 Top 5 和规则的关系

ready 候选清理结果

当前 ready 候选共 28 个。清理后，真正进入排序池的大约是 24 个。

非 roofer 风险

处理方式：

• 不直接删除客户档案。
• 先从 roofer Top 5 排序池移出。
• 后续如果确认主营包含 roofing，再单独恢复。

重复客户

处理方式：

• Top 5 排序时先合并，不让同一个客户占两个名额。
• 真正合并 entity / archive 重复记录要另开一次小修，不能在文档里假装已经完成。

排序池口径

从现在开始，Top 5 排序使用这个口径：

28 个 ready 候选
→ 移出明显非 roofer 风险 1 个
→ 合并 3 组重复
→ 剩约 24 个真实候选
→ 按商业价值排序

Milestone 2 完成标准

Milestone 2 做完时，应该能回答：

• 为什么 219 个不进 Design。
• 为什么 28 个 ready 里不是每个都值得做。
• 为什么 Top 5 是这几个。
• 每个 Top 5 该花什么资源，哪些资源先不花。
• 哪些客户只能轻触达，不能深挖。
• 哪些 ready 候选先排除出 Top 5 排序池，因为非 roofer 或重复。

下一步

继续推进时，优先做两件事：

1. 对 Mr Roof Solutions 做“入口无官网 → 后期找到官网”的路线修正，再决定它的网站样本和销售叙事。
2. 给 Top 5 每个客户写“下一步资源投入表”：哪些可以立刻做网站样本，哪些只补 ABN，哪些先复核网站复杂度。

Milestone 6 · Mr Roof 第一个完整闭环样本

2026-06-04。目标：用 Mr Roof Solutions 跑第一条完整业务闭环：master.md → 建站资料 → 网站样本 → 事实检查 → 销售材料。这不是批量建站，而是验证整条业务流程能不能从头走到尾。

为什么选 Mr Roof

Mr Roof Solutions 当前最适合做第一个完整样本：

• Google 评分 4.9，65 reviews，有业务基础。
• master.md 已存在并刷新。
• single-page-brief.yaml 验证 PASS。
• ABN 已有：76656868905。
• QBCC 牌照已从 registry 写入：15365053。
• 电话、地址、服务种子、服务区候选已有。
• 现有 logo 已从确认官网提取，并生成 brand kit。
• 外部资料已分层：Design 可用 2 条，sales only 2 条，context only 2 条。

路线修正

Mr Roof 不是简单的“完全没有网站”客户。

准确说法：

入口数据没有官网
→ 按无网站 starter 路线补资料
→ 后期搜索确认 mrroof.com.au 与客户同名同电话
→ 可用官网 logo / brand 作为建站素材
→ 但官网 licence 与 registry/master 有冲突，公开文案必须用 locked facts

所以销售材料不能说：

你没有网站。

应该说：

你在 Google / lead 入口里没有清楚带出可用官网；
我们后续确认了官网和品牌资料，但现有线上资料还需要统一和转化强化。

当前事实边界

可以公开使用

可以给 Design 做文案种子，但不能当硬事实

只能给销售 / 内部参考

不能用

第一条闭环要产出什么

1. 建站资料

必须已有或生成：

• clients/mr-roof-solutions/v2/master.md
• clients/mr-roof-solutions/v2/core-extract.json
• clients/mr-roof-solutions/v2/site-ctx.json
• clients/mr-roof-solutions/v2/handoff/od-package/content/external-material.json
• clients/mr-roof-solutions/v2/handoff/od-package/brand/brand-tokens.css
• clients/mr-roof-solutions/v2/single-page-brief.yaml

当前状态：已具备，single-page-brief PASS。

2. 网站样本

目标不是做最终上线版本，而是做一个可展示的一页样本。

页面应该强调：

• Redlands / Cleveland local roofing trust。
• Roof repairs、roof restoration、gutter and roof maintenance。
• 1300 电话强 CTA。
• QBCC / ABN 只用 locked facts。
• Google 评分和评价数可作为信任信号。
• Logo / brand 来自已确认官网。

页面不能写：

• 未确认奖项。
• 未确认 iSwirl 官方身份。
• 冲突 QBCC。
• “没有网站”这种不准确说法。

3. 事实检查

网站样本生成后必须检查：

• 电话是否一致。
• ABN 是否一致。
• QBCC 是否只用 15365053。
• 没有出现 15346199。
• 没有把 award / iSwirl 写成客户硬 claim。
• 没有把 geo-derived suburbs 写成客户确认服务区。

4. 销售材料

网站样本之后，要生成销售材料：

• 现有线上资料不统一的问题。
• Google 入口和官网资料需要统一的问题。
• 新页面怎么提高信任和转化。
• before / after 截图。
• 简短 email / DM 话术。
• 客户可打开的样本链接。

当前已生成：

当前销售路线：

首选 phone / contact form
原因：locked facts 里没有已验证 email；电话已验证。

外发话术不能直接说“你没有网站”，也不能说样本已经可以直接上线。正确角度是：

你们公开资料在 Google / 官网 / licence 展示上不够统一；
我们做了一个保守的一页预览，把 verified phone / ABN / QBCC 保持一致，
并把未确认的奖项、合作方、服务范围说法都先拿掉。

当前已完成检查

下一步

当前 Mr Roof 已经能用现有建站链生成一个“事实安全的 starter 预览”，但还不是可发布客户站。

已验证：

node scripts/test/test-cycle27-starter-fact-locked-compose.mjs
node scripts/test/test-cycle27-mr-roof-sales-pack.mjs
node scripts/outreach/capture-assets.js --file clients/mr-roof-solutions/v2/outreach/sales-pack.json --timeout 45000
npm run pl:validate-single-page-brief -- --slug mr-roof-solutions
npm run pl:fact-verify -- --slug mr-roof-solutions
npm run pl:audit-v4 -- --slug mr-roof-solutions --tier fast

当前 audit-v4 fast 结果：

T1: PASS
T2: 91/100
Composite: N/A_BLOCKED
Reason: GATE 3 · minimum_content_signal · services 4 / suburbs 2 / reviews 1 · need 3/3/(1 or banner)

业务判断：

• 可以继续作为内部 starter 样本和销售材料基础。
• 不能把它说成“可直接上线”的客户站。
• 下一步要补的是可公开使用的服务区/评价/页面证据，或者在 starter 销售材料里明确标注哪些是预览占位。
• 已退掉未确认默认 claim：free quote、emergency/storm、Colorbond replacement、冲突 QBCC 15346199、award / iSwirl。

Milestone 7 · Outreach 使用与回写闭环

2026-06-04。目标：网站样本和销售材料不是终点。它们必须能被拿去联系客户，并且每一次联系、回复、跟进、跳过、成交交接都能回写到系统里，避免销售动作散在聊天记录或人工记忆里。

当前路线

Mr Roof 当前已经走到：

master.md / site-ctx
→ fact-safe starter website
→ audit-v4 fast
→ sales-pack.json / sales-pack.md
→ desktop screenshot / mobile screenshot / scroll video
→ 销售看板识别为 mockup_ready

销售过程到底看哪里

主工作台是后台：

/admin/leads

它读取现有 lead/outreach index，把每个客户放进销售阶段：

new_lead
→ researching / needs_human
→ ready_for_mockup
→ mockup_building
→ mockup_ready
→ draft_ready
→ outreach_sent / follow_up_due / replied
→ paid_handoff / skipped

Discord 不是唯一销售系统。Discord 的作用是：

• 在频道里看得到 profile card / 阶段变化 / 人工提醒。
• profile card 的联系方式必须和后台 profile 同口径：邮箱、电话、官网、Contact us、GMB、社媒、地址、推荐触达方式。
• 给 operator 留下可见记录，避免“系统说做了，但频道里看不见”。
• 后续可以同步后台动作，但不能取代后台看板。

所以当前关系是：

后台 admin pipeline = 销售推进主工作台
Discord channel/profile card = 可视化同步层 + 人工提醒层
master.md / v2/outreach = 客户资料和销售记录的长期保存位置

Profile 必须保存的联系渠道

每个进入系统的 lead，不管最后做不做，都必须在 profile 里集中保存所有能联系客户的入口：

当前统一字段：

record.contactProfile

它会被后台 /admin/leads 使用，显示在 lead profile、CRM 快照、审计表格和搜索里。这样销售时不用到处找邮箱、电话、官网、社媒和地址。

真实看板状态：

为什么 M7 很重要

筛选和建站做得再好，如果销售动作没有回写，就会出现三个问题：

• 不知道这个客户到底有没有联系过。
• 不知道下一次什么时候跟进。
• 客户回复的信息没有进入后续建站、报价、成交判断。

所以 M7 的核心不是“写一封更好看的 email”，而是：

销售动作必须回到 v2/outreach
销售结果必须改变看板状态
客户回复必须成为后续 master.md / 网站 / 报价的输入

当前已接通的回写位置

所有 v3 roofer 客户优先写这里：

clients/<slug>/v2/outreach/lead-notes.jsonl

Mr Roof 对应：

clients/mr-roof-solutions/v2/outreach/lead-notes.jsonl

已验证：

node scripts/test/test-cycle27-roofer-outreach-note-v2.mjs

结果：

PASS · v3 roofer outreach notes write to v2 and update the sales index

事件怎么记录

1. 第一次联系

使用：

npm run funnel:record-lead-note -- --client mr-roof-solutions --company "Mr Roof Solutions" --note "Called the business and asked who should receive the preview." --next-follow-up-due 2026-06-07

应该写入：

clients/mr-roof-solutions/v2/outreach/lead-notes.jsonl

看板状态：

mockup_ready → follow_up_due

2. 客户回复

客户明确回复时，记录 action：

npm run funnel:record-lead-note -- --client mr-roof-solutions --company "Mr Roof Solutions" --action mark_replied --note "Owner replied and asked to see the preview link."

看板状态：

replied

下一步：

处理 prospect 回复
→ 决定补资料 / 发样本 / 进入报价 / 继续跟进 / 跳过

3. 安排下一次跟进

如果客户没回，但有明确下次动作：

npm run funnel:record-lead-note -- --client mr-roof-solutions --company "Mr Roof Solutions" --note "Sent contact form message. Follow up by phone." --next-follow-up-due 2026-06-10

看板状态：

follow_up_due

4. 跳过

如果连续跟进无意义，或者客户明确不适合：

npm run funnel:record-lead-note -- --client mr-roof-solutions --company "Mr Roof Solutions" --action skip_lead --note "No response after follow-up; keep out of active sales queue."

看板状态：

skipped

5. 成交交接

客户明确有兴趣并进入正式报价 / 成交时：

npm run funnel:record-lead-note -- --client mr-roof-solutions --company "Mr Roof Solutions" --action move_to_paid_handoff --note "Customer wants the website scoped and priced."

看板状态：

paid_handoff

当前代码验证

master.md 如何吃回写记录

scripts/leads/build-master-md.js 现在会读取：

clients/<slug>/v2/outreach/lead-notes.jsonl

然后在 master.md 里生成：

## Outreach 回写记录

这一段会显示：

• 最近一次销售动作。
• 下次跟进日期。
• 最近 8 条触达 / 回复 / 人工决定记录。
• 记录来源提醒：客户回复里的新事实不能直接进网站，必须先分层。

客户回复里的新事实怎么处理

客户回复不是“直接写网站”的通行证。M7 现在把客户回复里的事实分成四类：

当前规则：

• 客户确认的 service_list、suburbs_served、specialties 可以变成 Design 种子。
• 电话、邮箱、地址、ABN、QBCC / licence 这类硬事实必须走正式更新，不能只凭一句回复改网站。
• 奖项、官方认证、品牌授权、installer 身份必须要证据，默认进入 needs_confirmation_facts。
• 未确认来源的回复直接进入 blocked_facts。

复杂回复用 JSON 输入：

npm run funnel:record-lead-note -- --input tmp/mr-roof-reply.json

示例 payload：

{
  "client_slug": "mr-roof-solutions",
  "company": "Mr Roof Solutions",
  "actor": "matthew",
  "action": "mark_replied",
  "note": "Owner replied with services and asked to see the preview.",
  "customer_confirmed": true,
  "customer_facts": {
    "service_list": ["roof restoration", "gutter repairs"],
    "phone": "1300 999 999",
    "awards": ["Best Roofing Business 2025"]
  }
}

会写入：

clients/mr-roof-solutions/v2/outreach/lead-notes.jsonl
clients/mr-roof-solutions/v2/outreach/customer-reply-facts.jsonl

仍要继续补的地方

下一步必须补：

• 如果客户回复补了服务区 / 评价 / 项目照片，要能触发重新生成 site-ctx、网站样本和 audit。
• 如果客户确认 logo / 品牌偏好，要回到 v2/brand，影响后续模板语言。

M7 当前结论

M7 已经从“有销售材料”推进到“销售材料能进入看板，第一次触达/跟进能回写，master.md 能显示 outreach history，并且客户回复事实会先分层”。

但 M7 还没有完全结束，因为“客户回复事实 → 自动刷新 site-ctx / 网站 / audit”的触发规则还要继续接。

模块 7 · 建站内容（中文）

目标：说明 master.md 之后，系统怎么把客户资料变成网站可用的事实、文案、服务、评价、覆盖区域和最终建站输入。

一句话

模块 7 不是“让模型读 master.md 随便写网站”。

它分两条线：

1. 事实线：确定性生成，不能编。
2. 文案线：LLM 写 hero、服务、about、FAQ，所以必须被事实锁和质检管住。

当前稳定顺序：

core-extract.json
→ pl:extract-site-ctx
→ site-ctx.json + facts.json
→ pl:enrich-handoff
→ handoff/content/*
→ pl:assemble-handoff
→ handoff/od-package/content/*
→ pl:build-single-page-brief
→ single-page-brief.yaml
→ pl:compose-editorial

代码和 SOP 依据：

• docs/v3/SOP-MASTER-MD-TO-WEBSITE.md:27-47
• docs/v3/SOP-MASTER-MD-TO-WEBSITE.md:80-100
• scripts/cli/_deprecated-guard.js:7-17

事实线：不能编

1. core-extract.json

core-extract.json 的核心是 brief.real_facts。这里放的是已经从客户资料、官网、评价、GBP 等来源抽出来的事实。

后面电话、地址、ABN、服务、服务区、评价、品牌信号，优先从这里走。

2. pl:extract-site-ctx

命令：

npm run pl:extract-site-ctx -- --slug <slug> --force
npm run pl:extract-site-ctx -- --slug <slug> --write-content --force

它读取：

• master.md 开头资料。
• core-extract.json 的 real_facts、brand_signals、ai_extensions、narrative。

它写出：

• clients/<slug>/v2/site-ctx.json
• clients/<slug>/v2/facts.json
• 可选：handoff/od-package/content/reviews.json
• 可选：handoff/od-package/content/coverage.json

代码依据：

• scripts/cli/pl-extract-site-ctx.js:1-27
• scripts/cli/pl-extract-site-ctx.js:237-339
• scripts/cli/pl-extract-site-ctx.js:365-456

注意：reviews.json 和 coverage.json 是从真实评价/服务区整理出来的，优先级比公式兜底高。

文案线：能写，但要管住

命令：

npm run pl:enrich-handoff -- --slug <slug>
npm run pl:enrich-handoff -- --slug <slug> --only B1,B2,B3

它写到：

clients/<slug>/v2/handoff/content/services.json
clients/<slug>/v2/handoff/content/about.md
clients/<slug>/v2/handoff/content/hero-copy.json
clients/<slug>/v2/handoff/content/faq.json

这一段会调用 LLM，所以是风险最高的一段：可能写得空、写得夸、或者把没有核实的东西写成承诺。

代码依据：

• scripts/cli/pl-enrich-handoff.js:1-16
• scripts/cli/pl-enrich-handoff.js:139-178
• scripts/cli/pl-enrich-handoff.js:188-215
• scripts/cli/pl-enrich-handoff.js:240-266

打包线：编辑稿和渲染稿分开

当前有两个内容目录：

handoff/content/               # 编辑稿，pl:enrich-handoff 写这里
handoff/od-package/content/    # 渲染稿，pl:compose-editorial 读这里

中间必须跑：

npm run pl:assemble-handoff -- --slug <slug>

它会把 handoff/content/* 复制到 handoff/od-package/content/*。

代码依据：

• scripts/cli/pl-assemble-handoff.js:123-168
• scripts/cli/pl-assemble-handoff.js:170-188

旧文案保护

如果编辑稿比渲染稿新，pl:compose-editorial 默认会停，不会悄悄用旧文案。

修法：

npm run pl:assemble-handoff -- --slug <slug> --skip-checkpoint

或者渲染时加：

npm run pl:compose-editorial -- --slug <slug> --auto-assemble

代码依据：

• scripts/cli/pl-compose-editorial.js:425-447
• docs/v3/SOP-MASTER-MD-TO-WEBSITE.md:80-90

最终事实锁：single-page-brief.yaml

命令：

npm run pl:build-single-page-brief -- --slug <slug>
npm run pl:validate-single-page-brief -- --slug <slug>

single-page-brief.yaml 是渲染前的最终事实锁。它不写文案，不调用 LLM，不补假事实。

优先级：

core-extract.json 的 real_facts
> master.md 开头资料
> null / data gap

它会特别保护：

• 电话。
• 地址。
• ABN。
• 牌照。
• 服务区。
• 服务项目。
• 成立年份。

牌照只信高把握的官方查询；AI 推出来的服务区候选不会被当作正式覆盖区域。

Design 开工包 v1

当前不要再走旧的 design-handoff.md / Open Design handoff 路线。带 pl:build-design-handoff 的旧命令已经被 _deprecated-guard 默认封住；它属于旧路，不是现在的建站主线。

现在给 Design / 建站看的开工包分两层：

Logo / brand 入口

brand_tokens_path 不是手工随便补一个颜色文件。它应该来自 logo / brand skill 的产物。

现有 skill 路线：

标准输出分两层，不能混：

clients/<slug>/v2/brand/

这是 logo / brand skill 的作者目录，也是 pl:assemble-handoff 的品牌来源。每次组装时，它会被快照进：

clients/<slug>/v2/handoff/od-package/brand/
  brand-assets.md
  brand-tokens.css
  brand-spec.json
  logo-dark.svg
  logo-light.svg
  logo-mark.svg
  logo-horizontal.svg 或 logo-wordmark.svg
  favicon.svg
  social-avatar.svg
  visual-style-contract.md
  agent-handoff.md
  logo-qa-checklist.md
  logo-review.md 或 source-logo-audit.md

代码依据：

• scripts/cli/pl-assemble-handoff.js:52-115
• scripts/cli/pl-assemble-handoff.js:179-183

写入这个目录后，single-page-brief.yaml 的 brand_tokens_path 应指向：

clients/<slug>/v2/handoff/od-package/brand/brand-tokens.css

这层解决的是“网站有品牌基础”，不是“客户已经批准最终 logo”。无网站 starter 可以先用 demo brand kit 做销售预览，但必须在销售材料里标清：logo / brand 可替换，不能假装是客户现有官方 logo。

Logo 设计语言边界

brand kit 不只是 logo 图片。它至少应该把这些设计语言写清楚：

• logo 的气质：硬朗 / 亲民 / premium / 工业 / 家庭服务感。
• 颜色角色：主色、强调色、深色区、浅色区、边框、正文。
• 字体方向：标题和正文应该贴近 logo 的性格，不能和 logo 打架。
• 形状语言：圆角、边框、阴影、图标线条要和 logo 几何感一致。
• 图片方向：真实工地 / 家庭屋顶 / 工业感 / 避免哪些 stock 风格。
• CTA 风格：按钮颜色、语气、电话优先级。

现有 skill 已经会产出：

visual-style-contract.md
agent-handoff.md
brand-assets.md
logo-qa-checklist.md

这些文件现在是给建站 agent / 人审读的视觉规则层。后续增强必须复用这层，不要另开一套“设计语言说明”。

A. starter 概念开工包

用于“无网站客户先做一版 starter 页面概念”。这层可以开始设计，但不代表已经可以发布。

必须有：

clients/<slug>/v2/master.md
clients/<slug>/v2/core-extract.json
clients/<slug>/v2/site-ctx.json
clients/<slug>/v2/facts.json
clients/<slug>/v2/single-page-brief.yaml
clients/<slug>/v2/handoff/od-package/content/coverage.json
clients/<slug>/v2/handoff/od-package/content/external-material.json

Design 可以用：

• single-page-brief.yaml：电话、地址、ABN、牌照、服务、服务区等事实锁。
• site-ctx.json：结构化业务资料、评价、FAQ seed、外部资料分桶。
• external-material.json 里的 design_usable_facts：身份确认后的服务、服务区、专长、项目线索、客户语言。
• external-material.json 里的 context_only_facts：只作背景理解，不能写成客户自己的 claim。

Design 不能用：

• 搜索候选链接。
• 未确认同一客户的社媒 / 目录页。
• sales_only_facts 里的老板名、年限、奖项、团队规模等敏感资料，除非后面有更强来源确认。
• blocked_facts 里的电话、地址、ABN、牌照、官网候选。

B. 发布前事实锁

发布前必须再跑：

npm run pl:validate-single-page-brief -- --slug <slug>

这层比 starter 开工包更严格。它会拦：

• 缺 ABN。
• 缺品牌 token。
• 服务区太薄。
• 电话格式不合规。
• 牌照状态不清。

所以结论是：

starter_material_ready = 可以开始准备 starter 页面输入
validate-single-page-brief PASS = 发布前事实锁通过

两者不是一回事。

2026-06-04 当前 4 个无网站 starter 的状态：

已跑 pl:geo-suburbs 给 4 个 starter 补了离线 geo_derived 区域候选，所以“服务区数量不足”的发布前卡点已解除；但这些只是“附近区域候选”，不能写成客户亲口确认的服务区。

代码依据：

• scripts/cli/pl-build-single-page-brief.js:1-18
• scripts/cli/pl-build-single-page-brief.js:47-71
• scripts/cli/pl-build-single-page-brief.js:98-128
• scripts/cli/pl-build-single-page-brief.js:149-172

渲染器读取顺序

pl:compose-editorial 读取：

• checkpoint.json
• core-extract.json
• single-page-brief.yaml
• handoff/od-package/content/*
• facts.json
• master.md
• 图片和品牌资料

内容优先级大致是：

代码依据：

• scripts/cli/pl-compose-editorial.js:364-457
• scripts/cli/pl-compose-editorial.js:776-806
• scripts/cli/pl-compose-editorial.js:870-884
• scripts/cli/pl-compose-editorial.js:1241-1262
• docs/v3/CANONICAL.md:30-37

发布前的内容保护

模块 7 至少有这些保护：

1. pl:data-checkpoint

- 数据太薄会挡住建站。 - 如果服务文案文件存在但为空/像停放域名，会变 RED。

1. pl:validate-single-page-brief

- 检查最终事实锁。

1. pl:compose-editorial freshness guard

- 防止用旧文案渲染。

1. ctx-snapshot.json

- 渲染后记录每个区块到底用了哪个来源。

代码依据：

• scripts/cli/pl-data-checkpoint.js:81-111
• scripts/cli/pl-data-checkpoint.js:251-262
• scripts/cli/pl-compose-editorial.js:420-447
• scripts/cli/pl-compose-editorial.js:1241-1262

当前结论

模块 7 已经有一条能跑的主路。

事实线相对稳：core-extract.json → site-ctx.json → single-page-brief.yaml。

主要风险在文案线：pl:enrich-handoff 写出来的 hero/services/about/FAQ 质量不一定稳定，所以后面模块 9 网站质检必须继续盯：

• 有没有编造牌照、成立年份、团队、价格、保修。
• 服务内容是不是空泛。
• 是否用了旧文案。
• 是否有跨客户内容残留。

本轮验证

本模块核对后需要至少跑：

node scripts/test/test-brief-builder.mjs
npm run test:content-validator-locked-facts
node scripts/test/test-data-checkpoint-service-content.mjs
npm run pl:publish-business-map -- --dry

模块 8 · 网站渲染（中文）

目标：说明网站 HTML 是怎么从模块 7 的内容资料生成出来的，哪些渲染方式是主路，哪些只是可选增强，哪些旧路不能碰。

一句话

当前网站渲染主路只有一条：

npm run pl:compose-editorial -- --slug <slug>

它输出：

clients/<slug>/v2/editorial-output/index.html
clients/<slug>/v2/editorial-output/assets/
clients/<slug>/v2/editorial-output/ctx-snapshot.json

代码依据：

• scripts/cli/pl-compose-editorial.js:1-27
• scripts/cli/pl-compose-editorial.js:1225-1325
• docs/v3/CANONICAL.md:89-98

输入

pl:compose-editorial 会读：

• core-extract.json
• master.md
• checkpoint.json
• single-page-brief.yaml
• handoff/od-package/facts.json
• handoff/od-package/content/*
• handoff/photos/selected.json
• handoff/od-package/brand/*
• stock 图片库
• 可选：layout-plan.json
• 可选：wireframes/wireframe-home-<llm>.json

代码依据：

• scripts/cli/pl-compose-editorial.js:5-19
• scripts/cli/pl-compose-editorial.js:364-457

默认模板

默认模板：

templates/roofing/editorial-newsletter/template.html

可选已收录模板：

npm run pl:compose-editorial -- --slug <slug> --template trade-classic

模板规则：

• editorial-newsletter：默认，偏温暖 editorial。
• trade-classic：更直接的澳洲 trade voice。
• 新模板不能随便加，必须走 template inventory SOP 和三客户校准。

代码依据：

• scripts/cli/pl-compose-editorial.js:355-362
• scripts/cli/pl-compose-editorial.js:1170-1174
• docs/v3/CANONICAL.md:20-37
• docs/v3/INFRASTRUCTURE-INVENTORY.md:299-310

默认是单页

当前 Phase B 只支持 roofing 单页网站。

不是多页站，不是整站 LLM 自由生成，也不是 OD daemon。

代码/文档依据：

• docs/v3/CANONICAL.md:27-29
• docs/v3/CANONICAL.md:89-98
• scripts/cli/pl-compose-editorial.js:1317-1322

质量门

生产渲染不能绕过 checkpoint.json。

pl:compose-editorial 默认会：

1. 要求 checkpoint.json 存在。
2. 如果 checkpoint.verdict === RED，直接停止。
3. 检查编辑稿和渲染稿是否有旧稿问题。

--skip-checkpoint 只能开发/排查时用，不能当生产路径。

代码依据：

• scripts/cli/pl-compose-editorial.js:420-447
• docs/v3/CANONICAL.md:107-128

输出溯源

渲染后会写：

editorial-output/ctx-snapshot.json

它记录每个区块用了哪个来源：

• hero：hero-copy.json 或公式兜底。
• services：services.json 或 core-extract。
• about：about.md 或 core-extract narrative。
• reviews：reviews.json 或真实评价兜底。
• coverage：coverage.json 或服务区兜底。

这个文件后面排查“页面上这段话从哪里来”很有用。

代码依据：

• scripts/cli/pl-compose-editorial.js:1241-1262

图片

图片有三类来源：

1. 客户真实图片。
2. stock-library 里的行业图。
3. layout-plan 指定的图片。

默认路径会复制 stock 图片和已有真实项目图。使用 --use-layout-plan 时，如果计划里指定了真实图片但文件不存在，会直接停止，不会默默换成别的。

代码依据：

• scripts/cli/pl-compose-editorial.js:408-415
• scripts/cli/pl-compose-editorial.js:673-723
• scripts/cli/pl-compose-editorial.js:826-859
• scripts/cli/pl-compose-editorial.js:1225-1315

Logo / brand 如何影响模板

现有模板系统已经吃进去一部分品牌信息：

• header / footer 会用品牌包里的 logo。
• favicon 会用品牌包里的 favicon。
• CSS 会注入 brand-tokens.css。
• 模板颜色使用 --brand-primary、--brand-accent、--surface、--text 等变量。
• pl:audit-v4 会检查 logo 引用、深浅背景上的 logo 版本、品牌颜色是否真的出现在页面里。

代码依据：

• scripts/cli/pl-compose-editorial.js:418
• scripts/cli/pl-compose-editorial.js:895-897
• scripts/cli/pl-compose-editorial.js:977-993
• scripts/cli/pl-compose-editorial.js:1264-1284
• templates/roofing/editorial-newsletter/template.html:29-43
• templates/roofing/editorial-newsletter/template.html:316-319
• templates/roofing/editorial-newsletter/template.html:577
• scripts/cli/pl-audit-v4.js:705-778

但当前还要诚实区分：

所以现在的原则是：

brand kit 先定调
→ compose-editorial 吃 logo + tokens
→ audit-v4 检查品牌一致性
→ 需要更强视觉适配时，只在现有 template / recipe / layout-plan 上增强

不能因为 logo 设计语言还没完全自动驱动模板，就绕开 pl:compose-editorial 去写另一套网站生成器。

可选增强：layout-plan / block / recipe

有一套新的灵活模块系统，但它不是默认批量主路。

命令：

npm run pl:plan-layout -- --slug <slug> --base
npm run pl:plan-layout -- --slug <slug> --recipe trust-heavy
npm run pl:plan-layout -- --slug <slug> --auto-recipe
npm run pl:compose-editorial -- --slug <slug> --use-layout-plan

它会写：

clients/<slug>/v2/layout-plan.json
clients/<slug>/v2/layout-plan.audit.json

可选 recipe：

• editorial-default
• trust-heavy
• visual-first
• local-seo

关键边界：

• pl:plan-layout 可以默认 smart 地规划模块。
• 但 pl:compose-editorial --use-layout-plan 默认是关的。
• 不加 --use-layout-plan，实际渲染还是老的单页模板。
• recipe / auto-recipe 要单客户看过后再用，不做全局默认。

代码依据：

• scripts/cli/pl-plan-layout.js:1-11
• scripts/cli/pl-plan-layout.js:58-107
• scripts/cli/pl-compose-editorial.js:396-407
• scripts/cli/pl-compose-editorial.js:1175-1223
• docs/v3/CANONICAL.md:30-37
• docs/v3/HANDOFF-NEXT-SESSION.md:24-44

旧渲染路已经封住

不要走：

• pl:compose-site
• OD daemon
• 整页 LLM 渲染
• V2 module library
• design-handoff 旧层
• wireframe-to-spec / template-remix 等旧实验路

这些命令有 seal guard，默认会拒绝运行。

代码依据：

• scripts/cli/_deprecated-guard.js:1-22
• docs/v3/CANONICAL.md:130-170

当前结论

模块 8 当前可批量使用的是：

npm run pl:compose-editorial -- --slug <slug>

可选增强是：

npm run pl:compose-editorial -- --slug <slug> --template trade-classic
npm run pl:plan-layout -- --slug <slug> --recipe <recipe>
npm run pl:compose-editorial -- --slug <slug> --use-layout-plan

但批量推进时，默认应先守住 editorial-newsletter 主路；recipe 和 real-photo layout 只对具体客户逐个打开。

本轮验证

本模块核对后需要至少跑：

npm run test:deprecated-seal
npm run test:layout-plan-parity
npm run test:recipe-spine
npm run test:auto-recipe
npm run pl:publish-business-map -- --dry

模块 9 · 网站质检（中文）

目标：说明网站渲染完成后，哪些检查会拦发布，哪些只是建议；以及手机端、事实错误、假牌照、内容太薄分别由谁抓。

一句话

网站建完不能直接发。当前质检分三类：

1. 发布硬门：数据不够、手机端硬问题、事实/身份错误、内容太薄。
2. 网站质量分：品牌、结构、证据、视觉、文案密度。
3. 买家视角建议：文案有没有打动目标客户。

主要命令

npm run pl:copy-audit -- --slug <slug>
npm run pl:audit-v4 -- --slug <slug> --tier fast
npm run pl:audit-v4 -- --slug <slug> --tier full
npm run pl:persona-copy-audit -- --slug <slug> --runs 3

代码依据：

• package.json:428-452
• scripts/cli/pl-copy-audit.js:20-25
• scripts/cli/pl-audit-v4.js:27-36
• scripts/cli/pl-persona-copy-audit.js:10-13

发布硬门

发布前按顺序看：

1. checkpoint.json

- RED：不发布。 - YELLOW：只能预览，并且页面要有 preview 提醒。

1. single-page-brief.yaml

- GREEN 客户必须有，并且要能验证。

1. 最小内容量

- 服务不能太少。 - 覆盖区域不能太少。 - 评价没有真实内容时，页面要明确是预览/占位。

1. 手机端硬问题

- 390px 不能横向溢出。 - 手机端要有 sticky CTA。 - 关键按钮/输入区域要够大。

1. 快速质检分

- T1 事实检查要过。 - 品牌/语气/证据/事实交叉检查不能明显低。

文档依据：

• docs/v3/CANONICAL.md:107-168
• docs/v3/SOP-AUDIT-STANDARD-V2.md:177-188

代码依据：

• scripts/cli/pl-audit-v4.js:1025-1102
• scripts/cli/pl-audit-v4.js:1390-1430
• scripts/cli/pl-audit-v4.js:1550-1631

pl:copy-audit 管什么

pl:copy-audit 主要管两件事：

1. 确定事实不能错。

- 商家名。 - 电话。 - 地址。 - ABN。 - 牌照。

1. 文案不能密度太离谱。

- hero 副标题太长。 - 服务描述太长。 - about 太长。

它不会因为普通营销话术、轻微泛泛而自动挡发布。那些是建议，不是硬门。

代码依据：

• scripts/cli/pl-copy-audit.js:1-25
• scripts/cli/pl-copy-audit.js:31-70
• scripts/cli/pl-copy-audit.js:300-339

pl:audit-v4 管什么

pl:audit-v4 是主质检工具。

fast 版：

npm run pl:audit-v4 -- --slug <slug> --tier fast

主要看：

• T1 硬事实和页面机械问题。
• T2 品牌和 token 纪律。
• 证据丰富度。
• 最小内容量。
• 手机端机械门。
• 事实是否和 single-page-brief.yaml 对得上。

full / premium 版会加视觉和设计判断，成本更高，结果会受模型波动影响，所以需要看模型和多次运行统计。

代码依据：

• scripts/cli/pl-audit-v4.js:1-39
• scripts/cli/pl-audit-v4.js:1025-1102
• scripts/cli/pl-audit-v4.js:1530-1631

手机端是硬门

手机端不是“扣一点分”。

这些会直接挡发布：

• 页面横向溢出。
• 没有手机端固定 CTA。
• 关键按钮/电话/表单小于 44x44。

代码依据：

• scripts/cli/pl-audit-v4.js:1390-1430
• docs/v3/CANONICAL.md:130-134
• docs/v3/SOP-AUDIT-STANDARD-V2.md:177-188

pl:persona-copy-audit 管什么

这是买家视角文案审查。

它会问：这个页面对这个客户画像有没有说服力？

它看 8 项：

• 是否适合这个买家的真实任务。
• 是否帮助他做决定。
• 是否回答顾虑。
• 是否用了正确的信任信号。
• 是否避免了会让他离开的表达。
• 信息深度是否合适。
• 语气是否匹配。
• 下一步是否清楚。

但它是建议，不是批量硬门。Matthew 可以用它来判断“这页值不值得发”，但系统不应该只因为这个分低就自动挡所有发布。

代码依据：

• scripts/cli/pl-persona-copy-audit.js:1-13
• scripts/cli/pl-persona-copy-audit.js:62-96
• core/audit/persona-copy-judge.js:1-27

当前结论

模块 9 当前的发布前最小检查应该是：

npm run pl:copy-audit -- --slug <slug>
npm run pl:audit-v4 -- --slug <slug> --tier fast

如果要更稳，再加：

npm run pl:persona-copy-audit -- --slug <slug> --runs 3
npm run pl:audit-v4 -- --slug <slug> --tier full --vision-runs 3

其中 persona-copy-audit 是买家视角建议；audit-v4 full 要看模型和波动，不能和不同模型跑出的旧分数直接比。

本轮验证

本模块核对后需要至少跑：

npm run test:fact-verify
npm run test:content-validator-locked-facts
node scripts/test/test-grid-balance.mjs
npm run pl:audit-v4 -- --slug vicwest-roofing --tier fast --json
npm run pl:publish-business-map -- --dry

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 已开始跑“抓正文 → 挖 external_facts”：Mr Roof 和 Ultra 已经产出 Design 可用外部素材；NP / Prime 这轮只帮助确认背景，没有挖到可写入的网站素材。
• 真实 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 素材移到销售/人工核实。
• 已补 OpenCLI 备用恢复命令：npm run pl:opencli-recover -- --profile z3wvy2xe --smoke-url <url>。它会检查 doctor、必要时重启 daemon、打开独立 Chrome profile 并加载 /Users/matthew/opencli-extension/v1.0.17，再跑 smoke；不点、不填、不抓业务内容，只恢复只读通道。
• Mr Roof Solutions 已真实写入外部资料区：pl:mine-background --write 成功写入 6 个 external_facts，real_facts.phone 仍是 1300 023 230。重建后 external-material.json 分桶为 2 design、2 sales、2 context：Design 只看到服务区和专长；奖项 / social proof 进销售核实；iSwirl 服务和认证进背景参考。
• Ultra Roof Restorations 已真实写入外部资料区：OpenCLI 读取 Facebook 主页后确认同一客户，写入 2 个 external_facts（service_list、suburbs_served），real_facts.phone 仍是 0484 621 090。重建后 external-material.json 分桶为 2 design、0 sales、0 context、0 blocked；Instagram 仍为不够确定，不写入。
• NP Roof Repairs / Prime Roof Restorations 已跑 pl:mine-background dry：目录页、问答页能作为背景调查来源，但这轮没有挖到可用事实；没有写入 external_facts。结论是：搜索结果的第一作用仍然是排除和确认，只有正文里有明确服务/区域/特色等信息，才进入 Design 资料包。
• 已修 1300 电话验证 bug：single-page-brief.yaml 生成器本来能输出 1300 023 230，但验证器只认 +61 电话；已补红测再修，让 1300/1800 商业电话能通过事实锁格式检查。

阶段 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。

但这里必须分清两层：

starter_material_ready = 可以准备 starter 页面输入
validate-single-page-brief PASS = 发布前事实锁通过

当前 4 个 starter 都已有概念开工包。Mr Roof Solutions 已先跑通 logo / brand kit 链路，其余 3 个还不是发布就绪：

已跑 pl:geo-suburbs 给 4 个 starter 补了 18 个离线区域候选，服务区数量卡点已解除；这些是 geo_derived 附近区域，不能写成客户已确认服务区。

品牌 token 缺口不需要人工硬补颜色。现有 logo/brand skill 路线已经确认：

标准输出目录是 clients/<slug>/v2/handoff/od-package/brand/，发布前 single-page-brief.yaml.brand_tokens_path 应指向 clients/<slug>/v2/handoff/od-package/brand/brand-tokens.css。

新增主线命令：

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 已开始跑外部正文挖掘。结果不是“搜索到就写入”，而是按客户分化：

这证明搜索/enrich 的定位应该是：先排除错误来源，再补强少数高价值客户；不是把所有搜索结果都塞进网站资料包。

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 也不能从外部资料直接进网站文案，必须先人工/强来源确认是客户自己的奖项。
• 已补备用方案：pl:opencli-recover 可自动恢复 Browser Bridge 连接，主动作是重启 OpenCLI daemon、打开独立 Chrome profile、加载本地 extension、再跑 smoke。
• Mr Roof 已完成真实写入：外部资料进入 external_facts，再分到 design_usable_facts / sales_only_facts / context_only_facts。Design 当前只得到服务区和专长；奖项和 iSwirl 相关内容不会变成网站 claim。
• Ultra 已完成真实写入：Facebook 登录源确认后进入 external_facts，再分到 design_usable_facts。这说明登录源不是初筛工具，但对后期深挖有价值。

目标客户画像

我们想要的客户

我们不想要的客户

两条主路径

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

搜索放在哪里，取决于 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：

备用方案：

1. 主路：opencliFetch 只读读取 Facebook / Instagram / LinkedIn。
2. 第一备用：pl:opencli-recover 自动检查 OpenCLI，必要时重启 daemon，并打开独立 Chrome profile /Users/matthew/.opencli/chrome-leads 加载 /Users/matthew/opencli-extension/v1.0.17。
3. 第二备用：如果 profile 没登录对应社媒，保留 login_required 清单，不阻塞 lead 主流程，也不把标题/摘要当事实。
4. 禁止做法：不能把 dry-run 结果手动写进 core-extract；必须 live smoke 通过，再由 pl:mine-background --write 写入外部资料区。

真实 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、牌照、地址等强证据，才可能升级。
• Mr Roof Solutions 已完成一次端到端：OpenCLI 恢复命令 smoke 通过后，pl:mine-background --write 写入 6 个外部资料；重建 external-material.json 后，Design 只得到服务区和专长，奖项 / social proof 只给销售核实，iSwirl 服务和认证进入背景参考。
• Ultra Roof Restorations 已完成一次端到端：OpenCLI 读取 Facebook 主页后确认同一客户，pl:mine-background --write 写入 2 个外部资料；重建后 2 条都进入 Design 可参考素材。Instagram 这轮仍不够确定，未写入。
• NP Roof Repairs / Prime Roof Restorations 已 dry run：登录/目录来源能辅助背景调查，但本轮没有挖到可写入的网站素材，所以不进入 external_facts。

当前样本统计

原始来源清单

完整机器生成清单：

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）

Copy 审计怎么放（前置为主，后置兜底）

Matthew 的判断是对的：copy 不能主要等页面出来以后才审。很多文案、排版、信息边界的问题，建站前多花一点时间更值，后面 audit 再补会很浪费。

现在 copy 分三层：

1. 生成前 / 打包时先审文案包

写文案源头已经统一注入客户可见边界：services / about / hero 都明确告诉 AI 哪些能发挥、哪些不能编。之后 assemble-handoff 会清洗客户可见文案；site-build-doctor 的 copy_package 会在渲染前检查 services / about / hero / FAQ 有没有漏出内部提示。比如 “before publishing / draft copy / primary contact path / customer confirmation” 这类话，不能进客户页面。 no-website / starter 路径也已前置：starter-core-extract 生成的 FAQ / hero 种子必须是客户可见语言，不能再出现 “starter page / before publishing / operator / SEO coverage claims” 这种内部话；老 build-handoff 的 roofer 默认 FAQ 也不能再编 24h、牌照、质保、保险理赔。 新增一关：site-build-doctor 会在 site-ctx 阶段先查客户可见种子（FAQ / hero / service brief）。如果上游 site-ctx.json 还残留内部提示，即使最终 HTML 暂时没污染，也先 BLOCK，要求重抽 site-ctx 和重打包，避免以后重跑又复发。 设计输入也已单独守住：customer-brief.md 可以是内部长简报，但给设计 / OD / 图片生成代理使用前必须先经过共享清洗，去掉操作员提示、发布前确认话术、starter page、operator、before publishing、the page should... 这类容易被复制到页面里的句子。starter customer brief 生成器本身也已改干净，Mr Roof 当前 customer-brief 设计输入检查 = PASS。

1. 页面出来后再审整体表达

copy-audit 不是用来替代前置检查，而是看最终页面：有没有事实错、文案堆砌、重复、转化弱、上下文不顺、模块组合后读起来不自然。它是兜底，不是主战场。

1. 重点客户再做人群视角审

准备给 Matthew 看、准备销售、或者客户价值高时，再跑 persona-copy-audit / 人眼快速看一遍。批量阶段不每个都花这份资源。

AI 可以发挥的边界：

• 可以写：服务好处、hero/subhead、about、FAQ、CTA、local marketing 表达、模块里的解释性文案。
• 可以补：不涉及硬事实的行业常识、用户痛点、屋顶维护常见问题、为什么要早点检查这种营销表达。
• 不能编：公司名、电话、地址、ABN、licence、owner、经营年限、真实评价原文、社交主页、价格、质保、紧急服务、保险/认证/获奖、具体服务区域。
• 没确认但可以写的，要写成保守表达：比如 “help with roof maintenance around the local area”，不能写成 “serving 18 suburbs for 20 years”。

Audit 资源怎么花（不要全量乱跑）

原则：能在建站前做对的，不等 audit 后返工；能用轻量工具发现的，不上重型视觉/付费工具。

建站前多花 10 分钟
→ 少做 1 小时 audit 修补
→ 少浪费一次视觉 / full audit / 人工看图

截图要做，但要放对位置：

• 不是每个早期薄资料客户都先截图。
• 生成页面并通过轻量检查后，才抓 desktop / mobile。
• 准备销售材料时，再加 scroll video。
• 有 sales-pack.json 的客户，site-build-doctor 会检查 desktop/mobile 截图和 scroll video 是否真的存在；缺了只 WARN 并提示 outreach:capture-assets，不把薄资料客户一刀切挡死。
• 视觉模型不是替代人眼；它适合重点客户复核，不适合批量低价值样本全跑。

当前推荐顺序：

资料 checkpoint
→ 文案和模块计划
→ brand / logo / design language
→ 生成页面
→ site-build-doctor
→ copy-audit
→ audit-v4 fast
→ 截图 desktop/mobile
→ 重要客户：persona-copy-audit / full vision audit / 人眼复核

三条要记住的

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

当前优先级：先把网站制作跑顺

现在先不优先做 sales，也不急着加一堆新模板。建站主链路要先能稳定回答：

数据输入够不够
→ AI copy 有没有生成、有没有同步到渲染稿
→ logo / brand kit 能不能被模板吃到
→ single-page-brief 事实锁有没有
→ 模板和 layout-plan 用的是哪条路
→ HTML 有没有生成，来源快照有没有
→ 电话 / 表单 / Logo / 品牌色 / 社交账号 / FAQ 有没有真正进页面
→ owner / 经验 / 社媒主页这些证明材料有没有真实来源，候选帖子不能直接进 footer
→ customer-brief 给设计代理前有没有清掉内部操作说明
→ audit 卡在哪个门

新增体检命令：

npm run pl:site-build-doctor -- --slug <slug>

它只读文件，不调用大模型，不改客户资料。输出每一站的 PASS / WARN / BLOCK 和下一步建议命令。

新增的「本地营销稳定检查」专门防这类浪费：

• 已确认的社交账号有了，但 footer 没显示。
• FAQ 资料够了，但页面没显示。
• services / about / hero / FAQ 这些渲染前文案包里已经漏出内部提示；不等 HTML / audit 后才发现。
• customer-brief.md 原文如果含内部操作说明，设计输入会先清洗；如果清洗后仍有内部话，才 BLOCK。
• FAQ 写了“已持牌 / VBA licensed / QBCC licensed”，但 single-page-brief 没有可显示牌照号。
• VBA / Victorian Building Authority 这种同一机构的简称/全称不能被误判成事实冲突。
• brand kit 有了，但 HTML 没吃到品牌色 / Logo。
• 电话、点击拨号、联系表单这些转化点缺失。
• 内部建站提示（比如 “before publishing / draft copy / primary contact path”）漏到客户页面。
• 已经进入销售包的客户，截图 / 手机截图 / 滚动视频没留档。
• audit summary 比最新 checkpoint 老，避免拿旧报告继续判断。

新增的「证明 / 触达补强」专门防这类误用：

• owner name / 经验年限没有真实来源，就只提示补强，不让 AI 猜。
• Instagram / Facebook / forum / directory 里抓到的帖子或提及，只能当背景候选；确认是客户自己的主页后，才可以进 footer。
• footer 社媒现在走同一条共享规则：只有 profile-like 的主页 URL 能显示；instagram.com/reel/...、Facebook group/post、profile.php、占位符 # 都不会进 footer。
• 已确认主页写进 locked_facts.social_links 后，site-build-doctor 会继续检查它有没有真的显示在 footer。
• ABN / licence 会从根目录 facts 和 OD 渲染包合并读取，避免真实资料存在但被误报成缺失。

新增的「无官网 / 社交证据」接法：

• OpenCLI / social / directory 这类已确认身份的外部资料，会落到 external-evidence.json。
• pl:data-checkpoint 现在会承认 identity_status=same、promotable=true、mined=true 的外部证据：它可以补 sources_consumed，也会给 real_business_signal 最多 4 个信号点。
• pl:llm-extract-core 会把同一份 external-evidence.json 放进大模型资料包，让搜索/enrichment 得到的资料真正进入网站文案和 customer brief。
• 这不是放松事实门槛：没有确认同一客户的社交/目录资料不计分，不进入客户可见文案。
• 服务区域不再用“8 个区域”挡 starter 网站：3 个可用区域就够进一页预览/audit；如果只有 2 个区域 + 有完整地址，single-page-brief 和 audit-v4 fast 都只 WARN，不 BLOCK，因为可以用 pl:geo-suburbs 按地址离线推断周边候选区。AI 猜的区域仍然不算确认事实。

当前 Mr Roof 真实体检结果说明：

网站已经能渲染
AI 文案包齐
brand / logo 基础齐
single-page-brief 已存在
layout-plan 已存在，recipe = trust-heavy
服务区域 = 2（Cleveland / Brisbane，地址支撑；最终销售前建议再补 1 个区域或跑 geo-suburbs）
copy-audit = APPROVE · 2 low findings（可接受的轻微文案优化建议）
site-ctx 文案种子 = PASS（FAQ / hero 不再有 starter page / before publishing / SEO coverage claims）
设计输入简报 = PASS（customer-brief 可直接作为干净设计输入）
AI 文案包 = PASS（services/about/hero/FAQ 渲染前已无内部提示）
FAQ 模块 = PASS（layout-plan trust-heavy 已渲染进页面）
视觉留档 = PASS（desktop/mobile 截图 + scroll video 已存在）
audit-v4 fast：T1 PASS，品牌 91/100，Composite 91，Grade A，Verdict SHIP
当前主要卡点：
  1. checkpoint = YELLOW：核心资料已够预览，但最终销售前还要补强薄资料
  2. customer-brief 已有 deterministic starter 版本（3913 words / 19 sections），设计输入检查 PASS
  3. checkpoint rich = 4/6：服务/区域/Google 评分摘要已可用；仍缺 owner / experience 的真实来源
  4. proof/contact = WARN：ABN/licence 已确认；owner / experience 缺真实来源；Instagram 帖子是候选社媒，不能直接进 footer

结论：
  Mr Roof 当前 site-build-doctor = preview_ready。
  页面本身已经过 fast audit，可用于 starter preview / sales pack；
  但不叫最终发布 ready，直到薄资料补强为 GREEN。

所以接下来建站主线的优先顺序是：

1. 让每个候选客户都能跑 pl:site-build-doctor，一眼知道卡在哪。
2. 先补资料和内容闸门，让页面从 preview/starter 稳定进入可 audit 状态。
3. 再打开 layout-plan --auto-recipe / --use-layout-plan，把 FAQ / trust-heavy / local-seo 这类模块真正渲染进页面。
4. 模板新增放最后：只有现有 2 个模板和 recipe 不能覆盖真实客户时，再按 template inventory SOP 增加。

真实样本验证：

A-J Roofing Solutions
问题：FAQ 资料已经存在，layout-plan 也有 FAQ，但旧 HTML 没按 layout-plan 渲染，所以 FAQ 没进页面。
修法：pl:compose-editorial --auto-assemble --use-layout-plan
结果：site-build-doctor = ship_ready，audit-v4 fast = SHIP，copy-audit = APPROVE。

Mark Squire Roof Restorations
问题：FAQ 里写了 “Are you VBA licensed?”，但最终事实锁是 `license.status=omit`，不能显示牌照确认。
修法：渲染前自动过滤牌照确认类 FAQ；没有锁定牌照号就不让这类问答进页面。
结果：copy-audit 从 REJECT 变 APPROVE，site-build-doctor = ship_ready。

Vicwest Roofing
问题：FAQ / team / guarantee 有资料但旧页面没按智能模块渲染；另一个误报是页面写 `Victorian Building Authority`，事实锁写 `VBA`。
修法：`pl:plan-layout --auto-recipe` 选出 `trust-heavy`，再 `compose --use-layout-plan`；事实检查器接受常见牌照机构简称/全称。
结果：site-build-doctor = ship_ready，audit-v4 fast = SHIP，copy-audit 从 REJECT 变 APPROVE。

Mr Roof Solutions
问题：这是 thin-data / starter-preview 样本。页面能生成，但旧 `core-extract/site-ctx` 的 FAQ 和 hero 种子里一度残留 “starter page / before publishing / SEO coverage claims” 这种内部提示；另外 audit 旧规则会把 “2 个区域 + 完整地址” 错误挡在 Gate 3。
修法：生成前统一清洗客户可见文案；FAQ 守门不只查 licence，也会把内部建站 FAQ 拿掉；site-build-doctor 同一规则查 `site-ctx` 种子、`customer-brief` 设计输入、文案包和最终 HTML；`audit-v4` 与 brief 规则对齐，完整地址支撑的 2 个区域可预览，不再 BLOCK；checkpoint 不再要求 AI 编评论，Google 评分/评论数可作为无 quote 的证明摘要。
结果：site-ctx 种子 PASS，customer-brief 设计输入 PASS，本地营销稳定检查 PASS，copy-audit = APPROVE，audit-v4 fast = SHIP；checkpoint YELLOW，所以整体是 preview_ready，不是最终发布 ready。

当前架构的自由度（灵活模块系统 · 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。

五、质检在流程里的位置

质检不是只放在页面生成之后。

生成前 / 打包时
→ site-build-doctor 先查 site-ctx 的客户可见种子（FAQ / hero / service brief）
→ customer-brief 给设计/OD/图片生成前先清洗内部操作说明
→ assemble-handoff 清洗客户可见文案
→ site-build-doctor 的 copy_package 检查 services/about/hero/FAQ
→ 确保内部提示、待确认话术、不能展示的事实不进页面

页面生成之后
→ copy-audit 看最终页面诚实度 / 重复 / 堆砌 / 转化表达
→ audit-v4 看 5 个 P0 + 移动端
→ 重点客户再跑 persona-copy-audit / 人眼看

所以 copy-audit 是成品兜底，不是唯一文案把关；能在建站前审掉的问题，必须在建站前审掉。

六、薄资料 starter 的服务区域规则

不要再用“8 个区域”挡 starter 网站。

• 3 个可用区域：正常通过预览和 fast audit。
• 2 个区域 + 完整地址：允许预览，single-page-brief 只 WARN，audit-v4 fast 不用 Gate 3 BLOCK；最终销售前建议跑 pl:geo-suburbs 或补一个确认区域。
• 少于 2 个区域，或没有完整地址：继续拦住，避免页面看起来空、也避免 AI 编服务范围。
• AI 猜的区域不能当确认事实；只能放候选或用“nearby / by arrangement”这类保守表达。

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

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. 整理图片 / 链接入口到下游的实际接法。