2026/8/19

Agent Skill「feature-forge」:给存量项目安全地加功能

在已有项目上迭代功能的工作流:审阅 → 功能清单 → 备份 → 任务书 → 施工 → 验收,不破坏既有架构。

痛点:在跑得好好的存量项目上改新功能,最怕一改就破坏原来的东西

存量项目是「跑得好好的」状态,往上面加新功能,心里总悬着几件事:

  • 一改就破坏原来的东西:新功能没加好,旧功能先挂了,线上事故比功能上线还快。
  • 没有清单:要动哪些地方全凭记忆,改到哪算哪,漏了也不知道。
  • 没有备份:改坏了想回退,发现退不回去,只能对着 git log 干瞪眼。
  • 需求做偏:只给了个「加个按钮」的说法,做出来和预期差一大截。

存量项目迭代,风险不在「写新代码」,而在「动了不该动的地方还不自知」。feature-forge 就是给这个过程上一套保险。

适用场景

  • 已有项目要加新功能,项目正在稳定运行。
  • 重构局部,但整体架构不能动。
  • UI 迭代,在现有页面体系上做改动。

流程怎么用

① 审阅项目,逐条记功能清单

先逐页审阅整个项目,把要动的功能逐条记成功能清单:哪些地方会受影响、哪些是存量逻辑不能碰、哪些是新增的。清单让改动范围可视化,也防止改到一半忘了还有别的地方要同步改。

② 备份现状(可回退)

动手前先备份现状,确保任何一步出错都能回退到原来的状态。改坏了不可怕,退不回去才可怕——备份就是那个兜底的开关。

③ 写任务书,只给「功能清单 + 工程红线」

任务书里只写两样东西:

  • 功能清单:这次要做什么,逐条列清。
  • 工程红线:哪些绝对不能碰,比如既有架构、核心接口、性能底线。

至于布局怎么排、具体怎么实现,把决策自由度交给工具。约束给足但不越界,工具才有发挥空间,也不会跑偏。

④ 施工

按功能清单逐条施工,一条完成再进下一条。因为前面有清单和红线兜着,这个阶段可以放手推进,不用步步请示。

⑤ 逐条验收

完工后按功能清单逐条验收,每条确认「确实做了、且没影响旧功能」。验收不是走形式——它是「不破坏既有东西」这件事的最后一道确认。

关键

功能清单 + 备份 + 验收闭环,这三样齐了,改存量项目才不慌。清单管「改什么」,备份管「退得回」,验收管「没改坏」。缺一个,迭代就是在裸奔。

返回文章列表