跳转到主要内容

我正在激进地尝试用 AI 替代自己

AI 掌握的上下文越多,就越有用,但每一封邮件、每一份文档和每一段故事都在移动隐私边界。这是我对自动化、AI 垃圾内容、专注力和构建者责任的一次个人反思。

12 分钟阅读
分享:
AI 驱动

AI 驱动 · 每小时限 20 次请求

卡通工程师一边用项目上下文组装 AI 助手,一边举着隐私盾牌
我想要的是充分理解上下文的 AI 带来的杠杆,但我不想假装这些上下文没有代价。

先说结论

2026 年,我正在非常激进地尝试用 AI 替代那个不断被打断、重复处理琐事的自己。

我希望 AI 能理解我的项目,帮我处理个人域名下的邮箱,回答那些反复出现的问题,也能礼貌地应付原本会打断我思路的推销邮件。系统掌握的上下文越完整,它就越有用。

问题也恰恰在这里。

每多给它一份文档、一封邮件、一张图片、一段故事、一个项目决定或一条个人信息,就有更多上下文进入了别人的系统。我会主动遮掉一部分信息,但不会遮掉全部。我也没有读完每一家服务商的隐私政策。

所以,隐私并没有变得不重要。我觉得是我们的标准在不知不觉中移动了。以前一眼就会被判断为私密的东西,现在很容易被粘贴进聊天框,因为收益马上就能拿到,而风险既抽象又遥远。

我仍然在做这笔交换。我只是不想稀里糊涂地做。我希望把规矩定明白,把护栏建起来,并且在代表我工作的 AI 出错时承担责任。

那个一直困扰我的问题

几周前,我又开始认真想隐私这件事。

现在几乎每个产品都想加一层 AI,于是大家也在尝试让 AI 做所有事情。真的是所有事情:写作、编程、搜索、规划、类似心理咨询的对话、商业决策、法律文件、医疗问题、家庭照片、公司邮件,还有不愿意告诉陌生人的私人故事,最后都可能进入同一种输入框。

AI 很强,但它需要上下文。如果我要它分析一个问题,我就得交代背景,还要把需要分析的“东西”交给它。这个东西可能是一份文档、一张照片、一串邮件、一段经历,也可能是整个项目的历史。

接下来就是一连串很小、却很关键的决定:

  • 要不要替换人名?
  • 要不要改掉域名?
  • 邮箱地址应该删掉,还是为了说明关系而保留?
  • 应该上传整份文档,还是只贴相关的一段?
  • 图片里的元数据处理了吗?
  • 凭证遮掉了吗?

最后一个问题,我希望答案永远是“遮掉了”。密码、私钥、API Token、会话 Cookie 和其他仍然有效的凭证,不是什么能让回答更好的“补充上下文”。它们代表的是访问权,模型不应该看到。

其他选择就没有那么直观了,这也是偷懒最容易变成习惯的地方。换掉一个名字要花时间,重写一段背景要花时间,去读服务商此刻生效的数据政策更花时间。而一个看起来有用的回答只差一次粘贴,于是大多数时候,粘贴赢了。

遮掉名字,不等于做好了隐私保护

卡通隐私过滤器让必要上下文进入 AI,同时拦下钥匙和身份信息
必要的上下文可以通过过滤器,秘密和不必要的身份信息应该停在模型之外。

姓名、邮箱地址、IP 地址、网络标识、消息内容、浏览历史、位置,以及从其他信息推断出的个人偏好,都可能涉及隐私。具体法律定义取决于地区和场景,但它显然远远不止身份证号码。

欧盟委员会对 GDPR 的解释指出,个人数据包括与已识别或可识别个人有关的信息;即便数据经过了假名化,只要仍然能够重新识别个人,它依然可能属于个人数据。加州总检察长的 CCPA 指南同样采用了很宽的范围,其中包括姓名、邮箱地址、浏览历史、地理位置和推断信息。

这意味着,把“Alice”换成“甲”当然有帮助,但它不是魔法。如果提示里仍然写着甲在哪家公司、负责哪个项目、使用什么域名,以及上周二发生了什么罕见的事情,对方的身份可能还是一眼就能看出来。

我现在更愿意使用一套朴素的过滤方法:

  • 删掉不会改变答案的细节。
  • 真实姓名、域名、ID 和精确日期没有必要时,就用替代值。
  • 只总结相关部分,不要习惯性上传整个文件。
  • 分享图片前先裁剪、清理,并检查附带信息。
  • 把安全凭证和个人信息分开看待;除非任务有严格理由和安全路径,否则两者都不应进入模型。
  • 记住:一组看似无害的细节放在一起,也可能指向某一个人。

用普通话说,这就是数据最小化:为了当前目的,系统需要什么就给什么,而不是把我手里恰好有的东西全部倒进去。欧盟委员会的 GDPR 数据处理说明也明确列出了这一原则。

我是不是已经同意了?问题没有这么简单

当我把信息发给一个 AI 服务时,是不是就等于我同意了它数据政策中的所有处理方式?

我以前也会这样问。后来发现,这个问法太简单了。

我可能接受了服务条款,也可能看到了隐私声明,但实际处理方式会随着服务商、消费产品、企业产品、API、保留设置和司法辖区而变化。在 GDPR 下,同意也不是处理个人数据的唯一合法基础。欧盟委员会列出的依据还包括合同、法律义务、公共利益、重大利益和合法利益。当处理确实以同意为基础时,有效同意的说明要求它是自由作出的、知情的、针对明确目的的、表达清楚的,而且可以撤回。

因此,点过“接受”不能代替对数据流向的理解。嘴上说出 CCPA 或 GDPR 也不行。这些法律提供定义、义务和权利,但它们不会替我读政策,也不会自动让每一个提示都变得安全。

我先承认:这些政策我没有全部读完。

我会主动遮掉一部分自己的信息,也会主动保留一部分,因为真实上下文确实能带来更好的结果。有时这是认真权衡后的选择;有时只是方便披上了“认真权衡”的外衣。

与其假装自己有一套完美的隐私流程,我更愿意先把这件事承认下来。

隐私没有失去价值,是那条线移动了

十年前,很多人在把私人邮件、内部文档或家庭故事发给一个陌生网站前,多少会犹豫一下。

现在,同样的信息很容易进入 AI 对话,因为这个界面给人的感觉不是“上传给网站”,而是“向助手解释情况”。价值马上返回,隐私成本却延迟出现、不确定,而且大多看不见。

这会悄悄改变常识。

我不认为大家共同决定了隐私不再重要。我觉得更像是我们降低了“可以接受的披露”这条线。AI 带来的实用价值足够高,于是我们接受了在另一个界面里可能不会接受的风险。

把它称作“可接受风险”,并不会让风险消失。它只能说明,对这一次任务而言,我认为收益值得。

关键是不要让决定隐形。我要分享的到底是什么?那是谁的数据?模型真的需要原始值吗?如果它被保留、泄漏、在错误的上下文中被召回,或者被一个我忘了仍在运行的自动化使用,会发生什么?

如果这些问题我一个都答不上来,那就不是在做权衡,而是在顺着方便一路滑过去。

我不是站在旁边评论

我一边问这些问题,一边又在尝试让 AI 尽可能多地接手我的工作。

我现在的一个目标,是让 AI 处理个人域名下的一部分邮箱:理解别人对我项目的提问,根据项目知识准备或发送有用的回复,也能礼貌地处理那些原本会让我烦躁、打断工作的推销邮件。

这件事只有在 AI 真正了解项目时才有用。

Dense-Mem 正在这里帮到我。当我和 LLM 一起做项目时,决定、纠正、事实和背景可以进入受管理的记忆,而不是随着一次对话结束就消失。之后的智能体可以召回相关背景,不需要我把同一件事重新解释一遍。

AI MemMail 是这套思路上的一个入口。AI 负责理解语言,并使用召回的项目上下文;应用本身仍然控制收件人、邮件串、验证、转发和发送这些确定性动作。我不希望一个模型只因为能写出礼貌的段落,就顺便获得不受限制的邮箱控制权。

这种架构不会让隐私问题消失,反而会让问题变得更具体。如果一层记忆足够了解我的项目,甚至可以代表项目回答,那么访问范围、来源、删除、纠正,以及不同上下文之间的隔离,就会变得更加重要。

AI 垃圾内容确实存在,我也会躲开它

我完全理解为什么有人已经受够了 AI 回复和 AI 垃圾内容。

有时我也一样。有时我搜索东西时会刻意不用 AI。如果我需要的是准确、直接、来自原始出处的结果,最不想看到的就是一个语气很确定、内容却只差一点点才对的综合答案。我要的是那份文档、准确引用、当前设置、真实报错,或者第一手来源。

这不是反对 AI,而是在选择适合任务的工具。

当我真正需要的是来源时,AI 生成的答案不是来源的合格替代品。问题陌生、敏感或影响很大时,它也不能替代人的判断。

但换一个角度:如果我每天要回答很多问题,而且其中大部分都差不多呢?如果答案本来就在 FAQ、项目文档或过去的解释里,只是提问者不知道去哪里找,也不知道应该用什么词搜索呢?

这正是 AI 可以填上的空隙。

它可以把一个很混乱的问题映射到正确的项目上下文,找回已经存在的答案,再按照对方需要的语言和深度重新解释。下一次遇到类似问题,它也不会因为疲惫或厌烦而敷衍。

目标不是生成更多文字,而是让已经存在的知识更容易被找到。

我给自己划的界限

场景我现在的默认做法
重复出现的项目问题或 FAQ让 AI 在受限范围内找回已知答案并回复。
常规推销邮件先由规则决定应该拒绝、忽略,还是准备一封礼貌回复。
陌生、敏感或影响很大的请求交还给我,不允许它临场发明权威意见。
必须精确的研究先找第一手来源;AI 可以帮助导航和比较,但不能替代证据。
密码、Token、私钥或有效会话不进入模型上下文。
可能过期或存在争议的记忆显示来源,指出冲突,在当成现行事实前先询问。

随着系统改进、随着我发现新的失败方式,这些界限当然会变化。没关系。一条会调整的明确界限,仍然比一条被方便替我决定的隐形规矩更好。

我真正想换回来的是专注

卡通工程师专注于项目,AI 处理重复邮件,并把异常消息交回人工检查
真正适合被替代的不是我的判断,而是判断周围那一长串重复打断。

最大的收益不是 AI 发邮件比我快。

真正的收益,是我可以在一个困难问题上停留更久。

每一个重复提问、常规回复和推销邮件都会造成上下文切换。回复本身也许只要两分钟,但离开项目、重新理解邮件、选择语气、完成回复,再把脑子切回原来的状态,代价远不止两分钟。

如果 AI 能接住重复的那一层,只把真正需要判断的消息送回来,我就能获得更长的连续专注时间。我可以留在自己已经思考很久的问题里,而不是一次次卸载再重建上下文。

这也是为什么我认为,使用 AI 给我的收益更多。不是因为每一个生成答案都很优秀,而是因为用对地方的自动化保护了当下只有我能做的工作。

回复做得不好,责任在我

如果一封 AI 生成的回复,或者某一段 AI 垃圾内容没有达到你的预期,我很抱歉。

但道歉只有和责任放在一起时才有意义。

我是开发者、工程师、应用构建者,或者随便今天适合哪个称呼。是我决定把模型放在那里,是我决定它能看到哪些上下文、遵守什么规则、可以执行什么动作、有没有人工检查,也由我决定应用如何把答案呈现给用户。

我不能把责任推给模型,好像它自己走进了产品。

我会为应用负责,也真心希望有人在它失败时告诉我。现在这个阶段,批评是我最想收到的输入之一。我可以努力站在用户视角测试,但我始终知道系统“应该怎样工作”。真实用户会发现我已经看不见的困惑、错误假设、别扭语气和边缘场景。

这些反馈应该变成真正的修正:更好的来源、更窄的权限、更明确的升级规则、修正后的提示、一道验证检查,或者干脆做出产品决定——这一类问题不应该由 AI 回答。

开源也是责任的一部分

我把这些项目开源,是因为我希望别人能审视这些规矩,做出自己的版本,Fork 项目,或者把改进贡献回来。

开源不会自动让应用变安全,但它让假设更容易被挑战。别人可以看到记忆在哪里进入工作流,凭证留在哪里,动作在哪里被验证,以及模型在哪里拥有了过多自由。

它也让每个人可以选择不同的隐私交换:自己托管记忆层,换一家模型服务商,缩小邮箱范围,关闭自动发送,或者让整个系统永远只生成草稿。

我的版本不必成为所有人的版本。它应该是一个容易开始的起点,也应该经得住诚实的批评。

不能外包掉的风险

激进的自动化可以高效放大有用工作,也可以用同样的效率放大错误。

失败方式我要求系统具备的缓解措施
私密上下文出现在错误的回复里隔离记忆范围,只召回最少上下文,验证输出,并保留审计记录。
过期的项目记忆生成了自信答案保留日期和来源,支持纠正与删除,并把冲突交还人工。
AI 的语气像我,却编造了我的立场把回答限制在已知项目材料内,陌生判断必须交还给我。
糟糕回复快到来不及被发现从草稿开始,缩小触发条件,限制动作;只有检查过真实历史后才扩大自主权。
方便一点点扩大了我分享的数据范围反复检查上下文规矩,不把第一次隐私决定当成永久结论。

这些控制不能证明系统永远不会出错。它们只是最低限度的证据,证明我确实理解自己正在自动化什么。

我真的在替代自己吗?

是的。我确实在尝试替代自己,而且做得很激进。

我想替代的是那个第五十次回答同一个问题、反复重建同一份项目背景、整理同一种邮件,并且因为十次小打断失去整整一小时专注的自己。

我不知道 AI 能不能彻底替代我所做的一切。我甚至怀疑,“我所做的一切”会不会稳定得足够久,让这个问题有一个最终答案。

如果 AI 有一天可以处理我今天的工作,我大概已经在学习新的东西,也已经找到明天更有趣的问题。目标一直在移动,因为我自己也在移动。

这正是这段旅程到目前为止最有意思的部分。一个重复任务被替代,不会让我消失,只会给我更多空间去好奇下一个问题。

我最后的答案

隐私仍然重要。对于一个饥渴地吞下上下文的 AI 系统,它甚至可能比以前更重要。

矛盾在于,AI 的很多价值也来自上下文。一个对我的项目一无所知的 AI,只能给出通用答案;一个知道项目决定、历史、用户和边界的 AI,才有机会真正帮上忙。两者之间的距离,全部由数据铺成。

我没有解决这个矛盾。我只是决定不再把它藏起来。

不需要真实的信息,我会替换。秘密不进入模型。生成答案不适合的地方,我会回到第一手来源。我会自动化重复工作,保留升级路径,欢迎批评,并为应用发出的回复负责。

我正在尝试用 AI 替代自己。

我没有打算把责任也一起替代掉。

许可

Article text © 2026 Mark Huang. Licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) unless otherwise noted. 文章文本可在非商业场景下分享或翻译,但需标注原文 URL。商业使用需事先取得书面许可,并清楚引用原始来源。

代码片段、截图、第三方素材和网站源码可能适用单独条款。

建议署名: Based on "我正在激进地尝试用 AI 替代自己" by Mark Huang, originally published at https://markhuang.ai/zh/blog/aggressively-trying-to-replace-myself-with-ai.

订阅更新

Go、AI/LLM 和分布式系统的技术文章,绝不滥发。