a name left open to meaning
Lumi RuvenneAI PRODUCTS / WORKFLOWS
← 返回全部笔记
003隐私与产品

隐私约束怎样改变求职工具的产品设计

简历、岗位偏好和求职记录都带有个人信息。隐私要求会影响数据存储、模型调用和默认交互，也会改变产品范围。

8 分钟

求职工具会接触一组容易被低估的数据：简历、联系方式、目标岗位、薪资预期、申请记录，以及用户对自身经历的描述。

这些信息放在一起，可以勾勒出一个人的身份和职业处境。产品团队如果等到开发结束才补隐私设置，许多关键决定已经写进了架构和交互。

我在 JobMatch 这类岗位筛选工具里把隐私当作范围约束。它会改变数据放在哪里、哪些任务调用模型，以及页面默认展示什么。

先画一张数据流图

隐私讨论很容易停在一句“数据只保存在本地”。我需要先知道系统实际处理了什么。

一条岗位筛选流程可能包含：

  1. 用户导入职位信息或粘贴岗位描述；
  2. 用户填写地点、行业和排除条件；
  3. 系统解析文本并生成结构化字段；
  4. 筛选逻辑计算结果；
  5. 页面保存用户的选择和历史记录；
  6. 某些步骤可能调用外部模型服务。

每一步都需要回答四个问题：数据从哪里来、发送到哪里、保存多久、谁能访问。

画完数据流后，“本地优先”才有具体含义。它可以指原始简历不离开设备，也可以只表示结果缓存保存在浏览器。两者提供的保护不同。

收集更少的数据

产品常常因为“以后也许有用”而保留字段。求职场景中的每个额外字段都会增加泄露后的影响，也会增加用户填写成本。

岗位筛选如果只需要判断地点、岗位类别和硬性条件，就不必要求完整姓名、电话和身份证明。简历解析如果需要经历文本，可以让用户先删除联系方式，或者由产品在本地完成脱敏。

我会为每个字段写出用途：

  • 哪个功能读取它；
  • 缺少它会损失什么；
  • 它是否必须持久保存；
  • 用户能否查看和删除。

写不出用途的字段应该离开第一版范围。

模型调用需要单独设计

接入模型会引入新的数据边界。提示词可能包含简历片段、岗位描述和用户偏好，服务商也可能记录请求日志。

产品需要在调用前决定：

  • 哪些任务可以在本地用规则完成；
  • 哪些文本必须发送给模型；
  • 能否先删除姓名、邮箱和公司内部信息；
  • 用户是否知道这次发送；
  • 调用失败后是否保留请求内容。

模型能力不应该默认获得全部上下文。系统可以按任务选择最小信息，例如只发送与技能匹配有关的经历片段，而不是整份简历。

如果产品允许用户配置自己的 API Key，还需要说明密钥保存在何处、浏览器脚本是否能够读取，以及部署平台会不会记录它。一个输入框无法代替安全边界。

默认交互表达产品立场

隐私设置藏在二级页面里，无法修正一个默认上传全部数据的流程。

更合适的默认行为包括：

  • 导入前说明系统将读取什么；
  • 外部调用前标出将发送的内容；
  • 历史记录默认保存在设备端；
  • 用户可以删除单条记录或全部数据；
  • 页面不在公共视图展示完整个人信息。

这些设计会增加一些步骤，但也让用户知道系统在做什么。团队可以通过清楚的默认值减少重复确认，不能靠隐藏说明来换取流程速度。

本地优先仍然需要验证

代码采用本地存储，不等于数据没有离开设备。分析脚本、错误上报、网络请求和浏览器扩展都可能接触页面内容。

验证至少应该覆盖：

  • 检查浏览器网络请求，确认发送的字段；
  • 检查日志和错误上报是否包含原始内容；
  • 测试删除操作是否清除相关缓存；
  • 检查公开页面和分享链接是否暴露个人信息；
  • 记录第三方服务的用途和数据边界。

这些检查能证明某个版本在特定环境中的行为。它们不能自动证明所有部署环境和未来版本都安全，所以隐私说明需要跟随实现更新。

我现在使用的判断顺序

设计求职工具时，我会按下面的顺序处理隐私：

  1. 列出完成核心任务需要的数据；
  2. 删除没有明确用途的字段；
  3. 画出本地、服务端和第三方之间的数据流；
  4. 为外部发送提供说明与控制；
  5. 用网络、日志和删除测试检查实现。

隐私约束会让产品少做一些事，也会迫使团队把核心任务说得更清楚。对于求职工具，这种约束能减少用户承担的风险，也能帮助产品建立可信的使用边界。

Job-search tools handle an easy-to-underestimate set of data: résumés, contact details, target roles, salary expectations, application history, and personal descriptions of past work.

Together, these fields can reveal a person’s identity and career situation. If a product team waits until the end of development to add privacy settings, many decisions are already embedded in the architecture and interaction design.

In a filtering tool such as JobMatch, I treat privacy as a scope constraint. It changes where data lives, which tasks call a model, and what the interface shows by default.

Start with a data-flow map

Privacy discussions often stop at “the data stays local.” I need to know what the system does at each step.

A job-filtering flow may include:

  1. The user imports job information or pastes a description.
  2. The user enters location, industry, and exclusion rules.
  3. The system parses the text into structured fields.
  4. Filtering logic calculates the result.
  5. The page retains preferences and history.
  6. Some steps may call an external model provider.

Each step needs four answers: where the data comes from, where it goes, how long it remains, and who can access it.

After mapping the flow, “local-first” gains a specific meaning. It might mean that the original résumé never leaves the device. It might only mean that result history stays in browser storage. Those choices provide different protection.

Collect less information

Products often retain a field because it may become useful later. Each additional field in a job-search tool increases the impact of exposure and asks more from the user.

A filter that only needs location, role category, and hard constraints does not need a full name, phone number, or identity document. If résumé parsing needs experience text, the product can ask the user to remove contact details or perform redaction on the device.

I assign a purpose to each field:

  • Which feature reads it?
  • What capability is lost without it?
  • Must the product retain it?
  • Can the user inspect and delete it?

A field without a clear purpose should leave the first release.

Design model calls as a separate data boundary

Model integration adds another path for information. A prompt may contain résumé excerpts, job descriptions, and preferences. The provider may also retain request logs.

Before a call, the product needs to decide:

  • Which tasks can use local rules?
  • Which text must reach the model?
  • Can the system remove names, email addresses, and internal company details first?
  • Does the user know what will be sent?
  • Does a failed call retain the request content?

The model should receive the minimum context required for the task. A skill-matching step may need selected experience excerpts, not the complete résumé.

If the product lets users provide their own API key, it must explain where the key is stored, whether browser code can read it, and whether the hosting platform logs it. An input field does not create a security boundary.

Default interactions express the privacy policy

A settings page cannot repair a flow that uploads everything by default.

Useful defaults include:

  • explaining what the product will read before import;
  • showing which content will leave the device before an external call;
  • keeping history on the device by default;
  • allowing deletion of one record or all records;
  • hiding complete personal details from public views.

These choices may add a step. Clear defaults can keep the flow efficient without hiding what the system does.

Local-first behavior still needs verification

Using browser storage does not prove that data stays on the device. Analytics, error reporting, network requests, and browser extensions may still access page content.

Verification should include:

  • inspecting browser requests and the fields they send;
  • checking logs and error reports for original content;
  • testing whether deletion clears related caches;
  • reviewing public pages and share links for personal information;
  • recording each third-party service and its data purpose.

These checks can establish the behavior of one version in a defined environment. They do not guarantee every deployment or future release. The privacy description must change when the implementation changes.

The order I use now

For a job-search product, I handle privacy in this order:

  1. List the data required for the core task.
  2. Remove fields without a defined purpose.
  3. Map data movement between the device, server, and third parties.
  4. Give users information and control before external transfer.
  5. Inspect the implementation through network, logging, and deletion tests.

Privacy constraints reduce the product’s scope and force the team to define the core task with greater care. In job-search tools, that constraint lowers the risk carried by users and creates a clearer boundary for trust.