improve-app

改进应用

应用已经发布并能正常运行：有用户、界面和真实流程，但本应轻松顺畅的体验却显得粗糙。整个旅程分为九个阶段，按证据顺序解决用户感受到的问题：重新聚焦核心任务、消除阻力、打磨外观与关键时刻、精炼文案、诚实地说服用户，并以足够严苛、敢于删减的评审收尾。这个过程可交互（Agent 会先询问再做决定），也可中断后继续（状态保存在 docs/ 中）。代码层面的原因会转至代码相关旅程处理——本流程专注于改善产品体验。

核心原则

按证据顺序解决用户感受到的问题：重新聚焦应用受雇完成的任务，先消除阻力再打磨体验，精炼文案，诚实地说服用户，并以足够严苛、敢于删减的评审收尾。 令人困惑的流程即使配上更漂亮的界面，流失用户的速度也不会改变——阶段顺序至关重要。

此技能负责安排各阶段顺序、提出决策问题并记录你的决定。九个组成技能各自提供相应方法——请调用它们，而不是临时编造框架。

旅程地图

阶段	技能	要回答的问题	产出物
1	jobs-to-be-done	用户雇用这个应用来完成什么任务？它在哪些方面表现不佳？	扩展 docs/CUSTOMER.md — GATE
2	ux-heuristics	界面在哪些地方会让用户停下来思考？	扩展 docs/DESIGN.md、docs/EXPERIMENTS.md
3	design-everyday-things	用户在哪些地方因设计误导而做出错误操作？	扩展 docs/DESIGN.md、docs/EXPERIMENTS.md
4	refactoring-ui	应用的外观是否与功能一样清晰？	扩展 docs/DESIGN.md、docs/EXPERIMENTS.md
5	microinteractions	每个操作是否都有反馈，还是显得毫无反应？	扩展 docs/DESIGN.md、docs/EXPERIMENTS.md
6	made-to-stick	应用内文案是否通俗易懂，还是像行话？	扩展 docs/POSITIONING.md、docs/EXPERIMENTS.md
7	influence-psychology	付费墙和升级时刻是否做到了诚实地说服用户？	扩展 docs/POSITIONING.md、docs/EXPERIMENTS.md
8	high-perf-browser	用户实际操作时，应用是否感觉够快？	扩展 docs/DESIGN.md、docs/EXPERIMENTS.md
9	steve-jobs-design-review	整体体验是否优秀到令人惊叹，还是仅仅有所改善？	扩展 docs/PRODUCT.md、docs/DESIGN.md、docs/EXPERIMENTS.md

操作规则

1. 优先续接。 开始前，先阅读 docs/IMPROVE-APP-PLAN.md 和 Journey Map 中的每一份资料。如果跟踪文档已存在，用 3-5 行概述当前旅程状态，并询问要进入哪个阶段。完成标准：用户已确认进入点。已有跟踪文档的旅程应续接，绝不重新开始。
2. 仅在首次运行时进行需求收集。 如果没有跟踪文档：先完成下面的需求收集，然后创建 docs/IMPROVE-APP-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. 先收集证据，再重新设计；说服必须诚实。 没有阶段 1-3 的审计或证据条目支撑，任何 UI 或文案变更都不得上线——没有发现依据的变更必须退回审计阶段。每项上线的变更都必须在 docs/EXPERIMENTS.md 中记录，并预先设定指标。应用内的稀缺性提示、社会认同声明和升级承诺必须真实——任何需要编造证据的策略，都应替换为使用现有证据的策略。

访谈

创建跟踪文档前，先询问以下问题：

1. 这是什么应用？用户用自己的话来说，聘请它来完成什么任务？（确定阶段 1 的方向；是后续所有阶段的前提。）
2. 哪些方面最不尽如人意——令人困惑的界面、无响应的交互、显得不专业的 UI、文案薄弱、咄咄逼人的升级提示，还是响应迟缓？（确定从哪个阶段开始，并优先安排修复阶段。）
3. 你有哪些证据——录屏、支持工单、评价、转化漏斗流失数据、使用分析数据？（回答“没有”则进入可选的持续发现阶段。）
4. 应用运行在哪些平台上——Web、原生 iOS，还是两者都有？（决定阶段 8 和可选的 ios-hig-design；如果没有浏览器端界面且原生性能流畅，则跳过阶段 8。）
5. 应用内有哪些促销或升级界面——付费墙、升级提示、试用提醒、徽章？其中有关稀缺性和社会认同的说法目前属实吗？（确定阶段 7 的范围和诚信守则。）
6. 哪个流程流失的用户最多，或收到的工单最多？（帮助确定阶段 2-3、5 和 8 的重点。）
7. 你是否已有定位、设计或客户文档（POSITIONING.md、DESIGN.md、CUSTOMER.md）？（阶段 1、4、6、7 会以这些文档为基础。）

阶段跳过启发规则：没有浏览器端界面且原生运行速度流畅时，跳过阶段 8；没有应用内升级促销界面时，跳过阶段 7；UI 已能以一致的设计令牌比例在灰度下清晰呈现时，跳过阶段 4；应用内文案已具体明确且没有术语时，跳过阶段 6。绝不跳过阶段 1——它为其他所有阶段指明方向（可以推迟，但不要跳过）。然后根据模板创建 docs/IMPROVE-APP-PLAN.md 并确认计划。当 docs/IMPROVE-APP-PLAN.md 文件已创建、每个阶段的状态均已标注，且用户确认了计划时，即为完成。

阶段

阶段 1 — 重新锚定应用受聘完成的任务（待完成任务）— 门槛

目的： 在更改任何界面之前，明确用户聘请应用完成的任务，以及应用在哪些方面未能满足需求；阶段 2-9 只能修复阶段 1-3 的审查或发现所指出的问题。

简介（备用方案）： 用户聘请产品，是为了在特定情境下取得进展。将任务表述为“当 [情境] 时，我想要 [动机]，以便 [结果]”——绝不提及应用名称；每个任务都有三个维度（功能、情感、社交），遗漏任何一个维度，就无法解释用户为何留下。区分首次使用和重复使用（大任务 vs. 小任务），并列出替代方案，包括不使用产品和临时拼凑的解决办法。

调用： 使用 jobs-to-be-done 技能，提供应用、应用使用数据以及访谈中发现的最不尽如人意的流程。要求给出任务表述、三个维度及应用在各维度上的不足之处，以及用户转而使用的替代方案。

与用户共同决策： (1) 确认任务表述不提及产品名称也说得通。(2) 哪个维度最未满足——功能、情感还是社交？(3) 流失属于大任务（入门引导）还是小任务（日常使用）方面的问题？

产出： 扩展 docs/CUSTOMER.md，添加 ## Job Statement、## Job Dimensions（功能/情感/社交维度，每项都附上不足之处说明）和 ## Competing Alternatives（替代方案 | 用户选择它的原因 | 弱点，包括不使用产品的情况）。更新跟踪文档。

完成条件： 任务表述不提及产品名称，三个维度均附有不足之处说明，替代方案已记录，且阶段 1 标记为已完成——只有这样才能解锁阶段 2-9。

阶段 2——消除让用户思考的阻力（ux-heuristics）

目的： 减轻那些导致用户流失的流程中的认知负担——找出界面让用户停下来琢磨的地方。

简述（备用）：“别让我思考”——用户会快速浏览、满足于够用的结果，并设法应付过去。根据 Nielsen 的 10 项可用性原则开展启发式评估；为每个问题评定 0–4 级严重程度，并按严重程度 × 用户遇到问题的频率排序，让灾难性问题排在外观问题之前。对关键屏幕执行 Trunk Test（这是什么应用、这是哪个屏幕、我有哪些选项、我在哪里、搜索在哪里？）；先删掉一半文字，再删掉剩下文字的一半；改进表单，添加行内验证，并让错误消息说明是什么、为什么，以及如何解决。

调用： 在流失率最高的流程中使用 ux-heuristics 技能，并参考阶段 1 的工作和维度。要求提供按严重程度评级的评估、每个关键屏幕的 Trunk Test 结果，以及改写后的标签、表单和错误文案。

与用户共同决定： 哪些严重程度为 4 级和 3 级的问题现在修复，哪些列入待办？确认修复按严重程度 × 频率排序，而不是按修复难易程度排序。

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

完成标准： 每个问题都标有 0–4 级严重程度并有对应修复方案；每个关键屏幕都通过 Trunk Test 或已记录测试结果；严重程度为 4 级的问题都已指定负责人。

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

目的： 让错误操作难以发生，让每种结果都清晰可见——用户操作出错时，误导他们的是设计，而不是用户。

简述（备用）： 不存在人为错误，只有糟糕的设计。弥合两道鸿沟：通过清晰的示能符和约束弥合执行鸿沟（“我该怎么做？”）（例如，使用日期选择器而不是自由文本；输入有效前禁用“提交”）；通过低于 0.1 秒的反馈和清晰可见的系统状态弥合评估鸿沟（“发生了什么？”）。区分失误（意图正确，操作错误）和错误（意图错误）；优先提供撤销，而不是“确定吗？”对话框；撰写错误消息时说明哪里出错以及如何修复，绝不责怪用户。

调用： 在核心流程（引导流程、主要操作、破坏性操作）中使用 design-everyday-things 技能。要求指出薄弱的示能符、能让错误无法发生的约束、反馈缺失之处，并改写相关消息。

与用户共同决定： 哪些地方应以约束取代错误消息，哪些地方应以撤销取代确认对话框？

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

完成标准： 每个核心流程都已记录示能符、约束和反馈方面的改进；错误消息均符合“是什么／为什么／如何做”的检查清单；破坏性操作都提供撤销选项。

第 4 阶段 — 让界面清晰易用（refactoring-ui）

目的： 为界面建立专业的视觉层级，避免任何业余感破坏刚刚修复的流程。

简要说明（备用）： 优秀的 UI 靠系统，而非天赋。先用灰度进行设计：在添加任何颜色之前，通过尺寸、字重和对比度建立层级——组合使用这些手段，而不是层层叠加（只有一个主视觉元素才同时使用这三种手段）。采用固定的间距比例（4/8/16/24/32/48/64），组间距应大于组内间距；将文本宽度限制在 45–75 个字符，将表单宽度限制在 300–500px。最后再添加颜色：每种色相设置 5–9 个色阶，灰色应带色相，而非纯黑。

调用： 使用 refactoring-ui 技能，结合第 2–3 阶段的发现和当前设计令牌，优化关键屏幕。要求进行灰度层级检查、修正间距比例、建立系统化调色板，并给出具体的令牌/CSS 修改。

与用户共同决定： 在当前设计系统内修复，还是引入新令牌？确认先完成灰度布局，之后再处理颜色。

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

完成标准： 关键屏幕在灰度下层级清晰，已应用间距比例，每个屏幕都有一个突出的主要操作，并已记录令牌决策。

第 5 阶段 — 让每个操作都有鲜活反馈（微交互）

目的： 为用户每天都会接触的时刻提供反馈，让产品从“勉强能用”变成“令人喜爱”。

简要说明（备用）： 每个微交互包含四个部分——触发、规则、反馈、循环与模式。常见问题是缺少反馈或反馈延迟：直接操作需要在 100ms 内得到响应，通常应通过用户触碰的元素本身做出动画反馈（按钮按下后显示“正在保存…”），而不是弹出单独的提示。梳理每种状态——空、加载中、部分完成、完成、错误、禁用——并采用足以传达信息的最少反馈，根据事件的重要性调整反馈程度。

调用： 使用 microinteractions 技能检查使用频率最高的交互（保存、提交、切换、删除、加载）。要求检查触发/规则/反馈/循环，明确每种交互所需的反馈，完整梳理状态，并设计一个标志性时刻。

与用户共同决定：（1）优先打磨哪些交互。（2）哪个标志性时刻值得投入更多精力——应用移除测试：如果没有这个时刻，产品体验会明显变差吗？

产出物： 扩展 docs/DESIGN.md 中的 ## Microinteraction Inventory（交互 | 触发/规则/反馈/循环 | 修复 | 状态）；将修复项追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成标准： 每个经过检查的交互都已记录四个部分及所需反馈，所有状态均已梳理，标志性时刻通过移除测试，修复项已列出并标注状态。

阶段 6 — 精炼应用内文案（令人印象深刻）

目的： 让用户在应用内看到的文案——引导流程、空状态、错误提示、行动号召、工具提示——具体、清晰、不含行话。

简述（备用）： 克服知识诅咒：熟悉产品后，你就无法想象自己曾经不了解它。根据 SUCCESs（简单、意外、具体、可信、动情、故事性）为关键应用内文案打分。具体胜于抽象：“用户每天打开应用 8 次”，而不是“提高参与度”。简单就是指挥官意图——屏幕必须传达的唯一要点；如果某个标签需要配手册才能看懂，就重写它。

调用： 使用 made-to-stick 技能，结合引导流程文案、空状态、错误字符串、行动号召、工具提示，以及阶段 1 的工作语言。要求为每个界面打出 SUCCESs 分数，提供去除行话的具体改写，并说明每个屏幕的指挥官意图。

与用户共同决定： 哪些抽象表达要改成哪些具体细节？每个屏幕必须传达的唯一要点是什么？

产出物： 扩展 docs/POSITIONING.md 中的 ## Key Messages（界面 = 应用内屏幕 | 消息 | 状态），加入 SUCCESs 分数和具体改写；将文案测试追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪表。

完成标准： 每个应用内界面都有 SUCCESs 分数和具体改写，行话已清除，已明确每个屏幕的指挥官意图，并按界面记录了消息。

阶段 7 — 在决策时刻诚实地说服用户（影响心理学）

目的： 让应用内营销界面——付费墙、升级提示、试用提醒、社会认同、徽章——以真实证据说服用户，而非耍花招。

简述（备用）： 人们会借助心理捷径做决定——七项原则能促使人们说“是”：互惠、承诺、社会认同、权威、好感、稀缺、归属。将这些原则应用于用户做决定的场景（付费墙、升级、试用结束）；叠加运用各项原则，确保每项主张都真实，并让决定可以撤销。伦理底线：任何捏造的证据、虚假的稀缺感或隐瞒成本的暗黑模式，都不合格——只有在用户不知道策略时才奏效的手法，是操纵而非说服。

调用： 针对调研收集到的升级推销界面使用 influence-psychology 技能。询问哪些原则适用于各个决策点、每种原则对应的诚实文案是什么，以及如何检查决定是否可撤销——标出所有需要你尚不具备的证据才能使用的提示。

与用户共同决定：（1）每个界面由哪项原则主导。（2）对于每条稀缺性或社会认同提示：它今天是否属实？如果不属实，就删除它，或在发布前让它成为事实。

产出物： 扩展 docs/POSITIONING.md 中的 ## Key Messages（界面 | 消息 | 状态），加入说服性文案；在 docs/EXPERIMENTS.md 的 ## Experiment Backlog 中将每项改动列入队列，并注明预期影响的指标。更新跟踪表。

完成标准： 每个升级推销界面都注明主导原则和诚实文案；每项稀缺性或社会认同主张都经核实属实，否则已删除；决定可以撤销；改动已列入实验队列。

阶段 8 — 优化用户实际感受到的速度（high-perf-browser）

目的： 提升用户能感受到的交互和入口视图的响应速度——速度是体验的一部分，不是事后才考虑的后端问题。

简介（备用方案）： 瓶颈在于延迟，而非带宽——大多数痛点都源于往返请求过多。瞄准现场指标：关键交互的 INP 低于 200ms（拆分长任务，延迟加载非关键 JS），入口视图的 LCP 低于 2.5s（预加载主视觉，提高 fetchpriority），CLS 低于 0.1（通过明确的尺寸预留空间）。对于仍然存在的实际延迟，用骨架屏和乐观 UI 将其隐藏，让界面在服务器响应前就能做出响应。

调用： 在最慢的关键交互和入口视图上使用 high-perf-browser 技能；如有条件，结合跟踪记录或 Lighthouse 运行结果。请提供 INP 长任务、LCP 元素、布局偏移来源，以及按影响排序的修复列表，并指出适用骨架屏或乐观 UI 的位置。

与用户共同决定： 先测量哪些交互和视图，并确认将现场指标目标设为不可逾越的底线。

产出物： 扩展 docs/DESIGN.md 中的 ## UX Audit Findings（启发式类别 = performance；问题 | 严重程度 0-4 | 修复方案 | 状态），添加 INP/LCP/CLS 条目；将修复项追加到 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪器。

完成标准： 已将 INP/LCP/CLS 基线记录为 performance 条目，已设定目标（INP < 200ms、LCP < 2.5s、CLS < 0.1），并按影响对各项修复排序，同时注明延迟仍然存在时的骨架屏/乐观 UI 备用方案。

阶段 9 — 接受严苛、坦诚的评审（steve-jobs-design-review）

目的： 以“极致出色，否则就不算完成”为标准，冷静审视整体体验，并决定删减什么。

简介（备用方案）： 从客户体验出发，反向推导。以新用户的视角冷启动体验产品，明确它必须完成的唯一要事，统计达到价值所需的步骤，并给出二元结论，以及按优先级排序的删减清单和修复清单。聚焦就意味着说不——每项功能都可能被删除。审查围栏背面：空状态、错误文案、404、账单、取消、收据邮件——这些都必须达到主视觉屏幕的标准。

调用： 在阶段 1-8 完成后，对整个应用使用 steve-jobs-design-review 技能。请提供冷启动体验流程、唯一要事、达到核心价值所需的步骤数、二元结论、按优先级排序的删减和修复清单，以及围栏背面审查。

与用户共同决定： （1）接受删减清单——实际移除哪些功能。（2）哪些围栏背面修复立即发布，哪些稍后发布。

产出物： 扩展 docs/PRODUCT.md 中的 ## Outcome Roadmap（成果/问题 | 服务的工作 | 优先级 | 状态），将删减和修复作为按优先级排序的条目添加；将所有围栏背面修复追加到 docs/DESIGN.md 的 ## UX Audit Findings；将计划发布的修复加入 docs/EXPERIMENTS.md 的 ## Experiment Backlog。更新跟踪器。

完成标准： 已记录评审结论，已就删减清单达成一致并明确每项的处理方式，删减和修复已作为按优先级排序的条目加入 ## Outcome Roadmap，且跟踪器已将阶段 9 标记为完成。

可选阶段

技能	在以下情况下添加	产出物
ios-hig-design	应用以原生方式在 iOS 上发布	扩展 docs/DESIGN.md
lean-ux	高风险修复值得在完整构建前先进行低成本实验	扩展 docs/EXPERIMENTS.md
continuous-discovery	改进想法来自个人意见，而非每周与用户交流	扩展 docs/CUSTOMER.md
improve-retention	审查中发现首次运行激活阻力（完整留存引擎：grow-app）	扩展 docs/PRODUCT.md
web-typography	应用以文本为主，阅读舒适度决定体验	扩展 docs/DESIGN.md
inspired-product	待办事项只有功能列表，背后没有成果目标	扩展 docs/PRODUCT.md

可选阶段遵循相同的执行规则——像处理核心阶段一样加载并使用每项列出的技能；当“在以下情况下添加”条件首次成立时，将其插入相应位置。

常见错误

错误	修正方法
在消除阻碍之前先打磨视觉效果——即使界面再漂亮，只要流程令人困惑，用户流失率也不会降低。	先执行阶段 2-3（ux-heuristics、design-everyday-things）；任何视觉改动上线前，都必须有阶段 1-3 的发现作为依据。
灰度布局还没做好，就开始添加颜色。	先做灰度，最后再上色；如果界面在去色后仍然不合格，再好的配色方案也救不了它（refactoring-ui）。
把“用户错误”归咎于用户，然后不断叠加更多警告。	用约束来防止失误，用撤销来弥补失误，而不是弹出“确定要继续吗”对话框（design-everyday-things）。
根据团队外没人测试过的内部语言重写文案。	按照 SUCCESs 流程去除行话，然后将改写内容作为 EXPERIMENTS 卡片上线，而不是凭空猜测（made-to-stick）。
在升级提示中制造虚假稀缺感或编造社会认同。	每个稀缺提示和用户评价都必须真实；任何需要编造证据的策略，都应替换为使用现有证据的策略（influence-psychology）。
上线修复后，跳过严格的端到端评审。	以新用户的身份，从头执行阶段 9；二元结论和按优先级排列的删减清单，能发现逐阶段修复遗漏的问题（steve-jobs-design-review）。

完成整个旅程

退出检查清单：

• docs/IMPROVE-APP-PLAN.md 中的每个阶段都标记为 done、skipped: reason 或 deferred: reason。
• CUSTOMER.md 重新明确用户要完成的任务，并指出应用在每个维度上表现不足之处。
• DESIGN.md 包含 UX 审计发现、设计令牌/组件、微交互清单，以及注明负责人和优先级的性能条目。
• POSITIONING.md 的 ## Key Messages 包含应用内文案和说服触点，且所有稀缺感和社会认同声明都真实无误。
• 每项已上线改动都是 EXPERIMENTS.md 卡片或待办条目，并预先承诺了衡量指标；PRODUCT.md 的 ## Outcome Roadmap 则包含 steve-jobs 的删减和修复清单。

关闭跟踪表：每个阶段都标记为 done / skipped: reason / deferred: reason，并将 Next Actions 纳入相应的归属文档，而不是留在计划中。

后续路线：当体验经得起考验，且目标转向习惯养成、留存和增长循环时，继续使用 grow-app 技能。当审计反复发现代码层面的问题（查询缓慢、崩溃、模块难以测试）时，继续使用 improve-code-quality 或 remove-technical-debt 技能。当营销网站成为下一个最薄弱的环节时，继续使用 improve-website 技能。