Code with Cosmos：AI辅助开发实战，本地跑通数据库应用

Azure Cosmos DB 团队推出了一档名为 Code with Cosmos 的系列节目，由高级产品营销经理 Mark Ohari 和产品经理 Patti Chow 共同主持。第一集的目标很明确：从一个空文件夹出发，在完全不依赖 Azure 订阅的情况下，仅凭一台笔记本电脑，构建出一个可运行的 Cosmos DB 应用。

这件事的意义不在于炫技，而在于回答开发者启动新项目时最朴素的问题——怎么让它先跑起来。

起步阶段的真正难点：数据建模

Patti Chow 在节目中指出了一个常被低估的事实：大部分困难工作发生在写应用代码之前。开发者需要选择数据模型、分区策略、索引方案，并提前想清楚查询方式。这些决策最终会体现在可扩展性、延迟和成本上，一旦选错，三周后就得重构。

更麻烦的是，这一切还发生在接触任何 AI 能力之前。传统路径下，开发者要么依赖经验，要么查阅大量文档，试错成本高。

AI 辅助开发带来的变化在于，Cosmos DB 的专业知识被直接放进了开发环境。具体来说有三块：本地模拟器让开发者在笔记本上拥有一个真实的 Cosmos DB 环境；Agent Kit 把最佳实践教给编码助手；MCP Toolkit 则让智能体能够安全地连接数据。三者配合，开发者可以在 VS Code 内完成设计、生成、验证和测试，不必切换工具。

分区键（Partition Key） 是 Cosmos DB 中决定数据分布和水平扩展的核心概念。每个容器必须指定一个分区键属性，Cosmos DB 根据该属性的哈希值将数据分布到不同的物理分区上。分区键的选择直接影响三个方面：一是可扩展性，高基数（不同值多）的分区键能让读写均匀分布，避免热点分区造成吞吐瓶颈；二是查询效率，跨分区查询需要汇聚多个分区的结果，延迟和 RU 消耗都更高，而单分区查询可以精准命中；三是成本，每次操作消耗的请求单位（RU）会体现在账单上。常见误区是把低基数属性（如状态、类型）或频繁更新的属性作为分区键，导致分区膨胀。理想的分区键应具备高基数、分布均匀、且被高频查询用作过滤条件这三个特征。

请求单位（Request Unit, RU） 是 Cosmos DB 中衡量吞吐与成本的抽象单位。一次点读取（按 id 和分区键读取单个 1KB 文档）消耗 1 RU，写入、查询、更新消耗的 RU 各不相同，取决于文档大小、索引策略和查询复杂度。预配吞吐量模式下，开发者按每秒 RU 数（RU/s）购买容量，因此 RU 效率直接决定应用成本。理解 RU 有助于在设计阶段就优化查询：避免全表扫描、减少跨分区查询、精简索引，都能显著降低 RU 消耗。本地模拟器同样会返回每次操作的 RU 消耗，方便开发者在迁移云端前就完成成本调优。

从 PRD 到数据模型：对话式设计

演示项目的起点是一份简短的 PRD，描述了一个 AI 旅行规划应用，涉及用户、行程、航班和偏好，以及预期的查询方式。文档里甚至包含一个具体场景：有人计划去巴塞罗那过个长周末，应用需要记住他偏好精品小酒店、绝不订红眼航班这类细节。

在 VS Code 中，开发者把助手指向这份文档，助手会返回数据模型和容器设计，解释分区键的取舍，建议索引方案，并对照最佳实践做检查。开发者仍然是决策者，但不再是在信息不足的情况下拍板。

这个环节的价值在于把隐性的架构经验显性化。分区键选错是 Cosmos DB 新手最常见的坑之一，而助手会在设计阶段就把权衡讲清楚。

生成代码与查询：从自然语言到可测试结果

数据模型确定后，代码生成环节才是工具真正发力的时候。Agent Kit 赋予编码智能体真实的 Cosmos DB 专业知识，MCP Toolkit 让它连接到本地模拟器。于是生成的代码不再是通用 CRUD 模板，而是理解分区、索引、RU 效率和向量搜索的惯用写法。开发者只需描述需求，比如"用户、行程和偏好的数据层"，助手就会写出对应代码，甚至用旅行者、目的地、酒店、餐厅、航班等真实感数据填充模拟器。

节目主持人形容这个过程"像在聊这个应用"，但聊完之后手里有真东西可以测试。

查询环节同样如此。想要一个向量查询，用平实的英语描述即可，比如"找巴塞罗那适合轻松长周末的活动"，助手会写出包括向量距离计算在内的查询语句。开发者从自然语言出发，再检查和调优生成结果。所有操作都在本地模拟器上完成，模拟器是真实的 Cosmos DB 环境，分区键等配置一应俱全，同一份代码日后可以直接跑在云端 Cosmos DB 上。

向量搜索（Vector Search） 是 Cosmos DB 支持的查询能力之一，用于在向量化数据（如文本或图像的嵌入向量）中查找语义上最相似的结果。传统 NoSQL 查询基于精确匹配或范围条件，而向量查询通过计算向量之间的距离（如余弦相似度、欧氏距离）来排序结果，因此能回答“找巴塞罗那适合轻松长周末的活动”这类模糊语义问题。Cosmos DB 将向量存储在文档的数组属性中，并提供 VectorDistance 函数在查询中计算距离。执行向量查询通常需要配合向量索引（如 DiskANN 索引）以保证性能，且向量查询会消耗较多 RU。在演示中，助手生成的就是包含向量距离计算的查询语句，开发者可以在此基础上调整候选集大小和相似度阈值。

这套流程改变了什么

回看整集内容，路径可以概括为：空文件夹加一份规格说明，用助手设计数据模型，生成代码，产出并调优包括向量查询在内的各类查询，本地运行，最终得到一个可工作的应用。工具的作用是缩短到达终点的时间，而非替代开发者的判断。

对正在评估 AI 辅助开发的团队来说，这个演示提供了一个可参照的样本：AI 的价值不在于替你写完所有代码，而在于把领域最佳实践前置到设计和编码的每一步，减少后期返工。本地模拟器加 Agent Kit 加 MCP Toolkit 的组合，也说明了 AI 编程工具正在从"补全代码"走向"理解特定数据库语义"。

系列第二集将展示如何用向量、全文和混合搜索让应用变得智能，目标是在实时运营数据上找到巴塞罗那真正合适的那家酒店，而不只是相似的一家。

MCP（Model Context Protocol） 是一套开放协议，用于让 AI 智能体以标准化、可审计的方式连接外部工具和数据源。在 Cosmos DB 的场景中，MCP Toolkit 充当智能体与本地模拟器之间的桥梁：智能体通过 MCP 声明它可以执行哪些操作（如读取容器结构、运行查询、写入测试数据），工具端则负责权限控制和执行。这种设计把“智能体能碰什么数据、能做什么操作”变成显式契约，而不是让模型直接持有连接字符串任意操作。对开发者而言，这意味着可以在本地安全地让 AI 助手访问模拟器中的数据库，同时保持对数据访问边界的控制，也为后续迁移到云端时的安全策略打下基础。