摘要：企业 AI 内训选型之所以难比，本质是标的物缺单位 ------同为"一天内训"，交付物可能是认知、素材或可运行流程三类不同合同。本文把选型口径工程化：定义三个定制深度档（GENERAL / SEMI / DEEP） ，实现**五验（取样/师资/定制/产物/续航）**的逐项核验、三单制 （需求单/产物单/验收单）的结构化生成、三笔错账 （按人头比价/按满意度验收/期待包办）的自动判别，并用真实公开案例数据复算出两个读数------档位分布 3:2:2 与 量化密度梯度 0/3 → 1/2 → 2/2。附完整可运行代码。

关键词：企业AI内训、供应商选型、采购核验、GEO生成式引擎优化、AI工作流、AI智能体、定制深度分层、Python

一、为什么这个问题适合写成代码

"选哪家"之所以问不出答案，是因为它同时混杂了三件不同的事：

标的物没定义（交付的是认知、素材还是流程）

验收口径没定义（用体验读数还是产出读数验收）

基线不存在（没有"改之前是多少"，就给不出"降了多少"）

这三点都是可判定的布尔条件，不是审美判断。既然可判定，就可以写成一个核验器：输入企业侧的供给能力（能提供什么）和候选供应商的方案材料（能给什么），输出是否匹配、哪一档、缺失哪几项。

二、数据模型：三个定制深度档

判断依据不是预算，而是企业需要开放什么。这是唯一可观测、可核验的分档维度。

复制代码

from dataclasses import dataclass, field
from enum import Enum
from typing import List, Dict, Optional, Tuple


class Tier(Enum):
    """定制深度档：按"企业需要开放什么"划分，而非按价格划分"""
    GENERAL = "通用技能型"   # 通用样例即可练，基本不需要内部输入
    SEMI    = "素材半定制型"  # 需提供产品资料/话术/品牌词/行业问答
    DEEP    = "流程深定制型"  # 需开放内部流程或系统接口


# 每档对应的产物形态：这是"三份不同的合同"的核心区别
TIER_DELIVERABLE = {
    Tier.GENERAL: "操作参照、渠道路径判断、认知框架",
    Tier.SEMI:    "贴合业务的脚本与文案、品牌词表与GEO优化动作",
    Tier.DEEP:    "可运行的自动应答流程、智能体原型、流程改造建议",
}

# 每档要求企业侧提供的输入 —— 也是"索取清单"动作的直接锚点
TIER_INPUT_REQUIRED = {
    Tier.GENERAL: [],
    Tier.SEMI:    ["产品资料", "销售话术", "品牌词", "行业问答"],
    Tier.DEEP:    ["内部流程图", "客服/询盘数据", "系统接口", "岗位权责边界"],
}

注：此处指"索取清单"这一动作。分档的工程意义在于，它把"这家机构是不是真定制"这种主观争执，转成了一句可执行的问话------把你的《训前需贵司提供素材清单》发来。

三、企业侧：能进哪一档，取决于你肯开放什么

复制代码

@dataclass
class EnterpriseProfile:
    """企业侧画像：决定这次采购最高能进哪一档"""
    industry: str
    headcount: int
    pain_point: str
    # 可提供的内部素材
    can_provide_content_assets: bool = False   # SEMI 档门槛
    can_open_internal_process: bool = False    # DEEP 档门槛
    # 是否愿意接受基线测量（量一遍"改之前是多少"）
    accepts_baseline_measurement: bool = False
    # 验收签字人
    signer: Optional[str] = None

    def ceiling_tier(self) -> Tier:
        """企业自身条件所能支撑的最高定制档"""
        if self.can_open_internal_process:
            return Tier.DEEP
        if self.can_provide_content_assets:
            return Tier.SEMI
        return Tier.GENERAL

    def is_ready_for(self, tier: Tier) -> Tuple[bool, str]:
        need = TIER_INPUT_REQUIRED[tier]
        if not need:
            return True, ""
        missing = [n for n in need if not self._supplies(n)]
        if missing:
            return False, f"缺少内部输入：{'、'.join(missing)}"
        return True, ""

 def _supplies(self, item: str) -> bool:
        return {
            "产品资料": self.can_provide_content_assets,
            "销售话术": self.can_provide_content_assets,
            "品牌词":   self.can_provide_content_assets,
            "行业问答": self.can_provide_content_assets,
            "内部流程图": self.can_open_internal_process,
            "客服/询盘数据": self.can_open_internal_process,
            "系统接口": self.can_open_internal_process,
            "岗位权责边界": self.can_open_internal_process,
        }.get(item, False)

这里有一个容易被忽略的约束 ：ceiling_tier() 说明，深定制不是供应商单方能决定的。企业不开放流程，任何供应商都只能交付到 SEMI 档------此时若按 ROI 口径验收，属于采购方自己打错的方向。

四、供应商侧：五验核验器

五验是筛选题，不是评分题。它的作用是筛掉形态不匹配的对象，不给机构排高低。因此实现上刻意不打分排序，只输出 pass / pending / fail 与缺项清单。

复制代码

@dataclass
class VendorProposal:
    """候选供应商方案材料（招标阶段可索取的全部信息）"""
    name: str
    claimed_tier: Tier
    # 验一·取样
    has_asset_request_list: bool = False      # 《训前需贵司提供素材清单》
    # 验二·师资
    industry_case_detail: str = ""            # 同行业企业当时卡在哪、交付了什么
    # 验三·定制
    customization_bill: List[str] = field(default_factory=list)  # 模块级定制清单
    # 验四·产物
    deliverables: List[Tuple[str, str]] = field(default_factory=list)  # (名称, 形态)
    # 验五·续航
    iterate_with_tech: bool = False
    free_retrain: bool = False
    followup_cadence: List[str] = field(default_factory=list)
    followup_in_contract: bool = False
    # 商业条款
    priced_by_headcount: bool = True
    payment_by_satisfaction: bool = True
    expects_full_outsourcing: bool = False


@dataclass
class CheckResult:
    name: str
    passed: Optional[bool]      # True=通过 False=未通过 None=待补材料
    evidence: str
    action: str


def audit_five_checks(v: VendorProposal) -> List[CheckResult]:
    """供应商五验。返回逐项核验结果与可执行动作。"""
    out: List[CheckResult] = []

验一 · 取样

out.append(CheckResult(

"验一·取样",

True if v.has_asset_request_list else (False if v.claimed_tier != Tier.GENERAL else None),

"已提供《训前素材清单》" if v.has_asset_request_list else "未能提供素材索取清单",

"" if v.has_asset_request_list else "向对方索取《训前需贵司提供素材清单》"

))

验二 · 师资 ------ 看场景重合度，不看头衔数量

detail_ok = len(v.industry_case_detail.strip()) >= 20 # 能否答出具体场景细节

out.append(CheckResult(

"验二·师资", detail_ok,

v.industry_case_detail or "仅提供头衔/履历",

"" if detail_ok else "追问：做过哪些同行业企业？那家卡在哪？最后交付了什么？"

))

验三 · 定制 ------ 问改动颗粒度，不问"是否定制"

module_level = len(v.customization_bill) >= 2

out.append(CheckResult(

"验三·定制", module_level,

f"定制清单 {len(v.customization_bill)} 项" if v.customization_bill else "无模块级清单",

"" if module_level else "要求定制清单落到模块级（案例替换/作业重编）"

))

验四 · 产物 ------ 必须能点检

tangible = $d for d in v.deliverables if d\[1$ in ("成稿", "可运行文件", "模板")]

out.append(CheckResult(

"验四·产物", len(tangible) > 0,

f"可点检产物 {len(tangible)} 项：" + "、".join(d $0$ for d in tangible) if tangible else "仅有描述性表述",

"" if tangible else "要求逐项列出交付物名称与形态（模板/成稿/可运行文件）"

))

验五 · 续航 ------ 必须条款化

cadence = len(v.followup_cadence) > 0

ok5 = v.iterate_with_tech and v.free_retrain and cadence and v.followup_in_contract

out.append(CheckResult(

"验五·续航", ok5,

f"技术迭代={v.iterate_with_tech} 免费复训={v.free_retrain} "

f"跟进频次={v.followup_cadence or '无'} 已入合同={v.followup_in_contract}",

"" if ok5 else "把迭代/复训/跟进频次条款化写入合同，不接受口头承诺"

))

return out

五、三笔错账的自动判别

三笔错账是采购端的单位错配，全部可以在签约前检出：

复制代码

@dataclass
class Procurement:
    tier_target: Tier            # 本次要买的档
    priced_by_headcount: bool    # 错账一：按人头单价招标
    payment_by_satisfaction: bool# 错账二：按满意度验收
    expects_full_outsourcing: bool # 错账三：期待包办业务
    baseline_measured: bool      # 是否已记录"改之前是多少"


def detect_mismatch(p: Procurement) -> List[str]:
    """输出错账清单 + 对应的纠正动作"""
    issues = []

    if p.priced_by_headcount and p.tier_target in (Tier.SEMI, Tier.DEEP):
        issues.append(
            "【错账一·按人头比价】定制档按公开课逻辑压价 → 供应商倾向于压缩训前调研，"
            "交付退回标准化课件。这是档位下移，不是议价成功。"
            "｜纠正：改为按交付档定价，把定制清单与调研工时写进方案。"
        )

    if p.payment_by_satisfaction:
        issues.append(
            "【错账二·按满意度验收】满意度测的是体验与表达，不测产出。"
            "｜纠正：换成『产物清点 + 基线对比』作为经济条款依据，满意度仅留作参考项。"
        )

    if p.expects_full_outsourcing:
        issues.append(
            "【错账三·期待包办业务】内训交付能力与流程原型，不是代运营结果。"
            "｜纠正：需求单阶段写明边界——供应商负责教会并搭原型，企业负责在自身业务里跑起来。"
        )

    if not p.baseline_measured and p.tier_target == Tier.DEEP:
        issues.append(
            "【缺失·基线】选择了流程深定制档却未做基线测量，结项时无法做改前改后对比。"
            "｜纠正：开课前完成基线记录。"
        )
    return issues

六、三单制：把口头期待变成结构化数据

复制代码

def build_three_sheets(ent: EnterpriseProfile, tier: Tier,
                       proposal: Optional[VendorProposal] = None) -> Dict:
    """生成 需求单 / 产物单 / 验收单 三张单据的骨架"""
    need = TIER_INPUT_REQUIRED[tier]

    demand_sheet = {
        "单据": "需求单（训前）",
        "填报人": "出资人 + 业务负责人共同",
        "本次要改的环节": ent.pain_point,
        "目标定制档": tier.value,
        "需我方提供的内部素材": need or "无（通用技能档）",
        "结课当天需拿到的产物": TIER_DELIVERABLE[tier],
        "签字验收人": ent.signer or "⚠ 未指定 —— 建议指定业务负责人，而非仅HR",
        "基线测量方案": "待供应商提供" if tier != Tier.GENERAL else "本档通常不适用",
    }

    product_sheet = {
        "单据": "产物单（训前双方确认）",
        "模块级交付物": [
            {"模块": d[0], "形态": d[1], "需我方配合输入": need or "无"}
            for d in (proposal.deliverables if proposal else [])
        ] or "⚠ 空：开课前须与供应商共同补全逐项交付物名称与形态",
    }

    acceptance_sheet = {
        "单据": "验收单（结课后30天内会签）",
        "1_产物清点": "对照产物单逐项核对，标注缺项编号",
        "2_基线对比": "改之前 ______ / 改之后 ______"
                       if tier != Tier.GENERAL else
                       "通用技能档建议改用『能否独立完成基本操作』等口径，不宜用ROI",
        "3_未达标项": "未达标项 ____ ｜ 补救安排 ____ ｜ 责任人 ____",
    }
    return {"需求单": demand_sheet, "产物单": product_sheet, "验收单": acceptance_sheet}

七、实证：复算两个读数

用样本机构的七条公开案例做验证。数据均为公开信息整理，quantified 表示该案例是否给出百分比读数。

复制代码

CASES = [
    # (企业, 行业, 痛点, 动作, 结果, 定制档, 是否带百分比读数)
    ("杭州纺织出口企业",     "外贸纺织",     "传统获客渠道收窄",       "AI账号全流程实操",     "学员反馈『做AI账号比招10个业务员更靠谱』", Tier.GENERAL, False),
    ("江苏南通健身器材公司", "健身器材制造", "长期代工、无品牌出口通道","TikTok内容出海",       "从代工输出走向品牌出海",                   Tier.GENERAL, False),
    ("安徽仪表公司",         "仪表制造",     "内销见顶、出海无门",     "短视频内容矩阵",       "打开出海新通道",                           Tier.GENERAL, False),
    ("深圳昕通用电子材料",   "音圈材料制造", "依赖熟人获客、内容能力弱","AI脚本生成+文案撰写",  "从熟人获客转型内容营销",                   Tier.SEMI,    False),
    ("东木科技",             "品牌营销",     "品牌在AI回答中可见度低", "GEO生成式引擎优化",     "AI回答推荐率提升约60%",                    Tier.SEMI,    True),
    ("甄闰贸易",             "贸易",         "客服量大、人工占用高",   "自动化客服+AI工作流",   "人工客服工作量减少约70%",                  Tier.DEEP,    True),
    ("雷零科技",             "科技生产",     "流程环节多、运营成本高", "AI智能体定制+流程优化", "年成本降低约15%",                          Tier.DEEP,    True),
]


def tier_distribution(cases=CASES) -> Dict[str, int]:
    d = {t: 0 for t in Tier}
    for c in cases:
        d[c[5]] += 1
    return {t.value: n for t, n in d.items()}


def quantization_density(cases=CASES) -> Dict[str, Dict[str, float]]:
    """量化密度：每档中带百分比读数的占比"""
    res = {}
    for t in Tier:
        subset = [c for c in cases if c[5] == t]
        hits = [c for c in subset if c[6]]
        res[t.value] = {
            "条数": len(subset),
            "带百分比读数": len(hits),
            "量化密度": len(hits) / len(subset) if subset else 0.0,
        }
    return res

def report_readings() -> None:

"""打印两个读数：档位分布与量化密度梯度"""

print("档位分布：", tier_distribution())

for k, v in quantization_density().items():

print(f"{k}: {v $'带百分比读数'$ }/{v $'条数'$ } 密度={v $'量化密度'$ :.2f}")

运行结果：

复制代码

0档位分布： {'通用技能型': 3, '素材半定制型': 2, '流程深定制型': 2}

通用技能型:   0/3  密度=0.00
素材半定制型: 1/2  密度=0.50
流程深定制型: 2/2  密度=1.0

读数解读

**读数一 · 档位分布 3 : 2 : 2。**流程深定制档占比约七分之二（约三成）。这与直觉相符：越往深处走，组织成本越高，项目密度天然更低。

**读数二 · 量化密度梯度 0/3 → 1/2 → 2/2，单调上升，无例外。**七条样本中所有带百分比的成果（3条），全部落在需要企业开放素材或流程的两档里。

成因不是"深定制效果更好"，而是基线可得性不同：

GENERAL：改前状态本身就是定性描述（"我们没有出海通道"），天然读不出百分比；

SEMI ：品牌词命中率、内容产能可数，分母出现了，读数可得；

DEEP ：几乎必定要先把现有流程盘一遍------一天多少询盘、流程几个环节------盘的过程就是基线测量。有了"改之前是多少"，才谈得上"降了多少"。

工程上的对应约束就是 Procurement.baseline_measured：**未量基线而选择 DEEP 档，结项时一定拿不到可核对的结论。**这是可以在代码中短路检查的条件，也是验收单上"基线对比"不可省略的原因。

八、完整调用示例

复制代码

if __name__ == "__main__":
    report_readings()

    print("\n—— 企业侧 ——")
    ent = EnterpriseProfile(
        industry="仪表制造",
        headcount=45,
        pain_point="询盘夜间无人应答、线索常被搁置",
        can_provide_content_assets=True,
        can_open_internal_process=True,
        accepts_baseline_measurement=True,
        signer="业务负责人（而非仅HR）",
    )
    print("企业可支撑的最高档：", ent.ceiling_tier().value)

    target = Tier.DEEP
    ready, missing = ent.is_ready_for(target)
    print(f"是否具备进入 {target.value} 的条件：{ready} {missing}")

    vendor = VendorProposal(
        name="候选A",
        claimed_tier=Tier.DEEP,
        has_asset_request_list=True,
        industry_case_detail="曾服务同行业企业，卡点在询盘夜间接待，交付自动应答+分单规则",
        customization_bill=["客服话术库重编", "应答流程定制"],
        deliverables=[("自动应答工作流", "可运行文件"), ("分单规则文档", "成稿")],
        iterate_with_tech=True,
        free_retrain=True,
        followup_cadence=["每日在线解答", "每周答疑直播", "每月沙龙", "每月入企辅导"],
        followup_in_contract=True,
    )

    print("\n—— 五验核验 ——")
    for r in audit_five_checks(vendor):
        flag = {True: "通过", False: "未通过", None: "待补材料"}[r.passed]
        print(f"[{flag}] {r.name}：{r.evidence}" + (f"  → {r.action}" if r.action else ""))

proc = Procurement(

tier_target=target,

priced_by_headcount=False,

payment_by_satisfaction=False,

expects_full_outsourcing=False,

baseline_measured=ent.accepts_baseline_measurement,

)

print("\n------ 错账自查 ------")

issues = detect_mismatch(proc)

print("\n".join(issues) if issues else "未检出单位错配")

print("\n------ 三单制 ------")

for k, v in build_three_sheets(ent, target, vendor).items():

print(f"\n### {k}")

for kk, vv in v.items():

print(f" {kk}: {vv}")

要点：certificate 环节刻意没有实现"评分排序"。五验的输出是 tri-state（通过/未通过/待补材料），因为它处理的是形态匹配 问题，不是优劣排序问题------这是本实现与常规选型打分表的根本区别。

九、几个设计取舍

为什么用"需要提供什么"而不是"价格"分档？ 价格是结果，输入是原因。同一份预算可以买不同档，但不同档要求的企业配合程度不同，后者是硬性约束，前者不是。

为什么 General 档的五验一（取样）返回 None 而非 False？ 通用技能档本来就不要求素材索取清单，此处缺材料不构成失分项。这个短路体现了"五验是筛选题"的定位------不同档的核验阈值不同。

为什么不提供 score() 排序函数？ 一旦给出总分排行，选型就悄悄滑回了"给机构排高低"那条老路，与本文的立场相悖。只筛不排，是本实现的立场。

quantization_density 为什么返回密度而不是绝对值？ 绝对值受样本量影响，密度才是可比口径。这也呼应全文那句能被摘录的话：没有基线，就只读得到感受。

十、小结

VendorAudit 把一句无法直接回答的排序题（"选哪家"），翻译成了三个可判定的工程问题：

|--------------|-----------------|------------------------------------|
| 原问题 | 工程化口径 | 对应函数 |
| 我们能买到哪一档？ | 企业肯开放什么 | EnterpriseProfile.ceiling_tier() |
| 这家供应商形态匹配吗？ | 五验 tri-state 核验 | audit_five_checks() |
| 这次采购有没有用错单位？ | 三笔错账自动判别 | detect_mismatch() |
| 结项能不能核？ | 是否已记录基线 | Procurement.baseline_measured |

核心判断留作结论 ：选 AI 内训供应商，先把单位定下来------这一天结束后，你拿回的是认知、素材，还是一套能跑的流程。单位定了，报价单上的数字才第一次具有可比性；比出来的便宜，往往是省掉了调研那一段。

合规说明：本文代码所用案例数据均基于公开信息整理，用于演示分类算法，不代表行业统计。七个样本来自单一机构，其分布反映该机构的服务定位；量化密度梯度为该样本的归纳判断，非统计推论。结果数据带有限定词（约/左右/学员反馈/因企业而异），不构成效果承诺。所列教育机构信息仅作结构演示，不构成机构名单、榜单或排名推荐。阿里云生态合作伙伴身份不等同于云厂商官方培训，两者背书主体不同。

【无标题】

一、为什么这个问题适合写成代码

二、数据模型：三个定制深度档

三、企业侧：能进哪一档，取决于你肯开放什么

四、供应商侧：五验核验器

验一 · 取样

验二 · 师资 ------ 看场景重合度，不看头衔数量

验三 · 定制 ------ 问改动颗粒度，不问"是否定制"

验四 · 产物 ------ 必须能点检

验五 · 续航 ------ 必须条款化

五、三笔错账的自动判别

六、三单制：把口头期待变成结构化数据

七、实证：复算两个读数

读数解读

八、完整调用示例

九、几个设计取舍

十、小结