这篇我按“先跑起来、再讲取舍”的方式写《我用数据分析经验做了次 AI 项目最先失效的是旧方法》。概念会讲但重点放在代码怎么组织、哪里容易踩坑。摘要三个月前我接了一个智能分析项目以为有Python和SQL基础就能搞定结果上线第一天就翻车了。不是因为模型不行也不是因为Prompt写坏了而是权限越界和日志缺失让运维直接把我堵在工位上。这篇文章复盘我作为数据分析转大模型开发的真实踩坑经历重点讲生产环境里那些比调参更重要的工程能力。---目录数据分析的新机会自然语言BI的真相指标解释Agent数据工具调用项目案例我的Agent是怎么翻车的总结---数据分析的新机会我转型的动机很直接。做了五年报表每天重复同样的工作接需求、写SQL、出图表、改格式。业务方一句话这个数据有点问题我就要翻半天日志。大模型出现后我发现智能分析是个真需求。业务方不再满足于给我一张表他们想要的是告诉我为什么环比掉了。这个转变背后是产品形态的变化从报表到对话从静态到动态。但我一开始理解错了方向。我以为就是写个Prompt让模型回答问题然后用流式输出展示结果。Demo做得挺顺业务方也满意直到准备上线。---自然语言BI的真相很多人做自然语言BI第一步是查词库、第二步是写转换规则、第三步是调模型。这条路能跑通但生产环境里有个致命问题模型会幻觉。我的第一个项目里业务方问上个月华东区的利润为什么下降模型直接编了一个因为原材料涨价的回答。实际上那是模型训练数据里的信息和我们的业务毫无关系。解决方案不是换更强的模型而是加一层事实校验。我的做法是把关键判断拆成可验证的查询让模型先返回查询语句再执行再返回结果。这样即使模型推理错了SQL本身能暴露问题。async def verify_query(user_input: str) - dict: 验证模型生成的查询是否合理 # 1. 先让模型返回SQL而非直接回答 sql_response await llm.generate( messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ], response_format{type: json_object} ) # 2. 解析并校验SQL sql parse_sql(sql_response) validated await sql_validator.validate(sql) # 3. 执行并返回结果而非模型生成的文本 if validated.is_safe: result await execute_sql(sql) return {status: success, data: result} else: return {status: error, reason: validated.reason}这段代码看着简单但里面有个坑response_format在某些模型上支持不好会返回格式错误的JSON。我的处理方式是加一个重试机制最多重试三次超过就返回原始文本让业务方自己判断。---指标解释Agent指标解释是数据分析里最容易被低估的环节。业务方问为什么的时候他们真正想要的是一个因果链条而不是一个数字。我做过一个指标解释Agent核心思路是把问题拆解成三层数据层发生了什么、业务层可能的原因、建议层可以做什么。第一层靠SQL和统计这个最稳。第二层靠模型推理但必须带上业务上下文。第三层建议要谨慎最好只给参考选项而不是直接决策。踩过的坑是模型太自信了。它会用训练数据里的通用知识来回答特定业务问题导致给出的建议在实际业务里完全不可行。我的修复方式是给模型一个明确的边界你只能基于提供的上下文回答不知道就说不知道。---数据工具调用工具调用是Agent的核心能力但也是最容易翻车的地方。我见过的翻车案例主要有三种1. 模型调用了不存在的工具导致系统报错2. 工具参数被模型错误解析返回意外结果3. 工具权限过大模型在不知道的情况下执行了危险操作第三种是我亲身踩过的。我的Agent有一次在调试模式下调用了删除数据的工具虽然最后没有真正执行但运维日志里已经记录了这个行为。解决方案是权限分级。把工具分成只读和读写两类只读工具可以放开读写工具必须经过人工确认或者二次校验。class ToolPermission: 工具权限控制 READ_ONLY [query_data, get_summary, list_tables] WRITE_REQUIRED [update_metric, delete_record, export_data] classmethod def check_permission(cls, tool_name: str, user_role: str) - bool: if tool_name in cls.READ_ONLY: return True if tool_name in cls.WRITE_REQUIRED and user_role in [admin, analyst]: return True return False classmethod def audit_tool_call(cls, tool_name: str, user_id: str, result: dict): 记录工具调用日志 log_entry { timestamp: datetime.utcnow().isoformat(), tool: tool_name, user: user_id, result: result } # 写入日志系统 logger.info(json.dumps(log_entry, ensure_asciiFalse))这个权限框架看着简单但上线后才发现一个问题用户角色不是静态的。不同业务线有不同的权限体系需要和现有的RBAC系统对接。这一步花了我将近两周时间。---项目案例我的Agent是怎么翻车的让我讲一个具体的翻车故事。项目背景给销售团队做一个智能分析助手支持自然语言查询销售数据。Demo阶段一切顺利。我用了LangChain接了业务数据库Prompt写得也不错业务方测试后很满意。上线第一天运维给我发了三条告警。第一条是权限越界。我的Agent在回答给我看所有客户的联系方式时直接返回了包含手机号和邮箱的完整数据。这个问题出在Prompt里我没有明确限制数据返回的字段范围。第二条是日志缺失。业务方反馈昨天的查询结果不对但我查了日志发现Agent返回的结果根本没有记录到业务数据库只存在于内存里。这意味着结果不可追溯。第三条是响应超时。有一次业务方问了一个复杂问题Agent调用了五个工具总共花了47秒才返回结果。业务方以为系统卡死了直接关了页面。这三个问题每一个单独拿出来都不难解决但组合在一起就是生产环境的典型灾难。我的修复方案1. 加一个字段白名单所有查询必须经过白名单校验2. 把结果写入数据库每次查询都有记录3. 给工具调用加超时限制单个工具最多10秒总耗时超过30秒就返回部分结果---总结从数据分析转大模型我的体感是能跑通Demo的人很多能把Agent稳定上线的人很少。中间的差距不在算法而在工程。具体来说有三个建议第一权限设计要先于功能开发。不要等做完了再想权限问题那时候改成本很高。在写第一行代码之前就把工具的权限分级和校验逻辑想清楚。第二日志要覆盖完整链路。从用户提问到最终回答每一步都要有记录。特别是模型调用的参数和返回结果这些信息在排查问题时比什么都重要。第三交付文档比代码更重要。我的经验是一个Agent能不能长期维护取决于接手的人能不能看懂它。文档要包括系统架构、工具清单、权限说明、常见问题排查指南。数据分析的经验没有浪费。SQL能力、业务理解、数据敏感度这些在大模型项目里同样值钱。只是多了一层工程化的要求而这恰恰是很多技术人容易忽视的地方。我花了两个月才搞明白这件事。希望这篇文章能帮你省点时间。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。