设计、PM、工程师在作品集上共有的毛病是：case study 写成 STAR 流水账，那个真正起作用的”决定”反而没出场。AI 能修结构，前提是你把骨头给它——作品集故事的骨架是”不确定下你做了什么取舍”，不是活动清单。
任务场景
你在为自己的站、deck 或 take-home 复盘改写一个项目叙事。要一个 600-900 字的版本，把你做了什么决定、差点做了什么决定、错了你会怎么知道，三件事都写进去。
哪些情况适合让 AI 来做
- 项目已经 ship 了，有可衡量或定性的结果（真用户、真数字、真采用）。
- 你能讲清那一个最关键的决定——不是五个细节决定，是一个。
- 你愿意自己先写前 50 个字再粘给 AI。语气在前 50 个字里就定了。
- 你有目标读者（某个阶段 / 某个职能的 hiring manager）。
如果项目没 ship 或没真用户，跳过。整本作品集全是没 ship 的项目，传递的是”判断力”的问题，不是”机会”的问题。
需要先给 AI 的信息
- 项目 8-10 行（问题、你的角色、ship 了什么、结果）
- 那一个不确定下的决定——你差点做的另一个选择是什么、为什么没做
- 你顶住的约束（时间、预算、人头、技术债、品牌）
- 错了的代价：你的决定如果是错的，会崩在哪
- 读者 + 格式（网页 case study、6 页 deck、1 页 write-up）
可直接复制的 Prompt
你帮我写一个 {senior product designer} 作品集的项目叙事。
项目（8-10 行）：
{粘贴——问题、角色、ship、结果}
那一个不确定下的决定：
{比如："第 4 周时我们选择 ship 一个部分版本的 onboarding，而不是等到第 8 周 ship 完整版。差点选择等，因为数据质量有风险；最终 ship，因为 customer success 正在每天流失 ticket。"}
我顶住的约束：
{比如："工程只投了 2 周；品牌要求周一上线；没有额外 QA。"}
错了的代价：
{比如："如果 activation 涨不到 10%+，就在相同负载下出了一个更差的体验，还烧掉了内部支持者的信任。"}
目标读者：{Series B SaaS 的 hiring manager}。
格式：网页 case study，700-850 字。
按以下结构写：
1. 一段开头钩子（80 字内）——我做了什么决定 + 风险 stake，不要黑话。
2. 上下文——一段，只放 4-5 个事实，不科普。
3. 决定——明确点名我拒绝的那个选项以及为什么。
4. Ship 的东西——具体（几个屏、砍了什么、推迟了什么）。
5. 结果——数字 + 一个二阶结果（一个行为变化或下游指标）。
6. 复盘——一句诚实的话，不要三句。
语气规则：
- 第一人称，允许缩写。
- 一个人独立做的项目不要写 "I led"，写 "I designed"、"I made the call"。
- "Stakeholder alignment" 必须能点名 stakeholder 和具体摩擦，否则删。输出示例
钩子：用一段把那个决定讲完——“第 4 周我们 ship 了一个部分版本的 onboarding，而不是等到第 8 周 ship 完整版。“风险一句话——“客户成功每天因为掉头流失 12 张 ticket。”
上下文：只放四个事实——团队规模、产品阶段、约束、成功标准。不科普 SaaS。Hiring manager 不需要被解释 SaaS 是什么。
决定：点名替代项（“等数据质量修完”）以及为什么没选它（“ticket 流失是已知成本，数据风险是估算成本”）。这是故事的骨架。
Ship 的东西：具体 artifact——3 个 onboarding 屏换成产品内一个 checklist，一份被改名为 CS runbook 的 Notion 文档，那场被低估的工程和 CS 对齐”什么算 done”的会。
结果：activation 涨 28%，第一周每天少 9 张 ticket，外加一个行为变化——CS 开始自己跑 SQL 查 activation 表。
复盘：一句诚实的话——“我应该在 ship 前给 2 个 CS 看过部分版本；我假设他们会接受，这个假设让我后来花了一周重建信任。“
怎么改输出
- 像 STAR 模板——让 AI 把可见的 STAR 缝合线擦掉。钩子不准出现 “Situation:” 这种字眼。
- 决定写得虚——你没在输入里点名替代项，AI 也猜不出来。改输入，不要改输出。
- 活动太多、决定太少——让 AI 数活动，超过 3 个就砍。活动会稀释骨架。
- 听起来在邀功——加：“不准最高级。
显著提升改成具体数字；紧密合作改成职能名 + 具体摩擦。” - 每个项目味道一样——轮换骨架：一个项目是速度决定、一个是取舍决定、一个是”不做决定”（等待才是正确动作）。
容易踩的坑
- 把决定藏起来。读者分不清哪些是你定的、哪些是别人给你的。
- 团队项目里抬高自己的角色。“I led” 当只是 co-led，“I designed” 当只是评审。Recruiter 会查 reference，水分会被看穿。
- 摆过程产物（草图、journey map）却不讲它们改变了什么。没决定的过程是装饰。
- 不提约束。一个没有约束的项目读起来像没真发生——真项目都有约束。
- 同一个叙事打给所有读者。按岗位调钩子：PM 看约束和取舍、设计看 craft 和理由、工程看系统和成本。
FAQ
- 作品集放几个项目？ 长篇 3-5 个，加 2-3 个缩略图撑广度。超过 5 个稀释，少于 3 个显薄。
- 能用 AI 生成视觉吗？ 流程图和重构图可以。最终的主视觉不行——生成图越来越好认。
- 每个项目都要数字吗？ 至少 60% 要。Craft 项目可以纯定性，整本不能全是定性。
- NDA 怎么办？ 抹掉识别信息、改名字，决定保留。决定的结构本身很少属于机密。
- 要不要放失败项目？ 要——一个。零失败的作品集读起来要么 junior、要么被清洗过。