CareerPal：从整理履历到规划职业发展

CareerPal 面向准备实习和初次求职的学生。它从一个常见的起点出发：学生手里已经有课程项目、实习、社团活动和技能，但这些经历还没有被组织成能向别人说明的资料。直接给一套简历表格，要求用户自己决定填什么、写多深、怎么表达，困难仍然留给了用户。

这项设计选择先通过对话了解经历，再把资料用于个人展示、岗位比较和成长计划。核心产物不是一轮聊天结束后生成的简历文本，而是一份可以继续修改、补充并生成不同输出的个人资料。2026 年 5 月的设计和实现围绕这条关系逐步展开。

先把经历问清楚，再决定怎样展示

有现成简历和没有简历，是两条不同的入口。有简历的用户可以上传 PDF 或 Word，系统先提取文本、整理资料，再围绕缺失或模糊之处追问；没有简历的用户则从学习阶段、学校专业和项目经历开始，通过选项与自由输入逐渐展开。

这两条路径不应生成两份互不相干的数据。它们最终都进入同一个资料模型：教育、工作或实习经历、项目、技能与证书。项目不只保存名称，还包含描述、使用的技术、成果和链接；经历区分机构、角色、时间、工作内容与成果。各类对象还预留 comment，保存字段之外的说明和语境。

这为对话确定了一个具体任务。面对“我做过一个课程项目”，需要继续问清楚负责的部分、完成的工作和现有证据，而不是立即将它润色成一段完整成绩。原始资料充分之后，页面突出项目还是教育背景、简历为哪个岗位调整，才成为表达层面的选择。

对话优先，不等于所有修改都要聊天

早期规格要求入口保持单一焦点：打开产品，AI 先说话，用户知道下一步可以做什么。资料可视化随着对话出现，显示哪些部分为空、哪些已有内容，以及当前正在讨论哪个节点。点击教育或项目节点，可以把对话转向对应话题。

后续界面设计进一步区分首次整理和日常维护。新用户经过介绍、账户、称呼和 onboarding，再进入工作区；已有用户登录后直接回到自己的资料。工作区包含 Profile、Match、My resume、Grow 等页面，资料卡片可以打开编辑抽屉，也可以通过对话继续完善。

这不是把“无菜单”的早期口号机械地延伸到整个产品。首次使用时，聊天降低开始的门槛；之后只想改一个日期或联系方式时，直接编辑比重新解释一遍更合适。两种输入方式最终修改同一份资料，避免聊天中的版本和表格里的版本各自发展。

完整度也需要稳定含义。后续设计将 empty / partial / complete 的判定交给后端，前端只消费这个约定。例如，一项教育记录是否包含学校、学位和时间，一项项目是否包含描述、技术和成果。它衡量的是资料字段是否足够，而不是这个人的能力是否“完整”。如果把资料填写程度画成职业能力评分，界面就会赋予数据本来没有的含义。

对话怎样变成可修改的资料

技术上，一轮职业对话包含两个结果：给用户看的回答，以及对资料的更新。设计把它们分开处理。

用户发来消息后，后端核对会话归属，组合角色说明、已有资料和会话上下文，再调用模型。回答通过 SSE 逐段送到前端；成功完成后保存会话，执行资料提取，并在最终的 done 事件里返回资料差异 extraction_diff。差异记录修改前和修改后的值，使界面能够在回答结束后更新资料状态，而不必从 AI 的自然语言里猜测到底改了什么。

提取还有一条重要边界：依据来自用户明确提供的信息，不能从助手自己生成的描述中再提取“事实”。否则模型第一次添写的经历，会在下一步被写进资料库，再成为后续回答的依据。

纠正比首次提取更复杂。用户可能先说目标是数据工程，随后改成平台工程；也可能在聊天之外直接编辑资料。留存代码在回看会话时，不会无条件把旧聊天的最后一句覆盖到当前资料上：如果当前值已经不是该会话此前记录过的值，就保留这次独立修改。这样，对话核对才不会成为一种把人工编辑悄悄改回去的后台操作。

页面和简历使用同一份资料，但不走同一条生成路径

CareerPal 区分 career 和 page 两类会话。职业对话围绕经历和目标，允许触发资料提取；页面对话围绕表达、布局和风格，不应把“让项目区更突出”误写成职业事实。这两类会话共用模型调用基础设施，但使用不同上下文和后处理。

个人页面从结构化资料生成。设计保留三类样式，生成的 HTML 作为版本保存，包含所属用户、模板、版本号和公开状态。继续定制时产生新版本，而不是只在浏览器里修改一份无法追踪的内容。定向版本还可以关联来源岗位分析，使用户知道某次调整是为哪一个机会做的。

生成和公开是两个动作。后续页面托管方案默认私有，用户明确切换公开状态后，外部访问者才可以通过用户名路径读取页面。设计稿上的示例域名只是界面表达，不代表项目已经部署到那个地址。

PDF 的实现路线则直接读取结构化资料，以传统简历版式渲染，而不是把模型生成的网页原样打印。网页可以采用更丰富的布局；PDF 服务投递场景，两者有不同的排版要求。让它们共享资料、分别渲染，避免一个网页样式变化同时破坏简历输出。

Match：比较的是岗位要求与已有证据

第二阶段接收用户粘贴的岗位描述。分析输入是当前保存的资料加上这份 JD，输出被约束为公司、岗位、分数、优势、缺口和调整建议等字段。后续计划要求合法的结构化结果才能写入历史；模型返回格式错误时，不应保存一个只有部分字段的“成功分析”。

保存针对某岗位的简历版本，是分析之后的独立动作。方案将这个版本关联回原始匹配记录，同时让它出现在简历版本历史中。这样，岗位分析和为它生成的表达不会脱节，也不必为了某一次申请改写全部基础资料。

“分数”在这里需要克制解释。现有材料包含启发式与模型分析路径，前端也有分数可视化，但没有证明这些数值经过就业结果校准。它们不能被当作录用概率。更有解释力的是具体对应关系：岗位要求什么、资料中哪一段支持它、哪一项没有证据，以及可以怎样补充或更清楚地呈现。

下面是一段虚构的产品情境，不是真实用户记录或运行结果。

一名学生提供的事实是：在课程小组里负责数据看板的前端页面，用模拟数据完成演示，没有部署经验。目标岗位要求前端开发与部署经验。

展示页可以呈现课程项目、个人负责的页面和模拟数据的范围。匹配结果应分别指出已有的界面开发经历与缺少的部署证据，而不能把演示改写成“上线运营的数据平台”。定向简历可以调整项目的展示顺序、突出与岗位有关的工作，却不能因为岗位需要部署就添写部署经历。

Grow：建议必须有回到资料的路径

第三阶段把岗位差距转为成长计划。后续设计让用户从一份已保存的岗位分析发起生成，输入仍包含当前资料。模型输出 JSON 形式的节点树，经过结构和树关系验证后，保存为当前成长计划。

这个阶段的范围很具体：每个用户只有一份当前计划，新生成会替换它，而不是维护多条职业路线的完整历史。节点进展允许用户提交证据，系统保存日志、更新节点状态，并在个人资料的说明字段追加一条相关记录。

回到课程看板的示例，成长行动可以是完成一次真实部署并记录步骤与问题。只有学生实际完成并补充材料后，这才成为新的经历。这个回流让“缺什么—做什么—留下什么”连起来，也明确区分计划与成果：生成了一条行动项，不等于用户已经获得对应能力。

为产品逻辑留下可替换的技术边界

架构采用独立的 Next.js 前端和 FastAPI 后端。前端由阶段容器管理登录状态、页面切换和 API 调用，各个界面接收数据与回调；后端按认证、资料、会话、文件、页面、匹配与成长分模块，数据模型通过迁移管理。资料与生成版本保存在数据库，上传文件通过存储抽象处理，设计支持本地与对象存储路径。

模型层也被单独封装：内部使用统一消息结构，对外适配 OpenAI-compatible 与 Anthropic 格式；测试和早期界面接通可以使用确定性的 fake provider。这个分层允许先确认会话、数据和界面的契约，再替换模型接入，但也意味着设计原型中的动态效果、固定数据与真实模型能力必须分开理解。