AX · 深度精读
原书:AX — The Rise of Agentic Experience · LCA (Late Checkout Agency) · Issue 02, Design in The AI Age (07.25) · Theo Tabah (CEO) + Ed Landon (GM) · 69 页 · First Edition 2025
一句话总结
UX 是 40 年来教人"会用工具"的学科,AX 是教软件"会做队友"的新学科 —— 它的核心不是把 AI 塞进旧 UI,而是把产品的中心从一次性任务 (task) 转移到长期关系 (relationship),并把 trust 当作唯一会复利的护城河来设计。书的整本论证是一个 stack:Manifesto → Why now → Evolution Curve (1-4 level) → 6 个可复用 Patterns → 3 个外延方向 (NL / Generative / Invisible) → 8 个行为 Principles → Business Case + 12 月 Roadmap → 4 个 Trust 未来场景。
整体架构
11 章可以折成 5 段:
我的判断:这本书在论证结构上是干净的,但中间偏短(整本 69 页,真正密度高的文字 ~40 页),它的价值不在"新概念量"而在给一组散落的趋势(NL UI、generative UI、agent autonomy、memory、multi-agent)起了一个统一的名字 AX,并用 trust 这条主线把它们串起来。它不是 textbook,是 manifesto + 设计手册混合体 —— 标准的 design agency thought leadership 装订法。
最大的内在张力(这本书自己没说透):AX 把 trust 当作 moat,但 trust 本身是滞后指标 —— 你在 build 阶段没法直接优化它,只能优化先行指标(transparency / clarify-before-commit / escape hatch / memory editability)。 全书 8 Principles 大部分就是 trust 的先行指标。这就是为什么 Principles 比 Patterns 更值得 Solutions team 内化 —— Patterns 是组件,Principles 是判断准则。
核心 framework 深读
Framework 1 — UX vs AX 的本质对比 (Ch 1 + Ch 2, p.6-12)
来源:Ch 1 "Extending UX for the AI Age" + Ch 2 的 Before/After 对照表 (p.10)
核心定义:UX 是 interface design,AX 是 relationship design。作者用一句话锁定迁移:"A product with memory, initiative, and judgment is a collaborator, not a tool. And collaborators don't live in workflows, but they exist within the context of relationships." (p.6)
作者特别强调 AX 不是替换:UX 的 core principles(用户目标、intent mapping、清晰 flow)还在,AX 在这层基础上加了三件事 —— initiative, judgment, trust (p.6)。
· Single-shot tasks · 每次会话归零
· Designer 预先写死所有 path
· User 提供所有 context
· 成功 = 更少点击、更快流程
· 静态 trust 契约("看起来干净所以能用")
· Ongoing goals & iterations · 从不"重头来"
· 系统自己规划路径
· Context 是学到的,不是问出来的
· 成功 = earned trust + compounding value
· 动态 trust 契约(早期 show work,熟了再放手)
对比传统 UX:作者举的反例 —— "speed as quality"。在 classic app 里,fast load + 确定性 flow 是质量信号,但 agent 如果直接从 A 跳到 B 跑结果,user 没同意 destination 就会觉得 jarring。"Trust often requires dialogue before resolution." (p.11)
Solutions team 12 人的应用: - backend agent 设计的盲点就是把 UX = "更少点击" 这条本能带进来。客户问"能不能 one-click 完成?",我们要敢说"在 trust 还没建立之前,一个 confirm 步骤的价值比省 1 个点击大" - 在跟客户写 acceptance criteria 时,把 retention / 用户主动调用率 / hand-off-to-human 比例 作为指标 —— 不是 task completion time - agent 的 success metric 模板要分两组:一组 task-level (准确率、cycle time),一组 relationship-level (复用率、用户编辑次数、信任级别变化)
反 pattern(team 大概率正在犯的): - 把"减少摩擦"当作宇宙真理 → 应该问"这次摩擦有没有在 calibrate trust" - 设计 agent 输出"自信、简洁、不解释" → 在 functional trust 还没建立时这是 overconfidence,user 会 churn - 把 agent 当 backend job 设计(input → process → output) → 漏掉了整个 relationship arc
Framework 2 — AX Evolution Curve (Ch 3, p.15-19)
来源:Ch 3 整章。一张 advantage vs intelligence 曲线 (p.16),defensibility 水位线在 Level 2 和 Level 3 之间。
核心定义:产品从 reactive assistant 到 collaborative partner 的演化路径,4 个不能跳级的台阶 —— "It's a curve for a reason: you can't skip steps. Each level builds on the last." (p.15)
作者论证 / 例子:作者没给具体公司 case,而是给了一个关键判断:"As a product leader, you can't fake it. You can't jump from prompts to social context without building trust and memory first. You have to earn your way up." (p.18) —— 这是这本书少数有判断力的硬话之一。然后:"AX favors small beginnings" (p.18) —— 从狭窄、深理解的用户社群起步,比横向铺开更容易爬到 Level 3+。
对比传统 UX:传统 UX 没有"成熟度曲线",一个 app 上线就是一个版本,做得好不好是 craft 问题,不是 stage 问题。AX 的曲线意味着同一个产品在 Level 1 / 2 / 3 的设计目标、metric、信任策略都不同。
Solutions team 12 人的应用: - 每次给客户做 agent design,先问 "你现在在 Level 几?目标 Level 是几?",而不是直接跳到 "我们 build 一个 agent" —— 大部分客户其实在 Level 1.5 想要 Level 3 的体验,这是错配 - 客户 agent 项目交付时,做一张 Evolution Curve placement card:当前 Level、未来 6 个月目标 Level、blocker 是 memory 还是 context 还是 social embedding - Level 1 → Level 2 跳跃靠 behavioral observation (RUM-style 数据),Level 2 → Level 3 跳跃靠 persistent memory infra,Level 3 → Level 4 靠 team / org knowledge graph。这三个是不同的工程任务,排期不能混
反 pattern: - 一上来就承诺客户 "personalized agent" —— Level 3 要求 cross-session memory + edit UI + privacy boundary,这是 6-12 个月的工作不是 1 个 sprint - 用 Level 1 的指标(回答准确率)汇报 Level 3 的项目 —— 应该用 retention / 用户主动加 memory 次数 / cross-session continuity
Framework 3 — 6 个 AX Patterns (Ch 4, p.20-33)
来源:Ch 4 整章。作者明确说"They aren't exhaustive, but they're reliable." (p.20) —— 这是 LCA 自己 dozens of frontier companies 里归纳出来的。
每个 Pattern 都配了一个真实产品 example,这是全书可操作性最高的部分。
Example: String (Pipedream 的 agentic workflow builder)—— 用户给任务后,String 复述需求 + 给 gameplan + 请求 approval,然后才开始 step-by-step 执行 (p.22)
Example: Perplexity 的 footnote-style citation —— 答案文字旁边数字角标,hover 直接看 source snippet (p.24)。作者说"这跟人类已有的 verify behavior pattern 一致"
Example: Bolt 等 vibe coding 工具,每个 accordion tile 都带 Revert / Undo,既可以自然语言 rollback 也可以直接跳进 code 改 (p.27)
Example: ChatGPT 的 Memory 设置面板 + "Updated saved memory" inline 提示 + 单条 memory 的 Forget 按钮 (p.29)
对比传统 UX:UX patterns(Material / HIG)是关于 视觉与交互的可复用组件(button, modal, navigation)。AX patterns 是 行为与信任的可复用 protocol(handshake、confirm、show reasoning、undo、remember、co-draft)。维度完全不同。
Solutions team 12 人的应用: - 内部建一个 "AX Pattern Library" Notion 页,每个客户 agent 设计前,先 map "我们这次会用哪几个 pattern" —— 不是从零开始想交互 - backend-heavy 设计师(就是我们 team 的多数人)最容易漏的是 Pattern 1 (Intent Handshake) 和 Pattern 4 (Escape Hatch) —— 因为 backend 思维里 "agent 收到 task 就该执行"。把这两个写成 design review 必查项 - Pattern 5 (Memory) 最容易做错:做了 memory 但没做 editable UI = 隐私雷区。每次给客户做 memory 时,memory editor UI 是同一个 epic 不是 follow-up
反 pattern: - 把 Pattern 1 (Intent Handshake) 做成"为了 confirm 而 confirm",每个动作都问一遍 → 应该是 intelligent friction,只在 high-stakes (send / write / trigger workflow) 时停顿 - Pattern 3 (Adaptive Canvas) 做成 "每次界面都不一样" → 破坏 spatial memory,users 找不到东西 - Pattern 5 (Memory) 偷偷记 → user 没法 audit / 没法 edit / 没法 delete = trust 一次性塌方
Framework 4 — 8 AX Principles (Ch 8, p.49-55)
来源:Ch 8 整章 + p.55 的 8 条总览表(注意 p.55 表格里 04-08 的 description 是排版 bug,作者复制了 Level 描述,正文在 p.51-55)
作者明确定位:"These aren't rules to be rigidly followed, but they're helpful modes of interaction that elevate the relationship between user and product." (p.49)
对比传统 UX:Nielsen 的 10 heuristics 是关于 interface usability(visibility of system status, match real world, etc)。AX 8 Principles 是关于 agent behavior in relationships —— 大部分跟 UI 没关系,跟 agent 的"性格 / 节奏 / 边界感"有关。
Solutions team 12 人的应用: - 把这 8 条做成 agent design review checklist —— 上线前 stakeholder 必须确认每条要么 ✅ 要么 N/A - Principle 3 (intelligent friction) 是反 OKR 的 —— PM 会想"减少步骤",但成熟 agent 必须在 high-stakes 点停下来。这个 trade-off 要在 kickoff 时跟客户说清楚 - Principle 4 (Pushback) 是 team 最不敢做的 —— 怕"反驳用户" → 应该 reframe 成 "junior consultant 反问 senior partner" 的语气训练。一个具体战术:agent prompt 里加 "If the user's request would cause X, Y, Z, suggest an alternative before executing." - Principle 6 (Loop In Other Experts) 直接对应 multi-agent 架构 —— 这是我们已经在做的事,但要把"什么时候 escalate to human" 当成 一等公民设计,不是 fallback
反 pattern: - Principle 1 (Tapered Transparency) 反过来做 —— 一上线就给 user 简洁结果不解释,等于 Day 1 就让 user 信任陌生人,trust calibration 失败 - Principle 7 (Memory) 做了但没做 boundary —— 记了 user 不希望被记的东西(政治 / 健康 / 私人吐槽) - Principle 8 (Moat) 误解成 "feature lock-in" —— 真正的 moat 是 familiarity,是 user 不想从头训练新 agent 的迁移成本
Framework 5 — Trust 的四个阶段 (Ch 9 内嵌, p.56)
来源:Ch 9 "The Business Case for AX",p.56 那一页是 Trust is the Foundation 子章节
这是全书我认为最被低估的图,它把 trust 从抽象拆成 可测量的 4 个 stage:
"Can it complete basic tasks reliably?"
测量: task success rate, error rate
"Does it understand nuance, preferences, history?"
测量: 用户 re-prompt 次数, edit-to-output ratio
"Can it make good calls in ambiguous situations?"
测量: 用户接受 agent 主动建议的比例, autonomy 让渡程度
"Will it act in my best interest, even when incentives misalign?"
测量: 用户主动推荐, "this agent feels like it's on my side" 类问卷
作者论证:"Break that trust, and the whole experience collapses. The fastest way to do that? Overconfidence. Inconsistency. Taking action beyond what's authorized. Optimizing for company metrics over user success. Mishandling complexity when a handoff to a human would've been better." (p.57)
对比传统 UX:传统 UX 的"trust"是个 binary 黑盒(brand trust / 视觉 polish 信任)。这里把它做成 4 个 ladder,每一阶要不同的 evidence 来跨越。Functional → Contextual 要 memory infra,Contextual → Judgment 要 reasoning visibility,Judgment → Advocacy 要 长期一致的"用户利益优先"行为。
Solutions team 12 人的应用: - 每个客户 agent 项目,kickoff 时定位 "我们目标爬到哪个 stage" —— Stage 2 跟 Stage 4 的设计代价差 10 倍 - 给客户做 monthly review 时,把 4 stage 当作 ladder 报告 —— 用户当前在哪一阶,下一阶要的 evidence 是什么 - 如果客户的 agent 在 Stage 4(代表用户做决定),架构上必须有 audit log + override + advocacy proof(为什么这个建议是为用户好,不是为公司好)
反 pattern: - 把 Stage 4 (Advocacy) 当成 marketing 话术 —— "我们的 agent 站在你这边" 是要用产品行为证明的,不是写在 landing page 上的 - agent 在 Stage 1 (Functional) 没爬稳就给 Stage 3 (Judgment) 权限 —— 比如"能完成任务"还有 10% 错误率时就让它 主动 发邮件,一次错误等于 reset 整个 trust
Framework 6 — Interface Detail Curve (Ch 7, p.43-44)
来源:Ch 7 "Invisible UI as an Option",p.43 的钟形曲线
核心定义:作者画了一条"interface detail required vs machine intelligence"的钟形曲线,机器越笨 (Terminal) 界面越简单 → 中间机器中等智能 (Heavy GUI) 界面最复杂 → 机器变聪明 (NL UI) 界面又开始简化 → 极聪明 (Ambient / Invisible) 界面消失。
钟形拐点的判断很硬:"The smarter the machine gets, the lighter the interface." (p.43)
作者论证:作者把行业按"是否准备好走向 Invisible"分了三类 (p.45): - Logistics / Operations: 仓库工人不想停下来看屏幕 → audio / haptics / peripheral - Healthcare: 临床医生需要 information, not interfaces → 在需要时 surface patient data,不要 explicit query - Financial Services: portfolio 自动调,routine 隐形,只 flag 需要 human judgment 的决定
然后作者给了一个关键判断:"When interfaces become invisible, what's your differentiation? It has to be the level of your understanding of the customer and the quality of your product's judgment." (p.45) —— 这是为什么 vertical / domain expertise 是 Invisible 时代的护城河
对比传统 UX:传统 UX 的 "less is more" 是减法美学(Dieter Rams);AX 的 invisible 是 能力反向投射 —— 界面消失是因为 agent 能力够强,不是因为设计师品味好。这是哲学差异。
Solutions team 12 人的应用: - 设计客户 agent 时,问 "这个交互的 ideal 形态是 visible UI 还是 ambient signal?" —— 比如 报表 agent 的理想形态是 "每周一早上自动 Slack 发 3 行 summary" 而不是 "用户登录 dashboard 看" - backend agent 项目里这个最有杠杆 —— 我们已经在 backend 跑了,只是 frontend 还在按"必须有 dashboard"思维做,要 push 客户接受 最好的 dashboard 是没有 dashboard - 在 Solution Architecture 文档里加一栏 "Visibility Mode": visible UI / inline overlay / push notification / ambient / none
反 pattern: - 把 dashboard 当成 deliverable —— 很多时候 dashboard 是 没想清楚 trigger 是什么 的兜底方案 - 误以为 "Invisible 就是 chat" —— chat 还是 visible(只是 modality 变了),真正的 invisible 是 system 不让你想起它的存在
Framework 7 — 12 月 Implementation Roadmap + 4 个失败模式 (Ch 9 末尾, p.61-62)
来源:Ch 9 末尾 "Implementation Reality Check" + p.62 的 12-month staged buildout
作者罕见地给了一个具体的时间线(全书少数硬数字):
然后作者给了 4 个最常见的失败模式 (p.62):
① Over-conversational — chat 能塞按钮的地方也塞 chat
② Under-contextual — agent 不懂 user pattern 就上线
③ Interface destruction — 为了 smartness 破坏 spatial memory
④ Trust erosion — agent 自信地猜、不 escalate、不给 recovery
① Conversational design ≠ UX,是 dialogue flow + trust scaffolding
② Agent engineering ≠ API plumbing,是 prompt arch + context mgmt + fallback
③ User understanding 从 click funnel → relationship quality
④ Systems integration 必须支持 partial failure 优雅恢复
作者的硬话:"AX success is less about model sophistication and more about organizational readiness." (p.63) —— 这一句应该写在每个 Solutions team kickoff slide 第一页。
Solutions team 12 人的应用: - 这个 12 月 roadmap 直接套用到客户提案。客户问 "你们要做多久",标准答案不再是 "3 个月 PoC",而是 "3 / 6 / 9 / 12 月 4 个 phase,每个 phase 的可见价值是什么" - 4 个 failure mode 做成 internal QA checklist —— 任何 agent 上线前过一遍 - 跟客户讲 ROI 时,引用书里的 3 个数字:Twilio 个性化 → 190% retention / 200% engagement (p.59),Eaton 用 generative AI workflow → 设计周期 16 周降到 2 周 (p.59),Spotify 推荐 → 十年 1000%+ 增长 (p.59)
反 pattern: - 跳过 Month 1-3 的 single workflow,直接做 cross-workflow memory —— 没有先证明价值,memory 系统就是空中楼阁 - 把 Conversational design 当成 UX writer 的活 —— 它是 dialogue flow + trust scaffolding 的工程问题,需要 prompt engineer + designer 一起 - "我们 model 已经很好了,UX 慢慢加" —— 作者的反话:model 已经 commodity,relationship 才是 moat,顺序反了
跨章互文 + 跟其他书的关系
内部互文(同一论点不同章节如何回响)
跟 master-reading-plan 里其他 Tier 1 书的关系
(注:这里只引同一目录里 master-reading-plan.md 已经放在 Tier 1 的几本)
- vs Anthropic 的 Building Effective Agents —— Anthropic 那本是 agent 内部架构(workflow / orchestrator / loop pattern),AX 是 agent 对外交互。两本是 backend / frontend 的关系,组合用 = 完整设计语言
- vs Agentic Design Patterns (Anthropic Patterns book) —— ADP 给的是 prompt 层 / control flow 层的 patterns(reflection, tool use, planning, multi-agent),AX 6 patterns 是 UX 层 patterns(handshake, confidence cue, escape hatch)。两套 patterns 是垂直关系不是替代:ADP 决定 agent 能力,AX 决定能力如何被信任
- vs Anthropic Economic Index —— AEI 给的是 用户究竟用 AI 做什么任务(经验数据),AX 给的是 做这些任务时的关系结构。AEI 是地基里的数据集,AX 是上层建筑
- vs Architecture Modernization 那本 —— Architecture modernization 关心 team topology + 服务边界,AX 在 product 层补了 user-product 关系边界。Architecture modernization 让 team 能 ship,AX 让 ship 出来的东西值得用
最大的 gap:这 4 本里没人系统讲 evaluation / observability for agents。AX 的 Principles 给了 该衡量什么(retention / autonomy / trust stage),但 怎么衡量(metric instrumentation)还是空白。Solutions team 自己要补这一块。
12 人 team 怎么用这本书(实操 framework)
8 项 AX Pre-Launch Checklist(任何客户 agent 上线前过)
给 team 写的 SKILL 卡片清单
建议在 00-system/skills/ 下建 4 张 skill 卡:
内部共识改造(Solutions team 的本能反应需要重训练)
· "agent 收到 task 就该执行"
· "减少步骤 = 更好的设计"
· "model 能力是核心 differentiator"
· "agent 的成功 = task accuracy"
· "memory 是 nice-to-have"
· "interface 越简洁越好"
· "agent 收到 task 先 handshake 再执行"
· "Intelligent friction 比 frictionless 更值钱"
· "model commodity,relationship 才是 moat"
· "agent 的成功 = retention + trust stage 上升"
· "memory 是 Level 3 的入场券"
· "interface 该消失就消失,该显眼就显眼"
我的判断:这本书的 3 个最大 insight
Insight 1 — Trust 是唯一会 compound 的护城河,所以它是产品策略问题,不是 UX 问题
作者反复说 "trust is the moat",但真正的洞察是 trust 是个 复利变量 —— 每一次正确的 intent handshake / escape hatch / show-your-work 都在 deposit,每一次 overstep / 错猜 / 不 escalate 都在 withdraw。这跟 brand equity 在数学上同构(品牌也是复利的),但 brand 是营销层的,trust 是产品行为层的。
对 Solutions team 意味着:agent 项目的 ROI 模型不该用 "save X hours per week",该用 "trust stage 爬升曲线 → user retention 提升 → contract expansion"。前者是一次性,后者复利。
Insight 2 — AX 是 4 个 trust 未来的"通用语言"(BYOA / Browser / OS / Vertical)
Ch 10 的 4 个 future 表面上是预测,但作者用 同一套 AX framework 解释 4 个不同的赢家路径:无论赢的是 personal agent (BYOA) / browser (Dia, Arc) / OS-level AI (Apple/Google/Microsoft) / vertical companion (specialist startup),输的逻辑都一样 —— 没爬上 trust 的人输。
这是 framework 的真正威力:4 个未来场景表面上互相排斥,但都用 AX 的同一套指标筛选赢家。所以学这本书不是学一个具体行业的设计,而是学一个 用来评估任何 agent 类产品的诊断工具。
对 Solutions team:不管客户是 BYOA、browser、OS、还是 vertical specialist,问的诊断题是同一套(Evolution Curve placement + Trust Stage + Pattern coverage + Principle compliance)—— 这正是把我们做成 uniformly applicable advisory team 的杠杆。
Insight 3 — "Organizational readiness > Model sophistication" 是 1 句话颠覆整个销售话术
p.63 那句 "AX success is less about model sophistication and more about organizational readiness" —— 这彻底改变销售对话:
- 不再卖 "我们用最强 model 给你 build" —— model 是 commodity
- 而是卖 "我们让你的组织有能力 维持 一个 AX 产品的演进" —— conversational design + agent engineering + relationship metrics + systems integration 这 4 个 capability 一个都不能少
这意味着 Solutions team 的真正产出不是 "一个 agent",而是 "客户组织里能持续运营 agent 的 4 个 capability"。前者是 deliverable 项目,后者是 advisory engagement。商业模型完全不同 —— 后者的 LTV 高一个数量级。
Lightning 30 min · 给 team 内部分享版
15 分钟讲完的 4 句话脚本
一行 takeaway
"Build agents that earn the right to assist again tomorrow."(p.57 的改写)
Reading notes by Zhichao · 2026-05-17 · 基于 PDF first edition, LCA Issue 02, 07.25