先跑通一条真实路径，再扩展能力边界
ProfileClaw 的最佳起点不是研究所有端点，而是先完成一条真实工作流：创建 API Key，拉取 context，再按任务需要做最小扩展。
一条推荐路径，三个动作
- 默认 2-call 心智模型
- 从 Context API 开始
- 按需 expand，不要一开始拉满
- 创建 API Key，确认接入身份。
- 调用 Context API，先拿到聚合职业上下文。
- 只在需要时扩展 reasoning、dynamic context 或 webhook。
Recommended Path
五分钟内跑通第一次调用
按这个顺序走，最容易形成正确的产品心智：先身份，再上下文，再任务层。
Step 1 — Create an API Key
先在 Settings 中生成 API Key，让你的 agent 或应用有稳定的身份入口。
Step 2 — Call Context API
把 `/api/v1/context` 当成默认入口。它会先返回足够好的聚合结果。
Step 3 — Expand only when needed
只有在任务真的需要更多结构化信号时，再展开 career graph、dynamic context 或更专门的 endpoint。
Expand Rules
把 expand 当成加法，不是默认值
最常见的错误，是一开始就请求完整对象。更好的做法是：默认小对象，按场景逐步加深。
Default
先不传 `expand`，验证默认上下文是否足够驱动当前任务。
更便宜
更快
更适合大部分推荐与问答场景
Reasoning signals
需要更结构化的职业推理时，再加 `expand=careerGraph`。
可配 `careerGraph=summary`
适合 ranking / explanation
避免一开始 full view
Query-specific memory
只有在当前用户问题强依赖最近记忆时，再加 `dynamicContext`。
适合近期变化问题
可配 `query` 和 `timeRange`
保持 progressive disclosure
Integration Principles
接入原则应该先于端点熟悉度
如果你先掌握这几个原则，后面的 API 面会更容易理解。
Start broad
先从聚合上下文入口开始，不要上来就拆很多细碎调用。
Stay small
默认请求保持最小，只有任务证明需要时才加字段和 expand。
Branch by contract
错误处理、鉴权和 webhook 都按正式契约实现，而不是按猜测。
第一条请求应该尽可能小
默认先拿聚合上下文。这样既能压低成本，也能让后续 decision layer 更稳定。
最小调用
1
curl "https://api.profileclaw.com/api/v1/context" -H "Authorization: Bearer $PROFILECLAW_API_KEY"按需扩展
1
curl "https://api.profileclaw.com/api/v1/context?expand=careerGraph&careerGraph=summary&resumeSkillsLimit=20" -H "Authorization: Bearer $PROFILECLAW_API_KEY"跑通第一次成功后，再往下走
Quickstart 的目标不是教完所有东西，而是让你在最短时间建立正确的 mental model。