一个产品设计师把手上的项目从 1 个做到 6 个：他的五套工作流，连 Claude Skill 原文都放出来了
- 一个 VR 健身公司的产品设计师，半年内把同时在推的项目从 1 个变成 6 个，迭代周期几天一轮。
- 他给的定性是 AI 真正改变的是一个设计师能覆盖多大面积，但真正有用的是那五套工作流各配了一张真实截图。
- 最值钱的东西全藏在截图里：Claude Skill 的完整触发条件和输出模板、AI 写的数据逻辑文档、分支原型只用两个字段就实现了。
他做了什么：半年时间，手上的项目从 1 个变成 6 个
Krystian Zun 是 VR 健身公司 FitXR 的产品设计师，做了八年多 0→1 产品。他半年前一次只盯一个项目，现在同时推六个，头脑风暴、系统逻辑、原型、工单、进度更新全都自己来，迭代周期是几天一轮。这篇是他把这半年攒下的五套工作流一次交出来，而且每一套都配了真实截图；其中 Claude Skill 的完整定义、AI 生成的数据逻辑文档、分支原型的实现方式，都能一字不差地照抄走。
他自己给的定性是这样的：AI 通常被当成提速工具，同样的活干得更快。用了一年之后他认为这个框架抓错了重点：它真正改变的是规模，一个设计师能端到端拥有多少东西。速度只是顺带的。他强调自己没变聪明，也没开始加班，改的是注意力花在哪儿，剩下的交给 AI。
这套变化的起点是 FitXR，他形容是自己待过节奏最快的地方。头几个月他连着发实验，很快撞墙：得想办法跟上。从那以后，他每遇到一个卡点就问自己同一个问题：
这件事我能不能想办法把 AI 塞进去？
Krystian Zun
能不能卸掉一部分？能不能更快？能不能出更好的结果？他说这是一路试错试出来的，包括试出了哪些地方 AI 帮不上忙、甚至拖慢他、不如自己动手，只可惜这部分他一个例子都没给，这是全篇最可惜的缺口，文末再说。
他的心智模型：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.中文对照：动笔前先想清楚，上次更新之后发生了什么？做了哪些决定？什么完成了、什么在进行中？有没有时间线变化、里程碑挪动或者卡点？有没有值得一提的工程或赋能工作？盯着实质内容。忽略噪音，比如入群消息、机器人通知、琐碎的行政事项。如果某件事上次更新已经讲过了，别重复。
最后那两句最该抄。周报之所以难看，通常问题出在噪音太多、还老在重复上周说过的话，而不在信息不够。把「忽略什么」写进去，比把「写什么」写进去更管用。