跳转至

Alfred · 产品愿景

元信息

[!ABSTRACT] 愿景一句话（北极星 · 最上位约束） Alfred 从「辅助求职的工具」逐步演变为「懂我的个人管家」。

它凌驾于任何单点功能之上——当某个设计「对求职更省事、但对未来的管家形态是死路」时，否决它。

1. 最高原则

  1. 当前聚焦求职，但永远朝「个人管家」演进。 求职是第一个、也最重要的领域；但任何设计都不能把路写死。
  2. 可维护性优先于一时省事。 如果某个「现在更简单」的设计会损害未来的可维护性（maintainability），一律选可维护性。这是否决「临时写死」类方案的根本理由。
  3. 内核领域无关，本轮只做求职、但保留扩展能力。 对话 / 记忆 / 实体 / 事件 / 提醒等基座必须领域无关（见 ADR-0016）；本轮只聚焦求职，但必须为未来的管家形态保留扩展能力，不强行启动扩展。

2. 产品愿景分期

仅 V1 求职助理 是本轮聚焦范围；V2–V4 为未来分期，通过领域无关内核保留接入能力，本轮不实现。

V1 · 求职助理（本轮聚焦）

核心命题：把散落在语音、截图、PDF、链接里的求职信息，变成一张能查、能算、能提醒的关系网。

  • 岗位捕获（JD 链接 / 截图 / 口述）— 完整工作流见 PRD · 求职助理 工作流一。
  • 经历库（口语稿 → 结构化经历 → 按岗位定制的简历 bullet）— PRD 工作流一（step 5）、五。
  • 技能匹配（我会什么 × 岗位要什么 → 匹配与缺口）— PRD 工作流二 step 3。
  • 简历生成（Markdown 主信息 + 模板，版本可复用、可溯源）— PRD 工作流二。
  • 接触记录（Coffee Chat / 约饭 / 宣讲会 / 线上通话，泛化为 interaction）— PRD 工作流十四。
  • 投递追踪（Application Tracking）：端到端记录一次投递的完整生命周期（投递时间 / deadline / 面试 / offer / 拒信等节点）— PRD 工作流二 / 三 / 五 / 九 / 十等。
  • 主动提醒（截止日、投递后静默、感谢信、面试备战、技能缺口）— PRD 工作流四 / 六 / 七 / 十二。

V2 · 社交 CRM

核心命题：人脉不是通讯录，是「关系状态 + 欠的人情 + 该联系的时机」。

  • 关系强度与衰减
  • Follow-up 到期提醒
  • 引荐路径（我认识谁 → 谁认识目标公司的谁）
  • 互动历史时间轴

V3 · 记账

核心命题：个人财务的「该花 / 该省 / 该记」一目了然。

V4 · 健康 / Project / Vlog 记录

核心命题：把健康打卡、项目进度、Vlog 创作统一进「个人管家」的时间线与记忆。

3. 前端形态演进

  1. 第一阶段 · 微信小程序（最重要）— 类微信聊天界面，语音 / 文字 / 图片 / 文件双向流转。 选它是因为：多模态输入门槛最低、能写系统日历（提醒可落地）、分享成本低。
  2. 第二阶段 · 网页端 — 大屏编辑场景：改简历、看投递看板、批量整理经历。
  3. 第三阶段 · App — 脱离微信生态的原生体验。
  4. 第四阶段 · 接入树莓派等硬件 — 把 Alfred 带进物理世界（语音助手 / 家居触发）。

4. 愿景衍生的架构约束

以下硬约束直接来自上面的愿景；具体技术取舍见对应 ADR，不在此重复设计结论。注意：本表「含义」列只写约束级表述（"必须怎样"），不得滑入机制级描述（"用 X 实现"）；机制一律入对应 ADR。

愿景约束 含义 对应 ADR
「懂我」= 长期累积 用户原话永久留存；AI 提炼是可重算的派生物 记忆 / 事件-事实模型（ADR-0010）
「管家」= 主动找我 提醒引擎要有骨架，不是纯「你问我答」 提醒 / nudge 机制（ADR-0016）
一个人要用很多年 数据可导出、可回滚、可纠错 版本链 / 溯源（ADR-0014）
会替我做判断 每个结论都要能回答「你凭什么这么说」 简历溯源（ADR-0014）
内核领域无关 求职只是第一个领域包，不得把求职专有字段塞进通用内核 ADR-0016

5. 不做什么（同样重要）

  • 不做通用招聘平台：Alfred 服务「我」，不服务 HR，不做双边市场。
  • 不做自动投递机器人：投递决策必须由人做，Alfred 只降低摩擦、不代替判断。
  • 不做「什么都能聊」的聊天机器人：闲聊不是能力，是噪声源。无法归入任何领域的输入，落成记忆，不生成人格化回复。