admin/SEONexus

Fork 0

Files

root fc61444993 update codex handoff doc after seo pipeline restore

2026-04-16 22:45:57 +08:00

70 KiB

Raw Blame History

1270-SEONexus Codex 多版本协作交接总文档

正式服接手极简版

如果新的 Codex 会话是在正式服或其他机器上接手，而且当前目标是继续追回 GPT 模板深页 seo_copy 资产，先直接执行这一段，不要先大范围自由发挥。

当前共识

GPT 模板结构恢复主线已经跑通
jpjdxs-com 已验证：
- 首页可命中 guide-collection
- 详情页可命中 guide-detail
- 播放页可命中 guide-play
当前仓库内真正已经确认有非 default 深页资产的正式 host，主要是：
- chuanjiafeng-net
- liangzuan-net
- jpjdxs-com
下面这批 host 当前仓库里仍然只是 detail/play default-only，下一步应优先去正式服或其他机器找历史产物：
- pcslcl-com
- lsrxs-com
- lmjcg-com
- nblssy-com

当前 Git 节点

2026-04-16 本轮已经完成一笔主链提交：

commit: 2a905bbf
message: restore gpt seo copy pipeline and stabilize seo tkd output

这一笔提交已经落下的内容包括：

videoGpt1 的 seo_copy 模块重新挂载
VideoService / SiteContext 的 TKD 输出主链恢复
title / keywords / description 输出净化
路由兼容与 slug + id 场景取数修复
DPlayer 容器初始化修复
jpjdxs-com 样本文案回灌
交接文档同步更新

当前提交后的边界

这次提交之后，仓库里仍然保留一批未整理残留，后续接手时不要误判成“本轮漏提”：

其它 videoGpt1 页面模板改动
VideoCategoryModel / VideoModel 的独立改动
seo_copy_release_run.php 等脚本改动
chuanjiafeng-net / liangzuan-net 下的大量生成或回灌数据
code/public/_seo_copy_release/ 下的发布产物

因此后续如果要继续提交，默认进入的是“第二批整理阶段”，不是继续补提第一批主链。

接手后先做什么

按这个顺序：

先看本机目标项目目录下是否存在：
- code/data/seo_copy_published/<host>/detail
- code/data/seo_copy_published/<host>/play
- code/storage/domain_bootstrap_bundles
- code/storage/seo_copy_publish_logs/backups
重点只找两类文件：
- detail/*.json 中非 default.json
- play/*.json 中非 default.json
如果找到真实深页文件，就回灌到：
- code/data/seo_copy_published/<host>/detail
- code/data/seo_copy_published/<host>/play
回灌后必须再做页面验证：
- 详情页是否命中 guide-detail
- 播放页是否命中 guide-play

不要再重复做的事

不要再默认当前开发仓库里一定还有第二份历史资产
不要再把“模板入口丢失”和“深页资产缺失”混成一件事
不要用域名原文去跑目录脚本

例如：

错：--host=jpjdxs.com
对：--host=jpjdxs-com

接手时建议直接回报的最小信息

只要回复这 6 条就够主线继续判断：

当前排查机器名
当前项目根目录
目标 host
是否存在非 default detail/*.json
是否存在非 default play/*.json
回灌后是否命中 guide-detail / guide-play

目的

这份文档用于让多个 Codex 在 SEONexus 新版与旧版本之间长期协作时，保持：

交接清楚
边界清楚
合并节奏清楚
不互相覆盖
不重复试错

适用场景：

你会在正式环境再安装一个或多个 Codex
一个 Codex 主要盯新版优化
另一个 Codex 主要盯旧版本蜘蛛抓取与优化
后续还可能出现第 3 个、第 4 个 Codex

开工约定：

每个 Codex 开始实际工作前，先阅读本文件
没看完 1270 前，不进入代码改动阶段
如有对应专题文档，再继续看 1269 或最近的 production-fix 文档

核心原则

1. 同一时间只优化一份代码

这是最重要的规则。

任何时刻只允许：

新版在优化或
旧版本在优化

不允许两个 Codex 同时分别改两份代码后再互相猜着合。

正确节奏是：

先在一份代码上完成一轮优化
验证通过
合并/同步到另一份代码
再开始另一份代码的分析与优化

2. 另一份代码在未同步最新前，只做“观察”，不做“改动”

如果旧版本还没合并新版最新修复，则旧版本 Codex：

可以看日志
可以写分析
可以整理建议
不能先改一套自己的实现

否则后面很容易出现：

同一问题两边各修一版
路由/模板/观测逻辑走偏
合并时冲突越来越重

3. 新版是主验证场，旧版本是回灌场

除非明确说明某个问题只在旧版本存在，否则默认：

新版先验证
旧版本后回灌

这条规则适用于：

蜘蛛抓取分析
路由兼容
抓取入口修复
sitemap / rss / robots 修复
前端站群 Nginx 动态回源策略

不适用于：

旧模板专属结构问题
旧模板专属页面 bug
旧模板专属样式/模板分支问题

版本边界

新版负责什么

新版主要承担：

SEO 主线优化
蜘蛛抓取分析
新路由兼容策略验证
抓取入口修复
深页 301/404/500 治理
RSS / sitemap / canonical 规范
新功能验证

旧版本负责什么

旧版本主要承担：

已验证能力的回灌
老模板抓取稳定性修复
老模板历史路由兼容
老模板蜘蛛行为观察
老模板入口层与规范层修复

不要让旧版本先承担的内容

这些优先在新版验证，不要先在旧版本自由发挥：

Bootstrap 总控台整条链
站外 SEO 全量工作台
大型后台运营工作流
新模板展示层重构
URL 主输出风格大改

多 Codex 协作角色建议

Codex-A：新版主线 Codex

职责：

新版 SEO 优化
蜘蛛日志分析
路由兼容修复
抓取入口修复
新功能验证
输出可回灌结论

Codex-B：旧版本回灌 Codex

职责：

等待旧版本合并最新版代码
分析旧版本蜘蛛抓取
验证回灌效果
只做老模板特有问题修复
不先发明与新版不同的实现

Codex-C / Codex-D：后续扩展 Codex

职责建议：

专项观察
文档整理
日志归纳
回归验收

不建议一上来让多个 Codex 同时改核心路由/模板。

每次开始工作前必须确认的事项

任何一个 Codex 开工前，先确认以下 8 条：

先看完：

1270-SEONexus-Codex多版本协作交接总文档

当前自己负责的是：

新版还是
旧版本

另一份代码是否已经合并了最新修复
当前轮次是：

观察
修复
回灌
验收

这轮是否允许改代码
是否已有上一个 Codex 的交接结论
本轮修复目标是否只限定在一个主题
当前结论是应该先写本地分析，还是已经可以回流主文档
当前这轮是否涉及多服务器协作，如果涉及，谁是主线收口责任人

例如：

蜘蛛抓取概览
深页兼容
RSS 修复
旧模板入口规范

不要一轮里又修蜘蛛、又修广告、又修 Bootstrap、又补后台工作台。

如果当前是新开会话或新装的 Codex，建议固定顺序：

先看 1270
再看当前阶段执行文档，例如 1269
再看最近一次相关 production-fix 文档
最后再去读代码、日志和本地分析文档

严格边界

1. 不自动跨版本做“顺手修复”

例如当前在旧版本分析蜘蛛问题时，不要顺手：

改新版模板
改新版站外 SEO 面板
改新版 Bootstrap

反过来也一样。

2. 不自动提交

除非用户明确要求，否则：

不自动 commit
不自动 push

先把改动留在工作区，等用户确认。

3. 不整包恢复历史提交

像 22cc72ee 这种历史提交，只能作为：

缺失源码来源

不能整包恢复。

因为这类提交往往还混着：

运行产物
测试数据
storage 输出
临时样板文件

正确做法是：

定点恢复源码
然后继续冒烟验证

4. 不在两个版本上同时独立发明方案

例如：

新版把深页兼容做成 A
旧版本同时自己做成 B

这是最容易制造后续冲突的做法。

本轮关键经验补充

这一节记录 2026-04-16 这轮 videoGpt1 恢复与排障中已经确认的高价值结论。

后续任何 Codex 如果再遇到：

GPT 模板首页/详情/播放页引导文突然消失
分类首页、榜单列表、搜索页突然 404 或系统错误
某些域名正常，某些域名不正常

请优先先看这一节，再决定是否继续深挖。

1. 不是所有“页面丢内容”都是数据库问题

这轮已经确认，GPT 模板前面做过的引导文、补料、搜索引导、详情引导、播放引导，并不一定是数据库被删。

更常见的真实原因有 3 类：

模板文件被较轻版本覆盖
路由把请求导错了模板
服务层类型约束变严后，旧模板传空值直接报错

所以不要一看到：

title 空了
引导文没了
分类页报错
搜索页 404

就直接判断成：

seo_key 丢了
数据库被覆盖了
AI 生成没执行

正确顺序应该是：

先看实际命中的模板
再看实际命中的路由
再看服务层是否因为 null / '' 被强类型拦截
最后才去怀疑数据层

2. GPT 模板当前已确认恢复的主线页面

这轮已经恢复并验证通过的页面包括：

首页引导层
详情页引导层
播放页引导层
分类首页
一级分类页
二级分类页
榜单首页
榜单列表页
搜索结果页
历史记录页

其中首页、详情页、播放页的引导层恢复，不是只在一个域名生效，而是已经按多种路由家族做过抽查。

3. 本轮确认过的三条高频根因

根因 A：模板层被“轻量 seo_copy include”替换后，深页补料不再显性输出

现象：

首页还有一点东西
详情页/播放页引导感明显变弱
页面不报错，但前面测试过的引导文 UI、卡片、提示区块明显没了

结论：

不是整套模板消失
是 richer 版本页面级引导层退化成了轻量 include

处理原则：

优先从历史 git 内容里恢复页面级引导结构
不要简单再重写一套全新的风格

根因 B：路由注册错位，页面请求被导到了错误模板

本轮已确认过两个典型错位：

category_home 错导到 video/getCategory.html
rank_list 错导到 video/getRankIndex.html

后果：

分类首页会拿分类列表模板跑
榜单列表会拿榜单首页模板跑
页面可能有 title，但正文报 系统发生错误

处理原则：

先检查 code/app/home/config/router.php
再确认当前 page code 应该落到哪一个视图

根因 C：服务层 URL 方法后来加了强类型，旧模板空参数直接炸

本轮确认过的典型报错：

getVideoCategoryIndexUrl(): Argument #1 must be of type string, null given
getVideoRankUrl(): Argument #1 must be of type string, null given

这类问题的本质不是业务逻辑坏了，而是：

模板原来允许空值
服务层后来把参数收紧成强类型
一些分类首页 / 榜单页 / 空场景入口就直接报错

处理原则：

先恢复服务层对 null / '' 的兼容
不要先大面积改模板传参

原因很简单：

兼容服务层后，多个模板家族都会一起恢复
如果只修模板，很容易这里修好，别处再炸一个

4. `.html` 冻结路由是 GPT 新路由分支的重点兼容项

这一条非常重要。

当前 videoGpt1 不是走旧模板那套通用路由，而是走前面的 GPT 新路由分支，并且中途会直接 return。

这意味着：

后面的旧版搜索/历史等通用路由根本不会执行
任何冻结 family 里定义的搜索、历史、分类、榜单入口，都必须在 GPT 新路由分支里完整注册

本轮已确认一批域名使用：

get.html
record.html

这类带 .html 的冻结路径。

如果 GPT 新路由只按普通字符串注册，而不补 ->ext('html') 兼容别名，就会出现：

无点路径域名正常
.html 路径域名全部 404

这轮已经验证通过的 dot-family 域名包括：

chuanjiafeng.net
lcdchq.com
lgyz.net
oronorent.com
sdxhtgcl.com

这些域名现在都已经确认：

/get.html?keyword=test 正常返回搜索结果页
/record.html 正常返回历史记录页

5. 以后排查顺序建议

如果后面 снова 遇到 GPT 模板页面回退、404、搜索失效、分类页异常，优先按这个顺序：

看当前域名 theme_cache 里的 url_family
看该路由在 code/app/home/config/router.php 是否注册到正确视图
看是不是 .html 冻结路径
看服务层 URL 方法有没有因为 null 参数炸掉
看页面实际 HTML 是否已经命中 guide-collection / dm-desc-guide / guide-play
最后再怀疑数据层或 AI 生成层

不要一开始就：

回滚整仓
重建全部 SEO 数据
重新写一套模板

这样很容易把已经修好的主线再覆盖掉。

本轮主线可复用修复

以下内容属于“主线可复用修复”，后续如果旧版本或其它服务器出现同类问题，可以优先对照吸收：

路由层

category_home 应落到 video/getMap.html
rank_list 应落到 video/getRankList.html
带 .html 的冻结路径需要补无后缀 ext('html') 兼容别名

服务层

getVideoCategoryIndexUrl() 需要兼容 null
getVideoRankUrl() 需要兼容 null

模板层

首页需要有显性导览区，不要只剩纯卡片瀑布流
详情页需要保留剧情说明 + 延伸词入口 + 播放跳转提示
播放页需要保留当前线路 / 当前剧集 / 返回详情页 / 观看建议

交接提醒

后续 Codex 如果接到类似任务，请先确认：

当前问题到底是模板退化、路由错位，还是类型约束报错
当前域名是否使用 .html 风格冻结搜索/历史路由
当前问题是否已经在新版主线修过，可以直接回灌而不是重做

如果是同类问题，优先复用本轮思路，不要再重新设计一套实现。

SEO 文案发布层特别注意

1. 不要把“页面退化”直接等同于“模板被回滚”

videoGpt1 这类模板里，页面最终看到的引导文、补料、差异化说明，至少分成两层：

模板层是否还渲染对应区块
seo_copy_published 是否真的存在细粒度发布结果

如果模板还在，但 seo_copy_published/<host>/detail 和 play 下面只剩：

default.json

那么前台虽然还能出内容，但只会退回默认文案，不会再有：

单视频差异化文案
单播放页差异化文案
之前那种“每个域名、每个页面不完全一样”的细粒度表现

也就是说：

页面看起来像“前面的优化没了”
不一定是模板没了
很可能是发布层退回默认版了

2. 当前仓库已经确认的事实

在 2026-04-16 本地排查中，已确认：

code/data/seo_copy_published 共 27 个域名
27 个域名全部只有 detail/default.json
27 个域名全部只有 play/default.json
没有任何 detail/<video_id>.json
没有任何 play/<video_id>-play-<type>-<index>.json

这说明当前仓库里的“已发布文案目录”本身就是默认版，不是单个页面偶发异常。

3. 审计命令

后续任何 Codex 遇到“差异化文案是不是又丢了”时，先跑：

php code/scripts/seo_copy_published_audit.php --format=text

按域名单查：

php code/scripts/seo_copy_published_audit.php --host=lmjcg-com --format=text

带样本页检查预期 key 是否存在：

php code/scripts/seo_copy_published_audit.php \
  --host=lmjcg-com \
  --sample-detail=76310 \
  --sample-play=76310:default:1 \
  --format=text

如果输出里看到：

detail_default_only: yes
play_default_only: yes
expected_checks ... exists=no

就说明问题在发布层，不要先去重写模板。

4. Git 历史判断规则

如果怀疑是 git 覆盖导致退化，优先同时检查两块：

模板源码历史
code/data/seo_copy_published 历史

这次已经确认：

模板关键文件并没有发生整包回滚到很老版本
但 code/data/seo_copy_published 当前提交内容本身就是 default-only 版本

所以后续排查顺序应固定为：

先审计 seo_copy_published
再确认模板区块是否还在
最后才决定是否需要从历史发布批次恢复细粒度文案

5. Git 推送只能使用 `www` 用户

这是当前机器的固定约束，不要忽略。

原因：

root 用户可以排查问题、读日志、跑测试
但 root 没有 origin2 的可用 SSH 私钥
www 用户已经配置好可用私钥，且已验证可正常推送到 origin2

因此后续所有 Codex 都必须遵守：

可以用 root 做分析、读取、验证
一旦涉及 git push，只能切到 www
不要再直接用 root 执行 git push origin2 dev

标准推送命令：

su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus push origin2 dev'

如果需要先查看状态，也建议保持同一口径：

su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus status'
su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus log --oneline -n 3'

已验证结论：

root 推送会报 Permission denied (publickey...)
www 推送 origin2 正常成功

所以这不是代码问题，也不是远端仓库问题，而是当前机器上的 Git 身份边界。

5.1 仓库 ownership 也必须保持 `www:www`

除了 git push 只能使用 www，当前机器上还要额外遵守一条：

SEONexus 仓库目录本身也必须保持 www:www

尤其不能让下面这些路径长期混入 root:root：

.git
.git/index
.git/objects/*
docs/
其它会被 git pull / git checkout 自动写入的目录

已经验证过的真实故障现象包括：

error: insufficient permission for adding an object to repository database .git/objects
fatal: failed to write object
fatal: unpack-objects failed
error: unable to create file docs/...: Permission denied

这类问题的根因不是远端仓库异常，而是：

前面曾用 root 对仓库做过 commit、写文件或目录创建
导致 www 后续执行 pull / push / stash 时权限链断掉

因此后续建议固定为：

与 Git 直接相关的操作优先都用 www
root 只做日志排查、系统命令、权限修复
不要再用 root 在仓库里直接 commit、pull、push

如果已经出现 ownership 混乱，优先修复命令为：

chown -R www:www /www/wwwroot/diff-maccms/SEONexus

如果只是 .git 或仓库内同步文档目录出错，也至少要修：

chown -R www:www /www/wwwroot/diff-maccms/SEONexus/.git
chown -R www:www /www/wwwroot/diff-maccms/SEONexus/docs

这条规则和“只能 www 推送”应视为同一组约束，不能只做一半。

6. `SEONexus` 与 `SEONexusAdmin` 是同机双仓协作

当前机器上：

SEONexus
SEONexusAdmin

都位于同一台机器的 /www/wwwroot/ 下。

这意味着：

它们适合联合排查
但仍然是两个独立仓库
不能因为同机就默认一起改

推荐理解方式：

SEONexus 主要负责后端接口、路由、helper、model、日志、返回结构
SEONexusAdmin 主要负责前端页面、接口调用、参数、token/header、错误展示
Nginx / 域名 / 反代 / CORS / 登录态链路属于同机环境层

因此遇到后台报错时：

可以跨仓一起查
但修复时先判断主战场
一轮优先只改一个主仓

例如：

如果是接口 500、类缺失、helper 丢失、路由没挂，主战场通常是 SEONexus
如果是 axios 参数、header、token、前端展示层误报，主战场通常是 SEONexusAdmin
如果是跨域、代理、cookie、header 丢失，主战场通常是 Nginx / 反代配置

这条规则的核心不是“分开”，而是：

同机便于联查
分仓便于控边界

7. 不建议现在把所有项目硬并成一个 Git 仓库

当前更适合的结构是：

多个独立 Git 仓库
通过仓库内 doc/ 文档同步协作规则
通过明确边界控制多 Codex 并行协作

不建议现在把所有项目直接并成一个大仓，原因包括：

SEONexus、SEONexusAdmin、node 工具链、蜘蛛代理脚本、历史参考目录，生命周期并不一致
不同项目的提交节奏不同，强行并仓后日志会很乱
后续回滚、比对、定向发布会更重
正式服未必需要开发机当前的总目录结构
现在真正需要同步的是规则和关键文档，不是把所有杂项目录绑成一个提交历史

当前阶段更推荐：

业务主仓继续独立维护
关键协作文档同步到主仓的 doc/
需要跨仓排查时，通过文档说明目录关系和排查顺序

只有在未来满足以下条件时，才考虑是否要做 monorepo：

多个仓长期高度耦合
发布必须严格同版本号
CI/CD 也准备统一
权限、分支策略、回滚策略都已经设计清楚

在当前阶段，最稳的结论是：

不要把所有项目硬归成一个 Git
先把“协作规则归一、文档入口归一、推送口径归一”做好
这样收益更大，风险更小

8. 本轮 GPT 模板“像被覆盖了”的根因结论

这条是 2026-04-16 本地持续排查后新增的强结论，后续 Codex 看到“首页 title 变空、引导文没了、播放页像退回毛坯版”时，先按这里理解，不要再一上来误判成“整个 GPT 模板被回滚没了”。

8.1 早期 GPT 模板主骨架其实还在

从 git 历史看，真正把 videoGpt1 模板做起来的关键提交主要是：

eb8c0977 gpttemp，2025-12-31
90fc16fb gpt，2026-01-09
04f303ca index，2026-01-10
e23bf61f indextitle，2026-01-10

这些提交当时一起改了：

code/app/home/view/videoGpt1/...
code/app/services/VideoService.php
code/app/services/SiteContext.php
列表、评论、播放、详情等页面层

因此本轮看到的退化现象，不应直接理解成“那批 GPT 模板代码整包没了”。

8.2 真正可疑的覆盖点在 `origin2/dev`

当前分支关系已确认：

origin/dev 停在较早位置
origin2/dev 比 origin/dev 多出一整串后续提交
其中与这次问题最直接相关的关键提交是：
- 887e9528 debug，2026-04-14

这个提交做了一个非常关键的动作：

首次把 code/data/seo_copy_published 批量纳入 git
但纳入的内容是低覆盖版本
对 27 个域名来说，detail / play 基本只有 default.json
没有原先那种按视频 id、播放线路、集数拆开的细粒度深页发布结果

8.3 所以当前更像是“发布数据覆盖”，不是“模板源码被删”

更准确的判断应该是：

模板骨架大部分仍在
theme_cache 和模块布局大部分仍在
但是模板后续开始接入 seo_copy 后，读取到的是 default-only 的发布产物
于是原先更细的深页引导文，被统一的默认文案层盖平

用户体感上就会变成：

差异化引导文没了
页面排版味道变弱了
看起来像之前做过的 SEO 优化都被抹掉了

8.4 当前已锁定的责任边界

后续排查和恢复，优先按下面结论执行：

origin/dev 不是这次 seo_copy_published 覆盖的主要来源
当前已知问题链，主要来自 origin2/dev 这一串后续提交
其中 887e9528 debug 是这次“深页差异化内容退化”的关键观察点
bd073c67、7fff1a99 主要修路由、id-first、helper 恢复，不是这次内容退化的首因

8.5 恢复优先级

既然根因更偏向“发布数据被低覆盖版本顶掉”，恢复顺序必须固定为：

先恢复历史深页 seo_copy 发布数据
再验证模板区块是否需要微调
最后才考虑是否补新的内容生成

这一条必须强调：

优先恢复历史已验收资产
不要先用新的通用 AI 文案把旧资产覆盖掉

否则会继续出现：

页面能显示
但和之前测试通过的那版体验不一致
用户感觉“怎么又被重新写坏了”

工作顺序标准流程

场景 A：新版先优化，旧版本后回灌

新版 Codex 分析问题
新版 Codex 实施修复
新版验证通过
文档记录“哪些能力适合回灌旧版本”
旧版本合并最新代码
旧版本 Codex 开始观察与回灌验证
只补旧模板特有问题

场景 B：旧版本先发现问题

先判断该问题是不是旧模板专属
如果不是旧模板专属，先回新版验证
新版验证后再回灌旧版本
如果是旧模板专属，再只在旧版本修

哪些优化适合回灌旧版本

适合

这些通常适合回灌：

蜘蛛抓取日志分析
抓取概览工作台
robots.txt 修复
rss/baidu.xml 修复
sitemap 修复
canonical 规范
历史 detail/play/category 路由兼容
深页 404/301 治理
前端站群 Nginx 统一动态回源策略

慎回灌

这些要单独评估：

坏链随机视频兜底
播放页 SEO 策略大改
URL 主输出规则变更
复杂站外 SEO 面板
导入健康台全家桶
Bootstrap 总控台整条链

多 Codex 的交接模板

每个 Codex 每轮结束时，至少留下以下内容：

1. 本轮工作对象

新版 / 旧版本
目录路径
当前分支

2. 本轮目标

例如：

修复百度深页 301 -> 404
验证旧模板蜘蛛抓取概览
补回 rebase 丢失 helper

3. 本轮已改动文件

必须列路径。

4. 本轮未提交改动

说明是否：

仅工作区修改
已暂存
已提交但未 push

5. 本轮验证结果

至少说明：

哪些通过
哪些没通过
哪些未验证

6. 下一位 Codex 的注意事项

必须写明：

不要碰哪些文件
先看哪个文档
下一个最值动作是什么

文档同步规则

每轮有效优化后，至少同步两类文档中的一种：

1. 主题执行文档

例如：

1269-SEONexus-老模板第一阶段回灌执行文档

适合记录：

旧模板回灌目标
分阶段策略
验收口径

2. Codex 交接总文档

也就是当前这份文档，适合记录：

协作规则
边界
交接模板
多版本协作方法

如果后续发现某条规则经常踩坑，就更新本文件，不要只留在聊天记录里。

3. 单次线上事件排障文档

这类文档适合记录：

某一次正式服报错的完整排查过程
问题阶段
根因
线上改动
验证结果
下一位 Codex 的接手建议

当前已沉淀样例：

2026-04-16-admin2-spider-workbench-production-fix.md

使用原则：

1269 这类文档负责阶段执行
1270 这类文档负责长期协作规则
2026-xx-xx-...production-fix 这类文档负责单次线上事件闭环

这样后续主 Codex 接手时：

先看长期规则
再看当前阶段执行文档
最后看最近一次线上事件文档

就不会只靠聊天记录反推上下文。

4. 项目本地持续分析文档

除了需要进入 Git 的正式文档外，每个项目还允许保留一套“只服务当前项目持续优化”的本地分析文档。

这类文档推荐放在项目自己的：

code/storage/_analysis/

使用原因：

每个项目都有自己的蜘蛛日志来源、观察窗口和异常轨迹
这类分析如果完全不记录，后续优化容易断档
但如果全部提交进 Git，又会把大量过程性观察和未确认判断写进正式历史

因此这类文档的定位是：

允许持续记录
默认不提交
以项目私有观察为主
适合记录尚在观察期的中间结论

推荐最少按两层组织：

code/storage/_analysis/sources/
code/storage/_analysis/domains/

例如：

code/storage/_analysis/sources/baiduspider.md
code/storage/_analysis/sources/sogou.md
code/storage/_analysis/domains/sjzyunyang.com.md
code/storage/_analysis/domains/jingxifa.com.md

边界规则：

可以在每个独立项目里持续写自己的分析文档
也允许每个独立项目优化“本项目私有层”
但不建议每个项目独立发明一套公共核心方案

也就是：

项目私有观察可以分散记录
公共核心方案仍应集中验证、集中沉淀、再回灌

5. 本地分析必须回流主文档

code/storage/_analysis/ 只负责本地持续观察，不应成为最终知识沉淀的终点。

只要本地分析满足以下任一条件，就必须再整理回主文档：

已确认根因
已验证修复有效
结论能跨机器复用
结论能跨模板族复用
结论能减少其它 Codex 的重复劳动
结论会影响协作边界或排查顺序

推荐回流判断方式：

如果只是某台机器、某个时间窗口的临时观察，可以先留在 storage/_analysis/
如果已经形成“别人以后不用再重新验证”的结论，就应升级到 SEONexus/docs/

推荐回流路径：

全局协作规则 -> 1270
阶段执行 / 回灌策略 -> 1269
单次正式服事件闭环 -> 2026-xx-xx-...production-fix.md
其它模板族或专题结论 -> 对应专题正式文档

这条规则的目标是：

本地分析负责探索
主文档负责共享
不让每台机器都重复学习同一件事

6. 多服务器可以并行分析，但主线应单点收口

允许多台服务器同时进行：

日志分析
外网复测
各自写本地 storage/_analysis
提交各自的中间结论

但不建议多台服务器同时直接改同一个主线核心方案。

推荐规则：

本地分析可以并行
主线代码修改尽量单线
正式共享文档尽量单一主责任人收口

尤其是以下内容，不建议多台机器同时独立改：

深页兼容核心逻辑
路由兼容总逻辑
404 / 500 兜底主链
蜘蛛抓取核心统计逻辑
同一份正式共享文档

更稳的协作方式是：

多台机器并行做观察
各自把中间结论写到本地分析
主 Codex 统一判断哪些结论已经收敛
由一个主责任人修改主线代码或更新正式共享文档

这条规则的目标是：

允许大家同时学习
避免大家同时改乱主线

特别注意事项

1. 前端 Nginx 不要继续按 URL 模板枚举

前端站群应坚持：

静态资源缓存
非静态请求 MISS 后统一回后端

不要每新增一种 URL family，就去补前端 Nginx 前缀。

2. 旧版本不要轻易改主输出 URL 风格

旧版本更适合：

加兼容层
不推翻当前主输出

3. 观测和修复要分开记录

不要把：

日志观察
推测
已验证修复

写混。

4. 真实缺失源码与 CLI 冒烟假阳性要区分

像之前的：

Class not found
路由没挂
helper 丢失

这类是真缺失。

但像：

Undefined array key 9999

在 CLI 直接调控制器时，可能只是 admin 配置上下文不完整，不一定是真缺源码。

最后的工作纪律

多个 Codex 长期协作时，最重要的不是“每个都很聪明”，而是：

同步节奏一致
边界清楚
不抢改
不乱回滚
不各自发明一套实现

只要坚持这几条，后面就算扩到 3 个、4 个 Codex，也仍然能稳。

videoGpt1 页面来源地图

videoGpt1 当前页面体验，不是由单一模块决定，而是至少由下面 4 层共同组成：

1. `theme_cache`

位置：

code/storage/theme_cache/<host>.json

作用：

域名级 seed
dom_prefix
页面模块顺序
首页 / 分类 / 详情 / 播放的布局参数
标题文案槽位
URL family

判断：

这是 GPT 模板“每个域名看起来不一样”的核心来源之一
当前排查中，这一层没有整体丢失

2. 模板原生结构

位置：

code/app/home/view/videoGpt1/...

作用：

页面骨架
标题样式
meta 栏
行为按钮
播放器外壳
列表结构

详情页主链：

video/getVideoInfo.html
module/page/page_router.html
module/detail_main/detail_main_router.html
module/detail_main/layout/layout_B.html

播放页主链：

video/getVideoPlayUrl.html
module/page/page_router.html
module/player/player_router.html
module/player/engine/dplayer.html

3. `seoaddon`

入口：

module/detail_main/desc.html
{video:seoaddon ... /}
module/detail/_seo_addon.html

后端：

code/app/services/VideoService.php
code/app/common/helper/SiteStyle.php

作用：

详情页摘要
标签
提示语

判断：

这是原始 GPT 模板的重要组成部分
不是后加的统一卡片层

4. `seo_copy`

入口：

首页：index/index.html
详情：module/detail_main/desc.html
播放：video/getVideoPlayUrl.html

模板：

module/seo_copy/collection.html
module/seo_copy/detail.html
module/seo_copy/play.html

后端：

VideoService::getSeoCopyBlock()
SeoCopyStore

作用：

补充说明
FAQ
guide cards 卡片

判断：

这是后加层
不是原始 GPT 模板的主体

当前恢复策略

为了尽量恢复到前面测试通过时更接近的 GPT 模板体验，当前策略如下：

1. `site:seotkd` 不允许输出空 TKD

位置：

code/app/services/SiteContext.php

兜底顺序：

新 GPT SEO 池
旧 SubjectFormat key
domain 表字段

目标：

不再出现空 title
不再出现空 keywords
不再出现空 description

2. `detail` / `play` 页面不强行渲染 default-only `seo_copy`

位置：

code/app/services/VideoService.php

原因：

当前 code/data/seo_copy_published 中 27 个域名的 detail 和 play 全部只有 default.json
同时 module/seo_copy/detail.html / play.html 是统一卡片式输出
这会让详情页和播放页迅速退化成“通用说明卡片”

处理：

如果详情/播放页没有命中具体 page key
只命中 default
就先不渲染这一层

目标：

页面重新回到 theme_cache + 模板原生结构 + seoaddon 主导
尽量靠近之前 GPT 模板实测通过时的观感

当前判断顺序

如果用户反馈“前面做好的 GPT 模板体验又没了”，应按以下顺序排查：

看 title/keywords/description 是否为空
看 theme_cache 是否还在且命中正常
看详情 / 播放页是否只剩 default-only seo_copy
再判断是否真的发生过模板 Git 回退

不要先入为主认定“全部是 Git 覆盖”，因为当前更明显的现象是：

域名级模板差异仍在
seo_copy 深页细粒度内容缺失
叠加 TKD 取值异常后，页面体感会明显变差

2026-04-16 深页 `seo_copy` 恢复验证结论

已验证结论

本地仓库内，细粒度 detail/play 文案并不是“从未存在”，而是：

以前真实生成过
历史备份仍然存在
当前生效目录退回成了 default-only

可追溯来源主要包括：

code/storage/seo_copy_publish_logs
code/storage/domain_bootstrap_bundles
code/storage/seo_copy_batch

已完成样本恢复

1. `chuanjiafeng-net`

恢复来源：

code/storage/domain_bootstrap_bundles/chuanjiafeng-compact/data/seo_copy

恢复结果：

detail_default_only: no
play_default_only: no
detail: total=17, default=yes, non_default=16
play: total=17, default=yes, non_default=16

样本核验：

detail | key=154229 | exists=yes
play | key=154229-play-douban-1 | exists=yes

2. `liangzuan-net`

恢复来源：

code/storage/domain_bootstrap_bundles/liangzuan-next-stage-b1/data/seo_copy

恢复结果：

detail_default_only: no
play_default_only: no
detail: total=1, default=no, non_default=1
play: total=1, default=no, non_default=1

样本核验：

detail | key=154124 | exists=yes
play | key=154124-play-youzhi-1 | exists=yes

已新增恢复脚本

脚本位置：

code/scripts/seo_copy_restore_from_source.php

用途：

从历史来源目录恢复某个 host 的 detail/play 深页 JSON
支持先 --dry-run
支持指定 --host
支持指定 --source
默认写入 code/data/seo_copy_published

示例：

php code/scripts/seo_copy_restore_from_source.php \
  --host=chuanjiafeng-net \
  --source=code/storage/domain_bootstrap_bundles/chuanjiafeng-compact/data/seo_copy \
  --dry-run

正式写入：

php code/scripts/seo_copy_restore_from_source.php \
  --host=chuanjiafeng-net \
  --source=code/storage/domain_bootstrap_bundles/chuanjiafeng-compact/data/seo_copy

批量恢复原则

不要直接对全部 27 个域名做无差别恢复，推荐顺序：

先做单域名样本恢复
恢复后立刻跑审计
确认该域名前台表现符合预期
再决定是否扩大到更多真实域名

原因：

不同域名的历史覆盖程度不同
有的来源完整，有的来源只有 1 组样本
有些 bundle 是测试/并发演练产物，不适合无脑全量导回

2026-04-16 当前 27 域名可恢复性分层

按本地仓库现状盘点：

A. 已完成样本恢复

chuanjiafeng-net
- 当前生效：detail 非默认 16，play 非默认 16
- 最优来源：code/storage/domain_bootstrap_bundles/chuanjiafeng-compact/data/seo_copy/chuanjiafeng-net
- publish_logs 也存在历史样本：11 + 11
liangzuan-net
- 当前生效：detail 非默认 1，play 非默认 1
- 最优来源：code/storage/domain_bootstrap_bundles/liangzuan-next-stage-b1/data/seo_copy/liangzuan-net
- publish_logs 也存在历史样本：1 + 1

B. 当前仓库内暂未发现可恢复深页来源

以下域名在本地盘点时：

domain_bootstrap_bundles 中未发现可用 detail/play 深页 JSON
seo_copy_publish_logs 中也未发现对应历史深页 JSON

名单如下：

caosheninan-com
cnzhenbang-com
codohealth-com
glae-cc
gxhongzhuang-com
gz-yxsw-com
hbczccq-com
hyjssb-com
jingxifa-com
jpjdxs-com
jxxgygy-com
lcdchq-com
leici1940-com
lgyz-net
lmjcg-com
lsrxs-com
nblssy-com
oronorent-com
pcslcl-com
sdxhtgcl-com
sdxtwnc-com
sjzyunyang-com
ukoys-com
vikau-com
visitsumenep-com
zbsv3-com

当前批量策略结论

基于现有本地仓库，不建议直接做“27 域名全量恢复”，原因很直接：

当前已验证可恢复的真实域名只有 2 个
其余 26 个域名，至少在当前本地仓库中还没找到可靠深页来源
如果强行批量恢复，只会造成：
- 一部分域名真的恢复
- 大部分域名仍然 default-only
- 后续误判“脚本没效果”或“恢复逻辑不一致”

因此当前更稳的策略是：

先保留已恢复样本域名
继续从其它机器 / 旧仓库 / 历史备份中找剩余域名来源
每新增一批可靠来源，再做分批恢复

2026-04-16 新增结论：`publish_logs/backups` 比之前判断更有价值

继续深挖后，发现前面的判断还可以再前进一步：

code/storage/seo_copy_release_runs/20260408/*/run-summary.json
code/storage/seo_copy_release_runs/20260408/*/batch_publish.summary.json

这两类文件明确证明，当时并不是只有 default-only 的发布层。

已确认的历史事实包括：

2026-04-08 的发布运行里，校验过 232 个文件
其中包含：
- detail: 37
- play: 39
- category_list: 41
- search: 35
- 以及 home / category_index / rank_index / rank_list / forge
front_verify 里还能直接看到真实页面文案预览，说明当时这些页面不只是存在文件，而且前台命中验证也通过过

这条结论非常重要，因为它说明：

历史资产在这个仓库里确实存在过
不是用户记忆偏差
也不是“从来就没做过”
只是当前工作树里主数据层已经不完整，剩下的更多是发布备份残留

新增脚本：从发布备份聚合恢复

为了避免手工从各个 backup 目录一个一个抄，当前新增：

code/scripts/seo_copy_restore_from_publish_logs.php

作用：

直接扫描 code/storage/seo_copy_publish_logs/backups
聚合某个 host 在所有历史发布备份里出现过的页面键
按场景写回 code/data/seo_copy_published
支持 --dry-run

示例：

php code/scripts/seo_copy_restore_from_publish_logs.php \
  --host=chuanjiafeng-net \
  --dry-run

正式写入：

php code/scripts/seo_copy_restore_from_publish_logs.php \
  --host=chuanjiafeng-net

用新脚本恢复后的当前结果

chuanjiafeng-net

当前已从 publish_logs/backups 聚合恢复到：

home = 1
category_index = 1
category_list = 21
search = 11
rank_index = 1
rank_list = 1
detail = 11
forge = 11
play = 11

再加上之前从 bundle 恢复过的 detail/play 样本，现在本地发布目录里已达到：

detail = 17
play = 17
home = 1
category_index = 2
category_list = 22
search = 12
rank_index = 1
rank_list = 1
forge = 11

也就是说，chuanjiafeng-net 已经不只是“恢复了几个播放页”，而是整套首页、分类、搜索、榜单、详情、播放、forge 都恢复出一批真实历史资产。

liangzuan-net

当前已从 publish_logs/backups 聚合恢复到完整单样本链：

home = 1
category_index = 1
category_list = 1
search = 1
rank_index = 1
rank_list = 1
detail = 1
forge = 1
play = 1

虽然数量不大，但它是完整的场景闭环，不再只是 detail/play 两个点。

这一步对后续排查的意义

从现在开始，后续 Codex 处理“GPT 模板引导文是不是被覆盖没了”这类问题时，应该按下面顺序：

先看 seo_copy_published 当前是否 default-only
再看 seo_copy_publish_logs/backups 是否还有历史备份
能恢复就先恢复历史资产
最后才考虑模板微调或重新生成内容

不要再跳过第 2 步直接重写，否则很容易把已经存在过、且曾经验证通过的资产再次覆盖掉。

2026-04-16 补充结论：模板接入未丢，缺的是正式域名深页成品数据

这一轮继续追查后，已经可以把“为什么首页还有引导块，但详情页/播放页很多看不到”说明白：

现状不是“GPT 模板又被删了一次”

当前工作树里，videoGpt1 模板实际上已经接入了 seo_copy 模块，且这些接入点都还在：

首页：
- code/app/home/view/videoGpt1/index/index.html
- 已有 video:seocopy scene="home" + module/seo_copy/collection
分类页：
- code/app/home/view/videoGpt1/video/getCategory.html
- code/app/home/view/videoGpt1/video/getCategoryType.html
- code/app/home/view/videoGpt1/video/getRankIndex.html
- code/app/home/view/videoGpt1/video/getRankList.html
- code/app/home/view/videoGpt1/video/getSearchVideo.html
详情页：
- code/app/home/view/videoGpt1/module/detail_main/desc.html
- 已有 video:seocopy scene="detail" + module/seo_copy/detail
播放页：
- code/app/home/view/videoGpt1/video/getVideoPlayUrl.html
- 已有 video:seocopy scene="play" + module/seo_copy/play

也就是说，模板层“挂载引导文模块”这件事本身没有消失。

为什么首页能看到，详情/播放很多域名却看不到

根因已经验证清楚：多数正式域名当前的 seo_copy_published 只有粗粒度页面成品，深页只有 default.json，没有当时实际生成过的 detail/play 样本。

抽查结果：

jpjdxs-com
pcslcl-com
lsrxs-com
lmjcg-com
nblssy-com

它们目前都满足：

home/index.json 存在
category_index/index.json 存在
search/landing.json 存在
detail/default.json 存在，但没有 detail/154229.json 这类真实深页文件
play/default.json 存在，但没有 play/154229-play-douban-1.json 这类真实播放页文件

因此：

首页能正常出现 guide-collection
详情页和播放页会因为 default-only 被 VideoService 的抑制逻辑直接隐藏

这不是模板再次被误删，而是“深页成品资产后来丢了”。

实页验证结果

已直接用本地后端端口 13205 + Host 头验证：

jpjdxs.com
pcslcl.com
lsrxs.com
lmjcg.com
nblssy.com

验证现象一致：

首页 HTML 能搜到 guide-collection
详情页搜不到 guide-detail
播放页搜不到 guide-play

这和 seo_copy_published_audit.php 的审计结果完全一致。

对“是不是被 git 覆盖了”的判断

当前更准确的表述不是“整套 GPT 模板被 git 覆盖没了”，而是：

模板接入层还在
一部分首页/分类/搜索成品还在
当时生成并发布过的 detail/play 深页成品，大概率在后续同步、回滚、清理或目录覆盖过程中丢失

已知更强证据：

v20260413-openai-batch-26/openai_batch_result.json
v20260413-openai-batch-26/openai_deep_batch_26_rerun_20260414.json

里面明确记录了 jpjdxs.com / pcslcl.com / lsrxs.com / lmjcg.com / nblssy.com 都是：

已生成并发布首页/分类/搜索/详情/播放页文案

说明这些深页文案当时真实存在过。

目前能下的结论

你记得的那批首页引导文、详情引导文、播放引导文，并不是“记混了”
模板挂载位并没有整体消失
当前缺的是正式域名的历史深页成品文件
后续恢复应继续优先走“历史资产找回”，而不是重新手写一版替代品

后续恢复顺序

后面的 Codex 接手时，应按下面顺序继续：

先审计目标 host 是否 detail_default_only / play_default_only
再在 publish_logs / release_runs / batch / bundle / 其它运行产物 中找历史成品
找到就恢复原始 page-key 文件
只有在确定历史成品完全无法找回时，才考虑重生成

2026-04-16 补充结论：通用发布链和 bootstrap 发布链不是一回事

这次继续排查后，已经可以把“为什么很多正式域名只剩 default.json”说得更准确一些：

当前仓库里的“通用 AI 生成/发布链”本身就只覆盖粗粒度页面
其中 detail 只写 detail/default
其中 play 只写 play/default
它并不会自动产出 detail/<videoId>.json
也不会自动产出 play/<videoId>-<line>-<episode>.json

已确认的代码位置：

code/app/common/helper/SeoCopyGenerationHelper.php
code/app/common/helper/SeoCopyAiProviderHelper.php
code/app/admin/controller/Site.php

这些位置目前都还是按下面的固定目标处理：

home/index
category_index/index
category_list/default
search/landing
detail/default
play/default

也就是说：

如果某个域名只跑过这条“通用链路”
那它最终落盘到 seo_copy_published 的结果，本来就很可能只有默认深页

bootstrap 链路才会生成真实深页 page-key

和上面不同，seo_copy_domain_bootstrap.php 这条链路会生成：

detail/<videoId>.json
forge/<videoId>-forge-<n>.json
play/<videoId>-play-<line>-<episode>.json

因此真正的“详情页/播放页差异化补料”主要来自 bootstrap 或等价的深页发布流程，而不是后台那条通用发布流程。

为什么 `chuanjiafeng-net` / `liangzuan-net` 还看得到深页差异化

继续查 storage/seo_copy_release_runs 和 storage/domain_bootstrap_bundles 后，已经拿到了更直接的证据：

chuanjiafeng-net 的 release run 里明确记录过 detail/154229.json
同一批记录里也明确记录过 play/154229-play-douban-1.json
storage/domain_bootstrap_bundles/chuanjiafeng-compact/ 下也保留了大量真实深页素材
liangzuan-net 也有类似 bundle / 历史产物

这说明它们确实走过“深页发布链”，所以今天还能看到更完整的差异化补料。

为什么 `jpjdxs-com` 这批正式域名目前看起来像“只剩默认”

对下面这些 host：

jpjdxs-com
pcslcl-com
lsrxs-com
lmjcg-com
nblssy-com
lcdchq-com
lgyz-net
oronorent-com
sdxhtgcl-com

当前仓库里已经确认：

code/data/seo_copy_published/<host>/detail/ 只有 default.json
code/data/seo_copy_published/<host>/play/ 只有 default.json
storage/seo_copy_release_runs 里几乎搜不到这些 host 的深页发布记录
storage/domain_bootstrap_bundles 里也搜不到它们对应的历史 bundle

这意味着更大的概率不是“这次模板把深页补料删了”，而是下面两种情况之一：

这些 host 当时根本没有在当前仓库/当前机器里完成 bootstrap 深页发布
它们的深页发布资产存在于另一台机器、另一份工作区，后来没有同步回来

关于“后台预览看起来全没了”的补充说明

后台当前的已发布预览接口也会加重误判，因为它只展示：

detail/default
play/default

而不会枚举展示真实的：

detail/<videoId>
play/<videoId>-<line>-<episode>

对应代码位置：

code/app/admin/controller/Site.php
方法：getDomainSeoCopyPublishedPreview

所以后台看到“只有 default”，不一定等于前台一定没有具体深页；但对本轮这批正式域名来说，前台与文件审计结果已经相互印证，确实是深页资产缺失。

当前最可靠的判断

截至 2026-04-16，这个问题应拆成两层分别处理：

页面模板/UI 层这层已经恢复，首页/详情/播放的 GPT 模板挂载位、引导块和正文块都在
深页发布资产层这层在多数正式域名上仍缺历史 page-key 文件，因此只能 fallback 或直接抑制显示

后续任何 Codex 接手时，不要再把这两个问题混在一起判断。

2026-04-16 再补一条关键证据：`openai_batch_result` 里的“已发布详情/播放”不是深页发布

这次继续把运行结果、代码和 git 历史对齐后，可以更明确地纠正一个容易误解的点：

v20260413-openai-batch-26/openai_batch_result.json
v20260413-openai-batch-26/openai_deep_batch_26_rerun_20260414.json

里面对很多正式域名都写着：

written_pages = 6
已生成并发布首页/分类/搜索/详情/播放页文案

但这里的“6 个页面”不是：

首页
分类
搜索
真实详情深页
真实播放深页
其它真实样本页

而是固定指向这 6 个槽位：

home/index
category_index/index
category_list/default
search/landing
detail/default
play/default

已核实的代码证据

以下代码都由同一个提交引入固定槽位配置：

code/app/common/helper/SeoCopyGenerationHelper.php
code/app/common/helper/SeoCopyAiProviderHelper.php
code/app/admin/controller/Site.php

对应 git blame 结果显示，这几处固定配置都来自：

提交：0794c903
时间：2026-04-15 14:00:19 +0800

也就是从这套通用链路落地开始，它的设计目标就不是“为每个 host 发布真实 deep page key”。

对批处理成功记录的正确理解

因此当批处理结果里看到：

jpjdxs.com
pcslcl.com
lsrxs.com
lmjcg.com
nblssy.com
lcdchq.com
lgyz.net
oronorent.com
sdxhtgcl.com

都显示：

status = success
written_pages = 6

更准确的解释应该是：

它们成功写入了“6 个固定 SEO 文案槽位”
不是成功写入了真实 detail/<videoId>.json
也不是成功写入了真实 play/<videoId>-play-<line>-<episode>.json

对“当时明明说发布过详情/播放”的最终解释

现在可以把这句话解释完整了：

当时说“发布过详情/播放”
在通用链路语义里成立
但它指的是 detail/default 和 play/default
不等于深页差异化资产已经落盘

所以后面再排查“深页引导文为什么没有了”时，不能再单纯依据 openai_batch_result 里的成功状态下结论，必须继续看：

seo_copy_published/<host>/detail/
seo_copy_published/<host>/play/
是否真的存在非 default 的 page-key 文件

2026-04-16 外部找回清单

截至当前排查结果，下面这些正式域名在当前仓库内的发布状态完全一致：

jpjdxs-com
pcslcl-com
lsrxs-com
lmjcg-com
nblssy-com
lcdchq-com
lgyz-net
oronorent-com
sdxhtgcl-com

它们当前在 code/data/seo_copy_published/<host>/ 下都只有：

home/index.json
category_index/index.json
category_list/default.json
search/landing.json
detail/default.json
play/default.json

没有任何：

detail/<videoId>.json
play/<videoId>-play-<line>-<episode>.json

同时也已经确认：

当前机器 /www/wwwroot 范围内未发现这批 host 的第二份深页 JSON 副本
storage/seo_copy_release_runs 内未发现这批 host 的非 default detail/play 发布证据
storage/domain_bootstrap_bundles 内未发现这批 host 对应 bundle

因此，如果还要继续“找回历史成果”，应优先去当前仓库之外的地方找。

外部找回优先顺序

建议按下面顺序查：

旧服务器或旧工作区里的 code/data/seo_copy_published
旧服务器或旧工作区里的 code/data/seo_copy
旧服务器或旧工作区里的 code/storage/domain_bootstrap_bundles
旧服务器或旧工作区里的 code/storage/seo_copy_publish_logs
旧服务器或旧工作区里的 code/storage/seo_copy_release_runs
当时跑批使用过但未纳入 git 的临时目录、压缩包、备份盘

重点只看下面两类文件：

detail/*.json 中非 default.json 的文件
play/*.json 中非 default.json 的文件

外部找回时的最小判断标准

只要满足下面任意一条，就说明该 host 存在可恢复价值：

找到至少 1 个 detail/<videoId>.json
找到至少 1 个 play/<videoId>-play-<line>-<episode>.json
找到对应 host 的 bootstrap bundle
找到 release log / publish log 明确记录了非 default 的 detail/play page_key

如果四条都没有，再默认该 host 的历史深页资产在现有环境中不可恢复。

找回后的恢复原则

一旦在外部目录找到了某个 host 的深页资产，恢复时必须遵守下面原则：

只回灌该 host 缺失的 detail/play 非 default 文件
不覆盖已经存在的首页、分类、搜索固定槽位
不修改模板逻辑
不修改路由逻辑
不改数据库
先 dry-run 审计，再正式复制

恢复目标目录仍然是：

code/data/seo_copy_published/<host>/detail/
code/data/seo_copy_published/<host>/play/

如果外部也找不到，最小代价重建方案

只有在确认外部目录也找不到历史资产后，才进入重建方案。

重建时不要直接“大面积重写所有文案”，而应采用最小代价方案：

继续保留当前首页、分类、搜索固定槽位
只补 detail/play 深页资产
先补少量高频样本页，不一次性铺满全站
补料逻辑必须保持“同域名稳定、同视频稳定、同线路稳定”
优先生成真实 page-key 文件，而不是再写回 default.json

重建边界

如果进入重建，必须遵守下面边界，避免再把历史成果覆盖成统一模板：

不改现有 home/index
不改现有 category_index/index
不改现有 category_list/default
不改现有 search/landing
只新增非 default 的 detail/play 文件
不把新增深页资产重新压回 detail/default / play/default

当前阶段最重要的判断

截至 2026-04-16，最重要的判断不是“模板还要不要继续改”，而是：

先确认正式域名有没有可找回的历史深页资产
若没有，再进入“新增深页资产”的最小重建方案

在这一步之前，不建议继续大改 GPT 模板页面结构，否则容易把“资产缺失问题”误判成“模板呈现问题”。

2026-04-16 最小重建方案的技术实施蓝图

如果后续确认外部环境也找不到历史深页资产，推荐按下面的技术路径做“最小重建”，并且只做深页资产补回，不做模板重写。

目标

目标只做一件事：

为缺失的 host 新增少量真实 detail/play page-key JSON

不是要做下面这些事情：

不是重做首页 SEO
不是重做分类页 SEO
不是重做搜索页 SEO
不是重改 GPT 模板结构
不是把 fallback 文案整体替换成 AI 文案

已有可复用链路

当前仓库里，已经有一条能生成真实深页 page-key 的现成链路，可作为最小重建基础：

code/scripts/seo_copy_domain_bootstrap.php
code/scripts/seo_copy_release_run.php
code/app/common/helper/SeoCopyFallbackBuilder.php
code/app/common/helper/SeoCopyStore.php
code/app/services/VideoService.php

其中最关键的是：

seo_copy_domain_bootstrap.php 它本来就会生成：
- detail/<videoId>.json
- forge/<videoId>-forge-<n>.json
- play/<videoId>-play-<line>-<episode>.json
VideoService::buildSeoCopyPageKeys() 前台读取时也本来就优先查这些真实 page-key

所以最小重建不需要重新发明一套新格式，重点是把这条深页资产生成链安全地用在正式域名上。

建议的实施顺序

推荐按下面顺序推进：

样本选择
深页 JSON 生成
只回灌 published 目录
前台命中验证
蜘蛛抓取观察
再决定是否扩样本

第 1 步：样本选择

每个 host 先不要全量铺，而是先选小样本：

detail 先选 10 到 20 个 videoId
play 每个 videoId 只先选 1 条主线路
每条线路只先选 1 个集数

样本建议优先来自：

当前站点首页正在推荐的内容
分类页正在曝光的内容
蜘蛛日志最近命中的真实 detail/play URL
数据库里播放线路稳定、标题稳定的内容

第 2 步：深页 JSON 生成

生成深页资产时，优先使用现有 bootstrap 链路：

用 seo_copy_domain_bootstrap.php 生成单 host 小批量 bundle
让它输出真实 detail/play page-key JSON
源内容先允许走 SeoCopyFallbackBuilder

这样做的原因是：

先恢复“深页资产存在”这件事
再考虑文案质量迭代
避免一开始把问题扩大成“AI 质量 + 资产缺失 + 模板呈现”三件事同时处理

第 3 步：只回灌 `published`

真正回灌时，只把生成结果写到：

code/data/seo_copy_published/<host>/detail/
code/data/seo_copy_published/<host>/play/

不建议第一步就把内容同时写回：

code/data/seo_copy
大批量 approved
旧的通用 AI 发布链

因为当前最重要的是验证“前台是否会优先命中真实深页 page-key”。

第 4 步：前台命中验证

每次小批量回灌后，必须做 3 类验证：

文件验证
- detail/<videoId>.json 是否存在
- play/<videoId>-play-<line>-<episode>.json 是否存在
页面验证
- 详情页是否从“空/抑制”变成命中 guide-detail
- 播放页是否从“空/抑制”变成命中 guide-play
回退验证
- 其他没有补样本的页面，仍然保持原有 default/fallback 行为

第 5 步：蜘蛛抓取观察

回灌后不要立刻扩全站，先观察：

百度是否重新命中这批 detail/play
命中后是否稳定返回 200
页面正文是否能稳定被抓到，不再出现空白深页

当前最应该复用的代码点

后续实施时，优先围绕下面这些点展开，而不是另起炉灶：

code/scripts/seo_copy_domain_bootstrap.php 已具备真实深页 page-key 生成能力
code/app/services/VideoService.php 已具备优先查真实 page-key、缺失时回退 default 的读取逻辑
code/app/common/helper/SeoCopyStore.php 已具备按 host / scene / page_key 写入 JSON 的能力
code/scripts/seo_copy_restore_from_source.php 可作为“把 source 写回 published”的参考工具
code/scripts/seo_copy_published_audit.php 可作为回灌后的审计工具

当前不建议直接改动的代码点

在进入最小重建阶段时，下面这些位置不建议先动：

code/app/home/view/videoGpt1/* 页面层已经恢复，不是当前主问题
code/app/home/config/router.php 路由层已稳定，先不要把问题重新引入
code/app/admin/controller/Site.php 的通用 AI 发布逻辑这条链本身就是固定槽位链，短期不必强改成深页链

如果后续一定要补“后台一键深页发布”

那应该作为第二阶段做，而不是第一阶段。

第二阶段的方向应该是：

保留当前后台“固定 6 槽位”能力
另外新增“深页样本发布”入口
让后台可以按 host + videoId + playType + playIndex 生成和发布小批量深页 JSON

不要直接把原来的通用 AI 发布按钮改成全深页逻辑，否则风险很高。

最小重建阶段的成功标准

第一阶段不追求“恢复整站所有历史差异化”，只追求下面 4 条：

某个正式域名出现至少 10 个真实 detail/<videoId>.json
同一域名出现对应的 play/<videoId>-play-<line>-<episode>.json
详情页和播放页前台能稳定命中这些 page-key
蜘蛛开始重新抓到这些非空深页

做到这 4 条，就说明“深页资产链”已经重新打通，后面再扩量才有意义。

2026-04-16 试点重建 checklist

下面这份 checklist 用于“先拿 1 个正式域名做小样本试点”，目标是先验证链路，不追求一次铺满。

一、试点前准备

开始前先确认下面 4 件事：

只选 1 个 host，不并行多 host
不改模板
不改路由
不改数据库结构

建议优先试点 host：

lgyz-net
lcdchq-com
jpjdxs-com

原因：

这几个 host 当前都属于典型 default-only
前台路由已经验证过可访问
更适合做“补深页资产后是否立刻生效”的观察

二、样本选择 checklist

每次试点先准备：

10 到 20 个 videoId
每个 videoId 只选 1 条主线路
每条线路只选 1 个主集数

样本优先级：

首页正在推荐的内容
分类页正在曝光的内容
蜘蛛最近命中的详情/播放 URL
播放线路最稳定的内容

不建议选：

没有稳定播放线路的视频
刚入库、字段不完整的视频
需要复杂 slug 才能访问、当前又不稳定的视频

三、生成 bundle 的建议方式

推荐优先用现有 bootstrap 脚本做单 host 小样本 bundle。

参考命令模板：

php scripts/seo_copy_domain_bootstrap.php <host> \
  --detail-id=<videoId> \
  --detail-slug=<slug> \
  --search-keyword=<keyword> \
  --category-parent=<parent> \
  --category-child=<child> \
  --bundle-root=storage/domain_bootstrap_bundles/<bundle-name> \
  --index-root=storage/domain_bootstrap_bundles \
  --portal-root=public/_seo_copy_release

说明：

这一步的核心是拿到 bundle 里的真实 detail/play page-key JSON
不要求一开始就把 10 到 20 个样本一次性都塞进去
可以先跑通 1 个样本，再扩到 10 个

四、bundle 生成后先做 dry-run

生成 bundle 后，先不要正式应用，先 dry-run。

建议顺序：

php scripts/domain_bootstrap_run.php <bundle-root> --dry-run=1 --format=text

必要时再分步：

php scripts/domain_bootstrap_register.php <bundle-root>/site-register.sample.json --dry-run=1 --format=text
php scripts/domain_seo_bootstrap_apply.php <bundle-root>/site-bootstrap.sample.json --dry-run=1 --format=text

dry-run 通过后，再决定是否继续。

五、写回 `published` 前的文件检查

在真正回灌前，先确认 bundle/source 里已经出现：

detail/<videoId>.json
play/<videoId>-play-<line>-<episode>.json

如果只有：

detail/default.json
play/default.json

那说明这次生成仍然没有产出真实深页资产，不能继续写回。

六、回灌方式

如果 bundle/source 中已经有真实深页文件，优先用现成恢复脚本回灌：

php code/scripts/seo_copy_restore_from_source.php \
  --host=<host-dir> \
  --source=<bundle-or-source-root> \
  --dry-run

确认无误后，再正式写入：

php code/scripts/seo_copy_restore_from_source.php \
  --host=<host-dir> \
  --source=<bundle-or-source-root>

这个脚本当前只会处理：

detail
play

比较适合最小重建阶段使用。

七、回灌后的文件审计

写回后第一时间跑审计：

php scripts/seo_copy_published_audit.php --host=<host-dir> --format=text

必要时加样本检查：

php scripts/seo_copy_published_audit.php \
  --host=<host-dir> \
  --sample-detail=<videoId> \
  --sample-play=<videoId>:<playType>:<episode> \
  --format=text

通过标准：

detail_default_only: no
play_default_only: no
指定 sample 的 expected_page_key 存在

八、前台命中验证

文件审计通过后，再做前台读取验证。

读回验证：

php scripts/seo_copy_readback.php <host> detail <videoId> --format=text
php scripts/seo_copy_readback.php <host> play <videoId> <playType> <episode> --format=text

前台验证：

php scripts/seo_copy_front_verify.php <host> detail <videoId> --base-url=http://127.0.0.1:13205 --format=text
php scripts/seo_copy_front_verify.php <host> play <videoId> <playType> <episode> --base-url=http://127.0.0.1:13205 --format=text

通过标准：

详情页命中 guide-detail 或等价正文引导块
播放页命中 guide-play 或等价正文引导块
不是继续走空白或被抑制状态

九、试点观察窗口

第一次试点完成后，不要立刻扩全量，建议至少观察一个抓取窗口：

先观察数小时到 1 天
看蜘蛛是否回打这批深页
看命中后是否稳定 200
看正文是否真实输出，不再是空深页

十、试点成功后的扩量规则

只有试点成功后，才允许扩量。

扩量时建议：

先从 10 个样本扩大到 30 个
再从 30 个扩大到 100 个
每次扩量后都要重复审计和前台验证

不要直接：

一次生成全站所有 detail/play
一次回灌所有 host

十一、试点失败时怎么判断原因

如果试点失败，优先按下面顺序排查：

bundle/source 是否真的产出非 default detail/play
restore_from_source 是否真的写入 published
seo_copy_published_audit 是否仍显示 default-only
seo_copy_readback 是否能读到真实 page-key
seo_copy_front_verify 是否命中了对应前台 URL

只有先把这 5 层排干净，才允许怀疑模板或路由。

2026-04-16 第一试点 host 建议

基于当前仓库与本机回测结果，第一试点 host 建议优先选：

jpjdxs.com

原因：

当前属于典型 detail_default_only / play_default_only
首页和详情页都能稳定打开
已经能从详情页直接抽到真实播放链接
详情 URL 和播放 URL 规则相对清晰，便于做第一批 dry-run

当前已确认的 URL 形态：

详情页：/neirong-<videoId>-<slug>
播放页：/bf-<videoId>-<slug>/<playType>-<episode>

例如：

详情页：/neirong-154229-xiang-feng-bu-shi-jiu-shi-ren
播放页：/bf-154229-xiang-feng-bu-shi-jiu-shi-ren/douban-1

同时也已确认：

seo_copy_published 下不存在 detail/154229.json
seo_copy_published 下不存在 play/154229-play-douban-1.json

这正适合作为第一批“从无到有补深页资产”的试点。

`jpjdxs.com` 第一批样本候选

当前已从首页与详情页抽到一批真实样本，建议先从下面 8 个详情样本开始：

76342 / se-jiang-zhi-xue-mei-gui
76318 / she-sha-shou
76347 / se-jie
76341 / se-qing-dian-ying-da-shui-qiang-de-liu-de-wang
76324 / shao-nv-de-you-huo
76346 / se-gui-tou-tai
76359 / san-fen-zhi-yi-qing-ren
76325 / shao-nv-de-you-huo

对应已抽到的播放页候选如下：

76342
- default-1
- douban-1
- youzhi-1
76318
- default-1
- douban-1
- youzhi-1
76347
- default-1
- douban-1
76341
- default-1
- douban-1
76324
- default-1
- douban-1
76346
- default-1
- douban-1
- youzhi-1
76359
- default-1
- douban-1
- youzhi-1
76325
- default-1
- douban-1

第一试点最小建议组合

如果要把风险再压低，建议第一轮不是 8 个全上，而是先从下面 3 个 detail + 3 个 play 开始：

detail/76342
detail/76318
detail/76347
play/76342-play-douban-1
play/76318-play-douban-1
play/76347-play-douban-1

原因：

这 3 个样本都来自首页当前真实曝光内容
详情页与播放页链接都已实测能抽到
douban-1 在线路上最统一，适合先打通第一轮

当前试点前的已知空缺验证

已直接验证：

jpjdxs.com detail 154229 当前无对应 seo_copy_published 深页文件
jpjdxs.com play 154229 douban 1 当前无对应 seo_copy_published 深页文件

这说明当前环境仍然符合试点前置条件：

深页资产缺失是真实存在的
不是已经生成但前台没命中

70 KiB Raw Blame History Unescape Escape

1270-SEONexus Codex 多版本协作交接总文档

正式服接手极简版

当前共识

当前 Git 节点

当前提交后的边界

接手后先做什么

不要再重复做的事

接手时建议直接回报的最小信息

目的

核心原则

1. 同一时间只优化一份代码

2. 另一份代码在未同步最新前，只做“观察”，不做“改动”

3. 新版是主验证场，旧版本是回灌场

版本边界

新版负责什么

旧版本负责什么

不要让旧版本先承担的内容

多 Codex 协作角色建议

Codex-A：新版主线 Codex

Codex-B：旧版本回灌 Codex

Codex-C / Codex-D：后续扩展 Codex

每次开始工作前必须确认的事项

严格边界

1. 不自动跨版本做“顺手修复”

2. 不自动提交

3. 不整包恢复历史提交

4. 不在两个版本上同时独立发明方案

本轮关键经验补充

1. 不是所有“页面丢内容”都是数据库问题

2. GPT 模板当前已确认恢复的主线页面

3. 本轮确认过的三条高频根因

根因 A：模板层被“轻量 seo_copy include”替换后，深页补料不再显性输出

根因 B：路由注册错位，页面请求被导到了错误模板

根因 C：服务层 URL 方法后来加了强类型，旧模板空参数直接炸

4. .html 冻结路由是 GPT 新路由分支的重点兼容项

5. 以后排查顺序建议

本轮主线可复用修复

路由层

服务层

模板层

交接提醒

SEO 文案发布层特别注意

1. 不要把“页面退化”直接等同于“模板被回滚”

2. 当前仓库已经确认的事实

3. 审计命令

4. Git 历史判断规则

5. Git 推送只能使用 www 用户

5.1 仓库 ownership 也必须保持 www:www

6. SEONexus 与 SEONexusAdmin 是同机双仓协作

7. 不建议现在把所有项目硬并成一个 Git 仓库

8. 本轮 GPT 模板“像被覆盖了”的根因结论

8.1 早期 GPT 模板主骨架其实还在

8.2 真正可疑的覆盖点在 origin2/dev

8.3 所以当前更像是“发布数据覆盖”，不是“模板源码被删”

8.4 当前已锁定的责任边界

8.5 恢复优先级

工作顺序标准流程

场景 A：新版先优化，旧版本后回灌

场景 B：旧版本先发现问题

哪些优化适合回灌旧版本

适合

慎回灌

多 Codex 的交接模板

1. 本轮工作对象

2. 本轮目标

3. 本轮已改动文件

4. 本轮未提交改动

5. 本轮验证结果

6. 下一位 Codex 的注意事项

文档同步规则

1. 主题执行文档

2. Codex 交接总文档

3. 单次线上事件排障文档

4. 项目本地持续分析文档

5. 本地分析必须回流主文档

6. 多服务器可以并行分析，但主线应单点收口

特别注意事项

1. 前端 Nginx 不要继续按 URL 模板枚举

2. 旧版本不要轻易改主输出 URL 风格

70 KiB

Raw Blame History

4. `.html` 冻结路由是 GPT 新路由分支的重点兼容项

5. Git 推送只能使用 `www` 用户

5.1 仓库 ownership 也必须保持 `www:www`

6. `SEONexus` 与 `SEONexusAdmin` 是同机双仓协作

8.2 真正可疑的覆盖点在 `origin2/dev`

1. `theme_cache`

3. `seoaddon`

4. `seo_copy`

1. `site:seotkd` 不允许输出空 TKD

2. `detail` / `play` 页面不强行渲染 default-only `seo_copy`

2026-04-16 深页 `seo_copy` 恢复验证结论

1. `chuanjiafeng-net`

2. `liangzuan-net`

2026-04-16 新增结论：`publish_logs/backups` 比之前判断更有价值

为什么 `chuanjiafeng-net` / `liangzuan-net` 还看得到深页差异化

为什么 `jpjdxs-com` 这批正式域名目前看起来像“只剩默认”

2026-04-16 再补一条关键证据：`openai_batch_result` 里的“已发布详情/播放”不是深页发布

第 3 步：只回灌 `published`