原则一：主动预防而非被动补救

在产品设计初期就嵌入隐私考量，而不是事后打补丁。

这条原则，说白了就是一句话：别等房子盖好了再想着装防盗门。我做了这么多年隐私工程，见过太多团队把隐私当“后期装修”——产品上线了，用户投诉了，监管罚单来了，才慌慌张张地找地方打补丁。结果呢？补丁越打越多，系统越来越臃肿，用户体验也越来越差。

我个人习惯把隐私设计比作“地基里的钢筋”。你盖楼的时候就把钢筋埋进去，成本低、效果好。等楼盖好了再想加钢筋？那只能把墙砸了重来。你想想看，哪个更划算？

为什么“事后补救”总是失败？

我在项目中遇到过这样一个案例：某社交App上线后，发现用户聊天记录被第三方SDK偷偷上传。团队紧急加了个加密模块，但数据已经泄露了。更麻烦的是，加密模块和原有的消息推送系统冲突，导致用户收不到通知。最后花了三周时间重构，还赔了一笔和解金。

为什么会这样？因为隐私问题一旦暴露，往往已经造成了实际损害。事后补救有三个致命缺陷：

• 成本高——改一个底层数据模型，可能影响十几个模块
• 效果差——补丁只能堵住已知漏洞，新漏洞随时出现
• 体验降级——用户突然要同意一堆弹窗，谁受得了？

主动预防的核心：把隐私写进需求文档

我建议团队在启动任何新功能时，先问三个问题：

1. 这个功能需要收集哪些数据？——能不能少收集一点？
2. 数据会流向哪里？——有没有第三方SDK？
3. 用户能控制吗？——能不能让用户自己决定？

这三个问题，应该写在PRD（产品需求文档）的第一页。我曾经见过一个团队，把隐私需求写在了“附录”里，结果开发根本没人看。嗯，这里要注意：隐私需求必须和功能需求同等优先级，不能是“有空再考虑”的事。

实战案例：一个登录功能的隐私设计

举个最简单的例子——用户登录。传统做法是：

// 传统做法：收集所有能收集的信息
function login(username, password) {
    // 收集用户名、密码、设备型号、IP地址、GPS位置、通讯录...
    saveToDatabase({
        username: username,
        password: hash(password),
        device: getDeviceInfo(),
        ip: getIP(),
        location: getGPS(),
        contacts: getContacts()  // 等等，为什么要收集通讯录？
    });
}

你想想看，登录功能真的需要GPS位置和通讯录吗？不需要。这就是典型的“先收集再说”思维。

主动预防的做法是：

// 主动预防：只收集必要信息
function login(username, password) {
    // 只收集认证必需的信息
    saveToDatabase({
        username: username,
        password: hash(password)
        // 设备信息？不需要。位置？不需要。通讯录？绝对不需要。
    });
}

如果后续需要设备信息做安全风控，那也要单独询问用户授权，而不是偷偷收集。我曾经因为一个“偷偷收集IMEI”的SDK，被用户骂上热搜——那滋味，真不好受。

避坑指南：我曾经踩过的三个坑

做隐私设计这么多年，我总结了几条血泪教训：

坑一：依赖第三方SDK的隐私承诺

我曾经接入过一个“安全合规”的统计分析SDK，对方承诺“不收集用户隐私”。结果上线后，发现它偷偷上传了用户的WiFi列表。从那以后，我养成了一个习惯：所有第三方SDK，必须亲自做代码审查。别信承诺，信代码。

坑二：把隐私设计当成“安全团队的事”

很多产品经理觉得：“隐私问题？那是安全团队该操心的。” 大错特错。隐私设计是产品、设计、开发、测试所有人的事。我见过最成功的项目，是产品经理在原型阶段就标注了“此处需用户授权”，设计师在交互稿里画了隐私提示，开发在代码里做了数据最小化。全员参与，才能防患于未然。

坑三：忽视“默认设置”的力量

用户通常不会改默认设置。如果你默认“共享位置”，那99%的用户都会共享。如果你默认“不共享”，那99%的用户都不会共享。所以，默认设置就是你的隐私底线。我建议所有新功能，默认都选“最保护隐私”的选项。用户想开放？让他自己手动开。

主动预防的落地清单

最后，我整理了一份检查清单，你可以贴在工位上：

记住：隐私不是补丁，是基因。从产品诞生的第一天起，它就应该在那里。