Alfred · 产品愿景¶
元信息 - 状态：现行有效 - 最后更新：2026-08-06 - 范围：产品最上位愿景、分期与核心命题 - 关联：ADR-0016 领域无关内核、ADR 总览
Alfred 从「辅助求职的工具」逐步演变为「懂我的个人管家」。
这一句是本项目的最上位约束。它凌驾于任何单点功能之上—— 当某个设计「对求职更省事、但对未来的管家形态是死路」时，否决它。
1. 最高原则¶
- 当前聚焦求职，但永远朝「个人管家」演进。 求职是第一个、也最重要的领域；但任何设计都不能把路写死。
- 可维护性优先于一时省事。 如果某个「现在更简单」的设计会损害未来的可维护性（maintainability），一律选可维护性。这是否决「临时写死」类方案的根本理由。
- 内核领域无关，本轮只做求职、但保留扩展能力。 对话 / 记忆 / 实体 / 事件 / 提醒等基座必须领域无关（见 ADR-0016）；本轮只聚焦求职，但必须为未来的管家形态保留扩展能力，不强行启动扩展。
2. 产品愿景分期¶
仅 V1 求职助理 是本轮聚焦范围；V2–V4 为未来分期，通过领域无关内核保留接入能力，本轮不实现。
V1 · 求职助理（本轮聚焦）¶
核心命题：把散落在语音、截图、PDF、链接里的求职信息，变成一张能查、能算、能提醒的关系网。
- 岗位捕获（JD 链接 / 截图 / 口述）
- 经历库（口语稿 → 结构化经历 → 按岗位定制的简历 bullet）
- 技能匹配（我会什么 × 岗位要什么 → 匹配与缺口）
- 简历生成（Markdown 主信息 + 模板，版本可复用、可溯源）
- 接触记录（Coffee Chat / 约饭 / 宣讲会 / 线上通话，泛化为
interaction） - 投递追踪（Application Tracking）：端到端记录一次投递的完整生命周期——
- 什么时候投递的？
- 它的 deadline 在哪里？
- 有没有收到面试？
- 收到面试后，什么时候开始准备？
- 第一轮面试：面试官是谁？面试结果怎么样？
- 什么时候第二轮面试？
- 有没有拿到 offer？accept 还是 reject？接受 / 拒绝的截止期是什么时候？
- 主动提醒（截止日、投递后静默、感谢信、面试备战、技能缺口）
V2 · 社交 CRM¶
核心命题：人脉不是通讯录，是「关系状态 + 欠的人情 + 该联系的时机」。
- 关系强度与衰减
- Follow-up 到期提醒
- 引荐路径（我认识谁 → 谁认识目标公司的谁）
- 互动历史时间轴
V3 · 记账¶
核心命题：个人财务的「该花 / 该省 / 该记」一目了然。
V4 · 健康 / Project / Vlog 记录¶
核心命题：把健康打卡、项目进度、Vlog 创作统一进「个人管家」的时间线与记忆。
3. 前端形态演进¶
- 第一阶段 · 微信小程序（最重要）— 类微信聊天界面，语音 / 文字 / 图片 / 文件双向流转。 选它是因为：多模态输入门槛最低、能写系统日历（提醒可落地）、分享成本低。
- 第二阶段 · 网页端 — 大屏编辑场景：改简历、看投递看板、批量整理经历。
- 第三阶段 · App — 脱离微信生态的原生体验。
- 第四阶段 · 接入树莓派等硬件 — 把 Alfred 带进物理世界（语音助手 / 家居触发）。
4. 愿景衍生的架构约束¶
以下硬约束直接来自上面的愿景；具体技术取舍见对应 ADR，不在此重复设计结论：
| 愿景约束 | 含义 | 对应 ADR |
|---|---|---|
| 「懂我」= 长期累积 | 用户原话永久留存；AI 提炼是可重算的派生物 | 记忆 / 事件-事实模型（ADR-0010） |
| 「管家」= 主动找我 | 提醒引擎要有骨架，不是纯「你问我答」 | 提醒 / nudge 机制（ADR-0016） |
| 一个人要用很多年 | 数据可导出、可回滚、可纠错 | 版本链 / 溯源（ADR-0014） |
| 会替我做判断 | 每个结论都要能回答「你凭什么这么说」 | 简历溯源（ADR-0014） |
| 内核领域无关 | 求职只是第一个领域包，不得把求职专有字段塞进通用内核 | ADR-0016 |
5. 不做什么（同样重要）¶
- 不做通用招聘平台：Alfred 服务「我」，不服务 HR，不做双边市场。
- 不做自动投递机器人：投递决策必须由人做，Alfred 只降低摩擦、不代替判断。
- 不做「什么都能聊」的聊天机器人：闲聊不是能力，是噪声源。无法归入任何领域的输入，落成记忆，不生成人格化回复。