Domain Elimination Assessor(SkillHub)
Domain Elimination Assessor(ClawHub)


name: domain-elimination-assessor
author: 王教成 Wang Jiaocheng (波动几何)
description: 领域消除评估技能。评估一个领域是否能够被完全消除(被更大领域吸收或不再需要)。适用于:评估业务领域、工作流、组织结构、技术模块等的独立存在必要性。

Domain Elimination Assessor — 领域消除评估方法

核心理念

领域存在的根本问题:不是"这个领域能不能优化",而是"这个领域需不需要存在"。

传统思维是"领域存在→优化领域",但更根本的问题是:这个领域是否本就不该存在?如果领域本身是人的局限产物(组织架构、部门壁垒、历史遗留),那么消除领域比重构领域更彻底。

适用范围:任何可被识别为"领域"的实体——业务领域、工作流、组织部门、技术模块、知识分类、流程阶段等。


评估五步法

步骤 操作 要点
边界识别 识别领域的边界和范围 明确领域包含什么、不包含什么
存在理由分析 追问领域存在的根本原因 事情本身需要 / 人的局限需要 / 历史遗留
消除可行性评估 评估领域是否可以完全消除 被更大领域吸收 / 功能分散到其他领域 / 直接废弃
独立存在必要性判断 判断领域是否值得独立存在 边界清晰度 / 功能内聚性 / 消除成本
决策输出 消除 / 重构 / 保留 基于评估结果给出明确建议

领域存在理由分类

类型 标记 说明 处理建议
事情本身需要 ✅必要 领域的存在是因为事情本身有清晰的边界和内聚性 保留→可进一步优化
人的局限需要 ❌可消除 领域的存在是因为人的认知局限、组织架构、协作需要 消除→功能分散到其他领域
历史遗留 ⚠️待评估 领域的存在是因为历史原因,当前必要性存疑 评估后决定
外部约束 🔒不可消除 领域的存在是因为法规、标准、合同等外部约束 保留→可进一步优化

评估判断标准

满足任一即建议消除:

条件 阈值 示例
边界模糊度 领域边界≥50%与其他领域重叠 "运营支持"与"产品管理"高度重叠
功能离散度 领域内功能关联度<30% "行政管理"包含采购、HR、IT等不相关功能
独立价值 领域消除后整体功能无显著损失 "质量监督"功能可分散到各业务环节
消除成本 消除成本<重构成本 领域刚成立,人员少,流程简单

评估后典型决策

决策 适用场景 后续行动
消除 边界模糊、功能离散、历史遗留、消除成本低 功能分散到其他领域或直接废弃
重构 边界清晰、功能内聚、消除成本高 对领域进行进一步优化,提升效率和清晰度
保留 已足够优化、外部约束不可变 维持现状,无需额外操作

选择原则:能消除的不重构,能重构的不保留。消除是最彻底的优化。


评估验证清单

评估完成后必须逐项验证,五项全部通过才算评估完成:

# 验证项 说明
1 ⬜ 边界识别完整性 是否完整识别了领域的边界和范围
2 ⬜ 存在理由判定准确 是否准确判定领域存在的根本原因
3 ⬜ 消除可行性评估合理 是否合理评估了消除的可行性
4 ⬜ 独立存在必要性判断准确 是否准确判断了领域独立存在的必要性
5 ⬜ 决策建议明确 是否给出了明确的消除/重构/保留建议

任务体系

领域清单与依赖拓扑

ID 任务类型 说明 依赖 能力需求
D0-01 领域边界识别 识别目标领域的边界和范围:包含什么、不包含什么、与其他领域的交集 无(入口) 调研
D0-02 领域存在理由分析 追问领域存在的根本原因,标记为必要/可消除/待评估/不可消除 D0-01 调研→设计
D0-03 领域消除可行性评估 评估领域是否可以完全消除:被更大领域吸收、功能分散、直接废弃 D0-02 设计
D0-04 领域独立存在必要性判断 判断领域是否值得独立存在:边界清晰度、功能内聚性、消除成本 D0-03 设计→执行
D0-05 决策输出 基于评估结果给出明确建议:消除/重构/保留 D0-04 设计

依赖链路:D0-01 → D0-02 → D0-03 → D0-04 → D0-05


领域要求清单

D0-01 领域边界识别

  • 必选组件: 领域名称、领域范围描述(包含什么、不包含什么)、与其他领域的交集列表、边界清晰度评估(清晰/模糊/高度重叠)
  • 可选组件: 领域历史演变、领域规模(人员/流程/功能点数量)
  • 组装顺序: 领域确认→范围梳理→交集识别→边界清晰度评估→数据汇总
  • 约束: 必须完整识别领域的所有边界,不可跳过"理所当然"的边界;边界清晰度必须基于客观标准,不可凭感觉
  • 格式: 领域边界图(Markdown表格+交集标注)

D0-02 领域存在理由分析

  • 必选组件: 领域存在的根本原因(事情本身需要 / 人的局限需要 / 历史遗留 / 外部约束)、存在理由标记(✅必要 / ❌可消除 / ⚠️待评估 / 🔒不可消除)、标记理由
  • 可选组件: 存在理由细分(组织架构/协作需要/认知局限/历史惯性/法规要求)、消除动机评估
  • 组装顺序: 追问存在理由→根本原因判定→类型标记→理由记录→汇总统计
  • 约束: 每个领域必须追问"如果组织是完全扁平的、没有部门壁垒,这个领域还需要独立存在吗?";判定必须基于事情本身逻辑,不可因"行业惯例"保留
  • 格式: 存在理由分析表(Markdown表格)

D0-03 领域消除可行性评估

  • 必选组件: 消除方案(被更大领域吸收 / 功能分散到其他领域 / 直接废弃)、消除成本评估(低/中/高)、消除风险评估(低/中/高)、消除后功能覆盖度
  • 可选组件: 消除时间表、消除后需新增的协调机制、消除后需调整的依赖关系
  • 组装顺序: 消除方案设计→成本评估→风险评估→功能覆盖度验证→消除可行性判定
  • 约束: 消除方案必须具体到"功能A→领域X,功能B→领域Y";成本评估必须基于实际数据,不可凭感觉;风险评估必须考虑最坏情况
  • 格式: 消除方案表(Markdown表格)

D0-04 领域独立存在必要性判断

  • 必选组件: 边界清晰度评分(1-10)、功能内聚性评分(1-10)、消除成本评分(1-10,越高越不值得消除)、独立存在必要性评分(综合评分)
  • 可选组件: 评分依据详细说明、敏感性分析(不同权重下的评分变化)
  • 组装顺序: 边界清晰度评分→功能内聚性评分→消除成本评分→综合评分→必要性判定
  • 约束: 评分必须基于客观标准,不可凭感觉;综合评分必须考虑三个维度的权重(边界清晰度30%,功能内聚性40%,消除成本30%)
  • 格式: 评分表(Markdown表格)

D0-05 决策输出

  • 必选组件: 决策建议(消除 / 重构 / 保留)、决策理由、后续行动建议
  • 可选组件: 决策置信度(高/中/低)、决策风险提示、决策后跟踪指标
  • 组装顺序: 评估结果汇总→决策建议→理由记录→后续行动建议
  • 约束: 决策建议必须明确,不可模棱两可;如果建议消除,必须给出具体的消除方案;如果建议重构,必须说明重构方向和预期效果
  • 格式: 决策记录(Markdown)

领域范本

DEA-01 领域消除评估范本

对应任务: D0-01 ~ D0-05

适用场景: 任何领域的独立存在必要性需要评估

评估范本:

## 领域消除评估记录

### Step 1:领域边界识别(D0-01)

**目标领域**:________(如:质量监督部/运营支持/技术架构组/________)

**领域范围描述**:
- 包含:________
- 不包含:________

**与其他领域的交集**:

| 交集领域 | 交集内容 | 交集程度 |
|---------|---------|---------|
| ________ | ________ | 低/中/高 |
| ________ | ________ | 低/中/高 |
| ________ | ________ | 低/中/高 |

**边界清晰度**:清晰 / 模糊 / 高度重叠

**领域规模**:
- 人员:___人
- 流程:___个
- 功能点:___个

### Step 2:领域存在理由分析(D0-02)

**追问准则**:如果组织是完全扁平的、没有部门壁垒,这个领域还需要独立存在吗?

**存在理由**:________

**存在理由标记**:
- ⬜ 事情本身需要 → ✅必要
- ⬜ 人的局限需要 → ❌可消除
- ⬜ 历史遗留 → ⚠️待评估
- ⬜ 外部约束 → 🔒不可消除

**标记理由**:________

**存在理由细分**(如适用):
- 组织架构:________
- 协作需要:________
- 认知局限:________
- 历史惯性:________
- 法规要求:________

### Step 3:领域消除可行性评估(D0-03)

**消除方案**:

| 方案 | 具体描述 | 成本 | 风险 |
|------|---------|------|------|
| 被更大领域吸收 | ________ | 低/中/高 | 低/中/高 |
| 功能分散到其他领域 | ________ | 低/中/高 | 低/中/高 |
| 直接废弃 | ________ | 低/中/高 | 低/中/高 |

**推荐方案**:________

**消除后功能覆盖度**:
- 功能A → 领域X
- 功能B → 领域Y
- 功能C → 领域Z

**消除成本评估**:低/中/高(理由:________)

**消除风险评估**:低/中/高(理由:________)

### Step 4:领域独立存在必要性判断(D0-04)

**评分标准**:
- 边界清晰度(1-10):边界越清晰,分数越高
- 功能内聚性(1-10):功能越相关,分数越高
- 消除成本(1-10):成本越高,分数越高(越不值得消除)

**评分结果**:

| 维度 | 评分 | 权重 | 加权分 |
|------|------|------|--------|
| 边界清晰度 | ___/10 | 30% | ___ |
| 功能内聚性 | ___/10 | 40% | ___ |
| 消除成本 | ___/10 | 30% | ___ |
| **综合评分** | ___/10 | 100% | ___ |

**评分依据**:
- 边界清晰度:________
- 功能内聚性:________
- 消除成本:________

**必要性判定**:
- 综合评分 ≥ 7:领域值得独立存在 → 保留→可进一步优化
- 综合评分 4-6:领域存在必要性存疑 → 进一步评估或部分消除
- 综合评分 < 4:领域不值得独立存在 → 消除

### Step 5:决策输出(D0-05)

**评估结果汇总**:
- 边界清晰度:________
- 存在理由:________
- 消除可行性:________
- 独立存在必要性:________

**决策建议**:
- ⬜ 消除:领域不值得独立存在,建议消除
- ⬜ 重构:领域值得独立存在,建议进一步优化
- ⬜ 保留:领域已足够优化,无需重构

**决策理由**:________

**后续行动建议**:
- 如果消除:________
- 如果重构:对领域进行进一步优化,提升效率和清晰度
- 如果保留:________

**决策置信度**:高/中/低

**决策风险提示**:________

---

### 评估前后对比

| 维度 | 评估前 | 评估后 | 变化 |
|------|--------|--------|------|
| 领域状态 | 存在 | 消除/重构/保留 | ________ |
| 功能分布 | 集中在该领域 | 分散到其他领域/保持集中 | ________ |
| 协调成本 | 有 | 无/减少/保持 | ________ |
| 边界清晰度 | 模糊/清晰 | 更清晰/已消除 | ________ |

范本要点:

  • 评估的核心是"追问存在理由"——每个领域都必须回答"这是事情本身需要还是人的局限需要"
  • 消除领域比重构领域更彻底——如果领域本不该存在,消除是最佳选择
  • 评分必须基于客观标准,不可凭感觉——边界清晰度、功能内聚性、消除成本都需要量化
  • 决策建议必须明确——消除/重构/保留三选一,不可模棱两可
  • 范本中 ________ 为待用户提供的内容,不可AI编造

使用规则

  1. 判断是否需要评估:当领域边界模糊、功能离散、存在历史遗留问题时,触发评估
  2. 按链路执行:D0-01 → D0-05,不可跳步
  3. 产出交付:按领域要求清单逐项填充,或按DEA-01范本结构替换实际内容
  4. 用户主权:AI按技能框架产出的内容是起点,不是终稿。用户对任何环节有独特的校准点、质量标准或业务约束,都可以也应当要求修改——尤其是评分标准的权重,只有用户知道哪些维度对他的场景最重要。用户还可以主动提供清单(该领域应包含的组件列表)和样本(高质量的同类评估作为参考)作为校准参考,让AI的产出更贴合实际需求

事实纪律

  1. AI工具能力描述必须基于实际能力,不得夸大
  2. 评估结果必须标注为"参考范围",实际效果取决于具体领域
  3. 涉及法规、标准、合同等外部约束的领域必须明确标注,不可因评估而忽略
  4. "消除可行性评估"必须基于实际数据,不可凭感觉
  5. "独立存在必要性判断"必须基于客观标准,不可凭感觉
Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐