数据湖与分区架构技能用于在存储平台因管道规模扩张而陷入混乱之前，为其建立结构。它帮助智能体设计清晰的湖区分区、数据集边界、所有权、生命周期规则以及可安全发布的存储约定。
用途方面，该技能适用于在数据湖、仓储、湖仓、流式与混合形态之间选择整体云架构模式的任务，也适用于单纯的分区设计。它可以帮助设计新的数据湖、重组原始、暂存、精炼或治理分区、定义对象存储布局与生命周期规则、划分落地区、转换区与发布区职责，以及减少共享湖存储中出现的数据沼泽行为。需要留意的是，它不应用于为没有运营目的的多余分层提供理由。
主要能力体现在工作流上：首先定义湖的用途与消费者，明确源数据落地的需求、内部生产者团队、发布消费者以及合规与保留期望；其次有意识地定义分区模型，典型分区包括原始或落地、标准化或暂存、精炼或建模、发布或服务；然后为每个分区分配职责，决定谁写入、谁读取、存在何种质量保证、是否允许变更；接着设计存储约定，包括路径或目录命名、分区策略、保留生命周期、文件大小预期、所有权标签与元数据；最后将发布规则与湖的便利性分开，因为湖中的每个数据集并非都准备好供共享消费。
使用方式上，该技能以工作流步骤引导智能体逐步完成设计，并包含验证环节，要求分区模型具有清晰的目的与边界，所有权、读写期望与质量保证明确，存储约定与生命周期规则有文档记录，共享发布数据集与原始落地数据分离。此外还提供跨云架构参考，当任务不仅是分区设计，而是要在湖、仓储、湖仓、流式与混合形态之间选择整体云架构模式时，可参考 cloud-data-engineering-architecture-patterns.md。
适用场景包括新数据湖设计、分区重组、对象存储布局与生命周期定义、落地区/转换区/发布区职责划分、减少共享存储中的数据沼泽行为，以及跨云架构模式选择。
限制方面，该技能明确不应用于为没有运营目的的多余分层提供理由。文档列出了常见合理化的反驳：将全部数据倾倒进一个桶或容器并期望稍后整理，会导致数据湖变成数据沼泽；更多分区并不总意味着更好的治理，没有明确目的的多余分层会增加复杂性并拖慢团队；湖中存在文件并不意味着可用于分析，原始落地数据很少具备共享使用所需的质量或契约保证。同时指出红旗信号：分区含义重叠或未记录、数据集或分区级别的所有权不清晰、发布数据与落地数据混在一起、缺少保留、清理或生命周期策略。