1. 项目概述当AI遇上复杂业务需求最近在得物技术团队内部我们完成了一个代号为“BP Claw”的项目核心目标是解决一个困扰我们很久的痛点如何让AI更精准地理解并生成复杂的业务需求规格说明。听起来有点抽象简单说就是让AI从一个模糊的业务想法自动生成一份结构清晰、技术细节完备的Flink实时计算任务需求文档我们内部称之为FlinkSpec。这源于一个非常现实的挑战。在数据平台和实时计算领域业务方比如产品、运营和数据开发工程师之间常常存在一道“理解鸿沟”。业务方描述需求时会说“我想看用户下单后5分钟内的行为路径”这背后其实隐含了数据源、时间窗口、关联逻辑、输出格式等一系列复杂的技术约束。过去数据开发需要反复沟通、澄清手动将这些业务语言“翻译”成技术语言形成FlinkSpec这个过程耗时耗力且容易产生歧义。“BP Claw”这个名字很有意思BP可以理解为Business Process业务流程或Business Proposal业务提案Claw则是“爪子”寓意着这个工具能像爪子一样精准地从纷繁的业务描述中“抓取”出关键的技术要素和逻辑关系。我们的实践表明通过引入AI进行需求智能化解析与辅助生成沟通效率提升了数倍需求文档的规范性和准确性也得到了显著增强。如果你也在为业务需求到技术实现的转化效率而头疼或者对AI如何落地到具体的研发提效场景感兴趣那么接下来的内容或许能给你一些启发。2. 核心难题拆解为什么AI写不好FlinkSpec在启动BP Claw项目之前我们首先深入分析了AI在生成FlinkSpec这类特定技术文档时面临的几大核心难题。理解这些难题是设计有效解决方案的前提。2.1 业务语言的模糊性与技术语言的精确性冲突业务人员描述需求时语言通常是目标导向、场景化的并且充满省略和默认共识。例如“统计热门商品”这句话至少隐含了以下几个需要技术明确的问题“热门”的定义是什么是按过去1小时的点击量、下单量还是销售额阈值是多少“商品”的范围是什么是所有SKU还是特定类目是否排除已下架商品统计的粒度是什么是按商品ID还是按SPU输出结果需要包含哪些字段实时性要求如何是每5分钟更新一次榜单还是基于滑动窗口实时计算AI模型如果缺乏足够的领域知识很容易生成笼统的、缺乏可操作性的描述无法直接用于开发。它需要被“教会”如何识别这些模糊点并按照预设的规则框架进行提问或填充。2.2 FlinkSpec本身的结构化与逻辑复杂性一份合格的FlinkSpec远不止是几句功能描述。它是一份高度结构化的文档通常包含以下模块需求概述业务背景与价值。输入数据源精确到Topic名、字段Schema、数据格式JSON/Avro、QPS估算。处理逻辑核心业务逻辑的伪代码或流程图包括过滤、映射、聚合、关联Join等操作特别是时间窗口Tumbling/Sliding/Session和状态State的使用。输出结果输出到的存储如Kafka Topic、HBase表、ClickHouse表及其Schema。性能与容错要求延迟要求P99延迟、吞吐量、Checkpoint配置、并行度建议。监控与告警关键指标如吞吐量、背压、消费延迟的监控方案。让AI一次性生成如此复杂且互相关联的内容是极其困难的。它必须理解数据流的因果关系如某个字段必须先被解析才能用于后续过滤以及技术组件之间的约束如选择HBase作为输出可能影响实时查询的性能设计。2.3 领域知识的深度依赖Flink生态有大量特定的概念、配置参数和最佳实践。例如时间语义Event Time、Processing Time、Ingestion Time的区别与应用场景。状态后端MemoryStateBackend、FsStateBackend、RocksDBStateBackend的选择考量。精确一次语义如何通过Source端、Flink内部、Sink端三方配合实现Exactly-Once。资源估算如何根据数据量和处理复杂度估算TaskManager的CPU、内存配置。这些知识对于通用大语言模型LLM来说是陌生的。如果不在AI应用中注入这些领域知识生成的Spec可能会犯低级技术错误比如在超大状态场景下推荐使用MemoryStateBackend导致生产环境OOM。3. BP Claw 的系统性设计思路基于以上难题我们没有选择让AI“自由发挥”生成全文而是设计了一套“结构化引导知识增强”的协同框架。BP Claw不是一个简单的提示词工程而是一个将AI作为核心推理引擎的业务-技术转换工作流。3.1 核心架构分阶段、模板驱动的生成流水线我们将FlinkSpec的生成过程分解为多个顺序阶段每个阶段解决一个子问题并逐步丰富文档细节。这模仿了资深数据开发工程师的思考路径需求澄清与要素提取阶段输入用户用自然语言描述的业务需求如“实时追踪用户从浏览到下单的转化漏斗并按渠道细分”。AI作用调用LLM基于我们预置的“问题清单”和“实体识别规则”与用户进行多轮对话式澄清。例如AI会主动询问“您说的‘转化漏斗’具体包含哪几个步骤比如‘浏览商品详情页’、‘加入购物车’、‘提交订单’”以及“按渠道细分‘渠道’是指流量来源app/web、广告渠道还是运营位”输出一份结构化的需求要素表明确了业务目标、核心实体用户、订单、商品、关键指标转化率、各步骤UV、维度时间、渠道和过滤条件。技术映射与逻辑推导阶段输入上一步产出的需求要素表。AI作用结合“Flink知识图谱”内部构建的包含常见业务模式与技术实现的映射关系和“组件库”推导出技术实现方案。例如识别出“转化漏斗”需要计算步骤间的唯一用户数这通常涉及基于用户ID的流式去重和跨事件关联从而映射到使用KeyedProcessFunction或Interval Join的技术方案。输出初步的技术方案草图包括建议的Flink算子、数据流图以文本或标准图形描述语言输出、可能的数据源和输出表。规格文档填充与生成阶段输入技术方案草图 标准化的FlinkSpec文档模板。AI作用将前两步的产出物填充到模板的对应章节。例如将识别出的数据源Topic名称、字段填入“输入数据源”章节将推导出的处理逻辑用结构化的伪代码或配置描述填入“处理逻辑”章节。同时调用内部的资源计算模型根据预估的QPS和复杂度自动生成“性能与容错要求”中的并行度、内存等建议值。输出一份完整的、结构化的FlinkSpec草案。人工审核与反馈优化阶段输入AI生成的FlinkSpec草案。过程数据开发工程师对草案进行审查、修正和补充。所有的人工修改都会被系统记录。AI作用系统利用这些人工反馈数据对AI模型进行微调Fine-tuning或强化学习RLHF优化其在下一轮生成中的表现。例如如果工程师多次将AI生成的“使用滚动窗口”改为“使用滑动窗口”系统会学习到在特定指标场景下滑动窗口更受青睐。3.2 关键技术组件解析为了实现上述流水线我们构建了几个关键组件领域知识库与约束规则库这是BP Claw的“大脑”。我们将公司内部的实时数据开发规范、Flink最佳实践、已有的数据资产Topic、表、字段元数据、业务术语词典等结构化地存入知识库。同时编写了大量约束规则例如“如果输出目标要求低延迟查询则优先考虑输出到Kafka或ClickHouse而非HBase”“涉及状态大小超过1GB的聚合必须使用RocksDBStateBackend”。这些规则用于在生成过程中对AI的提议进行校验和修正。增强的提示工程与上下文管理我们为每个生成阶段设计了系统化的提示词Prompt这些提示词包含了角色设定“你是一个经验丰富的Flink数据开发专家”、任务说明、输出格式要求以及最关键的——从知识库中动态检索的相关案例和规则。通过长上下文窗口我们将用户需求、对话历史、相关知识和模板一次性提供给LLM使其能在丰富的上下文中进行推理。可解释性与可控性设计我们深知“黑盒”AI在技术场景中是危险的。因此BP Claw在生成Spec的每个部分时都会尝试附上简短的“推理依据”。例如在推荐使用Event Time时会注明“因为业务需求涉及基于事件发生时间的窗口统计”。同时工程师可以在生成过程中随时干预手动选择或修改AI提供的选项确保最终输出完全在掌控之中。4. 实操过程从一句话需求到完整Spec让我们通过一个简化的真实案例看看BP Claw是如何工作的。假设业务方提出需求“实时监控APP首页不同运营位Banner、金刚位、Feed流的点击率和GMV贡献。”4.1 第一阶段需求澄清对话用户输入需求后BP Claw的AI助手会启动对话AI: 您好已收到您的需求“实时监控APP首页不同运营位的点击率和GMV贡献”。为了为您生成准确的技术方案需要澄清几个细节“点击率”的计算口径是什么是点击该运营位的UV / 曝光该运营位的UV还是点击次数 / 曝光次数“GMV贡献”是指点击该运营位后最终产生的GMV还是指通过该运营位入口带来的下单GMV统计时间窗口是多长例如点击后24小时内产生的GMV都算作该运营位的贡献时间粒度您希望监控的实时数据看板其刷新频率是多少例如每1分钟更新一次近1小时的数据运营位定义“Banner”、“金刚位”、“Feed流”是否有明确的唯一标识如position_id数据来源是否能准确带上这些标识业务方逐一回答后系统会生成一份需求要素摘要。4.2 第二阶段技术方案推导基于澄清后的要素BP Claw结合知识库进行推导数据源识别知识库中检索到用户行为日志点击、曝光通过log_user_actionTopic上报订单数据通过trade_orderTopic流转。这两个Topic的Schema已知。逻辑推导计算点击率需要将同一运营位的曝光事件和点击事件进行关联。由于曝光和点击可能有时序间隔且需按用户去重系统推导出使用基于Event Time的窗口关联Windowed Join或使用Interval Join是合适方案。计算GMV贡献需要将点击事件与后续的订单事件关联。这是一个典型的延迟关联场景点击和下单可能间隔数小时。知识库规则提示“对于延迟关联且时间跨度较大1小时建议使用Flink SQL的Temporal Table Function或旁路查找如维表Join而非流式Join以避免状态无限增长”。系统据此推荐使用维表Join方案将订单数据作为维表。输出设计由于是实时监控看板需要低延迟查询知识库规则推荐输出到ClickHouse物化视图。系统自动提议输出表结构包含time_window,position_id,exposure_uv,click_uv,ctr,gmv等字段。4.3 第三阶段文档生成系统将上述推导结果填充到标准的FlinkSpec模板中章节AI生成内容示例部分输入数据源1.log_user_action(Kafka Topic): 格式JSON包含user_id,event_time,event_type(exposure/click),position_id,page(‘home’)等字段。处理逻辑核心步骤1. 过滤出首页(page‘home’)的曝光、点击事件流。2. 双流Join对曝光流和点击流按position_id和user_id分组在1分钟滚动窗口内进行关联计算各运营位各窗口内的曝光UV和点击UV。3. 点击流与订单维表Join点击流通过user_id与订单维表从trade_orderTopic实时构建进行关联统计点击后24小时内产生的GMV并按position_id和窗口聚合。输出结果输出至ClickHouse集群bi.clickhouse.realtime数据库下的ads_home_position_ctr_gmv_mv表主键为(window_start,position_id)。性能要求预估QPS行为日志 50k/s订单 5k/s。建议并行度8。建议TaskManager内存4GB其中Managed Memory 1.5GB。Checkpoint间隔1分钟。4.4 第四阶段人工审核与修正数据开发工程师收到这份草案后可能会发现一些问题并修正修正Join类型工程师认为第一步曝光和点击的关联使用Interval Join点击事件在曝光事件后10分钟内比滚动窗口更精确避免了窗口边界切分事件的问题。他手动修改了处理逻辑描述。补充细节工程师补充了订单维表的更新策略如基于CDC的实时更新和关联键user_idorder_timeclick_time。调整参数根据历史经验将并行度从8调整为12以更好地应对流量高峰。这些修正被系统记录用于后续的模型优化。5. 实践中的挑战与应对策略在BP Claw的开发和落地过程中我们遇到了不少挑战也积累了一些经验。5.1 挑战一LLM的“幻觉”与事实性错误即使提供了丰富的上下文LLM有时仍会“捏造”不存在的数据表字段或错误的技术特性。应对策略严格的输出结构化与验证我们强制要求AI的输出必须符合预定义的JSON Schema或模板字段。对于关键实体如Topic名、表名、字段名系统会与元数据中心进行实时校验如果不存在则提示AI重新生成或直接标记为“需人工确认”。检索增强生成RAG的深度应用不仅仅是提供知识库片段我们在生成关键技术决策如选择哪种Join时会要求AI同时引用知识库中相关案例的ID或规则编号增强其输出的可追溯性和可信度。设置“置信度”阈值对于AI生成的某些内容如资源参数估算系统会给出一个置信度分数。低于阈值的部分会高亮提示工程师重点审查。5.2 挑战二复杂业务逻辑的分解与推理有些业务需求非常复杂涉及多流关联、递归逻辑或自定义状态处理超出了当前AI单次推理的能力。应对策略任务分解我们训练AI学会主动将复杂需求拆解为多个子任务。例如“计算用户生命周期价值LTV”可以分解为“新客识别”、“订单行为流处理”、“衰减模型应用”等子任务然后逐个生成子Spec最后组装。思维链Chain-of-Thought提示在Prompt中明确要求AI“逐步思考”并输出中间推理步骤。这不仅能提高最终结果的准确性也方便工程师理解AI的“思路”发现逻辑漏洞。引入专家工作流对于极其复杂的场景BP Claw会退化为一个“智能助手”模式它只负责生成初步的框架和填充已知的模块化部分如数据源定义将最核心、最复杂的逻辑部分留白由工程师手动编写并作为“新知识”反哺系统。5.3 挑战三与现有研发流程的集成如何让BP Claw生成的Spec无缝融入现有的需求管理、开发、测试流程应对策略输出物标准化生成的FlinkSpec严格遵循团队已有的Markdown文档格式并且可以一键导出为JIRA任务或Confluence页面关联到具体的需求卡片。生成可执行代码骨架在Spec的基础上BP Claw可以进一步生成Flink DataStream API或Flink SQL的代码骨架包含主要的算子链和空函数体开发者只需填充核心业务逻辑即可这直接将提效环节从设计阶段延伸到了编码阶段。建立反馈闭环我们将代码评审Code Review中发现的、与设计相关的问题也反向关联到原始的AI生成Spec分析是需求理解偏差、技术方案错误还是知识库缺失从而形成从“需求-AI设计-开发-评审-优化AI”的完整闭环。6. 效果评估与未来展望经过几个月的内部试点和迭代BP Claw已经在我们部分业务线的实时数据需求中常态化使用。量化效果需求澄清周期从平均2-3天缩短到2-3小时主要耗时在于业务方思考并回答AI的澄清问题。Spec初稿质量约70%的常规需求AI生成的Spec初稿经过工程师少量修正少于30%的内容调整即可进入开发阶段。复杂需求也能提供有价值的框架参考。工程师满意度调研显示数据开发工程师认为该工具减少了大量重复、低效的沟通和文档编写工作能更专注于核心逻辑和性能优化。未来演进方向从“辅助生成”到“协同设计”下一步我们希望BP Claw能更主动地参与技术方案的设计讨论。例如当识别到某个需求可能对状态后端造成压力时能主动提出备选方案如使用外部存储Redis并进行优缺点对比。多模态输入理解支持业务方直接上传草图、流程图甚至语音描述AI能从中提取需求信息进一步降低输入门槛。覆盖更广的数据开发生命周期将能力从需求设计FlinkSpec生成扩展到作业上线后的智能运维例如根据运行日志自动诊断反压根源、推荐优化参数甚至预测资源瓶颈。BP Claw项目的实践让我们深刻体会到AI在垂直领域的落地关键不在于模型的绝对大小而在于领域知识的深度注入、工作流的精心设计以及对“人机协同”模式的深刻理解。它不是要替代数据开发工程师而是成为一个不知疲倦、知识渊博的初级助手将工程师从繁琐的“翻译”和“填表”工作中解放出来去解决更富创造性的问题。这个从“编码输入”难题入手的实践或许能为其他领域AI应用的发展提供一个可参考的路径。