Cyber Silicon Valley：AI 人才与企业匹配平台

一个做过 RAG 项目的人，并不一定知道自己还适合哪些岗位。一家想把 AI 用进业务的企业，也未必能一开始就写出准确的招聘要求。双方都有信息，但这些信息往往分别停留在简历、项目介绍、职位描述和零散对话里。招聘平台能够把两边放在同一个列表中，却不一定帮助他们理解彼此。

Cyber Silicon Valley（CSV）围绕这个问题组织产品：人才一侧有持续了解其能力、经历与目标的 AI companion，企业一侧有帮助梳理需求和筛选候选人的 AI。两边的对话都需要落到可查看、可修改的结构化信息，再支持机会探索、匹配解释和预沟通。AI 的角色贯穿这条路径，而不是等用户填完所有表单后才出现在页面角落。

先认识一个人，再生成他的档案

CSV 的人才入驻从一个简单的对话入口开始。产品设计允许从简历、链接或自我介绍切入，目的不是增加几种上传方式，而是接受不同人已经拥有的材料：有人有整理好的履历，有人只有项目页面，也有人更容易先说清楚最近在做什么。

后续对话围绕能力画像中仍然缺失的信息展开。除了职位名称和技能标签，还要了解做过什么项目、承担什么工作、希望寻找什么机会，以及什么时候可以开始。这些问题会影响匹配，不应被一段漂亮但笼统的个人简介替代。

入驻界面把对话和正在形成的档案并排放置。右侧画像最初带有模糊遮罩；随着具体信息得到确认，姓名、角色、技能和经历逐项变得清晰。这里的显现动效承担反馈作用：用户可以看到，刚才说的内容究竟被系统理解成了什么。对话不再是提交后就看不见的输入过程。

技术上，普通回复与结构化更新是两类事件。模型流式输出文字，也可以发出 reveal_profile_field、add_skill_tag 等工具事件，由界面更新对应字段。完成入驻后，这些信息成为后续功能共用的能力画像；用户仍能直接编辑，而不必通过反复提示模型来纠正每一个字段。

这也决定了产品的一个边界：画像必须能被本人辨认和修正。让 AI 帮助组织经历，并不意味着允许它补写不存在的经验。

一个常驻伙伴，几个明确的工作空间

进入主页后，画像不只是交给招聘方看的简历，也是 companion 理解用户的上下文。技能、经历、目标和可用时间共同支持后续回答。用户补充一个新项目或改变求职方向时，伙伴能够把新信息转成档案更新，而不是把它留在一段难以再次找到的聊天记录中。

CSV 没有把所有任务挤进同一个聊天窗口。不同空间对应不同问题：

Home：我现在如何被介绍，我的能力与目标是什么。
Coach：怎样改进简历、准备面试，或分析某项机会需要补充的能力。
Seeking Report：有哪些值得进一步了解的机会，为什么值得看。
Opportunity Fair：当我还不知道应该搜索什么时，从哪些相邻方向探索。
Inbox：哪些邀请、预沟通结果和后续事项需要我决定。

这些空间共用个人档案，却不需要共用同一段无限增长的聊天历史。职业辅导与机会讨论具有各自的任务上下文；常驻伙伴则保持用户认识上的连续性。它应当能指出与具体经历有关的建议，而不是每到一个页面就重新问一次“请介绍一下你自己”。

设计中的记忆层也服务于这一点：长期相关的信息需要单独组织，普通消息仍保留为对话。相较于把所有旧消息不断塞回模型，这种划分让“系统记住了什么”和“这次正在讨论什么”有不同的位置。

企业首先要把需求说清楚

另一侧的难点并不只是简历太多。企业可能需要长期招聘，也可能需要一个有明确交付物的项目团队；一句“需要 AI 人才”无法支撑有效筛选。

企业入驻因此先确认公司信息，再澄清意图与需求。职位文本、已有 JD 和对话输入最终收敛为同一种可编辑需求卡片：技能要求、必需与加分项、资历、开始时间、项目周期、交付物、预算与工作方式。对于项目合作，“要交付什么”与“做过什么岗位”同样重要。

结构化也让模糊的偏好可以被检查。例如，一项要求究竟是不能妥协的条件，还是愿意用其他经验补足的加分项？远程工作是否可接受？什么时候必须到岗？这些区别如果只藏在一段文字里，后续的匹配分数很难解释。需求卡片经过企业审阅和调整，再进入发布与筛选。

筛选提供两种互补的方式。结构化视图按维度列出要求与候选人信息，支持硬条件过滤和并排比较；对话视图则允许企业进一步追问，例如“这些人中，谁有实际交付过系统的经验”。两种入口最终进入同一份候选人详情，而不是生成两套互不相认的评价。

候选人详情复用人才侧的能力画像，同时突出与当前需求有关的部分。对同一个人，面对不同岗位时重点可以不同，但不能因此改变原始经历。

两个 AI 可以先谈，但人的决定必须留下

发现一个看起来合适的人之后，双方仍有大量基础信息要确认。CSV 的 AI 预沟通让企业侧和人才侧的代理分别依据已有材料展开有限轮次的问答：企业侧围绕职位要求提问，人才侧依据个人画像回应。

这一部分在设计过程中发生过实质变化。最初的 MVP 用候选人资料与岗位信息生成一份模拟预沟通摘要；后来的流程改为保存实际生成的多轮 AI 对话，再从对话中提炼摘要。二者的区别很重要：摘要应该能回到发生过的交换，而不是让读者误以为一个结论背后已经存在完整沟通。

预沟通有独立的状态与消息记录。系统区分 AI HR、AI talent、企业本人和候选人本人，也保留参与确认、AI 筛选、候选人审阅、完成与拒绝等状态。AI 问答结束后进入候选人审阅，并把结果送到双方收件箱；候选人能在了解内容后决定是否继续；接受之后，流程才进入双方直接消息的会话，拒绝则结束这次预沟通。

这种安排把自动化放在信息准备阶段。人才侧 AI 对档案的代述，不能被包装成本人已经接受岗位条件；两个代理产生了流畅对话，也不等于双方达成合作。

后台逐轮保存消息和轮次数。外部模型调用在数据库事务之外进行，返回后才用短事务写入结果；更新还检查会话是否仍处于预期状态。这样可以减少长时间占用数据库，并在任务中断后依据已保存的轮次继续处理。生成摘要后，再推进状态并写入通知。一次预沟通因而是可恢复的工作过程，而不只是页面里的一次长请求。

界面、业务与长任务分别承担什么

CSV 的架构随产品从早期 Next.js 全栈方案演变为前后端分离。当前前端使用 Next.js 承担页面、交互与流式呈现；业务 API 使用 FastAPI，长任务交给独立的 Python worker。

这项拆分对应两种不同的等待。建档或与 companion 聊天时，用户需要看到文字和工具事件持续出现，API 通过 SSE 返回进展。匹配、报告和预沟通则属于可能跨越页面停留时间的工作，需要队列、保存结果和再次读取，而不能依赖一个一直打开的标签页。

PostgreSQL 保存用户画像、需求、匹配记录、对话与通知等持久数据，pgvector 为向量信息提供存储基础；Redis 承担队列与协调，arq worker 执行后台工作。共享的 Python 包分别组织接口契约、业务逻辑、数据访问和模型调用，使 API 与 worker 不必各自解释一遍“画像”“会话”或“岗位”的含义。CLI 与 MCP 接口也围绕这套业务边界接入。

模型提供商被放在独立路由层。业务流程定义要传入的个人资料、岗位内容与工具，而不是把所有页面直接绑到某一家模型接口。模型能力可以替换，用户资料和预沟通状态仍然属于产品自身。

对话负责引导，界面负责让信息站得住

CSV 的视觉和交互设计强调单一焦点。入驻是叙事过程：先打招呼，再提供入口，再逐步呈现画像，不在第一屏同时展示所有功能。完成入驻后的工作空间则承担比较、浏览和处理事项，需要稳定的结构，不能要求用户通过聊天重新生成每一张列表。

两类界面由同一个 companion 联系起来。它可以解释当前看到的机会，帮助修改资料，也可以引导下一步；但能力画像、需求卡片、匹配维度和预沟通记录仍然是可以独立查看的对象。

这使 CSV 的核心落在一个具体的产品问题上：让 AI 帮助双方把不完整的信息逐步说清楚，同时让每一次理解都留下可检查的结果。最终的选择仍然来自人，而不是来自一个无法展开的匹配分数。