先读现状，
再决定怎么做

这节课要完成什么

1. 分清用户看到的现象和代码里的原因；
2. 找到当前真正应该修改的项目；
3. 让 Codex 先说明它看到了什么，不急着写代码；
4. 根据找到的原因决定最小改法；
5. 需要用户选择时，先停下来确认。

先把信息分成三层

“页脚看起来不一样”是你看到的现象，“学习页覆盖了共享宽度”才是查过代码后的原因。把两者分开，Codex 才不会围绕猜测反复打补丁。

第一步先确认应该修改哪一份

真实项目常有正式版、实验版、备份、构建目录和历史归档。当前被团队认定为准、后续应该继续维护的那一份，叫作“真源”。文件名看起来最新，不代表它就是应该修改的版本。

New-Yuntu-AGI/
├── cn网站项目/new_yuntuagi.cn_v2.2.1-beta/   # 正式源码真源
├── 战略发展/官网v4暖黑视觉初版-20260814/    # v4 实验原型
├── 网站快照中心/                              # 回滚快照
└── 网站实验归档/                              # 历史试验

动手前，要先说清本轮操作的完整路径、这个版本的用途，以及明确不修改哪些相邻项目。遇到多个候选目录时，先读根目录说明、状态文件和版本文档。

先读项目规则，再读实现

1. 根目录或上级目录的 AGENTS.md；
2. 工作区状态、官网说明、README 与开发文档；
3. 项目自己的 package.json、锁文件和运行脚本；
4. 设计系统、组件规范与内容真源；
5. 与任务相关的测试、历史修复记录和数据库边界。

规则文件解决“允许怎么做”；源码解决“现在怎么做”；真实运行解决“实际发生了什么”。三者不能互相替代。

从入口向下追，不要全库漫游

先找到用户真正进入的路由或入口组件，再追到共享组件、数据和样式。搜索应该围绕用户看见的文字、路由、组件名和 class，而不是从整个项目逐行阅读。

# 找到学习页与页脚引用
rg -n "SiteFooter|/learning|footer" app components

# 找到容器宽度定义
rg -n "shell|width: min|max-width" app/*.css components

# 查看项目脚本，不执行未知命令
sed -n '1,200p' package.json

调查命令只用于示例。实际项目中先确认工具存在，并优先使用项目已经采用的方式。

调查报告应该回答七个问题

1. 本轮应该修改哪一个版本，它的完整路径是什么；
2. 哪些项目规则适用；
3. 用户从哪个入口看到问题；
4. 这个页面由哪些文件共同控制；
5. 当前页面是否与用户描述一致；
6. 问题原因是什么，可以在哪里看到；
7. 准备怎样修改、怎样检查，还有什么风险。

结论：学习页页脚组件与首页相同，偏差来自外层容器。

证据：
- 两页均引用 components/site-shell.tsx
- 首页 footer 内层使用 .shell = 1140px
- 学习页新增规则覆盖为 1240px

建议：删除学习页局部覆盖，恢复共享 .shell。

验证：1440px 与 390px 比较页眉、正文、页脚边界。

调查结束后设置一个实施检查点

当任务范围明确、风险低，而且用户已经直接授权实现时，Codex 可以调查后继续执行；但仍应在内部保留这个检查点，发现真源不明、规则冲突或影响扩大时主动停下。

调查阶段最常见的错误

1. 找到第一个同名文件就开始改；
2. 只读页面文件，没有看共享组件和数据来源；
3. 把构建产物当成源码真源；
4. 看到注释或文档就相信它仍然有效，没有与运行结果对照；
5. 为了证明预设方案，只收集支持它的证据；
6. 调查范围不断扩大，却没有回到用户目标。

视频录制与复习提纲

1. 从一张页脚截图提取观察而非原因；
2. 演示如何确认 v4 实验真源；
3. 从路由追到共享组件与 CSS；
4. 把事实和假设分栏记录；
5. 形成最小方案并在实施前停下；
6. 展示一个“改对数字但改错层级”的反例。