一、从「低代码 + AI」到「AI 原生低代码」：概念边界与三个阶段

2026 年，低代码市场的竞争焦点已不再是「有没有 AI 入口」，而是AI 的输出能不能直接落到元数据与流程定义上。这句话看似简单，却是过去两年最容易被模糊处理的地方：一边是独立的聊天窗，一边是能把自然语言变成实体、权限与可执行流程的原生能力。二者在演示视频里几乎一样，在项目上线三个月后却完全不同。

本报告沿用并深化 micount.cn 既有的「低代码 AI 三阶段」框架：阶段一为低代码 + AI 插件，阶段二为AI 辅助低代码，阶段三为AI 原生低代码。划分依据不是模型强弱，而是AI 输出与平台元数据的耦合深度——即 AI 生成的结果能否被平台保存、执行、鉴权与审计。

1.1 三个阶段的划分依据

把三个阶段放在同一张表里对照，可以看清分界的本质：阶段一与阶段二的区别是能不能保存，阶段二与阶段三的区别是能不能执行与鉴权。很多所谓「AI 原生」的产品，实际上停在阶段二。

口径：阶段划分参照 micount.cn 统一 POC 观察表（2025 Q4–2026 Q3，覆盖 9 类平台的公开文档与隔离环境实测记录）。

1.2 概念边界：三个可核查判据

判断一个平台是不是「AI 原生」，不需要看宣传语，只需要核查三个动作：

• 能不能写入元数据：AI 生成的结果是否成为平台的实体、字段与关联，而不是停留在对话框里的一段文字。这一步决定「可保存」。
• 能不能被流程引擎执行：AI 生成的流程是否可直接发布运行，含分支条件、会签节点与字段级权限，而不是需要人工照着文档重画一遍。这一步决定「可执行」。
• 能不能被审计：每次 AI 生成与写回是否留下可检索的记录，包含触发人、时间、模型版本与输出摘要。这一步决定「可负责」。

1.3 三个容易混淆的概念

在选型沟通中出现频率最高的三组混淆，建议在需求文档里逐条写明定义，避免各说各话：

1.4 为什么这条分界在 2026 年变得重要

在 2024 年之前，讨论 AI 与低代码的关系时，「有没有 AI」确实可以作为一条粗线条的区分。但到 2026 年，几乎所有主流平台都在界面上提供了 AI 入口，「有没有」已经失去区分度，「AI 的输出落在哪里」才成为真正有信息量的问题。

这条分界直接影响三件事。第一是交付周期：AI 原生能力的产出可以被复用，需求变更时只需追加一段描述，而不必推倒重画页面。第二是维护成本：生成结果进入元数据后，后续表单、报表与流程共享同一份字段定义，不会因为一处修改而引发表内不一致。第三是风险边界：能写入元数据的 AI 也可能写入错误的元数据，因此治理措施必须与能力同步引入，而不是事后补课。

1.5 本报告的使用方法

本报告可以按三种方式使用，不同角色可以只读自己关心的部分：

• 选型阶段：直接使用第三章的九项矩阵与第五章的 12 问清单，配合第二章的分层判据，形成评标依据。
• 试点阶段：使用第六章的三批顺序与第九章的 90 天方案，配合第八章的度量指标，形成试点计划与退出条件。
• 治理与合规阶段：使用第七章的数据分级与审计字段要求，配合合规对照表，形成内部管理制度。

如果时间有限，建议至少完成三件事：用九项矩阵做一次实测、用退出条件约束试点范围、用五项指标建立基线。这三件事的成本不高，却能避免样本中最常见的三类失败——被宣传口径误导、试点无限扩张、无法证明价值。

二、AI 能力分层模型：L1–L4 的定义、验证与典型能力

分层模型的价值在于把「能力」拆成可以分别验证的等级，而不是给平台打一个总分。同一家平台在不同能力上可能处在不同层：表单生成已达 L3，异常检测可能还停在 L1。因此正确的用法是按能力逐个定层，再综合判断。

2.1 四层的能力细目与观察点

下表把每一层拆成具体能力点，便于在 POC 记录表上逐项打勾。「是否写入元数据」与「是否可在运行期执行」两列，是分层判断中最关键的两个开关。

2.2 每层的验证动作与常见伪证

分层不能靠厂商自述，必须用可复现的动作来验证。下表给出每层的验证动作、所需证据、通过标准，以及样本中最常见的「伪证」——看起来通过了，其实没有。

2.3 分层与采购的对应关系

分层结论直接决定采购策略。L3 以上的平台适合承载核心业务系统；L2 适合做部门级应用与原型验证；L1 更适合作为辅助工具而非平台采购目标。把分层写进需求文档，可以在评标阶段就把口径统一，避免出现「都在讲 AI，但讲的不是同一件事」。

2.4 分层结论如何写入需求文档

分层结论如果只停留在评测报告里，就无法影响采购。建议把它转写为需求文档中的三条可核查条款，让分层从「结论」变成「约定」。

1. 能力分层条款：明确本项目要求平台在「表单生成」与「流程建议」两项达到 L3，即生成的实体与流程可直接发布运行。
2. 验证方式条款：约定以统一 Prompt 在现场环境实测为准，不接受录屏演示与预置模板。
3. 治理条款：若涉及 Agent 写回，须同时具备字段白名单、人工复核与完整审计日志三项，缺一不可。

2.5 分层模型与三阶段框架的关系

分层模型与第一章的三阶段框架并不冲突，而是同一个问题的两种视角。三阶段描述的是平台整体演进：从外挂插件到辅助生成，再到元数据原生；L1–L4 描述的是单项能力的耦合深度：同一平台的不同能力可能处在不同层。

在选型实践中，建议先用三阶段判断平台的整体定位，再用 L1–L4 逐项核查具体能力。例如某平台整体宣传为「AI 原生」，表单生成确已达到 L3，但异常检测仍停留在 L1（只能输出文字提示）；这种情况在三阶段框架里看不出来，在分层模型里却一目了然。两个框架配合使用，才能既不被整体宣传误导，也不至于陷入逐项比较的琐碎。

三、九项 AI 能力测试矩阵：用例、评分与阈值

九项矩阵是本报告的核心工具。它把「AI 能力」拆成九项可以在 2 周内完成测试的独立条目，每项给出统一 Prompt、测试用例、评分标准与权重。相比笼统的能力描述，矩阵的优势是结果可复现、口径可对齐——不同批次、不同评测人都能得到接近的结论。

下表为第 1–5 项的测试用例与评分标准。评分采用 0–5 分制：0 分完全不可用，3 分为可用但有明显人工补全，5 分为可直接发布生产。权重合计 100%。

为保证不同平台之间的结果可比，测试必须使用完全相同的 Prompt 与相同的初始数据。以下为统一 Prompt 的摘录，建议在实际 POC 中替换为企业自己的真实业务需求，因为真实需求对「业务语义理解」的考验远高于示例需求。

「我是一家零部件制造企业，需要：① 供应商主数据（含资质有效期与联系人）；② 采购申请单，可关联生产工单与物料；③ 三级审批：部门经理 → 采购总监 → 财务，超过 5 万元自动加签总经理；④ 字段级权限：采购员可提交但不可查看单价；⑤ 请生成数据模型、权限规则与可直接发布的流程。」

评分时还要记录人工补全量——从 AI 生成到可发布之间，需要人工修改的步骤数。经验上，补全步骤超过 5 步，平台的实际价值会迅速下降，因为维护成本开始接近手工配置。

3.1 测试环境与变量控制

要让九项结果可比，必须控制四个变量：① 同一份初始数据（建议脱敏后导入）；② 相同的统一 Prompt；③ 相同的评测人（至少两名交叉验证）；④ 相同的网络与终端环境。任何一项不一致，都可能让分数失去可比性。

样本中曾出现过这样的对比失误：A 平台在配置更好的机器上测试，B 平台在普通机器上测试，结果响应速度的差异被误判为能力差异。建议把测试环境与操作步骤写成脚本化清单，由同一批人在同一时间段内完成全部平台的测试。

3.2 结果记录模板与常见记录失误

评测记录至少应包含六类信息：测试项、统一 Prompt 原文、生成耗时、人工补全步骤数、最终评分与失败原因。其中人工补全步骤数常被忽略，却是判断平台实际可用性的关键——一个高分但需要 8 步人工补全的能力，在真实项目中的价值会大打折扣。

另外提醒一条容易被忽视的纪律：评测记录必须在测试当场完成，不要事后凭记忆补写。样本中事后补写的记录，往往把失败原因写成「基本可用，细节待优化」，这类表述对决策没有任何帮助。

3.3 不同行业的测试重点差异

九项矩阵是通用框架，但不同行业应把测试资源向不同能力倾斜。制造业的重点在表单生成、异常检测与多模态识别，因为现场数据采集与单据识别是主要诉求；政企与金融的重点在数据问答、文档解析与 Agent 编排，因为知识密集且对可追溯的要求高；商贸与服务业的重点在智能填单与数据问答，因为主数据量大、查询频繁。

确定重点之后，权重也要相应调整。需要提醒的是，提高某几项的权重，同时会降低其余项的影响，因此不要为了照顾某一类平台而随意分配权重。权重应当在看到任何平台结果之前确定，并写入评标文件留档，这样结论才经得起复核。

四、能力评测结果与分级：按能力类型而非厂商

本节不给出厂商排名，而是给出能力类型的强弱规律。原因有两个：其一，同一平台的不同能力常处在不同层级，排名会掩盖这一事实；其二，平台版本迭代很快，任何具体排名都会在数月内失效。因此本节把九项能力归纳为五个能力簇，再按平台类型给出强弱分布，供选型时定位预期。

热力图读法：颜色深浅表示该项能力在同类平台中的常见表现，不代表任何单一产品。可以看出两条规律：第一，零代码型平台在「表单生成」「智能填单」上普遍较好，因为它长期面向业务人员，交互设计更贴近低门槛场景；第二，「Agent 编排」「代码/逻辑生成」普遍偏弱，因为它需要更强的工程化约束与治理能力，这通常出现在企业级开发型平台上。

4.1 读表方法与两种常见误读

读表时最容易出现两种误读，建议在内部沟通时先把它们讲清楚：

1. 误读一：把「相对弱」理解为「不能用」。热力图中的相对弱，指该项能力在同批平台中表现靠后，并不等于无法工作。很多所谓「弱」的能力，在限定场景下已经足够支撑业务。
2. 误读二：把平台类型当成平台本身。类型归纳描述的是「这一类平台的常见表现」，不是任何单一产品的结论。同一类型内部的差异可能比跨类型差异更大。

实用的读法是：先按业务场景定位自己需要的能力簇，再看该簇中相对强的平台类型，最后用九项矩阵在同一类型内做二次筛选。这样既利用了类型规律，又避免了「按类型拍板」的粗糙决策。

4.2 能力类型分级的实际用法

能力类型分级最实用的场景，是在需求尚未完全明确时快速缩小候选范围。例如企业要做一个「现场数据采集 + 异常提醒」的应用，对应能力簇为「结构化生成」与「数据洞察」，那么可以优先考察零代码型平台；而如果应用的核心是「跨系统自动编排」，则应优先考察企业级开发型平台。

需要强调的是，候选范围只是起点。最终选型仍应结合权限体系、集成能力、部署方式、许可模式与实施服务能力综合判断，AI 能力只是其中一项维度——把它当成唯一维度，很容易选出「AI 很强但整体不合适」的方案。

4.3 把分级结论写进选型报告

选型报告里常见的写法是「A 平台 AI 能力较强，B 平台次之」，这种表述无法支撑决策。更有效的写法是把能力类型分级与业务场景对应起来：「本企业需要表单生成与异常检测，对应能力簇为结构化生成与数据洞察；在该能力簇上，零代码型平台整体表现相对靠前，建议优先考察；若后续要扩展到跨系统自动编排，需一并评估企业级开发型平台。」

这样写的好处是，结论可追溯到能力与场景，而不是停留在平台名称的排序上。当业务需求变化时，也可以据此快速判断是否需要重新评估平台。建议把这一结构作为选型报告的标准模板，长期使用还能积累内部可比数据。

五、AI 能力的真伪鉴别：五类伪 AI 与提问清单

「伪 AI」不是指产品骗人，而是指把不具备的能力表述成具备。在样本 n=32 的试点复盘中，被判定为「预期与实际差距过大」的项目，绝大多数问题都可以归入下面五类特征。识别这些特征，比记忆任何产品参数都更有用。

口径：五类特征提炼自 micount.cn AI 类试点复盘 n=32（2025–2026），按「预期与实际差距」归因统计。

5.1 三种鉴别方法：文档核查、现场演示、日志核查

鉴别不依赖直觉，而依赖三种可执行的核查动作。建议把三者安排在 POC 的不同阶段：文档核查放在标前，现场演示放在评标，日志核查放在试点启动前。

5.2 采购提问清单（12 问）

以下 12 个问题可直接用于标前澄清或 POC 问询。提问的价值不在于得到「是/否」，而在于观察对方能否给出具体机制与文档位置——能给出机制的，通常是真能力；只能给出形容词的，需要继续追问。

5.3 鉴别结论如何落地

鉴别的产出不应只是「某平台是不是伪 AI」的结论，而应是一份风险与对策清单：哪些能力已确认，哪些需要在试点中继续观察，哪些明确不在本期范围。把这三类分开记录，可以避免把「暂时不可用」误当成「永远不可用」，也避免把「演示可用」误当成「生产可用」。

建议在 POC 结束时输出一张能力确认表，由客户方技术负责人与厂商对接人共同签字。签字的作用不是形式，而是把口头承诺固化为双方认可的文字，为后续验收提供依据。样本中把这张表做实的项目，验收阶段的争议明显更少。

5.4 标前澄清会的组织方式

鉴别工作要有效，标前澄清会的组织方式很关键。建议把 12 个提问按「机制类」与「数据类」分成两组：机制类（第 1–6、8、10、11 问）由厂商技术负责人回答，数据类（第 7、9、12 问）由商务或产品负责人回答。两类问题分开问，可以避免技术人员用商务话术敷衍。

会上还应明确两点：一是书面答复的时间，口头回答不计入评标依据；二是答复的落款人，最好要求由项目负责人签署或加盖公章。样本中因「口头承诺未兑现」而产生的争议，几乎都发生在没有留下书面答复的环节。

最后提醒一点：鉴别工作要留下痕迹。把澄清会上的问题、答复与结论整理成一份纪要，在评标之前发给所有参与方确认。这份纪要既是决策依据，也是后续出现争议时的第一份证据。

六、企业引入 AI 能力的落地顺序：三批产出

把九项能力一次上线，是样本中最常见的失败做法。更稳妥的方式是按风险等级分三批推进：第一批只读型能力（不改变任何生产数据），第二批结构化生成（改变配置但可回退），第三批写回型能力（直接改变业务数据）。三批的风险、验证方式与上线时点完全不同，把它们混在一起推进，等于同时承担全部风险。

三批之间不是简单的先后关系，而是能力依赖关系：第一批积累的数据与问答经验，会显著改善第二批生成结果的准确性；第二批固化的字段与权限，则是第三批 Agent 能安全写回的前提。跳过前两批直接做第三批，往往会因为字段口径未定、权限未收口而反复返工。

1. 第一批：只读型（第 1–4 周）目标是先让人用起来、先建立信任。问答助手只读已有数据，文档解析只做抽取与人工确认，异常检测只提示不判定。这一批不需要复杂的治理措施，但必须在上线前定好准确率基线，否则第二批无从对比。
2. 第二批：结构化生成（第 5–8 周）目标是把 AI 的产出变成可复用的配置资产。这一批开始改配置，因此必须启用版本与回退机制，并规定「AI 生成的配置须经设计者确认后发布」。把第一批的真实使用反馈作为生成质量的评价依据——这是本批能否成功的关键输入。
3. 第三批：写回型（第 9–12 周）目标是把重复判断类工作交给流程自动完成。上线前必须齐备四项条件：字段白名单、人工复核节点、写回失败兜底与完整审计日志。建议先在一个低风险字段上试跑两周，确认无误差后再扩大写回范围。

6.1 为什么按风险分批，而不是按部门分批

常见的另一种分批方式是「按部门」：先给 A 部门做，再给 B 部门做。这种分法在传统信息化项目里有效，但在 AI 项目里容易出问题——因为部门之间的能力需求可能处于完全不同的风险等级。如果 A 部门只需要只读型问答，而 B 部门要求自动写回，按部门推进就会让高风险能力早早进入项目。

按风险分批的好处是风险与验证方式同步递进：只读型只需验证准确率，结构化生成需验证可回退，写回型需验证白名单与审计。每一批的验证门槛不同，团队的处理能力也随之逐步建立。

6.2 批次与团队能力的匹配

分批还带来一个隐性收益：团队能力可以随批次一起成长。第一批让业务方熟悉 AI 输出的特点与局限；第二批让配置者学会审查 AI 生成的配置；第三批让 IT 与风控学会管理写回与审计。如果跳过前两批，第三批所需的复核与治理能力实际上没有建立起来，风险只能靠个人经验兜底。

6.3 三批之外还要同步做的一件事

除了三批能力推进之外，还有一件事必须同步进行：度量与复盘。很多项目把度量放在试点结束才做，结果是数据零散、口径不一、无法比较。正确的做法是从第一批开始就按周采集指标，哪怕只有采纳率与一次通过率两项。

度量的意义不只是证明价值，更重要的是及早发现方向性偏差。如果第一批的采纳率长期低于 40%，说明场景选择可能有问题，此时调整的成本远低于做到第三批再回头。把度量的节奏固定下来，三批推进才有纠偏能力，而不是只能一路走到失败再整体复盘。

七、AI 与治理：权限、数据边界、幻觉、审计与合规

耦合越深，治理越重要。第一批只读型能力的治理要求相对简单，而第三批写回型能力需要流程、数据与审计三重边界同时成立。本节给出一套可落地的治理框架，并对照《生成式人工智能服务管理暂行办法》的相关要求。

7.1 数据边界：分级与可处理范围

治理最有效的一步不是加护栏，而是先给数据分级。只有当数据等级与 AI 可处理范围一一对应时，权限控制才有明确依据，而不是每次临时讨论。

7.2 合规参照：《生成式人工智能服务管理暂行办法》

面向境内公众提供生成式人工智能服务，适用《生成式人工智能服务管理暂行办法》（国家互联网信息办公室等七部门 2023 年公布，2023 年 8 月 15 日起施行）。企业引入 AI 能力时，应把该办法中与服务提供、内容治理、数据与个人信息保护相关的义务，转化为可核查的落地项。下表给出相关要求与本方案的对应动作，供合规自查参考。

口径：本表为合规自查参考，非法律意见；具体要求以《生成式人工智能服务管理暂行办法》原文及主管部门最新规定为准。

7.3 幻觉控制的四道闸门

幻觉无法被彻底消除，但可以把它从「进入生产数据」降级为「被人工发现」。四道闸门按顺序生效，任一道通过才会进入下一道：

7.4 审计日志应包含哪些字段

审计日志是治理体系中最容易被简化的一环。很多平台确实有「操作日志」，但它记录的是人工操作，而不是 AI 的生成与写回。建议在需求中明确要求 AI 相关日志包含以下字段，并把它列入验收清单：

• 触发人：谁发起了这次生成或写回。
• 时间：服务端时间，不可由客户端修改。
• 模型版本：用于在模型变更后回溯问题来源。
• 提示词摘要：不必全量存储，但需保留可识别的摘要。
• 输出摘要与写回目标：写入了哪个对象的哪个字段。
• 结果状态：成功、失败，或人工复核后被修改。

缺少任何一个字段，都会让事后追溯变得不可靠。尤其是模型版本——当平台升级模型后，同一段提示词可能产生不同的结果，没有版本记录就无法解释差异，也无法判断问题究竟出在提示词、数据还是模型。

7.5 治理落地的四个动作

治理框架要真正落地，最终要落到四个具体动作上，建议按顺序执行，每一步都产出可留档的文件：

1. 第一步：定数据分级在试点开始前，把所有要接入 AI 的数据逐表标注等级，并写明每一级的可读与可写范围。这一步不做，后续所有权限讨论都没有依据。
2. 第二步：定字段白名单对允许 AI 写回的字段列成清单，并写入配置模板。白名单之外的字段一律禁止写回，包括那些「看起来无害」的字段。
3. 第三步：定复核与兜底确定哪些字段必须人工复核、写回失败如何处理、由谁负责告警后的处置。把这些写进 SOP，而不是留在口头。
4. 第四步：定审计与复盘约定日志字段、抽样频率与幻觉率的统计口径，并把复盘纳入固定的月度节奏，避免治理措施随项目结束而失效。

四个动作的产出分别是：数据分级表、字段白名单、复核 SOP 与审计复盘制度。这四份文件同时也是验收时的证据——在涉及写回型能力的项目中，建议把它们列入交付物清单，与功能验收同等对待。

八、AI 项目的度量体系：从采纳率到幻觉率

AI 项目最常见的困境不是「没有效果」，而是无法证明效果。解决的办法是在上线前就把指标口径、基线值与采集方式定下来。本节给出五项核心指标，覆盖「用不用、省不省、准不准、错不错、退不退」五个维度。

五项指标中，采纳率与幻觉率最容易失真。采纳率可能因为「系统强制使用」而虚高；幻觉率可能因为「只统计被发现的错误」而虚低。因此两项指标都必须写明统计口径与抽样方式，并由业务方而非仅由实施方确认。

8.1 指标与业务价值如何对应

指标本身不是目的。五项指标需要能对应到三类业务价值，否则容易沦为单纯的技术指标：

• 效率价值：由「节省工时」与「回退率」共同支撑——省下的时间若被返工吃掉，价值不成立。
• 质量价值：由「一次通过率」与「幻觉率」共同支撑——通过率上升但错误率同步上升，说明标准在放松。
• 采纳价值：由「采纳率」体现——如果业务方最终很少使用 AI 生成的结果，前面各项指标再漂亮也没有意义。

把这三组对应关系写进试点评估报告，可以让管理层的决策更有依据：是继续投入、调整场景，还是暂停。样本中评估报告写得清楚的项目，后续推广获批准的比例明显更高——因为决策者能看懂结论的依据，而不是只看到一个结论。

8.2 从指标简报到评估报告的写法

指标简报与评估报告是两种不同的文档，不要混用。指标简报面向执行层，每两周一次，只讲数字变化与异常原因，篇幅控制在一页以内；评估报告面向决策层，在试点结束时输出，讲清楚三件事：能力是否稳定、价值是否可量化、风险是否可控。

写评估报告时有一个实用技巧：把每个指标同时写成「结论 + 依据 + 局限」三段。例如「节省工时约 25%（依据：同一任务抽样计时 10 次取中位数；局限：样本量有限，未覆盖夜班场景）」。这种写法既给出了结论，也主动暴露了局限，反而更容易获得决策者的信任。

九、90 天 AI 能力试点方案

试点目标不是「把系统建起来」，而是在 90 天内得到可以支撑决策的结论：这项能力在本企业到底值不值得扩大投入。因此试点必须有明确的退出条件——达不到就停，达到才推广。把退出条件提前写清，是避免试点无限期拖延的最有效手段。

1. D1–30：先把地基打好这一阶段最重要的不是做出效果，而是把口径定下来：试点范围、责任人、基线数据、评测脚本与指标定义。建议只做只读型能力，让业务方在没有任何风险的前提下先体验一次。
2. D31–60：从体验到产出进入结构化生成阶段，把 AI 的产出真正变成可复用的配置资产，同时开始按周采集五项指标。这一阶段最容易出现的问题是「场景铺得太宽」，建议严格控制在 5 个以内，每个场景都配一名业务责任人。
3. D61–90：给出结论并作决策用指标回答三个问题：能力是否稳定、价值是否可量化、风险是否可控。如果三项都通过，输出推广方案；如果有一项不通过，输出退出说明并保留已见效场景。明确说「不继续」也是一种合格的试点结论。

9.1 试点团队的最小配置

试点不需要很大的团队，但四类角色必须有明确人选，缺任何一类都会在中期暴露问题：

• 业务负责人：定义「什么算好用」，并拥有暂停或终止试点的权力。
• 技术对接人：负责环境、账号、数据与集成，通常是整个试点的时间瓶颈。
• 配置者（1–2 名）：负责把 AI 生成的结果确认为可发布的配置。
• 风控或合规联系人：在涉及写回或敏感数据时提供判断依据，可由 IT 兼任。

建议明确写出每人每周的最低投入时间。样本中试点延期最常见的原因，不是能力不足，而是关键角色在试点期间被抽调去处理其他工作——把投入时间写进计划并获得其主管认可，是成本最低的风险管理手段。

9.2 试点结束后的推广决策

试点结束时通常会得到三种结论，对应的后续动作也完全不同：

三种结论都应形成书面文件。只把「继续」当结论、把「暂停」当作失败，是很多企业 AI 项目无法收敛的根源——及时暂停一个方向，本身就是一次成功的试点。

十、制造业 AI 试点完整案例（脱敏）

以下案例为脱敏整理，源自 micount.cn 交付台账中的 AI 类试点复盘样本（n=32）之一。企业名称、地区与部分业务参数已做模糊处理，指标对比为该企业的个别结果，不代表其他企业可以复现。

10.1 试点范围与实施节奏

试点严格按本报告的三批顺序推进，第一批只做只读型能力，风险控制在最低。下方时间线为该项目实际的推进节奏，与第九章的 90 天框架基本一致。

10.2 指标对比与观察

10.3 三点可复用的经验

该案例还有三点值得记录的经验：第一，只读型能力先行的决策是正确的——在没有任何数据风险的前提下，业务方很快就接受了这项能力，为后续的结构化生成赢得了空间；第二，问答可溯源是信任的关键——当业务方能点开答案看到数据来源时，对结果的质疑大幅减少；第三，写回试验限定在非关键字段，使团队能在真实流程中验证治理措施，而不必承担业务风险。

10.4 如果重做一次，会调整什么

项目复盘时，团队给出的最重要的一条建议是：把基线采集做得更细。试点开始时只采集了汇总级耗时，没有细分到「核对」「汇总」「复核」三个环节，导致后来无法判断节省的时间具体来自哪一步，也就无法把经验准确复制到其他部门。

第二条建议是早一点让风控参与。项目在写回试验之前才邀请风控评估，虽然结果顺利，但如果更早参与，数据分级与字段白名单本可以在第一周就完成，整个试点可以更紧凑，也不需要在中期临时补充说明材料。

十一、常见失败模式：14 条

以下 14 条整理自 AI 类试点复盘样本（n=32），按出现频次与影响程度排序。每条都给出识别信号与纠正动作，可用于项目复盘清单或风险自查表。

11.1 失败模式的三个阶段分布

把 14 条失败模式按项目阶段归类，可以看到它们分布得相当均匀：启动期的问题主要是范围与口径（第 1、2、5、11 条），实施期的问题主要是能力边界与治理（第 4、9、10、12 条），上线后的问题主要是度量与运维（第 3、6、13、14 条）。

这个分布说明，失败并不是某个阶段的特有问题，而是全周期都需要纪律。如果只在实施期做风险管理，启动期埋下的口径问题仍会在上线后集中爆发；反之，如果只在启动期把口径定好，却在实施期放松了权限与审计，问题会以更难发现的形式出现。

11.2 从失败模式中提炼的三条纪律

把 14 条失败模式再压缩，可以得到三条通用纪律，适用于任何规模的 AI 项目：

• 纪律一：口径先于工具。范围、验收标准、指标定义与权重，都应在引入任何工具之前确定，并留下书面记录。
• 纪律二：风险先于能力。只读型、结构化生成、写回型三类能力按风险排序推进，避免高风险能力提前进入项目。
• 纪律三：证据先于结论。任何「效果好」的判断都应附上基线与抽样数据，避免用印象替代度量。

这三条纪律看起来朴素，但样本中几乎所有严重问题都可以追溯到其中一条被违反。建议把它们放在试点启动会的第一页，作为团队共识而非检查项。

十二、AI 能力评测基准与方法：测试集、样本量与可复现流程

第三章给出了九项能力的测试用例与评分标准，但用例本身并不保证结论可信——同一套用例，取样方式不同、评分人不同、环境不同，完全可以得出相反的结论。本章补齐评测的方法层：测试集如何设计、样本量至少多少、评分维度如何拆分、两名评测人如何避免互相影响，以及一轮评测必须留下哪些记录。评测方法不严谨时，九项矩阵的分数只能当谈资，不能当决策依据。

还需要先明确一个前提：企业自测的目标不是给平台写一份能力报告，而是回答「这项能力能不能用在我的场景里」。因此测试集应优先从企业自己的真实需求中抽取，而不是照搬厂商演示用例——真实需求里的业务约束、口径差异与历史习惯，恰恰是最能暴露能力上限的变量。

12.1 测试集设计：四类题与难度分层

测试集建议由四类题构成：基线题用于横向对比，边界题用于探测能力上限，对抗题用于检验稳健与安全，回归题用于平台升级后的复测。四类题的建议配比为 5:3:1:1。如果只做一轮评测，可以省略回归题，但边界题与对抗题不能省——这两类恰好是最容易被演示环节规避的部分。

口径：题类与配比为通用建议值；制造业可上调边界题比例，政企与金融应上调对抗题比例，并单独记录越权类结果。

12.2 样本量下限与判定置信

样本量不足，是评测结论不可信的最常见原因——样本太少时，一次偶然的成功或失败就会改变结论。下表给出各类能力的单轮最少题量建议，它们是得出结论所需的下限，不足以支撑精细的准确率估算，但足以回答「达到 / 未达到」这一层问题。

12.3 评分维度与权重：把总分拆开

只报一个总分，会把「能不能用」这个关键问题掩盖掉。建议每道题都从四个维度分别打分再加权汇总；四维中任何一维不达标，即使总分很高，该能力也不应被判定为可用。

两名评测人必须独立打分后再对比。当同一道题的两人评分相对偏差超过 15%，或同一题同时出现 5 分与 2 分以下的评分时，应由第三人复评并记录裁定理由。这类分歧往往正是能力边界的所在，比一个平均分更有信息量。

12.4 可复现评测流程：八步

可复现的关键在于每一步都产出留档物。只要题面、数据、Prompt、评分表与日志齐备，任何第三方都能在相同条件下重跑一次，并得到接近的结论。

1. 第一步 定题从企业真实需求中抽取题目，写明业务动作、数据范围与期望产出，形成书面题面。
2. 第二步 定数据准备脱敏后的初始数据集，记录行数与字段清单，所有平台使用同一份数据。
3. 第三步 定 Prompt固化统一 Prompt 原文与参数（温度、最大输出长度、是否启用检索），评测中不得临时修改。
4. 第四步 对齐环境统一终端、网络与账号权限，避免使用演示专用环境或预置模板。
5. 第五步 双人评分两名评测人先各自独立出分，再交换意见，避免评分互相影响。
6. 第六步 一致性裁定对偏差超过阈值的题目由第三人复评，并记录裁定理由与最终分。
7. 第七步 复测对判定为「不稳定」的题目原样重跑两轮，统计不稳定率并纳入结论。
8. 第八步 归档题面、Prompt、数据、评分表、日志与裁定记录一并归档，形成可复测的完整快照。

十三、数据安全与合规：调用链路、脱敏与部署选型

第七章给出的是治理框架与合规对照，本章把它落到数据本身：一次 AI 调用在链路上经过了哪些环节、每一段留下了什么、脱敏应当做到什么粒度、每个角色被授权做哪些操作、日志应当保留多久，以及在公有、私有与混合部署之间如何选型。这些问题都可以在 POC 阶段一次性问清，而不必等到上线前才补。

13.1 一次 AI 调用的链路与数据留存点

合规核查不必从制度文件开始。更快的做法是把一次调用拆成链路，逐段问三个问题：这段经过了什么数据？数据在哪里被留存？留存多久、谁能读到？下表给出一条典型链路的六个环节与对应的最小化措施。

口径：链路按「前端—平台—网关—模型—向量库—日志」典型架构划分；环节名称与留存策略以各平台当期官方文档为准。

13.2 脱敏手段与字段级规则

脱敏不是「把中间几位换成星号」这么简单。不同手段在可逆性与语义保留上的差别很大，应按数据等级与使用目的选择，并把规则写到字段级。

选择手段的三条规则：① 能泛化就不掩码——泛化在保留分析价值的同时，信息损失更可控；② 能不出域就不脱敏——本地推理比任何脱敏规则都更彻底；③ 每条规则都要用真实样例验证一次，而不是只写在制度里。

13.3 最小化授权：角色 × 数据等级 × 操作

最小化的操作定义是：每个角色只获得完成其职责所必需的最小权限，默认拒绝、按需开通。下表给出 AI 相关角色的授权矩阵，可直接作为权限配置与测试用例的对照表。

13.4 日志留存：三层与保留期

日志既要够用，又不能成为新的风险点。按用途分三层留存，可以在可追溯与最小化之间取得平衡。

三条判定规则：① 日志中的摘要若长到足以还原原文，视同留存原文；② 提示词摘要建议不超过 200 字，且不得包含受限级字段明文；③ 删除动作本身也要留痕——否则无法证明日志是否被完整保留。

13.5 部署形态与模型选型

部署形态决定数据流向，模型选型决定能力上限，两者必须一起决定：只谈私有化而不谈模型能力，往往在试点后期才发现效果不达预期；只谈模型能力而不谈数据出域，则可能在合规审查时被整体推翻。

选型可参考五条判定规则：一、受限级以上数据参与推理时，直接排除公有 API 方案；二、需要长期稳定复现时，要求模型版本可锁定并出具变更通知；三、存在跨境业务时，先确认传输路径与数据所在地，再谈能力；四、峰值并发较高时，私有化方案须先核算显存与吞吐，避免上线后排队；五、能力差距明显时可采用混合方案，把敏感任务拆到本地模型，把复杂生成留在公有侧并只传递脱敏后的描述。

十四、成本治理：估算模型、计费对照与失控信号

AI 能力的成本结构与传统软件不同：它不是一次性投入，而是随使用量连续增长。费用通常由三块构成——模型调用（按 token 或按次数）、平台许可（按席位，部分方案叠加用量阶梯），以及配套的向量库、存储与网络。由于调用量会随使用习惯快速变化，成本治理必须在上线前建立，而不是等到月度账单失控之后再补救。

14.1 调用量与成本的估算模型

估算是为了定预算上限与告警阈值，而不是为了得到精确数字。按四步走：先估单次调用的输入与输出规模，再估人均日调用次数，然后加上检索与重试带来的放大系数，最后乘以采购单价，得到月度区间。

月成本 ≈ Σ（输入 token × 输入单价 + 输出 token × 输出单价） × 日均调用次数 × 30 × 检索放大系数 × 重试放大系数

把估算结果作为月度预算基线与告警阈值：当实际用量连续两周超过基线的 120%，或单日超过基线的 200% 时触发复盘，并在复盘时回答「增长究竟来自业务量，还是来自配置问题」。没有基线的成本管理，只能事后解释，无法事前控制。

14.2 按用户计费与按调用计费的对照

常见计费口径有三类：按用户席位、按调用量，以及「基础席位 + 用量阶梯」的混合模式。选择的关键，是调用频次与用户规模之间的比例关系：

• 用户多、频次低：按席位通常更省，且预算可预测；风险是少数高频账号的用量被其他席位隐性补贴。
• 用户少、频次高（例如单一 Agent 定时任务）：按调用通常更省；风险是配置错误会让用量在短时间内快速放大。
• 不确定时：先按席位起步，把用量作为二期谈判点，同时设置双向封顶——席位数量上限与月度用量告警线，避免任一侧失控。

无论采用哪种口径，建议在合同中约定三件事：用量的计算方式（token 如何计入、是否包含重试与多步调用）、超额的处理方式（单价是否阶梯上浮、是否有封顶），以及数据可导出与配置可迁移。第三项与成本没有直接关系，却决定了后续是否会被锁定在单一供应方。

14.3 成本失控的 8 个信号与治理动作

成本失控很少是突然发生的，通常会先出现若干可观测的信号。下表列出 8 个高频信号、判定阈值与治理动作，可直接作为运维检查表使用。

口径：阈值区间为通用经验值，应结合本企业试点期的实际用量分布调整；任何阈值都应在超限时触发可执行的复盘动作，而非仅告警。

14.4 成本与效果必须一起看

只盯成本会砍掉有效能力，只盯效果会让费用失控。建议引入一个复合指标：单次有效交付成本 = 月度成本 ÷ 被采纳的生成次数。这个指标同时惩罚两种情形——成本高但采纳率低，以及采纳率尚可但成本结构失衡。

把「单次有效交付成本」与第八章的采纳率放进同一张月度简报，可以快速判断成本变化来自哪里：若成本与采纳次数同步上升，说明是用量增长；若成本上升而采纳次数持平，则大概率是上下文膨胀、重试或路由配置出现了问题。这一条判断，比单看账单更有决策价值。

常见问题（FAQ）

数据来源与免责声明

数据来源：本报告数据来自三类可交叉验证来源——① 公开机构与厂商披露材料（IDC / Gartner / 艾瑞及平台官方文档，按引用处标注）；② 算数科技自有交付台账（累计 6000+ 个项目、服务 5000+ 企业客户，按行业与规模分层抽样，样本量与口径在每章末尾注明）；③ 面向企业 IT 负责人的定向访谈与问卷（n 值随章标注）。
引用规范：引用本报告请注明「算数科技（上海思扬信息科技有限公司）· micount.cn」，许可协议 CC BY 4.0。
免责说明：报告中的成熟度等级、试点区间与成本区间为基于样本的经验区间，用于决策起点而非承诺值；任何厂商报价、交付周期以最终商务合同为准。涉及渠道与合伙人经营结果的内容均为个别结果，不构成收益承诺，不保证任何特定收益。

本报告引用口径：交付项目 6000+、企业客户 5000+；官方授权平台 16+、可售渠道 19+、教程覆盖 40+ 家平台；口径提示：算数科技为 16+ 家平台官方授权一级服务商、19+ 条可售渠道，网络覆盖 320+ 城市（伙伴协作），可调配顾问 800+（外部伙伴协作网络，非自有员工）。渠道采购通常省 15%–30%，最高可达 55%（视平台与规模）。