上一篇我整理了后台列表最容易出现的六类结构问题。再往前追一步会发现其中不少问题都来自同一个起点Codex 还没有确认项目里的列表页范式就开始照需求拼页面。“做一张通知列表支持标题搜索、时间筛选、分页、新增、编辑、查看和删除”这是一份业务需求不是一份项目实现说明。Codex 可以据此生成一张通用的 Vue3 Element Plus 页面却无法仅凭这句话知道搜索区是页面内联还是独立组件列表和分页是手写还是交给tabMixin日期范围在哪里转换请求 Loading 由页面还是请求封装管理操作按钮怎样接入权限弹框是否使用useDialogImp和midDialog新增、编辑、查看是共用一个表单还是分开处理。所以新建页面之前我会先把任务改成“识别范式”暂时不允许修改代码。这里使用的名称来自当前可用的web-skills规范是可以核对的结构材料不代表每个 Vue3 项目都必须这样写。真正进入目标项目时仍然要以仓库现状和项目规则为准。我说的“列表页范式”不是复制某个页面范式不是找一张最像的页面然后整页复制、替换字段。我需要的是一组稳定关系关系要回答的问题页面组合搜索区、操作区、表格、分页和弹框怎样组合状态归属查询条件、列表、页码、总数和弹框状态分别由谁持有数据流用户操作怎样进入统一查询再更新页面公共能力项目已有的组件、Mixin、Hook、指令和工具函数是什么接口契约请求参数、响应结构、Loading 与错误处理在哪里统一业务差异当前页面与参考页面有哪些必须保留的不同范式关注的是“为什么这样连接”。如果只复制代码很容易把参考页面的业务字段、权限码、固定参数和历史兼容逻辑一起带过来。第一步先找两个参考页面不急着只选一个我通常不会让 Codex 只找“最相似页面”而是找两类证据。一张业务最相似的页面它帮助确认搜索条件数量和类型、表格列复杂度、行操作种类以及是否包含弹框、导出或批量操作。一张近期且结构稳定的页面它帮助确认当前项目推荐的组件组织方式、新版公共封装怎样使用、命名和目录习惯以及旧页面里哪些写法已经不再沿用。业务最像的页面不一定最值得复制。它可能创建得早包含过时写法近期页面也不一定业务最接近。两份证据交叉看才能区分“项目范式”和“单页偶然写法”。我会让 Codex 给出选择理由而不是只返回文件路径。第二步沿页面向下追公共封装只读页面模板还不够。当页面中出现tabMixin、paging、SearchBtn、useDialogImp、v-disOperation或请求封装时我会要求继续向下读至少确认公开契约和关键副作用。例如不能因为看见const { listData, getList, delRow } tabMixin(config);就直接得出“项目使用统一列表 Mixin”。还要继续确认listData内部保存哪些字段getList接收怎样的参数查询条件是否会被持久保存翻页时怎样合并当前条件删除成功后是否自动刷新响应里的列表和总数从哪里读取异常是否在这里吞掉或继续抛出。公共封装常常承担页面代码里看不见的契约。AI 如果只模仿调用形式、不理解内部行为就容易重复请求、重复提示或者在错误的地方再维护一份状态。第三步沿页面向上查规则和目录作用范围页面附近的代码告诉我“大家现在怎么写”项目规则则告诉我“哪些写法必须遵守”。两者不能互相替代。我会确认仓库和子目录是否存在AGENTS.md当前目录适用哪些命名和组件规则API、组件、service 是否按页面模块组织是否要求script setup是否规定列表、表单、弹框必须使用现有封装验证命令和验收方式是什么。OpenAI 官方文档说明AGENTS.md可以按目录作用范围提供项目指引。因此Codex 不能只读仓库根规则也不能把另一个模块的局部规则直接套到当前页面。第四步画出最小列表数据流读完文件以后我不会接受一段泛泛总结而会要求一条可检查的数据流。以当前web-skills中的列表结构为例可以先抽象成搜索组件编辑表单 ↓ 提交查询条件 页面统一 getList 入口 ↓ 合并分页与固定参数 项目 API 封装 ↓ 返回 records / total tabMixin 更新 list 与 pageObj ↓ el-table 与 paging 响应式更新这条图必须回答两个返回路径翻页时如何复用已经提交的查询条件新增、编辑或删除成功后如何回到列表刷新。如果只画出“表单 → 接口 → 表格”说明分页和操作闭环仍然没有被理解。第五步把稳定范式与业务差异分开我会让 Codex 输出两张表。第一张是稳定范式项目能力证据位置当前页面应怎样使用列表状态Mixin 或组合函数沿用其列表、分页和删除入口搜索表单相邻搜索组件沿用提交与重置契约分页公共分页组件传入既定页码对象和查询函数请求API 与请求封装沿用参数位置和 Loading 配置弹框Hook 与公共组件沿用打开类型、数据传递和关闭方式权限指令或权限组件使用项目权限码和现有展示策略第二张是当前业务差异新增哪些搜索字段表格列怎样显示空值、长文本和状态是否需要固定参数哪些操作受权限控制保存或删除后如何刷新是否存在特殊异常或空状态。这样做以后计划会很清楚稳定部分按项目范式实现差异部分单独确认不能相互污染。我会要求每个结论都带证据等级Codex 对项目的总结有时听起来很确定实际上只是根据命名推测。我会把结论分成三档已确认已经读到直接定义或稳定调用。例如公共分页组件明确接收getListFun和pageObj。高概率多个相邻页面写法一致但没有找到强制规则。例如三个近期列表页都把搜索区拆成独立组件。待确认只有文件名、注释或单个旧页面能支持仍可能是历史遗留。证据分级的价值是防止 AI 把“看起来像”直接升级成项目事实。什么时候应该停止阅读开始制定计划让 AI 先读项目不等于无限扩大上下文。我会设置五个停止条件已找到适用的项目规则已找到业务相似和近期稳定的参考页面已追到列表、分页、搜索、请求、弹框和权限的关键契约已画出查询、翻页和操作后的返回路径已列出当前需求与范式的差异和未决项。达到这些条件就应该停止继续浏览不相关模块转入实施计划。如果关键封装存在冲突、参考页面明显分成两套写法或者接口契约缺失则暂停实现先让人选择。继续“平均”两套写法通常只会产生第三套结构。一份可以直接交给 Codex 的范式识别任务当前先不要修改代码。请识别这个项目的后台列表页范式 1. 阅读当前目录适用的项目规则。 2. 找一张业务最相似的列表页以及一张近期、结构稳定的列表页。 3. 追踪它们使用的搜索、列表、分页、请求、弹框和权限封装。 4. 画出初始化、查询、重置、翻页、保存成功和删除成功的数据流。 5. 分别输出稳定范式、当前业务差异和待确认项。 6. 每个关键结论附文件或定义证据并标记为已确认、高概率或待确认。 停止条件上述关系已经闭合不再继续读取无关模块。 在我确认以前不创建页面不调整公共封装。这份任务的重点不是让 Codex 生成更长的分析而是让下一步修改建立在项目证据上。写在最后后台列表是高频页面最怕的不是某一列写错而是每次新建页面都产生一套新的搜索、分页和请求关系。我让 Codex 先识别范式本质上是在做一次小范围的工程对齐先确认稳定结构再处理业务差异最后才开始写代码。下一篇会进入列表里最先失控的部分——搜索条件。我会拆开用户正在编辑的值、已经提交的查询条件和最终接口参数说明为什么这三者看起来相似却不应该始终混成同一个对象。本系列持续更新。后续会继续检查搜索、表格列、分页、Loading 与异常路径怎样沿用同一套项目范式。参考资料OpenAI Codex 用例理解大型代码库追踪请求流并定位相关模块OpenAI Codex 文档使用具有目录作用范围的 AGENTS.md 提供项目指引
)
