领域术语的统一治理：业务术语表与代码命名规范的AI辅助对齐

TL;DR> > 术语不一致是AI代码生成质量的头号杀手：> 1. 术语鸿沟 — 业务说”客户”，代码写”User”，AI无所适从

1. 统一术语表 — 建立企业级业务术语与代码命名的映射
2. AI辅助对齐 — 让AI理解业务语境，生成符合规范的代码
3. 持续治理 — 术语是活的，需要持续更新和演进

关键洞察：没有统一术语的AI生成，就像没有图纸的建筑——混乱且危险。

📋 本文结构

1. 术语不一致的问题
2. 统一术语治理模型
3. 业务术语表设计
4. 代码命名规范
5. AI辅助对齐机制
6. 实施与治理

术语不一致的问题

混乱的现实

场景：电商系统的命名混乱

业务文档：

• “客户下单后，订单进入待支付状态”
• “商家可以查看客户的购买历史”

代码实现：

// 团队A的代码
class User {
    List<Order> orders;
}

// 团队B的代码
class Customer {
    List<Purchase> purchaseHistory;
}

// 团队C的代码
class Member {
    List<Transaction> transactions;
}

问题：

• 同一个业务概念，三种代码命名
• AI生成代码时无所适从
• 跨团队协作困难
• 知识检索效果差

AI时代的术语危机

问题1：AI理解困难

Prompt："为客户生成订单报表"

AI困惑：
- "客户"对应哪个类？User、Customer、Member？
- "订单"对应哪个类？Order、Purchase、Transaction？
- 报表需要哪些字段？

结果：AI生成的代码可能混用不同团队的命名风格，造成更大混乱。

问题2：RAG效果差

知识库检索时：

• 搜索”客户” → 只找到部分文档（因为还有”用户”、”会员”）
• 搜索”订单” → 漏掉”交易”相关的知识

问题3：新人 onboarding 困难

新开发者需要学习：

• 业务术语
• 各团队的代码命名习惯
• 术语之间的映射关系

学习成本高，容易出错。

术语不一致的代价

统一术语治理模型

三层术语架构

flowchart TB
    subgraph Terminology["三层术语架构"]
        L3["业务层（Business Language）
        - 业务专家使用的自然语言
        - 示例：客户、订单、支付、退款"]
        L2["映射层（Mapping Layer）
        - 业务术语与代码命名的对应关系
        - 示例：客户 → Customer"]
        L1["代码层（Code Language）
        - 代码中的命名（类、方法、变量）
        - 示例：Customer、Order、PaymentService"]
    end
    
    L3 --> L2
    L2 --> L1
    
    style Terminology fill:#f8fafc,stroke:#64748b,stroke-width:2px
    style L3 fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style L2 fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style L1 fill:#d1fae5,stroke:#059669,stroke-width:2px

术语治理原则

原则1：单一事实来源（Single Source of Truth）

所有术语定义集中管理，避免多个地方定义同一个术语。

原则2：业务驱动（Business-Driven）

术语从业务角度定义，技术命名服务于业务表达。

原则3：显式映射（Explicit Mapping）

业务术语和代码命名之间的关系必须显式记录，不能隐式假设。

原则4：持续治理（Continuous Governance）

术语是活的，需要随着业务发展持续更新。

业务术语表设计

术语表结构

# business-glossary.yml

terms:
  - id: "customer"
    display_name: "客户"
    definition: "在平台注册并购买商品或服务的个人或组织"
    domain: "销售域"
    owner: "产品团队"
    
    aliases: # 别名
      - "顾客"
      - "买家"
    
    code_mappings: # 代码映射
      - language: "java"
        class_name: "Customer"
        package: "com.company.sales.domain"
      - language: "python"
        class_name: "Customer"
        module: "sales.models"
      - language: "typescript"
        class_name: "ICustomer"
        file: "src/types/customer.ts"
    
    attributes: # 属性定义
      - name: "id"
        type: "UUID"
        description: "唯一标识"
      - name: "name"
        type: "String"
        description: "客户名称"
      - name: "status"
        type: "Enum"
        enum_values: ["ACTIVE", "INACTIVE", "SUSPENDED"]
        description: "客户状态"
    
    relationships: # 关系定义
      - target: "order"
        relation: "one-to-many"
        description: "一个客户有多个订单"
    
    constraints: # 约束
      - "客户名称不能为空"
      - "邮箱格式必须合法"
    
    examples: # 使用示例
      - "新客户注册后状态为ACTIVE"
      - "客户可以查看自己的订单历史"
    
    status: "approved"  # approved/draft/deprecated
    version: "2.1"
    last_updated: "2026-03-01"
    updated_by: "zhangsan"

术语分类体系

业务术语
├── 核心域（Core Domain）
│   ├── 客户域
│   │   ├── 客户
│   │   ├── 会员等级
│   │   └── 客户标签
│   ├── 订单域
│   │   ├── 订单
│   │   ├── 订单项
│   │   └── 订单状态
│   └── 商品域
│       ├── 商品
│       ├── SKU
│       └── 库存
│
├── 支持域（Supporting Domain）
│   ├── 支付域
│   ├── 物流域
│   └── 营销域
│
└── 通用域（Generic Domain）
    ├── 用户认证
    ├── 通知
    └── 审计日志

术语生命周期

草稿（Draft）
    ↓ 业务方提出
评审中（Under Review）
    ↓ 术语委员会评审
已批准（Approved）
    ↓ 正式发布
已发布（Published）
    ↓ 业务变化
已废弃（Deprecated）
    ↓ 过渡期后
已退役（Retired）

代码命名规范

命名约定

类名（Class Name）：

// 业务实体
Customer              // 客户
Order                 // 订单
PaymentTransaction    // 支付交易

// 服务
CustomerService       // 客户服务
OrderProcessor        // 订单处理器
PaymentGateway        // 支付网关

// 仓库（Repository）
CustomerRepository    // 客户仓储
OrderRepository       // 订单仓储

方法名（Method Name）：

// 查询
findCustomerById(id)           // 根据ID查找客户
findOrdersByCustomerId(id)     // 根据客户ID查找订单
searchCustomers(criteria)      // 搜索客户

// 命令
createCustomer(dto)            // 创建客户
updateCustomerStatus(id, status) // 更新客户状态
cancelOrder(id)                // 取消订单

// 业务操作
placeOrder(customerId, items)  // 下单
processPayment(orderId, payment) // 处理支付
refundOrder(orderId, reason)   // 退款

变量名（Variable Name）：

// 避免缩写
customer                // ✓ 好
cust                    // ✗ 不好

// 避免无意义命名
customerName            // ✓ 好
name                    // ✗ 上下文不明
cn                      // ✗ 缩写

// 集合命名
customers               // 客户列表（复数）
customerList            // 明确List类型
customerMap             // 明确Map类型

语言特定规范

Java：

// 包命名
com.company.sales.domain      // 领域层
com.company.sales.application // 应用层
com.company.sales.infrastructure // 基础设施层

// 接口与实现
CustomerRepository            // 接口
CustomerRepositoryImpl        // 实现
CustomerRepositoryJpa         // JPA实现

Python：

# 模块命名
sales/models/customer.py      # 模型
sales/services/customer_service.py  # 服务
sales/repositories/customer_repo.py # 仓储

# 类命名（PEP8）
class Customer:
    pass

class CustomerService:
    pass

TypeScript/JavaScript：

// 接口命名
interface ICustomer {          // 匈牙利命名法（可选）
  id: string;
  name: string;
}

// 类型别名
type CustomerStatus = 'ACTIVE' | 'INACTIVE';

// 文件名
customer.ts                   // 单数小写
customer-service.ts           // 短横线连接
customer.service.ts           // 点分隔（Angular风格）

AI辅助对齐机制

AI理解业务语境

Context注入：

class AIContextBuilder:
    def build_context(self, task_description):
        """
        根据任务描述构建AI理解的语境
        """
        # 1. 提取关键业务术语
        terms = self.extract_business_terms(task_description)
        
        # 2. 查询术语定义
        term_definitions = []
        for term in terms:
            definition = self.glossary.lookup(term)
            if definition:
                term_definitions.append(definition)
        
        # 3. 构建AI Prompt Context
        context = f"""
        业务语境：
        当前任务涉及以下业务概念：
        {self.format_term_definitions(term_definitions)}
        
        代码命名规范：
        - 使用英文类名：{self.get_code_mappings(terms)}
        - 遵循命名约定：首字母大写驼峰命名
        - 包/模块位置：{self.get_package_info(terms)}
        
        相关实体关系：
        {self.get_relationships(terms)}
        
        约束条件：
        {self.get_constraints(terms)}
        """
        
        return context

示例：

用户输入：
"为客户生成订单历史查询功能"

AI构建的Context：
业务语境：
- 客户（Customer）：在平台注册的个人或组织，类名Customer，位于sales.domain
- 订单（Order）：客户的购买记录，类名Order，位于sales.domain
- 关系：Customer 1:N Order

代码命名规范：
- 查询方法名：findOrdersByCustomerId
- 服务类名：OrderQueryService
- 返回类型：List<Order>

约束条件：
- 只返回已完成的订单
- 按时间倒序排列
- 最多返回100条

代码生成对齐

生成模板：

class AlignedCodeGenerator:
    def generate(self, task, business_context):
        prompt = f"""
        任务：{task}
        
        业务语境：
        {business_context}
        
        要求：
        1. 使用上述业务语境中的类名和方法名
        2. 遵循代码命名规范
        3. 包含适当的注释说明业务含义
        4. 返回类型和参数类型必须与术语定义一致
        
        请生成符合规范的代码：
        """
        
        return self.llm.generate(prompt)

示例输出：

@Service
public class OrderQueryService {
    
    private final OrderRepository orderRepository;
    
    /**
     * 查询客户的订单历史
     * 
     * @param customerId 客户ID
     * @return 客户的订单列表（只包含已完成订单，按时间倒序）
     */
    public List<Order> findOrdersByCustomerId(UUID customerId) {
        // 业务规则：只查询已完成的订单
        return orderRepository.findByCustomerIdAndStatusOrderByCreatedAtDesc(
            customerId, 
            OrderStatus.COMPLETED,
            PageRequest.of(0, 100)  // 最多100条
        );
    }
}

命名冲突检测

自动检测代码中的术语不一致：

class TerminologyLinter:
    def lint(self, code_file):
        issues = []
        
        # 1. 解析代码中的命名
        code_entities = self.parse_code(code_file)
        
        # 2. 对比术语表
        for entity in code_entities:
            business_term = self.infer_business_term(entity)
            
            if business_term:
                # 检查是否符合规范
                standard_name = self.glossary.get_code_name(business_term)
                
                if entity.name != standard_name:
                    issues.append({
                        'type': 'naming_mismatch',
                        'entity': entity.name,
                        'business_term': business_term,
                        'should_be': standard_name,
                        'location': entity.location
                    })
        
        return issues

示例检测：

// 代码中的命名
class User {                    // ⚠️ 警告：应该用 Customer
    List<Purchase> history;     // ⚠️ 警告：Purchase 应该用 Order
}

// 检测结果
[
  {
    "type": "naming_mismatch",
    "entity": "User",
    "business_term": "客户",
    "should_be": "Customer",
    "suggestion": "Rename 'User' to 'Customer' to align with business glossary"
  },
  {
    "type": "naming_mismatch",
    "entity": "Purchase",
    "business_term": "订单",
    "should_be": "Order",
    "suggestion": "Consider using 'Order' instead of 'Purchase'"
  }
]

IDE集成

实时提示：

开发者输入：
class Client {

IDE提示：
⚠️ 命名建议
"Client" 可能对应业务术语 "客户"
建议改为 "Customer" 以符合规范

[查看定义] [自动重构] [忽略]

自动补全：

开发者输入：
customer.find

IDE自动补全：
customer.findOrdersById()
customer.findActiveOrders()
customer.findOrderHistory()
（基于术语表中的方法定义）

实施与治理

实施路线图

阶段1：术语盘点（1个月）

• 梳理现有业务术语
• 整理代码中的命名现状
• 识别命名冲突和不一致
• 建立术语优先级（核心域优先）

阶段2：建立术语表（1个月）

• 定义核心域术语
• 建立业务-代码映射
• 制定命名规范
• 获得业务方确认

阶段3：工具集成（1个月）

• 部署术语管理平台
• IDE插件开发/配置
• CI/CD集成术语检查
• AI工具集成术语Context

阶段4：治理运营（持续）

• 术语变更审批流程
• 定期审计代码合规性
• 新术语快速 onboarding
• 度量和优化

治理组织

术语委员会：

• 产品代表：提供业务定义
• 架构师：制定技术规范
• 开发代表：反馈实践问题
• AI工程师：确保AI兼容性

职责：

• 新术语审批
• 术语变更决策
• 规范更新
• 争议仲裁

度量指标

合规性指标：

• 术语覆盖率：代码中命名与术语表的匹配率
• 命名一致性：同一业务概念的不同代码命名数量
• 冲突数量：检测到的命名冲突数

效果指标：

• AI生成代码采纳率
• 新人上手时间
• 跨团队沟通效率
• Bug率（因术语混淆导致的）

结论

🎯 Takeaway

核心洞察

洞察1：术语是AI理解的桥梁

AI不懂业务，但它可以理解映射。术语表就是这个映射。

洞察2：术语治理是AI代码生成的前置条件

没有术语治理，AI代码生成就是”garbage in, garbage out”。

洞察3：术语治理是人机协作的基础

人类用业务语言思考，AI用代码语言生成。术语表让两者对齐。

洞察4：术语治理需要持续投入

术语不是一次性的，而是随着业务发展不断演进的。

行动建议

立即行动：

1. 识别最严重的3个命名不一致问题
2. 建立最小化的术语表（核心域）
3. 在团队内宣导术语规范

本周目标：

1. 建立术语Git仓库
2. 制定命名规范文档
3. 配置IDE检查规则

本月目标：

1. 完成核心域术语定义
2. 集成到AI工具链
3. 建立术语变更流程

记住：

“术语治理的ROI极高：投入1小时统一术语，节省100小时的沟通成本。”

📚 延伸阅读

本系列相关

• AISE框架：AI-Native软件工程理论体系 (#34)
• Prompt Library的企业级管理 (#38)
• 知识资产化 (#10)

领域驱动设计（DDD）

• 《Domain-Driven Design》(Eric Evans)
• 《Implementing Domain-Driven Design》(Vaughn Vernon)
• Ubiquitous Language（通用语言）

命名规范

• Google Java Style Guide
• PEP 8 (Python)
• Microsoft TypeScript Guidelines

AI-Native软件工程系列 #39

深度阅读时间：约 10 分钟

最后更新: 2026-03-11