# 全部笔记

> 搜索社群分享、圆桌记录、作品集经验与实践模板。

Canonical page: https://aixdesign.kens-toolbox.com/zh/learn/notes

## Portfolio Case Study Writer

把项目经历整理成背景、问题、过程、方案、结果与复盘，适合先搭案例提纲，再补齐个人贡献和关键判断。  提供真实项目材料，请它先列结构与证据缺口，再逐段组织内容。明确要求不补造用户研究、引语或业务指标。  用于组织已有事实。缺少的证据标为待补充，不能把推测写成已验证的结果。

[Portfolio Case Study Writer](https://github.com/Paramchoudhary/ResumeSkills/blob/main/skills/portfolio-case-study-writer/SKILL.md)


## Impeccable · 页面审查与精修

把页面打磨拆成层级审查、排版调整、精简和收尾等任务。适合已经有内容和页面，需要提高完成度的作品集。  先选首页项目区和一个案例页做 critique，再按问题使用 distill 或 polish。检查标题、图片与演示的阅读顺序。  先保留现有设计系统与真实内容，在一个页面验证效果后再扩展。安装步骤以项目文档为准。

[Impeccable · 页面审查与精修](https://github.com/pbakaus/impeccable)


## Emil Kowalski Skills · 动效与交互细节

围绕缓动、反馈和交互完成度提供指导。improve-animations 可审查已有动效并给出修改计划，适合先定位问题。  用 emil-design-eng 检查界面细节，用 improve-animations 审查动效。把操作反馈与案例演示的叙事节奏分开讨论。  improve-animations 默认产出审查与计划，不直接修改产品源代码。apple-design 是作者整理的资料，不是 Apple 官方 Skill。

[Emil Kowalski Skills · 动效与交互细节](https://github.com/emilkowalski/skills)


## Anthropic Frontend Design · 页面视觉方向

从真实内容和受众出发，探索字体、构图与视觉重点。适合新建首页或案例页时比较设计方向。  先提供一个真实案例与目标读者，让它比较两种构图。确定方向后，再延展到其他页面。  已有明确视觉语言时，要把保留项写清楚，避免一次任务里让多个 Skill 同时决定全站风格。

[Anthropic Frontend Design · 页面视觉方向](https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md)


## UI UX Pro Max · 设计参考与实现规则

提供可检索的风格、配色、字体和 UX 指导，包含 Svelte 等技术栈的实现参考，适合补齐具体设计问题。  围绕一个问题检索，例如字号层级、小屏长标题或表单反馈，再与项目已有组件和规范对照。  参考库不能代替项目判断；先选局部问题，不直接用一套新风格覆盖已有作品集。

[UI UX Pro Max · 设计参考与实现规则](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill)


## Taste Skill · 局部视觉改版

通过更明确的视觉约束探索页面布局、信息密度与表现方式，适合为首页或项目卡片制作对比方案。  限定一个区块，先记录原版的目标与问题，再比较调整后的层级、间距和内容可读性。  不同技能与版本的侧重点会变化，使用前看当前说明。风格更强烈不等于项目更容易被理解。

[Taste Skill · 局部视觉改版](https://github.com/Leonxlnx/taste-skill)


## Interactive Portfolio · 作品集结构与交互

从个人介绍、项目展示、导航和联系入口梳理作品集体验，适合检查信息是否容易找到、互动是否支持内容。  让它检查访客能否快速看懂你做什么、最值得看的项目是什么，以及如何联系你；再检查小屏体验。  作为补充清单使用，不把仓库热度当成单项 Skill 的效果证明，也不承诺求职结果。

[Interactive Portfolio · 作品集结构与交互](https://github.com/davila7/claude-code-templates/blob/main/cli-tool/components/skills/creative-design/interactive-portfolio/SKILL.md)


## Vercel Web Design Guidelines · 发布前检查

读取最新网页规范，检查指定 UI 代码，并给出带文件位置的问题。适合发布前检查键盘操作、焦点、布局和动效。  指定首页和一个案例页，要求列出问题位置与修复建议；修复后再用浏览器检查手机布局、链接和降低动态效果设置。  规范审查负责实现质量，不能代替个人风格判断或真实浏览器验收。

[Vercel Web Design Guidelines · 发布前检查](https://github.com/vercel-labs/agent-skills/blob/main/skills/web-design-guidelines/SKILL.md)


## 用痛点、过程与结果组织项目故事

按背景、过程和结果组织案例：用户遇到什么问题，你如何探索与选择，最终带来了什么变化。根据听众调整细节，在面试中说明自己的贡献、挑战和收获。  挑一个案例，按「之前的痛点、你做了什么、之后的收益」写成三段，结尾留一句结论。也可以积累自己的职业故事和用户故事，按听众与主题选择。  适合建立案例骨架，再按项目特点补充证据与设计细节。


## 为面试中的能力判断提供证据

围绕设计能力、沟通协作、产品思维和团队合作准备具体事例。讲清情境、行动与结果，让面试官能够判断你的贡献，以及你如何理解用户和处理分歧。  拿一份 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 界面要自己类推。每章篇幅不短，先挑和你手头问题对应的那章。

[Google PAIR Guidebook：人本 AI 产品设计手册](https://pair.withgoogle.com/guidebook/)


## AI UX Playground：150 多条真实产品的 AI 交互模式

收了 150 多个已上线产品的 AI 交互模式，分 11 类：信任、聊天、Agent、输入、输出、商业、音频、性能等。每条有截图，多数带可点的交互 demo，还写了什么时候用、常见坑和反模式。例子来自 ChatGPT、Claude、Perplexity、Cursor 这些产品。免费，不用登录，英文。  你要设计流式输出或工具调用的界面时，先去 Outputs 和 Agents 两类里翻同名模式，把它列的坑对照你的方案过一遍。  收的是别家产品的做法，不是规范。同一个模式在不同产品里做法不一样，挑的时候看它标的适用条件。

[AI UX Playground：150 多条真实产品的 AI 交互模式](https://www.aiuxplayground.com/patterns/)


## Claude Code Subagents：子 Agent 怎么配、怎么隔上下文

Claude Code 的官方文档。子 Agent 就是一个带 YAML 头的 Markdown 文件：写名字、什么时候该派它、能用哪些工具、用哪个模型，再加一段系统提示词。它在自己的上下文里干活，只把摘要带回主对话。文档给了代码审查、只读数据库查询几个完整例子，还讲了 fork 和非 fork 的区别。英文。  挑你重复做的一件事，比如「检查设计稿文案」，照文档格式写一个子 Agent 文件放进 .claude/agents/，跑一次看它带回来的摘要够不够用。  只适用 Claude Code。文档更新很快，字段名以页面当前版本为准，别照旧截图配。

[Claude Code Subagents：子 Agent 怎么配、怎么隔上下文](https://code.claude.com/docs/en/sub-agents)


## Pablo Stanley：设计师怎么和 coding agent 一起干活

Pablo Stanley 2026 年 9 月写的 27 章小册子，专门给不是工程师的设计师。他让 Claude 读了自己的使用记录，写下他真的在做的事：在终端里开 Claude Code，用 claude agents 一屏看所有后台任务，每个任务在自己的 worktree 里跑，解释过两遍的事就做成 skill，改完先让 agent 自己看结果再给工程师看。还有一段六个 agent 挤在一个文件夹里互相覆盖的翻车记录。  只挑一章，明天用在一件真事上。比如「一个问题一个文件」：把你反复向 agent 解释的一条规则写进项目文件，看下次它还犯不犯。  他用的是跳过权限确认的模式，前提是自己的仓库、每个改动走单独分支和 PR。有生产环境密码的机器别照做。

[Pablo Stanley：设计师怎么和 coding agent 一起干活](https://agents.pablostanley.com)


## Whiteboard Design Skill：在 Claude Code 里练白板题

一个 Claude Code skill，用 /wb 命令把对话变成八步白板：为什么、给谁、场景、假设、发散、流程、方案、总结，还会生成低保真和高保真线框图。有练习模式，也有「实战模式」：读会议转录实时填白板。附评分表和题型分类。英文。  装好后用 /wb 出一道题，按 s1 到 s8 走一遍，重点看它在「假设」和「取舍」两步问了你什么，把问题抄下来当自己的清单。  要装 Claude Code，实战模式还要接 Notion 转录。真面试别开着它，练习用就好。

[Whiteboard Design Skill：在 Claude Code 里练白板题](https://github.com/HueyRen/whiteboard-design-skill)


## Carbon Patterns：IBM 怎么把组件组合成场景模式

IBM Carbon 设计系统的模式库。模式是「用户完成一个目标的最佳实践」，比单个组件高一层，共 14 个通用模式：对话框、空状态、筛选、表单、加载、登录、通知、搜索、只读输入、禁用态等。每个都写了什么时候用、怎么组合组件、有哪些变体。免费，英文。  你在写自己团队的「空状态」或「筛选」规范时，先把 Carbon 那一页的结构抄下来当模板，再填你们的内容。  是企业软件的模式，做消费级产品的话，登录、通知这几条要自己调。

[Carbon Patterns：IBM 怎么把组件组合成场景模式](https://carbondesignsystem.com/patterns/overview/)


## Vercel：把产品设计判断写进仓库教给 Agent

Vercel 把产品设计决策当代码管：一个 product-design skill 放在仓库里，里面有判断标准、文案规则、从已上线 PR 里抽出来的范例和踩过的坑。再配 linter 自动拦，比如两三个固定选项就该用单选而不是下拉。评审意见从 Slack、Figma、GitHub 收回来，人工批准后才更新规则。2026 年 6 月的文章。  挑你团队评审时反复提的一条意见，比如「别嵌套弹窗」，写成一条可观察的规则，存进项目里让 agent 读。  讲的是 Vercel 自家做法，前提是设计和工程在同一个仓库里工作。先从一条规则试，别一上来搭整套。

[Vercel：把产品设计判断写进仓库教给 Agent](https://vercel.com/blog/teaching-agents-product-design-at-vercel)


## Unslop UI：一份「AI 生成界面别这么做」的规则

一个给 coding agent 用的 skill，专门列 AI 生成界面的通病：全是同一色相的「颜色糊」、图标套圆角方块当装饰、拿 emoji 当视觉元素、hero 区用衬线体、过度玻璃拟态、层层嵌套的卡片、慢动画。它要的是干净无衬线、留白当工具、图标只在帮助理解时出现。支持 Claude、Cursor、Gemini 等，附正反对比图。  把它列的反例拿出来，对照你最近让 AI 生成的一个页面，数一数中了几条。中的那几条改成你自己的约束写进提示词。  风格偏简洁的产品界面，可按项目的品牌规范选用其中的规则。

[Unslop UI：一份「AI 生成界面别这么做」的规则](https://github.com/yuwen-lu/unslop-ui)


## The Art Director：18 种风格的海报提示词生成器

一个 AI skill，输入主题和文案，它按 18 种预设风格（日式复古印刷、字体拼贴等）给你一套海报方案：一条可直接贴进 Midjourney 或 ChatGPT 的主提示词、方形横版竖版三种尺寸、配色和辅助素材提示。每种风格配一张参考图。Claude 和 ChatGPT 都能用，把文件夹丢给它就行。  拿你下一张活动海报试：选一种风格，让它出提示词，生成后和你自己写的提示词结果对比，看差在哪。  输出的是图片生成器用的提示词，不是设计稿。18 种风格里有 8 种取自 Kittl 的 2026 趋势报告，用多了容易撞。

[The Art Director：18 种风格的海报提示词生成器](https://github.com/sijingsun/the-art-director)


## HTML to Design：把网页导进 Figma 变成可编辑图层

一个 Figma 插件，贴 URL 就能把网页转成可编辑的 Figma 图层，用来改版、对标竞品或抓设计素材。要登录才能看的页面或内网页面得装它的 Chrome 扩展。免费版每 30 天 10 次导入，付费版不限次、高清图、批量导入。  先拿一个公开的竞品页面试导一次，看图层命名和 auto layout 能不能直接用。要导公司内部页面，先问清楚数据去了哪。  免费版 30 天只有 10 次，正式做对标前先算够不够。导公司内部页面前先查你们的数据政策。

[HTML to Design：把网页导进 Figma 变成可编辑图层](https://html.to.design/home/)


## Linear：为什么高质量的产品这么少

Linear 联合创始人 Karri Saarinen 2025 年 5 月写的。他的观点是每次新技术出来，行业都会先追速度和成本、丢掉手艺，过一阵人们又开始怀念质量；AI 更进一步，可能把判断和品味从制作里剥离出来。文末讲 Linear 怎么做：靠直觉多过靠数据、招手艺好的人、小团队不交接、MVP 只内部用、零 bug 政策。  把文末 Linear 的几条做法列出来，逐条问：我们团队现在哪条做得到、哪条做不到、卡在谁那里。  作者讲的是自家选择，Linear 是盈利的小团队工具公司。大公司或大流量产品照搬「不看数据」要谨慎。

[Linear：为什么高质量的产品这么少](https://linear.app/now/why-is-quality-so-rare)


## AnnotaLayer：在任何网页上和团队一起批注

一个 Chrome 扩展，装好后在任何网页上点一下就能留评论，localhost、Vercel 预览页、正式站都行。发一个链接给同事，对方不用装扩展就能看到你的批注并回复，评论有线程、能标已解决。它说自己不读取页面内容，只是盖在你的应用上面一层。免费版 10 个分享页、每页 30 条评论。  下次让别人看原型时，别再截图发群。用它在页面上标三处要反馈的地方，把链接发出去，看回复是不是比截图来得准。  还是 Beta，要 Google 账号登录。免费版每页 30 条评论，走查大页面容易不够；Pro 版还没上线。

[AnnotaLayer：在任何网页上和团队一起批注](https://annotalayer.com/)


## Boris Tane：先审计划，再让 Claude 写代码

作者把和 Claude Code 干活分四步：研究写成 research.md，计划写成 plan.md，然后他在计划上批注改一到六轮，最后让 Claude 一口气实施完并在计划里打勾。核心原则是「没审过书面计划，不让它写代码」。他说批注计划那一步最值钱，因为改的是架构假设，不是语法。2026 年 2 月的文章。  找一个范围明确的小任务，让 AI 先出 plan.md，你在文件里批注两轮再放行，和直接让它做的结果对比。  作者是工程师，讲的是改代码库。省 token、长会话这些是他个人体验，他「清空改动重来」的操作别照搬。

[Boris Tane：先审计划，再让 Claude 写代码](https://boristane.com/blog/how-i-use-claude-code/)


## Notion AI 的设计思路：按场景给 AI 不同入口

Notion 产品设计负责人 2023 年 9 月写的。他们没做一个万能聊天框，而是按你在哪：新建空白页给起草工具，已有正文给摘要、续写、提取待办，选中文本给改语气、改语法，并排显示改前改后。AI 是横跨所有 block 的一层，不是一个独立功能。  把你产品里 AI 可能出现的位置列出来：空白态、已有内容、选中内容。给每个位置各写一个动作，别都指向同一个聊天框。  适合参考如何按任务场景安排 AI 入口，以及如何让用户理解和控制结果。

[Notion AI 的设计思路：按场景给 AI 不同入口](https://www.notion.com/blog/the-design-thinking-behind-notion-ai)


## Notion：让人留在环里，AI 才可信

Notion AI 研究团队 2023 年 10 月写的。他们把 AI 用法分成三种：生成、修改、查找，每种都要让用户看得懂、改得了 AI 在做什么。例子是拿客户访谈转录做 PPT：先找痛点，再找好评，再生成结论，中间停下来让人确认。难点是暴露太多决策点会烦，太少又失去控制。  把你产品里一条 AI 流程拆成步骤，标出哪些中间结果用户必须看一眼、哪些错误会往下传。只在会往下传的地方加确认。  2023 年的文章，讲的是文档工具。给大学生看课程摘要和给销售看机密数据，该暴露多少不一样，作者自己也说要按场景调。

[Notion：让人留在环里，AI 才可信](https://www.notion.com/blog/humans-in-the-loop-creating-intuitive-and-trustworthy-ai-experiences)


## Designercize：随机出白板题、限时练

一个白板题生成器。选难度（易、中、难），点「Reload」换题直到满意，题目固定三段：Design（设计什么）、For（给谁）、To help（解决什么），默认 15 分钟计时。做完给 0 到 3 星，配一句玩笑话。免费，不用登录。  每周抽一道题，按「澄清问题、做选择、画流程、解释取舍」走 15 分钟，录屏，找人看回放给反馈。  星级是玩笑，不是评估。它只出题，不会像真面试官那样追问，追问要找人。

[Designercize：随机出白板题、限时练](https://designercize.com/)


## Awesome Design Systems：350 多个设计系统的清单

GitHub 上一张按字母排的大表，收了 350 多个公开设计系统，从 Google、Microsoft、Adobe 到 GOV.UK 这类政府系统。每条标四项：有没有代码组件、有没有语气规范、有没有 Figma 或 Sketch 设计文件、源码开不开放。社区维护，500 多次提交。  挑两个和你产品平台、行业接近的系统，比同一个组件（比如 Toast）的适用条件、状态、文案，别只比颜色。  可按产品类型寻找设计系统，对照组件、交互模式和文档结构。

[Awesome Design Systems：350 多个设计系统的清单](https://github.com/alexpate/awesome-design-systems)


## Atomic Design 第五章：设计系统怎么活下去

Brad Frost《Atomic Design》第五章「Maintaining Design Systems」，2016 年。核心是把设计系统当产品养，不是当交付物做完。具体讲：分「maker」和「user」两种角色、跨职能团队、改动流程和弃用规则、语义化版本号、在样式指南里放 changelog 和路线图、模式命名不带业务语境。例子是 Lonely Planet 用一个 API 同时喂模式库和生产环境。  把作者列的维护要素抄下来：角色、流程、版本、changelog、沟通渠道。对照你团队的设计系统，勾掉已有的，剩下的就是要补的。  英文，可免费在线阅读。重点关注设计系统的维护、协作与治理方法。

[Atomic Design 第五章：设计系统怎么活下去](https://atomicdesign.bradfrost.com/chapter-5/)


## AI Design Field Guide：AI 设计长文月刊

三个设计师办的 AI 设计长文站，每月更新。首页挂的作者来自 OpenAI、Figma、Anthropic 等，头条是前 OpenAI 设计师写的「Designing Memory」。议题是 eval、prompt、工具调用、心智模型这类，不是 UI 灵感库。免费，有英文、西班牙文和中文版。  挑一篇和你手头问题最近的读，读完写一句「这篇让我改了什么想法」。别整站收藏。  文章偏长，适合安排完整阅读时间，并结合自己的项目做练习。

[AI Design Field Guide：AI 设计长文月刊](https://www.aidesignfieldguide.com/)


## Interface Craft：Josh Puckett 的界面手艺课，买断制

前 Dropbox、Wealthfront 设计师 Josh Puckett 做的付费资料库：40 多篇长文、交互式演示、视频、skill 文件和自制工具，讲怎么把界面做到「timeless」。免费只能看 3 篇预览，全部内容要 249 美元买断，有按国家的平价定价和教育折扣。  通过免费内容了解课程的示例与练习方式，判断是否符合自己的学习目标。  付费课程，适合已有界面设计基础、希望深入练习视觉细节的设计师。可先阅读免费内容了解课程风格。

[Interface Craft：Josh Puckett 的界面手艺课，买断制](https://www.interfacecraft.dev/)


## 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 里你写的为准。

[Impeccable：给 coding agent 装一套设计词汇](https://impeccable.style/)


## CodePen：在浏览器里写小交互

在浏览器里写 HTML、CSS、JS，右边实时预览，不用装东西。2026 年的 2.0 版支持多文件、Sass、TypeScript、Tailwind、Vue，自动编译。别人的 pen 可以直接 fork 改，首页和搜索里有大量按钮、动效、加载态的小样例。  把你作品集里一个想加的交互（比如悬停放大或滚动渐显）先在 CodePen 上搜同类 pen，fork 一个改成你的样式，再搬进站里。  样例质量参差，搬之前看一眼授权和依赖，别把一整个第三方库拖进作品集。

[CodePen：在浏览器里写小交互](https://codepen.io/)


## React Bits：200 多个 React 动效组件

开源的 React 动效组件库，200 多个，分文字动画、UI 元素、微交互、背景、3D 五类。每个组件有 JS/TS 和 CSS/Tailwind 四种版本，可以用 shadcn 命令一行装，也能直接复制代码。授权是 MIT 加 Commons Clause，个人和商用都行，但不能拿组件本身去卖。  挑一个背景或文字动效放进你作品集的首页试试，看加载速度和你现有样式冲不冲突。  只给 React 项目用，Vue 和 Svelte 有官方移植。动效组件容易堆过头，一页放一两个就够。

[React Bits：200 多个 React 动效组件](https://www.reactbits.dev/)


## Netlify：把静态页面免费发上线

网站托管平台。把项目文件夹拖进 Netlify Drop 就能上线，也能连 Git 仓库，每次 push 自动部署，PR 还有预览链接。CLI 部署可以不登录先试。除了托管还有 serverless 函数、数据库、表单这些。  把你作品集的静态导出拖进去发一次，看流程顺不顺，再决定要不要连 Git 自动部署。  部署前查看带宽和构建额度；自定义域名需要单独购买。

[Netlify：把静态页面免费发上线](https://www.netlify.com/)


## Eagle：本地素材库，买断制

设计师用的本地素材管理软件，Mac 和 Windows 都有，一次买断，30 天全功能试用。浏览器扩展可以拖拽或批量存图，支持图片、视频、GIF、字体、PDF。能按颜色搜、按标签筛、自动去重，还有 AI 语义搜索和以图搜图。  把手头那一批散在文件夹和收藏夹里的参考图导进去，用标签和智能文件夹分一遍，看检索是不是真的比 Finder 快。  素材保存在本机，换电脑时需要同步；使用前查看当前定价。

[Eagle：本地素材库，买断制](https://eagle.cool/)


## Bestfolios：设计师作品集和简历案例库

一个作品集和简历展示站，收了约 100 个作品集、50 份简历，还有书和文章推荐。每条标身份和公司，比如 Meta 的 Staff 设计师、AWS 的 UX lead、在读的 IBM 实习生，也有编辑精选标签。从学生到 Staff 都有，正好和只收实习生的 Cofolios 对照。  挑三份和你目标岗位接近的，只看首屏：他们用一句什么话介绍自己、第一个案例放什么。对照改你自己的首屏。  适合对照不同职业阶段的作品集结构、案例深度和简历表达。

[Bestfolios：设计师作品集和简历案例库](https://www.bestfolios.com/home)


## Cofolios：大厂设计实习生的作品集合集

专收拿到 Apple、Google、Meta、Figma 等公司设计实习的人的作品集，可以按公司和学校筛。定位是「给早期职业设计师的作品集灵感」，另有实习职位板、案例拆解和作品集点评功能，可以订阅拿实习的 newsletter。  筛你目标公司的两三份，看它们首页第一屏放什么、案例讲到多细，和 Bestfolios 上资深设计师的比一比差别在哪。  以实习生作品集为主，申请正式岗或高级岗时需调整参考标准。

[Cofolios：大厂设计实习生的作品集合集](https://www.cofolios.com/)


## Ethan 的 Framer 作品集：三个精选案例的结构参考

一位 IBM 高级产品设计师用 Framer 做的作品集。结构是 3 个精选案例（设计 token、AI 与 UX、仪表盘）加 5 个其他项目，再加 About 和推荐语，案例点进去是单独页面。数据写得具体，比如某项目「上线当天用户增长 300%+」。  数一数你的作品集：精选几个、其他几个、有没有推荐语。对照它的「3 + 5 + About + 推荐」结构，看你的比例是不是失衡。  适合参考精选项目、其他项目、个人介绍与推荐语的组织方式，案例可进入详情页阅读。

[Ethan 的 Framer 作品集：三个精选案例的结构参考](https://thatethan.framer.website/)


## Logan Liffick：极简到只剩文字的个人站

Vercel 设计工程师的个人网站。整站几乎只有文字：About、Latest、Connect 三段，深色背景，横线分隔，点联系方式会提示「已复制」。没有案例展示，靠一句话说自己做什么和链接到 X、GitHub。  看它怎么用最少的元素说清楚「我是谁、在做什么、怎么找我」。给你自己的首页第一屏也写一版三句话版本。  适合参考文字层级与极简导航。展示项目经历时，可搭配完整的案例详情。

[Logan Liffick：极简到只剩文字的个人站](https://loganliffick.com/)


## Behance：看完整案例的视觉叙事

Adobe 旗下的作品发布平台，交互设计分类里有大量 UX 和产品设计的长案例页。适合看别人怎么用图和版式把一个项目从头讲到尾，视觉叙事和演示做到什么水平。  挑两三个和目标岗位接近的长案例，只看结构：从问题到方案用了几屏、哪几张图承担了主要叙事、结果放在哪。对照你自己的一个案例。  很多是概念稿或视觉提案，不是真实上线的项目。判断案例深度时看有没有约束、取舍和结果，别只看图好不好看。

[Behance：看完整案例的视觉叙事](https://www.behance.net/galleries/interaction-design)


## Dribbble：看封面、首屏和视觉风格

以单张作品图为主的设计社区，portfolio 标签下多是作品集首屏、封面和缩略图设计。适合快速翻一遍视觉风格。  翻 20 张作品集首屏，存 3 张第一眼就知道「这人做什么」的，写下它们靠的是标题、配图还是排版。  只有单张图，看不到案例叙事，概念稿也多。拿它参考视觉，别拿它参考案例结构。

[Dribbble：看封面、首屏和视觉风格](https://dribbble.com/tags/portfolio)


## Awwwards：网站设计评奖站，看动效和视觉

网站设计奖项平台，每天评一个 Site of the Day，十分制打分，有评审团。可以按类型（作品集、电商、建筑）和技术（Webflow、Framer、WebGL、GSAP）筛。免费看，有付费 PRO 会员和付费学院课程。  筛「Portfolio」类看 10 个，记下 3 个想学的手法，然后问一句：这个手法会不会让招聘方找不到我的案例？  适合参考视觉表现与动效。用于求职作品集时，需要兼顾案例阅读、导航和加载速度。

[Awwwards：网站设计评奖站，看动效和视觉](https://www.awwwards.com/websites/portfolio/)


## Godly：网页与视觉设计灵感库

浏览网页、界面、品牌、动效、3D 与字体设计案例，为作品集寻找排版、配色和视觉风格参考。  挑一两个案例，记下你想借鉴的具体手法（比如某种网格或标题字号），拿自己的一个页面试试。  截图适合参考视觉风格；交互与动效请查看案例原站。

[Godly：网页与视觉设计灵感库](https://godly.website/)


## 让长任务的等待过程更清楚

长任务需要同时考虑四件事：缩短实际耗时、尽早提供有用的结果、支持离开或取消、方便完成后检查。可按任务需要提供中间结果、完成通知和真实进度，让用户知道下一步能做什么。  拿同一个任务测三样：第一个有用结果多久出来、用户知不知道下一步、走开再回来能不能接上。中途先给一部分能核对的产物，说清取消会怎样。  步骤拆得更细不一定更好，短任务反而会被拖慢；进度和成果数量别编。


## 按操作后果设计确认方式

确认方式应与操作的影响相匹配。只读任务需要说明范围和来源；可撤销的修改需要让用户看清目标与变化；涉及权限或重大影响的操作需要明确授权。设计时同时考虑撤销、恢复和异常处理。  把你的 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 总结、哪些是确认过的结论。  互评是同行的看法，不是招聘方的标准，作品集改完还要拿真实面试去验。


## Related resources

- [AI 设计方法](https://aixdesign.kens-toolbox.com/zh/learn/design-with-ai.md): 从用户研究、创意探索到原型与交付，找到适合当前任务的方法。
- [AI 产品体验设计](https://aixdesign.kens-toolbox.com/zh/learn/design-for-ai.md): 探索信任、透明度与用户控制，让 AI 产品更易理解和使用。
- [设计师的 Vibe Coding](https://aixdesign.kens-toolbox.com/zh/learn/vibe-coding.md): 面向设计师的 AI 编程方法、工具与实践参考。
- [作品集打造](https://aixdesign.kens-toolbox.com/zh/learn/build-portfolio-with-ai.md): 用 AI 梳理项目、组织案例叙事，完成作品集并持续打磨。
- [社区经验与复盘](https://aixdesign.kens-toolbox.com/zh/learn/community-field-notes.md): 整理社区分享、设计圆桌与作品集互评中的经验、练习和资源。
- [AI 设计工具目录](https://aixdesign.kens-toolbox.com/zh/tools.md): 探索设计、研究、视觉创作与开发中的 AI 工具。

The community notes archive contains Chinese source material, not translated copies of every note.

Part of [Ken's Toolbox](https://kens-toolbox.com/). Account and participant data are not included in this public summary.