路线图

AI 能力

能力	现状	什么条件下值得做	设计要点
LangGraph 编排	未使用。岗位评估是一次结构化调用，六个阶段压在一段 task 里。	任务出现真正的分支或回退：某一步失败要回到上一步重取证据；或者需要人工在中间确认。	三个节点起步（解析 → 取证据 → 评估）；每个节点独立 Zod；保留单次调用作为 fallback；记录每节点耗时与 token。
RAG 检索	未使用。档案与简历全文直接放进上下文。	素材卡超过 200 张，或岗位库超过 5000 条，导致“全量放进去”超出模型窗口；或者要按语义找相似岗位。	先只检索素材卡：pgvector + chunk 表，top-k 5，带来源链接；召回错误要能被用户看见。
多 Agent 协作	未使用。单 Agent，单轮生成。	任务需要并行探索多个方向，且合并成本低于串行。	先证明单 Agent 的天花板在哪；否则只是把一次调用拆成三次。
评测集	只有结构校验和人工确认，没有样本跑分。	要改 prompt、换模型、或引入检索时，必须先把评测集建起来。	50 条真实任务样本；指标：事实错误率、结构合法率、延迟、token 成本。
每用户配额	只有认证接口限流，AI 接口没有配额。	服务端开始为用户的 AI 调用付费，或对外开放注册。	按用户按天计数，存数据库；超额返回可读的提示，而不是 429 白屏。

工程

能力	现状	什么条件下值得做	设计要点
插件搬出 popup	填写主流程跑在 popup 里，失焦即销毁。	用户开始在长表单上频繁中断，或者要支持“关掉弹窗后继续填”。	service worker + offscreen document；进度与结果落到 storage，popup 只做展示。
数据库级隔离	共享库表，应用层带 userId 过滤。	有第二个真实用户，或者要对外开放注册。	先加集成测试覆盖越权，再考虑 RLS 或按租户分 schema。
可观测性	requestId + 容器日志，没有链路追踪。	线上问题无法靠日志定位，或者响应时间开始影响体验。	结构化日志；AI 调用记录 provider、模型、耗时、token；错误聚合。
CI 跑测试	CI 只构建镜像，不跑 lint / typecheck / test。	多人协作，或者一次线上事故的根因本可以被 CI 拦住。	先跑最快的单测；迁移检查单独一步；失败不阻断镜像构建，但阻断部署。

为什么写触发条件

“以后会加”是一句没有成本的话，所以它经常变成永远不加。 写清楚“什么条件下加”，有两个好处：到条件时你知道该动手；不到条件时，你能理直气壮地不加。

这个项目里，LangGraph 和 RAG 都属于后者：现在不加，不是因为不会， 而是因为当前任务没有出现需要它们的约束。具体的设计取舍写在 《LangGraph 与 RAG：什么时候该加回来》。