上一篇写完差异审查清单后下一步自然会遇到一个问题代码看过了命令也跑绿了这项前端任务是不是就能结束我的答案通常是还不能只凭这一项结束。构建通过当然有价值。它能帮助我发现模块解析、语法转换、资源处理、配置和打包过程中的一部分问题。问题不在于构建没用而在于我们经常让它承担了超出能力边界的证明责任。我见过一种很有诱惑力的交付方式修改已完成。 构建命令执行成功。 功能可以正常使用。前两句话之间可能有证据关系第二句与第三句之间却缺了一大段。构建成功只能说明构建流程成功不能自动推出用户路径正确。把两者直接连起来就是前端任务里很常见的“假完成”。先问清楚所谓“构建通过”到底运行了什么我不会先讨论构建结果而会先确认命令本身。不同仓库中下面这些命令可能代表完全不同的检查组合build可能只执行打包build可能先执行类型检查再打包类型检查可能只覆盖某个应用或某份配置Lint 可能检查整个仓库也可能只检查特定目录测试脚本可能进入监听模式也可能一次性退出CI 中的脚本可能比本地脚本多出环境校验、生成步骤或其他检查。所以“构建通过”至少要补齐四项信息项目要回答的问题实际命令完整运行了哪个脚本而不是口头上的“构建”脚本定义它串联了哪些工具与子命令覆盖范围检查了哪个应用、目录、配置和环境执行结果是否完整退出是否存在警告、跳过项或环境限制这一步看起来基础却能挡住很多错误推断。如果没有先读项目脚本Codex 可能运行一个名称相似但覆盖范围不同的命令如果只看到退出码不看脚本定义我们也可能把“打包成功”误写成“类型、测试和页面都验证过”。构建通过通常能证明什么在具体项目里必须以真实脚本和工具配置为准。一般来说构建成功最多能支持下面几类结论中的一部分代码进入了当前构建链入口、模块和资源能够被当前构建配置处理没有在这一流程里遇到阻断错误。注意这里说的是“进入当前构建链”。没有被入口引用的代码、被条件排除的代码、另一个应用中的代码不一定因此得到检查。静态依赖在当前条件下能够解析导入路径、依赖包和构建插件至少在当前环境里完成了解析。这不等于所有运行时加载都正确。动态路径、远程资源、权限数据和接口返回仍然需要其他证据。产物能够被生成构建工具完成了转换和产物输出没有出现阻断打包的错误。产物能生成是交付链条中的必要信号但它仍然没有回答产物运行后的业务行为。脚本中显式串联的检查已经执行如果真实脚本明确包含类型检查、Lint 或测试那么这些被串联的检查可以分别记录结果。我不会因为它们都藏在一个build命令里就把证据合并成一句“全部正常”。每一种检查仍然要按自己的证明边界解释。构建通过不能自动证明什么真正需要警惕的是下面五个跳跃。第一不能自动证明业务规则正确下面这类代码完全可能通过类型和构建const handleReset () { form.name fetchList() pageNum.value 1 }如果fetchList在调用时读取pageNum请求仍可能带着旧页码发出。每一个变量都有类型函数也能被打包但“重置后从第一页查询”这个业务结果并没有成立。构建工具不知道产品要求先重置页码还是先请求也不知道哪些状态必须保持不变。业务正确性需要行为路径、数据观察或有针对性的断言来证明。第二不能自动证明异常和连续操作正确一次正常提交成功不等于下面这些路径也成立连续点击两次会不会重复请求校验失败后按钮状态会不会恢复保存失败后用户输入是否保留关闭弹窗再打开是否残留旧数据前一个请求晚返回时是否覆盖新结果组件卸载后异步结果是否继续回写。这些问题依赖时间、状态和操作顺序。构建过程不会替用户点击两次按钮也不会主动制造请求乱序。如果需求涉及异步、生命周期或连续操作只有构建结果就宣布完成证据一定不够。第三不能自动证明真实接口和数据契约成立TypeScript 类型描述的是代码当前相信的数据形状不是服务端一定返回的数据形状。例如前端定义interface UserDetail { enabled: boolean }如果真实响应使用status: 1而转换层没有处理构建仍然可以成功。错误只会在真实响应进入页面时暴露。接口相关任务还需要回答请求参数是否在正确时机生成空值、枚举和日期是否按契约转换业务失败与网络失败是否被区分响应是否经过项目约定的适配层成功后的刷新使用了服务端结果还是旧表单数据。这部分需要接口契约、测试替身、网络请求或可用联调环境提供证据。第四不能自动证明页面视觉和交互可用前端有大量问题不会让构建失败弹窗被遮挡操作列在窄屏下不可见长文本撑破布局Loading 覆盖范围错误错误提示被立即清掉焦点无法进入新增字段按钮看得见却因为透明遮罩无法点击DOM 结构变化使深层样式或测试选择器失效。CSS 合法不等于布局正确事件绑定合法也不等于交互顺畅。真实页面验证的价值就是让代码进入浏览器、进入目标尺寸、进入具体状态再观察用户能否完成任务。第五不能自动证明没有回归构建通常关注“当前代码能否产出”不负责证明“原有行为全部保持不变”。一个公共组件默认值被改变所有调用方仍然可以编译一个事件触发时机被提前类型签名仍然一致一个全局样式选择器扩大构建产物也能正常生成。这些改动的危险在于新的目标路径可能正常旧调用方却悄悄改变。回归证据必须根据前面建立的调用链和影响范围来选择不能用一次全局构建代替。四类“绿色但未完成”的前端信号我会特别警惕下面四种交付说明。只有退出码没有命令范围只写“命令成功”没有说明脚本定义、覆盖目录和环境。这时我知道有一条命令是绿的但不知道它证明了什么。只有正常路径没有失败与连续路径只验证打开、填写、保存成功没有检查失败恢复、重复操作和关闭重开。这通常意味着功能演示可以完成但状态机还没有验收。只有代码推断没有运行证据交付说明使用“应该”“理论上”“预计不会影响”等词却把结论写成“已完成”。推断可以帮助确定下一步检查不能伪装成已经观察到的结果。只有新增功能没有原有路径回归目标按钮能用了就结束验证公共契约、共享状态和受影响调用方没有检查。这会把副作用推迟到其他页面暴露。我用四个问题判断证据够不够Codex 提交结果后我会连续问四个问题。1. 这条检查实际覆盖了什么是整个仓库、单个应用、一个测试文件还是一条页面路径证据没有覆盖范围就不能用于扩大结论。2. 它用什么机制发现错误类型检查依赖类型关系Lint 依赖静态规则单测依赖断言构建依赖构建链页面验证依赖真实运行与观察。每种机制能看到的错误不同。3. 它是否直接对应本次风险如果任务修改的是弹窗焦点运行与焦点无关的工具并不能证明目标完成如果任务修改纯数据转换针对转换函数的测试通常比盲目点完整页面更直接。证据要与风险匹配不是数量越多越好。4. 还有什么没有验证我会要求把未知项单独列出而不是用一句“其余应该没问题”收尾。未验证并不可怕。最危险的是把未验证写成已通过让后续接手的人失去风险判断依据。完成结论应该是一条证据链我现在更愿意把前端任务的完成条件写成下面这条链任务目标 → 实际差异 → 静态约束 → 相关行为 → 真实页面 → 影响范围回归 → 未验证项这条链不要求每个小任务都运行所有工具而是要求每一个关键风险都有对应证据。例如下面只是一个方法示例不代表任何具体项目的实际结果## 完成证据 ​ ### 任务目标 - 重置筛选条件后从第一页按默认条件重新查询。 - 每页数量保持不变。 ​ ### 差异范围 - 仅修改目标列表页和对应测试。 - 未修改公共分页组件与请求封装。 ​ ### 自动检查 - 类型检查已运行记录实际命令与结果。 - 相关测试覆盖重置前后的页码、条件和请求顺序。 - 构建已运行记录目标应用与结果。 ​ ### 页面路径 - 查询 → 翻页 → 重置。 - 请求失败 → 检查条件与 Loading 恢复。 ​ ### 回归 - 普通查询和翻页行为保持不变。 ​ ### 未验证 - 明确记录当前环境无法覆盖的事项及原因。如果当前任务只是文案调整证据链可以很短如果修改公共组件、权限或异步状态证据链就必须更完整。我判断深度时看的是失败代价和影响范围不是修改行数。让 Codex 汇报“证明了什么”不要只汇报“跑了什么”我会把验证要求写成这样的结构请基于仓库真实脚本完成验证不要猜测命令。 ​ 对每项检查分别报告 1. 实际命令或操作路径 2. 覆盖范围和运行环境 3. 结果与关键输出 4. 这项结果能够证明什么 5. 不能证明什么 6. 未执行或无法执行的原因。 ​ 不要用构建通过替代业务、页面和回归验证。 如果证据不足请将结论写成“未验证”不要推断为通过。这个要求的作用不是让报告变长而是阻止工具结果越权。写在最后构建通过是一条重要证据但它不是前端任务的最终判决。我会先确认构建命令真实做了什么再判断它覆盖了哪些文件、哪些规则和哪些环境。随后把业务路径、数据契约、异常状态、页面交互和影响范围分别交给合适的验证方式。只有当关键风险都能找到对应证据剩余未验证项也被如实记录我才会把 Codex 的修改写成“任务完成”。下一篇会继续拆解类型检查、Lint、单元测试、构建和页面验证的职责每一种手段最适合发现什么问题、不能替代谁以及怎样按反馈成本和任务风险安排执行顺序。本系列持续更新。第 2 周 Day 5 的下一篇会把今天的“证据边界”整理成一张可直接复用的前端验证矩阵。