在现代 WebGIS 开发中，空间数据处理、坐标系转换以及复杂的前端地图交互往往耗费开发者大量精力。随着 ChatGPT、Claude 和 GitHub Copilot 等大型语言模型（LLM）的普及，AI 辅助编程已成为行业标配。
然而，许多开发者在使用 AI 时常遇到生成的代码无法运行、空间逻辑错乱或完全无视坐标系等问题。这背后的核心原因在于缺乏对 AI 的有效引导。提示词工程（Prompt Engineering）正是连接自然语言与精准空间计算的桥梁。本文将深入探讨 WebGIS 场景下的提示词编写方法，助力开发者实现从理论到实践的效率跃升。
一、 为典型 WebGIS 业务构建高质量 Prompt 的四步框架
在 WebGIS 开发中，由于涉及地图引擎 API（如 Leaflet, Mapbox, Cesium）和空间计算库（如 Turf.js, JTS），需求描述必须极致精确。为此，我们提炼出一个通用的 “角色-任务-上下文-输出” (RTCO) 四步 Prompt 构建框架：
- 角色 (Role)：设定 AI 的专业背景，激发其调用特定领域的知识储备（如：资深 WebGIS 前端工程师、PostGIS 数据库专家）。
- 任务 (Task)：用动宾短语清晰定义需要完成的核心动作，避免模糊表述。
- 上下文 (Context)：这是 GIS 提示词的灵魂。 必须明确包含技术栈版本、坐标系（EPSG 代码）、数据格式（GeoJSON、WKT 等）以及输入数据的具体特征。
- 输出 (Output)：规定代码的语言、结构、注释要求及容错/异常处理机制。
📌 实践案例 1：前端多边形绘制与缓冲分析
假设业务需求是：“在地图上绘制并缓冲分析用户绘制的多边形”。
❌ 模糊的 Prompt（极易翻车）：
“帮我写一段代码，在地图上画一个多边形，然后给它做一个缓冲区并在地图上显示出来。”
（缺点：未指定地图引擎、未说明缓冲距离单位、缺乏坐标系概念，极易导致生成的代码报错。）
✅ 基于 RTCO 框架优化的 Prompt：
# 角色
你是一位拥有 10 年经验的资深 WebGIS 开发工程师，精通前端地图交互与空间几何分析。
# 任务
请编写一段 JavaScript 代码，实现以下功能：监听用户在地图上完成多边形绘制的事件，获取该多边形数据，对其进行缓冲分析，并将缓冲结果渲染到地图上。
# 上下文
1. 技术栈：前端使用 Leaflet (v1.9) 作为地图引擎，使用 Turf.js 作为空间分析库。
2. 输入参数：用户绘制的多边形坐标系为标准的 WGS84 (EPSG:4326)。
3. 缓冲参数：缓冲距离为 500 米。请注意处理 Turf.js 中 buffer 函数的单位设置。
4. 样式要求：原多边形填充颜色为蓝色，缓冲区多边形填充颜色为红色且透明度设为 0.5。
# 输出要求
1. 提供完整的、可直接放入 HTML <script> 标签中运行的 JavaScript 代码片段。
2. 包含关键步骤的中文注释（如坐标提取、Turf 缓冲计算、图层添加到 Leaflet）。
3. 必须包含异常处理机制，例如当用户绘制的点少于 3 个（无法构成多边形）时，在控制台输出警告。
效果解析：通过该框架，AI 能够精准感知 GIS 的苛刻要求，一次性生成包含 L.polygon 绑定、turf.buffer 正确传参以及完备容错逻辑的高质量代码。
📌 实践案例 2：后端 PostGIS 空间近邻查询与性能优化
在后端 GIS 开发中，开发者常需要编写复杂的空间 SQL。如果 Prompt 缺乏对投影和索引的约束，AI 生成的 SQL 往往在小数据量下可行，但在生产环境中会面临严重的性能瓶颈。
✅ 基于 RTCO 框架优化的 Prompt：
# 角色
你是一位精通 PostgreSQL 和 PostGIS 的资深空间数据库架构师。
# 任务
请编写一段高效的 SQL 查询语句，实现“查找距离指定用户位置 5 公里范围内的最近的 5 家医院，并按距离由近到远排序”。
# 上下文
1. 数据库表结构：
- `hospitals` 表：包含 `id` (主键), `name` (名称), `geom` (空间字段)。
- `user_locations` 表：包含 `user_id`, `geom` (空间字段)。
2. 空间坐标系：所有 `geom` 字段的 SRID 均为 4326 (WGS84 经纬度)。
3. 核心约束：由于使用 4326 坐标系，直接使用 ST_Distance 计算结果单位为度。必须使用 Geography 转型或 ST_DWithin 进行以“米”为单位的计算。
# 输出要求
1. 提供完整的 SQL 查询语句。
2. 必须利用 PostGIS 的空间索引操作符（如 `<->`）结合 ORDER BY 和 LIMIT 来优化近邻查询（KNN）的性能。
3. 提供对应的创建空间索引（GIST）的 SQL 语句。
4. 简要注释核心空间函数的逻辑。
📌 实践案例 3：Mapbox GL 数据驱动样式 (Data-Driven Styling)
Mapbox 的表达式（Expressions）语法极其强大但也极其繁琐，通过 RTCO 框架可以让 AI 直接输出精准的样式配置 JSON。
✅ 基于 RTCO 框架优化的 Prompt：
# 角色
你是精通 Mapbox GL JS 和 WebGL 渲染的前端地图专家。
# 任务
为矢量瓦片图层中的“建筑物 (building)”编写一个 Mapbox GL 的 `paint` 属性配置，实现基于属性和缩放级别的数据驱动样式。
# 上下文
1. 图层数据源：矢量瓦片中建筑物要素包含 `height` 属性（单位：米，数值型）和 `type` 属性（字符串，值为 'residential' 或 'commercial'）。
2. 渲染规则：
- 颜色：如果是 'residential' 则为 '#ffcc00'，如果是 'commercial' 则为 '#3366ff'，其他类型为 '#cccccc'。
- 3D高度 (fill-extrusion-height)：直接绑定 `height` 属性。
- 透明度 (fill-extrusion-opacity)：在地图缩放级别 (zoom) 12 到 15 之间，透明度从 0.2 平滑过渡到 0.8。
# 输出要求
1. 仅输出 Mapbox GL Style JSON 中 `paint` 对象的代码块。
2. 必须使用 Mapbox 最新的 Expression 语法（如 `['match', ...]`, `['interpolate', ...]`），严禁使用已废弃的 property function 语法。
二、 Few-shot 提示词在复杂空间计算任务中的实战
在常规的增删改查业务外，WebGIS 常涉及复杂的空间算法逻辑（如空间关系判断、拓扑检查、路径规划）。面对这类任务，仅靠指令描述往往会导致 AI 在处理特殊几何体时发生“幻觉”。此时，Few-shot（少样本）提示词技术显得尤为重要。它通过在 Prompt 中提供少量典型的“输入-输出”示例，让 AI 掌握隐式的空间计算规律。
🎯 构建 Few-shot 示例的三大准则
- 样本多样性：涵盖标准情况与变体（如凹多边形、凸多边形、带孔多边形）。
- 输入输出明确对应：使用结构化数据（JSON/WKT）展示映射关系。
- 包含边界情况 (Edge Cases)：这是 GIS 算法最易出错的地方（如点落在线段上、极点问题），必须通过示例明确浮点数精度或拓扑临界状态的处理。
📌 实践案例 1：点与复杂多边形的位置关系判断
判断点在多边形的“内部”、“外部”还是“边界上”，尤其是遇到带孔多边形和边界精度问题时，大模型极易出错。
✅ 整合 Few-shot 的 Prompt 示例：
你是一个专业的空间算法工程师。请编写一段基于 Turf.js 的 JS 函数 `checkPointPosition(point, polygon)`，判断点与多边形的位置关系。返回值必须是 "Inside", "Outside", 或 "Boundary"。
考虑到浮点数精度和拓扑关系的复杂性，请严格参考以下 3 个示例的逻辑模式：
# 示例 1（标准内部）
Input Point: {"type": "Point", "coordinates": [10, 10]}
Input Polygon: {"type": "Polygon", "coordinates": [[[0, 0], [20, 0], [20, 20], [0, 20], [0, 0]]]}
Expected Output: "Inside"
Reasoning: 点完全被多边形的闭合环包围。
# 示例 2（带孔多边形内部的外部点）
Input Point: {"type": "Point", "coordinates": [10, 10]}
Input Polygon: {"type": "Polygon", "coordinates": [[[0, 0], [20, 0], [20, 20], [0, 20], [0, 0]], [[5, 5], [5, 15], [15, 15], [15, 5], [5, 5]]]}
Expected Output: "Outside"
Reasoning: 点虽然在外环内部，但落在内环（孔洞）中，因此在多边形外部。
# 示例 3（边界临界情况 - 容差处理）
Input Point: {"type": "Point", "coordinates": [10, 0]}
Input Polygon: {"type": "Polygon", "coordinates": [[[0, 0], [20, 0], [20, 20], [0, 20], [0, 0]]]}
Expected Output: "Boundary"
Reasoning: 点正好落在多边形的底边上。在代码实现中，必须结合 Turf.js 的方法（如 booleanPointOnLine 或点到线段的距离计算，容差设定为 1e-6）来捕捉边界情况。
请根据上述示例的严谨逻辑，输出完整的 JS 函数代码。
📌 实践案例 2：复杂 GeoJSON 坐标流的多维数组递归降维
GeoJSON 不同几何类型的坐标数组嵌套深度完全不同（Point 1维、LineString 2维、Polygon 3维、MultiPolygon 4维）。AI 经常写出无法兼容所有深度的递归函数，导致 Cannot read property '0' of undefined。
✅ 整合 Few-shot 的 Prompt 示例：
# 角色与任务
你是一个 GIS 数据处理专家。请使用 JavaScript 编写一个函数 `transformGeoJSON(geojson, transformFn)`，接收任意标准 GeoJSON 对象，遍历其所有的 geometry 坐标，并应用传入的 `transformFn` 来修改底层坐标点。
# 难点说明
GeoJSON 的 `coordinates` 数组深度随类型变化极大。为了确保你的递归逻辑健壮，请严格分析并适配以下 Few-shot 示例中的数组维度：
- 示例 1（Point: 1D 数组）
Input: {"type": "Point", "coordinates": [100.0, 0.0]}
Target: transformFn 直接接收并处理 `[100.0, 0.0]`。
- 示例 2（LineString: 2D 数组）
Input: {"type": "LineString", "coordinates": [[100.0, 0.0], [101.0, 1.0]]}
Target: transformFn 被调用两次，分别处理 `[100.0, 0.0]` 和 `[101.0, 1.0]`。
- 示例 3（Polygon: 3D 数组 - 包含外环和内环）
Input: {"type": "Polygon", "coordinates": [ [[100,0], [101,0], [101,1], [100,1], [100,0]], [[100.2,0.2], [100.8,0.2], [100.8,0.8], [100.2,0.8], [100.2,0.2]] ]}
Target: transformFn 需要穿透 3 层数组，处理最底层的每一个 `[lng, lat]` 坐标对。
# 输出要求
根据上述规律，编写一段精简且高效的递归代码。需确保能正确解析 Feature 的 `geometry` 属性以及 FeatureCollection 的 `features` 数组。
📌 实践案例 3：意图推断——模糊空间自然语言转 OGC 标准 WKT 与 SQL
在 NL2SQL/NL2GIS 应用中，用户输入往往是不规范的口语。如果没有 Few-shot 示例，大模型极易犯两个致命错误：多边形未闭合，以及距离计算忽略投影转换。
✅ 整合 Few-shot 的 Prompt 示例：
# 角色与任务
你是一个专业的空间文本解析引擎与数据库架构师。请将用户输入的自然语言转化为 OGC 标准的 WKT，并生成对应的 PostGIS SQL。数据库表为 `facilities`，包含空间字段 `geom` (SRID: 4326)。
# Few-shot 示例学习
[示例 1：离散点提取]
User: "我要标记两棵树，一棵在经度116.3纬度39.9，另一棵在116.4和39.8。"
WKT: MULTIPOINT(116.3 39.9, 116.4 39.8)
Reasoning: 提取到两个独立的坐标对，使用 MULTIPOINT。注意严格遵循“经度在前，纬度在后”。
[示例 2：闭合区域自动首尾相连（高危边界情况）]
User: "划定一个保护区，四个顶点分别是 [10,10], [20,10], [20,20], [10,20]。"
WKT: POLYGON((10 10, 20 10, 20 20, 10 20, 10 10))
Reasoning: 用户只提供了4个顶点，但 OGC 标准强制要求 Polygon 首尾必须闭合。因此，必须自动将第一个点追加到末尾。
[示例 3：带有缓冲意图的空间查询（投影转换陷阱）]
User: "找一下坐标(120.1, 30.2)周围 500 米范围内的所有设施。"
WKT: POINT(120.1 30.2)
SQL: SELECT * FROM facilities WHERE ST_DWithin(geom::geography, ST_GeomFromText('POINT(120.1 30.2)', 4326)::geography, 500);
Reasoning: 提取中心点为 POINT。由于 SRID=4326 单位是度，必须将字段和目标点强制转型为 `geography` 类型，确保 500 的单位被正确解析为米。
---
# 当前任务
User: "帮我建一个电子围栏，范围依次经过经纬度 113.5,22.1 然后是 113.6,22.1，再到 113.6,22.2，最后是 113.5,22.2，帮我查一下这个围栏里面所有的设施。"
请严格按照上述学习到的逻辑（特别是坐标闭合规则），只输出解析后的 WKT 字符串和最终的 PostGIS SQL 语句，并附带简短的推理（Reasoning）。
效果解析：通过这三个高度提纯的示例，AI 能够自动补齐 (113.5 22.1) 作为多边形的闭合点，并正确使用 ST_Contains 或 ST_Intersects 生成高可用 SQL。
三、 总结与展望
在 WebGIS 开发中，提示词工程不仅是一门对话的艺术，更是空间逻辑工程化的体现。
- 掌握 “角色-任务-上下文-输出” (RTCO) 四步框架，可以快速生成健壮的基础 GIS 交互与渲染代码；
- 运用遵循 “多样性、明确性、边界性” 准则的 Few-shot 技巧，则能从容应对复杂的空间拓扑与几何算法挑战。
展望未来，AI 与 GIS 的融合将不断深化。从现阶段的 AI 辅助编码，到未来的自然语言生成地图（NL2Map）与自动构建空间数据分析管道（GeoAI Pipeline），WebGIS 开发者的角色正逐渐向 “空间 AI 调度师” 转变。持续精进提示词工程，不仅能解决当下的效率痛点，更是我们在空间智能化时代保持核心竞争力的必由之路。
