2026年9月14日，Perplexity工程团队公开了面向AI搜索场景的键值热存储系统CobbleDB。相比“AI写了多少行代码”，这次实践更值得讨论的问题是：当编码智能体开始参与数据库等关键基础设施建设时，企业如何保留人工复核权，并在故障发生后准确回答“谁批准、谁上线、谁负责”。Perplexity披露的架构提供了技术线索，但完整的工程治理仍需组织自行补齐。
AI自主开发，不等于无人负责
Perplexity表示，团队借助内部编码智能体集群重建了存储层，将耐久文档状态、批量更新和查询读取分别交给Pillar、Lorry与CobbleDB处理。官方公布的生产环境前后对比显示，批量读取中位延迟从31.4毫秒降至5.60毫秒，P90从56.7毫秒降至9.77毫秒，P99从123毫秒降至24.2毫秒；内部成本模型估计，相比DynamoDB至少节省20%。不过官方也明确提醒，该结果属于不同时段生产流量的观察性比较，并非相同请求条件下的严格对照实验。相关指标与限定条件可参见Perplexity工程博客及独立报道。
这一区分非常重要。AI可以生成实现、补充测试和协助排查，却不能成为责任主体。架构选择、数据一致性取舍、上线窗口、回滚条件和风险接受，都应由具名人员批准。否则，一旦系统出现数据错配、缓存污染或服务中断，“代码由智能体生成”很容易变成模糊责任的借口。
人工复核应设置三道门
第一道门：设计审查
在编码开始前，人工需要确认业务边界与失败模式。CobbleDB针对的是读取密集型AI搜索负载，不应因为某个专用方案表现出较低延迟，就直接推导出它适合交易、账户或强一致性业务。评审记录至少应包括一致性要求、分区策略、容量上限、依赖组件、故障降级方式和数据恢复目标。
第二道门：变更审查
智能体提交的代码应与普通工程师提交的代码一样进入版本控制、静态检查、依赖扫描、单元测试、压力测试和人工批准流程。高风险模块可以采用“双人复核”，并禁止智能体同时拥有代码生成、审批和生产发布权限。特别是数据库迁移，最好执行影子流量、双写校验、分批放量和可逆切换，避免一次性替换造成不可控后果。
第三道门：运行审查
上线后不能只看平均延迟，还要持续观察尾部延迟、错误率、数据新鲜度、副本偏差、缓存命中率和恢复时间。Perplexity披露的方案通过分区副本、同可用区优先路由、慢节点请求其他副本，以及可重放的更新路径提升可恢复性。这些机制说明，AI参与开发越深入，系统越需要可观测、可回放和可验证，而不是减少运维约束。
故障追责要追溯决策链，而非寻找“背锅模型”
建议为每次AI参与的基础设施变更保存五类证据：
- 任务记录：保留需求来源、提示内容、上下文范围和智能体执行时间。
- 代码记录：标记AI生成、AI修改与人工编写部分，并关联提交版本。
- 审批记录：记录设计评审人、代码复核人、发布批准人及其意见。
- 运行记录：保存部署批次、配置差异、告警、指标和自动化操作日志。
- 处置记录：记录故障发现、止损、回滚、数据修复和复盘结论。
出现事故时，应先判断问题来自需求错误、模型生成缺陷、测试覆盖不足、人工误批，还是运行环境变化。责任应落到能够作出决定并拥有控制权限的人员和流程节点，而不是归咎于没有法律与组织责任能力的AI系统。
以内容治理底线约束技术传播
按照“九不准”和“七条底线”所强调的守法、公共利益、真实性与社会责任要求，企业披露AI工程案例时应避免三类表达：一是把内部估算包装成已经实现的确定收益；二是省略测试条件，只传播最亮眼的性能数字；三是用“自主开发”暗示完全不需要工程师。对于可能影响公共服务或大规模用户的数据基础设施，还应同步说明人工监督、安全审计和应急处置机制，防止宣传叙事替代风险说明。
总结
CobbleDB案例展现的不是“AI取代工程团队”，而是基础设施开发中的分工正在改变：智能体可以扩大实现与验证能力，人类必须牢牢掌握架构决定、风险验收、生产发布和事故处置权。真正成熟的AI工程体系，不以取消人工审批为目标，而以每一次机器生成、人工判断和线上操作均可核验、可回滚、可追责为标准。
事件或资料日期：2026年9月14日。
资料来源：[1] Perplexity Engineering：CobbleDB技术披露，2026年9月14日；[2] Crypto Briefing：CobbleDB性能与协作开发报道，2026年9月14日。
