\r \r

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

\r

核心理念\r

\r 领域存在的根本问题：不是"这个领域能不能优化"，而是"这个领域需不需要存在"。\r \r 传统思维是"领域存在→优化领域"，但更根本的问题是：这个领域是否本就不该存在？如果领域本身是人的局限产物（组织架构、部门壁垒、历史遗留），那么消除领域比重构领域更彻底。\r \r 适用范围：任何可被识别为"领域"的实体——业务领域、工作流、组织部门、技术模块、知识分类、流程阶段等。\r \r ---\r \r

评估五步法\r

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

领域存在理由分类\r

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

评估判断标准\r

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

评估后典型决策\r

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

评估验证清单\r

\r 评估完成后必须逐项验证，五项全部通过才算评估完成：\r \r | # | 验证项 | 说明 |\r |---|--------|------|\r | 1 | ⬜ 边界识别完整性 | 是否完整识别了领域的边界和范围 |\r | 2 | ⬜ 存在理由判定准确 | 是否准确判定领域存在的根本原因 |\r | 3 | ⬜ 消除可行性评估合理 | 是否合理评估了消除的可行性 |\r | 4 | ⬜ 独立存在必要性判断准确 | 是否准确判断了领域独立存在的必要性 |\r | 5 | ⬜ 决策建议明确 | 是否给出了明确的消除/重构/保留建议 |\r \r ---\r \r

任务体系\r

\r

领域清单与依赖拓扑\r

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

领域要求清单\r

\r

D0-01 领域边界识别\r

\r

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

D0-02 领域存在理由分析\r

\r

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

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

\r

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

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

\r

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

D0-05 决策输出\r

\r

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

领域范本\r

\r

DEA-01 领域消除评估范本\r

\r 对应任务: D0-01 ~ D0-05\r \r 适用场景: 任何领域的独立存在必要性需要评估\r \r 评估范本:\r \r

## 领域消除评估记录\r
\r
### Step 1：领域边界识别（D0-01）\r
\r
**目标领域**：________（如：质量监督部/运营支持/技术架构组/________）\r
\r
**领域范围描述**：\r
- 包含：________\r
- 不包含：________\r
\r
**与其他领域的交集**：\r
\r
| 交集领域 | 交集内容 | 交集程度 |\r
|---------|---------|---------|\r
| ________ | ________ | 低/中/高 |\r
| ________ | ________ | 低/中/高 |\r
| ________ | ________ | 低/中/高 |\r
\r
**边界清晰度**：清晰 / 模糊 / 高度重叠\r
\r
**领域规模**：\r
- 人员：___人\r
- 流程：___个\r
- 功能点：___个\r
\r
### Step 2：领域存在理由分析（D0-02）\r
\r
**追问准则**：如果组织是完全扁平的、没有部门壁垒，这个领域还需要独立存在吗？\r
\r
**存在理由**：________\r
\r
**存在理由标记**：\r
- ⬜ 事情本身需要 → ✅必要\r
- ⬜ 人的局限需要 → ❌可消除\r
- ⬜ 历史遗留 → ⚠️待评估\r
- ⬜ 外部约束 → 🔒不可消除\r
\r
**标记理由**：________\r
\r
**存在理由细分**（如适用）：\r
- 组织架构：________\r
- 协作需要：________\r
- 认知局限：________\r
- 历史惯性：________\r
- 法规要求：________\r
\r
### Step 3：领域消除可行性评估（D0-03）\r
\r
**消除方案**：\r
\r
| 方案 | 具体描述 | 成本 | 风险 |\r
|------|---------|------|------|\r
| 被更大领域吸收 | ________ | 低/中/高 | 低/中/高 |\r
| 功能分散到其他领域 | ________ | 低/中/高 | 低/中/高 |\r
| 直接废弃 | ________ | 低/中/高 | 低/中/高 |\r
\r
**推荐方案**：________\r
\r
**消除后功能覆盖度**：\r
- 功能A → 领域X\r
- 功能B → 领域Y\r
- 功能C → 领域Z\r
\r
**消除成本评估**：低/中/高（理由：________）\r
\r
**消除风险评估**：低/中/高（理由：________）\r
\r
### Step 4：领域独立存在必要性判断（D0-04）\r
\r
**评分标准**：\r
- 边界清晰度（1-10）：边界越清晰，分数越高\r
- 功能内聚性（1-10）：功能越相关，分数越高\r
- 消除成本（1-10）：成本越高，分数越高（越不值得消除）\r
\r
**评分结果**：\r
\r
| 维度 | 评分 | 权重 | 加权分 |\r
|------|------|------|--------|\r
| 边界清晰度 | ___/10 | 30% | ___ |\r
| 功能内聚性 | ___/10 | 40% | ___ |\r
| 消除成本 | ___/10 | 30% | ___ |\r
| **综合评分** | ___/10 | 100% | ___ |\r
\r
**评分依据**：\r
- 边界清晰度：________\r
- 功能内聚性：________\r
- 消除成本：________\r
\r
**必要性判定**：\r
- 综合评分 ≥ 7：领域值得独立存在 → 保留→可进一步优化\r
- 综合评分 4-6：领域存在必要性存疑 → 进一步评估或部分消除\r
- 综合评分 \x3C 4：领域不值得独立存在 → 消除\r
\r
### Step 5：决策输出（D0-05）\r
\r
**评估结果汇总**：\r
- 边界清晰度：________\r
- 存在理由：________\r
- 消除可行性：________\r
- 独立存在必要性：________\r
\r
**决策建议**：\r
- ⬜ 消除：领域不值得独立存在，建议消除\r
- ⬜ 重构：领域值得独立存在，建议进一步优化\r
- ⬜ 保留：领域已足够优化，无需重构\r
\r
**决策理由**：________\r
\r
**后续行动建议**：\r
- 如果消除：________\r
- 如果重构：对领域进行进一步优化，提升效率和清晰度\r
- 如果保留：________\r
\r
**决策置信度**：高/中/低\r
\r
**决策风险提示**：________\r
\r
---\r
\r
### 评估前后对比\r
\r
| 维度 | 评估前 | 评估后 | 变化 |\r
|------|--------|--------|------|\r
| 领域状态 | 存在 | 消除/重构/保留 | ________ |\r
| 功能分布 | 集中在该领域 | 分散到其他领域/保持集中 | ________ |\r
| 协调成本 | 有 | 无/减少/保持 | ________ |\r
| 边界清晰度 | 模糊/清晰 | 更清晰/已消除 | ________ |\r
```\r
\r
**范本要点**:\r
- 评估的核心是"追问存在理由"——每个领域都必须回答"这是事情本身需要还是人的局限需要"\r
- 消除领域比重构领域更彻底——如果领域本不该存在，消除是最佳选择\r
- 评分必须基于客观标准，不可凭感觉——边界清晰度、功能内聚性、消除成本都需要量化\r
- 决策建议必须明确——消除/重构/保留三选一，不可模棱两可\r
- 范本中 `________` 为待用户提供的内容，不可AI编造\r
\r
---\r
\r
## 使用规则\r
\r
1. **判断是否需要评估**：当领域边界模糊、功能离散、存在历史遗留问题时，触发评估\r
2. **按链路执行**：D0-01 → D0-05，不可跳步\r
3. **产出交付**：按领域要求清单逐项填充，或按DEA-01范本结构替换实际内容\r
4. **用户主权**：AI按技能框架产出的内容是起点，不是终稿。用户对任何环节有独特的校准点、质量标准或业务约束，都可以也应当要求修改——尤其是评分标准的权重，只有用户知道哪些维度对他的场景最重要。用户还可以主动提供清单（该领域应包含的组件列表）和样本（高质量的同类评估作为参考）作为校准参考，让AI的产出更贴合实际需求\r
\r
---\r
\r
## 事实纪律\r
\r
1. AI工具能力描述必须基于实际能力，不得夸大\r
2. 评估结果必须标注为"参考范围"，实际效果取决于具体领域\r
3. 涉及法规、标准、合同等外部约束的领域必须明确标注，不可因评估而忽略\r
4. "消除可行性评估"必须基于实际数据，不可凭感觉\r
5. "独立存在必要性判断"必须基于客观标准，不可凭感觉