企业官网建设流程全解析

1. 为什么“先选模型”是大多数企业AI项目翻车的起点

我见过太多团队在AI项目启动会上，第一个议题就是“咱们用哪个大模型”。讨论得热火朝天，从参数规模比到榜单排名，从开源方案聊到闭源API，结果三个月过去，Demo都没跑通一个。问题出在哪？不是技术能力不行，而是顺序搞反了。

企业AI落地和做技术选型实验完全是两码事。实验室里你可以为了跑一个benchmark去折腾环境、调参、换模型，因为目标就是验证模型能力上限。但企业场景里，模型只是整个系统中的一个组件，它的价值取决于它嵌入的业务流程能不能跑通、能不能产生可衡量的收益。你选了一个榜单第一的模型，结果发现它在你最核心的业务场景上响应延迟超标，或者推理成本是预算的三倍，那这个选择就是负分。

“别先选模型”这句话听起来像是一句正确的废话，但真正能做到的团队少之又少。原因很现实：模型选型是最容易讨论、最容易出结论、最容易让所有人觉得自己在推进事情的环节。而场景优先级排序需要深入业务、需要跟一线人员对齐、需要面对“这个需求到底值多少钱”这种让人不舒服的问题。人性天然倾向于做简单且看起来有进展的事，选模型恰好满足这个心理。

所以这篇文章要讲的，是一套在选模型之前就应该完成的七维排序方法。它的核心目的只有一个：让你在打开任何模型文档之前，就已经清楚知道哪个场景先做、哪个场景后做、哪个场景现在根本不该做。这套方法不依赖任何特定模型或平台，它是一套思考框架，适用于任何行业、任何规模的企业AI项目。

我把它拆成七个维度，每个维度都有明确的评估标准和打分逻辑。你可以直接拿一张Excel表，把候选场景列进去，逐项打分，最后按总分排序。整个过程不需要写一行代码，但它的价值远超任何技术选型文档。

2. 七维排序法的完整框架与打分逻辑

2.1 第一维：业务价值密度——这个场景到底值多少钱

业务价值密度是我最看重的维度，没有之一。它的核心问题是：这个场景如果做成了，能带来多少可量化的收益，或者避免多少可量化的损失？

注意“可量化”三个字。很多团队在评估业务价值时喜欢用“提升效率”“改善体验”这种模糊表述，这等于没评估。你需要把价值翻译成财务语言：节省了多少人力工时、减少了多少客诉赔付、提升了多少转化率、缩短了多少交付周期。哪怕是一个粗略的估算，也比模糊描述强一百倍。

具体打分时，我建议用“年化价值”作为统一口径。比如一个智能客服场景，预计能替代5个全职客服的工作量，每个客服年成本10万，那这个场景的年化价值就是50万。另一个场景是合同审核辅助，预计能把法务审核时间从平均2小时缩短到20分钟，法务团队每年处理2000份合同，按时薪折算，年化价值可能是80万。这样一对比，优先级就清晰了。

但这里有个陷阱：不要只看绝对价值，要看价值密度。一个年化价值500万的场景，如果需要投入20人月的开发资源，另一个年化价值200万的场景只需要3人月，后者的价值密度更高，应该优先做。所以我在打分时通常用“年化价值/预估投入”作为最终得分，这样能避免被大数字迷惑。

还有一个容易被忽略的点：价值的确定性。有些场景的价值是板上钉钉的，比如替代外包标注团队，做成了就是省钱。有些场景的价值是概率性的，比如提升推荐转化率，效果取决于模型能力、用户行为、市场竞争等多重因素。对于确定性高的场景，我会在打分上给一个1.2到1.5的系数；对于确定性低的，给0.6到0.8的折扣。这不是精确科学，但能防止团队把资源押注在“可能很美好”的场景上。

2.2 第二维：数据就绪度——你手里到底有没有“燃料”

AI项目烧的是数据，不是算法。一个场景的业务价值再高，如果数据就绪度不够，强行上马就是给自己挖坑。数据就绪度我通常拆成四个子项来评估：数据可得性、数据质量、标注成本、隐私合规。

数据可得性是最基础的：这个场景需要的数据，你现在有没有？如果没有，能不能在合理时间内拿到？我见过一个团队想做设备故障预测，业务价值极高，但设备传感器数据分散在三个不同的老旧系统里，接口文档缺失，数据格式不统一。光是打通数据就花了四个月，项目还没进入建模阶段，业务方的耐心已经耗尽了。所以对于数据可得性差的场景，要么先立项做数据治理，要么直接降权处理。

数据质量比可得性更隐蔽。有些数据你能拿到，但里面全是噪声。比如客服对话记录，如果ASR转写准确率只有70%，那基于这些文本做意图分类的效果必然大打折扣。评估数据质量时，我建议抽样100到200条真实数据，人工检查关键字段的准确率、完整率、一致性。这个动作花不了两天，但能避免后面几个月的无效劳动。

标注成本经常被低估。监督学习场景需要标注数据，而标注是人力密集型工作。一个实体识别场景，如果标注一条数据需要2分钟，你需要1万条训练数据，那就是333个小时的标注工作量。按每人每天有效标注6小时算，需要将近两个月。这还没算标注规范制定、标注质量抽检、标注人员培训的时间。所以对于标注成本高的场景，要么优先考虑少样本或零样本方案，要么在排序时把标注成本折算成时间成本扣减价值得分。

隐私合规是一票否决项。如果场景涉及个人敏感信息，而企业又没有相应的数据脱敏能力和合规流程，这个场景再诱人也得往后放。这不是技术问题，是法律和品牌风险问题。我在打分时会把隐私合规风险分为“无风险”“低风险”“中风险”“高风险”四档，高风险场景直接标记为“暂缓”，不进入排序池。

2.3 第三维：技术可行性——现有手段能不能搞定

技术可行性这个维度最容易被高估，也最容易被低估。高估是因为很多团队看了几篇论文就觉得“这个能做”，低估是因为有些团队被之前的失败项目吓怕了，觉得“这个肯定做不了”。我的经验是：不要凭感觉判断，要拆解成具体的技术子问题，逐个评估成熟度。

拆解的方法很简单：把这个场景的AI需求写成一句话，然后问自己“这句话里哪些部分是目前技术能稳定解决的，哪些部分是碰运气的”。比如“自动从合同扫描件中提取关键条款并生成风险提示”，拆解后是：OCR识别扫描件（成熟）、条款实体抽取（较成熟）、风险规则匹配（成熟）、风险提示生成（较成熟）。四个子问题里没有一个是“碰运气”级别的，那这个场景的技术可行性就很高。

反过来，“根据客户情绪实时调整话术并预测成交概率”，拆解后是：语音情绪识别（中等成熟，噪声环境下不稳定）、实时话术生成（较成熟但延迟要求高）、成交概率预测（依赖大量历史数据，冷启动困难）。这里面有多个子问题存在不确定性，技术可行性就要打折扣。

我通常用一个简单的三级评估：成熟（有大量成功案例，可直接复用）、较成熟（有案例但需要调优，存在一定风险）、探索期（案例少，效果不稳定，需要预研）。如果一个场景里“探索期”的子问题超过两个，我会建议先做技术预研，不进入正式排序，等预研结果出来再评估。

还有一个实操心得：不要用“最先进”作为技术可行性的标准，要用“最稳定”。企业场景里，一个准确率85%但稳定运行的方案，价值远高于一个准确率92%但三天两头出故障的方案。所以在评估技术可行性时，我会优先考虑那些有成熟工程实践的技术路线，而不是追新。

2.4 第四维：流程嵌入度——AI输出能不能顺畅接入现有工作流

这个维度是我在踩了无数次坑之后才加进来的。很多AI项目在技术验证阶段表现很好，一到上线就崩，原因不是模型不行，而是AI的输出和现有工作流格格不入。

流程嵌入度评估的是：AI产出的结果，需不需要人工二次处理？需不需要改变现有岗位的操作习惯？需不需要和其他系统做深度集成？这三个问题的答案越复杂，嵌入度越差，优先级越低。

举个例子：一个智能工单分类场景，AI把工单分到对应部门。如果现有工单系统有开放的API，AI分类结果可以直接写回去，工单自动流转，那嵌入度就很高。但如果现有系统没有API，需要人工把AI分类结果复制粘贴到另一个界面，那这个场景的落地价值就大打折扣，因为省下来的分类时间又被新增的复制粘贴操作吃回去了。

流程嵌入度还涉及组织接受度。有些岗位天然抵触AI辅助，觉得是在质疑他们的专业能力。这种情况下，即使技术方案完美，落地也会遇到软性阻力。我在评估时会跟一线主管聊，了解他们对AI介入的态度。如果抵触情绪明显，我会建议先做“辅助决策”而不是“自动决策”，让AI只给建议，最终决定权还在人手里，等信任建立后再逐步放权。

打分时我用“嵌入阻力”作为指标：低阻力（API直连，无需改变操作习惯）、中阻力（需要少量人工确认或简单集成）、高阻力（需要改变岗位职责或深度改造现有系统）。高阻力的场景不是不能做，但需要额外预留变革管理的时间和资源，在排序时应该往后放。

2.5 第五维：投入产出周期——多久能看到回头钱

企业AI项目最怕的是“三年不开张，开张吃三年”。大多数业务方没有耐心等三年，他们需要的是在可见的周期内看到可衡量的回报。所以投入产出周期是一个非常现实的排序维度。

我把周期分为四档：一个月内（快速见效）、一到三个月（短期）、三到六个月（中期）、六个月以上（长期）。快速见效的场景应该优先做，因为它们能建立信心、争取后续资源、积累内部案例。中期和长期场景不是不重要，但它们需要更强的理由才能排在前面。

这里有个策略性的考量：用快速见效的场景养长期场景。比如你先做一个智能文档摘要的场景，两周上线，业务方立刻感受到效率提升，这时候你再提“我们想做一个需要三个月的数据治理项目来支撑更复杂的分析”，业务方批预算的概率就大得多。反过来，如果你一上来就推一个六个月才能看到效果的项目，很可能在第三个月就被叫停了。

投入产出周期还跟资源占用有关。有些场景虽然见效快，但需要占用核心算法工程师的全部时间，导致其他场景无法推进。这种情况下，我会评估是否有更轻量的替代方案，比如用现成API而不是自研模型，用规则引擎而不是机器学习。轻量方案虽然效果上限低，但能快速验证价值，等价值被认可后再迭代升级。

2.6 第六维：可扩展性——做完这个，下一个能不能复用

可扩展性这个维度经常被忽略，但它决定了你的AI能力是“一次性项目”还是“可积累资产”。评估可扩展性时，我问三个问题：这个场景沉淀的数据能不能用于其他场景？这个场景开发的组件能不能被其他场景复用？这个场景验证的流程能不能推广到其他部门？

比如你做一个合同审核场景，沉淀了合同领域的实体识别模型、条款分类器、风险规则库。这些组件在采购合同、销售合同、劳动合同审核中都能复用，那可扩展性就很高。反过来，如果你做一个非常垂直的设备故障诊断场景，模型只适用于特定型号设备，数据只来自特定产线，那可扩展性就很低，做完这个场景后下一个场景几乎要从零开始。

可扩展性高的场景，即使当前业务价值不是最高，也值得优先考虑，因为它能降低后续场景的边际成本。我在打分时会给可扩展性高的场景一个1.1到1.3的系数，给可扩展性低的场景一个0.8到0.9的折扣。这个调整幅度不大，但在多个场景得分接近时，往往能起到决定性的区分作用。

还有一个实操建议：优先选择那些能沉淀“数据飞轮”的场景。所谓数据飞轮，就是用户使用AI产品产生新数据，新数据反过来提升AI效果，效果提升吸引更多用户使用。比如智能客服场景，每次对话都在产生新的语料，这些语料可以用来优化意图识别和回复生成，形成正向循环。这种场景的长期价值远超一次性项目。

2.7 第七维：风险可控性——最坏情况能不能兜住

最后一个维度是风险可控性。AI项目有太多不确定性：模型效果不达预期、数据质量出问题、业务方中途改需求、关键人员离职。这些风险如果失控，轻则项目延期，重则项目取消甚至造成业务损失。所以我在排序时一定会评估：这个场景如果失败了，最坏情况是什么？能不能兜住？

风险可控性高的场景有几个特征：失败成本低（投入资源少）、失败影响小（不影响核心业务）、失败可回退（能回到人工流程）。比如一个内部知识库问答场景，即使AI回答不准，员工也可以自己搜索文档，不会造成外部损失。这种场景就适合作为早期试点。

风险可控性低的场景则相反：失败成本高、影响核心业务、无法回退。比如一个自动交易决策场景，AI判断错误可能导致直接资金损失，而且交易一旦执行无法撤销。这种场景即使业务价值再高，也应该放在最后，等前面场景积累了足够的信任和技术能力后再考虑。

我在打分时用“风险等级”来量化：低风险（失败无实质影响）、中风险（失败有可控损失）、高风险（失败有重大损失或合规问题）。高风险场景直接标记为“需额外审批”，不进入常规排序。这不是说高风险场景不能做，而是说它们需要更严格的论证和更充分的准备，不能和低风险场景放在同一个池子里比较。

3. 把七个维度拼成一张可执行的排序表

3.1 打分表的设计与权重分配

七个维度讲完了，现在把它们拼成一张可操作的打分表。我通常用Excel或在线表格，列是候选场景，行是七个维度，每个维度按1到5分打分，最后加权求和。

权重分配没有绝对标准，取决于企业当前阶段。如果企业是第一次做AI项目，我会把业务价值密度、数据就绪度、风险可控性的权重调高，因为早期项目需要快速证明价值且不能出大问题。如果企业已经有多个成功AI项目，想追求更大突破，我会把可扩展性和投入产出周期的权重调高，因为这时候需要构建长期能力而不是单点突破。

一个参考权重方案：业务价值密度25%、数据就绪度20%、技术可行性15%、流程嵌入度10%、投入产出周期10%、可扩展性10%、风险可控性10%。这个方案偏保守，适合大多数传统企业的第一次AI尝试。你可以根据自己情况调整，但有一条原则：业务价值密度和数据就绪度的权重加起来不应低于40%，因为这两个维度是AI项目成败的决定性因素。

打分时有个技巧：每个维度先定“及格线”再打分。比如数据就绪度，如果数据完全拿不到，直接0分；如果数据能拿到但质量差，2分；如果数据质量好但需要标注，3分；如果数据现成且质量好，5分。这样能避免打分时的主观随意性。

3.2 场景拆解：从模糊需求到可打分单元

打分表设计好了，但很多团队卡在第一步：候选场景怎么列？业务方给的需求往往是“我们要用AI提升客服效率”，这是一个模糊需求，不是一个可打分场景。你需要把它拆解成具体的AI应用点。

拆解方法我常用“动词+对象+AI能力”的公式。比如“提升客服效率”可以拆成：自动回答常见问题（问答能力）、自动分类工单（分类能力）、自动总结对话（摘要能力）、自动推荐回复话术（生成能力）。每个拆解出来的点都是一个独立场景，可以单独打分。

拆解时要注意颗粒度适中。太粗了没法打分，比如“智能客服”就是一个太粗的场景。太细了管理成本高，比如“自动识别客户说的‘你好’并回复‘您好’”就是一个太细的场景。我的经验是：一个场景应该对应一个明确的AI能力，且能独立上线产生价值。按这个标准，“自动回答常见问题”是一个合适的颗粒度。

拆解完成后，把所有场景列出来，先做一轮快速筛选：明显不靠谱的（数据完全没有、技术完全不可行、风险完全不可控）直接剔除，剩下的进入正式打分。这一轮筛选不需要太严格，宁可多留几个，打分阶段自然会区分出优劣。

3.3 打分实操：一个制造业企业的完整案例

为了让你更直观地理解，我用一个制造业企业的案例来演示完整打分过程。这家企业想做AI质检、AI排产、AI设备维护、AI文档问答四个场景。我们逐个维度打分。

业务价值密度：AI质检能替代3个质检员，年化价值约30万；AI排产能提升设备利用率5%，年化价值约100万；AI设备维护能减少非计划停机，年化价值约80万；AI文档问答能减少工程师查资料时间，年化价值约20万。按价值密度排序：排产>设备维护>质检>文档问答。

数据就绪度：质检有历史图像数据但标注不完整，打3分；排产有历史排产记录但格式混乱，打2分；设备维护有传感器数据但采样频率低，打2分；文档问答有现成文档库，打4分。

技术可行性：质检的缺陷检测有成熟方案，打4分；排产的约束优化问题复杂，打3分；设备维护的预测性维护在学术界成熟但工业界案例少，打2分；文档问答的RAG方案成熟，打4分。

流程嵌入度：质检需要和产线PLC集成，打2分；排产需要和ERP对接，打3分；设备维护需要和工单系统打通，打3分；文档问答独立使用，打5分。

投入产出周期：质检预计2个月上线，打3分；排产预计4个月，打2分；设备维护预计6个月，打1分；文档问答预计1个月，打5分。

可扩展性：质检模型可复用到其他产线，打4分；排产逻辑可复用到其他工厂，打4分；设备维护模型可复用到其他设备类型，打3分；文档问答可复用到其他部门，打4分。

风险可控性：质检失败可回退人工，打4分；排产失败影响生产计划，打2分；设备维护失败可能导致意外停机，打2分；文档问答失败无实质影响，打5分。

按参考权重加权求和后，文档问答得分最高，质检次之，排产第三，设备维护最低。这个结果和很多人的直觉相反——业务价值最高的排产反而排第三。原因很简单：排产的数据就绪度低、技术可行性中等、风险可控性差，综合下来不如文档问答和质检适合作为起步场景。

这个案例告诉我们：业务价值高不等于优先级高。企业AI落地要的是综合胜率，不是单点最优。

4. 排序之后：从优先级到落地节奏的转换

4.1 第一批场景的选择原则

排序表出来了，但不要机械地按分数从高到低做。第一批场景的选择有额外的策略考量。我的原则是：第一批做两个场景，一个“速赢场景”加一个“能力场景”。

速赢场景是分数最高、最快能上线的那个，它的使命是在一个月内让业务方看到实实在在的效果，建立信任、争取后续资源。能力场景是分数中上、但能沉淀可复用能力的那个，它的使命是为后续场景打基础，哪怕见效慢一点也没关系。

为什么是两个而不是一个？因为只做速赢场景，你会陷入“一直在做简单场景”的困境，能力没有积累。只做能力场景，你可能在能力建成之前就被业务方叫停了。两个一起做，速赢场景提供短期信心，能力场景提供长期价值，节奏最稳。

4.2 被搁置场景的重新评估时机

排序靠后的场景不是永远不做，而是在当前条件下不适合做。条件会变，所以需要定期重新评估。我通常建议每季度重新跑一次排序表，重点看三个变化：数据就绪度有没有提升、技术可行性有没有突破、业务价值有没有变化。

比如一个场景因为数据质量差被搁置，如果这季度完成了数据治理，它的数据就绪度得分会大幅提升，排名可能从倒数变成前三。另一个场景因为技术不成熟被搁置，如果出现了新的开源方案或工具链，技术可行性得分也会提升。所以搁置不等于放弃，而是“等待条件成熟”。

重新评估时要注意不要频繁切换方向。有些团队每个季度都换一批场景做，结果哪个都没做完。我的建议是：一旦启动一个场景，至少给它一个完整的投入产出周期，除非遇到不可逾越的障碍。频繁切换的代价是团队疲于奔命、业务方失去耐心、技术积累归零。

4.3 排序方法本身的迭代

七维排序法不是一成不变的。随着企业AI成熟度提升，维度和权重都应该调整。比如企业第一次做AI时，风险可控性权重很高，因为输不起。等做了三四个成功项目后，风险承受能力增强，可以把更多权重给可扩展性和业务价值密度，追求更大突破。

另外，维度本身也可以细化。比如“数据就绪度”在早期是一个粗粒度指标，等企业有了数据治理体系后，可以拆成“数据覆盖率”“数据更新频率”“数据标注质量”三个子维度，评估更精确。

我自己的习惯是：每做完一个AI项目，复盘时顺便回顾排序表，看看当初的打分和实际结果差多少。如果某个维度反复出现“打分偏高但实际踩坑”的情况，说明这个维度的评估标准需要修正。这种迭代不需要很正式，每次花半小时记录一下就行，但长期积累下来，你的排序直觉会越来越准。

5. 几个容易踩的排序陷阱与我的应对经验

5.1 被“技术炫酷度”带偏

这是最常见的陷阱。某个场景用了最前沿的技术方案，团队讨论时兴奋不已，打分时不知不觉就给技术可行性打了高分。但技术炫酷度和业务价值没有必然关系，甚至往往是负相关——越炫酷的技术，工程成熟度越低，落地风险越高。

我的应对方法很简单：在技术可行性打分时，强制要求提供至少一个同行业或同场景的成功案例。如果找不到案例，最高只能打3分。这个规则看起来粗暴，但能有效过滤掉“为了用技术而用技术”的场景。

5.2 忽略“隐性成本”

很多场景在打分时只算了开发成本，忽略了运维成本、标注成本、算力成本、变革管理成本。这些隐性成本加起来往往是开发成本的两三倍。一个场景开发只花了一个月，但上线后每月需要两个人维护标注流水线，一年下来就是24人月，远超开发投入。

我的应对方法：在投入产出周期打分时，把“上线后第一年的总拥有成本”作为分母，而不是只看开发周期。这样能更真实地反映场景的经济性。

5.3 业务方“会哭的孩子有奶吃”

有些业务方嗓门大、催得紧，他们的场景就容易被排到前面。但嗓门大不等于价值高，可能只是他们更擅长表达或者更急于表现。如果排序被嗓门大小左右，资源就会流向低价值场景。

我的应对方法：所有场景统一走打分表，不接受“特事特办”。如果某个业务方坚持要插队，可以，但需要他们自己提供数据证明这个场景的价值密度确实高于当前排在前面的场景。这个门槛能过滤掉大部分情绪化需求。

5.4 把“技术可行性”等同于“团队能力”

有些场景技术上是可行的，但你的团队没做过，需要学习成本。如果打分时只考虑技术本身的成熟度，不考虑团队的学习曲线，就会高估可行性。我见过一个团队选了计算机视觉场景，因为学术界方案很成熟，但团队全是NLP背景，结果光搭环境就花了一个月。

我的应对方法：在技术可行性打分时，增加一个“团队熟悉度”子项。如果团队有相关经验，加0.5分；如果完全没有，减0.5分。这个调整幅度不大，但能提醒决策者考虑学习成本。

5.5 排序结果不沟通

排序表做完了，锁在项目负责人电脑里，业务方不知道自己的场景为什么排在后面，就会产生猜疑和不满。这种信息不对称会消耗大量沟通成本，甚至导致项目推进受阻。

我的应对方法：排序结果和打分依据对全部相关方公开。每个场景为什么得这个分，哪个维度拖了后腿，都写得清清楚楚。业务方看到自己的场景在“数据就绪度”上得分低，就知道下一步该去推动数据治理，而不是抱怨排序不公。公开透明是减少内耗的最好方式。

6. 从排序到执行：让七维方法真正落地的几个关键动作

6.1 建立场景池的日常维护机制

七维排序不是一次性动作，而是一个持续维护的过程。我建议指定一个角色（可以是产品经理或AI项目负责人）专门负责场景池的维护，每两周更新一次场景状态，每季度重新打分排序。这个工作量不大，但能保证排序表始终反映最新情况。

场景池的维护包括：新增业务方提出的场景、更新已有场景的数据就绪度、记录技术可行性的变化、标记已经完成的场景。维护得好，排序表就是一个活的决策工具；维护得不好，它就是一张过期的废纸。

6.2 用排序结果驱动资源分配

排序表最大的价值不是“知道先做哪个”，而是“知道资源该往哪投”。如果排序显示数据就绪度是大多数场景的瓶颈，那下一步就应该立项做数据治理，而不是急着招算法工程师。如果排序显示技术可行性普遍不是问题，那就可以把资源集中在业务价值高的场景上，快速推进。

我见过一些团队，排序表做得漂漂亮亮，但资源分配还是拍脑袋，结果排序表沦为摆设。要让排序表真正发挥作用，必须把它和预算、人力、时间分配挂钩。排序表说哪个场景优先，资源就往哪个场景倾斜，否则排序就失去了意义。

6.3 向管理层汇报排序结果的话术

向管理层汇报时，不要讲七个维度的细节，他们没耐心听。直接讲三件事：我们评估了多少个场景、排序前三名是什么、为什么第一名是它。然后用一页纸展示打分表，重点标出每个场景的短板维度。

管理层最关心的是“为什么做这个不做那个”，所以你的汇报要能回答这个问题。比如“我们选择文档问答作为第一个场景，因为它的数据就绪度最高、风险最低、一个月内能上线，而排产虽然业务价值最高，但数据质量差、技术复杂度高、失败影响大，我们计划在完成数据治理后再启动”。这种汇报方式既展示了专业性，又给出了清晰的决策逻辑。

6.4 排序方法的培训与推广

如果企业有多个AI团队或多个业务线，七维排序法可以推广成统一的方法论。推广时不要只发文档，要带着大家实际跑一遍。找一个真实的场景池，让各团队一起打分、一起讨论分歧、一起调整权重。这种工作坊形式比看文档有效十倍。

推广过程中会遇到阻力，主要是“我们的场景特殊，不适用这套方法”。我的应对是：允许每个团队在七个维度之外增加一个自定义维度，但权重不能超过10%。这样既尊重了特殊性，又保持了框架的统一性。

7. 我在这套方法上踩过的坑和最终沉淀的经验

最早我也是一个“模型优先”的信徒。2019年做第一个企业AI项目时，我花了三周时间对比各种模型架构，写了详细的选型报告，结果项目上线后发现最大的问题根本不是模型——是业务方根本不愿意用。他们觉得AI分类结果不可靠，宁愿自己手动处理。那个项目最终不了了之，模型选得再好也没用。

后来我强迫自己改变顺序：先跟业务方聊，把他们的痛点列出来，评估每个痛点的数据基础和技术可行性，排完序之后再去看模型。这个转变让我的项目成功率大幅提升。不是说模型不重要，而是说模型是最后一步，不是第一步。

七维排序法是我在十几个项目上迭代出来的。最早只有三个维度（价值、数据、技术），后来发现流程嵌入度不够会翻车，加了第四个。再后来发现有些场景做完就完了，没有积累，加了可扩展性。再后来发现风险失控会拖垮整个团队，加了风险可控性。最后把投入产出周期单独拆出来，因为业务方的耐心是有限资源。

这套方法不完美，但它能帮你在信息不完整的情况下做出相对理性的决策。企业AI落地本来就是一门在不确定性中找确定性的手艺，七维排序法就是我的手艺工具箱里最趁手的那把。你不需要照搬我的权重和打分标准，但你需要有一套自己的排序逻辑，并且坚持在选模型之前用它。这个顺序上的小小改变，可能就是你的AI项目从“又一个失败试点”变成“真正产生价值”的分水岭。