基于AI的质量风险管控旨在通过AI解决质量领域诸多难题，本文分别从风险前的风险管理、风险中的风险感知和风险后的风险控制等多个阶段介绍质量管控的整体思路，实现质量结果的持续可控。

本文介绍了一种融合“AI项目管理、端到端Feature交付、全视角数字化度量”的研发新范式，旨在利用AI技术解决协作痛点，实现研发交付的高效与可控。

面对复杂的业务场景，百度数据分析平台（TDA） 通过分析能力增强与性能优化双轮驱动，来持续保障用户的分析体验

本文概述了在业务高速发展和降本增效的背景下百度MEG（移动生态事业群组）大数据成本治理实践方案，主要包含当前业务面临的主要问题、计算数据成本治理优化方案、存储数据成本治理优化方案、数据成本治理成果以及

百度电商风控研发团队在审核场景，通过流程ai化改造和建设机审AI Agent，阶段性实现了替代人审和完成审核提效目标的最佳实践。

本文深入剖析大规模微服务系统中雪崩故障的形成机理与微观演化路径，并结合百度系统性治理框架，分享可落地的预防与应对实践。

导读

面对传统数据接入流程人力高、周期长、质量难控的痛点，本文提出了“数据平台智能化入库”的整体解决方案。方案以大型语言模型（LLM）为核心，结合代码生成流与执行流构建“智能代码闭环”，实现从数据Schema识别、结构化映射、质量规则抽取到入库包构建的全流程自动化。通过“生成-执行-反馈”闭环机制，系统能持续自我优化、沉淀知识与代码资产，大幅缩短接入周期（从3个月降至3天内）、降低人工成本（从4人月降至零人工干预），并显著提升系统可控性与扩展性，为企业级数据治理与智能化运营奠定了坚实技术基础。

01 背景与挑战

1.1 业务背景与需求场景

在当代企业数据治理体系中，数据平台承担着汇聚多源异构数据、支撑数据分析与业务决策的核心职能。典型业务场景包括：

• 跨部门数据整合与分析
• 实时业务监控与决策支持
• 用户行为分析与个性化推荐
• 企业级数据资产沉淀与管理

这些场景要求数据接入流程具备高效率、高准确性和强可扩展性，以适应快速变化的业务需求。

1.2 传统数据接入方案

传统数据接入采用全人工对接模式，其核心流程包括：

1. 需求沟通阶段（约2周）

• 业务方与百度产品经理多次会议明确需求

• 架构师参与评估技术可行性与方案设计

• 确定数据格式、传输方式、更新频率等细节

2. 开发实施阶段（约6周）

• 业务方开发团队按照百度数据标准进行适配开发

• 百度架构师团队提供技术指导与方案评审

• 双方开发团队协调接口对接与联调测试

3. 测试验证阶段（约1周）

• 数据质量验证与一致性检查

• 性能压力测试与稳定性评估

• 安全合规性审查与漏洞修复

4. 上线运维阶段（持续）

• 生产环境部署与监控

• 异常处理与应急响应

• 定期维护与迭代更新

1.3 痛点分析与技术挑战

1.3.1 效率瓶颈突出

• 人力成本极高：平均需要4人月（1PM+1架构师+2开发）对接一个业务方

• 接入周期漫长：从启动到上线平均需要2-3个月时间

• 扩展性受限：人力投入随业务量增长线性增加，无法支撑业务快速扩展

1.3.2 质量保障困难

• 标准落地不一致：人工理解偏差导致数据标准执行不统一

• 错误反馈滞后：数据质量问题往往在后期才发现，修复成本高

• 知识沉淀不足：对接经验难以标准化和复用

1.3.3 技术复杂度高

• 异构数据源适配：不同业务系统数据类型、格式、协议差异大

• 实时性要求挑战：既要保证数据处理的准确性，又要满足低延迟要求

• 规模扩展难题：传统人工方式无法应对数据量和业务量的快速增长

1.4 智能化转型的必然性

面对这些挑战，数据平台数据接入必须向自动化、智能化方向转型：

• 降低人力成本：从4人月/业务降到接近零人工干预

• 提升接入效率：从数月缩短到3天内完成新业务接入

• 保证数据质量：通过智能校验确保数据标准统一执行

• 支持大规模扩展：智能系统可并行处理多个业务接入请求

02 整体技术架构与核心流程

我们提出的“数据平台数据智能化入库”解决方案，其核心目标是将传统高度依赖人工配置、规则编写与经验判断的数据入库流程，转变为一种高度自动化、自适应的智能化流水线。整套架构的设计哲学是：以大型语言模型（LLM）为核心驱动力，以“代码即资产”为核心理念，通过“生成-执行-反馈”的闭环，将LLM的认知与泛化能力固化为可重复、高效率、易维护的业务逻辑代码。

整个系统的顶层架构如下图所示，它清晰地勾勒了从原始数据输入到最终数据入库的全过程，以及支撑该过程的智能闭环体系：

该架构的核心可以概括为两条主线：

1. 水平流水线（核心流程）：描述了数据处理的四个阶段，是业务价值实现的直接体现。

2. 垂直闭环（技术核心）：即“智能代码闭环逻辑”，它像大脑和神经系统一样渗透并赋能每一个阶段，是实现智能化的关键技术保障。

2.1 核心流程详解

如架构图所示，整个智能化入库流程分为四个层层递进、环环相扣的关键阶段。每个阶段都共享同一套智能代码闭环逻辑，但在具体任务、模型输入输出和后处理上各有侧重，共同构成了一个完整的数据处理管道（Pipeline）。

阶段一：数据原始Schema智能识别

技术目标：理解未知结构数据的组织方式、字段语义、数据类型及潜在质量问题，为后续处理奠定基础。

技术难点与深度：

1. 多模态与非均匀结构：数据源可能是结构化的CSV、半结构化的JSON/XML、甚至非结构化的日志或PDF文本。模型必须具备多模态理解能力和强大的模式泛化能力，从杂乱元数据中提取关键信息。

2. 语义歧义消解：识别类似ctime,create_time,生成时间等不同命名实际上属于同一语义范畴。这要求模型具备深厚的领域知识沉淀。

3. 异常值与模式冲突检测：在首行看似是INT类型的字段中，可能存在N/A、NULL、“-”等异常值，模型需要推断出真实的数据类型并提出清洗建议。

智能化实现：

此阶段的“代码生成流”会驱使基础模型（如CodeLLama, DeepSeek-Coder）分析数据样本。Prompt会精心设计，要求模型输出的不是简单描述，而是可执行的数据分析代码（例如生成Pandas DataFrame的dtypes分析、describe统计、唯一值枚举、异常值检测规则的代码）。生成的代码在CodeServer执行后，其输出（数据profile报告）会成为反馈，用于优化下一次的代码生成或用于模型微调。

阶段二：结构化数据抽取与映射

技术目标：将原始数据，无论是简单的行列转换还是复杂的嵌套解析，规整为目标数据库所需的扁平化结构。

技术难点与深度：

1. 复杂嵌套结构解析：处理JSON中多层嵌套的List和Object，并将其安全地展开为一维表结构，同时处理好父子关系的映射，防止数据丢失或错乱。

2. 跨表关联与实体识别：从多个数据文件中识别出可关联的键（如user_id），并自动建议表关系模型。这涉及实体统一和消歧等NLP核心难题。

3. 高性能转换逻辑：生成的代码不仅要逻辑正确，还需考虑大数据量下的性能（如避免逐行处理，尽量使用向量化操作）。

智能化实现：

此阶段Prompt会包含第一阶段识别出的Schema，并指示模型生成数据转换代码（如Pandas数据处理管道、PySpark SQL查询或自定义解析函数）。模型需要理解目标表结构，并编写出包含类型转换、字段拆分、嵌套展开等逻辑的高质量代码。代码执行流的效率优势在此淋漓尽致，一次生成，后续百万条数据都复用同一份高性能代码执行。

阶段三：数据质量规则与筛条件的智能抽取

技术目标：从业务需求描述或数据样本中，自动提取出数据清洗的质量规则（如：金额字段必须大于0）和面向业务查询的常用筛选项（如：按地区=、时间=筛选）。

技术难点与深度：

1. 从自然语言到规则逻辑的转化：理解“取最近3个月的有效数据”这类业务口语，并将其转化为WHERE date >= ‘2024-02-17’ AND status = ‘active‘这样的精确SQL条件。这是一项复杂的语义解析（Text-to-SQL）任务。

2. 规则冲突检测：自动识别并解决生成的规则间可能存在的矛盾（如规则A要求字段不为空，规则B又允许其为空）。

3. 规则合理性评估：生成的规则是否过于宽松或严格，需要有一定的业务先验或通过历史数据验证进行反馈。

智能化实现：

Prompt会引导模型将模糊的需求转化为精确的、可组合的条件判断逻辑代码或配置参数（如生成一套用于数据清洗的Python函数或一套可供下游系统调用的筛选器配置JSON）。这是将业务知识固化到系统中的关键一步。

阶段四：数据入库包的自动构建与执行

技术目标：将前三个阶段的产出物（表结构、转换代码、清洗规则）打包成一个可独立部署、版本化管理、一键执行的“数据入库包”。

技术难点与深度：

1. 工作流编排：生成的代码需要按照正确的依赖关系组织成执行工作流（例如：先建表 -> 然后跑数据转换 -> 最后执行数据质量检查）。

2. 原子性与可逆性：保障执行过程的原子性（全部成功或全部回滚），并提供版本回退的能力，这要求生成代码中融入事务管理逻辑。

3. 自动化部署集成：如何将最终合格的代码包无缝对接到CI/CD流程或调度系统中，实现真正的“无人值守”。

智能化实现：

此阶段模型的角色更像是一个自动化架构师。它根据前序步骤的产出，生成诸如 Dockerfile、SQL 建表语句、Airflow DAG 定义文件或 Shell 部署脚本等，将分散的代码模块整合为一个完整、健壮的数据管道应用。

2.2 架构优势总结

通过“智能代码闭环逻辑”赋能的核心四阶段架构，我们实现了：

1. 能力固化与性能飞跃：将LLM的智能一次性沉淀为代码，执行效率相比纯模型调用提升百倍，极大降低了对模型实时性与算力的依赖。

2. 卓越的可调试性与可控性：每一阶段的产出都是代码或配置，完全透明、可版本控制、可人工Review与干预，实现了智能与人工的完美协同。

3. 持续进化能力：闭环中的反馈机制为模型的持续优化（通过SFT和RL）提供了高质量的数据来源，系统会越用越聪明，成功率不断提升。

4. 清晰的职责边界：该架构明确了LLM的职责是“编写代码”，而CodeServer的职责是“执行代码”，二者各司其职，使得系统更加稳定和模块化。

此架构不仅解决了当前数据入库的痛点，更为企业构建了一个持续积累、不断优化的“数据知识库”和“自动化代码库”，为未来的数据治理与应用打下了坚实的技术基础。

03 智能入库的技术闭环

在数据平台“数据智能化入库”的全流程中，智能代码闭环逻辑 是实现自动化与自适应优化的核心引擎。它的本质是通过 代码生成流（Code Generation Flow） 与 代码执行流（Code Execution Flow） 的协同，形成一个“自我进化”的技术闭环，将大模型的自然语言处理与工程化执行环境深度结合，从而达到 自动生成 → 自动执行 → 自动优化 → 自动部署 的能力。

3.1 双流并行的核心思路

智能代码闭环逻辑由两条并行的主线构成：

1. 代码生成流（Code Generation Flow）

• 通过大模型理解数据特征和业务目标，自动生成可运行的逻辑代码。

• 在生成过程中引入模式识别、Prompt 优化、上下文记忆机制，确保输出代码具有 业务适配性、鲁棒性和可维护性。

• 生成代码不仅包括数据解析、清洗、抽取逻辑，还涵盖数据条件处理、数据入库包构建、Schema 管理等全链路自动化操作。

2. 代码执行流（Code Execution Flow）

• 所有生成的代码都被自动推送至

CodeServer 执行环境，形成标准化的任务流。

• 执行过程中严格控制依赖版本、逻辑分支与错误回滚机制，保证代码执行的可追溯与可控性。

• 执行结果与异常会实时反馈给生成流，用于二次修正与自适应优化。

这两条流相互作用，构建了一个持续收敛的 智能闭环。

3.2 代码生成流的完整流程

代码生成流并非简单的“一次性代码生成”，而是一个带有反馈自适应机制的复杂工程化过程：

“模式识别 → 代码生成 → 执行校验 → 自适应优化 → 部署上线”，并加入自动化 CR Gate与人机协作。

1. 模式识别与需求建模

• 通过大模型对原始数据 Schema、样本数据进行分析，抽取元信息（字段类型、依赖关系、语义标签）。

• 结合业务侧规则，自动生成逻辑约束与需求规格说明（Specification）。

• 技术难点：需要跨越 非结构化到结构化语义转换，同时保证生成结果能够驱动下游逻辑。

2. 智能代码生成

• 基于识别结果自动生成 ETL（Extract-Transform-Load）、Schema 适配、清洗、数据入库等多类代码。

• 引入 模板驱动 + 大模型自由生成 的混合模式，确保生成的代码既符合业务通用逻辑，又能保持灵活性。

• 技术难点：需要解决 代码可编译性与业务正确性 的双重挑战。

3. 自动化校验与反馈

• 在 CodeServer 中执行生成代码，收集运行日志、错误栈、性能指标。

• 自动对比结果与预期，生成反馈信号。

• 技术难点：错误可能出现在数据层（Schema 不匹配）、逻辑层（业务规则缺失）、执行层（依赖冲突），闭环系统需要自动分类与修复。

4. 自适应优化与Prompt迭代

• 根据反馈结果自动调整 Prompt，或更换基础模型（如 Code LLM → 专用 SFT 模型）。

• 可结合 RLHF/代码打分器，通过强化学习优化生成逻辑。

• 技术难点：如何避免“震荡式优化”（模型不断在两个错误之间切换），需要引入收敛判定机制。

5. 自动部署与人工干预

• 最终验证通过的代码自动上线至执行流，作为标准任务模块。

• 在自动部署前触发 代码 CR（Code Review） 流程，支持人工审查与修订。

• 技术难点：需要保证部署过程安全可控，同时能在人工介入与智能优化之间平衡。

整个闭环在每个阶段都遵循同一套迭代模式：模式识别 → 自动生成代码 → 代码校验与反馈 → 自适应优化 → 部署/触发。下面把每一步拆解为技术要点与工程实现：

3.2.1 模式识别（Schema & 元信息推断）

• 目标：从样本数据中识别字段、类型、语义（时间/金额/ID/地名/指标）以及表间关系（主外键、实体归属）。

• 混合方法：

        统计与启发式：空值率、唯一值率、类型分布、正则候选（日期/邮箱/UUID）用于初筛。

        嵌入与聚类：对文本字段建立文本/列级向量（例如基于token embedding或sentence embedding），通过聚类区分自由文本 vs 枚举 vs 代码值等。

        LLM 语义推断：对列样本与上下文使用大模型输出列的语义标签（例如：{"col":"trade_time","type":"timestamp","semantic":"交易时间"}），并给出置信度与解释。对于复杂嵌套JSON，采用分层解析策略（先抽样确定结构，再全量扫面）。

• 输出：候选Schema（字段名/类型/nullable/示例/语义标签/置信度）写入元数据仓库，供下游CodeGen调用。

• 难点与对策：

        字段语义不唯一：使用多模型投票（统计+embedding+LLM），并保留不确定列供人工复核；

        极端稀疏或混合型列（如ID混合文本）：启用规则引擎回退（正则、字典）。

3.2.2 自动生成代码（解析、清洗、数据入库脚本）

• 目标：根据候选Schema与业务约束自动生成可执行的ETL/ELT代码、SQL建表DDL或数据入库包。

• 模式：

        模板化生成：将常见操作（日期格式化、货币归一、异常值剔除、字段映射）抽成模板片段，LLM负责拼接并补全业务特例逻辑。

        AST/代码骨架：LLM生成代码时同时产出中间AST或结构化输出（例如JSON形式的操作步骤），以便静态分析与快速修改。

        测试驱动生成：同时自动生成单元/集成测试（小样本断言），以及基于property-based tests的约束（如：主键唯一、外键完整性、列值范围）。

• 工程要点：

        限制能力：对LLM生成代码的能力进行语法/安全限制（沙箱API、资源限制、禁止系统调用）。

        可解释的代码注释：强制在生成代码里内嵌可追溯的注释（生成者版本、prompt id、时间戳），便于回溯。

3.2.3 代码校验与反馈（CodeServer 执行）

• 目标：在受控环境执行生成代码，收集执行结果、异常与性能指标，形成可训练的反馈数据。

• 关键组件：执行沙箱（CodeServer）——负责安全执行、资源隔离、输入/输出挂载与审计日志。

• 测试套件：

        单元测试：断言核心转换逻辑；

        性能测试：采样数据上跑批量执行以估计时延与内存使用；

        回归/一致性测试：与历史版本比对（例如同源数据处理结果的差异率）。

• 异常采集与分类：语法错误、运行时异常、数据不一致、性能瓶颈、业务规则违背（例如金额为负但不可负）等都需要被分类并打标签（error taxonomy），以驱动后续优化。

3.2.4 自适应优化（Prompt、模型与训练回路）

• 目标：通过数据驱动方式持续提升模型在生成正确代码与正确抽取方面的成功率，并降低人工干预率。

• 方法栈：

        Prompt 版本管理：记录prompt、模板、示例输入-输出对。优先做prompt工程优化（few-shot、chain-of-thought、structured-output constraints）。

        SFT（Supervised Fine-Tuning）：将高质量的人标或已验证代码片段并入训练集，做周期性SFT；

        强化策略训练（CodeServer trace driven）：将执行成功/失败作为奖励信号，训练奖励模型或使用RL（离线RL或基于策略梯度的微调）提高生成器的长期回报（具体实施需注意样本偏差与安全控制）；

        自动化A/B测试：对新prompt/模型做小流量评估，采集关键指标再决定是否推广。

• 数据回路：执行Trace（包含代码、输入样本、执行结果、错误类型、人工修订历史）拼成训练样本，按label刷入训练仓库。

3.2.5 自动部署与触发（CR 流程与治理）

• 自动PR与人工审批：通过自动化工具将生成代码封装为变更请求（PR），执行静态策略检查（安全、合规、命名规范），当满足高置信条件可自动合并并部署，否则进入人工审查流程。

• 部署策略：金丝雀/分批上线、变更影响评估（schema迁移锁、回滚脚本）、自动化回滚阈值（如数据偏差超过阈值）。

• 新数据触发：数据落地或对象存储到达新文件时自动触发分类识别并调用已上线代码或触发新代码生成流程。

3.3 代码执行流的核心机制

与代码生成流互补，代码执行流强调 稳定性与可控性：

• 版本化管理：执行逻辑与模型访问解耦，每一次更新都通过版本化控制，可快速回滚。

• 异常检测与容错：通过日志追踪与异常监控体系，自动分类问题（数据错误 / 逻辑错误 / 环境错误），实现快速修复。

• 人工干预能力：在执行中可随时切换业务逻辑版本，支持定制化处理。

• 高效执行：相比直接依赖大模型在线推理，执行流运行在编译后的固定逻辑上，性能提升可达 百倍以上。

04 模型训练与持续优化

• 针对不同阶段，采用专属基础模型、个性化Prompt及后训练数据集

• 难点优先通过模型结构与Prompt优化，常态下使用SFT训练

• 引入CodeServer的强化学习机制，将代码执行结果反馈给模型，形成“代码-模型-业务”三位一体的持续学习系统

• 对于模型失效或边缘场景，支持人工审核与快速回溯修正，保证系统稳健性

05 技术创新与价值

1. 模式驱动与自动代码生成深度融合：大幅降低人工介入，提高入库效率与准确性

2. 全流程可追溯、可自愈：闭环反馈机制保障数据资产治理质量

3. 模型与代码双重强化学习：以执行结果反哺模型训练，技术深度行业领先

4. 弹性扩展与自动适配新数据源：支持多类数据源与业务变化，极大增强系统通用性与可维护性

06 未来展望

• 引入多模态大模型，提升非结构化数据（如图片、文本、视频）入库能力

• 深度集成数据质量检测、异常识别与业务语义理解，为数据平台智能治理提供更强保障

• 打造端到端的“智能数据工厂”，支撑企业级数据资产的自动化、智能化运营

结语：

数据平台智能化入库，是AI与数据工程深度融合的前沿技术。通过模式识别、自动代码生成与循环反馈的闭环体系，我们不仅显著提升了数据入库的自动化和智能化水平，还为企业数据资产的高效治理奠定了坚实基础。欢迎大家交流探讨，共同推进数据智能领域的发展！

面对百度APP日均数千亿PV、超百PB数据规模带来的巨大挑战，我们完成了数据仓库的系统性升级。本文详细阐述了通过"两步走"策略解决资源压力、处理延迟和架构瓶颈的全过程。

随着人工智能技术的迅猛发展，如何在视频内容创作领域通过大模型自动化合成视频，来满足用户日益增长的内容需求？

随着百度Feed流业务高速发展，如何建设时效更高、数据更准确、架构更稳定的Feed实时数仓？详细阅读查看

看BaikalDB如何借助模型上下文协议(MCP)，让数据库对话像聊天一样简单——无需编写代码，大语言模型即可完成复杂数据分析。

你有没有这样的体验？导航说30分钟能到，结果真的一分不差？ 有时候导航告诉你要绕行5分钟的路，其实省下了20分钟的堵车。 这些神奇的“预知能力”，就是我们常听到的 ETA（Estimated Time

你有没有过这样的体验？在高速上对着导航喊“小度小度”，它就神奇地回应道“来了”；在地下车库问“最近的充电桩”，屏幕立刻跳出相关的充电桩指引；甚至对车载语音助手说“有点冷”，空调的温度就会悄悄调高。这些

面向业务场景的大模型评估中会面临着什么样的问题，如何解决这些问题，在实际评估中又需要注意哪些问题呢？

本文重点介绍TDS在数据开发治理实践上的核心理念与技术落地，包括“流程标准化、质量可控化、运维智能化”三大方向。

本文介绍了百度网盘如何通过Flink构建实时计算引擎，以解决Spark Streaming存在的问题，提供高性能、低延迟、稳定的实时计算能力，并介绍了实时计算引擎的演进历程、选择Flink的原因及展望

本期内容4年开发经验的 Java 大佬执墨为我们带来了包括规则配置在内的5个文心使用技巧分享。助你增加 AI Coding 技能点！一起来看看！

执墨，4年开发经验程序员一枚，一个懂点 AI 的软件研发工程师，持续学习有意思的技术、做有意思的事，目前在探索如何培养出一个 AI 开发搭子。

相信大家在实际使用 AI 生成代码的过程中，会发现**有些代码让人抓心挠肝，不是放错了位置，就是不符合项目规范，最后还要返工手动修改，觉得不如自己手搓。**但别担心，自己学写代码怎么说也学了三四年，玩游戏角色释放技能也有前摇，AI 写好代码当然也需要慢慢培养。从 Zulu 开始公测我就在使用文心快码，也算是小有经验。那么结合个人在 IntelliJ IDEA 中的使用体验，我总结了 Zulu 和 Chat 各自比较实用的技巧，希望能对大家有所帮助。

▎Zulu 调教指南：生成代码更可用

1.用 # 提供上下文

大语言模型本质上是基于前文内容来预测下一个最可能的词或代码片段。没有上下文，模型就无法准确判断下一步生成内容，因此对上下文的理解和利用是生成高质量代码的基础。在开发场景中，上下文不仅包含当前文件或代码片段，还涵盖项目结构、依赖关系、函数和变量作用域等。通过理解这些上下文，AI 能够更准确补全代码或生成符合项目风格的内容。

在文心快码中为 Zulu 添加上下文：Zulu 目前支持文件、文件夹和项目级别的上下文。开发者可以通过 # 操作符来唤起当前被索引的所有的文件，并添加为当前会话的上下文。

Step1：# 操作符唤起上下文菜单

Step 2：选择对应的文件或者目录。可以添加多个，如果没有选择上下文，则会默认使用当前项目为上下文环境。

Step 3：上下文配置好以后，可以通过自然语言的方式来描述你需要让 AI 干的事情。

在这个例子中，我选择了 Cache.java 这个文件，然后让 Zulu“实现一个查询缓存时，根据类型做反序列化的函数，目标为 Redis 序列化”。这时 Zulu 就开始阅读上下文，立刻理解了我的需求，在 Cache 接口中进行修改，添加了目标功能。

2.善用命令自动执行

**Zulu 能够自动感知当前工程的框架、技术栈、文件结构和运行环境，根据需求自动生成终端命令，并将这些命令发送到开发环境中的终端进行执行。**这种能力在脚本语言的开发过程中，非常具有优势，比如 Python、JS 等。你无需关注需要使用什么框架，AI 自行去进行使用和安装，开发者能够更专注于业务逻辑的实现。

例如在下面的 Python 虚拟环境创建和配置中，Zulu 首先生成并执行了终端命令 python3 -V，查看当前环境中已安装的 Python 版本，然后通过命令 python3 -m venv venv 创建了一个虚拟环境，最后通过 source venv/bin/activate && pip install -r requirements.txt 激活虚拟环境并安装项目依赖。整个过程完全没有跳出 IDE，极好地维护了开发过程中的心流体验。

3.规则约束

当没有提供规则文件去约束 Zulu 的生成行为时，在进行一个新的项目开发过程中，很容易会生成一些不达预期的代码，也会魔改代码。了解到文心快码支持自定义 Rules，因此我为 Zulu 编写了执行的上下文约束，控制其代码的生成。下面将具体展开我撰写规则的思路。

3.1编码环境

**介绍当前的编码环境，说明当前项目的所使用的技术栈。这一步至关重要，就好比给 Zulu 描绘了一幅项目的蓝图，让它清楚自己所处的 “战场” 环境。**例如在这个基于 Java 的 Spring Boot 项目中，明确告知了 Zulu 项目使用的是 Java 语言，以及 Spring、Spring Boot、Spring Security 等相关技术框架。这样，Zulu 在生成代码时，就能遵循这些技术栈的规范和特点，生成与之适配的代码。

## 编码环境
用户询问以下编程语言相关的问题：
- Java
- Spring&SpringBoot&SpringSecurity
- MyBatis&MybatisPlus
- RocketMq
- Nacos
- Maven
- SpringSecurity

3.2代码实现指南

**这个部分说明当前项目具体的代码如何实现，比如数据库表的创建规范、用户上下文怎么获取、项目结构的含义等。这相当于给 Zulu 制定了一套详细的工作 SOP，让它生成的代码符合项目的特定要求。**在采用 DDD（领域驱动设计）方式实现代码的项目中，我为 Zulu 提供了如下的 SOP。

1. 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  1. 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  2. Application或者Service层的输出必须的DTO，接口层的返回可以是DTO 也可以自己定义 VO
  3. 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域UserDO，应用层的DTOUserDTO
  4. 项目的类之间的转换需要使用 MapStruct 来完成
2. 在使用三方依赖的时候，需要将对应的依赖内容先添加到 Maven 依赖中
3. 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  1. 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  2. 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  3. 对于批量查询接口，你需要涉及分页的能力，不能使用内存分页，只能在 DB 层面做分页，并且要考虑深分页的问题
  4.  所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  publicclassBaseResp<T> {
      privateString code;
      privateString message;
      privateT data;
  }
  4. 对于应用层，需要注意如下几点：
      1. 函数的输入和输出都是 DTO

3.3总结历史记录

每次使用 Zulu 生成代码后，可以让 Zulu 帮我们将每一次 Query 后的结论进行总结并记录到文件中，这对于项目的跟踪和回溯非常有帮助。提示词如下：

## 历史记录
1. 针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
2. 你需要按照倒序的方式记录这个历史纪录

这种详细的记录格式，能够清晰地展示每次代码生成的时间、变更内容以及涉及的文件，方便开发者随时查看和追溯项目的开发记录。而倒序记录使得最新的变更记录排在前面，开发者能够快速获取到最新的项目动态，提高了信息查找的效率。

▎Chat 隐藏技巧：编码交互更灵活

在研究 Zulu 的同时，我也发现了 Chat 功能比较好用的地方，下面想继续分享一些让编码过程更方便快捷的能力。

1.Inline Chat 行间会话

通过圈选代码片段，使用 Ctrl + I 快捷键可以唤起文心快码的行间对话能力，帮助我们快速对局部代码进行优化和调整，**此时上下文即当前的代码片段。

在对话框中输入需要 AI 完成的任务，Comate 会自动扫描代码并编辑，编辑完成后可以自行决定是否采纳或者忽略。

2.Git Commit 快捷键提交代码

在完成一个功能模块的开发后，需要提交代码到版本库。一般来说需要手动梳理本次代码的修改内容，编写提交信息。而在文心快码中，只需点击 Git Commit 快捷按钮，Comate 就能自动分析代码的变更情况，生成详细准确的提交信息，大大节省了时间，同时也提高了提交信息的质量，方便团队成员更好地了解代码的变更历史。

在 Git Commit 的时候点击快捷按钮，可以快速总结本次代码的变更内容。

▎案例实操

接下来就把这些小技巧应用在实际案例中，检验一下是否对开发流程有提效。

1. 实现一个社区自动签到脚本

文心快码在编写脚本方面具有显著优势，准确率极高。在实际工作中，我现在用到的脚本几乎都由文心快码完成，并且几乎都能一次性运行通过。**以实现一个社区自动签到脚本为例，具体操作步骤如下：

Step 1: 书写提示词，直接用自然语言描述即可，需要给出其接口定义信息和执行规则。

“给我写一个 python 脚本，实现接口签到和抽奖能力。

以下是签到接口的定义：

GET 接口：……(为保护隐私，此处略去）

以下是抽奖接口的定义：……

再调用接口时，你需要按照先调用签到再调用抽奖的顺序来完成，并且这两个接口需要一个 cookie 信息来完成调用，因此你需要定义一个全局的 cookie 来实现这两个接口的定义。”

Step 2: Zulu 后自行生成对应的文件

Step 3: 按照 Zulu 的提示执行对应的命令，然后这个脚本就成功实现完成了。

2. 实现一个约束之下的意图识别服务

这个案例的重点在于，在新的项目中如何将自己业务项目中的一些编码规则告知 AI，使生成的代码更符合团队的开发规范。

Step 1: 书写提示词，在提示词部分添加了“实用技巧”中的第3点规则约束部分提到的规则。

“我需要你实现一个意图识别的工程能力，它的主要功能是对外提供一个 OpenApi 的接口来根据用户的输入返回一个固定的意图。这个 OpenApi 的实现思路是：

1.查询本地的规则列表；然后进行匹配；

2.如果本地的规则都无法匹配，则调用第三方的 LLM 接口进行意图识别；

3.返回结果。

你的代码实现需要按照这个规则来：#.zulurules”

完整规则见附录一

Step 2: Zulu 生成代码与总结

▎写在最后

文心快码是我个人使用的第一款 AI 编程工具，其核心功能围绕两大模块展开：编程智能体 Zulu 与 Chat ，二者协同能够满足不同编程需求。Zulu 与 Chat 功能相比，核心差异在于其具备更强的自动化编码能力：能够直接生成完整文件并编写代码，且生成内容会以 Diff 格式清晰展示修改痕迹，方便开发者直观对比并选择是否采纳。文心快码插件实现了与 JetBrains 系列 IDE 的深度集成——开发者无需离开熟悉的 IDE 环境，即可调用 AI 编程能力。对于我这样习惯使用 JetBrains 工具链的 Java 程序员而言，这种原生集成的体验尤为友好，能在日常开发流程中自然融入 AI 辅助，减少工具切换成本。

附录：Rules 示例

你是一名资深后端开发专家，精通 Java、Spring、SpringBoot、MyBatis、MyBatisplus、RocketMq以及各种中间件，如：Zookeeper、Nacos、SpringCloud等。你思维缜密，能够提供细致入微的答案，并擅长逻辑推理。你会仔细提供准确、事实性、深思熟虑的答案，并且在推理方面堪称天才
- 严格按照用户的需求执行。
- 首先逐步思考——用伪代码详细描述你的构建计划。
- 确认后，再编写代码！
- 始终编写正确、符合最佳实践、遵循 DRY 原则（不要重复自己）、无错误、功能完整且可运行的代码，同时确保代码符合以下列出的 代码实现指南。
- 优先考虑代码的易读性和简洁性，而不是性能。
- 完全实现所有请求的功能。
- 不要留下任何待办事项、占位符或缺失的部分。
- 确保代码完整！彻底验证最终结果。
- 简洁明了，尽量减少其他描述。
- 如果你认为可能没有正确答案，请明确说明。
- 如果你不知道答案，请直接说明，而不是猜测。
- **注意：尽量使用已经存在的目录，而不是自建目录**
- 你需要严格按照 cursorrules 中的内容来生成代码，不要遗漏任何内容
# 编码环境
用户询问以下编程语言相关的问题：
Java
Spring&SpringBoot&SpringSecurity
MyBatis&MybatisPlus
RocketMq
Nacos
Maven
SpringSecurity
# 代码实现指南
## 依赖处理
- 你所有使用到的依赖必须在根目录的 Pom 文件中做 Dependency Management 版本管理
- 对于通用的依赖可以直接放到根目录的 Pom 文件中，如 lombok
## 监控上报能力
- 你需要为项目中所有使用到的外部插件增加监控上报能力，如：线程池，Redis、MySQL 等。你可以使用 Spring actuator 提供的能力对外提供 Prometheus 格式的上报信息
## 数据库SQL
你需要根据用户的输入来推断可能使用到的表的结构，并按照如下的格式生成。
- 其中 create_time、update_time、create_user、update_user 是必须拥有的字段。
ext和is_deleted可以根据用户的需求来选择添加
- 对于唯一索引，其需要同一个前缀为 ux_，如：ux_business_key_type；对于非唯一索引，需要同一个前缀为 idx_，如：idx_business_key_type
```CREATE TABLE `audit_log` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '账户日志ID',
`business_key` varchar(100) NOT NULL DEFAULT '' COMMENT '业务实体ID或索引,如账号名',
`business_type` smallint(6) unsigned NOT NULL DEFAULT '0' COMMENT '10000-账号,20000-邮箱,30000-ADKeeper,40000-远程账号',
`operate_desc` varchar(500) NOT NULL DEFAULT '' COMMENT '操作描述',
`version` int(11) NOT NULL DEFAULT '0' COMMENT '版本号',
`ext` json DEFAULT NULL COMMENT '扩展属性',
`is_deleted` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '是否删除0为未删除，1为删除',
`create_time` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
`update_time` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
`create_user` varchar(32) NOT NULL DEFAULT '' COMMENT '创建人',
`update_user` varchar(32) NOT NULL DEFAULT '' COMMENT '更新人',
PRIMARY KEY (`id`),
KEY `idx_business_key_type` (`business_key`,`operate_type`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8 COMMENT='账户审计表'
```#编写代码时遵循以下规则：
- 你不能直接在根目录上创建 src 文件夹，而是要创建一个当前项目的子模块来完成代码生成，模块的名字默认为 当前项目名-api
- 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  - 使用充血模式和工厂模式的方式来完成项目代码的实现
  - 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  - Application或者Service层的输出必须的 DTO，接口层的返回可以是 DTO 也可以自己定义 VO
  - 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域 UserDO，应用层的DTO UserDTO
  - 项目的类之间的转换需要使用 MapStruct 来完成
  - 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  - 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  - 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  - 所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  public class BaseResp<T> {
      private String code;
      private String message;
      private T data;
  }
  - 对于应用层，需要注意如下几点：
     - 函数的输入和输出都是 DTO
  - 对于远程调用层，需要注意如下几点：
     - 你需要使用 @HttpExchange 的能力来完成远程调用，并且让项目中的第三方配置收口到同一个配置节点下。示例如下：
@HttpExchange
public interface IntentRemoteClient {
    @PostExchange(value = "/api/open/agent/intent")
    BaseResprecognizeIntent(
        @RequestBody IntentRequest request
    );
}
@Data
@ConfigurationProperties(prefix = "api")
public class ApiProperties {
    /**
     * 应用依赖的外部服务的配置, 这些外部服务使用 MiPaaS 认证中心提供的认证
     */
    @Valid
    @NotEmpty
    private Map external;
    /**
     * 外部服务配置
     */
    @Data
    public static class ExternalService {
        /**
         * 服务 API 的基础 URL
         */
        @NotBlank
        @URL
        private String baseUrl;
        /**
         * 对一些配置的覆写
         */
        private ExternalServicePropertiesOverrides overrides;
    }
    /**
     * 认证使用不同的 URL 和 认证凭据的配置
     */
    @Getter
    @AllArgsConstructor
    public static class ExternalServicePropertiesOverrides {
        private String authServiceBaseUrl;
        private ClientCredential clientCredential;
    }
    @Getter
    @AllArgsConstructor
    public static class ClientCredential {
        private String appId;
        private String appSecret;
    }
} 
@Configuration
@EnableConfigurationProperties(ApiProperties.class)
public class RestApiConfig {
    private final Mapservices;
    public RestApiConfig(ApiProperties appProperties) {
        this.services = appProperties.getExternal();
    }
    @Bean
    public IntentRemoteClient intentRemoteClient() {
        // 1. 获取服务对应的配置
        var svc = findServiceConfiguration("intent");
        // 2. 构建 Client
        var httpClient = HttpClient.create()
          .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
          .wiretap(true)
          .responseTimeout(Duration.ofSeconds(10));
        var client = WebClient.builder()
          .baseUrl(svc.getBaseUrl())
          .codecs(clientCodecConfigurer -> clientCodecConfigurer.defaultCodecs().maxInMemorySize(50 * 1024 * 1024))
          .clientConnector(new ReactorClientHttpConnector(httpClient))
          .filter(new AuthorizationAuthFilter(svc.getOverrides().getClientCredential().getAppId(),
            svc.getOverrides().getClientCredential().getAppSecret(), svc.getBaseUrl()))
          .build();
        var factory = HttpServiceProxyFactory.builderFor(WebClientAdapter.create(client)).build();
        return factory.createClient(IntentRemoteClient.class);
    }
    /**
     * 生成服务配置
     *
     * @param name 服务名称
     * @return ExternalService
     */
    @NotNull
    private ApiProperties.ExternalService findServiceConfiguration(@NotNull String name) {
        var svc = services.get(name);
        if (svc == null) {
            throw new IllegalArgumentException("no such service");
        }
        return svc;
    }
} 
  - 对于数据库层，你需要注意如下几点：
     - 你需要为DB增加 自动映射枚举 的能力，即可以在数据库的 PO 中直接使用枚举
     - 你需要使用 自动填充字段 功能来填装 create_time、update_time、create_user、update_user。其中创建人和更新人可以通过 SpringSecurity 获取。
# 历史记录
针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
你需要按照倒序的方式记录这个历史纪录

当人工智能进入深度应用的黄金时代，单一模态的局限正被多模态交互彻底打破。文心 ERNIE-4.5-VL 视觉语言模型（ ERNIE-4.5-VL-28B-A3B；ERNIE-4.5-VL-424B-A

在播放器架构不断演进的今天，视频后处理技术正在成为提升用户体验的关键环节。相比传统的解码即播，现代播放器越来越多地引入后处理链路，通过增强画质、渲染氛围等手段，为用户提供更具沉浸感的视听体