Vibe Coding 的后半场：把“能跑”变成“能活”的维护 Skill
过去一阵子，vibe coding 最容易让人上头的部分是“十分钟做完一个功能”。但最近三个月在 X 上，越来越多开发者开始把注意力放到另一个问题上：
这段 AI 生成的代码，下周还改得动吗？
这也是我很认同的一个观点：vibe coding 的前半场是生成，后半场是维护。
为什么“维护 Skill”会突然重要
最近的讨论里，一个很实用的方向是把维护动作独立成 Skill，而不是每次靠人临场提醒。它针对的不是“实现需求”，而是这些更容易被忽略的工程动作：
- 把膨胀文件拆回合理模块
- 去掉重复逻辑和 copy-paste 代码
- 补最小必要测试
- 清理无用依赖和临时配置
- 更新文档和运行说明
- 在真正落盘前做一次结构性审查
这些动作单看都不性感，但它们决定了项目能不能继续长。
维护 Skill 解决的不是“懒”，而是上下文丢失
很多 vibe coding 项目会烂尾，不是因为模型写不出代码，而是因为后续几轮对话里，维护标准开始漂移：
- 今天让它拆文件，明天忘了
- 这次补测试，下次没提就不补
- 上轮要求保留风格，这轮又变了
Skill 的价值在于把这些维护要求变成固定入口。这样每次调用的不是一句模糊的“顺便整理一下”，而是一套稳定流程。
一个实用的维护工作流
如果你现在就在用 Claude Code、Codex 或其他带 skills 的 agent，我建议把维护流程拆成四步：
1. 先做结构检查
让 agent 先回答：
- 最大的技术债在哪里
- 哪些文件已经超过合理复杂度
- 哪些模块耦合过重
2. 再做小步重构
不要一句“全部重构”。更稳的做法是：
- 一次只改一个切面
- 每次都要求保留行为不变
- 先跑测试，再决定是否继续扩散
3. 把维护动作写进 Skill
把这些要求固化进去：
- 命名风格
- 模块边界
- 测试底线
- 文档更新要求
- 什么时候必须停下来请求人工确认
4. 把维护和交付拆开
交付 Skill 关注“完成功能”，维护 Skill 关注“让代码还能继续活”。这两个目标不要混成一次模糊的对话。
我的判断
vibe coding 接下来最值钱的能力，不是“谁一条 prompt 能写更多代码”，而是：
谁能把维护经验编码成可重复调用的 Skill。
生成只是让项目启动，维护 Skill 才能让项目不塌。
来源
- X.com：关于 vibe coding maintenance skill 的讨论
- Claude Code 官方 skills 文档