他的心智模型：AI 加长的是 T 型人才的那一横

设计圈有个「T 型人才」（T-shaped）的老说法：一竖是你扎得最深的那一块，UX、UI、研究、动效随便哪个；一横是你能横跨其他领域把事情办成的宽度，不要求同样水准同样速度，够把活推动起来就行。

AI 加长的是那一横。它让他在自己不擅长的领域里快得多。

这里他给了一个挺诚实的限定，值得原样记下来：这个增益因领域而异，也因人而异。比如 AI 在高质量视觉设计上还是不行，至少按他自己的标准、按他对自己的要求来说不行。但换成一个不太懂设计的开发者，让 AI 生成一个简单的落地页，结果就相当能看。

第二层模型是关于「设计师这份工作到底是什么」。他把它剥到底：理解问题、理解横跨业务和技术和产品的那些关联与影响，然后找到能把它们捏合到一起的方案。落到实操上，就是不停地换方向、换思路、反复迭代，直到某一下对了。

AI 让这个循环转得更快。他说他把 AI 当草图或者纸原型用：产出物本身不是重点，把自己的思考推过「显而易见」那一层才是。

工作流一：周报和工单交给一个 Claude Skill，他只负责点头或跳过

先说一个前提，这条决定了你能不能照抄：FitXR 没有传统意义上的产品经理。项目和围绕它的日常运转，由做这个项目的一线同事自己扛，排期、对齐、开工单、写进度更新、给管理层汇报，全都压在本职的设计和工程工作上面。所以他们能自动化的都尽量自动化。

他用的组合是 Claude + Skills + 连到 Slack、Granola、Linear 的 MCP。Granola 是会议记录工具，负责把通话转成文字和纪要；Linear 是团队的项目和任务管理工具。

链条是三步：

Granola 负责抓上下文。团队是远程的，上下文散落在 Slack 线程、站会、会议通话里；有了它，他开会时可以真的在场参与，而不是低头记笔记。然后到每周末，一个 Skill 去扫这些转录和 Slack 消息，按不同职能、不同同事分别草拟 Linear 的进度更新。

第二个 Skill 管的是「漂移」。他说他们团队以「在 Slack 里做完决定就再也不出 Slack」而臭名昭著。这个 Skill 拿对话去比对 Linear 上的工单，把对不上的地方标出来，范围变了但没同步回去、状态写错了、决定做了但没记录。每条建议他自己过一遍，批准或者跳过，几分钟搞定。

他现在同时卷在六个项目里，都属于同一张大图，但各有各的细节、难点和碎片。几个月前，他只会用这个投入度盯住一个项目。他的判断是：如果全靠手工盯这些，很容易就变成一份全职工作；AI 不能替代投入和理解，但它能把可重复的、极其耗时的那部分卸掉。

Skill 原文就在截图里：触发条件怎么写、输出模板长什么样

这一节的东西正文一个字没提，全是从上面那张截图中间那块读出来的。这个 Skill 叫 linear-status-update，触发方式是「斜杠命令 + 自动」。

它的描述几乎全在写「什么时候该出场」

描述部分花了绝大部分篇幅穷举用户可能怎么开口：draft an update for the project、write a status update、update Linear based on slack、write a project update from our meetings、pull together a project update，以及「任意一个来源（Slack、Granola、会议）加任意一个去处（Linear、项目更新）的组合」。最后还补了一句兜底：

只要是在把近期动态汇总成 Linear 更新，就用这个 Skill，哪怕用户根本没提「skill」这个词。

截图中的 Skill 描述，本站译

这个写法本身就值得学。写 Skill 的人容易把力气全花在「怎么做」上，结果它在该出场的时候没被唤起。触发条件写得越具体、越接近人真实的说话方式，它才越可靠。

步骤 3：动笔前先想清楚什么是新的

Step 3: Identify what's new
Before drafting, work out:
- What has happened since the last update?
- What decisions were made?
- What was completed? What's in progress?
- Are there any timeline changes, milestone shifts, or blockers?
- Is there any significant engineering or enablement work worth
  calling out?

Focus on substance. Ignore noise like channel join messages, bot
notifications, and minor logistics. If something was already
covered in a previous update, don't repeat it.

最后那两句最该抄。周报之所以难看，通常问题出在噪音太多、还老在重复上周说过的话，而不在信息不够。把「忽略什么」写进去，比把「写什么」写进去更管用。

步骤 4：先照抄这个项目已有的格式，没有才用默认模板

步骤 4 的第一句是「严格遵循这个项目已有更新的格式和语气」，只有在没有历史更新时才用下面这个默认模板：

# DD.MM.YY - [Project Name] Update

## Status:

* :[emoji]: [On Track / At Risk / Off Track]

[Optional: one or two sentences of framing context — a key
decision, headline shift, or anything needed to set the scene.
Omit if there's nothing essential to say here.]

## Last Week:

**[Workstream]:**
* [What happened — @mention relevant people where useful]

工作流二：让 AI 先把显而易见的想法快速倒完

这条他自己也说是比较显然的用法，但他讲了自己怎么想这件事，值得看。

他不指望 AI 给出「那个答案」，多数情况下它给不出。AI 真正擅长的是：把所有显而易见的、简单的、有时甚至有点蠢的想法，非常快地倒完。

因为在任何创作过程里，最先冒出来的想法通常是最可预测的那些。只有越过这一层，才开始摸到有点意思的东西。AI 把这一层加速了，所以他不用从白纸开始，他手上有个起头。

第二个场景是真卡住的时候：有个奇怪的边缘情况，一堆变量要考虑，每个选项都不太对劲，怎么选都有取舍，人会在这个循环里出不来。这时他让 AI 把可能的方向快速铺开。这些方向本身谈不上完美，但铺开之后能把这个空间和所有取舍看得更清楚，通常这就够他脱身往前走了。

工作流三：喂原料让 AI 出一版结构初稿，人来改和抛光

他说这是 AI 开始像「真·超能力」的地方：需要消化大量数据、逻辑和活动部件的场合。套路是固定的，

案例：Checkpoints

他最近做的一个项目类似「Spotify Wrapped」，一个里程碑庆祝时刻，给用户一份数据、成就和高光的总结，要做得特别、个性化。

纸面上这种点子听着很棒，一旦开始想实现和逻辑就迅速复杂起来。难点很具体：他们有八个不同的健身品类（原文 eight studios，指搏击、拳击、HIIT、舞蹈、尊巴这类课程门类），有些共用数据点比如卡路里和连击分，但很多指标完全不同，搏击和拳击记出拳数，HIIT、舞蹈、尊巴记步数。另外还有一大堆采集了但根本没往界面上放的数据。

他从开发那儿拿到一份原始数据 dump，说手工整理这些「说实话简直是噩梦」。

· 项目背景
· 我想达成什么
· 数据文件
· Figma 设计的链接
· 解释每个屏幕的笔记

他对产出的评价很克制，这段照抄：它不完美，有几个问题，有些数据他不想用，有些地方 AI 理解错了或者假设错了。但那不是重点。重点是他不用从白纸开始自己捋，而是手上有了一个很强的起点，从那儿往下深挖、逐块细化、打磨到能进生产。

副产品是他得到了一份能发给团队的结构化文档，可以当作全队的唯一真相源。他说了一句挺有分量的话：这种产物，放在以前是他花一周从零做出来会挺自豪的那种。这次他不到一天就有了一个扎实的版本。

AI 写出的数据逻辑文档：20 个高光候选，外加一套五步挑选算法

正文只用一句话带过了这份文档，但截图把它整个摊开了。文档叫 DATA-LOGIC.md，开头第一句就是自我定位：

本文档定义每个屏幕展示什么数据、数据从哪来、怎么算。迭代原型时以它为准。

DATA-LOGIC.md 开篇，本站译

里面有四块内容，一块比一块具体：

什么算一个好的高光，文档里写死了

他后来把这份文档做成了可浏览的说明站，那一版里有一段定义，是整篇最值得搬走的产品判断：

高光是这一章里最令人印象深刻的那一个具体数字。它必须让人感觉像一段具体的记忆，而不是一个汇总指标。

什么算好的高光：具体、人能读懂（312 拳，而不是综合表现分 72.4）；专属于某一次训练；每次 checkpoint 都不一样，这样才不会看腻。

Checkpoints 数据逻辑说明站，本站译

「312 拳，而不是综合表现分 72.4」这一句，基本上把这类功能的成败讲完了。

挑选算法五步

二十个候选里最后只有一个能上屏，靠的是这五步。这是全篇最能直接搬走的一段：

1. 过滤  排除关键字段在整章内为空或为零的候选；
         排除粒度条件不满足的候选
         （例：没有多节课的日子 → 跳过「单日」级候选）

2. 打分  score = 数值 ÷ 该指标「够惊艳」的阈值

3. 选取  分数最高的胜出；
         平手时优先粒度更细的（单节课 > 单次训练 > 单日 > 整章）
         理由：越具体越让人记得住

4. 多样性 如果同一类别在上个 checkpoint 已经赢过，
         跳过它，用下一个高分

5. 副标题 单节课级 → "{课程类型}, {日期}"
         单次训练级 → "Workout, {日期}"

他给分支流程做原型，前两次都失败了：Figma 里失控，Google 文档没人读

这一段是全篇最有用的经验，因为他把失败讲得比成功还细。

项目叫 Positive Friction，是他在 FitXR 的第一个大项目：重做新用户引导。方向从「优化到能开始玩的时间」转向个性化得多的流程，用户走一串比较长的问题，分成若干段，根据答案看到不同的洞察，结尾拿到一组个性化高光和一份达成目标的计划。他基本上全包：问题和答案、逻辑和分支、洞察屏，最后连高保真设计。

第一次：在 FigJam 和 Figma 里画，几乎立刻失控

他先在 FigJam 里映射流程，再在 Figma 里做些小原型，演示某些答案和洞察怎么走。几乎立刻就变得无法管理，组合太多、条件太多、任何一点小改动都会涟漪到其他所有地方。

第二次：写成剧本发给大家评审，结果没人给反馈

有人建议他先聚焦内容：把所有问题、答案、分支逻辑放进一个 Google 文档，几乎像一个剧本，用那种方式评审。

结果他基本没拿到任何反馈。而他自己承认这完全说得通，那玩意儿读起来很痛苦：

你感受不到流程。你判断不出它是不是太长，也没法判断问题问得好不好。你更不可能测试这个体验。

Krystian Zun，本站译

到这一步，他说多半是出于绝望，冒出一个念头：我都用 AI 做过自己的产品和点子了，能不能干脆用 AI 把这份文档变成一个原型？

成了，而且效果很好。

换成 AI 做原型之后：改一处逻辑变成改一行数据

先说清楚 Figma 的边界在哪。Figma 应付大部分设计工作没问题，但有些项目交付的是一整套系统，带分支、逻辑、个性化和不断变化的状态，一屏屏画面只是它的表层。给这种东西在 Figma 里做原型，用他的话说，「从难受到基本不可能」。

换成 AI 之后，到进入视觉设计阶段之前他几乎没再碰 Figma，改用 AI 迭代真正的体验：内容、问题顺序、分支逻辑、洞察的不同呈现方式，甚至不同的输入方式。

最大的差别是他可以一次性在整个流程上迭代。收到这类反馈的时候，「改这个问题」「这一段挪前面」「换个方式展示这条洞察」「更新这个答案的逻辑」，他不用先手工更新一份真相源文档、再把改动重写到原型的各个角落。他把反馈丢进对话，AI 就在整份东西上一次改完。

这彻底改变了迭代的速度和深度。因为我不再是在给屏幕做原型了，我在给行为做原型。

Krystian Zun，本站译

截图里能看到这个原型是怎么搭的

项目叫 positive-friction，是个 Next.js 应用。目录结构里最关键的一个决定是：仓库里有个 docs/ 文件夹，放着 BRANCHING_LOGIC.md、BRANCHING_LOGIC_EXAMPLES.md 和 QUESTIONNAIRE_OVERVIEW.txt，逻辑说明和代码待在同一个仓库里，AI 改代码的时候能同时读到规则。

QUESTIONNAIRE_OVERVIEW.txt 是大白话写的规格书。截图里能读到真实内容：第 2 题是「你在健身（或 FitXR）上的主要目标是什么？」，五个选项，提升精力并减压 / 减重并更健康 / 增肌塑形 / 玩得开心 / 改善柔韧度。这一条底下用星号框着标明：这是一道分支题，它决定后续出现哪些问题。然后展开 BRANCH A：只有选了「提升精力并减压」的人，才会看到接下来那道「你什么时候最需要提神？」以及随后那张过场屏。

而那张过场屏的文案，会再按上一题的答案换成三版中的一版。下面这个可以点：

全部机关只有两个字段

代码里对应的结构在 questionnaire-data.ts 里，只用两个字段就把上面这套东西撑起来了：

// 条件显示：前面某题选了指定答案，这一步才出现
showIf: {
  conditions: [
    { questionId: "goal-selection",
      operator: "equals",
      value: "have-fun" },
  ],
}

// 动态文案：按前面某题的答案，换掉这一屏的内容
dynamicContent: {
  questionId: "fun-type",
  contentMap: {
    "music-rhythm":       "...",
    "competition":        "...",
    "variety-surprises":  "...",
    "feeling-connected":  "...",
  },
  defaultContent: "Got it — we'll fill your plan with the
                   kind of fun that keeps you hooked.",
}

其余的组织方式也很干净：lib/ 底下按职责拆成数据、条件判断、动态内容、状态、类型五个文件；界面组件和屏幕各一个目录。还有个小设计值得学，DebugNavigation.tsx，跑起来的原型左上角有个 Debug 按钮，评审的时候可以跳着走，不用每次从头把问题答一遍。

他怎么拿反馈：原型部署成链接，扔进 Slack

这一步正文也没写，但它是整套流程能转起来的关键。原型部署到 vercel.app，直接把链接甩进 Slack，配一段结构化的说明：这次改了什么、我特别想要哪方面的反馈、下一步是什么。

还有个小动作挺聪明：他把同事的反馈整理成 txt 文件提交进仓库，git 记录里能看到 Create sams_suggestions_v2.txt 和 add sam's notes to breakdown 两次提交。反馈进了仓库，AI 下次改的时候就能直接读到。

他说这个项目最后成了公司历史上最成功的实验之一，没有给任何数字。他自己的定性是：这是 AI 不只让他更快、而是让一个本来多半不会发生的版本变成可能的例子。

工作流五：四个 Agent 在 Paper 上并行画界面，一个界面约三分钟

先给他的总判断：前面几条都是逻辑、系统和结构，这是 AI 最强的地方；但对于精细的、能进生产的 UI，他仍然认为 AI 不怎么样，除非你有一套扎实的设计系统托底。

不过有两块他最近在试，而且是真的兴奋。

Paper：一块给 AI 画画的无限画布

Paper 是个画布设计工具。他的形容是：类似 Figma，但建立在 HTML 而不是私有格式上，而且从一开始就是照着 AI 和 MCP 工作流设计的。他明确说它还在 alpha、缺基础功能，现在还替代不了 Figma。

但作为一块给 AI Agent 去创作的无限画布，他说它已经领先很多：可以同时跑多个 Agent，并行探索好几个布局或方向，而不是一次一个。配一份写得好的 design.md，结果「意外地不错」。而且因为是 HTML 底子，设计到代码的鸿沟几乎消失，他做过一个小实验：在 Paper 里复刻一个 Figma 组件，然后让 AI 直接把它建进了他们的代码库。

截图右下角那几行状态条给出了正文没有的硬数字：

更值得看的是它自己会检查自己。日志里那串对话是这样的：「东西都放好了，让我截个图检查一下质量。」→「看起来不错！内容在底部被裁掉了，切换画板为 fit-content。」→「fit-content 干净地解决了裁切。」这个「产出 → 截图自查 → 发现问题 → 修」的循环，才是它能真出活的原因，而不是一次生成就完事。

收尾汇报里能看到它是照着设计系统做的，颗粒度细到这个程度：状态栏用 #FAFAFA 中性外壳配深色图标、导航标题用 Barlow 700、头像配 #3B8AF3 蓝环、数据行是三张白卡（训练数 / 连续天数 / 卡路里）、周目标进度卡蓝色填充白色轨道且完成度 80%、退出按钮用 #E4FE5B 柠檬绿药丸配深色文字，并且专门注明「柠檬绿按 FitXR 规范只留给主要 CTA」「蓝色强调色一致性：数据数字、PRO 徽章、进度填充、图标着色全部使用 #3B8AF3」。

他不擅长动效，于是让 AI 先去探索，自己同时干别的

这一条绕回了开头那个 T 型模型，也是全篇的因果闭环。

他对动效的态度写得很具体：很尊重，漂亮的动画能让产品的感觉好一大截；但这不是他自然而且快的地方。每次要碰他都有点发怵，主要是知道会花掉不少时间。难点在于，他很难从静态帧之间想象出转场，更难想出既好看又有点独特的东西。这就不是他那一竖。

现在的做法很朴素：给上下文、描述想法、给关键帧或者静态屏，让 AI 提出转场方案，或者直接在它们之间做动画。

他的自评也很诚实：对专业动效设计师来说这可能非常基础，但对他这样的人就很有用，它把他带到一个好得多的起点，之后他还能自己进去细化和打磨。

他最后的落点是：AI 没让他什么都擅长，也没有取消对品味、判断和理解问题的需求。它给的是杠杆，起步更快、探索更多方向、处理更多复杂度、在自己不强的领域里也能干活、同时让好几件事往前走。所以他认为真正的机会在于围绕它重新想我们怎么工作：哪里保持掌控、哪里交出去、哪里用它脱困、哪里用它给自己的思考腾出更多面积，从小任务里省下几分钟，是最小的那部分收益。

他没交代的几件事：说 AI 有拖后腿的时候，却一个例子都没给

这份方法档案有几个洞，照抄之前值得知道。

一、最可惜的一个。他在开头明确说过，一路试错让他搞清楚了 AI 在哪些地方帮不上忙、甚至拖慢他、不如自己动手，然后整篇没有给出一个具体例子。方法文里「什么时候别用」往往比「什么时候用」更值钱，这一块整个缺席了。

二、「六个项目」没有任何量化对照。多大算一个项目、每个投入多少、质量有没有下降，都没说。「公司历史上最成功的实验之一」同样没有任何数字，留存、转化、完课率一个都没有。这些全部是他自己的口径。

三、组织前提对多数读者不成立。他能同时管六个，前提是 FitXR 没有产品经理、项目由一线自己扛。在有专职 PM 的团队里，他卸掉的那部分工作本来就不在设计师手上，杠杆自然小得多。

四、两个 Skill 只有一个能看到。周报那个能从截图完整还原，管「漂移」那个没有任何可看的东西，而后者听起来是更难写、也更有意思的那个。

五、design.md 没给样张。他说「配一份写得好的 design.md，结果意外地不错」，但这份文件长什么样一个字没提。从 Paper 那一节 Agent 汇报的颗粒度看（精确到某个色值只能用在主要 CTA 上），多半正是那份文件决定了效果好坏，可惜没放出来。

先说前提，这条决定你能不能照抄：FitXR 没有传统意义上的产品经理，排期、开工单、写周报、给管理层汇报，全压在一线同事本职的设计和工程活上面。他把这套流程写成一个 Skill（写给 AI 的固定作业指导：什么时候出场、按哪几步做、产出长什么样），每个周末跑一遍。

Granola 把通话转成文字，他开会时可以真的在场参与；Linear 是团队记工单和进度的地方；最后一关始终是人。截图里 Skill 的原文有两处能直接搬走：触发条件穷举了他真实会怎么开口，末尾还补一句哪怕没提 skill 这个词也照办；步骤里明确写了要忽略什么，入群消息、机器人通知、上次已经讲过的事。

更硬的一套是这个：喂原始素材，让 AI 出一版有结构的初稿，人来改和抛光。他做的功能类似 Spotify Wrapped，给用户一份阶段总结，难在八个健身品类的指标各不相同（搏击拳击记出拳数，HIIT 舞蹈记步数），还有一堆采集了但从没上过界面的数据。他把项目背景、想达成什么、数据文件、设计稿链接、每一屏是干嘛的笔记一起丢过去，拿回一份数据逻辑文档：每屏展示什么、数据从哪来、怎么算，连设计稿的节点编号都对得上。这种产物他以前得花一周从零做，这次不到一天就有了扎实版本（他自己的口径）。

二十个候选进来，一个上屏，规则是 AI 自己写进文档、他采纳的。同一份文档里它还挂了个待办：光靠现有字段没法可靠地把课归到同一次训练里，它把这条标成未决问题，没用漂亮话糊过去。

他给一个带分支的新用户引导做原型，前两次都失败了。先在 FigJam 和 Figma 里画，组合和条件一多就失控，改一处涟漪到其他所有地方；改成把问题、答案、分支逻辑写进一个 Google 文档像剧本一样发出去评审，几乎没人给反馈，读的人感受不到流程，判断不出长短，也没法测。第三次他让 AI 把这份文档变成一个能跑的网页原型，部署成链接扔进 Slack 收反馈，结果「改一处逻辑」变成改一行数据。

到画界面这一步他的判断保守得多：精细的、能进生产的界面，除非有一套扎实的设计系统托底，他认为 AI 还不行。他在试的是 Paper（一块画布式的设计工具，底子是网页 HTML 而不是设计软件的私有格式，画出来的东西离能跑的代码更近）：四个 Claude Code Agent 同时开工，分头画设置页、个人资料页、训练详情页和付费墙。日志里能看到它自己截图检查、发现内容在底部被裁掉、改成自适应高度再确认一遍，这个自查自修的循环才是它能出活的地方。