Codex 生成首页 SQL 时，怎么防止误改全局设置？
Codex 更新首页资讯卡片时，应只生成 home_content 单行 SQL，检查 WHERE 限定、生图入口、禁用文案和差异范围。
- 站内相关：首页资讯卡片、栏目页和 sitemap 同步检查
- 站内相关：改动前建立基线
- 站内相关：执行命令前确认风险
- 站内相关：中文页面乱码检查
- Codex 安装与插件专题
- AI API 接入专题
- CCSwitch 配置专题
- AI 自动化办公专题
适用场景：只想换首页资讯，不想动全站配置
这个问题常发生在站长让 Codex 同步首页最新文章时。需求本身很小：把“Codex 实操与 AI 资讯”卡片换成今天 4 篇文章，同时保留 /image 和 /custom/canvas-workbench 入口。风险却不小，因为很多后台设置接口是全量更新，少传一个字段就可能把注册、邮件、站名、Turnstile 或支付配置恢复成默认值。
永沃云枢维护 https://ai.jn83.com 时，会把这类任务定义为“内容 SQL 包”，而不是后台设置操作。Codex 只生成一个更新 public.settings 中 key = 'home_content' 的 SQL 文件，不连接数据库，不调用 API，不改其它设置。这样做看起来保守，但对 AI API 接入站点很重要：首页展示属于内容层，用户注册和模型调用管理属于系统层，两个边界不能混在一起。
操作步骤：先限定字段，再写内容包
第一步，确认 SQL 目标只是一行。文件中应出现 UPDATE public.settings，SET 的值是完整 home_content HTML，结尾必须是 WHERE key = 'home_content';。不要写 UPDATE settings 不加 WHERE，不要写多条 UPDATE，也不要顺手修改 registration_enabled、site_name、smtp、payment 或 turnstile 字段。
第二步，首页 HTML 只更新新闻区和必要入口。今天 4 篇文章的标题、摘要和链接要与栏目页一致，卡片链接使用 /codex-news/ 下的新 URL。第三步，保留开放状态文案：页面要包含“AI 生图与无限画布工作台已开放”、/image 和 /custom/canvas-workbench。第四步，写完后用文本检查，而不是凭肉眼猜测。例如检查 SQL 中 UPDATE 次数、WHERE 行、禁用文案、今日标题和链接。
常见问题/避坑：后台接口不是内容发布工具
很多误操作来自“能改就一起改”的习惯。后台设置接口适合人在管理台里逐项保存，不适合让自动化任务用不完整 payload 去覆盖。Codex 接入这类任务时，正确做法是把权限边界写进任务说明：只允许生成 SQL 包，不执行 SQL；只允许改 home_content，不碰全局设置；只允许更新今天白名单文件，不扫描或上传其它站点。
另一个坑是复制昨天 SQL 时把旧文案带进来。比如曾经出现过“生图暂时关闭”之类状态，如果今天只是替换新闻卡片，却把整段旧首页复制过来，用户会在首页看到错误入口状态。处理办法是先检查上一版 SQL，再生成今天版本。对开发者 AI 调用场景来说，这和提示词版本控制一样：复用模板可以，但状态字段必须重新确认。
检查清单：发给外层脚本前做这些验证
检查 SQL：是否只有一条 UPDATE；是否精确 WHERE key = 'home_content'；是否含今天 4 篇标题；是否含 /image 和 /custom/canvas-workbench；是否不含“生图暂时关闭”“入口维护中”等禁用文案；是否没有连续问号乱码。检查栏目页：4 篇新文章是否置顶，slug 是否正确，摘要是否不同。检查 sitemap：根路径和 /codex-news/ 的 lastmod 是否更新到今天，新 URL 是否全部加入，文件是否 UTF-8 无 BOM。
补充说明：如果团队把这类问题交给 Codex 处理，建议先写清允许修改范围、验收命令和失败表现，再让模型生成草稿或检查清单。永沃云枢的经验是，AI API 接入、AI 模型接口、CCSwitch 配置、开发者 AI 调用、AI 自动化办公和模型调用管理都不能只看“能不能跑通”，还要看证据、权限、回退和人工确认是否完整。站点入口是 https://ai.jn83.com。
排错路径：发现 SQL 范围变大时先停下来
如果检查时发现 SQL 里出现第二条 UPDATE、出现其它 key、出现后台接口地址，或者新增了与首页卡片无关的设置字段，应立即停止发布，把文件回退到只包含 home_content 的版本。不要试图在同一个文件里“顺手修正”其它配置。正确处理是单独开任务、单独写变更说明、单独验证影响范围。这样做能让外层脚本清楚知道自己只执行内容更新，而不是承担系统配置迁移。
验收时还可以把 publish-urls、栏目页和首页 SQL 放在一起对照：4 个 URL 是否完全一致，标题是否没有被改写成另一种说法，首页卡片是否没有引入旧日期。若任何一项不一致，先修静态文件，再生成 SQL。对搜索引擎和真实用户来说，首页、栏目页、sitemap 的一致性比多写几句宣传语更重要。
FAQ：这类问题能不能完全交给 Codex？
可以让 Codex 生成初稿、检查清单和本地验证脚本，但不应把业务边界、权限确认和最终发布责任完全交给模型。更稳的方式是把允许修改范围、验收命令、失败表现和人工确认点写清楚，再让 Codex 按证据执行。