avoid-feature-creep
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseAvoid Feature Creep for Agents
避免功能蔓延：面向开发者与AI Agent的指南
Stop building features nobody needs. This skill helps you ship products that solve real problems without drowning in unnecessary complexity.
Feature creep kills products. It delays launches, burns budgets, exhausts teams, and creates software nobody wants to use. The most successful products do fewer things well.
停止开发无人需要的功能。此方法帮助你交付能够解决实际问题的产品，避免陷入不必要的复杂之中。
功能蔓延会毁掉产品。它会延迟发布、耗尽预算、拖垮团队，最终打造出无人愿意使用的软件。最成功的产品往往是把少数事情做到极致。
The Core Problem
核心问题
Feature creep is the gradual accumulation of features beyond what your product needs to deliver value. It happens slowly, then all at once.
Warning signs you're in trouble:
- Release scope keeps growing without clear user value
- You're copying competitor features without validating need
- Stakeholders keep adding "just one more thing"
- The codebase is getting harder to maintain
- Users complain the product is confusing or bloated
- You haven't shipped in months
What it costs:
- Development time on features 80% of users never touch
- Increased bug surface area
- Team burnout and context switching
- Delayed time-to-market
- Technical debt that compounds
- User confusion and abandonment
功能蔓延是指产品逐渐累积超出其核心价值需求的功能。它的发生是一个缓慢的过程，最终会突然爆发。
预警信号：
- 发布范围持续扩大，但没有明确的用户价值支撑
- 盲目复制竞品功能，未验证用户需求
- 利益相关者不断提出“就再加一个功能”的要求
- 代码库维护难度越来越大
- 用户反馈产品复杂、臃肿
- 数月未发布新版本
造成的损失：
- 80%用户从未使用的功能占用大量开发时间
- 潜在bug数量增加
- 团队 burnout 与频繁上下文切换
- 上市时间延迟
- 技术债务不断累积
- 用户困惑与流失
Decision Framework
决策框架
Before adding ANY feature, run through this checklist:
1. VALIDATE THE PROBLEM
□ Does this solve a real, validated user pain point?
□ Have we talked to actual users about this need?
□ What evidence supports building this?
2. CHECK ALIGNMENT
□ Does this support the core product vision?
□ Would this delay our current release?
□ What are we NOT building if we build this?
3. MEASURE IMPACT
□ How will we know if this feature succeeds?
□ What KPIs will change?
□ Can we quantify the value (time saved, revenue, retention)?
4. ASSESS COMPLEXITY
□ What's the true cost (build + test + maintain + document)?
□ Does this add dependencies or technical debt?
□ Can we ship a simpler version first?
5. FINAL GUT CHECK
□ Would we delay launch by a month for this feature?
□ Is this a differentiator or just table stakes?
□ Would removing this harm the core experience?If you can't answer YES to questions 1-3 with evidence, do not build the feature.
在添加任何功能之前，先完成以下检查清单：
1. 验证问题真实性
□ 该功能是否解决真实且经过验证的用户痛点？
□ 我们是否与真实用户沟通过此需求？
□ 有哪些证据支持开发此功能？
2. 检查对齐性
□ 该功能是否符合核心产品愿景？
□ 它会延迟当前版本的发布吗？
□ 如果开发此功能，我们将放弃开发哪些其他功能？
3. 衡量影响
□ 我们如何判断该功能是否成功？
□ 哪些关键指标（KPI）会发生变化？
□ 能否量化其价值（如节省时间、增加收入、提升留存）？
4. 评估复杂度
□ 真实成本是多少（开发+测试+维护+文档）？
□ 会增加依赖或技术债务吗？
□ 能否先发布一个更简化的版本？
5. 最终直觉检查
□ 我们是否愿意为该功能延迟一个月发布？
□ 这是差异化功能还是行业标配？
□ 如果去掉此功能，会影响核心用户体验吗？如果无法为前3项问题提供有证据支持的肯定答案，请勿开发该功能。
Scope Management Rules
范围管理规则
Rule 1: Define and Defend Your MVP
Write down exactly what "done" means before you start. Document what you're NOT building. Reference this constantly.
markdown
undefined规则1：定义并坚守你的MVP
在开始开发前，明确写下“完成”的定义。记录下我们不会开发的内容，并持续参考这份文档。
markdown
undefinedMVP Scope Document Template
MVP范围文档模板
Core Problem
核心问题
[One sentence describing the user problem]
[一句话描述用户面临的问题]
Success Criteria
成功标准
[How we know we've solved it]
[我们如何判断问题已解决]
In Scope (v1)
包含范围（v1版本）
- Feature A: [brief description]
- Feature B: [brief description]
- 功能A：[简要描述]
- 功能B：[简要描述]
Explicitly Out of Scope
明确排除范围
- Feature X: Deferred to v2
- Feature Y: Will not build unless [condition]
- Feature Z: Not our problem to solve
- 功能X：推迟至v2版本
- 功能Y：仅在[特定条件]满足时开发
- 功能Z：不属于我们要解决的问题
Non-Negotiables
不可协商项
- Ship by [date]
- Budget: [hours/dollars]
- Core user: [specific persona]
**Rule 2: Use Version Control for Scope**
Treat scope like code. Track changes. Require approval for additions.
```bash- 发布日期：[具体日期]
- 预算：[工时/费用]
- 核心用户：[具体用户画像]
**规则2：用版本控制管理范围**
像对待代码一样对待范围。跟踪变更，添加功能需要经过审批。
```bashCreate a scope document and track it
创建范围文档并跟踪
git add SCOPE.md
git commit -m "Initial MVP scope definition"
git add SCOPE.md
git commit -m "Initial MVP scope definition"
Any scope changes require explicit commits
任何范围变更都需要明确提交
git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"
**Rule 3: The 48-Hour Rule**
When someone requests a new feature, wait 48 hours before adding it to the backlog. Most "urgent" requests feel less urgent after reflection.
**Rule 4: Budget-Based Scoping**
Every feature has a cost. When something new comes in, something else must go out.
"Yes, we can add that. Which of these three features should we cut to make room?"git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"
**规则3：48小时规则**
当有人提出新功能需求时，等待48小时再将其加入待办事项。大多数“紧急”需求经过思考后会变得不再紧急。
**规则4：基于预算的范围规划**
每个功能都有成本。当有新需求加入时，必须移除其他功能来腾出空间。
“是的，我们可以添加这个功能。那我们应该砍掉以下三个功能中的哪一个来腾出资源？”Saying No
如何说“不”
Saying no to features is a skill. Here are templates:
To stakeholders:
"That's an interesting idea. Based on our user research, it doesn't solve our core user's top three problems. Let's add it to the v2 consideration list and revisit after we validate the MVP."
To executives:
"I understand the value this could bring. If we add this, we'll delay launch by [X weeks] and deprioritize [Y feature]. Here are the trade-offs - which path should we take?"
To users:
"Thanks for the feedback. We're focused on [core problem] right now. I've logged this for future consideration. Can you tell me more about why this would be valuable?"
To yourself:
"Is this scratching my own itch or solving a real user problem? Would I bet the release date on this?"
To AI agents (Claude, Opus, Codex, Ralph, Cursor):
"Stop. Before we add this feature, answer: Does this solve the core user problem we defined at the start of this session? If not, add it to a DEFERRED.md file and stay focused on the current scope."
When working with AI coding agents:
- State your scope constraints at the start of every session
- Agents will suggest improvements. Most are out of scope.
- Treat agent suggestions like stakeholder requests: apply the 48-hour rule
- If an agent keeps pushing a feature, ask "Why?" three times to find the real need
拒绝功能需求是一项技能。以下是一些沟通模板：
对利益相关者：
“这是个有趣的想法。根据我们的用户研究，它并未解决核心用户的三大痛点。我们将其加入v2版本的考虑清单，在验证MVP后再重新评估。”
对高管：
“我理解这个功能的价值。如果添加它，我们将延迟发布[X周]，并优先放弃[Y功能]。这是相关的权衡方案，我们应该选择哪条路径？”
对用户：
“感谢你的反馈。我们目前专注于解决[核心问题]。我已将此需求记录在未来版本的考虑清单中。能否详细说明这个功能对你的价值？”
对自己：
“这是在满足我自己的需求，还是解决真实的用户问题？我是否愿意用发布日期来赌这个功能？”
对AI Agent（Claude、Opus、Codex、Ralph、Cursor等）：
“停。在添加此功能前，请回答：它是否解决了我们在会话开始时定义的核心用户问题？如果没有，将其加入DEFERRED.md文件，继续专注于当前范围。”
与AI编码Agent协作时：
- 在每次会话开始时明确说明范围约束
- Agent会提出改进建议，其中大多数超出当前范围
- 将Agent的建议视为利益相关者的需求，应用48小时规则
- 如果Agent持续推动某个功能，连续问三次“为什么”以找到真实需求
AI-Specific Guidelines
AI产品专属指南
When building AI-powered products, feature creep has extra risks:
AI Feature Creep Red Flags:
- Adding AI because "everyone else is"
- Building AI summaries without validating users want them
- Multiple AI features without clear differentiation
- AI capabilities that don't connect to core user workflows
AI Feature Discipline:
- One AI feature at a time
- Validate the use case with users first
- Measure actual usage, not just availability
- Question: "Does the AI make the core task faster or better?"
Before adding any AI feature, answer:
- What specific task does this automate?
- How is this better than the non-AI alternative?
- What happens when the AI is wrong?
- Can we ship without this AI feature?
开发AI驱动产品时，功能蔓延存在额外风险：
AI功能蔓延预警信号：
- 因为“别人都在做”而添加AI功能
- 在未验证用户需求的情况下开发AI摘要功能
- 多个AI功能之间没有明确的差异化
- AI能力与核心用户工作流程无关
AI功能纪律：
- 一次只开发一个AI功能
- 先与用户验证使用场景
- 衡量实际使用率，而非仅关注功能是否可用
- 自问：“AI是否让核心任务变得更快或更好？”
添加任何AI功能前，请回答：
- 该功能具体自动化了什么任务？
- 它比非AI替代方案好在哪里？
- AI出错时会发生什么？
- 没有这个AI功能，我们能否发布产品？
Backlog Hygiene
待办事项治理
A messy backlog enables feature creep. Clean it ruthlessly.
Monthly Backlog Audit:
For each item older than 30 days:
1. Has anyone asked about this since it was added?
2. Does it still align with current product vision?
3. If we never built this, would anyone notice?
If the answer to all three is "no" → Delete it.Priority Framework (MoSCoW):
- Must Have: Product doesn't work without it
- Should Have: Important but not critical for launch
- Could Have: Nice but can wait
- Won't Have: Explicitly out of scope
Be honest: Most "Should Haves" are actually "Could Haves" in disguise.
混乱的待办事项会助长功能蔓延。必须无情地清理它。
月度待办事项审计：
对于所有超过30天的待办项：
1. 自添加以来，有人询问过这个需求吗？
2. 它仍然符合当前的产品愿景吗？
3. 如果我们永远不开发它，有人会注意到吗？
如果三个问题的答案都是“否” → 删除该待办项。优先级框架（MoSCoW）：
- 必须有（Must Have）：没有它产品无法正常工作
- 应该有（Should Have）：重要但对发布非关键
- 可以有（Could Have）：锦上添花但可延后
- 不会有（Won't Have）：明确排除在范围外
请诚实面对：大多数“应该有”的功能实际上是“可以有”的。
AI Session Discipline
AI协作会话规范
Session Start Check:
Before coding with any AI assistant (Claude, Cursor, OpenCode), state:
- What specific feature you're building
- What's explicitly out of scope for this session
- When you'll stop and ship
Mid-Session Check:
Every 30-60 minutes, ask your AI:
"Are we building the right thing today, or are we adding scope?"
If the answer is "adding scope," stop. Commit what you have. Start fresh.
Session End Check:
Before closing an AI coding session:
- What did we actually build vs. what we planned?
- Did scope expand? Why?
- What should we defer to the next session?
Daily AI Check:
At the end of each day working with AI assistants:
1. Features completed today: [list]
2. Scope additions today: [list]
3. Was each addition validated? [yes/no]
4. Tomorrow's focus: [single item]Sprint Planning Guard Rails:
- No new features mid-sprint without removing something
- Capacity for bug fixes and debt paydown (20% minimum)
- Clear definition of done for each item
Stakeholder Management:
Create a single source of truth for scope decisions:
markdown
undefined会话开始检查：
在与任何AI助手（Claude、Cursor、OpenCode等）编码前，明确说明：
- 你正在开发的具体功能
- 本次会话明确排除的范围
- 何时停止开发并发布
会话中途检查：
每30-60分钟，向AI提问：
“我们今天在开发正确的功能吗？还是在扩大范围？”
如果答案是“扩大范围”，请停止开发。提交已完成的代码，重新开始。
会话结束检查：
在关闭AI编码会话前：
- 我们实际开发的内容与计划的有何不同？
- 范围是否扩大？原因是什么？
- 哪些内容需要推迟到下次会话？
每日AI协作检查：
在每天与AI助手协作结束时：
1. 今日完成的功能：[列表]
2. 今日新增的范围：[列表]
3. 每个新增范围是否经过验证？[是/否]
4. 明日重点：[单一任务]冲刺规划防护措施：
- 冲刺中途不得添加新功能，除非移除现有功能
- 预留至少20%的容量用于修复bug和偿还技术债务
- 为每个任务明确“完成”的定义
利益相关者管理：
创建范围决策的单一可信来源：
markdown
undefinedScope Decision Log
范围决策日志
| Date | Request | Source | Decision | Rationale | Trade-off |
|---|---|---|---|---|---|
| 2025-01-15 | Add export to PDF | PM | Deferred v2 | Not core to MVP | Would delay launch 2 weeks |
| 2025-01-16 | Dark mode | User feedback | Approved | User research shows demand | Removed social sharing |
| 2025-01-17 | Add caching layer | Claude | Deferred | Premature optimization | Stay focused on core feature |
| 2025-01-17 | Refactor to hooks | Cursor | Rejected | Works fine as is | Technical scope creep |
**Agents as Stakeholders:**
AI coding agents are now stakeholders in your project. They have opinions. They make suggestions. Treat them like any other stakeholder:
- **Log agent suggestions** in your scope decision log with the agent name as source
- **Apply the same rigor** you would to a PM or executive request
- **Agents optimize for different things** (code quality, patterns, completeness) than you might need right now
- **"The agent suggested it" is not a valid reason** to add a feature
Common agent-driven scope creep patterns:
- "Let me also add error handling for edge cases you haven't hit yet"
- "This would be cleaner with a refactor"
- "You should probably add tests for this"
- "Let me add TypeScript types for these additional scenarios"
Each of these might be good ideas. None of them are your current scope unless you decide they are.| 日期 | 需求内容 | 提出方 | 决策结果 | 决策依据 | 权衡方案 |
|---|---|---|---|---|---|
| 2025-01-15 | 添加PDF导出功能 | 产品经理 | 推迟至v2版本 | 非MVP核心需求 | 会延迟发布2周 |
| 2025-01-16 | 深色模式 | 用户反馈 | 批准 | 用户研究显示有需求 | 移除社交分享功能 |
| 2025-01-17 | 添加缓存层 | Claude | 推迟 | 过早优化 | 继续专注核心功能 |
| 2025-01-17 | 重构为Hooks | Cursor | 拒绝 | 当前实现正常可用 | 属于技术范围蔓延 |
**将AI Agent视为利益相关者：**
AI编码Agent现在是项目的利益相关者。它们有自己的观点，会提出建议。像对待其他利益相关者一样对待它们：
- **记录Agent的建议**：在范围决策日志中记录，来源标注为Agent名称
- **应用相同的审核标准**：与对待产品经理或高管的需求一致
- **Agent的优化目标不同**：它们可能更关注代码质量、模式完整性，而非当前的发布需求
- **“Agent建议的”不是添加功能的合理理由**
常见的Agent驱动的范围蔓延模式：
- “我还可以为你尚未遇到的边缘情况添加错误处理”
- “重构会让代码更简洁”
- “你可能需要为这个功能添加测试”
- “我来为这些额外场景添加TypeScript类型”
这些可能都是好主意，但除非你明确决定，否则它们都不属于当前范围。Recovery: You're Already Bloated
补救措施：你的产品已经臃肿不堪
If feature creep has already happened:
Step 1: Audit Current Features
- List every feature
- Check usage data for each
- Identify features with <5% engagement
Step 2: Categorize
- Core: Users can't accomplish their goal without it
- Supporting: Makes core better
- Peripheral: Nice but not necessary
- Bloat: Nobody uses it
Step 3: Remove or Hide
- Deprecate bloat with warning period
- Move peripheral features behind advanced settings
- Communicate changes clearly to users
Step 4: Prevent Recurrence
- Add feature creep checks to your PR/code review process
- Require usage metrics before features graduate from beta
- Build feature flags so you can easily remove experiments
如果功能蔓延已经发生：
步骤1：审计当前功能
- 列出所有功能
- 检查每个功能的使用数据
- 识别使用率<5%的功能
步骤2：分类
- 核心功能：用户无法完成目标的必备功能
- 辅助功能：提升核心功能体验
- 外围功能：锦上添花但非必需
- 臃肿功能：无人使用
步骤3：移除或隐藏
- 逐步淘汰臃肿功能，提前发出警告
- 将外围功能移至高级设置中
- 向用户清晰传达变更内容
步骤4：防止复发
- 在PR/代码评审流程中添加功能蔓延检查环节
- 要求功能在从beta版毕业前提供使用数据
- 使用功能开关，以便轻松移除实验性功能
Quick Reference Commands
快速参考问题清单
When reviewing any feature request, ask:
1. "What user problem does this solve?"
2. "What's the smallest version we could ship?"
3. "What are we NOT building to make room for this?"
4. "How will we measure success?"
5. "What happens if we never build this?"If you can't answer these clearly → Do not proceed.
在评审任何功能需求时，提问：
1. “这个功能解决了什么用户问题？”
2. “我们可以发布的最小版本是什么？”
3. “为了开发这个功能，我们将放弃开发哪些功能？”
4. “我们如何衡量成功？”
5. “如果永远不开发这个功能，会发生什么？”如果无法清晰回答这些问题 → 请勿继续。
The Golden Rule
黄金法则
Ship something small that works. Then iterate based on real usage data.
Users don't remember features. They remember whether your product solved their problem.
Every feature you don't build is:
- Time you get back
- Bugs you don't have to fix
- Documentation you don't have to write
- Code you don't have to maintain
- Confusion you don't add
The best products aren't the ones with the most features. They're the ones that do the right things exceptionally well.
"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry
先交付一个可用的最小版本，再根据真实使用数据迭代。
用户不会记住功能的数量，只会记住你的产品是否解决了他们的问题。
你没有开发的每个功能意味着：
- 节省的时间
- 无需修复的bug
- 无需编写的文档
- 无需维护的代码
- 避免的用户困惑
最好的产品不是功能最多的产品，而是把正确的事情做到极致的产品。
“完美不是无法再添加什么，而是无法再去除什么。”——安托万·德·圣埃克苏佩里",