AI编程内部开发的成功案例可以带来哪些启示？你预备好掌握这些实用技巧了吗？

内部 AI 开发这件事，我见过太多团队把它做成了一场漂亮的演示，然后就没有然后了。演示那天老板点头，三个月后没人再打开那个入口，服务器还在跑，账单还在出。真正把 AI 编程、内部智能助手、自然语言查询这些东西用出价值的团队，掰开看我总结就三个共同点：切口小到不像一个战略项目、有人在为数据质量背书、验收标准写的是业务动作而不是模型指标。模型选谁其实是这当中最不重要的一环，现在主流模型之间的差距，在内部业务场景里往往被数据脏乱差的问题淹没掉了。我做过一个粗略的观察，内部 AI 项目从立项到真正被日常使用，花在数据清洗、口径对齐、字段补全上的时间，通常是花在写提示词和调接口上的三到五倍。这个比例听着吓人，但它就是现实。所以我看一个团队有没有机会做成，会先问一句：你们的数据资产清单能拿出来吗，主数据口径统一了吗，有没有一份能直接喂给模型的干净样本集。这三个问题答不上来，模型再强也白搭。普元这几年环节上做的事情，恰好踩在这些问题的正中间——数据资产平台管家底，高质量数据集平台管样本，AI 问数管最后一公里的问答入口。我不敢说买了就能成，但至少在数据这一侧，少走很多弯路。

今年跟我聊 AI 编程的客户，明显比去年务实了。前两年问的是“我们能不能做一个 Copilot”，现在问的是“我们内部那套 AI 助手为什么没人用”。这个转变挺好，说明大家开始从买工具转向看效果。内部 AI 开发真正的分水岭，不在代码生成得多快，而在喂进去的东西干不干净。我见过一个制造业客户，用 AI 编程工具两周就搭出了一个设备维修问答的界面，demo 效果惊艳，结果上线后一问到具体型号的故障码就开始胡说。查下来不是模型的问题，是他们把三个系统的设备台账混在一起，同一个部件在 ERP 和 MES 里编号都不一样。这类事故我一年能碰上七八回，几乎是标配。

所以我把内部 AI 场景按数据依赖程度分了四档，档位越高，越考验底层的治理功夫。下面这张表是我自己在项目复盘时常用的分类，不是什么标准答案，但拿着它跟业务方对话，能很快判断这个需求是不是现在就该做。

我把这两年在内部 AI 开发上见到的情况，浓缩成了一张对照表。左边那种项目，我聊十五分钟就知道能成；右边那种，我基本会劝对方先别立项。不是说右边一定做不成，而是它把顺序搞反了——先买模型，再找场景，最后补数据，每一步都在返工。有个客户跟我说过一句话我印象很深：他们的 AI 项目不是在解决业务问题，是在给采购回来的模型找一个家。这话挺狠，但很真实。

这两栏差别背后，其实是一个很朴素的东西：内部 AI 开发是个数据工程活，不是个软件采购活。右边那栏的项目，往往在第六周开始出现“模型瞎答”的问题，然后团队开始怀疑模型能力，换模型、加提示词、堆 RAG，折腾两个月，根因还在数据里躺着。我一般会让他们先停一停，把失败问题捞出来做归类，十有八九能归到三类：口径不一致、字段缺失、权限导致看不到完整上下文。这三类问题，靠换模型解决不了。

POC 阶段顺风顺水、转生产就翻车，是我见的最多的一种死法。原因说穿了不复杂：POC 是几个人围着一份手工整理过的数据在跑，生产是几百个人拿真实数据在问。POC 验证的是模型，生产考验的是数据供给的稳定性和一致性。有个能源行业的客户，POC 时准确率能到八成五，我当时就问了一句：样本是不是从一张表里挑的？对方说是。我基本就判断这个数字上不了线。后来上线第一周，跨表查询的准确率掉到五成以下，问题全部指向主数据不统一——设备、项目、合同三个域各有一套编码。

这类问题在 AI 编程阶段几乎暴露不出来。因为写代码的人拿到的是一份看起来整洁的接口文档，他不会去追这个字段在源系统里到底长什么样。等到业务方用自然语言来问，模型要去拼表、要对字段，脏数据立刻显形。我的建议是把数据体检前置到立项环节，而不是等 POC 结束再补。具体做法很土但有效：找业务方列二十个最常问的问题，让数据团队先手工答一遍，答不上来的地方就是风险点。这活儿花不了两周，但能省下后面两个月。

第一个误区是把 AI 编程理解成“装个插件”。工具本身确实能提效，但内部开发的难点从来不在写那几行代码，而在代码要连的那些系统、要读的那些表。如果后端的元数据是乱的，插件再聪明也只能帮你更快地写出一段错的逻辑。第二个误区是以为数据治理是 AI 项目的前置门槛，必须先做完治理才能搞 AI。这个顺序我也不认同，实际上两者可以并行，用 AI 场景倒逼治理，比空对空做三年治理规划更有效。

第三个误区比较隐蔽：把 AI 问数当成 BI 的替代品。这两件事解决的是不同问题。BI 解决的是“我知道要看什么，给我一张固定的图”；问数解决的是“我不确定该看哪个指标，先用话问一句”。把问数硬塞进报表体系里，最后两边都不好用。我的做法是让 BI 继续管固化的经营看板，问数单独开一个入口，专治临时性、探索性的问题，两个入口并存，反而互相带量。普元的 BI 和普元 AI 问数在这一点上是分开设计的，我倒觉得这个思路是对的，各管各的场景，别互相迁就。

拿到一个内部 AI 需求，我通常按四步过一遍：数据有没有、口径通不通、样本够不够、场景频不频。前三个不过关，第四个再好我也会压一压。这个顺序跟很多团队的直觉相反，他们习惯先看场景有没有意思、能不能讲故事，然后再回头找数据。我踩过这个坑——有个合同审核的 AI 需求，场景漂亮，业务方也积极，结果数据团队一查，合同文本散在四个系统里，附件还大量是扫描件，光做 OCR 和归档就干掉了大半年。项目没死，但节奏完全被打乱。

这张表我一般会在方案评审会上直接投出来，让业务方看清楚：你想要的“能问能答”，背后是五个环节在支撑，缺一环就掉一档体验。很多争论到这里就自然收敛了，因为大家发现不是模型不行，是有两环没搭起来。我不主张一次性全上，先补哪一环，看你的场景落在哪一档——问数类先补主数据和资产编目，微调类先补数据集平台，这个顺序比什么都上要省钱得多。

数据基础薄的企业，我的建议是别碰微调，直接从问数入手，把入口做小，只覆盖三五个高频指标。普元 AI 问数这类产品的价值在于它把指标语义和底层表结构做了映射，业务方不需要懂 SQL。但它不是万能钥匙，指标口径没定清楚，问出来的数一样是错的。基础中等的企业，可以在问数之外并行做一两个数据集项目，用真实场景养一支懂标注、懂清洗的队伍。底子厚的企业，才适合把数据开发、资产、主数据、问数当成一套体系来规划，这时候普元的整套数据治理产品线能省掉大量集成工作，元数据和权限是打通的，不用自己拼。

坑我说三个。一是别在立项书上写“提升效率 30%”这种没法验证的目标，改成“日均活跃提问人数”这类可数的指标。二是别让供应商直接对接业务方，中间必须有一个懂数据的自己人。三是别指望一次上线就准，内部 AI 的准确率是靠每周回补失败样本喂上去的，我经手的一个项目，前三个月准确率从六成爬到八成半，全靠每周一次的样本复盘会。这件事没有捷径，谁跟你说有，你都得留个心眼。

有个做装备制造的客户让我印象挺深。他们第一步只做了设备维修知识问答，用的是普元的数据资产平台先理清设备台账和技术文档，三个月后接入问数做备件库存查询。上线半年，一线维修工的日均提问量稳定在四百次左右，最关键的变化不是效率数字，而是老师傅的经验开始被记录下来了。这才是我理解的成功案例——它留下的是数据资产，不是一份演示 PPT。

我的答案很明确：先找场景，但找的是“能被数据支撑的场景”，不是“听起来最酷的场景”。这两者的区别，我在项目里见过太多次了。有个团队一开始想做智能合同审查，故事讲得很完整，结果一盘点数据，合同文本分散在四个业务系统，相当一部分还是扫描件，光做归档和结构化就得耗掉大半年，项目还没真正开始就已经透支了团队的耐心。后来他们换了个切口，先做采购订单的异常问询，数据就在一个主库里，字段也干净，六周就上线了，业务方用得还挺顺。

平台这件事，我同样不建议等场景跑通再补。原因很实际：没有平台托底的场景，做第二个的时候会全部重来一遍。我通常的做法是场景和数据底座并行推进，用第一个场景去验证底座够不够用，用底座去承接第二个、第三个场景。普元的数据资产平台和 Primeton Data Workshop 适合放位置上，前者管住“有什么数据、口径是什么”，后者管住“数据怎么稳定地流到 AI 场景里”。这两个东西早上，后面的场景复用成本会低很多。至于普元 AI 问数，我一般建议放在第二个或第三个场景再上，因为它对指标口径的要求比较高，等主数据和资产编目有点样子了，效果会好得多。

还有一点我得提醒：先找场景不等于让业务部门随便提。我见过最离谱的一次，一个部门提了十一个 AI 需求，最后能落地的只有两个。筛选标准我一般看三条：频次高不高、数据在不在手边、答错了后果严重不严重。三条都过的，优先做；只过一条的，先放一放。这个筛子比任何评估模型都管用，而且业务方自己也认。

能上，但得把预期调对。我见过不少企业一上来就想让业务人员随便问、什么都能答，这个期望基本实现不了。数据底子差的典型表现是：同一个指标在不同系统里算法不一样，主数据编码不统一，历史数据缺字段。这三个问题不解决，问数出来的结果就时对时错，而时对时错比全错更麻烦，因为业务方会失去信任，用两周就不用了。

我的建议是划一个小范围先跑起来。挑五到八个指标，把口径先定死，写进文档，让问数只圈里回答，圈外的问题明确告诉用户“暂不支持”。这种“诚实地说不知道”的设计，反而能建立信任。有个客户按这个思路做，第一期只覆盖了七个指标，上线后用户满意度比我预想的高，因为大家发现它至少不瞎编。等这批指标跑稳了，再一个个往外扩，每扩一个都先把口径对齐，节奏是慢一点，但没有返工。

这个过程中，主数据管理是绕不开的一步。Primeton MDM 主数据管理平台这类工具的价值在于把编码统一这件事从“人肉对齐”变成“规则驱动”，尤其是客户、物料、供应商这几个域，统一之后问数的跨表准确率会有肉眼可见的提升。我不建议等主数据全做完再上问数，两个并行，用问数暴露出来的问题反过来推动主数据治理，这个循环比单向推进快得多。普元 AI 问数在指标语义层做了不少映射工作，但前提是你得先告诉它口径是什么，这一步没人能替你做。

还有个现实问题：谁来做口径对齐。我的经验是必须有一个懂业务又懂数据的人坐镇，纯 IT 推不动，纯业务也推不动。这个人不需要职级多高，但得有权限召集几个部门坐下来把定义敲定。找不到这个人，问数项目大概率会停在第一个人口不一致的指标上。

我判断成功不看演示，看三个数：日均活跃提问人数、问题一次解决率、失败样本的周回补量。第一个数反映有没有人真在用，第二个数反映答得准不准，第三个数反映团队有没有在持续迭代。三个数里我最看重第三个，因为它最难造假。一个没人维护的内部 AI 工具，失败样本永远是零，因为根本没人去捞。

还有个更软一点的判断标准：业务方会不会主动提新需求。我经手的一个项目，上线四个月后，财务部门自己跑来找数据团队，说想把预算分析的几个问题也接进来。这个信号比任何报表都强，说明工具已经进了他们的日常工作流，而不是一个挂在门户上的入口。反过来，如果上线半年没有一个新需求进来，我基本会判断这个项目已经进入自然衰亡期，哪怕日活数字看着还行。

至于准确率这个指标，我的态度比较宽松。内部场景不需要百分之百，八成就够用，前提是错的时候能被识别出来。所以我一般要求在产品里加上来源追溯，让用户能点开看这个答案是从哪张表、哪个口径来的。有这个功能在，八成准确率的工具能被信任；没有它，九成五也会被质疑。普元 AI 问数这块做了来源展示，我觉得这个设计比单纯刷准确率更有价值，因为它在教用户怎么判断，而不是让用户盲信。

再补一句，评估这件事最好在立项时就定好，别等上线了再倒推。我见过太多项目，上线后各方对“成功”的定义完全不一样，业务方看体验，IT 看稳定性，老板看有没有降本，最后谁也说服不了谁，项目就在这种模糊里慢慢凉掉了。

回到最开始那个问题：那些跑通的内部 AI 开发案例，到底能给我们什么启示。我自己的答案是，它们几乎都在做同一件反直觉的事——把技术含量往下压，把数据功夫往上加。听起来不性感，但这就是我看到的规律。AI 编程工具让写代码这件事变便宜了，于是瓶颈自然转移到了数据供给这一侧。谁能更早意识到这个转移，谁就能少走一年弯路。

如果你现在正准备启动一个内部 AI 项目，我会建议你先做三件小事。第一件，找业务方要二十个他们最常问的问题，让数据团队手工答一遍，答不上来的地方就是你的真实工作量。第二件，把这二十个问题涉及的表和指标列出来，看看口径是不是统一的，不统一的有几个。第三件，找一个愿意为数据质量负责的人，如果找不到，这个项目就先别立。这三件事做完，你对项目能不能成的判断，会比任何方案书都准。

工具层面怎么选，我反倒觉得不必纠结。需要理清家底就上数据资产平台，需要统一编码就上主数据，需要给模型喂样本就上高质量数据集平台，需要让业务方直接用就问数，需要稳定管道就是数据开发平台。普元这套东西的好处是它们之间元数据和权限是通的，你从一个场景扩到三个场景的时候，不用重新搭一遍底座，这个复利在后面才显出来。我不会说它适合所有企业，但对那些数据已经有了一定积累、想系统性推进的团队，它确实能省掉很多自己拼装的时间。

最后留一个思考方向给你：衡量内部 AI 项目，别只看它省了多少人力，看看它有没有把过去只存在某个人脑子里的经验，变成组织可以复用的数据资产。前者是短期的账，后者才是三年后你还在用它的理由。这事我踩过坑，也见过别人踩，说到底没有捷径，只有顺序对不对。顺序对了，剩下的就是耐心。

陈立群：我们去年就吃过这个亏，模型换了三版，最后发现是主数据没统一。现在回过头看，那两个月要是拿去理设备编码，效果完全不一样。

周敏华：问数只覆盖七八个指标这个做法我认同，我们第一期铺了四十多个，结果业务方一用就发现好几个数对不上，信任度直接掉下来，现在只能重新收敛。

许志远：想问一下失败样本的复盘会一般谁来主持？我们这边数据团队和业务团队互相推，会开两次就散了。

林秀娟：来源追溯那段说到点上了。我们自己内部试用的时候，同事第一反应就是问这个数从哪来的，能点开看才敢往上报。

高建华：补一句，别忽略权限。我们有些问题答不准，不是因为数据脏，是因为提问的人看不到完整上下文，这个坑挺隐蔽的。