全部笔记
搜索社群分享、圆桌记录、作品集经验与实践模板。
Portfolio Case Study Writer
把项目经历整理成背景、问题、过程、方案、结果与复盘，适合先搭案例提纲，再补齐个人贡献和关键判断。
提供真实项目材料，请它先列结构与证据缺口，再逐段组织内容。明确要求不补造用户研究、引语或业务指标。
用于组织已有事实。缺少的证据标为待补充，不能把推测写成已验证的结果。
Impeccable · 页面审查与精修
把页面打磨拆成层级审查、排版调整、精简和收尾等任务。适合已经有内容和页面，需要提高完成度的作品集。
先选首页项目区和一个案例页做 critique，再按问题使用 distill 或 polish。检查标题、图片与演示的阅读顺序。
先保留现有设计系统与真实内容，在一个页面验证效果后再扩展。安装步骤以项目文档为准。
Emil Kowalski Skills · 动效与交互细节
围绕缓动、反馈和交互完成度提供指导。improve-animations 可审查已有动效并给出修改计划，适合先定位问题。
用 emil-design-eng 检查界面细节，用 improve-animations 审查动效。把操作反馈与案例演示的叙事节奏分开讨论。
improve-animations 默认产出审查与计划，不直接修改产品源代码。apple-design 是作者整理的资料，不是 Apple 官方 Skill。
Anthropic Frontend Design · 页面视觉方向
从真实内容和受众出发，探索字体、构图与视觉重点。适合新建首页或案例页时比较设计方向。
先提供一个真实案例与目标读者，让它比较两种构图。确定方向后，再延展到其他页面。
已有明确视觉语言时，要把保留项写清楚，避免一次任务里让多个 Skill 同时决定全站风格。
UI UX Pro Max · 设计参考与实现规则
提供可检索的风格、配色、字体和 UX 指导，包含 Svelte 等技术栈的实现参考，适合补齐具体设计问题。
围绕一个问题检索，例如字号层级、小屏长标题或表单反馈，再与项目已有组件和规范对照。
参考库不能代替项目判断；先选局部问题，不直接用一套新风格覆盖已有作品集。
Taste Skill · 局部视觉改版
通过更明确的视觉约束探索页面布局、信息密度与表现方式，适合为首页或项目卡片制作对比方案。
限定一个区块，先记录原版的目标与问题，再比较调整后的层级、间距和内容可读性。
不同技能与版本的侧重点会变化，使用前看当前说明。风格更强烈不等于项目更容易被理解。
Interactive Portfolio · 作品集结构与交互
从个人介绍、项目展示、导航和联系入口梳理作品集体验，适合检查信息是否容易找到、互动是否支持内容。
让它检查访客能否快速看懂你做什么、最值得看的项目是什么，以及如何联系你；再检查小屏体验。
作为补充清单使用，不把仓库热度当成单项 Skill 的效果证明，也不承诺求职结果。
Vercel Web Design Guidelines · 发布前检查
读取最新网页规范，检查指定 UI 代码，并给出带文件位置的问题。适合发布前检查键盘操作、焦点、布局和动效。
指定首页和一个案例页，要求列出问题位置与修复建议；修复后再用浏览器检查手机布局、链接和降低动态效果设置。
规范审查负责实现质量，不能代替个人风格判断或真实浏览器验收。
用痛点、过程与结果组织项目故事
按背景、过程和结果组织案例：用户遇到什么问题，你如何探索与选择，最终带来了什么变化。根据听众调整细节，在面试中说明自己的贡献、挑战和收获。
挑一个案例，按「之前的痛点、你做了什么、之后的收益」写成三段，结尾留一句结论。也可以积累自己的职业故事和用户故事，按听众与主题选择。
适合建立案例骨架，再按项目特点补充证据与设计细节。
为面试中的能力判断提供证据
围绕设计能力、沟通协作、产品思维和团队合作准备具体事例。讲清情境、行动与结果，让面试官能够判断你的贡献，以及你如何理解用户和处理分歧。
拿一份 JD，把自己按那四个维度各写一件面试官能记成事实的事：做了什么、结果是什么，别写「我沟通能力强」这种结论。感谢信只在真有具体收获时发，泛泛的一句不如不发。
不同岗位和公司的评价维度不同，准备时对照目标岗位要求。
结合成长目标安排换工作的时机
回顾已有经历、当前岗位的成长空间和潜在机会，再安排求职时间。把项目进展、学习目标与机会匹配度放在一起比较，定期检查自己的选择是否仍然合适。
开一张表记每家公司：投递方式、日期、每轮结果和笔记。面完当天写下被问的问题、你的答案、自信度打分和下次怎么答，挂在哪个环节就集中补那个环节。
求职节奏需要结合个人情况和目标市场调整。
让作品集支持快速浏览与深入阅读
首页清楚说明定位，并突出最相关的项目。案例开头交代业务背景、问题、角色和结果，再展开探索与取舍，让读者既能快速理解，也能继续深入阅读。
找一个当过面试官的朋友，限时两分钟看你的作品集，边看边说，记下他点了哪里、停在哪里，再让他复述你的项目，看他记住的是不是你想让他记住的。
阅读时长因人和场景而异，可通过实际阅读反馈检查信息是否清楚。
讲案例时呈现问题与关键取舍
用核心问题、问题拆解、方向探索、关键取舍和结果组织讲述。选择能充分展示设计能力的项目，并根据面试时长调整细节，让听众理解方案是如何形成的。
把主案例改成五轮，每轮结束写一句「这一轮解决了什么」。回答问题时先 10 秒确认问题，20 秒给结论句，再看对方兴趣决定展开多少。
深入案例演示和简短电话沟通需要不同的内容密度，可分别准备长短版本。
在评审邀请中写清预期结果
发起评审前，明确希望参会者理解、决定或协助的事项。邀请中列出参与人、议程和预期结果，内容从听众关心的问题展开。可搭配默读、原型体验或具体问题讨论。
下次汇报邀请里加一句「离开这个会议时，我们要定下…」，写进你想要的决定。开讲前把设计过程理成「因为 A 所以做了 B，因为 B 所以做了 C」的链条。
适用于需要反馈或决策的设计评审，形式与时长按参与人数调整。
用明确的问题获得具体反馈
展示方案时说明背景、设计阶段和本轮需要的反馈类型。给反馈时描述可观察的现象，再询问设计理由，例如页面对齐方式或按钮状态为何变化。
下次 review 开头写三行：现在到哪一步、想要哪类反馈、不想要哪类。给别人反馈前把每条改写成「相机拍得到」的事实，再加一个问句。
反馈范围应与当前阶段一致，避免同时讨论所有细节。
项目开始时对齐参与人和目标
明确谁参与项目、共同目标是什么、用哪些指标判断进展。当不同角色关注的指标冲突时，回到共同目标讨论取舍，并约定沟通时间、渠道和内容。
kick-off 时写下参与的人、目标和指标、约束、设计原则。新进团队先约 1:1，问对方的职业路径、和设计师合作的经历、工作习惯。会后记下决定、遗留问题、下一步，标明谁拍板。
随着范围和参与人变化，及时更新目标与沟通安排。
从方案建议中找出要解决的问题
收到 PM 的方案建议时，先确认它对应的用户问题、需求依据和目标。理解双方的评估标准后，再比较不同方案如何满足这些条件，形成可以共同讨论的取舍。
下次拿到需求，先写下三个问题：用户是谁、解决什么问题、为什么现在做。答不上来的拿去问 PM，并说明每个答案会怎么改变你的设计决策。
结合团队实际分工确定设计与产品各自的责任。
白板面试：澄清问题、比较方向、展开方案
为开场、问题澄清和方案探索分配时间。先确认用户、场景与限制，再比较有差异的方向，选择一条展开流程；条件变化时，说明如何调整优先级和范围。
用 designercize 或 sharpen 随机抽一题，计时 30 分钟练。出声说你打算做什么、为什么，结尾回到最初定的目标，检查方案有没有达到。
适用于现场协作练习，具体时间分配按题目复杂度和面试要求调整。
带着探索结果讨论下一步
遇到问题时，带上已有尝试、备选方案和需要帮助的具体事项。在时限内比较方向，交付后继续关注实现与结果，让协作建立在清晰的判断和责任上。
把你现在 level 和下一 level 的要求各列一栏，第三栏写你做到的证据，第四栏写没做到的行动计划，下次一对一拿给 manager 看。
经验要求因岗位而异，可用具体行为与结果说明自己的能力。
根据内容表现确定响应式断点
从小屏逐步调整宽度，观察内容何时需要换行、重排或改变导航形式，再确定断点。常见处理方式包括列堆叠、弹性布局、结构重排和次要内容折叠。
拿你手头一个页面，从最窄的手机宽度开始拉，每次难看就记一个断点，再给每个断点写清楚栏数和哪些内容要收起来。
在实际页面中检查文字、图片和交互状态，而不只比较设计稿尺寸。
对照平台规范理解交互选择
对照不同平台的导航、输入、反馈和无障碍规范，区分平台惯例与共通原则。为具体任务选择合适的模式，并解释需要保留平台差异的原因。
下次做双端页面，先列出用到的组件，逐个标记：这是平台差异（分开画），还是通用规则（两份规范一起查）。触控目标记住 Android 48dp、iOS 44pt。
实现时查阅目标平台当前的官方规范，并在目标设备上验证。
持续维护设计系统的规则与组件
把设计系统作为持续维护的产品，明确组件负责人、使用规则和反馈入口。结合产品需求安排更新，与设计和工程定期检查组件是否满足实际场景。
先做 audit：把现有界面里的按钮、字号、颜色全列出来，合并重复的（有团队把 20 种字号压到五六种），再挑 20% 核心页面用新组件重排一遍，看撑不撑得住。
维护方式按团队规模安排，组件与使用文档需要一起更新。
用真实经历回答行为面试问题
选择具体经历说明自己的不足、采取的改进和学到的内容。讲失败项目时交代个人责任与后续行动；没有相同经历时，可以明确说明，并解释自己的处理思路。
挑三个真实项目，各写一段：当时情况、你的任务、你做了什么、结果和学到什么。用「我」不用「我们」。同一家公司不同轮次换着讲，别当复读机。
谈离职原因时聚焦职业目标、工作条件和期待的变化。
沿一条流程分析产品的设计取舍
选择一条具体任务流程，依次观察界面、评价使用体验、提出对设计理由的假设，再讨论改进。可以从新老用户、用户与商业目标、体验与实现成本等角度分析。
挑一个你常用但没隐私内容的 app，选一条主流程走一遍，每屏按「是什么、好不好、为什么这样、怎么改」说出来，再找一个更了解这个产品的人对答案。
演示前使用不含私人信息的账号或材料，并确认面试的选题要求。
评估工具的功能与迁移成本
将需求分成必需、重要和可选，逐项检查工具支持情况。同时用真实文件试迁移，观察组件、样式、协作和维护成本，比较收益是否值得投入。
拿你团队最常做的一种任务在新工具里从头做一遍，同时把一个真实组件库导过去，记下哪些要手动修。
用当前版本做小范围试用，再确定迁移范围和时间。
让交付版本与探索稿清楚区分
明确标记探索中、待确认和可开发的版本，并约定工程从哪里获取最新交付。同步记录设计理由、状态和规格，减少使用错误版本造成的返工。
打开你正在交接的文件，把定稿和探索稿分到不同 page，给没定的页面标上 WIP，交接时只发定稿那一页的链接。
按团队工具安排交接，重点是版本、负责人和变更信息清楚可查。
远程协作中明确时间与响应预期
在日历中标明工作与专注时段，约定哪些问题适合异步沟通。请求反馈时说明需要什么、何时需要，并为讨论和会议设置清晰的结束条件。
今天在日历上加三种 block：专注做设计、处理 Slack 和邮件、吃饭休息，再把会议提醒从 10 分钟改成 3 分钟。
安排需与团队时区、协作习惯和工作政策一致。
让构思活动产生可验证的认识
开展方案讨论前，明确要回答的问题、决策人和结束条件。用故事板、轻量原型或用户反馈比较方向，记录哪些假设得到支持、哪些需要进一步探索。
开构思会之前写下这一轮要回答的问题和退出条件：做到什么程度还拿不到反馈，就换方向。
按问题的不确定性选择验证方式，避免为了走流程增加活动。
设计难以推进时检查目标与约束
一个看似很小的需求也可能涉及产品定位或目标冲突。方案反复受阻时，回到要解决的问题、优先级和约束，与相关同事明确哪些需要取舍，哪些需要重新决策。
接到需求先问三句：这解决哪个用户问题、和产品方向怎么对上、不做会怎样。答不上来就把风险写下来发给 PM。
先确认阻碍发生在哪一层，再决定调整方案、范围或产品方向。
为目标设定可观察的进展与结果
将目标转成可以检查的行动和结果，例如完成一个原型并通过任务测试。区分学习活动、交付数量和用户效果；分析指标变化时，结合覆盖范围、时间和对照信息。
把你这季度的目标改写成三条能数出来的 KR，每条标上时间点，然后发给 manager 和同组的 PM。
活动完成可以说明投入与进展，业务效果还需要相应的结果证据。
谈薪前先定三条线
谈之前写下三个数：梦想值、想要值、低于就走人的值，免得被一句「这是最高了」带跑。要问清的条目：base 和股权分开报，sign-on 不算 TC；股权是期权还是 RSU、cliff 多久、四年怎么分、离职后已 vest 的会不会被收回。听到第一个数字先说比预期低，别当场答复，数字要写进邮件。
拿到 offer 前先问 recruiter 目标 level 和这一级 band 的上下限，再把股权条款逐条问清，要书面确认。
具体薪酬与股权条款以书面文件为准；税务和期权估值问题可咨询专业人士。
用时间表协调多轮面试
记录每家公司的面试阶段、下一步、准备事项和答复期限。根据自己的准备节奏协调日期，为修改作品集、休息和比较机会留出时间。
建一张表，每家公司一行：当前阶段、下一步动作、截止时间、还不知道的事。每天早上过一遍，标出今天要 follow up 的。
面试数量与安排按精力和机会调整，提前沟通时间冲突。
Google PAIR Guidebook：人本 AI 产品设计手册
Google 的 AI 产品设计手册，分六章：用户需求与成功定义、数据与评估、心智模型、可解释与信任、反馈与控制、出错与优雅失败。每章配一份团队讨论用的 worksheet 和离线 PDF，另有模式库、案例和术语表。全书用一个跑步 App「RUN」举例，讲到「该自动化还是该增强」怎么选。免费，英文。
做 AI 功能之前，先把「用户需求」那章的 worksheet 打印出来和团队填一遍：这个问题 AI 有没有独特价值，该自动化还是增强。
例子是推荐、追踪这类传统 AI 场景，聊天和 Agent 界面要自己类推。每章篇幅不短，先挑和你手头问题对应的那章。
AI UX Playground：150 多条真实产品的 AI 交互模式
收了 150 多个已上线产品的 AI 交互模式，分 11 类：信任、聊天、Agent、输入、输出、商业、音频、性能等。每条有截图，多数带可点的交互 demo，还写了什么时候用、常见坑和反模式。例子来自 ChatGPT、Claude、Perplexity、Cursor 这些产品。免费，不用登录，英文。
你要设计流式输出或工具调用的界面时，先去 Outputs 和 Agents 两类里翻同名模式，把它列的坑对照你的方案过一遍。
收的是别家产品的做法，不是规范。同一个模式在不同产品里做法不一样，挑的时候看它标的适用条件。
Claude Code Subagents：子 Agent 怎么配、怎么隔上下文
Claude Code 的官方文档。子 Agent 就是一个带 YAML 头的 Markdown 文件：写名字、什么时候该派它、能用哪些工具、用哪个模型，再加一段系统提示词。它在自己的上下文里干活，只把摘要带回主对话。文档给了代码审查、只读数据库查询几个完整例子，还讲了 fork 和非 fork 的区别。英文。
挑你重复做的一件事，比如「检查设计稿文案」，照文档格式写一个子 Agent 文件放进 .claude/agents/，跑一次看它带回来的摘要够不够用。
只适用 Claude Code。文档更新很快，字段名以页面当前版本为准，别照旧截图配。
Pablo Stanley：设计师怎么和 coding agent 一起干活
Pablo Stanley 2026 年 9 月写的 27 章小册子，专门给不是工程师的设计师。他让 Claude 读了自己的使用记录，写下他真的在做的事：在终端里开 Claude Code，用 claude agents 一屏看所有后台任务，每个任务在自己的 worktree 里跑，解释过两遍的事就做成 skill，改完先让 agent 自己看结果再给工程师看。还有一段六个 agent 挤在一个文件夹里互相覆盖的翻车记录。
只挑一章，明天用在一件真事上。比如「一个问题一个文件」：把你反复向 agent 解释的一条规则写进项目文件，看下次它还犯不犯。
他用的是跳过权限确认的模式，前提是自己的仓库、每个改动走单独分支和 PR。有生产环境密码的机器别照做。
Whiteboard Design Skill：在 Claude Code 里练白板题
一个 Claude Code skill，用 /wb 命令把对话变成八步白板：为什么、给谁、场景、假设、发散、流程、方案、总结，还会生成低保真和高保真线框图。有练习模式，也有「实战模式」：读会议转录实时填白板。附评分表和题型分类。英文。
装好后用 /wb 出一道题，按 s1 到 s8 走一遍，重点看它在「假设」和「取舍」两步问了你什么，把问题抄下来当自己的清单。
要装 Claude Code，实战模式还要接 Notion 转录。真面试别开着它，练习用就好。
Carbon Patterns：IBM 怎么把组件组合成场景模式
IBM Carbon 设计系统的模式库。模式是「用户完成一个目标的最佳实践」，比单个组件高一层，共 14 个通用模式：对话框、空状态、筛选、表单、加载、登录、通知、搜索、只读输入、禁用态等。每个都写了什么时候用、怎么组合组件、有哪些变体。免费，英文。
你在写自己团队的「空状态」或「筛选」规范时，先把 Carbon 那一页的结构抄下来当模板，再填你们的内容。
是企业软件的模式，做消费级产品的话，登录、通知这几条要自己调。
Vercel：把产品设计判断写进仓库教给 Agent
Vercel 把产品设计决策当代码管：一个 product-design skill 放在仓库里，里面有判断标准、文案规则、从已上线 PR 里抽出来的范例和踩过的坑。再配 linter 自动拦，比如两三个固定选项就该用单选而不是下拉。评审意见从 Slack、Figma、GitHub 收回来，人工批准后才更新规则。2026 年 6 月的文章。
挑你团队评审时反复提的一条意见，比如「别嵌套弹窗」，写成一条可观察的规则，存进项目里让 agent 读。
讲的是 Vercel 自家做法，前提是设计和工程在同一个仓库里工作。先从一条规则试，别一上来搭整套。
Unslop UI：一份「AI 生成界面别这么做」的规则
一个给 coding agent 用的 skill，专门列 AI 生成界面的通病：全是同一色相的「颜色糊」、图标套圆角方块当装饰、拿 emoji 当视觉元素、hero 区用衬线体、过度玻璃拟态、层层嵌套的卡片、慢动画。它要的是干净无衬线、留白当工具、图标只在帮助理解时出现。支持 Claude、Cursor、Gemini 等，附正反对比图。
把它列的反例拿出来，对照你最近让 AI 生成的一个页面，数一数中了几条。中的那几条改成你自己的约束写进提示词。
风格偏简洁的产品界面，可按项目的品牌规范选用其中的规则。
The Art Director：18 种风格的海报提示词生成器
一个 AI skill，输入主题和文案，它按 18 种预设风格（日式复古印刷、字体拼贴等）给你一套海报方案：一条可直接贴进 Midjourney 或 ChatGPT 的主提示词、方形横版竖版三种尺寸、配色和辅助素材提示。每种风格配一张参考图。Claude 和 ChatGPT 都能用，把文件夹丢给它就行。
拿你下一张活动海报试：选一种风格，让它出提示词，生成后和你自己写的提示词结果对比，看差在哪。
输出的是图片生成器用的提示词，不是设计稿。18 种风格里有 8 种取自 Kittl 的 2026 趋势报告，用多了容易撞。
HTML to Design：把网页导进 Figma 变成可编辑图层
一个 Figma 插件，贴 URL 就能把网页转成可编辑的 Figma 图层，用来改版、对标竞品或抓设计素材。要登录才能看的页面或内网页面得装它的 Chrome 扩展。免费版每 30 天 10 次导入，付费版不限次、高清图、批量导入。
先拿一个公开的竞品页面试导一次，看图层命名和 auto layout 能不能直接用。要导公司内部页面，先问清楚数据去了哪。
免费版 30 天只有 10 次，正式做对标前先算够不够。导公司内部页面前先查你们的数据政策。
Linear：为什么高质量的产品这么少
Linear 联合创始人 Karri Saarinen 2025 年 5 月写的。他的观点是每次新技术出来，行业都会先追速度和成本、丢掉手艺，过一阵人们又开始怀念质量；AI 更进一步，可能把判断和品味从制作里剥离出来。文末讲 Linear 怎么做：靠直觉多过靠数据、招手艺好的人、小团队不交接、MVP 只内部用、零 bug 政策。
把文末 Linear 的几条做法列出来，逐条问：我们团队现在哪条做得到、哪条做不到、卡在谁那里。
作者讲的是自家选择，Linear 是盈利的小团队工具公司。大公司或大流量产品照搬「不看数据」要谨慎。
AnnotaLayer：在任何网页上和团队一起批注
一个 Chrome 扩展，装好后在任何网页上点一下就能留评论，localhost、Vercel 预览页、正式站都行。发一个链接给同事，对方不用装扩展就能看到你的批注并回复，评论有线程、能标已解决。它说自己不读取页面内容，只是盖在你的应用上面一层。免费版 10 个分享页、每页 30 条评论。
下次让别人看原型时，别再截图发群。用它在页面上标三处要反馈的地方，把链接发出去，看回复是不是比截图来得准。
还是 Beta，要 Google 账号登录。免费版每页 30 条评论，走查大页面容易不够；Pro 版还没上线。
Boris Tane：先审计划，再让 Claude 写代码
作者把和 Claude Code 干活分四步：研究写成 research.md，计划写成 plan.md，然后他在计划上批注改一到六轮，最后让 Claude 一口气实施完并在计划里打勾。核心原则是「没审过书面计划，不让它写代码」。他说批注计划那一步最值钱，因为改的是架构假设，不是语法。2026 年 2 月的文章。
找一个范围明确的小任务，让 AI 先出 plan.md，你在文件里批注两轮再放行，和直接让它做的结果对比。
作者是工程师，讲的是改代码库。省 token、长会话这些是他个人体验，他「清空改动重来」的操作别照搬。
Notion AI 的设计思路：按场景给 AI 不同入口
Notion 产品设计负责人 2023 年 9 月写的。他们没做一个万能聊天框，而是按你在哪：新建空白页给起草工具，已有正文给摘要、续写、提取待办，选中文本给改语气、改语法，并排显示改前改后。AI 是横跨所有 block 的一层，不是一个独立功能。
把你产品里 AI 可能出现的位置列出来：空白态、已有内容、选中内容。给每个位置各写一个动作，别都指向同一个聊天框。
适合参考如何按任务场景安排 AI 入口，以及如何让用户理解和控制结果。
Notion：让人留在环里，AI 才可信
Notion AI 研究团队 2023 年 10 月写的。他们把 AI 用法分成三种：生成、修改、查找，每种都要让用户看得懂、改得了 AI 在做什么。例子是拿客户访谈转录做 PPT：先找痛点，再找好评，再生成结论，中间停下来让人确认。难点是暴露太多决策点会烦，太少又失去控制。
把你产品里一条 AI 流程拆成步骤，标出哪些中间结果用户必须看一眼、哪些错误会往下传。只在会往下传的地方加确认。
2023 年的文章，讲的是文档工具。给大学生看课程摘要和给销售看机密数据，该暴露多少不一样，作者自己也说要按场景调。
Designercize：随机出白板题、限时练
一个白板题生成器。选难度（易、中、难），点「Reload」换题直到满意，题目固定三段：Design（设计什么）、For（给谁）、To help（解决什么），默认 15 分钟计时。做完给 0 到 3 星，配一句玩笑话。免费，不用登录。
每周抽一道题，按「澄清问题、做选择、画流程、解释取舍」走 15 分钟，录屏，找人看回放给反馈。
星级是玩笑，不是评估。它只出题，不会像真面试官那样追问，追问要找人。
Awesome Design Systems：350 多个设计系统的清单
GitHub 上一张按字母排的大表，收了 350 多个公开设计系统，从 Google、Microsoft、Adobe 到 GOV.UK 这类政府系统。每条标四项：有没有代码组件、有没有语气规范、有没有 Figma 或 Sketch 设计文件、源码开不开放。社区维护，500 多次提交。
挑两个和你产品平台、行业接近的系统，比同一个组件（比如 Toast）的适用条件、状态、文案，别只比颜色。
可按产品类型寻找设计系统，对照组件、交互模式和文档结构。
Atomic Design 第五章：设计系统怎么活下去
Brad Frost《Atomic Design》第五章「Maintaining Design Systems」，2016 年。核心是把设计系统当产品养，不是当交付物做完。具体讲：分「maker」和「user」两种角色、跨职能团队、改动流程和弃用规则、语义化版本号、在样式指南里放 changelog 和路线图、模式命名不带业务语境。例子是 Lonely Planet 用一个 API 同时喂模式库和生产环境。
把作者列的维护要素抄下来：角色、流程、版本、changelog、沟通渠道。对照你团队的设计系统，勾掉已有的，剩下的就是要补的。
英文，可免费在线阅读。重点关注设计系统的维护、协作与治理方法。
AI Design Field Guide：AI 设计长文月刊
三个设计师办的 AI 设计长文站，每月更新。首页挂的作者来自 OpenAI、Figma、Anthropic 等，头条是前 OpenAI 设计师写的「Designing Memory」。议题是 eval、prompt、工具调用、心智模型这类，不是 UI 灵感库。免费，有英文、西班牙文和中文版。
挑一篇和你手头问题最近的读，读完写一句「这篇让我改了什么想法」。别整站收藏。
文章偏长，适合安排完整阅读时间，并结合自己的项目做练习。
Interface Craft：Josh Puckett 的界面手艺课，买断制
前 Dropbox、Wealthfront 设计师 Josh Puckett 做的付费资料库：40 多篇长文、交互式演示、视频、skill 文件和自制工具，讲怎么把界面做到「timeless」。免费只能看 3 篇预览，全部内容要 249 美元买断，有按国家的平价定价和教育折扣。
通过免费内容了解课程的示例与练习方式，判断是否符合自己的学习目标。
付费课程，适合已有界面设计基础、希望深入练习视觉细节的设计师。可先阅读免费内容了解课程风格。
Impeccable：给 coding agent 装一套设计词汇
一套给 Claude Code、Cursor、Copilot 等 coding agent 用的设计 skill。装好后有 /impeccable typeset（理字体层级）、distill（简化拥挤界面）、polish、audit（上线前检查）等命令，还有 61 条自动检测 AI 默认审美的规则。设计上下文存在 DESIGN.md 和 PRODUCT.md 里，跨轮次保持一致。免费，自动 PR 检查是付费项。
拿一个你已经用 AI 生成的页面，先跑 /impeccable audit 看它挑出什么，再跑 typeset 看字体层级改了哪些。前后截图对比。
要装到你的 agent 里（npx 或插件市场）。它有自己的审美倾向，和你的品牌规范冲突时以 DESIGN.md 里你写的为准。
CodePen：在浏览器里写小交互
在浏览器里写 HTML、CSS、JS，右边实时预览，不用装东西。2026 年的 2.0 版支持多文件、Sass、TypeScript、Tailwind、Vue，自动编译。别人的 pen 可以直接 fork 改，首页和搜索里有大量按钮、动效、加载态的小样例。
把你作品集里一个想加的交互（比如悬停放大或滚动渐显）先在 CodePen 上搜同类 pen，fork 一个改成你的样式，再搬进站里。
样例质量参差，搬之前看一眼授权和依赖，别把一整个第三方库拖进作品集。
React Bits：200 多个 React 动效组件
开源的 React 动效组件库，200 多个，分文字动画、UI 元素、微交互、背景、3D 五类。每个组件有 JS/TS 和 CSS/Tailwind 四种版本，可以用 shadcn 命令一行装，也能直接复制代码。授权是 MIT 加 Commons Clause，个人和商用都行，但不能拿组件本身去卖。
挑一个背景或文字动效放进你作品集的首页试试，看加载速度和你现有样式冲不冲突。
只给 React 项目用，Vue 和 Svelte 有官方移植。动效组件容易堆过头，一页放一两个就够。
Netlify：把静态页面免费发上线
网站托管平台。把项目文件夹拖进 Netlify Drop 就能上线，也能连 Git 仓库，每次 push 自动部署，PR 还有预览链接。CLI 部署可以不登录先试。除了托管还有 serverless 函数、数据库、表单这些。
把你作品集的静态导出拖进去发一次，看流程顺不顺，再决定要不要连 Git 自动部署。
部署前查看带宽和构建额度；自定义域名需要单独购买。
Eagle：本地素材库，买断制
设计师用的本地素材管理软件，Mac 和 Windows 都有，一次买断，30 天全功能试用。浏览器扩展可以拖拽或批量存图，支持图片、视频、GIF、字体、PDF。能按颜色搜、按标签筛、自动去重，还有 AI 语义搜索和以图搜图。
把手头那一批散在文件夹和收藏夹里的参考图导进去，用标签和智能文件夹分一遍，看检索是不是真的比 Finder 快。
素材保存在本机，换电脑时需要同步；使用前查看当前定价。
Bestfolios：设计师作品集和简历案例库
一个作品集和简历展示站，收了约 100 个作品集、50 份简历，还有书和文章推荐。每条标身份和公司，比如 Meta 的 Staff 设计师、AWS 的 UX lead、在读的 IBM 实习生，也有编辑精选标签。从学生到 Staff 都有，正好和只收实习生的 Cofolios 对照。
挑三份和你目标岗位接近的，只看首屏：他们用一句什么话介绍自己、第一个案例放什么。对照改你自己的首屏。
适合对照不同职业阶段的作品集结构、案例深度和简历表达。
Cofolios：大厂设计实习生的作品集合集
专收拿到 Apple、Google、Meta、Figma 等公司设计实习的人的作品集，可以按公司和学校筛。定位是「给早期职业设计师的作品集灵感」，另有实习职位板、案例拆解和作品集点评功能，可以订阅拿实习的 newsletter。
筛你目标公司的两三份，看它们首页第一屏放什么、案例讲到多细，和 Bestfolios 上资深设计师的比一比差别在哪。
以实习生作品集为主，申请正式岗或高级岗时需调整参考标准。
Ethan 的 Framer 作品集：三个精选案例的结构参考
一位 IBM 高级产品设计师用 Framer 做的作品集。结构是 3 个精选案例（设计 token、AI 与 UX、仪表盘）加 5 个其他项目，再加 About 和推荐语，案例点进去是单独页面。数据写得具体，比如某项目「上线当天用户增长 300%+」。
数一数你的作品集：精选几个、其他几个、有没有推荐语。对照它的「3 + 5 + About + 推荐」结构，看你的比例是不是失衡。
适合参考精选项目、其他项目、个人介绍与推荐语的组织方式，案例可进入详情页阅读。
Logan Liffick：极简到只剩文字的个人站
Vercel 设计工程师的个人网站。整站几乎只有文字：About、Latest、Connect 三段，深色背景，横线分隔，点联系方式会提示「已复制」。没有案例展示，靠一句话说自己做什么和链接到 X、GitHub。
看它怎么用最少的元素说清楚「我是谁、在做什么、怎么找我」。给你自己的首页第一屏也写一版三句话版本。
适合参考文字层级与极简导航。展示项目经历时，可搭配完整的案例详情。
Behance：看完整案例的视觉叙事
Adobe 旗下的作品发布平台，交互设计分类里有大量 UX 和产品设计的长案例页。适合看别人怎么用图和版式把一个项目从头讲到尾，视觉叙事和演示做到什么水平。
挑两三个和目标岗位接近的长案例，只看结构：从问题到方案用了几屏、哪几张图承担了主要叙事、结果放在哪。对照你自己的一个案例。
很多是概念稿或视觉提案，不是真实上线的项目。判断案例深度时看有没有约束、取舍和结果，别只看图好不好看。
Dribbble：看封面、首屏和视觉风格
以单张作品图为主的设计社区，portfolio 标签下多是作品集首屏、封面和缩略图设计。适合快速翻一遍视觉风格。
翻 20 张作品集首屏，存 3 张第一眼就知道「这人做什么」的，写下它们靠的是标题、配图还是排版。
只有单张图，看不到案例叙事，概念稿也多。拿它参考视觉，别拿它参考案例结构。
Awwwards：网站设计评奖站，看动效和视觉
网站设计奖项平台，每天评一个 Site of the Day，十分制打分，有评审团。可以按类型（作品集、电商、建筑）和技术（Webflow、Framer、WebGL、GSAP）筛。免费看，有付费 PRO 会员和付费学院课程。
筛「Portfolio」类看 10 个，记下 3 个想学的手法，然后问一句：这个手法会不会让招聘方找不到我的案例？
适合参考视觉表现与动效。用于求职作品集时，需要兼顾案例阅读、导航和加载速度。
Godly：网页与视觉设计灵感库
浏览网页、界面、品牌、动效、3D 与字体设计案例，为作品集寻找排版、配色和视觉风格参考。
挑一两个案例，记下你想借鉴的具体手法（比如某种网格或标题字号），拿自己的一个页面试试。
截图适合参考视觉风格；交互与动效请查看案例原站。
让长任务的等待过程更清楚
长任务需要同时考虑四件事：缩短实际耗时、尽早提供有用的结果、支持离开或取消、方便完成后检查。可按任务需要提供中间结果、完成通知和真实进度，让用户知道下一步能做什么。
拿同一个任务测三样：第一个有用结果多久出来、用户知不知道下一步、走开再回来能不能接上。中途先给一部分能核对的产物，说清取消会怎样。
步骤拆得更细不一定更好，短任务反而会被拖慢；进度和成果数量别编。
按操作后果设计确认方式
确认方式应与操作的影响相匹配。只读任务需要说明范围和来源；可撤销的修改需要让用户看清目标与变化；涉及权限或重大影响的操作需要明确授权。设计时同时考虑撤销、恢复和异常处理。
把你的 Agent 会做的动作列出来，分成只读、可撤销写入、加权限或高影响三类。每类写清确认方式和出了问题怎么退回。
治理上不能跳的步骤，和具体做法可以放手，是两回事，别混在一起放行。
把 Agent 行为写进交付标准
除界面外，还需要定义 Agent 何时追问、何时请求确认、遇到缺失信息或中断时如何处理。为这些情境编写行为说明和测试样例，标明需要用户介入的节点，以及部分完成时如何展示结果。
每种情境写三栏：希望它怎么做、不许它怎么做、怎么算通过。至少覆盖正常、缺输入、没权限、重复跑、用户中断五种。
行为说明与测试样例配合使用，便于设计和工程核对实现。
AI 白板：把时间留给待解决的问题
与面试官确认用户、场景和范围后，可把 AI 用于探索方案、搭建原型和检查设计。用一份简短清单记录已确认事项，减少重复讨论，并约定输出语言与篇幅。
开场先列一张「已确认 / 待探索」清单：用户、场景、范围、语言、输出多长。AI 只对待探索的缺口提问，每轮探索都留下一个能比较的选择。
练习前确认面试允许使用的工具、时间范围和交付要求。
白板面试中如何与 AI 和面试官协作
使用 AI 时，需要持续向面试官说明思考过程。围绕一个明确任务探索方案，解释关键取舍，并控制原型范围，让问题界定、优先级判断和沟通能力都能被看见。
照六步走：确认能不能用 AI 和用哪些工具 → 说清这次只解决哪个任务 → 做两三个有差异的方向 → 原型只做到能验证关键假设 → 关键选择后向面试官解释理由 → 收尾分清已验证、假设和下一步。
这是练习用的流程，真实面试的规则以那家公司为准。
用具体取舍展示设计判断
案例可以围绕四类证据展开：理解了哪些约束、比较过哪些方案、为什么推翻某个初稿、哪些结果得到验证。涉及 AI 时，说明它参与了什么，以及你如何检查和选择产出。
挑一个案例，写下一个你否掉 AI 建议的具体理由和证据，再标清你本人负责的部分。
自己后来做的试验，别写成公司已上线的成果；效率提升和收益要有数据才写。
App Critique：从任务理解设计取舍
从用户、设计和产品三个角度分析一条具体流程：谁在使用、页面如何支持任务、设计受到什么约束。结合信息结构、交互与视觉表现解释设计选择，再提出值得验证的改进方向。
自己走完一条任务，按「谁在什么情境做什么 → 页面怎么支持它 → 有什么约束或商业目标 → 哪个摩擦最值得验证」记下来。
手上没数据时，别断言某个问题影响了转化。
反向面试：用具体事例了解管理方式
了解管理方式时，可以询问真实的工作情境：如何接收下属反馈、如何处理分歧、多久讨论职业发展、最近怎样帮助设计师成长。具体事例有助于判断团队的协作方式是否适合你。
准备三个追问：意见不一致时你怎么处理？多久聊一次职业发展？最近一次帮人成长具体做了什么？每个都要他给一个真实例子。
一次面试的回答只够看一个侧面，别急着给对方下定论。
指标未达预期时如何复盘
指标未达预期时，可与 PM 一起检查目标定义、方法、执行和资源。结合数据口径、覆盖范围和观察时间寻找原因，再确定下一轮要验证的假设。作品集也可以展示这类复盘与调整。
拉上 PM 对四件事：目标定义、数据口径、改动覆盖了多少用户、观察了多久。然后写下下一轮要验证的假设。
复盘写得再清楚，也不等于业务收益已经到手，作品集里别混着说。
面试中讲清 AI 使用与设计判断
准备一个能说明设计判断的案例：你解决了什么问题、为什么选择某个方向、AI 在哪里提供了帮助、哪些步骤由你完成。用具体取舍解释能力，方便面试官理解你的贡献并继续追问。
拿一个真实案例试讲一遍，说清贡献、取舍，以及 AI 在哪一步帮了忙、哪一步没用。讲完让听的人复述你的判断。
不同公司的招聘标准不同，面试准备应以目标岗位的要求为准。
为 AI 组织设计系统上下文
设计系统规则可以按视觉、品牌、组件、布局和交互拆成可检索的文档，也可以与组件代码和示例一起维护。前者便于按任务查找，后者便于跟随实现更新；组合模式和设计理由也需要记录。
不管哪种写法，补齐五层：token 的语义和禁止硬编码、组件的状态和键盘操作、pattern 的适用场景和反例、当初为什么这么定、怎么验证算完成。
可参考 Carbon 的模式文档组织方式，并使用项目自己的组件与视觉规范。
根据约束选择原型环境
依赖真实组件、数据状态和已有功能的任务，适合在代码库中探索；问题和方向尚未确定时，可以先用轻量原型比较方案。选择环境时，权衡反馈速度、实现约束与后续集成成本。
从原型切回真实系统前列一张表：哪些是模拟数据、哪些是临时实现、哪些假设要换掉。别把原型直接当上线实现。
代码只记录做成了什么，为什么这么设计往往还得另外写下来。
按工程需要确定交付内容
交付前与工程确认需要的是视觉参考、可交互的规格，还是可集成的代码。再约定状态、边界条件、数据契约和测试的负责人，让设计产物能接入团队现有的开发流程。
交付前问三件事：下游要哪种产物？状态、边界条件、数据契约和测试谁补？哪些组件能直接复用，哪些只是表达意图？
一种产物不会适用所有工程团队，每换一个团队重新问一遍。
把收藏转化为练习与分享
将感兴趣的资源放进待学清单，在固定学习时间选择一项解决当前问题。完成练习后，记录适用场景、关键设置、操作步骤、示例和体会，形成可复用、可分享的经验。
每张资源卡只写五样：解决什么问题、什么时候值得看、下一步练什么、出自哪里、验证到哪一步。每次只挑一项去解决一个真实问题。
收藏不等于会了。只读过、试过、验证过是三种状态，标清楚。
检查自然语言输入的使用门槛
自然语言输入可能受到表达习惯、语言熟练度和任务知识的影响。设计时可以比较自由输入、结构化选项、示例和分步提示，观察哪种方式更有助于目标用户完成任务。
找几个表达习惯不同的人做同一个任务，比成功率、改了几次、理解对不对。再拿结构化输入、示例、分步提示和自由输入对照着测。
将这些影响作为待验证的假设，用目标用户的任务表现检验。
按原因处理设计走查中的偏差
走查中的偏差可能来自规范不清、组件未复用、实现错误或验收范围不一致。先记录预期与实际，再与相关同事确认原因，分别通过补充规范、复用组件、修复代码或对齐验收要求处理。
每个偏差记下预期、实际、怎么复现、影响谁。然后判断该补规范、查组件和 token 的复用入口、附证据修代码，还是先谈验收责任。
不是每处差异都是 pixel-perfect 缺陷，有些是合理的实现取舍。
从任务完成度检查 AI 生成界面
检查 AI 生成界面时，先看信息结构是否支持任务，再看交互、性能和无障碍，最后调整视觉细节。为每一层设定可观察的检查项，避免仅凭画面风格判断质量。
按顺序查：任务和信息结构 → 交互行为和失败状态 → 无障碍 → 最后才调视觉。每一层留下检查记录。
看起来更好看了，不代表任务能完成、结果是对的，这两样要单独验。
用明确的任务与计划开始 AI 协作
提供目标用户、任务流程、设计系统和约束，让 AI 先说明实施步骤。通过计划检查理解是否一致；探索界面时，保留比较不同方向的空间，再选择值得细化的方案。
每次试验先把产品、目标、流程、目标用户、设计系统写成系统指令。让 AI 先出计划，你批准了再生成，走偏的拐点记下来。
有的公司直接写进代码库，有的只在沙盒里做，工程都还要 review，别照搬别家的做法。
按任务选择工具组合
先确定要完成的任务，再比较基础模型、界面生成工具、代码编辑器和建站工具。可以组合使用分析、生成和实现能力，并用一个小项目检查衔接是否顺畅。
先写下你要验证的任务、打算搭配哪两三个工具、公司有什么限制，再安排一次小试验。
有的公司禁用 vibe coding 工具，动手前先查你们的政策。
为原型迭代保留可恢复的版本
用 Git 保存可验证的改动，方便比较方案和恢复之前的版本。为 AI 提供组件与使用规则；需要测试多个情境时，可在同一原型中切换用例，减少重复生成。
在完成一个可验证的小改动后提交版本。为 AI 提供设计系统规则；研究原型可加入用例切换面板，方便比较不同状态。
涉及后端或 Agent 的项目，还需要单独验证数据、权限和异常处理。
学 AI 工具，先选方向再挑工具
可以围绕一个具体目标安排学习：重做作品集、搭建常用工具组合，或独立完成一个可用的小产品。为目标选择练习项目和必要工具，完成后再扩展下一项能力。
写下你的方向是哪一个，只留下这个方向用得上的两三个工具，其余先放进待学清单。
根据自己的目标选择方向，不必同时学习所有工具。
为容易被打断的工作安排节奏
把工作拆成可以暂停和继续的小步，集中时间完成关键部分，再安排细节与收尾。离开前记录下一步，预期有变化时及时沟通，并明确哪些工作可以协作完成。
把手头的工作拆成随时能停、随时能接上的小步，每次停下记好下次从哪开始。赶不上期限的话，早点说清新预期和需要谁帮。
根据精力、照护责任和团队安排调整节奏，为计划保留余量。
海报级好看的图，点击率不一定高
一个电商 AIGC 团队的经验：通用模型出的商品图海报级好看，点击率不一定更高。他们的做法是按场景给模型归类，一次只改一个变量，通过多轮测试，从数据里找规律，不同市场的风格偏好也不一样。另一个观察是 AI 让「先做出来给人看」变便宜了，不抽象的提案更容易过。早期最大的误区是 AI 万能论。
展示 AI 出的设计时，把视觉观察和目标指标并排放。在真实场景里一次只改一个变量测，别拿「好看」代替业务验证。
这一经验来自电商商品图场景，其他行业需要用自己的用户和业务指标验证。
挑经理看两层：团队运作和你的成长
这份指南把「好经理」拆成两层。团队层看他能不能搭一支互补的团队、有没有流程和工具、敢不敢替设计发声和做取舍；个人层看他有没有一套评估工作的原则、懂不懂设计、会不会主动分享和给反馈。红旗也列得很直接：微观管理、不好接近、对你的成长没兴趣、功劳只往自己身上揽。
45 分钟这么排：团队和领导风格 10 分钟，设计指导 15 分钟，职业成长 10 分钟，留 10 分钟提问。核心追问：你支持过谁做成了什么、下属和你意见不合时怎么办、有人跟着你成长是什么样。
按面试时长调整各部分比例，为最关心的问题留出讨论时间。
先证明你适合这个岗位，再讲项目细节
首页说明你的领域、产品经验和角色，案例页用具体工作支撑定位。对照目标岗位选择重点，同时展示设计质量、关键决策和实际贡献。
选一个目标岗位，给主案例写三件最要证明的事，每件配一条真实证据。再自问一遍：案例第一屏能不能看懂问题、你的贡献和结果？
用目标岗位的要求和实际阅读反馈检查表达效果，持续调整案例。
网页是给人自己读的，演示是用来讲的
作品集网页、口头讲述、现场被追问是三种场景。网页上没人替你解释，背景、约束、你负责的部分得自己交代清楚；口头讲可以按问题、取舍和对方会追问的点来组织。首页突出定位和项目入口，详细论证放在案例页。
找个同行读完复述一遍「你做了什么、为什么重要」。他讲偏的地方就是要改的地方。
分别准备适合独立阅读的网页和适合口头讲解的演示材料。
练视觉判断，不只收集灵感
临摹成熟产品和设计系统来练基本功，比追花哨管用。练法是一次只盯一个问题，比如层级、间距或文字密度：存参照，做一版，写下差在哪、为什么这么改，再看真实渲染出来的效果。注意细节差异，也要按问题对用户的影响安排修改优先级。
挑一个页面、一个问题。存好参考图和改前改后的版本，写下为什么这么改。
临摹是拿来学的。别人的作品别包装成自己的项目放进作品集。
把理想方案和实际交付分开
展示改进设想时，可以与当时的交付版本对照，并标清概念探索、实际交付和已上线内容。可用的讲法顺序：当时的限制 → 当时的选择 → 实际结果 → 今天的改进设想 → 还没验证的假设。
给每块内容打标签：已上线 / 实际交付 / 概念探索 / 后续重设计。指标要对到正确的那个版本上。
blue-sky 方案配上真实业务指标，读者会以为指标是它带来的。保密协议和面试要求优先于展示欲。
AI 提速了，判断过程还是要让人看见
在作品集中展示你如何使用和判断 AI 产出：AI 用在哪一步、你给了什么约束、哪些产出被你否了、最后怎么验证。只放一排工具图标，或者写「生成了 50 版」，说明不了能力。
留一个被你否掉的方案，讲清它的问题、你改的依据、最后怎么验证的。
业务数据和研究引语应来自真实记录，概念探索需明确标注。
设计评审：先对齐这次要解决什么
往期分享里最差的求反馈方式是展示完问「你觉得怎么样」，对方不知道你要什么。这份模板把背景、阶段、要哪类反馈、不要哪类先写下来，比如还在探信息架构就明说别收文案意见。给反馈的人按「观察 → 对用户的影响 → 建议」写：「看着怪」不算，「左对齐和居中混用」才算。
项目 / 日期： 用户要完成什么任务： 现在在哪个阶段：探索 / 选方案 / 交付检查 已经定死的约束： 这次想要什么反馈： 这次不聊什么： 备选方案和各自的证据： 观察 → 对用户的影响 → 建议： 决定：采纳 / 待验证 / 不采纳（写理由） 下一步和确认过的负责人： 什么算完成：分歧记下来了，下一步能直接做。
按真实项目填写，并和相关负责人确认分工与下一步。
决策记录：日志和知识分开写
往期分享讲交接：只有定稿进交接工具，还在改的标 WIP，工程才不会拿草稿开工。记录也一样分两种：日志记发生了什么，知识笔记写以后遇到同类事怎么办。AI 会议摘要会把模糊讨论写成肯定的责任人和行动项，圆桌回放的自动转写就出过这种错，所以摘要先当草稿，有人确认才算数。
问题和背景： 状态：提议 / 已决定 / 待验证 / 已撤回 选了哪个方案，还有哪些备选： 为什么选它： 证据和来源（标清是原文 / 转写 / AI 总结 / 假设）： 确认过的负责人和日期： 怎么验证： 出现什么情况要重新考虑： 以后能复用的方法，以及什么情况不适用：
按真实项目填写，并和相关负责人确认分工与下一步。
AI 原型：探索和交付分开验收
圆桌上最一致的经验是让 AI 先写计划、人审过再动手，读计划比读代码容易发现错。Vibe coding 共创表里最常见的坑是版本控制，改一轮把上一版搞乱。所以这份模板在开始前写清目标、不能动的资产、允许用的数据，中间给每个方向存档，结束时区分「能演示」「设计检查过」「工程审查过」「真实环境验证过」，一个状态不能冒充另一个。
这轮的用户场景和目标： 已有的上下文和设计规则： 不能动的资产： 允许用的数据： 要产出什么，什么算完成： 要先审一遍的计划 / 假设： 比了哪些方向，留下或放弃的理由： 哪些是模拟数据，哪些是真功能： 验证到哪一步：能演示 / 设计检查过 / 工程审查过 / 真实环境验证过 失败或走偏了：先存下当前能用的版本，缩小范围，回头看约束。
按真实项目填写，并和相关负责人确认分工与下一步。
设计系统：给组件留一份维护约定
往期分享的结论：只有组件没有使用规则，那是组件库，不是设计系统。有团队给每个组件配设计 owner 和开发 owner，每周一次内部会、一次和 PM、开发的评审。这份模板把使用场景、不适用情境、状态、两边负责人、已知实现差异写在一起。先拿高频问题验证它有没有帮到团队，再扩组件数量。
组件和版本： 它解决哪个高频任务： 什么时候用 / 什么时候别用： 默认、加载、空、出错、无权限这些状态： 交互规则和无障碍要求： 设计和工程各由谁维护： 已知的实现差异： 这次改了什么，为什么，影响谁： 怎么验证：下次同类任务能不能直接复用，不一致有没有变少？
按真实项目填写，并和相关负责人确认分工与下一步。
作品集与面试的一页准备卡
作品集网页别人自己看、你口头讲、现场被追问，是三种场景，材料要分开准备。招聘经理先看岗位匹配，再看案例深度，所以这张卡从岗位和要证明的能力开始，往下才是案例、取舍和最可能被追问的那个决定。每次模拟面试只盯一个问题，改完再模拟下一个。
要投的岗位，想证明的能力： 主案例，我负责的部分： 遇到的约束，关键的取舍： 哪些结果验证过，证据是什么： 最可能被追问的决定： 网页单独看，哪里看不懂： 口头讲的时候重点讲什么： 这家公司面试能不能用 AI： 这次模拟只查一个问题： 收到的反馈，下一步改什么：
结果和研究都要真的。能不能用 AI 工具，以那家公司的面试规则为准。
互评按观察、影响、建议三段给
作品互评前，说明目标、当前版本和一个希望解决的问题。反馈按观察、影响、建议三部分展开，便于转化为具体修改。结束后保存前后对比，记录仍需解决的问题。
下一轮开始前，每人写三行：目标、当前版本、一个想解决的问题。反馈按「观察 / 影响 / 建议」写。结束时存前后对比，列出没解决的。笔记标清哪些是人写的、哪些是 AI 总结、哪些是确认过的结论。
互评是同行的看法，不是招聘方的标准，作品集改完还要拿真实面试去验。