improve-website

改进网站

一段可交互、可续接的旅程，将一个虽已上线但表现不佳的网站转化为一份有依据的修复事项优先级清单。整个流程分为八个阶段，先诊断访客为何没有转化，再改进可用性、层级、排版、信息传达、速度、记忆度和错误处理——每个决策点都会征求你的意见，并将结果记录在 docs/ 中。每项更改都有相应理由；重要更改会以测试的形式发布。

核心原则

诊断、修复、验证：由真实访客的证据决定哪些内容需要更改，并将每项修复作为可测试的假设发布。 阶段顺序经过精心设计——先研究，再依次处理可用性、视觉效果、信息传达、速度、记忆度和错误容忍度，因为每个阶段的产出都会为下一阶段提供依据。

此技能会安排各阶段的顺序、提出决策问题，并记录你的决定。具体方法由各个组成技能提供——调用它们，而不是自行发挥其框架。

旅程图

阶段	技能	要回答的问题	产出
1	cro-methodology	访客为何没有转化，哪项修复能带来最大的收益？	更新 docs/METRICS.md、docs/WEBSITE.md、docs/EXPERIMENTS.md — GATE
2	ux-heuristics	访客在评估方案前会在哪些地方受阻？	更新 docs/DESIGN.md、docs/EXPERIMENTS.md
3	refactoring-ui	页面看起来是否和读起来一样清晰？	更新 docs/DESIGN.md、docs/EXPERIMENTS.md
4	web-typography	访客能否轻松阅读文案？	更新 docs/DESIGN.md、docs/EXPERIMENTS.md
5	storybrand-messaging	陌生人能否在五秒内理解这项方案？	更新 docs/POSITIONING.md、docs/EXPERIMENTS.md
6	high-perf-browser	页面能否在访客失去耐心前加载完毕？	更新 docs/METRICS.md、docs/WEBSITE.md、docs/EXPERIMENTS.md
7	made-to-stick	这个想法是否足够令人难忘，能让访客记住并作出决定？	更新 docs/POSITIONING.md、docs/EXPERIMENTS.md
8	design-everyday-things	采取行动的访客是否会遇到阻碍？	更新 docs/DESIGN.md、docs/EXPERIMENTS.md

运行规则

1. 优先续接。 首先阅读 docs/IMPROVE-WEBSITE-PLAN.md 和 Journey Map 中的所有产物。如果跟踪文档存在，请用 3-5 行概述旅程进度，并询问要进入哪个阶段。完成标准：用户已确认入口。已有跟踪文档的旅程应续接，绝不重新开始。
2. 仅在首次运行时进行信息收集。 如果没有跟踪文档：先执行下方的信息收集，然后创建 docs/IMPROVE-WEBSITE-PLAN.md，并将每个阶段的状态标记为 pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason。完成标准：跟踪文档已创建，且用户已确认阶段计划。
3. 进入阶段。 说明该阶段的作用、需要做出的决策、产出的文档以及大致工作量。提供继续 / 跳过 / 延后选项——标记为 GATE 的阶段可以延后，但不能跳过。用户选择继续后，将该阶段标记为 in-progress。完成标准：用户已作出选择。
4. 技能调用与回退。 加载并使用该阶段的技能：每个阶段的 Invoke 行都会用 slug 指定技能——使用该技能执行阶段。如果该技能不可用，请提供：npx skills add wondelai/skills/<slug> --global。如果用户拒绝，则依据 Brief 执行阶段——采用最低可行方法。说明当前采用的模式。
5. 阶段内决策。 询问“与用户共同决策”下的所有问题，并提供具体选项及推荐方案。在跟踪文档的 Key Decisions 中记录选择。默默做出决策属于缺陷。
6. 阶段退出。 写入前先展示产物草稿供用户确认。用户批准后：写入或扩展 docs/ 文件，并更新跟踪文档（状态、Key Decisions、Next Actions）。完成标准：文件已写入，且阶段行显示 done。
7. 产物规范。 写入前先阅读；仅在文件不存在时创建，否则应扩展文件——添加或更新自己的章节，并保留其他人的内容。docs/ 中的文件名均为大写。首次创建 docs/ 文件时，请参阅 references/artifact-templates.md——使用完整骨架创建文件（包含所有章节标题），然后填写该阶段指定的章节。每条建议都必须以复选框或表格行的形式记录，并注明负责人和优先级。
8. 先诊断，再重新设计。 在 Phase 1 诊断得出证据之前，不得发布任何视觉或文案改动；每项改动都必须记录在 EXPERIMENTS.md 中，并预先确定指标。没有 Phase 1 发现作为依据的修复应退回 Phase 1；没有配套测试的大胆改动应留在待办事项中，直到有测试为止。

调研信息

创建跟踪表前，请先询问以下问题：

1. 我们要改进哪个页面或流程？它应该推动的唯一一项操作是什么？（明确每个阶段的范围；这是 Phase 1 的门槛——一个页面有 3 个 CTA，就等于没有目标。）
2. 用你自己的话描述转化问题，并说明你有哪些证据——分析数据、跳出率、流失情况？（为 Phase 1 的漏斗诊断提供依据。）
3. 你是否有真实访客反馈——退出调查、评论、支持工单、录屏等？或者你能获取这些反馈吗？（Phase 1 的反驳必须使用客户自己的措辞。）
4. 每周大约有多少流量？（这决定了 A/B 测试能否达到统计显著性；流量较低时，应更多依靠定性分析和启发式阶段。）
5. 你最常听到哪种抱怨——“看起来不专业”“没人理解我们是做什么的”“页面很慢”“文字很难读”？（根据指南常见问题，决定优先处理哪个修复阶段。）
6. 你是否有现成的定位或品牌文档（POSITIONING.md）？（Phase 5 和 Phase 7 会以此为基础。）
7. 你能否提供真实素材——URL、线上文案、CSS、分析截图？（技能的效果取决于你提供的证据。）

跳过启发式分析：如果正文已满足 16px / 约 66ch / 1.5-1.7 的行高，则跳过 Phase 4；如果 Core Web Vitals 已全部为绿色，则跳过 Phase 6（但如果页面几乎无法渲染，应先快速处理 LCP）；如果消息传达已得到验证且清晰，则跳过 Phase 5 或 Phase 7。绝不可跳过 Phase 1——它为其他所有阶段指明方向。

然后根据模板创建 docs/IMPROVE-WEBSITE-PLAN.md 并确认计划。完成标准：docs/IMPROVE-WEBSITE-PLAN.md 已创建，所有阶段均已标注状态，且用户已确认计划。

阶段

Phase 1 — 诊断访客无法转化的原因（cro-methodology）— 门槛

目的： 在调整任何像素之前，找出页面在哪些地方以及为何流失访客。Phase 2-8 只能修复可追溯到 Phase 1 发现的问题。

简要说明（备用方案）： 不要猜测——要调查。绘制漏斗，找出受阻环节（表现不佳且流量高的阶段）和缺失环节（不存在的阶段）。明确每个页面推动的唯一一项操作。用客户自己的措辞，为五大顾虑（信任、价格、契合度、时机、投入）建立 O/CO 表格，并为每项摩擦点列出反驳措施。按 ICE 排序。

调用： 使用 cro-methodology 技能，并提供目标页面/流程、唯一一项操作以及真实访客反馈。要求输出漏斗图、O/CO 表格、缺失的说服素材，以及按 ICE 排序的假设列表。

与用户共同决策：（1）确认每个页面的唯一一项操作；移除相互竞争的 CTA。（2）先解决损失金额最大的受阻环节，还是先补上缺失环节？（3）如果流量较低，则接受定性分析和启发式证据。

交付物： 扩展 docs/METRICS.md 中的 ## Funnel 和 ## Stage & One Metric That Matters；扩展 docs/WEBSITE.md 中的 ## Conversion Elements 和 ## Audit Findings（问题 | 严重程度 0-4 | 修复方案 | 状态）；扩展 docs/EXPERIMENTS.md 中的 ## Experiment Backlog（按 ICE 排序）。更新跟踪表。

完成标准： 漏斗已绘制，每个页面的唯一一项操作已确定，每项经过调研的异议都有对应的反驳措施，待办列表已按 ICE 排序，且 Phase 1 已标记为完成——只有此时才会解锁 Phase 2-8。

阶段 2 — 消除可用性障碍（ux-heuristics）

目的： 找出访客在哪些地方会遇到阻碍——这些障碍会让他们还没考虑产品价值就离开。

简述（备用）： 别让我思考。用户会快速浏览、将就着用，并设法应付。根据 Nielsen 的 10 项可用性启发式原则进行启发式评估；按问题出现频率、影响和持续性，对每个问题评为 0-4 级，让灾难性问题的优先级高于表面问题。对内页进行主干测试（是什么网站、当前页面是什么、有哪些选项、我在哪里、搜索在哪里？）。删掉一半文字，再删掉一半；去掉让人摸不着头脑的图标导航。

调用： 使用 ux-heuristics 技能，提供页面/流程和阶段 1 的发现。要求输出按严重程度评级的评估、每个关键页面的主干测试结果，以及改写后的错误提示和标签文案。

与用户确定： 哪些严重程度为 4 级和 3 级的问题现在修复，哪些放入待办？确认按严重程度而非修复难易程度安排修复。

产出物： 扩展 docs/DESIGN.md 中的 ## UX Audit Findings（问题 | 启发式原则 | 严重程度 0-4 | 修复方案 | 状态）；将每项修复追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog，并标注 ICE。更新跟踪表。

完成标准： 每个问题都标有 0-4 级严重程度；每个关键页面都通过主干测试或已记录测试结果；严重程度为 4 级的问题都有负责人。

阶段 3 — 修复视觉层级（refactoring-ui）

目的： 让页面看起来和读起来一样清晰——只有一个明确的焦点，而不是所有元素都在争抢注意力。

简述（备用）： 优秀的 UI 靠系统，而非天赋。先用灰度设计：在使用任何颜色之前，通过尺寸、字重和对比度建立层级——组合这些手段，不要叠加（仅主视觉元素使用全部三种手段）。采用间距比例（4/8/16/24/32/48/64），组间距大于组内间距。将文本宽度限制在 45-75 个字符。最后再添加颜色：每种色相使用 5-9 个色阶，灰色应带有色调，而非 #000。

调用： 使用 refactoring-ui 技能，提供页面、阶段 2 的发现和 CSS 框架。要求进行灰度层级调整、修正间距比例、制定系统化配色，并提供准确的类名/CSS 修改。

与用户确定： 在现有设计系统内修复，还是引入新令牌？确认先确保灰度布局清晰，再处理颜色。

产出物： 扩展 docs/DESIGN.md 中的 ## Tokens（间距比例 · 配色色阶 · 阴影）和 ## Components （组件 | 决策 | 状态）；将修复追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成标准： 灰度布局清晰易读，已应用间距比例，一个主要 CTA 占据主导地位，并已记录令牌决策。

阶段 4 — 提升文字可读性（web-typography）

目的： 修正决定访客能否舒适阅读文案的排版参数。

简述（备用）： 字号、行长和行高比字体更重要。修正三项：正文 ≥16px（阅读内容较多的页面为 18px）；通过 ch 或 max-width 将行长设为 45-75 个字符（~66 个字符为理想值）；正文行高为 1.5-1.7，标题行高为 1.1-1.25。构建模块化比例；使用 swap 加载字体，预加载一种字体，进行子集化，控制在 <200KB。

调用： 使用 web-typography 技能，提供阅读内容较多的模板和 DESIGN.md 中的字体决策。要求提供带有流式 clamp() 比例的修正后 CSS，以及字体加载方案。

与用户确定： 保留当前字体，还是调整字体搭配？确认字体加载预算（<200KB），阶段 6 将验证该预算。

产出物： 扩展 docs/DESIGN.md 中的 ## Typography（字体 · 比例 · 行长 · 行高 · 加载策略）；将修复追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成标准： 关键模板上的正文字号、行长和行高均达到目标；比例已定义；加载策略已记录。

阶段 5 — 锤炼信息（storybrand-messaging）

目的： 让陌生人在 5 秒内明白你做什么，以及为什么重要。

简报（备用）： 客户是英雄；你的品牌是向导（尤达，而非卢克）。执行 SB7：一个想要某样东西的角色、三个层面的难题（外部／内部／哲学层面——大多数品牌会漏掉内部层面）、一个兼具同理心和权威性的向导、一个包含 3-4 个安全步骤的计划、一个直接 CTA 加一个过渡 CTA，以及失败／成功的利害关系。撰写一句话：“我们帮助那些遇到 [Y] 难题的 [X]，实现 [Z]。”

调用： 使用 storybrand-messaging 技能，提供当前文案、POSITIONING.md（如果存在）以及阶段 1 中的内部问题。要求改写首屏文案、编写 BrandScript 和一句话描述。

与用户共同决定： 哪个一句话描述能通过“听一遍后复述”的测试？确认文案必须指出的内部问题。

产出物： 扩展 docs/POSITIONING.md 中的 ## Brand Script (StoryBrand)、## One-Liner 和 ## Key Messages（展示位置 | 信息 | 状态）；将文案测试追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成条件： 选定一句话描述；首屏文案指出内部问题，并包含一个直接 CTA 和一个过渡 CTA；按展示位置记录信息。

阶段 6 — 提升页面速度（high-perf-browser）

目的： 确保缓慢的加载不会白费清晰表达所做的工作——页面必须在人们失去耐心之前加载完成。

简报（备用）： 瓶颈在于延迟，而非带宽——减少往返次数。以 Core Web Vitals 为目标：LCP <2.5s、INP <200ms、CLS <0.1、TTFB <800ms。预加载 LCP 主视觉元素；预留空间（宽度／高度或 aspect-ratio），避免 CLS；延迟加载非关键 JS；内联关键 CSS；缓存不可变资源；在 HTTP/2 下取消分片。

调用： 使用 high-perf-browser 技能，并提供页面 URL，以及性能跟踪记录或 Lighthouse 运行结果（如果有）。要求指出 LCP 元素、布局偏移来源、阻塞资源，并提供按优先级排序的修复清单。

与用户共同决定： 如果页面几乎无法渲染，是否先处理能快速改善 LCP 的修复，再处理其他问题？哪些修复现在上线，哪些需要测试？

产出物： 扩展 docs/METRICS.md 中的 ## Baselines & Targets（CWV 指标 | 基线 | 目标 | 未达标时的处理），以及 docs/WEBSITE.md 中的 ## Audit Findings；将修复追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成条件： 记录 CWV 基线和目标，为每项修复指定负责人，并标记任何仍在 HTTP/2 下使用的 HTTP/1.1 变通方案。

阶段 7 — 让核心创意令人印象深刻（made-to-stick）

目的： 让产品提供的价值足够令人难忘，能在人们访问网站与做出决定之间的间隔中留在脑海里。

简报（备用）： 克服知识的诅咒。根据 SUCCESs（简单、意外、具体、可信、情感、故事）为关键信息评分。具体：用感官细节取代抽象描述（“30 分钟内送达，依然热乎”；“每月节省 16 小时”）。简单：明确“指挥官意图”——访客必须记住的一件事。让统计数据贴近人的实际感受（辛纳屈测试）；优先选择具体数字，而非整数。

调用： 使用 made-to-stick 技能，并提供标题、价值主张、关键特性以及阶段 5 的一句话描述。要求为每条信息提供 SUCCESs 评分和具体改写，指出“指挥官意图”，并给出一个贴近人的实际感受的统计数据。

与用户共同决定： 唯一的“指挥官意图”信息是什么？哪些抽象描述应替换成哪些具体细节？

产出物： 扩展 docs/POSITIONING.md 中的 ## Key Messages，加入 SUCCESs 评分和具体改写；将文案测试追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成条件： 每条关键信息都有 SUCCESs 评分和具体改写；明确“指挥官意图”；关键统计数据贴近人的实际感受。

阶段 8 — 从设计上消除错误（design-everyday-things）

**目的：**保护那些决定采取行动的访客——让错误操作无法发生，而不是只提醒他们别这么做。

**简述（备用）：**没有人为错误，只有糟糕的设计。弥合两道鸿沟：通过清晰的指示线索（可按的按钮、可编辑的字段）和约束（用日期选择器代替自由输入，直到内容有效前禁用提交按钮）弥合执行鸿沟（“我该怎么做？”）；通过在 0.1 秒内提供反馈弥合评估鸿沟（“发生了什么？”）。用撤销功能修正操作失误，并将破坏性操作分开；错误消息应说明哪里出了问题以及如何修正，不能责怪用户。

**调用：**针对转化关键流程（注册、结账、账户设置）使用 design-everyday-things 技能。询问指示线索是否薄弱、哪些约束能让错误无法发生、反馈有哪些缺口，以及如何改写消息。

**与用户共同决定：**哪些地方应以约束代替错误消息？哪些地方应以撤销代替“确定要继续吗？”确认？

**产出物：**扩展 docs/DESIGN.md ## UX Audit Findings（问题 | 诺曼鸿沟对应的启发式原则 | 严重程度 0-4 | 修复方案 | 状态）；将修复项追加到 docs/EXPERIMENTS.md ## Experiment Backlog。更新跟踪表。

**完成标准：**每个转化流程都记录了指示线索／约束／反馈方面的改进；错误消息符合检查清单要求；破坏性操作均提供撤销选项。

可选阶段

技能	在以下情况下添加	产出物
influence-psychology	需要为异议点准备合乎伦理的说服素材（社会认同、权威、真实稀缺性）	扩展 docs/WEBSITE.md ## Conversion Elements
microinteractions	交互显得迟钝或没有响应	扩展 docs/DESIGN.md ## Microinteraction Inventory
top-design	重新设计需要一个标志性时刻，而不只是修补问题	扩展 docs/DESIGN.md ## Design Direction
steve-jobs-design-review	重新发布前，需要一次不留情面的端到端评审	扩展 docs/WEBSITE.md ## Audit Findings

可选阶段遵循相同的执行规则——像核心阶段一样加载并使用每项列出的技能；在“添加条件”首次成立时插入。

常见错误

错误	修正
研究之前就重新设计——面对未解决的异议，只是页面变得更漂亮，转化效果不会有变化。	先运行阶段 1（cro-methodology）；没有阶段 1 的发现作为依据，就不发布任何视觉或文案改动。
测试过于保守的小调整（按钮颜色、字体微调），小到永远无法达到显著性。	用 ICE 评分挑选大胆的改动；测试前先问“这能让结果提升 10 倍吗？”（cro-methodology）。
在灰度布局奏效之前就添加颜色。	先灰度，后上色；如果页面在去色后效果不佳，再好的配色也救不了它（refactoring-ui）。
在清晰度工作完成之前，孤立地优化速度。	清晰度之后再优化速度（阶段 6）；例外情况——如果页面几乎无法渲染，则优先处理快速 LCP 修复（high-perf-browser）。
把“用户错误”归咎于用户，并添加更多警告。	用约束预防错误，用撤销功能补救，而不是用对话框（design-everyday-things）。
混淆清晰度与记忆度——清晰的信息也可能转眼就被遗忘。	同时运行阶段 5 和阶段 7；StoryBrand 让人理解你，Made to Stick 让人记住你。

完成整个旅程

退出检查清单：

• docs/IMPROVE-WEBSITE-PLAN.md 中的每个阶段都标记为 done 或 skipped: reason。
• WEBSITE.md、DESIGN.md、POSITIONING.md 和 METRICS.md 都将每项修复作为表格行列出，并注明负责人和优先级。
• 每项高 ICE 变更都已在 EXPERIMENTS.md 的 ## Experiment Cards 中设计为 A/B 测试，并预先确定了指标。
• 每个关键页面的唯一行动都清晰明确，且已移除相互竞争的 CTA。

重新调用 cro-methodology，为高 ICE 待办项设计大胆的测试，以此形成闭环：预先计算样本量，运行一个完整的业务周期，要求达到 95% 置信度，绝不提前查看结果——然后将它们从 ## Experiment Backlog 移至 ## Experiment Cards，并将 Next Actions 纳入相关文档，以此关闭跟踪流程。

后续方向：当网站已实现转化，且需要更多高质量流量时，继续使用 grow-website 技能。 当摩擦来自产品而非营销网站时，继续使用 improve-app 技能。