# Portfolio Story Builder

> 将简历、项目经历和零散材料转成可投递的产品经理或运营作品集，支持材料盘点、产品/运营双叙事判断、单问题补证据、三项目精选、证据评分与去水分、招聘官 30 秒测试、挑战模式、隐私检查、生成 strategy-product-portfolio-template v2 兼容 projects.json 并构建预览。适用于用户说“把简历做成作品集”“帮我包装产品项目”“运营项目怎么写”“生成可投递作品集”等场景。

- Skill: `haimuhaimu/portfolio-story-builder` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add haimuhaimu/portfolio-story-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haimuhaimu/portfolio-story-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: haimuhaimu (https://skillmd.com/u/haimuhaimu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haimuhaimu/portfolio-story-builder

---


# Portfolio Story Builder

把“包装”理解为提升证据密度和叙事清晰度，而不是放大头衔或编造指标。输出必须让招聘官快速看懂候选人解决了什么问题、做了什么判断、有什么证据、哪些结果属于团队。

## 核心闭环

按顺序完成：**材料盘点 → 判断 product / operations / hybrid 叙事 → 一次只问一个高价值问题补证据 → 从全部经历选择 3 个项目 → 去水分与证据强度评审 → 隐私红线检查 → 生成 v2 `projects.json` → 在目标仓库构建预览**。

材料已足以继续时直接推进，不为了走流程机械追问。事实不足时明确写“待补充”；不生成貌似合理的虚构指标、客户、职责或结果。

## 1. 盘点材料

从简历、项目文档、聊天描述、复盘、截图或数据摘要中建立经历台账。每段经历至少抽取：

- 场景、目标用户/业务对象、问题与约束
- 本人角色、关键判断、具体动作、协作边界
- 结果、口径、时间窗、证据载体
- 实际交付物与可复用资产
- 敏感项、冲突项、缺失项

同一事实只保留一个主记录；冲突事实标记待确认，不擅自选择更“好看”的版本。

## 2. 判断主叙事

根据目标岗位而非当前职级判断：

- **product**：核心价值来自问题定义、产品机制、需求取舍、实验验证或系统落地。按 [产品项目叙事指南](references/product-case-guide.md) 组织。
- **operations**：核心价值来自人群经营、内容/活动/渠道策略、节奏执行、转化复盘或运营机制。按 [运营项目叙事指南](references/operations-case-guide.md) 组织。
- **hybrid**：经历横跨产品与运营。先按投递岗位选全局主预设，再让三个项目分别采用最能解释贡献的主叙事；不要在同一项目里来回切换视角。

模板的 `rolePreset` 只有 `product` 与 `operations`。hybrid 不新增 schema 枚举，按目标岗位选择其一。

## 3. 一次只补一个高价值证据

先判断当前最大证据缺口，只问一个问题。优先级为：

1. 目标岗位不清，导致无法选叙事与项目
2. 三个候选项目无法区分的关键结果或个人贡献
3. 结果的口径、时间窗、基线/对照、证据载体
4. 关键取舍、失败方案或护栏
5. 可公开范围与隐私授权

问题要让用户容易回答，例如：“在 A 项目中，最能证明效果的一项结果是什么？请同时给出指标口径和观察周期。”收到答案后更新台账，再决定是否还有必要问下一题。用户明确不知道时记录“待补充”并继续，不换一种方式逼问。

## 4. 从全部经历选择 3 个项目

先对全部经历评分，不从用户最先提到的三个直接开写。使用 [证据强度评分与去水分](references/evidence-score.md) 中的选择矩阵，兼顾：

- 对目标岗位的相关性
- 证据强度与可验证性
- 个人判断和贡献密度
- 与常见候选人的差异化
- 三个项目之间的能力互补

三个项目应形成组合：一个证明核心岗位能力，一个证明复杂度或跨团队推进，一个证明差异化或成长潜力。证据弱但相关性不可替代时可以保留，同时显式标记待补证据。

## 5. 去水分、挑战与 30 秒测试

按 [证据强度评分与去水分](references/evidence-score.md) 逐项目给出 0–5 分证据分，删除空话、重复结果、虚假因果和越界归功。

进入**挑战模式**：站在怀疑型招聘官视角质疑归因、口径、失败样本和个人边界。挑战只用于发现缺口，不用推测填空。

执行**招聘官 30 秒测试**。只看首屏标题、摘要和核心指标，检查能否在 30 秒内回答：

- 候选人做的是什么项目？
- 本人最关键的动作或判断是什么？
- 至少一个可信证据是什么？
- 为什么与目标岗位相关？

任一项答不出，优先重写信息顺序，不靠增加篇幅修复。

## 6. 隐私红线检查

生成前和构建前各检查一次 [隐私检查清单](references/privacy-checklist.md)。默认删除内部链接、用户明细、密钥、项目代号和未经确认可披露的精确业务数据。自动扫描不能替代用户对组织保密规则的最终确认。

## 7. 生成 v2 projects.json

复制 `assets/portfolio-v2-minimal.json` 作为匿名安全的非 strict 起草骨架，按 [v2 数据规范](references/portfolio-v2-schema.md) 填充。骨架中的 product 示例用于说明元素结构，保留“待补充”和弱证据，因此不能作为 strict 合格作品：

- `schemaVersion` 固定为 `2`
- `rolePreset` 只能为 `product` 或 `operations`
- `featuredProjectSlugs` 恰好引用已选中的 3 个项目
- 缺失事实使用“待补充”，不伪造结果
- 主线默认关闭 `profile`、`thinking`、`advancedModels` 中非必要展示

生成后运行审计：

```bash
python3 scripts/audit_portfolio.py <projects.json> --strict --output <audit-report.json>
```

退出码：`0` 通过，`1` 需要修改，`2` 输入或输出错误。根据 JSON 报告修复后重跑；严格模式仍有警告时不得称为可投递版本。

审计器的能力边界是**内容质量检查 + 本 Skill 声明的 v2 最小契约**：它检查关键对象、字段类型、数组元素、占位、证据强度、常见隐私模式，以及 featuredProjectSlugs、roadmap、starMap 的项目引用完整性，但不替代目标模板的完整类型系统、normalize 行为或运行时约束。适合跨语言共享的规则标识、脱水词与隐私模式统一维护在 `audit-manifest.json`，不要在 JS 与 Python 中分别新增硬编码。最终兼容性仍以目标模板自身的 test/build 结果为准。

## 8. 在目标仓库构建预览

先确认目标仓库和数据文件位置；未提供仓库时，只交付可审计的 `projects.json` 并询问目标仓库，不臆造路径。

- 使用 `git-collaboration-version-control` skill 完成分支、变更检查和版本协作。
- 使用 `frontend-development` skill 完成数据接入、依赖安装、构建和本地预览验证。
- 使用 `deploy` skill 完成可访问预览。

只在用户指定的目标仓库中写入作品集数据和必要的展示调整。构建失败时保留审计通过的数据文件，报告具体错误，不用删除字段规避真实问题。

## 个人模型彩蛋

仅在三个项目、审计、隐私检查和预览主线全部完成后，主动询问用户是否希望增加个人模型彩蛋。只有用户明确选择后，才启用 `advancedModels` 并补充 `personalOperatingSystem`、`influences`、`trainingHistory` 或 `calibrationLogs`。

彩蛋不能阻塞投递主线，也不能用人格标签替代项目证据；用户不选择时保持对应数组为空。

## 开发验证

正常作品集工作流只运行 `scripts/audit_portfolio.py`，不执行测试套件。仅在开发或修改审计器时运行 `python3 -m unittest scripts/test_audit_portfolio.py`；测试入口见 [test_audit_portfolio.py](scripts/test_audit_portfolio.py)。

## 交付标准

最终交付包括：

1. 三个项目的选择理由与证据分
2. v2 兼容 `projects.json`
3. 审计 JSON 报告及退出码
4. 隐私检查结论与仍需用户确认项
5. 目标仓库构建结果和预览地址；若未提供仓库，明确标记该项待执行
6. 仍为“待补充”的证据清单

