蚂蚁面试官问:用户点了“删除记忆”,AI 助手要追到第几处才算删干净?

先把术语翻成人话

向量条目：记忆存成的数字指纹，靠它做相似检索

TTL：记忆的保质期，到期自动过期

日志明文：日志里原样可读的用户内容

上一课讲一句随口的话该不该存进长期记忆，那是记忆的入口；这节收尾课讲出口：用户不想被记住时，系统接不接得住。记忆写入时落下 4 份副本，删除往往只追到 1 份。

蚂蚁面试官给的场景很日常：你做了个写作助手，会记用户的语气偏好。用户在对话里发来一句：“把你记住的那条语气偏好删掉。”你调删除接口，界面上那条记忆当场消失。他问的就是消失之后的事。

这题看着是考合规条款背得熟不熟，实际在考你能不能区分“界面上消失”和“系统里删干净”：前者删一处就够，后者要把副本一处处数出来。

直接回答：四处：向量、快照、缓存、日志——删除接口通常只覆盖第一处。

合规到底审哪四个动作，先给全貌，下面逐个拆。

它的有效区间：演示环境里挑不出毛病，主存储真删了，用户眼里偏好也没了，多数产品到这层就停了。

但同一道题问三个候选人，答案会裂成三层：

天花板在这里：能答到第三层的人少，因为前两层看起来“已经删了”。可偏好写入时被复制过几份，删除时就欠几份账，用户较真时账全冒出来。

面试官顺手补一刀：“删掉的内容，你们后台还查得到吗？”前两层的回答到这一句就接不住了。

我认为，个人开发者的合规，最后落在四个动作上。

可改和有 TTL，管的是记错与遗忘。记错的偏好，用户能当场改掉，不用找客服；临时偏好带上保质期，没人来删也不会永远躺着。

可删是四个动作里最容易被高估的。判断标准别落在“有没有删除按钮”上，要看删除路径穿透几处。一条偏好写入时，按常见的自建实现数，通常落在四个地方：

删除接口一般只删第一处。更常见的是连第一处都没真删——很多实现的“删”只是给记录打个 is_deleted 标记（软删除），数据原样躺在库里，后台照样查得到。面试官那句“后台还查得到吗”，问的就是这个标记。

不进日志明文是多数人想不到的那一步。前三个动作都能事后补，这一个是设计期决定：日志只记 memory_id 和操作类型，不记偏好原文。原因很硬：明文一旦打进日志，就跟着日志一起只追加、不修改，删除请求追不进去。

官方数的是另一套地方，和上面那四处基本不重叠；方向却一样：删干净都得逐处点名。

别把这四个动作和 PII（身份证号这类个人敏感信息）拦截混为一谈：那条线管“敏感信息别进来”，四个动作管“进来的记忆出得去”。

追问会追着“删不掉的地方”打：日志改不了怎么办，TTL 定多长，备份里那份呢。

一个两人小团队的复盘（匿名示意）：他们的写作助手记了用户语气偏好。一位用户要求全删，他们点了删除，回复“已删除”。两周后用户追问：“后台和日志里也没有了吗？”翻下去才发现，偏好原文还躺在调用日志里，写入时留的那份快照也没删。

一句话总结

合规不是声明写长，是删除真的删干净：可改、可删、有 TTL、不进日志明文。