用 AI 写了一个经纬度格式转换工具，从需求到落地的完整过程

郭邯 2026-08-18 0 阅读10分钟

最近在做一个地理相关的内部工具时，频繁需要处理经纬度格式转换和距离计算的问题。每次都要打开各种在线工具，来回切换页面，实在麻烦。正好最近在尝试用 AI 辅助开发，就想着能不能让 AI 帮我快速实现一个自用的工具。

为什么会有这个需求

做地图相关的开发，经常会遇到这样的场景：从数据库里导出的坐标是十进制度格式（比如 39.9042），但客户要求展示为度分秒格式（比如 39°54'15.12"N）。反过来，从 GPS 设备获取的坐标可能是 DMS 格式，需要转成 DD 格式才能存储。

以前我的做法是：打开搜索引擎，找个在线转换工具，复制粘贴，再复制回来。这个过程来回切换页面，效率很低。而且很多在线工具还带广告，页面加载也慢。

后来想着，既然自己会写代码，为什么不做一个自用的工具呢？正好也想试试 AI 辅助编程的效果，就有了这个项目。

传统方案的问题

在动手之前，我其实考虑过几个方案：

方案一：直接用现成的在线工具

• 优点：零成本，打开即用
• 缺点：需要切换页面，数据需要复制粘贴，不能批量处理，而且有些工具还限流

方案二：写一个命令行脚本

• 优点：可以批量处理，速度快
• 缺点：不够直观，每次都要打开终端，而且不方便给团队其他人用

方案三：做一个简单的 Web 工具

• 优点：可视化操作，方便分享，可以集成到内部系统中
• 缺点：需要花时间开发

最终选择了方案三，因为考虑到这个工具可能不止我自己用，团队里其他人也需要，Web 页面是最友好的形式。

AI 辅助开发的过程

说实话，一开始我对 AI 写代码是持怀疑态度的。毕竟以前用 AI 写的代码，经常出现逻辑错误或者风格不一致的问题。但这次我决定认真试一次，看看能不能配合 AI 完成一个完整的工具。

第一轮：需求描述

我用的提示词大概是这样的：

你是一名资深前端工程师。请根据下方规格，生成一个独立的单文件 HTML 工具。

要求：
- 生产级别代码，质量高，可读性强
- 严格实现「功能列表」中的所有功能，不得省略、不得用 placeholder 代替
- 所有用户可见文案必须使用 i18n 机制

然后列出了详细的功能列表，包括：

1. DD→DMS 转换
2. DMS→DD 转换
3. 双向输入，自动计算
4. 半球标识自动判断
5. Haversine 公式计算距离
6. 方位角计算
7. 常用城市坐标速查
8. 一键复制结果

第二轮：AI 代码的问题

AI 第一次生成的代码，整体结构还不错，但有几个问题：

问题一：输入框联动逻辑不完善

AI 生成的代码中，DD 输入框的 oninput 事件只触发了 onDDChange()，而 DMS 输入框的事件只触发了 onDMSChange()。但实际使用中，用户可能会在两个输入框中来回切换，需要确保两边数据始终同步。

function onDDChange(){
    var lat=parseFloat(document.getElementById('ddLat').value);
    var lon=parseFloat(document.getElementById('ddLon').value);
    updateHemispheres();
    if(!isNaN(lat)){
        document.getElementById('dmsLat').value=ddToDmsStr(lat,true);
    }else{
        document.getElementById('dmsLat').value='';
    }
    // ... 省略
}

问题二：DMS 解析不够健壮

AI 生成的 dmsStrToDd 函数，虽然能处理标准格式，但遇到一些特殊情况就会出错。比如用户输入 39°54'15.12" 和 39 54 15.12 这种格式不同的情况，需要统一处理。

function dmsStrToDd(str){
    // ... 省略
    // 需要处理多种分隔符：°、'、"，以及空格
    var normalized=str.replace(/[\u00b0\u00ba\u2218]/g,' ').replace(/['\u2019\u2032"]/g,' ').replace(/[\u2033\u201d]/g,' ').trim();
    parts=normalized.split(/[\s,]+/).filter(function(p){return p.length>0;});
    // ... 省略
}

问题三：缺少输入校验

AI 生成的代码，对极端输入（比如超过 90 度或 180 度的经纬度）没有做校验。虽然这不是核心功能，但作为一个生产级工具，应该要有基本的输入检查。

第三轮：与 AI 的对话调优

发现问题后，我和 AI 进行了多轮对话：

我： "DMS 解析函数需要处理更多格式，比如 39 54 15.12 这种空格分隔的格式，还有 39°54'15.12" 这种标准格式。"

AI： "好的，我来优化解析逻辑。我会统一处理各种分隔符，并增加格式校验。"

我： "输入框需要加防抖处理，避免用户连续输入时频繁触发计算。"

AI： "明白，我会增加一个防抖函数，延迟 300ms 执行计算逻辑。"

我： "城市坐标按钮点击后，需要同时更新 DD 和 DMS 两个输入框。"

AI： "好的，我会在 applyCity 函数中同时更新两个输入框的值。"

通过几轮对话，AI 不断完善代码。但说实话，AI 生成的代码还是需要人工检查的。比如它对 NaN 的处理、对空值的判断，有时候不够严谨。这些地方我都需要手动修改。

核心技术实现

DD → DMS 转换

这个转换逻辑其实很简单：

function ddToDmsStr(dd, isLat) {
    var hemi = isLat ? (dd >= 0 ? 'N' : 'S') : (dd >= 0 ? 'E' : 'W');
    dd = Math.abs(dd);
    var d = Math.floor(dd);
    var mFloat = (dd - d) * 60;
    var m = Math.floor(mFloat);
    var s = (mFloat - m) * 60;
    return d + '°' + String(m).padStart(2, '0') + '\'' + s.toFixed(2).padStart(5, '0') + '"' + hemi;
}

这里有几个细节需要注意：

1. 要先取绝对值，再计算度分秒
2. 分和秒要用 padStart 补零，保证格式统一
3. 半球标识根据正负判断

DMS → DD 转换

反向转换稍微复杂一点，因为要处理各种输入格式：

function dmsStrToDd(str) {
    // 处理负号和半球标识
    // 统一分隔符
    var normalized = str.replace(/[°º˚]/g, ' ').replace(/[''']/g, ' ').replace(/[""]/g, ' ').trim();
    var parts = normalized.split(/[\s,]+/).filter(function(p) { return p.length > 0; });
    // 如果是单个数字，直接当作十进制度
    if (parts.length === 1) {
        return parseFloat(parts[0]);
    }
    // 否则按度分秒解析
    var d = parseFloat(parts[0]);
    var m = parseFloat(parts[1]);
    var s = parts.length >= 3 ? parseFloat(parts[2]) : 0;
    return d + m / 60 + s / 3600;
}

这里踩过一个坑：度分秒的符号 ° 在 Unicode 中有多种表示方式（\u00b0、\u00ba、\u2218），需要统一处理。AI 一开始只处理了 \u00b0，导致其他符号无法解析。

Haversine 距离计算

距离计算用的是 Haversine 公式，这是球面距离计算的标准方法：

function haversine(lat1, lon1, lat2, lon2) {
    var dLat = toRad(lat2 - lat1);
    var dLon = toRad(lon2 - lon1);
    var a = Math.sin(dLat / 2) * Math.sin(dLat / 2) +
            Math.cos(toRad(lat1)) * Math.cos(toRad(lat2)) *
            Math.sin(dLon / 2) * Math.sin(dLon / 2);
    var c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a));
    return R_EARTH * c;
}

地球半径取 6371 km，这个值在大多数场景下精度足够。

方位角计算

方位角计算稍微复杂一些，需要用到 atan2 函数：

function bearing(lat1, lon1, lat2, lon2) {
    var y = Math.sin(toRad(lon2 - lon1)) * Math.cos(toRad(lat2));
    var x = Math.cos(toRad(lat1)) * Math.sin(toRad(lat2)) -
            Math.sin(toRad(lat1)) * Math.cos(toRad(lat2)) * Math.cos(toRad(lon2 - lon1));
    var brng = Math.atan2(y, x);
    return (toDeg(brng) + 360) % 360;
}

注意最后要加 360 再取模，确保方位角在 0-360° 范围内。

设计决策

为什么用纯前端？

这个工具不需要存储数据，也不需要后端逻辑，纯前端完全够用。而且纯前端可以免费部署在静态页面上，不需要维护服务器。

为什么用单文件 HTML？

考虑到这个工具可能会被分享给团队其他人使用，单文件 HTML 是最方便的形式。直接打开浏览器就能用，不需要安装任何依赖。

为什么支持中英文切换？

虽然主要是自己用，但考虑到团队里可能有外籍同事，而且作为在线工具发布后可能被更多人使用，所以做了 i18n。

为什么用 CSS 变量做主题？

CSS 变量配合 prefers-color-scheme 媒体查询，可以自动适配系统的深色模式，不需要手动切换。

踩坑记录

坑一：input[type="number"] 的滚动条问题

在 Chrome 中，input[type="number"] 的上下箭头按钮会占用空间，导致输入框看起来不整齐。解决方案是隐藏默认的滚动条：

input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
    -webkit-appearance: none;
    margin: 0;
}
input[type="number"] {
    -moz-appearance: textfield;
}

坑二：复制到剪贴板的兼容性

navigator.clipboard.writeText() 在非 HTTPS 环境下不可用，需要降级到 document.execCommand('copy')。虽然现在基本都是 HTTPS 了，但为了兼容性还是做了 fallback。

坑三：DMS 格式的字符串解析

用户输入 DMS 格式时，可能会用各种符号分隔。比如 39°54'15.12"、39 54 15.12、39-54-15.12 等。需要统一处理这些格式。

使用 AI 辅助开发的感受

这次用 AI 辅助开发，整体体验还是不错的。AI 帮我节省了大部分编码时间，尤其是在 HTML/CSS 布局和基础逻辑实现上。但它也有明显的短板：

1. 对边界的处理不够严谨：AI 生成的代码，对空值、NaN、特殊字符的处理经常有问题，需要人工检查和补充。
2. 对业务逻辑的理解不够深入：比如 DMS 格式的多种变体，AI 一开始只处理了标准格式，需要我提示才会补充。
3. 代码风格不够统一：AI 生成的代码，变量命名和函数组织方式可能不一致，需要整理。

我的建议是：把 AI 当成一个高级的代码生成器，而不是一个完全自主的开发者。用的时候要给出明确的需求和验收标准，生成后要认真 review 代码，尤其是边界情况。

最终效果

工具完成后，用起来确实方便多了：

• 输入十进制度，自动转换度分秒
• 输入度分秒，自动转换十进制度
• 选择两个城市，自动计算距离和方位角
• 支持中英文切换
• 支持深色模式

整个工具是一个单文件 HTML，可以直接打开使用，也可以部署到静态服务器上。

适用场景

这个工具适合以下场景：

1. 地图开发调试：需要快速查看坐标格式转换结果
2. GPS 数据处理：需要批量转换坐标格式
3. 地理教学演示：展示 DD 和 DMS 格式的关系
4. 物流路径规划：计算两个地点的直线距离和方向

如果你也有类似的需求，可以在线体验：地理编码演示 - 在线经纬度格式转换工具

总结

这次用 AI 辅助开发小工具的经历，让我对 AI 编程有了新的认识。AI 确实能提高开发效率，但前提是你要有清晰的思路和严格的需求描述。与其说 AI 帮你写代码，不如说 AI 帮你把想法快速变成现实。

最后想说，不管用什么工具，核心还是你对业务的理解和对代码质量的要求。AI 只是个加速器，不能替代你的判断力。