推荐语
ChatSQL从"替代人"到"赋能人"的实战转型，6个月实现业务价值转正。 核心内容： 1. AI+理念：用ChatSQL重构取数流程，而非作为外挂工具 2. 6步落地流程详解：从需求审核到效果验证的关键步骤 3. 需求标准化案例：业务语言到机器语言的翻译层建设
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
我曾断言"ChatSQL不会成功"，不少读者问：那你们还在做什么？
答案是：我们把目标从"替代人"调整为"赋能人"。
当我说"不会成功"时，指的是那个试图自主理解一切复杂业务、实现100%自动化的"AI神话"。但这不意味着ChatSQL没有价值——恰恰相反，当我们放下对完美的执念，转向务实的人机协同，ChatSQL开始真正产生业务价值。
我给团队定了一个目标：6个月内，ChatSQL实现收益由负转正——即我们为ChatSQL投入的人工成本和流程改造成本，小于它带来的效率提升收益。
6个月过去，我觉得离目标很近了，至少我是有信心的。
这篇文章，我把这套方法完整公开。如果说前几篇是"为什么"和"做什么"，这篇是"怎么做"——一份可直接复用的落地手册。
核心理念：AI+，而非+AI
在展开具体步骤之前，必须先校准一个认知：
不要把ChatSQL当成取数的"外挂"，它必须成为取数流程本身。
这就是我们说的AI+，而非+AI。
什么是+AI？在原有流程旁边加一个AI入口，用户想用就用，不想用就走老路。结果呢？没人用，因为改变习惯的成本太高。
什么是AI+？用AI重构流程本身，让AI成为流程的默认路径，人工变成兜底。这样，AI的价值才能被充分释放。
明确这一点后，我们开始。
第一步：需求审核——把好入口关
做什么
在需求提交环节，强制业务人员在线化、模板化填写需求。不允许用附件形式提交需求，实在不行，至少确保附件是标准化的。
需求管理员要严格履行审核职责：对不符合要求的需求，必须打回重填。
为什么这么做
ChatSQL最大的失败原因不是技术，而是输入质量。
我们统计过，在ChatSQL运行失败的案例中，约45%的根因是"需求描述不清晰"。业务人员习惯了跟人沟通——一句话说不清楚，电话里再补充。但大模型不会打电话，你给它什么，它就理解什么。
具体案例
下面是一个需求审核案例（仅做示意）：
优化前（打回）
原始需求："帮我取上月活跃用户数"
缺失信息：时间范围不明确、渠道未指定、活跃定义缺失、维度未说明、是否排除特殊用户
ChatSQL理解率：约5%（基本靠猜）
优化后（通过）
原始需求："取2024年11月，渠道=APP端，活跃定义=当月登录≥3次的用户，按地市维度汇总，排除内部测试账号"
缺失信息：无
ChatSQL理解率：约50%（有明确执行路径）
需求管理员的审核要点清单：
- 时间范围：是否明确到月/周/日？"上月"要转化为具体日期
- 业务口径：关键指标的计算逻辑是否清晰？
- 维度信息：按什么维度汇总？地市/渠道/产品？
- 过滤条件：是否需要排除特定数据？
- 输出格式：是否有特殊的格式要求？
转型启示
需求标准化的本质，是建设"业务语言"到"机器语言"的翻译层。这个翻译层过去存在于数据开发人员的脑子里，现在必须显性化、结构化。
执行难点与应对
难点：业务人员不配合，嫌麻烦。
应对：
- 短期：需求管理员兜底，自己把需求"脑补"完整。"你不入地狱，谁入地狱。"
- 中期：用ChatSQL的成功案例教育业务人员——你多花2分钟写清楚需求，能节省2天等待时间。
- 长期：将需求规范纳入制度，与绩效挂钩。
第二步：流程变更——让AI成为默认路径
做什么
重构取数流程：需求不再直接流转到开发人员，而是由ChatSQL Agent先行处理。
- 如果ChatSQL运行成功，开发人员审核后直接返回结果
- 如果ChatSQL运行失败，再进入人工处理流程
为什么这么做
我们最初的做法是：需求流转到开发人员，由开发人员决定是否使用ChatSQL。
结果发现两个问题：
- 评估失真：开发人员倾向于挑简单的需求用ChatSQL，复杂的直接自己写，导致我们无法客观评估ChatSQL的真实能力边界。
- 抵触情绪：开发人员觉得ChatSQL是额外负担——"我自己写SQL只要10分钟，用ChatSQL调试半天还不一定对，图什么？"
流程变更后，ChatSQL成为默认路径，开发人员的角色从"执行者"变成"审核者"和"兜底者"。
流程对比
变更前：
业务提需求 → 需求分配给开发人员 → 开发人员决定是否用ChatSQL → 返回结果
变更后：
业务提需求 → 需求审核 → ChatSQL自动处理 → 成功：开发人员审核 → 返回结果
（失败则进入人工流程）
业务价值
流程变更后，业务人员的感知发生了质变：
- 变更前：提交需求后平均等待2-3天
- 变更后：简单需求最快30分钟返回结果
这个体验差异，是ChatSQL获得业务认可的关键。
转型启示
流程变更的本质，是从"人为中心"到"AI为中心"的范式转换。人的角色从"执行"变成"监督"和"兜底"，这是AI时代工作方式的根本转变。
第三步：出错处理——提示词工程是核心战场
做什么
ChatSQL一次成功率较低（当前约15%），出错后不要急着人工接管，而是通过优化提示词让ChatSQL再试。
关键原则：开发人员现在是提示词工程师，不是SQL工程师。不要改代码，要改提示词。
为什么这么做
我们统计过ChatSQL的出错原因分布：
- 需求描述不清晰：45%——应对策略：补充需求描述
- 元数据不完善：25%——应对策略：补充字段含义、枚举值映射
- 大模型理解偏差：20%——应对策略：调整提示词表述方式
- 模型能力限制：10%——应对策略：人工兜底
90%的问题可以通过优化提示词解决，只有10%需要人工写代码。
具体案例：一次完整的提示词修复过程
（仅做示意）
原始需求："取11月各地市的宽带新增用户数"
第一次运行：失败
错误信息：无法确定"宽带新增"的业务口径，存在多个可能的计算方式
开发人员分析：
- "宽带新增"在公司有两种口径：一种是当月新装机，一种是当月净增（新装-拆机）
- 需求没有明确是哪种
提示词补充：
"取11月各地市的宽带新增用户数。口径说明：宽带新增指当月新装机用户，不含拆机后复装。数据源使用DW层的userbindbandmonthly表，新增标识字段为isnewbindband=1"
第二次运行：失败
错误信息：字段"city_name"在目标表中不存在
开发人员分析：
- 大模型选错了地市字段，表里的字段名是"areaname"而非"cityname"
- 元数据里没有标注这个字段代表地市
提示词再次补充：
"取11月各地市的宽带新增用户数。口径说明：宽带新增指当月新装机用户，不含拆机后复装。数据源使用DW层的userbindbandmonthly表，新增标识字段为isnewbindband=1。地市字段使用area_name"
第三次运行：成功
容错机制
除了人工修复提示词，我们还尝试建立自动容错机制：
- 错误反馈重试：把报错信息作为上下文，让大模型自动修正，最多重试3次
- 模型切换：如果默认模型失败，自动切换到备用模型重试
- 历史匹配：从历史成功案例中匹配相似需求，参考其提示词结构
通过这些机制，我们把一次成功率15%提升到了二次成功率（含人工修复）82%。
转型启示
提示词工程的本质，是将开发人员的隐性知识（业务理解、数据理解）显性化。每一次提示词优化，都是在为ChatSQL"喂养"高质量的领域知识。
执行难点与应对
难点：开发人员抵触，觉得"调提示词比写代码还慢"。
应对：
- 初期确实会慢，但这是学习曲线，必须坚持
- 强制要求：即使调试提示词的时间超过写代码，也必须优先用ChatSQL
- 建立提示词模板库，降低调试门槛
- 将提示词优化能力纳入技能考核
第四步：指标评估——用数据驱动改进
做什么
建立指标体系，持续监控ChatSQL的运行质量，用数据发现问题、驱动改进。
核心指标（某业务线）
- 端到端平均取数时长：用户提交需求到结果返回的总时长。当前值：2天，目标值：<8小时。监控目的：评估真实业务价值。
- 一次取数准确率：首次ChatSQL成功数/总需求数。当前值：15%，目标值：30%。监控目的：评估ChatSQL基础能力。
- 二次取数准确率：首次失败后修复成功数/首次失败数。当前值：82%，目标值：90%。监控目的：评估人工修复能力。
- 取数覆盖率：ChatSQL成功实现数/总需求数。当前值：30%，目标值：50%。监控目的：综合评估技术能力。
指标看板实践
我们每周会看这四个指标的趋势图。下面是一个真实的问题发现案例：
现象：第3周，取数覆盖率从32%掉到了21%。
排查过程：
- 先看一次准确率——从15%掉到12%，下降不算剧烈
- 再看二次准确率——从82%掉到58%，下降明显
- 分析二次失败的案例，发现集中在某个业务线
根因：该业务线新上线了一批数据表，但元数据没有同步到ChatSQL的知识库。开发人员补充提示词时，因为不熟悉新表结构，修复成功率大幅下降。
改进措施：建立元数据同步机制，新表上线必须同步更新ChatSQL知识库。
另一个案例：流程卡点发现
现象：取数覆盖率稳定在30%，但端到端平均时长始终在20小时以上，降不下来。
排查过程：
- ChatSQL处理时长——平均15分钟，不是瓶颈
- 人工审核时长——平均2小时，可接受
- 需求审核环节——平均8小时，明显过长
根因：需求管理员白天要处理其他工作，需求审核集中在下班前批量处理。业务人员上午提的需求，要到晚上才能进入ChatSQL处理。
改进措施：调整需求管理员的工作安排，增加一次午间审核，将需求审核时长压缩到4小时以内。
转型启示
指标体系的本质，是建立数字化转型的"反馈回路"。没有指标，就没有改进的方向；没有监控，就不知道改进是否有效。
第五步：知识沉淀——构建飞轮效应
做什么
每一次取数完成后，将改进成果沉淀到知识库：
- 优化后的需求描述模板
- 成功的提示词案例
- 发现的元数据问题及修复
- 业务口径的标准化定义
为什么这么做
ChatSQL的能力提升是一个"飞轮"：
高质量知识 → ChatSQL准确率提升 → 更多成功案例 → 更多知识沉淀 → 高质量知识
飞轮一旦转起来，ChatSQL会越来越强。但如果不做知识沉淀，每次都是从零开始，永远在原地打转。
知识沉淀的四个维度
- 需求模板：沉淀标准化的需求描述结构，存入需求模板库，由需求管理员负责
- 提示词：沉淀成功的提示词案例，存入提示词案例库，由开发人员负责
- 元数据：沉淀字段含义、枚举值、业务口径，存入数据字典，由知识库团队负责
- 业务规则：沉淀跨表关联逻辑、计算规则，存入业务规则库，由知识库团队负责
具体案例：从一次取数到知识沉淀
原始需求："取各渠道的用户留存率"
问题：ChatSQL不理解"留存率"的计算口径
修复过程：开发人员补充提示词，明确留存率=次月仍活跃用户数/当月新增用户数
知识沉淀：
- 在业务规则库新增"留存率"的标准定义
- 在提示词案例库保存本次成功的提示词结构
- 在需求模板库增加"留存率取数"的标准模板
后续效果：3周后有类似需求，ChatSQL一次成功，因为知识库里已经有了"留存率"的标准定义。
转型启示
知识沉淀的本质，是将个人能力转化为组织能力。过去，取数能力存在于开发人员的脑子里，人走了能力就没了。现在，能力沉淀在知识库里，成为组织的数字资产。
第六步：组织保障——这不是技术项目
做什么
ChatSQL不是一个技术项目，而是一次组织变革。必须有匹配的组织保障。
组织架构
- 总指挥（我本人）：把握方向、关键决策、协调资源
- 项目经理（开发组组长，非技术经理）：统筹人员、流程、资源协同
- 开发团队（3人）：流程优化、ChatSQL智能体构建、系统集成
- 模型团队（2人）：大模型集成、微调、测试
- 知识库团队（2人，从取数团队剥离）：数据字典优化、知识沉淀
踩坑经验
坑1：让技术经理当项目经理
最初我们让大模型的技术经理负责项目，结果推不动。因为ChatSQL涉及人员、流程、组织、资源等多方面协同，技术经理缺乏这方面的经验和权限。
后来换成开发组组长，他熟悉取数业务、了解团队成员、有流程话语权，推进顺利很多。
坑2：全面铺开
最初想一步到位，让所有取数需求都走ChatSQL。结果问题层出不穷，团队疲于奔命。
后来改为分步实施：先从一条业务线试点，验证可行后再逐步扩展。当前50%的取数已完成切换。
坑3：知识库团队缺位
最初没有专门的知识库团队，元数据优化靠开发人员兼职做。结果大家都忙于日常取数，没人有精力做知识沉淀。
后来专门从取数团队剥离2人，全职负责数据字典和知识库，飞轮才真正转起来。
转型启示
组织保障的本质，是让"正确的人做正确的事"。技术问题可以靠技术解决，但组织问题必须靠组织解决。
总结：这是一次微型的数字化转型
回顾这6步，你会发现：打造一个可用的ChatSQL的过程，其实就是一次数字化转型的过程。
- 第一步需求审核：业务流程标准化
- 第二步流程变更：工作范式转换
- 第三步出错处理：人机协同模式建立
- 第四步指标评估：数据驱动的管理闭环
- 第五步知识沉淀：组织能力资产化
- 第六步组织保障：配套的组织变革
远不是技术上死磕那么简单。
为了弥补大模型上下文理解能力的不足，我们需要围绕它做一次流程的重构，这必然涉及到组织、人员、系统、数据等的优化。
我们的ChatSQL还没有完全成功，但我相信方向是对的，只要在每个环节持续精益求精地打磨，成功是可期的。
最后我还是强调一点：
当前ChatSQL面向的仅仅是取数场景，取数的大多数关键环节还是掌握在IT手里，因此，以IT为主去推进还是有可能的。
但大多数的AI+场景不是这样，IT团队没有什么发言权，如果没有业务的强力推动，做大模型很容易陷入昙花一现、DEMO盆景或者PPT自嗨的困境。
你可以改变自己，但改变不了体系。体系的改变需要时间，而这不是某个人、某个团队、某个企业、甚至某个行业所能左右的。
因此，如果做不成功，不要老是怪自己，抬头看一下，再决定路要怎么走。
与大家共勉！
系列文章回顾：
公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！
粤ICP备14082021号
免费POC，
零成本试错
