第 2 周前六天我把 Codex 参与前端任务的几个关键环节逐个拆开了读项目、查调用链、评估影响、审查差异、分层验证以及发现错误后的纠偏。这些内容连起来以后很容易产生一个冲动既然这套做法有效是不是应该马上写进项目规则或者做成一个本地 Skill我现在会先踩刹车。一次对话顺利完成只能说明这套处理在当前目标、当前仓库和当前上下文中成立。它里面可能同时混着四种东西可以长期复用的工程原则只适用于这个仓库的项目约定只为当前任务成立的事实为了解决一次异常临时作出的选择。如果不先分开就把整段对话沉淀下来结果通常不是“Codex 更懂项目”而是规则越来越长、触发越来越泛、冲突越来越难解释。所以我不会问“这次做法好不好”而会让它先过四道门。沉淀之前先分清四类内容同一句经验应该放在哪里取决于它承担什么职责。第一类任务证据任务证据回答的是这一次为什么这样判断。例如当前页面的入口文件这次需求涉及的调用方当前接口返回的字段某条测试失败的具体输出某个页面路径的实际观察结果本轮纠偏保留和移除了哪些差异。这些信息非常重要但大多数不应该直接进入长期规则。调用方会变化接口会调整失败输出只属于当时环境。它们应该留在任务记录、代码差异、测试或项目文档中作为这次结论的依据。把任务证据写成长期指令最大的风险是事实过期以后Codex 仍然把它当作规则执行。第二类项目规则项目规则回答的是在这个仓库或目录中长期应该怎样做。例如使用哪种包管理器和真实检查命令组件、API、状态和路由的目录职责公共组件能否直接修改提交前必须运行哪些检查某个目录使用哪套命名和代码模式哪些生成文件不能手工编辑。这类内容通常更适合放在具有明确作用范围的AGENTS.md或仓库文档中。关键不是文件名而是规则能否贴近它实际约束的代码范围。全仓通用规则放上层目录特有规则放到更接近目标文件的位置避免一个页面的特殊做法变成整个项目的默认要求。第三类可复用流程可复用流程回答的是遇到一类重复任务时按什么步骤、使用什么资源、产生什么结果。例如接手陌生前端项目时怎样建立最小项目地图修改公共组件前怎样查调用链和影响范围前端差异怎样从正确性、范围和副作用三个层面审查一张后台列表页怎样按项目范式拆分搜索、表格、分页和弹窗一个发布流程要调用哪些已有脚本并输出什么报告。这类内容才是 Skill 的主要候选。它不只是几条口号而应包含触发条件、输入、执行顺序、可复用资源、验证方式和输出要求。OpenAI 官方的 Codex Skills 用例也把 Skill 放在“需要重复使用的工作”中并建议从已经能工作的示例、规则、命令、脚本和理想输出出发再创建并验证可复用能力。但“有一个成功示例”是起点不是通过证明。第四类临时判断临时判断回答的是在信息不完整或多种方案都合理时这一次选择什么。例如保存失败后当前业务选择保留还是回滚旧值一次局部需求是否允许顺手清理技术债当前版本先兼容旧字段还是直接迁移某个无法运行的页面验证是否阻断本次交付为了赶当前节点哪些非关键问题延后处理。这些决定通常依赖业务优先级、版本计划和当时风险不应该伪装成永久规则。它们可以记录为决策和背景下一次遇到相似场景时重新判断。如果把临时选择写进 SkillCodex 会在缺少原始条件的任务中重复执行一个已经失去前提的决定。第一扇门这件事真的会重复吗我先检查重复性而不是先进编辑器写SKILL.md。所谓重复不是两次任务里都出现了“写代码”而是下面这些核心部分保持相似输入信息相似决策步骤相似需要调用的资源或命令相似输出结构相似判断成功的方式相似。例如“所有前端任务都要注意质量”不算可复用流程它没有具体输入和动作。“修改公共组件前先列出公开契约、直接调用方、条件性入口、DOM 与样式依赖再输出修改、回归和排除范围”就更接近重复流程。我会问三个问题换一个页面或组件这套步骤仍然成立吗下一次是否还会人工复制相同检查和输出格式如果不沉淀最容易重复遗漏的是哪一步如果这套做法只服务一次迁移、一次事故或一个特殊页面我会把它留在任务记录里。不是所有经验都需要升级成工具。第二扇门规则是否足够稳定会重复还不够。有些工作虽然经常发生但每次关键决定都不同。例如表单失败后的产品行为、删除最后一条数据后的分页策略、不同业务的权限展示都可能需要重新确认。我会把候选流程拆成两部分。稳定骨架跨任务不轻易变化的内容先查项目事实再制定计划区分目标行为和保持不变项修改公共契约前检查调用方每一批改动都要有直接验证失败时先分类再决定修正、回退或重规划交付时列出已验证和未验证事项。可变参数每次必须从当前任务取得的内容目标页面与文件范围真实命令业务正常、异常和边界行为允许改变的公共契约当前环境与可用测试具体回归路径。Skill 应该固定稳定骨架并明确要求读取可变参数而不是把某一次参数写成永远正确的答案。如果一个候选规则无法区分“什么不变”和“什么每次要确认”它还不适合沉淀。第三扇门作用范围能不能说清楚好的规则不只说明什么时候使用还要说明什么时候不要使用。我会为每个候选项补齐四个边界边界要回答的问题触发条件什么任务出现时应该加载或执行不触发条件哪些相似任务不适用仓库范围全局、某个仓库、某个目录还是某类文件冲突处理与当前需求、近层规则或项目事实冲突时怎么办例如“后台列表必须使用某个列表封装”只有在项目确实采用该封装时才成立。如果另一个 Vue3 项目没有对应基础文件却仍然强制套用Skill 就从减少偏差变成制造偏差。所以我更愿意写先确认仓库是否存在并使用目标列表封装若存在按项目范式实现若不存在不创建同名体系冒充项目规则先查现有列表模式。这比“所有列表必须这样写”更可靠。范围清楚还能决定它应该放在哪里跨仓库重复的通用流程可以考虑个人 Skill团队和项目共同使用的流程可以考虑仓库级 Skill 或项目文档目录内的稳定编码要求更适合近层AGENTS.md一次任务的事实和决定留在任务本身。第四扇门能不能验证它确实被正确执行最容易被忽略的是可验证性。如果 Skill 执行以后只能得到“看起来更规范”我很难判断它到底减少了问题还是只是让输出更整齐。我会要求候选流程至少有三类验证中的一类。过程验证检查关键步骤有没有发生。例如是否先读取了项目规则和真实脚本是否输出了调用链与影响范围是否在扩大公共范围前暂停是否区分了已确认、推断和未知项。结果验证检查输出是否满足明确结构。例如差异审查是否包含触发条件、影响和证据验证报告是否记录命令、范围、结果和未验证项列表页范式图是否覆盖搜索、状态、接口、表格、分页和弹窗边界。反例验证给它一个不适用场景看它能否拒绝错误套用。例如仓库不存在目标封装时会不会自行创建一整套业务规则未确认时会不会擅自补默认行为只有环境失败时会不会修改业务代码用户已有差异存在时会不会尝试整体清理工作区。能处理正常任务不代表边界可靠。反例往往更能暴露一条规则是不是写得太宽。一张“应该放在哪里”的判断表内容推荐位置原因当前接口响应与失败输出任务记录、测试或项目文档属于当次证据可能变化仓库命令、目录职责和禁止项AGENTS.md或仓库文档与代码作用范围紧密相关重复执行的审查、生成或验证流程Skill有稳定步骤、资源和输出当前版本的业务取舍决策记录或任务说明依赖当时条件不应永久自动执行可以机器运行的检查项目脚本或 CI由工具直接执行比文字提醒可靠Skill 如何调用已有检查Skill编排入口与输出但不复制工具实现这里还有一个原则能用项目脚本稳定执行的规则不要只写成自然语言提醒。Skill 可以调用检查、整理结果和决定下一步但不应该重新发明已经存在的 Lint、测试或构建逻辑。我怎样处理一条候选经验我会按下面的顺序处理而不是直接创建 Skill。第一步只提取一个明确问题不要把一次完整对话全部打包。例如从一项前端任务中只提取“公共组件修改前的影响评估”而不是把需求、实现、调试、提交说明全部塞进同一个流程。一个 Skill 有一个清楚职责更容易触发、验证和维护。第二步删掉当前任务专属信息移除页面名、临时字段、一次性接口、当时失败输出和没有普遍依据的业务选择。保留稳定步骤、需要读取的输入、必须暂停的条件和可复用模板。第三步写清触发与拒绝条件除了“何时使用”还要明确哪些仓库基础必须存在哪些信息缺失时只能调查哪些业务选择必须交还给人哪些范围扩大需要重新规划哪些工具结果不能替代页面验收。第四步用另一类相似任务复核不是复制原任务而是换一个具有相似结构、不同业务参数的场景检查稳定骨架是否仍然成立。如果每换一个页面都要重写大部分规则说明沉淀对象可能只是项目示例还不是流程。第五步保留更新入口项目和工具会变化。候选流程需要知道真实命令从哪里读取项目规则冲突时以什么为准哪些内容需要随仓库更新发现反例以后如何调整触发或边界哪些旧规则应该删除而不是继续叠加。沉淀不是把经验封存而是让它进入可以验证和修订的生命周期。一份可直接使用的规则候选卡# 规则或 Skill 候选卡 ​ ## 1. 要解决的重复问题 - 问题 - 常见遗漏 - 为什么值得复用 ​ ## 2. 稳定性 - 不随任务变化的步骤 - 每次必须重新读取的参数 - 仍然依赖人工决定的内容 ​ ## 3. 作用范围 - 触发条件 - 不触发条件 - 适用仓库或目录 - 与近层项目规则冲突时 ​ ## 4. 可复用资源 - 项目脚本 - 模板 - 示例 - 权威文档 ​ ## 5. 验证方式 - 过程检查 - 结果检查 - 反例 - 失败时的停止条件 ​ ## 6. 放置结论 - 任务记录 / 项目文档 / AGENTS.md / Skill / 项目脚本 - 依据这张卡的价值是允许候选经验得到“暂不沉淀”的结论。不成熟的规则留在候选区比过早进入所有任务更安全。写在最后一次成功的 Codex 对话可以成为 Skill 的素材但不能直接等同于 Skill。我会先区分任务证据、项目规则、可复用流程和临时判断再让候选经验通过四道门是否真的重复稳定骨架是否清楚作用范围是否明确执行结果是否能够验证。通过以后再决定放进项目脚本、AGENTS.md、仓库文档还是 Skill。没有通过就留在当前任务或候选记录里不为了“体系化”强行升级。下一篇我会完成第 2 周的最后一次收束在第一版闭环基础上加入影响范围、差异审查、分层验证和错误纠偏三条控制回路整理成 Codex 前端任务闭环第二版。本系列持续更新。第二版完成后下一阶段会把这套闭环放进 Vue3 与 Element Plus 后台列表场景中开始验证它在具体页面任务里的适用边界。