haimuhaimu Portfolio Story Builder
把“包装”理解为提升证据密度和叙事清晰度，而不是放大头衔或编造指标。输出必须让招聘官快速看懂候选人解决了什么问题、做了什么判断、有什么证据、哪些结果属于团队。
核心闭环
按顺序完成：材料盘点 → 判断 product / operations / hybrid 叙事 → 一次只问一个高价值问题补证据 → 从全部经历选择 3 个项目 → 去水分与证据强度评审 → 隐私红线检查 → 生成 v2 projects.json → 在目标仓库构建预览。
材料已足以继续时直接推进，不为了走流程机械追问。事实不足时明确写“待补充”；不生成貌似合理的虚构指标、客户、职责或结果。
1. 盘点材料
从简历、项目文档、聊天描述、复盘、截图或数据摘要中建立经历台账。每段经历至少抽取：
- 场景、目标用户/业务对象、问题与约束
- 本人角色、关键判断、具体动作、协作边界
- 结果、口径、时间窗、证据载体
- 实际交付物与可复用资产
- 敏感项、冲突项、缺失项
同一事实只保留一个主记录；冲突事实标记待确认，不擅自选择更“好看”的版本。
2. 判断主叙事
根据目标岗位而非当前职级判断：
- product：核心价值来自问题定义、产品机制、需求取舍、实验验证或系统落地。按 产品项目叙事指南 组织。
- operations：核心价值来自人群经营、内容/活动/渠道策略、节奏执行、转化复盘或运营机制。按 运营项目叙事指南 组织。
- hybrid：经历横跨产品与运营。先按投递岗位选全局主预设，再让三个项目分别采用最能解释贡献的主叙事；不要在同一项目里来回切换视角。
模板的 rolePreset 只有 product 与 operations。hybrid 不新增 schema 枚举，按目标岗位选择其一。
3. 一次只补一个高价值证据
先判断当前最大证据缺口，只问一个问题。优先级为：
- 目标岗位不清，导致无法选叙事与项目
- 三个候选项目无法区分的关键结果或个人贡献
- 结果的口径、时间窗、基线/对照、证据载体
- 关键取舍、失败方案或护栏
- 可公开范围与隐私授权
问题要让用户容易回答，例如：“在 A 项目中，最能证明效果的一项结果是什么？请同时给出指标口径和观察周期。”收到答案后更新台账，再决定是否还有必要问下一题。用户明确不知道时记录“待补充”并继续，不换一种方式逼问。
4. 从全部经历选择 3 个项目
先对全部经历评分，不从用户最先提到的三个直接开写。使用 证据强度评分与去水分 中的选择矩阵，兼顾：
- 对目标岗位的相关性
- 证据强度与可验证性
- 个人判断和贡献密度
- 与常见候选人的差异化
- 三个项目之间的能力互补
三个项目应形成组合：一个证明核心岗位能力，一个证明复杂度或跨团队推进，一个证明差异化或成长潜力。证据弱但相关性不可替代时可以保留，同时显式标记待补证据。
5. 去水分、挑战与 30 秒测试
按 证据强度评分与去水分 逐项目给出 0–5 分证据分，删除空话、重复结果、虚假因果和越界归功。
进入挑战模式：站在怀疑型招聘官视角质疑归因、口径、失败样本和个人边界。挑战只用于发现缺口，不用推测填空。
执行招聘官 30 秒测试。只看首屏标题、摘要和核心指标，检查能否在 30 秒内回答：
- 候选人做的是什么项目？
- 本人最关键的动作或判断是什么？
- 至少一个可信证据是什么？
- 为什么与目标岗位相关？
任一项答不出，优先重写信息顺序，不靠增加篇幅修复。
6. 隐私红线检查
生成前和构建前各检查一次 隐私检查清单。默认删除内部链接、用户明细、密钥、项目代号和未经确认可披露的精确业务数据。自动扫描不能替代用户对组织保密规则的最终确认。
7. 生成 v2 projects.json
复制 assets/portfolio-v2-minimal.json 作为匿名安全的非 strict 起草骨架，按 v2 数据规范 填充。骨架中的 product 示例用于说明元素结构，保留“待补充”和弱证据，因此不能作为 strict 合格作品：
schemaVersion固定为2rolePreset只能为product或operationsfeaturedProjectSlugs恰好引用已选中的 3 个项目- 缺失事实使用“待补充”，不伪造结果
- 主线默认关闭
profile、thinking、advancedModels中非必要展示
生成后运行审计：
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-controlskill 完成分支、变更检查和版本协作。 - 使用
frontend-developmentskill 完成数据接入、依赖安装、构建和本地预览验证。 - 使用
deployskill 完成可访问预览。
只在用户指定的目标仓库中写入作品集数据和必要的展示调整。构建失败时保留审计通过的数据文件，报告具体错误，不用删除字段规避真实问题。
个人模型彩蛋
仅在三个项目、审计、隐私检查和预览主线全部完成后，主动询问用户是否希望增加个人模型彩蛋。只有用户明确选择后，才启用 advancedModels 并补充 personalOperatingSystem、influences、trainingHistory 或 calibrationLogs。
彩蛋不能阻塞投递主线，也不能用人格标签替代项目证据；用户不选择时保持对应数组为空。
开发验证
正常作品集工作流只运行 scripts/audit_portfolio.py，不执行测试套件。仅在开发或修改审计器时运行 python3 -m unittest scripts/test_audit_portfolio.py；测试入口见 test_audit_portfolio.py。
交付标准
最终交付包括：
- 三个项目的选择理由与证据分
- v2 兼容
projects.json - 审计 JSON 报告及退出码
- 隐私检查结论与仍需用户确认项
- 目标仓库构建结果和预览地址；若未提供仓库，明确标记该项待执行
- 仍为“待补充”的证据清单