site-consistency — 要约对齐文案 QA

网站一致性——与报价一致的文本审核

目标：网站上的每一段文本都讲述同一个故事——即主页上声明的报价——面向同一个客户，使用相同的承诺、名称和术语。先审核；仅修改用户批准的内容。

两条硬性边界：

1. 先审核后修改。 审核是只读的。在用户批准审核表的特定行之前，不得修改任何文件。
2. 仅文本。 本技能仅修改文字——绝不修改布局、样式、组件、图片、路由或页面结构。请参阅“仅文本编辑规则”。

语言

• 使用用户在对话中使用的语言与用户交流。报告、表头、严重性标签和“原因”列均使用该语言。
• 当前文本的引用需逐字保留原文。
• 建议的网站文本应以被替换文本的语言编写，需地道且符合习惯（绝非直译），并保留网站原有的称呼方式（例如波兰语的“Ty”/“Państwo”、德语的“du”/“Sie”）和语气。
• 通过 <html lang>、国际化配置、本地化文件和可见内容检测网站语言。对于多语言网站，确定主要语言环境；如果不清楚需要审核哪些语言环境，请询问。

工作流程

按顺序执行以下步骤。步骤1-6绝不修改文件。

步骤 1 — 侦察

阅读 references/text-inventory.md。确定：

• 技术栈和路由（URL如何映射到文件），
• 文本所在位置：组件/模板、国际化文件、Markdown/MDX/内容集合、元数据、邮件模板、外部CMS，
• 语言环境和网站主要语言，
• 现有的报价文档：docs/offer/offer-brief.md（由 grand-slam-offer 技能编写）或 docs/ 中的任何简介/定位文档。

如果大部分文本位于外部CMS中，且既没有导出数据也没有读取渲染后网站的URL，则在进行下一步之前告知用户哪些内容可以审核，哪些不能。

步骤 2 — 从主页提取报价

像初次访问者一样阅读主页：首先是英雄区，然后按顺序浏览每个部分，包括 <title>、meta description、页眉和页脚。填写报价声明：

字段	需要回答的问题
销售内容	产品/服务及其形式
目标客户	客户/用户画像、细分市场、市场
核心承诺	客户获得的结果（+时间框架，如有说明）
机制/差异化	交付方式，为何选择此方案而非其他替代方案
名称	报价、产品、方法和套餐名称的准确拼写
关键术语	价格/套餐、保证、稀缺性/截止日期、交付时间——仅限于已声明的部分
主要转化	主要行动号召以及点击后会发生什么
语气	语调、称呼方式、定位（高端、经济、专家、友好……）

对于每个字段，记录其值及来源（引用 + 位置）。如果主页上未声明某个字段，则填写“未声明”。如果存在报价简介，则逐字段将其与主页进行比较。

对于具有多个不同报价的网站（例如为不同受众提供独立服务），记录主页的总括报价并列出子报价；每个子报价页面将对照其自身的报价和总括报价进行检查。

步骤 3 — 报价清晰度关卡

当满足以下所有条件时，报价被视为清晰：

1. 仅凭主页即可回答“销售内容”、“目标客户”、“核心承诺”和“主要转化”。
2. 主页呈现一个主要报价（或一个清晰的带有子报价的总括报价）——无竞争性报价。
3. 主页没有自相矛盾（两个价格、两个受众群体、两个不同的承诺）。
4. 主页不与报价简介（如果存在）相矛盾。

清晰 → 继续。报价声明作为基准；它将被置于报告顶部，以便用户更正。

不清晰 → 停止并在审核其他任何内容之前询问用户关于报价的信息。切勿猜测报价以跳过此关卡。

• 如果可用，使用 AskUserQuestion 工具（每轮最多4个问题），选项应基于在网站上实际找到的候选项，并留出自定义回答的空间。否则在聊天中提问。
• 仅询问缺失或矛盾的字段，例如“主页同时销售 X 和 Y——哪个是主要报价？”、“主要客户是 A（英雄区）还是 B（服务部分）？”、“简介声明30天保证，主页是14天——哪个是当前的？”。对于多个报价，确认层级结构（主要报价 vs. 子报价）。
• 将答案记录在报价声明中，来源注明“由用户确认”。不清晰或矛盾的主页文本将成为发现项——主页将像其他页面一样，对照已确认的报价进行审核。

步骤 4 — 页面和文本清单

列出访问者可以阅读的所有内容（详见 references/text-inventory.md）：

• 每个路由/页面，包括动态路由和内容集合，
• 共享文本：页眉、导航、页脚、横幅、弹窗/模态框、表单（标签、占位符、验证、成功/错误消息）、404/500和空状态，
• 访问者间接看到的文本：<title>、meta description、Open Graph/Twitter 标签、JSON-LD 文本字段、alt、aria-label、网页清单名称/描述，
• 事务性电子邮件和通知（如果其模板在仓库中）。

为每个页面赋予其叙事角色（参见 references/consistency-checklist.md）——该角色决定了该页面“一致”的含义。

大型网站：完全审核每个核心页面。对于相同类型的大型集合（例如超过20篇博客文章或产品），审核共享模板以及每个项目的标题、描述、简介和行动号召；在报告中说明以此方式涵盖了哪些内容，并提供全面审核的选项。如果 Agent 工具可用，可以将清单分发给子 Agent——为每个子 Agent 提供已确认的报价声明、检查清单及其页面列表，然后将它们的发现合并到一个表格中。

步骤 5 — 审核

阅读 references/consistency-checklist.md。对照报价声明，根据页面的角色，检查每个文本单元的所有维度（D1–D10）。对于每个发现项，记录：位置、逐字引用、维度、严重性、问题原因（与特定报价声明字段相关）、修复类型以及建议的文本。

• 首先构建事实矩阵（每个提及价格、保证、截止日期、名额、交付时间、名称的内容——并排放置），以便系统地捕捉页面之间的矛盾，而不是偶然发现。
• 建议的文本遵循仅文本编辑规则，绝不捏造事实。缺失的事实应以网站语言使用占位符（例如 [待填写：…]，波兰语 [DO UZUPEŁNIENIA：…]）。
• 事实冲突且无法确定真相时 → 修复类型为决策：列出选项，不进行选择。
• 文本无法解决的问题（图片显示不同产品、缺少部分或行动号召按钮、不应存在的页面、链接目标错误、URL 别名）归入“文本范围之外”——予以报告，但此技能不进行修复。

步骤 6 — 审核报告，然后停止

严格按照“输出格式”呈现报告。报告始终以发现项表格结束。 表格之后唯一允许的内容是批准问题。然后停止并等待——在此轮中不修改任何文件。

批准问题（如果可用，使用 AskUserQuestion 工具）：

• 应用所有
• 仅应用严重和主要
• 应用选定的行（用户列出编号并可编辑任何提案）
• 不应用——仅审核

用户希望应用的每个决策行都需要一个答案；尽可能在同一轮中询问这些问题。

步骤 7 — 应用批准的修复

• 按照仅文本编辑规则，仅应用批准的行，并采纳用户的编辑。
• 在更改字符串之前，检查它还在哪里渲染（共享的国际化键、共享组件、可重用的 Markdown 片段）。如果新文本不适应该上下文，则停止并询问。
• 如果批准的修复结果需要进行非文本更改，或无法按批准的方式应用，则跳过该修复并报告。不要临时采用不同的修复方法。
• 存储在外部 CMS 中的文本：不要尝试编辑它；准备一个复制粘贴列表（CMS 条目/字段 | 当前文本 | 新文本）。

步骤 8 — 验证和报告

• 重新阅读每个更改的段落及其周围文本——它必须在上下文中读起来自然。
• 在批准的范围内搜索旧版本的遗留内容（旧名称、旧术语、旧承诺）。
• 验证更改的文件：JSON/YAML 解析、本地化文件保留相同的键、插值变量完整。如果有一个可用的快速 lint/类型检查/构建工具，运行它。
• 多语言：列出其他需要匹配更新的语言环境字符串，除非用户也批准更新这些字符串。
• 以摘要表结束：编号 | 位置 | 状态（已应用 / 已跳过 —— 原因 / 需要 CMS 更新） | 更改（简短描述）。除非被要求，否则不提交。

仅文本编辑规则

允许：

• 用户可见的字符串内容：JSX/模板中的文本节点、渲染给用户的字符串字面量、国际化值、Markdown/MDX 散文、frontmatter 文本字段（标题、描述）、仓库中的 CMS/内容文件，
• 文本属性和元数据：alt、title、aria-label、placeholder、<title>、meta description、OG/Twitter 文本、JSON-LD 文本值、清单名称/描述，
• 表单、系统和电子邮件模板消息，
• 在现有文本元素内重写、缩短或删除句子。

不允许（改为在“文本范围之外”下报告）：

• 添加、删除、重新排序或重新样式化元素、部分或组件；更改标记、类、CSS 或非文本属性，
• 清空一个元素——空元素属于布局更改；应重写它，
• 国际化键、变量名、文件名、路由、URL 别名、锚点（别名是文本，但更改它们会破坏链接和 SEO），
• 链接目标（href）——只能更改链接文本，
• 图片、图标、视频和其他媒体，
• 代码逻辑、条件语句、数据获取。

编辑时：

• 保留插值和语法：{name}、{{count}}、%s、:attribute、ICU 复数/选择、HTML 实体、字符串内的内联标签（<strong>、<br>、<0>…</0>）、Markdown 格式以及转义字符（JSX/JSON 中的引号、PHP 字符串中的撇号）。
• 保持长度与原文接近（大约 ±30%），因为布局不会改变。如果修复需要更多文本，请在提案中说明。
• 匹配网站的排版惯例（引号、破折号、不间断空格）。

强制性规则

• R1. 只读审核。 在获得明确批准之前，不得进行编辑或文件写入（包括报告文件，除非用户要求）。批准仅涵盖已批准的行。
• R2. 仅文本。 超出仅文本编辑规则的所有内容均予以报告，绝不更改。
• R3. 基准优先。 绝不针对猜测的报价进行审核：报价声明要么从主页明确得出，要么由用户确认。
• R4. 证据。 每个发现项都逐字引用当前文本，并给出精确位置（file:line 或国际化键）。
• R5. 表格始终放在最后。 每份审核报告都以发现项表格结束，即使没有发现项——此时则以覆盖范围表（页面 | 角色 | 结论）结束。
• R6. 不捏造事实。 提案不得包含用户未提供或网站尚未一致声明的数字、结果、推荐、保证或条款。冲突 → 决策。缺失 → 占位符。
• R7. 一致性，而非统一性。 不要到处粘贴英雄区的承诺，也不要在每个页面上强行推销。仅标记那些根据页面角色而言，与报价相矛盾、冲淡、偏离或分散注意力的文本。法律页面永远不为叙事目的而重写——仅标记其与营销文案的事实冲突，并建议审查法律文本。
• R8. 与报价对齐，而非重新设计它。 本技能使网站与已确认的报价保持一致。如果报价本身较弱（模糊的承诺、无证据、价格驱动），在摘要中用一句话说明，并建议使用 grand-slam-offer 技能；不要在此处重建报价。
• R9. 语言。 使用对话语言进行沟通；建议的网站文本使用被替换文本的语言。

输出格式

审核报告

按以下顺序的部分，使用对话语言编写：

1. 基准报价 — 报价声明（紧凑表格）+ 其来源（主页 / 报价简介 / 由用户确认）。
2. 范围 — 已审核的页面和文本来源（数量 + 列表或分组）、语言环境、通过抽样涵盖的内容、位于仓库外且未审核的内容。
3. 摘要 — 按严重性统计的发现项数量；2-3个最大的叙事问题，每个一句话；可选一句关于报价本身的内容（R8）。
4. 完整重写（仅当需要时）——超过约40个单词的提案，完整呈现，标有发现项编号。
5. 文本范围之外（仅当存在时）——简短条目；此技能不会修复它们。
6. 发现项表格 — 报告的最后一个元素。

发现项表格——表头翻译成对话语言：

#	位置	严重性	当前文本	不应如此的原因	建议的修复

• # — 用于批准的稳定ID。
• 位置 — 页面 · 部分 · file:line 或国际化键。
• 严重性 — 严重 / 主要 / 次要（见检查清单）。
• 当前文本 — 相关片段的逐字引用；超过约25个单词时用“…”缩短。
• 不应如此的原因 — 与基准的具体冲突，例如“主页：面向牙科诊所；此处：面向任何企业”。
• 建议的修复 — 以网站语言编写的准确新文本、“参见完整重写 #N”，或 DECISION: A) … / B) …。

按严重性排序，然后按清单中页面的顺序排序。

例如，在波兰语对话中，三个核心表头变为“Jak jest dziś”、“Dlaczego tak nie powinno być”、“Jak to poprawię”。

示例行（英语网站，英语对话）：

#	位置	严重性	当前文本	不应如此的原因	建议的修复

……

……（此处内容因翻译而截断）