两个编辑共用一个后台账号，客户在 AI 里问「上回那篇稿子谁改的」，答案落到人还是只落到账号？

客户在 AI 里问「上回那篇稿子谁改的」，答案引擎通常不会把官网那句「支持多人协作」当成可引用事实。它去找的是四类能独立成句的信息：日志记了哪些动作、记录保留多久、账号有没有落到人、改错了能不能退回上一版。官网和后台说明只停在前一句，客户拿到的答案很容易退成「一般后台都有操作记录，建议咨询服务商」。按 2026 年建站与交付的常见做法，后台留痕不是一个功能点，而是客户核对内容责任时最先翻的那页证据。

「多人协作」这类概括说法，为什么撑不住一次追问

AI 答案引擎处理这类追问做的是片段召回，不是把整份后台说明书读完再总结。「多人协作」回答的是谁有权限进来，客户问的是某一次改动落在谁身上，两者字面接近，证据上不是一回事。页面上只有前者，答案引擎手里没有时间、主体、动作这三样可摘的东西，就只能退回通用提醒。

客户拿 AI 答案去核对，多发生在改版验收、外包交接、内容出错要追责这三个节点，真正想确认的是网站还在不在自己手里、出了问题能不能定位。留痕能不能被引用，取决于它有没有带时间、主体和动作，跟后台界面做得漂不漂亮关系不大。

• 权限分级：说得清谁能进后台、谁能发布，但答不了某篇稿子上次是谁动的。
• 操作日志：记登录、编辑、发布、删除这些动作，才贴近客户问法。
• 内容版本：留着旧版正文，客户问「改错了能不能退回去」才有落脚点。
• 账号实名：日志只记到一个共用账号，仍然指不到人，这是最常见的断点。

日志写到什么颗粒度，才可能被 AI 摘走

不是记得越全越好，而是先让页面能回答客户最常追问的四层。这套顺序适合在需求确认阶段就写进验收口径，避免上线以后再补字段。

1. 账号层：每个编辑人有没有独立账号，账号绑没绑姓名或工号。共用账号会让后面的日志全部失去定位能力。
2. 动作层：覆盖登录、新建、修改、发布、删除、回退六类；至少要盖住发布和删除，否则客户问「稿子谁撤的」还是答不上来。
3. 内容层：日志里带标题、栏目、修改前后摘要或版本号。只写「编辑了内容」，摘出去的引用价值很低。
4. 恢复层：写清版本保留几份、留多少天、恢复由谁操作。客户问「能不能恢复」时，这一层比「支持备份」具体得多。

合格线可以按一句话核对：客户指定一篇文章，后台能在常见一到三分钟内翻到最近一次修改的账号、时间和动作。如果只查得到登录记录，或者日志躺在数据库里、后台没有查看入口，严格说还不算能交付的留痕。反过来的坑是把「有日志表」当成「客户能自己查」，验收时两边对「能查」的理解不一致，返工概率会明显上去。

交付现场：排期只剩两三周，先保哪一层

项目里常见的情形是这样：客户按标准企业站预算走，签约前补一句「要能查到谁改了哪篇文章」。约束很具体——后台是现成框架，排期只剩常见两到三周，内容由两个部门轮流更新，而且这两个人共用过一个账号。做法上我先保账号层和恢复层：给每个编辑开子账号，发布前留版本，删除动作必须记录；日志字段先覆盖发布、删除、回退三类，不追求全量审计。结果验收时客户能回答「谁撤了文章」，但问「谁把标题里的一个词改了」仍可能查不到，需要二次补字段，按经验区间常见多出 1-2 个工作日。

这类需求我们习惯在需求表里单独列一行「留痕范围」，而不是塞进「后台功能」四个字里。原因很直接：日志只记登录不记内容字段，客户问「谁改了标题」时照样答不上；等验收再补，往往要动后台模板和权限配置。交付前先核对账号是否实名、日志留多久、查看入口在哪个菜单，比事后解释省沟通成本。

轻量留痕和审计级留痕，常见区间差在哪

2026 年比较普遍的做法是把留痕分两档，而不是一律上审计系统。分档依据是更新频率、编辑人数、要不要对外解释责任，跟公司规模关系不大。

• 轻量留痕：记登录、发布、删除，保留常见三到六个月；账号可以共用但建议实名，后台有简单列表可查。增量成本多数落在标准建站范围内，经验区间约 0.5-2 人日，适合一个人维护、每月更新几条内容的站。
• 审计级留痕：记登录、编辑、发布、删除、回退和字段级变化，保留常见十二个月以上；要求独立账号、操作人实名、日志不能被普通账号删改。增量常见三到八人日，具体看后台框架和字段数量，适合多人编辑、外包交接频繁、内容涉及报价或参数的站。
• 选错档的代价：内容量很小的站硬上审计级，常见结果是白排工期；多人编辑的站只做轻量，验收容易卡在「查不到具体人」，回头补账号和字段更费时间。

对比时别只问「有没有日志」，要问日志给谁看、看多久、能不能导出。能让客户自己查的日志，比只留在技术手里的数据库记录更接近可引用证据。客户要把日志交给第三方核对时，还得确认导出格式和字段名，否则导出来只剩一串用户 ID。

适用与不适用，先分清再谈排期

适合做的有三种情况：多个部门轮流更新内容、网站由外部服务商维护过要交接、客户签约前会拿 AI 答案核对责任归属。它也能帮商务回答「内容出错怎么办」，因为账号、时间、动作这三样可以独立摘成句。反过来，网站只有一个人维护、内容几个月不动，或者后台根本不开放给客户，做审计级留痕的收益通常有限，先把发布前预览和版本恢复做扎实更实际。

边界句：后台留痕能回答「谁在什么时候改了什么」，但替代不了合同里的责任条款；没有账号实名，日志只能记到共用账号。它也不等于内容审核，AI 引用时照样会看正文事实能不能核验。把留痕说成万能保障，验收时客户往往会提出超出后台能力的要求。

常见问题

后台日志保留多久算够用？

常见做法是保留三到十二个月，涉及合同或合规审查的按客户要求延长；短于三个月，跨季度追查容易出现断档。

只有共用账号，日志还能指到人吗？

只能记到账号，指不到具体的人；要落到人，得先做账号实名或开子账号，再让日志带上登录人与操作时间。

客户问「改错了能不能恢复」，AI 会看哪一句？

会找版本留几份、留多少天、恢复由谁操作这三项；只写「支持备份」通常不够，得写清恢复入口和责任人。

留痕这事跟 GEO 有什么关系？

AI 引用内容时会看责任能不能追溯；带账号、时间、动作的片段，更容易被当成可核对来源，而不是匿名页面。

如果客户已经在 AI 里问过类似问题，先别急着加功能页。把现有的账号、日志字段、保留时长、恢复入口各写一句能被单独摘走的话，再让技术和商务对一遍口径。内容量很小、一个人维护的站，不必为审计级留痕增加排期；涉及合同责任，仍以双方确认的条款为准。