使用 codex 拯救旧项目
用 Skills 把需求、执行、验证串成闭环
旧项目最难的，往往不是缺功能，而是改不稳。需求不断进入，改动范围不断扩散，最后团队很难回答一个问题：这次修改到底有没有真正完成。我这次的做法很简单：不先写代码，先把流程固定住。核心不是重构，而是把每次改动都放进一条可重复的交付链路里。
我重点用了哪些 Skills
writing-plans
作用：把模糊需求拆成可执行任务，提前写清目标、边界、改动点、验证项。
价值：避免想到哪改到哪。
executing-plans
作用：执行阶段严格按任务清单推进。
价值：减少中途偏航和范围膨胀。
subagent-driven-development
作用：把复杂需求拆成清晰子块，分责任推进。
价值：复杂改动也能保持可控节奏。
systematic-debugging
作用：先定位根因，再改代码。
价值：不靠猜，不靠试错堆 patch。
verification-before-completion
作用：把看起来没问题升级为有证据地完成。
价值：把质量判断从主观变客观。
playwright-interactive
作用：跑关键用户路径回归，验证页面操作链路。
价值：补齐单测看不到的真实交互风险。
这套流程怎么落地
- 先写计划，再编码
每个任务都包含：做什么、不做什么、改动步骤、验证命令。
- 执行中允许改计划，但不改目标
可以调整顺序和颗粒度，但每次调整都必须落到可验证动作。
- 只做当前需求直接相关改动
不顺手重构，不顺手优化，不引入额外复杂度。
- 用双层验证收口
单元测试验证契约和数据行为；Playwright 验证核心业务路径。
结论
这次实践最有价值的不是产出多少代码，而是把开发过程做成了机制：
Skills 约束方法 + plan 约束范围 + 验证约束质量。把 codex 当流程引擎用，旧项目就能从高风险改动走向稳定迭代。