把大模型接到网页后面，可以很快生成一批百科条目；让这些条目持续更新、接受纠错并保留可信的修订记录，却是另一项工程。最新调查称，马斯克推出的 AI 百科项目 Grokipedia 自今年 4 月以来页面更新功能基本停滞，过去三个月没有条目完成更新，用户提交的编辑请求也长期停留在待处理状态。
这件事暴露出的并不只是某个产品的运营问题。对于任何试图构建“AI 版维基百科”的团队，内容生成只是入口，真正决定项目能否存活的是编辑工作流、来源治理、审核能力和可观测性。
百科不是一次性生成任务
普通的 AI 问答可以在请求到达时即时生成答案，百科系统却需要维护一个长期存在的知识状态。一条人物、公司或政策条目发布后，现实世界仍会变化：职位会调整，数字会修订，争议会出现，新来源也可能推翻旧结论。
因此，一个可持续的 AI 百科至少要处理四类事件：
- 定时检查条目的事实是否过期；
- 接收用户提交的修改和证据；
- 判断新来源是否可靠、是否真的支持修改；
- 发布修订，同时保留版本、理由和责任记录。
如果其中任何一环没有足够的自动化或人工产能，系统就会形成队列。队列一旦长期不消费，页面看起来仍然在线，知识库实际上已经停止生长。调查所描述的“无条目完成更新”和“编辑请求长期待处理”，正是比访问故障更难察觉的内容层停机。
AI 能加速编辑，也会放大审核负担
大模型擅长归纳材料、改写段落和生成候选修订，但它不能自动解决来源冲突。两个看似权威的来源可能给出不同数字；一篇新报道也可能只是转述旧消息。模型若直接覆盖正文，错误会快速扩散；若每次修改都交给人工，提交速度又可能远高于审核速度。
更稳妥的设计是把模型放在“提出候选变更”的位置，而不是让它直接成为最终发布者。每次候选变更应至少携带：
- 修改前后的结构化差异；
- 支持该修改的来源及抓取时间；
- 模型对证据充分性的判断；
- 涉及人物声誉、政治、医疗等高风险主题的标记；
- 人工审核或自动发布策略的执行结果。
这种设计不会消除争议，但能让争议变得可追踪。相比一句“由 AI 生成”，读者更需要知道某个句子基于什么材料、何时加入、经过了什么审核。
可以这样实践：给内容更新队列加停滞监控
下面是一个可直接运行的最小监控脚本。这里明确做一个工程假设：百科后台能够定期导出 entries.json，其中包含条目最后更新时间，以及待处理编辑请求的提交时间。脚本不会判断内容是否正确，但能发现“系统在线、编辑流程已经停摆”的情况。
先创建 entries.json：
{
"entries": [
{"id": "mars", "updated_at": "2025-05-01T10:00:00Z"},
{"id": "ai-safety", "updated_at": "2025-06-15T08:30:00Z"}
],
"edit_requests": [
{"id": "edit-101", "submitted_at": "2025-06-20T12:00:00Z", "status": "pending"}
]
}
再保存并运行以下 Python 脚本。运行前可通过环境变量调整阈值：
#!/usr/bin/env python3
import json
import os
import sys
from datetime import datetime, timezone
from pathlib import Path
MAX_ENTRY_AGE_DAYS = int(os.getenv("MAX_ENTRY_AGE_DAYS", "90"))
MAX_PENDING_AGE_DAYS = int(os.getenv("MAX_PENDING_AGE_DAYS", "14"))
def parse_time(value: str) -> datetime:
return datetime.fromisoformat(value.replace("Z", "+00:00"))
def age_days(value: str, now: datetime) -> int:
return (now - parse_time(value)).days
data = json.loads(Path("entries.json").read_text(encoding="utf-8"))
now = datetime.now(timezone.utc)
alerts = []
for entry in data.get("entries", []):
age = age_days(entry["updated_at"], now)
if age > MAX_ENTRY_AGE_DAYS:
alerts.append(f"stale entry: {entry['id']} ({age} days)")
for request in data.get("edit_requests", []):
if request.get("status") != "pending":
continue
age = age_days(request["submitted_at"], now)
if age > MAX_PENDING_AGE_DAYS:
alerts.append(f"stuck edit: {request['id']} ({age} days)")
if alerts:
print("CONTENT PIPELINE ALERT")
print("\n".join(f"- {item}" for item in alerts))
sys.exit(1)
print("Content pipeline is within configured thresholds.")
执行命令：
MAX_ENTRY_AGE_DAYS=60 MAX_PENDING_AGE_DAYS=7 python3 monitor_updates.py
在生产环境中，可以把它接入定时任务和告警平台。更关键的是增加业务指标，例如每日完成修订数、待处理请求的 P50/P95 等待时间、被拒绝修改的原因分布，以及高风险条目的人工复核覆盖率。只监控服务器存活，无法发现内容生产已经归零。
上线 AI 百科前应回答的问题
Grokipedia 的停更报道提醒团队，发布首批页面并不等于建立了百科。正式采用类似方案前，应给出清晰答案：谁对条目的持续维护负责？积压超过阈值时如何扩容或降级？用户能否查看修订状态和拒绝理由？模型、来源规则或审核政策变更后，旧条目是否会重新评估？
还要接受一个现实的权衡：开放编辑能扩大覆盖面，也会引入垃圾信息与协调攻击；高度自动化能提高吞吐量，也可能批量发布同一种错误；严格人工审核能提高质量，却需要稳定、长期的编辑预算。
AI 可以降低撰写候选文本的成本，但百科的核心成本从来不只是写作。持续发现变化、验证证据、处理争议并公开修订过程，才是“可替代维基百科”这一目标中最难复制的部分。