RULE
边界思维
[RULE] 边界思维
- 类型: 原则
- 强度: 8/10
- 验证: ✓0 / ✗0
定义
IF: 设计任何解决方案、工具、流程或系统
THEN: 必须明确回答三个问题：
- 能解决什么：适用场景、预期效果、成功标准
- 不能解决什么：排除的问题类型、失效场景
- 为什么不能：局限性的根本原因
原理
不知边界的方案是危险的——要么被误用，要么被过度扩展。
清晰的边界带来：
- 正确的使用预期
- 合理的资源投入
- 避免过度承诺
- 便于后续迭代改进
局限性三分类
| 类型 | 说明 | 例子 |
|---|---|---|
| 技术限制 | 当前技术能力、性能、兼容性约束 | "不支持 IE 浏览器" |
| 设计选择 | 为简洁/稳定而有意放弃的功能 | "只处理文本，不处理图片" |
| 资源考量 | 时间、人力、成本限制下的取舍 | "V1 只覆盖核心场景" |
应用模板
设计方案时填写：
方案名称：___
✅ 能解决：
-
-
❌ 不能解决：
-
-
❓ 为什么：
-
反模式
| 模式 | 后果 |
|---|---|
| "这个方案能解决所有问题" | 过度承诺，必然失败 |
| "应该能行吧" | 边界模糊，误用风险 |
| 只说能做什么，不说不能做什么 | 用户预期失控 |
证据
- 支持: INFO-099（问题解决思考框架）
- 反例: （待收集）
关联
- 协同: RULE-通用解法优先（设计通用方案时明确边界）
- 协同: RULE-先Spec后代码（Spec 中应包含边界定义）
- 应用: 技术方案设计、产品需求定义、沟通承诺