mcpField
A
avoid-feature-creep

avoid-feature-creep

github.com/waynesuttonAgent 工作流4051.3k 次安装4 周前更新
代码仓库

关于 avoid-feature-creep

avoid-feature-creep 是面向编码 Agent 和开发者的技能，帮助实现范围紧扣明确请求。它提供范围膨胀信号、检查问题，以及将额外想法留作建议的流程。

主要功能

  1. 01让改动对应明确请求
  2. 02识别范围扩大的信号
  3. 03将额外事项留作建议
  4. 04用引导问题检查范围
  5. 05将范围约束用于 PRD

适用场景

  1. 01将缺陷修复限制在所请求的改动内
  2. 02审查 Agent 提出的实现方案
  3. 03区分产品需求与未来设想

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/waynesutton/builder-skills --skill avoid-feature-creep

安装后在 Claude Code 中输入/avoid-feature-creep确认已加载。

附带文件agents/openai.yamlassets/small-logo.svg

详细介绍

避免功能蔓延

请求决定范围。差异中的所有内容都应能追溯到请求中的某句话。其他内容都只是建议，不是变更。

核心规则

只做用户要求的内容。不要做那些“更好”的东西、资深工程师也会顺手做的东西，或代码库“本该有”的东西。如果差异中的某一行无法用请求来解释，它就不该出现在差异中。

这既适用于产品范围，也适用于代码范围。PRD 一旦超出问题陈述的范围，和一个顺带重构的 Bug 修复，犯的是同一种毛病。

功能蔓延开始的信号

注意到以下任何一种情况时，就该停下来：

  • 你的推理中出现了“既然都在这里了”或“不如顺便”
  • 为没人提出的情况添加配置选项、标志或参数
  • 因为改动附近的代码看起来不整洁，就去重构它
  • 为了让第一个功能看起来完整，又添加了第二个功能
  • 为用户从未遇到过的边缘情况添加错误处理
  • 为变更范围之外的代码添加测试、类型或文档
  • 将一次性实现泛化为可复用的抽象
  • 没有明确的用户需求，却照搬竞品功能
  • PRD 中名为“未来”或“锦上添花”的章节越来越长
  • 改动涉及了请求中从未提及的文件

这些想法可能都不错。但除非用户提出，否则都不在范围内。

应该怎么做

  1. 完成请求。交付能够完整满足请求的最小改动。
  2. 随手记录额外想法，但不要着手实施。
  3. 最后把它们集中到一处：
    • 在聊天或 PR 摘要中，放在 Suggestions 标题下，每条一行
    • 在 PRD 中，放在 Out of scope 下，并用一句话说明原因
    • 如果代码库中有 prds/ 文件夹，就将它们追加到相关 PRD 的 Out of scope 部分
  4. 让用户决定。“Agent 觉得不错”不代表获得了批准。

写下建议成本很低，忽略它们也不费事。未经请求的代码会增加审查时间、引入 Bug，还会模糊这次改动的目的。

利益相关者，包括 Agent

每个功能请求都有来源：PM、高管、用户、想解决某个痛点的开发者，或 AI 编码 Agent。对他们一视同仁。记录请求，结合当前范围进行权衡；除非请求能解决这项工作最初要解决的问题，否则就先搁置。

AI Agent 也是利益相关者。它们有自己的意见，而且会积极推动。常见的 Agent 驱动型功能蔓延包括：

  • “我再为你还没遇到的边缘情况添加一下错误处理”
  • “重构一下会更整洁”
  • “你最好为这个添加测试”
  • “我为这些额外场景添加了类型”

如果你是 Agent，发现自己正在这样做时，就把这些想法移到建议列表中。如果你正在与 Agent 合作，就在会话开始时说明范围，并像对待其他利益相关者的要求一样看待它提出的额外事项。

添加任何内容前，先问自己：

  • 这能解决请求中提到的问题吗？
  • 能正常工作的最小版本是什么？
  • 如果我们永远不做这件事，会怎样？

如果第一个问题的答案是否定的，就把它列入建议。

前后对比

请求：“为任务添加 deletedAt 字段，并在列表查询中隐藏已删除的任务。”

之前，功能蔓延版：

  • 在架构中添加 deletedAt
  • 添加 by_user_and_deleted 索引
  • 重写 list，让它使用该索引
  • 添加 softDelete、restore 和 purgeDeleted 变更
  • 添加一个在 30 天后清理数据的 cron
  • 将 list 重命名为 listActive，并更新三个调用处
  • 添加一个 showDeleted 参数，“以便以后用于管理界面”

之后，限定范围版：

  • 在架构中添加 deletedAt: v.optional(v.number())
  • 添加索引并让 list 使用它，这样已删除的行就不会被加载

随改动发送的摘要：

Done: deletedAt field and list query now skips deleted tasks.

Suggestions
- A softDelete mutation to set deletedAt (nothing sets it yet)
- A restore mutation
- A cron to purge rows older than 30 days
- An admin flag on list to include deleted rows

两行差异就满足了请求。四条建议保留了所有想法。接下来怎么做，由用户决定。

PRD

PRD 的每个部分都必须回扣其问题陈述。PRD 越写越长时：

  • 重新阅读问题陈述。删掉任何与之无关的内容。
  • 将删掉的内容移至 Out of scope，并为每项说明一个理由。
  • 如果删掉的内容构成一项完整的功能，那就应该是第二份 PRD，而不是扩充第一份。

检查清单

  • 每个改动的文件都能从请求中推导出来
  • 没有新增请求未要求的配置选项、标志或参数
  • 没有重构相邻代码
  • 没有为了完善第一项功能而添加第二项功能
  • 没有为改动范围之外的代码添加测试、类型或文档
  • 额外内容列在摘要的 Suggestions 下，或 PRD 的 Out of scope 下
  • 摘要先用一行说明完成了什么，再列出建议
  • 如果用户说了“只做我要求的事”，差异中就只包含这些内容

评论

支持 Markdown