# 内容更新与审查生命周期

Codex 的产品界面、模型、权限、工具和外部服务变化很快。Prysai LLM Playbook 必须把“更新”设计成日常流程，而不是版本发布前临时搜索。

## 内容分类

### 稳定知识

例如上下文的重要性、验证的必要性、任务拆解、最小权限、停止条件和证据思维。它们可以长期保留，但仍应通过实践复查。

### 受产品影响的知识

例如 Codex App、CLI、IDE、Cloud、skill、plugin、MCP 和权限模式的当前用法。必须引用官方文档和记录复核日期。

### 高度易变事实

例如模型名称、价格、额度、可用区域、功能入口、命令参数和第三方服务 API。正文不写死，使用“截至日期 + 来源 + 适用范围”，必要时以自动生成的状态页呈现。

## 每条易变事实的最小记录

```yaml
claim: "事实内容"
source: "官方 URL"
checked_at: "YYYY-MM-DD"
applies_to: "产品/版本/地区/账户范围"
owner: "维护者"
next_review: "YYYY-MM-DD"
status: "verified | stale | disputed | removed"
```

## 更新触发器

- 官方文档、发行说明或产品页面发生变化；
- 用户报告章节步骤失效；
- 实验的首次通过率下降；
- 模型或工具输出出现新的系统性失败；
- 许可证、上游仓库或外部依赖变化；
- 组织或团队的安全、品牌或政策变化。

## 审查流程

1. **定位：** 找出受影响的章节、skill、实验和链接；
2. **分级：** 判断是文字、产品步骤、模型事实、许可证还是安全问题；
3. **取证：** 优先读取拥有该事实的官方来源或实际运行结果；
4. **修改：** 更新正文、来源记录、测试夹具和版本说明；
5. **验证：** 运行内容检查、skill 验证和相关实验；
6. **复核：** 由另一位贡献者或新鲜上下文检查是否引入过时断言；
7. **发布：** 记录变更、责任人、复核日期和已知限制。

## 质量门槛

内容更新不能只检查 Markdown 能否渲染。至少要回答：

- 读者是否仍能按步骤完成任务；
- 易变事实是否有当前来源；
- 权限和副作用说明是否仍然准确；
- 实验是否仍然可复现；
- 外部资产归属和许可证是否仍满足要求；
- 章节是否把新功能解释成能力，而不是只增加按钮说明。