我怎样给 Codex 分配验收职责:类型检查、Lint、单测、构建、页面验证

上一篇我讨论了为什么构建通过不等于任务完成。继续往下一个更具体的问题是类型检查、Lint、单元测试、构建和页面验证到底该怎样分工最省事的回答是“全部都跑”。但这仍然没有解决三个工程问题某项检查通过以后我究竟能得出什么结论某项检查失败以后应该先修实现、修测试还是先检查环境当时间和环境有限时哪些验证不能省哪些可以明确留作未验证项。我不会把验证手段理解成五道重复的保险而会把它们看成五种不同的观察窗口。它们看到的是不同层面的错误也各自有盲区。验收先从风险开始不从命令开始Codex 修改完成后我不会立刻机械运行一串固定命令。我会先回到任务和影响范围列出这次最可能出错的地方。例如改动主要风险修改组件 Props类型兼容、默认值、旧调用方行为修改表单提交校验、重复提交、失败恢复、请求数据修改列表查询参数转换、页码、请求顺序、空状态修改局部样式布局、溢出、遮挡、不同尺寸修改公共工具函数输入边界、返回语义、全部调用方修改构建配置入口、依赖、资源和目标环境产物风险列清楚以后再给每项风险匹配证据。如果顺序反过来容易出现一种“检查很多、目标没证”的假繁忙类型、Lint、构建全部绿色但真正修改的焦点行为一次都没有验证。第一类类型检查负责契约一致性类型检查最擅长回答代码中的类型关系是否自洽。它通常适合发现Props、Emits 和函数参数不匹配返回值与调用方预期不同对象缺少必需字段可空值未被正确收窄枚举、联合类型和泛型使用冲突重构后旧符号、旧签名或错误导入仍被引用。类型检查能够证明什么在实际命令覆盖的文件和配置中代码满足当前类型系统表达出的约束。这句话里有三个限制实际命令、当前类型系统、已经表达出的约束。类型检查不能证明什么类型定义与真实接口响应一致业务规则本身正确类型断言后的数据真的安全any、忽略指令或宽泛类型覆盖的位置没有风险页面交互、视觉和时序正确没有进入当前类型配置的文件也被检查。下面这段代码可以类型正确业务顺序仍然错误fetchList() pageNum.value 1类型系统知道fetchList可调用、pageNum是数字却不知道需求要求先回到第一页再请求。我怎样使用类型检查结果我会记录实际命令使用的配置覆盖的应用或目录是否存在忽略或跳过失败是否由本次差异引入。类型检查失败时我先判断是契约真的冲突还是生成文件、路径别名、依赖和环境没有准备好。不能看到红色就让 Codex 随意扩大修改范围。第二类Lint 负责静态规则和高频缺陷模式Lint 更像一套可执行的项目规则。它可能检查未使用变量和导入可疑条件、错误的 Promise 使用或不安全写法框架相关规则导入顺序、命名、复杂度和代码风格项目自定义的禁止模式。具体能检查什么完全取决于仓库实际配置和插件。Lint 能够证明什么被检查代码没有触发当前启用规则中的阻断项或自动修复后满足这些规则。Lint 不能证明什么代码实现了正确需求未启用的规则也得到满足自动修复没有扩大差异页面、接口和状态行为正确所有“规范”都已经被配置成机器规则。我尤其不会把“Lint 无错误”写成“代码质量没有问题”。Lint 只能发现它认识、启用并覆盖到的模式。自动修复要单独审查差异如果执行带自动修复的命令我会在之后重新检查完整差异。原因很简单自动修复可能改变导入、格式甚至任务范围外的文件。修复结果合法不等于差异范围合理。第三类单元测试负责可重复的行为断言单元测试的价值不只是“多一项绿色结果”而是把关键规则变成可重复执行的断言。它适合验证数据转换和参数映射空值、边界值和错误分支状态转换组件输入输出契约指定用户动作后的可观察结果已修复问题的回归条件。单测能够证明什么在测试提供的输入、替身、环境和断言下被执行代码产生了预期结果。测试的证明力度来自断言不来自用例数量。一条只断言“组件能够挂载”的测试不能证明保存失败后输入会保留十个快照也不一定覆盖请求乱序。单测不能证明什么用例没有覆盖的分支正确测试替身与真实接口一致浏览器布局、焦点和原生行为正确测试实现没有复刻同一个错误假设公共组件的所有真实调用方式都兼容。我会先看测试为什么能抓住这次错误如果新增测试只是让当前实现变绿却无法说明旧实现为什么会失败这条测试的回归价值就很有限。我会让测试至少说明触发条件是什么观察哪个结果哪个错误实现会被它拦住是否覆盖了保持不变的行为。测试失败时也不能默认实现错了。还要判断需求变了、测试过时、环境异常还是实现真的偏离了既有行为。第四类构建负责集成到产物链构建位于更综合的一层。它关心代码、依赖、资源和配置能否进入目标产物流程。它适合发现入口或模块解析失败构建插件和资源处理问题生产配置下的转换错误缺失依赖和部分环境变量问题产物生成阶段的阻断错误脚本中串联的其他检查失败。构建能够证明什么当前命令、配置和环境下目标产物流程成功完成。构建不能证明什么用户能够完成目标操作接口返回与前端假设一致错误、空态、权限和连续操作正确页面没有遮挡、溢出和焦点问题没有被入口覆盖的代码也正确原有调用方行为没有变化。构建是“能进入交付产物”的证据不是“产物中的功能已验收”的证据。第五类页面验证负责真实用户路径页面验证把前四类检查没有覆盖的运行环境、真实交互和视觉状态带回来。它适合验证用户能否找到并触发入口点击、输入、选择、提交和关闭是否连贯请求参数、响应结果和页面状态是否对应Loading、空态、错误、禁用和恢复是否正确弹窗层级、长文本、窄屏和滚动是否可用焦点、键盘和连续操作是否符合要求直接受影响的原有路径是否保持。OpenAI 的 Codex QA 用例也强调执行真实流程前要明确测试环境、关键流程、账号或数据状态并用复现步骤、期望结果、实际结果和严重程度记录发现。对我来说这正好说明页面验证不能只写“打开看了一下”。页面验证能够证明什么在明确环境、数据、账号状态和操作步骤下被执行的路径产生了实际观察到的结果。页面验证不能证明什么没有走过的路径也正确一次手动操作能够替代稳定的回归测试所有尺寸、浏览器、角色和数据组合都已覆盖代码内部契约和全部调用方都安全偶然成功的异步路径没有竞态。页面验证同样有范围不能因为“我点过了”就无限扩大结论。一张五类验证职责矩阵我会用下面这张表做第一轮分工验证手段最擅长发现主要盲区交付时必须记录类型检查类型、签名、可空性、契约引用业务规则、真实数据、运行交互命令、配置、覆盖范围、结果Lint已配置的静态规则和高频模式未配置规则、业务与页面行为命令、规则范围、自动修复差异单元测试指定输入下的行为和回归断言未覆盖分支、真实浏览器与接口用例范围、关键断言、结果构建入口、依赖、资源、配置和产物流程业务、异常、视觉和回归行为目标环境、脚本定义、结果页面验证真实流程、状态、视觉和交互未执行路径、内部静态契约环境、数据、步骤、期望与实际这张表最重要的不是方便打勾而是防止一项证据替另一项越权。我怎样安排执行顺序一般情况下我会优先获得反馈快、定位直接的证据再进入成本更高的集成和页面验证。第 0 步确认真实入口先读取项目规则、脚本和测试配置确认使用什么包管理器有哪些真实脚本类型、Lint、测试和构建分别覆盖哪里是否需要生成代码、安装依赖或准备环境变量页面运行需要什么账号、数据和服务。不确认这些内容后面的命令结果很容易被误读。第 1 步运行最靠近改动的静态检查优先检查目标包、目标应用或相关文件能否通过类型和静态规则。反馈越靠近差异越容易快速定位。如果项目只有全量命令就使用真实全量命令如果项目支持可靠的局部检查也要说明局部范围不能把它写成全仓结果。第 2 步运行能覆盖目标行为的测试测试选择来自任务风险而不是文件名相似。修改参数转换就找能够断言输入输出的测试修改组件事件就覆盖事件时机、负载和旧调用方式修复异常恢复就让失败分支真正被触发。如果没有相关测试我会记录测试缺口再根据风险决定补测试还是依靠其他证据不会虚构“相关测试通过”。第 3 步进入目标构建链前面的直接错误处理以后再验证代码能否进入项目要求的产物流程。构建失败时根据失败阶段回到类型、依赖、资源或配置定位不要把所有问题都归因于刚修改的业务代码。第 4 步按用户路径验证页面页面验证必须从验收标准生成步骤。我会至少写清环境本地、测试或其他明确环境 账号与权限使用哪类角色 数据前置需要什么记录和状态 操作步骤按顺序列出 期望结果页面、状态、请求和提示分别怎样 实际结果实际观察到什么 剩余问题失败、阻断或未覆盖项如果环境不可用就把这一步标成未执行或无法验证并说明它阻断了哪条完成结论。第 5 步回到完整差异和影响范围验证过程可能新增测试、更新快照或触发自动修复。最后必须重新审查完整差异确认没有验证过程中产生的临时文件没有自动修复造成的无关变化所有差异仍能映射到任务目标或验证证据受影响调用方的回归范围没有遗漏失败和未验证项已经进入交付说明。验证不是差异审查之后的一条单行命令而是可能反过来改变差异的过程。不同任务怎样选择最小证据组合“最小”不是越少越好而是刚好覆盖关键风险。任务类型通常优先的证据不能轻易省略局部类型修正类型检查、相关测试、差异审查真实调用方契约纯数据转换类型检查、边界单测真实输入形状或契约依据列表查询与分页类型、相关测试、页面路径请求参数、连续操作和状态恢复表单提交类型、测试、页面路径校验、重复提交、失败恢复局部样式构建、页面视觉检查目标尺寸、长内容和相关状态公共组件类型、测试、构建、代表页面回归旧调用方、默认行为和公开契约构建配置目标构建、产物或运行检查对应环境与入口范围这张表只能做起点。真实项目已有检查能力、任务影响和失败代价才决定最终组合。检查失败后不要立刻让 Codex“全部修好”验证失败时我会先分类。本次修改引入失败与当前差异存在明确因果关系修复范围仍在任务内。回到当前批次修正再重新运行受影响检查。历史失败修改前已经存在且与当前任务无关。记录基线和对比证据不把它包装成本次通过也不要擅自扩展成全仓清理。环境失败依赖、服务、账号、数据、网络或配置不满足执行条件。说明缺失条件以及哪些结论因此无法得出。测试或规则过时需求和契约已经确认变化但旧断言或规则仍描述旧行为。先确认新的权威基线再更新测试不能为了让实现变绿就直接改期望值。原因未明保留失败输出和复现方式先定位不把猜测写成结论。这个分类能阻止一次局部前端需求在验证阶段突然膨胀成“顺手修完整个仓库”。验证结果不能只有通过和失败我使用四种状态状态含义已通过在明确范围和条件下执行成功未通过已执行并观察到与预期不符未执行当前没有运行该项检查无法判断已尝试但环境、基线或工具条件不足以形成结论其中“无法判断”和“未执行”不能写成绿色也不一定直接否定整个任务。它们要和任务风险一起判断是否阻断交付。例如局部文案修改没有相关单测可能不阻断公共组件契约修改无法运行调用方检查风险就明显不同。一份可以直接交给 Codex 的验证模板# 前端任务验证计划 ​ ## 1. 任务风险 - 目标行为 - 主要风险 - 直接影响 - 需要回归 ​ ## 2. 项目真实检查入口 - 包管理器 - 类型检查脚本与范围 - Lint 脚本与范围 - 测试脚本与范围 - 构建脚本与目标环境 - 页面启动与测试条件 ​ ## 3. 证据分工 ### 类型检查 - 要证明 - 不能证明 ​ ### Lint - 要证明 - 不能证明 ​ ### 单元测试 - 目标用例与关键断言 - 未覆盖 ​ ### 构建 - 目标应用与配置 - 不能替代的验证 ​ ### 页面验证 - 环境、账号和数据 - 路径、期望与实际 ​ ## 4. 执行结果 对每项使用已通过 / 未通过 / 未执行 / 无法判断 - 实际命令或操作 - 覆盖范围 - 关键结果 - 失败归类本次引入 / 历史失败 / 环境失败 / 规则过时 / 原因未明 ​ ## 5. 完整差异复查 - 自动修复或测试生成的变化 - 无关差异 - 回归范围 ​ ## 6. 最终结论 - 已有证据 - 未验证项 - 剩余风险 - 结论可接受 / 修复后复审 / 需要重新规划 / 证据不足模板中的“不能证明”是我最看重的一栏。它迫使每个绿色结果留在自己的职责范围内也让下一项验证为什么存在变得清楚。写在最后类型检查、Lint、单测、构建和页面验证不是同一张试卷的五次重复答题。类型检查守住契约Lint 执行静态规则单测固定关键行为构建检查产物链页面验证观察真实用户路径。每一种手段都重要也都不能独自宣布前端任务完成。我真正需要 Codex 交付的是一份匹配关系这次改动有哪些风险每项风险由什么证据覆盖检查在什么范围和条件下执行还有哪些事项没有得到证明。当这份匹配关系清楚以后验证才不再是“最后把命令跑一遍”而是前端任务闭环里可以复查、可以解释、也可以承担结论的一部分。下一篇会进入第 2 周 Day 6AI 改错以后到底应该让它继续修还是清理当前方案重新开始。我会先按目标理解、范围失控、局部实现、契约变化和环境问题给错误分类再选择纠偏方式。本系列持续更新。下一步会从“怎样证明改对”转向“发现改错以后怎样止损”继续完善 Codex 前端任务闭环。