最初只有一张散点图，异常还读不出来
这是最早的 PRD 原型，只有散点、连轨迹都还没有。身份识别、异常原因和信息优先级都还没有被组织起来。
让设计在真实数据里成立。
这是 Surf Cryptopedia 2.0 Heat Map 的一次完整设计迭代：起点是一版 mock data 图表，三天后交付的是经真实数据校准的可运行原型和最终设计。这里记录的不只是结果，而是这条 AI 工作流怎样运转——上下文如何构建、AI 在哪里探索、我在哪里做判断。
Final design / In product context
Outcome从 mock data 图表到真实数据交互原型
Timeline3天 · 从初版到最终交付
Iterations10+轮方案与实现迭代
Team1名设计师 · 0 前端支援
01 / Before → After
三天之后，变化不只是画面，而是阅读顺序终于清楚了。
初版主要在展示数据，最终版本把「这是谁、发生了什么、为什么异常、我还应该看什么」连成了一条路径。它不是停留在 Figma 里的理想状态——每一条规则都在真实代码和真实数据里走过一遍。
从看到一个异常点，到读懂它为什么异常
token、价格变化、信号 breakdown、Heat 与 AI Summary 现在可以顺着读下去。
02 / Context Engineering
动手之前，我先让产品、设计和代码处在同一个上下文里。
我最开始想解决的不是样式，而是这张图究竟要帮人看懂什么。所以第一步不是写 prompt，而是 Context Engineering:决定哪些材料必须进入 AI 的上下文、哪些约束不能被改写。这一步很花时间，但它决定了后面的建议会不会只是「另一张看起来不错的图」。
我先把图放回真实产品里，再决定哪些信息值得被看见。
我的第一步
我把 PRD、现有界面、Surf 设计规则、代码和数据接口一起交给 AI。这样它面对的不是一个「请优化 UI」的空泛问题，而是一个有来路、有约束、也有后续交付方式的产品问题。
我带进来的材料
它帮我解决什么
怎么使用
产品 PRD
先理解 Heat、四个信号维度以及异常状态到底代表什么。
Read
Surf Design System
让颜色、密度、圆角与暗色模式继续属于 Surf，而不是生成另一套视觉语言。
Constrain
现有 Figma
通过 Figma MCP 直接读取：看清原本的设计意图，也看清哪些结构已经走不下去了。
Compare
代码仓库
确认页面、组件和接口的真实结构，让方案可以直接进入运行环境。
Build
真实价格数据
用真实分布检验坐标、离群点、轨迹和筛选器，而不是让 mock data 替设计兜底。
Validate
03 / Process
实际过程没有这么整齐。我把它重新整理成了七个转折点。
原始记录里有尝试、返工，也有很多很小但重要的调整。这里按照事情真正发生的顺序重排，并分别写清楚我做了什么、AI 帮了什么、每一步留下了什么。
00 · Where I started
我从一版已经能跑的图表开始。
初版有筛选、散点和轨迹，也能让人感受到市场变化。但它依赖 mock data，点位不容易辨认，hover 后的信息也没有形成明确的阅读顺序。这些问题成为了后面每轮迭代的参照。
- 我做的
- 先写清楚哪些地方是真的不好用，而不是笼统地要求「再优化一下」。
- AI 做的
- 帮我梳理现有结构，确认哪些代码和组件可以继续沿用。
- 留下的
- 一份可以持续对照的初始版本。
我没有从 prompt 开始，而是先把上下文补齐。
我让 AI 先读 PRD、Surf 设计规则和现有 Figma，再进入代码分支查看页面、组件与接口。它需要知道这些信号是什么意思，也需要知道最终的设计要回到哪里。
- 我做的
- 决定哪些材料必须进入上下文，并指出产品里不能被随意改写的部分。
- AI 做的
- 通过 MCP 读取 Figma 和仓库，把分散的信息整理成对当前任务有用的背景。
- 留下的
- 一份双方都能继续工作的共同起点。
我先比较信息怎么读，再讨论它应该长什么样。
围绕异常的四个维度，我让 AI 快速试了 radar、dimension equalizer、verdict-first 等不同结构。这个阶段故意保持低保真，因为我需要比较的是阅读方式，而不是哪张图更精致。
- 我做的
- 提出几种值得比较的阅读路径，并确保方案之间真的有差异。
- AI 做的
- 快速把抽象方向画出来，让它们可以被并排讨论。
- 留下的
- 一组不靠装饰区分的候选结构。
我没有选中某一版，而是把几版拆开重组。
B 和 C 的主体结构更适合承载信息，D 的标题更快进入结论。我把它们重新组合成一条阅读路径：先知道发生了什么，再看整体形状，最后深入信号证据。
- 我做的
- 比较各版真正有效的部分，重新安排顺序，并说明为什么这样组合。
- AI 做的
- 按照新的组合继续做高保真方案，帮我快速看见合并后的效果。
- 留下的
- 一个不属于任何单一候选稿的新方向。
方向一旦清楚，我就让它尽快进入真实页面。
AI 直接在代码里实现地图、hover 卡片、筛选器和动画。我在运行页面上继续看颜色、padding、轨迹、对齐和信息密度;很多在单张效果图里看不见的问题，这时才会出现。
- 我做的
- 在完整页面里检查关系，把「有点不对」继续说成可以修改的具体问题。
- AI 做的
- 修改代码、运行预览，并在不破坏已有功能的前提下快速迭代。
- 留下的
- 一个可以真实操作、继续修改的前端版本。
换上真实数据以后，原来成立的东西又要重新判断。
真实 price data 带来了更极端的离群点，也暴露了坐标尺度、轨迹密度和筛选逻辑的问题。它不是简单替换内容，而是在告诉我：这套视觉规则能不能承受真实世界。
- 我做的
- 找出 mock data 没有暴露的问题，决定哪些规则需要为真实分布让路。
- AI 做的
- 接入数据、调整参数，并处理坐标、轨迹和筛选器的实现细节。
- 留下的
- 一版经真实数据重新校准的 Heat Map。
最后，我回到 Figma 完成那些仍然需要手工判断的部分。
我重新整合了地图、卡片、Attention Frontier 和 AI Summary，也把过程中真正影响结果的取舍写下来。最终稿不是某一次生成的终点，而是多轮比较、实现和返工后的合成。
- 我做的
- 完成最后的视觉取舍，并回头辨认哪些判断真正改变了结果。
- AI 做的
- 帮我比较不同阶段，整理零散记录，让过程可以被重新阅读。
- 留下的
- 最终 Figma 设计、可运行版本和这份过程记录。
这一阶段的原始记录 · 补齐上下文
2 records这一阶段的原始记录 · 打开方案
4 records · scroll这一阶段的原始记录 · 拆开重组
1 record这一阶段的原始记录 · 放进代码
3 records · scroll这一阶段的原始记录 · 换上真实数据
8 records · scroll这一阶段的原始记录 · 回到 Figma
4 records · scroll04 / Workflow & Toolchain
回头看，这次协作反复发生的是同一个循环。
我没有依赖某一条特别神奇的 prompt。真正有用的是：每一轮都知道自己在解决哪一层问题，先让 AI 快速尝试不同方向，再由我收窄范围，然后尽快回到真实环境里检查。这个循环不属于这一个项目——它是可以复用的工作方式。
看清问题
产品目标 · 数据含义 · 现有界面 · 用户阅读路径
打开选项
低保真草图 · 不同信息结构 · 不同视觉表达
做出取舍
比较 · 删除 · 合并 · 重排优先级 · 说明原因
回到真实环境
代码 · 接口 · 真实数据 · hover · 筛选 · 动画
留下判断
最终 Figma · 可运行原型 · 调整记录 · 设计原则
这个循环背后的工具链
Inputs / Context
产品与约束
- 产品 PRD
- Figma 设计稿
- Surf Design System
- 代码仓库 · 数据接口
Agent
Claude Code
- Figma MCP · 读取设计稿
- 浏览器预览 · 视觉验证
- 终端与代码执行
- Opus 4.8 · 1M context
Running Prototype
真实环境里的页面
- 真实价格数据
- hover · 筛选 · 动画
- 暗色 / 浅色模式
Deliverables
回到 Figma 定稿
- 最终设计稿
- 可运行原型
- 设计原则沉淀
每一轮验证的结论，都会作为新的上下文回到循环起点 ⟲
我没有让 AI 替我做决定。我让它帮我更快地看到决定会带来什么。
每一轮怎样继续
「感觉不对」不能直接进入下一轮。我会把它改写成具体问题：信息是不是太平、标签是否抢焦点、浅色模式为什么变脏、真实数据为什么把坐标压扁。问题越具体，下一次结果越有用。
05 / Judgment
真正改变结果的，是我没有顺着每一个现成答案走下去。
AI 给了我很多可以继续发展的方向，但最后留下来的结构，大多经过了删除、合并或重新排序。下面六个取舍最能说明最终设计为什么会变成现在这样。
Decision 01
我换回了真实 token logo
AI 生成的 monogram 很整齐，但交易者首先需要的是快速认出自己在看谁。熟悉的 logo 比统一的形式更重要。
Decision 02
我让价格和公式露出来
只有一个 Heat 分数，会让结果像黑盒。我补回价格变化与计算关系，让人能判断这个异常值不值得相信。
Decision 03
我没有在四个方案里选一个
我保留了 B 和 C 的主体结构，再拿 D 的标题方式放到最前面。最后的版本来自组合，而不是投票。
Decision 04
我把产品本身加了回来
它既然是一张地图，就应该有 Attention Frontier;它既然属于 AI research 产品，就应该有一段真正有用的 AI Summary。
Decision 05
我重新排了信息顺序
先读状态和原因，再看 breakdown，最后用 radar 建立整体印象。不是每个模块都值得同样大的声音。
Decision 06
一种颜色只做一件事，控件能合就合
状态色只表达涨跌，维度色留给 breakdown;筛选器能合并就合并，让注意力回到 token 和异常本身。
06 / Reflection
这次做完以后，我也看到了几个下次可以更早处理的问题。
原始日志本来只是工作记录，有些重要判断是在结果出来后才被我重新命名。如果再做一次，我会更早建立记录方式和检查标准，让过程本身也成为可以持续积累的设计资产。
我会继续保留的做法
- 先让 AI 理解真实产品，再让它提出设计答案。
- 先用低成本方案打开选择，晚一点进入高保真。
- 不必选中某一个生成结果，可以拆开再重新组合。
- 尽早进入代码和真实数据，不让 Figma 替现实兜底。
如果再做一次
- 在第一轮就写下几条清晰的体验假设，避免中途反推目标。
- 同步记录「为什么拒绝」，而不只保存被选中的方案。
- 更早检查浅色模式、响应式和设计 token 的偏差。
- 补充真实用户反馈与使用数据，验证阅读顺序是否真的更快。
AI 改变的不是速度，
而是设计师能负责的范围。
这一次，我可以一个人把设计一路送到真实数据面前：更早看到更多可能，更快把判断放进真实环境里检验。而我正在做的，就是把这种协作方式，变成团队可以复用的日常工作方式。