Birdor 商业计划书第三十五章：隐私、安全与数据策略

本系列导航

• 上一篇：第三十四章：AI 模型路由与成本控制
• 下一篇：第三十六章：可观测性与 SRE 计划
• 返回目录：Birdor 商业计划书目录

本章关键词

隐私、安全、本地执行、AI 调用、历史记录、敏感数据、API token、审计、数据保留。

适合阅读的人

• 需要理解第三十五章：隐私、安全与数据策略的人。
• 正在把 Birdor 商业计划书转成产品、内容、技术或运营动作的人。
• 希望从 AI 开发者工具平台视角建立系统判断的人。

本章摘要

Birdor 处理的是开发者经常粘贴的技术数据：JSON、JWT、日志、配置、API header、错误堆栈。这些内容可能包含敏感信息。隐私和安全不是附属页面，而是工具体验的一部分。

Birdor 的原则是：能本地处理就本地处理；需要服务器处理时明确提示；需要 AI 调用时单独说明；历史记录由用户控制；团队数据边界清晰。

35.1 数据分类

数据可分为：

• 本地输入：只在浏览器处理。
• 服务器输入：发送到 Birdor 后端。
• AI 输入：发送到模型服务。
• 用户历史：用户主动保存。
• API 请求：通过 token 调用。
• 团队数据：workspace 共享。
• 审计日志：安全和管理事件。

不同数据要有不同保留和处理策略。

35.2 本地优先

JSON format、Base64 decode、Timestamp convert、JWT decode 等基础工具应优先本地执行。页面应明确说明“此操作在浏览器本地完成”。

本地优先能提高速度，也能建立信任。

35.3 AI 调用提示

AI 功能必须单独提示：

• 输入会发送到服务器。
• 可能会发送到模型提供方。
• 不建议粘贴密钥、密码、生产 token。
• 是否保存历史由用户选择。

不要把 AI 调用隐藏在普通按钮后面。用户需要知道数据边界。

35.4 敏感数据检测

Birdor 可以逐步加入敏感字段检测：

• password。
• secret。
• token。
• authorization。
• api_key。
• email。
• phone。

检测不必阻止用户，但应提示风险。

35.5 历史记录策略

历史记录应遵循：

• 默认不保存敏感工具输入。
• 用户主动保存。
• 用户可删除。
• Pro 可提供私密历史。
• Team 历史区分个人和 workspace。

历史记录是留存能力，但不能牺牲隐私。

35.6 API token 安全

API token 需要：

• 只显示一次。
• 可撤销。
• 可命名。
• 可限制 scope。
• 可查看最后使用时间。
• 可轮换。

Team token 还应记录创建者和用量。

35.7 团队数据边界

Team 必须清楚区分：

• 个人历史。
• 团队历史。
• 个人模板。
• 共享模板。
• 个人 API token。
• 团队 API token。

边界不清会带来严重信任问题。

35.8 本章结论

Birdor 的隐私和安全策略应嵌入每个工具页。本地优先、AI 调用提示、用户可控历史、敏感数据提醒、API token 管理和团队数据边界，是开发者工具平台获得信任的基础。

35.9 开发落地清单

第一批安全任务：

• 为每个工具标注 local/server/AI 处理模式。
• 在输入区展示隐私说明。
• 历史记录默认用户主动保存。
• API token 只显示一次。
• 支持 token 撤销。
• AI 调用前展示数据处理提示。
• 对常见敏感字段做轻量提示。

这些能力不需要很复杂，但必须从第一版开始存在。

35.10 安全风险

风险包括默认保存敏感输入、AI 调用不透明、团队数据边界不清、API token 泄露后无法撤销、日志中记录用户原始敏感数据。Birdor 应尽量记录 metadata，而不是记录完整输入。

35.11 验收标准

• 用户知道数据是否离开浏览器。
• 用户能删除保存历史。
• API token 可撤销。
• AI 调用有明确提示。
• Team 数据和个人数据边界清楚。
• 服务日志避免保存敏感原文。

延伸阅读

• AI 时代全球开发者工具平台目录
• 第三十四章：AI 模型路由与成本控制
• 第三十六章：可观测性与 SRE 计划