第一幕：一句话，从零到有

我之前做的一个项目是图像解说方向，期间反复需要验证地理坐标信息，当时就是手工打开腾讯地图网页版，搜索一个地点，再右键查看坐标，复制粘贴到代码里测试。反反复复，烦得不行。
有一天突然想到：如果我有一个工具，能直接搜索地址、点击地图就拿到坐标、还能规划路线，该多方便。
项目最开始，我的需求非常模糊：
“帮我做一个腾讯地图的 demo，可以搜索地址、点击地图解析坐标、做路线规划。”
其实说"需求"有点抬举自己了。那更像是一个念头。
“做一个工具"对于新手小白来说，和"造一辆车"的难度差不多。坦白说，我也不擅长写代码。典型的"知道方向、走不了全程"的状态。
所以，当我对WorkBuddy 说出这句话的时候，我的心态其实是"试试看，反正也亏不了什么”。我甚至做好了它给我一堆链接让我自己去研究的准备。
就是在这样的背景下，我打开了 WorkBuddy，说了一句话。

然后一个下午之后，我的EdgeOne上多了一个完整可用的地图应用。

WorkBuddy没有问我"你用什么框架"、“需要后端吗”、“你懂 JavaScript 吗”。它没有反问，没有确认，没有把需求拆解成 Jira Ticket 让我去填——它直接开始干。
十几分钟后，一个完整的应用已经出现在我的工作区。
打开一看：左侧三个 Tab（搜索、坐标解析、路线规划），右侧腾讯地图实时渲染。搜索框输入"故宫"，按下回车，地图立刻飞到北京，标记点上弹出一个编号气泡，气泡里写着"故宫博物院"。点击地图任意位置，坐标框里实时出现经纬度和反向解析的地址文字。切换到路线规划 Tab，起点终点填上两个地方，选择驾车，地图上画出一根蓝色路线，旁边还有预计距离和用时。

那一刻我的感受很微妙——不是"哇它好厉害"，而是"等等，我是不是只需要学会怎么说人话就行了"。这是我第一次感受到"对话式开发"和"让 AI 帮我改代码"的区别：后者是你还在掌舵，前者是你说目的地，它负责开船。

---

第二幕：WorkBuddy的工作方式

有了第一个版本之后，我开始变得贪心。
倒也不是故意贪心——是 v1.0 用了一两天之后，那些"要是有 xxx 就好了"的念头开始一个接一个冒出来。用坐标解析的时候，我发现自己经常需要把坐标发给别人，但没有"复制"按钮，每次都要手动选中数字；用路线规划的时候，起点永远是手动输入的，可我明明就坐在电脑前面，为什么不直接用 GPS 定位呢？
这些想法都很碎片化，不是什么经过深思熟虑的产品规划。我只是在某个瞬间觉得"差一点什么"，然后顺手就打字告诉WorkBuddy了。
接下来我陆续提出新需求——准确说，是想到什么说什么：

• “能不能加一个「我的位置」功能，用 GPS 定位我在哪？”
• “我想搜附近的餐厅/医院/ATM，做个分类快捷入口”
• “历史记录能不能保存下来，关掉网页再打开还在”
• “加个测距功能，我想量两个地点之间的距离”
• “地图能不能切换卫星图和夜间模式”

我本以为WorkBuddy每次会给我一个"最简可行方案"——加个按钮、调用 API、显示结果，三步走。但实际上，它每次都不只是"加一个按钮"，而是真的在设计这个功能。
拿"历史记录"来说。我说的就两个字：“保存”。
WorkBuddy做了什么？它用 localStorage 做了本地持久化，这样关掉浏览器再打开数据还在。它发现纯坐标用户看不懂（谁记得自己上次点的是 39.91535, 116.40423？），于是异步调用逆地理编码 API 把坐标转成地址文字，填充到历史记录列表里。每条记录点击一下，地图会平滑飞行到那个位置，而不是突兀地跳切。超过 20 条自动删除最旧的，防止 localStorage 溢出。还加了一个小的删除按钮和"清空全部"按钮，方便管理。
这些，我一条都没有提。
再说"附近搜索"。我原话大概是"帮我搜附近的餐厅、医院什么的"。
WorkBuddy做了 9 个分类快捷按钮——🍜 餐饮、🛒 购物、🚌 交通、🏥 医疗、🏨 住宿、🎓 教育、🏦 银行、⛽ 加油站、📍 其他——每个按钮都有图标，排列整齐。然后它加了一个 500 米到 5 公里的半径滑块，让我可以调节搜索范围。更进一步：它把「我的位置」按钮放在了搜索中心，点一下就能自动把 GPS 坐标填进去，不需要手动输入。
这个交互设计的逻辑链条是这样的：

用户搜"附近" → 自然需要先定位"我"在哪 → 所以把 GPS 坐标自动填入 → 而不是让用户手动输入坐标（用户根本不知道自己的坐标是什么）

WorkBuddy把这个完整的用户旅程想清楚了，而我的脑子里只有"搜附近的"四个字。
这就是WorkBuddy让我最惊讶的地方：它不只响应你说的，它在想你没说的。

---

第三幕：一键部署，真的就一键

功能做完了，我面临最后一个问题：怎么让别人也能访问？
一个纯前端的 HTML 文件，理论上扔到任何静态托管上就能跑。但你知道，实际操作起来，"理论上"这三个字后面通常跟着一长串坑——买个域名、配 SSL 证书、搞 Nginx、配反向代理、处理 CORS、如果是国内服务器还得上备案……
“怎么让别人也能访问？”
这个我们就需要调用EdgeOne的skill来连接。先发布一个简单的应用进行测试。

然后我看着它在对话窗口里执行了一系列操作：读取本地的 index.html 文件内容，调用 deploy_html 工具上传到 EdgeOne Pages 的 CDN 节点，十几秒后返回了一个 HTTPS 链接：

https://mcp.edgeone.site/share/t_Ve9eJ-PjufI2N8FnH-l

全球 CDN 加速，HTTPS 加密，立即可访问。不需要域名，不需要备案，不需要服务器。
我把这个链接发给朋友，他们打开就能用，不用安装任何东西。放在手机浏览器里也一样——腾讯地图本身就有移动端适配，我的页面又没有用任何固定宽度的布局，所以天然就是响应式的。
这个部署过程里，我没有接触任何 CLI 命令、没有登录任何控制台、没有配置任何 DNS 记录、没有跑过一次 git push。WorkBuddy把整条链路都打通了，因为它不只是个"代码生成器"——它连接了工具链。这就好比你雇了一个装修队，他们不但帮你设计、帮你施工，最后还帮你把钥匙交到新房客手里。

运行效果如下：

第四幕：迭代升级的记忆

v1.0 上线之后，我又断断续续找WorkBuddy加了五六个功能，每次都是新开对话。按照以往使用 AI 助手的经验，我本以为每次都要重新解释项目背景——“这是一个地图应用，用的腾讯地图 API，代码在 index.html 里，目前有三个功能……”
但WorkBuddy完全不需要。因为它有开发记忆功能。
每次对话结束后，WorkBuddy会自动把关键信息写到工作区的记忆文件里——今天做了什么、用了什么技术方案、改了哪些文件、部署到哪个地址了。下次新对话打开时，它会先读取这些记忆文件，然后直接接上上次的状态。
所以我的对话通常是这样开始的：

“继续扩展 mcp-geo 的功能，加个距离测量。”

然后WorkBuddy就知道：哦，这是 mcp-geo 项目，代码在 index.html 里，腾讯地图 JavaScript SDK + WebService API，纯前端单文件，上次部署到了 EdgeOne Pages。
它不需要我重复任何上下文。
这个体验在传统开发流程里几乎不可能实现。如果是两个人协作，你至少要有一份 README、一份 CHANGELOG、一个 Git commit history，新接手的人要花半天时间读代码才能进入状态。但WorkBuddy只需要几秒钟。
而且它不只是"记得上次做了什么"，它还记得上次为什么这么做。比如第一次对话里我提供了腾讯地图的 API Key，WorkBuddy把它作为默认值写进了代码。后续对话里它从来没有问过我"Key 是什么"，因为记忆里已经有了。
这让我意识到一件事：WorkBuddy的开发记忆不只是一份日志，它更像是一个项目经验的沉淀机制。每次对话的决策、试错、方案选择都被记录下来，形成了一个累积的知识库。对话越多，WorkBuddy对这个项目的理解就越深。

---

技术细节：WorkBuddy帮我做了哪些事

事后我整理了一下，这个项目里有几个技术决策是我自己完全不会做的。我把它们列出来，一方面是给同样在学编程的朋友参考，另一方面也是想说明：龙虾的厉害之处不在于"能写代码"，而在于"知道该写什么代码"。

1. JSONP 跨域方案

腾讯位置 WebService API 不支持 CORS（跨域资源共享），这意味着在纯前端环境下，你用标准的 fetch() 或 XMLHttpRequest 去调接口，浏览器会直接拦截。
这是一个经典的"前端调接口"难题。常见的解决方案有：

• 搭一个 Node.js/Python 后端做代理（但这引入了服务器成本和运维负担）
• 用 Nginx 反向代理（但需要部署 Nginx）
• 让腾讯开放 CORS（但你只是一个 demo 开发者，没有这个权限）

WorkBuddy选了第四种方案：JSONP（JSON with Padding）。

function jsonp(url, callbackName) {
  return new Promise((resolve) => {
    window[callbackName] = resolve;
    const script = document.createElement('script');
    script.src = `${url}&output=jsonp&callback=${callbackName}`;
    document.body.appendChild(script);
    script.onload = () => script.remove();
  });
}

原理很简单：浏览器不会拦截 <script> 标签的跨域请求。所以把 API 调用包装成一个 JS 文件的 URL，服务端返回的不是 JSON 数据而是一段 JS 代码（调用你指定的回调函数），这样数据就"绕过"了跨域限制。
这不是什么冷僻知识，任何一个有经验的前端工程师都知道。但如果我自己来，我大概会绕一大圈，最后放弃说"需要后端"。WorkBuddy直接选了最合适的方案，而且用 Promise 包了一层，让异步调用可以 await，代码可读性极好。

2. Haversine 算法离线测距

距离测量功能是我自己提出来的，但我没有想过实现细节。WorkBuddy的选择让我眼前一亮：它完全不调用 API，用纯数学公式在前端计算两点之间的球面距离。

function haversine(p1, p2) {
  const R = 6371000; // 地球平均半径，单位：米
  const φ1 = p1.lat * Math.PI / 180;
  const φ2 = p2.lat * Math.PI / 180;
  const Δφ = (p2.lat - p1.lat) * Math.PI / 180;
  const Δλ = (p2.lng - p1.lng) * Math.PI / 180;
  const a = Math.sin(Δφ/2)**2 + Math.cos(φ1)*Math.cos(φ2)*Math.sin(Δλ/2)**2;
  return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a));
}

Haversine 公式是用来计算球面上两点之间最短距离（大圆距离）的经典算法，以地球半径 6371 公里为基准。精度误差小于 0.5%，完全满足日常使用。
更重要的是这个方案的设计意图：离线计算意味着零延迟、零 API 调用成本、即使没有网络也能用。 WorkBuddy甚至在这个基础上自动换算出了步行和驾车的预估时间——按 5km/h 步行和 40km/h 城市驾车速度估算。
这种"不调 API、用本地算法"的决策，是WorkBuddy在权衡了"响应速度"和"功能完整性"之后主动做的选择。我没有提过"离线"这个词，但它认为这个功能应该离线工作。

3. 动态 SVG 图标

所有地图标注（搜索结果编号、我的位置、测量点）都是动态生成的 SVG，不依赖任何图片资源：

const svg = `<svg xmlns="http://www.w3.org/2000/svg" width="28" height="36">
  <path d="M14 0C6.3 0 0 6.3 0 14c0 9.8 14 22 14 22S28 23.8 28 14C28 6.3 21.7 0 14 0z" fill="${color}"/>
  <text x="14" y="18" text-anchor="middle" fill="white" font-size="11" font-weight="bold">${label}</text>
</svg>`;

这意味着搜索结果可以有 1-20 的编号标记，每个颜色不同（红、蓝、绿、紫），我的位置是绿色脉冲圆点，测量点是橙色标记——全部通过变量动态控制，零图片文件、零网络请求。
这个细节我自己绝对不会想到。我大概率会用 PNG 图标，或者干脆不编号。

我的 Prompt 工作流与 Skill 使用心得

很多人问我：“你和WorkBuddy对话的时候，是怎么描述需求的？需要写很专业的 Prompt 吗？”
答案是：不需要。我的 Prompt 都是大白话。
整个 mcp-geo 项目从立项到 v2.0，我大概用了这些 Prompt：

第一轮（创建项目）：
"帮我做一个腾讯地图的 demo，可以搜索地址、点击地图解析坐标、做路线规划。"

第二轮（接入真实 Key）：
"我把腾讯地图的 API Key 给你，替换成我自己的，Key 是 PPVBZ-xxxxx。"

第三轮（功能扩展）：
"继续丰富扩展设计本项目的实用功能，完成开发并撰写技术报告文档。"

第四轮（持续迭代）：
"能不能加一个我的位置功能，用 GPS 定位我在哪？"
"我想搜附近的餐厅、医院什么的，做个分类快捷入口"
"加个测距功能，我想量两个地点之间的距离"

第五轮（部署上线）：
"怎么让别人也能访问？"

你会发现几个规律：第一，我没有用任何结构化格式（没有 Markdown 列表、没有 JSON schema、没有"请你以 xxx 的身份"）；第二，我的需求是渐进式的，从一个模糊的大方向逐步细化到具体功能；第三，每次只有一个核心诉求，不堆砌。
这其实是我用 WorkBuddy 以来总结出的 Prompt 策略——说人话，一次一件事，让WorkBuddy自己判断该做什么。
如果你把十个需求塞进一条消息里发出去，WorkBuddy当然也能处理，但它的注意力会被分散，每个功能的完成度可能就不如逐个推进。而如果你一次只提一件事，它会在这个功能上"深挖"，把所有相关的边界条件、交互细节、异常处理都考虑到位。

Craft / Plan / Ask 三模式的使用

WorkBuddy 有三种工作模式：Craft（你说我做）、Plan（先想后做）、Ask（只说不做）。在 mcp-geo 开发中，我几乎全程使用 Craft 模式——直接让WorkBuddy动手，不要求它先出方案。
这不是偷懒，而是一种信任迭代的策略。Craft 模式下会立即执行，如果有问题我再在下一轮指正。这比先看方案再审批要快得多——毕竟我的代码评审能力有限，与其花时间看方案，不如直接看结果。
唯一用到 Plan 模式的时候是 v2.0 大版本升级，当时我需要一次性增加五个功能模块。先列出了一个 TODO 清单，把五个功能按依赖关系排了优先级（先做"我的位置"，因为"附近搜索"依赖它），确认后才开始逐个实现。这种时候 Plan 模式确实更合理——功能太多，直接开干容易遗漏。
Ask 模式我用得比较少，主要是用来验证一些技术假设，比如"腾讯地图 WebService API 支持跨域吗"这种我拿不准的问题。

Skill 机制：WorkBuddy的"外挂"

WorkBuddy 的 Skill 机制是龙虾能力的核心放大器。你可以把它理解为龙虾的"技能包"——默认状态下龙虾是一个通才，加载了特定 Skill 之后它就变成了那个领域的专家。
在 mcp-geo 项目里，WorkBuddy用到了两个关键的 Skill/工具链：
第一个是 EdgeOne Pages MCP 工具。 这不是一个用户可见的 Skill 名称，而是龙虾内置的 MCP（Model Context Protocol）集成。它让WorkBuddy可以直接调用腾讯云 EdgeOne Pages 的部署接口，把 HTML 文件上传到全球 CDN 网络。没有这个工具，我需要手动登录腾讯云控制台、创建项目、上传文件、配置域名——一套流程下来至少 20 分钟，而且每次更新都要重复。
第二个是WorkBuddy的代码搜索与文件操作能力。 它可以直接读写我工作区里的文件，搜索代码中的特定模式，批量修改。这意味着当我说"在路线规划的起点旁边加一个’使用我的位置’的按钮"时，不需要我把整个 HTML 代码贴给它——它自己会打开文件、定位到路线规划模块、插入按钮代码、保存文件。这种能力让我在迭代时完全不用关心"文件在哪里"、“代码怎么找"这类琐碎问题。
我还注意到一个自动触发 Skill 的机制。当我的需求涉及到特定领域时（比如金融数据查询），它会自动加载对应的 Skill，不需要我手动指定。虽然 mcp-geo 项目没有用到这些领域 Skill，但这个设计思路让我很欣赏——它意味着WorkBuddy的能力边界是可以无限扩展的，每加一个 Skill，就多了一种"超能力”。

---

服务器与部署：我为什么选择 EdgeOne Pages

聊到部署，我想多说几句。因为服务器选择这件事，其实也是WorkBuddy帮我做的决策。
最初我对部署的认知停留在"买个云服务器，装 Nginx，把文件扔上去"这个层面。我甚至想过要不要用我已有的腾讯云账号开一台轻量服务器。但WorkBuddy评估了 mcp-geo 的技术特征后，直接推荐了 EdgeOne Pages。
它的判断依据很简单，但我自己完全没想到：
mcp-geo 是一个纯前端项目，不需要服务器端运算。 所有地图渲染在用户浏览器里完成，所有 API 调用从用户浏览器直接发往腾讯服务器（通过 JSONP）。整个项目就是一个 HTML 文件加一个地图 SDK 的 CDN 引用。
这种项目的最佳部署方案不是"服务器"而是"CDN 分发"——把文件放到离用户最近的节点，让用户直接下载运行。
EdgeOne Pages 正好满足这个需求。它是腾讯云旗下的静态站点托管服务，几个特点：

• 零配置部署：通过 MCP 工具一键上传，不需要 SSH、不需要 FTP、不需要 git push
• 全球 CDN：文件自动分发到全球边缘节点，国内用户访问延迟在几十毫秒以内
• 自动 HTTPS：不需要单独申请证书，部署即加密
• 免费额度：个人项目和 demo 完全够用
• 秒级更新：改了代码重新部署一次，CDN 节点几秒内生效

WorkBuddy帮我算了一笔账：如果我用传统的云服务器方案（CVM + Nginx + 域名备案），从开始到上线至少需要3-4天。而 EdgeOne Pages 方案，从部署到上线只需要 15 秒，成本为零。对话式开发带来的不只是开发效率的提升，而是整个交付链条的压缩。

最终成果

MCP Geo v2.0，功能一览：

模块	功能描述
🔍 地址搜索	关键词 + 城市限定，地图标注编号，支持批量结果展示
🏪 附近搜索	9 大分类快捷入口，自定义 500m~5km 搜索半径
📍 坐标解析	双向（坐标↔地址），附近 POI 自动显示
🗺️ 路线规划	驾车/步行/骑行三种方式，地图绘制完整轨迹
📏 距离测量	多点测量模式，Haversine 球面算法，离线计算
🕘 历史记录	自动保存近 20 条坐标，localStorage 持久化
🧭 我的位置	GPS 实时定位，精度显示，联动其他模块
🌙 地图样式	标准 / 🛰️ 卫星 / 🌙 夜间三种底图一键切换

部署方式：EdgeOne Pages（全球 CDN，HTTPS，零运维）

写在最后

我不打算在这里说"AI 会取代程序员"之类的话，因为那不是我的感受。
我的感受是：有了WorkBuddy，我这个编程初学者，也能做出超出自己能力边界的东西。
不是因为我变聪明了，而是因为WorkBuddy龙虾帮我补上了那些我缺失的部分——不只是代码，还有判断：用哪个方案、避哪个坑、怎么设计交互细节、怎么写文档、怎么部署上线。这些判断原本是资深工程师的直觉，现在WorkBuddy替我做了。
但我也不想说"人人都能用 AI 做产品"。说实话，如果我对地图 API 一无所知、对 Web 开发完全没有概念，我大概也提不出那些需求。WorkBuddy擅长的是放大你的能力，而不是替代你的思考。
换句话说，你得知道自己想要什么——WorkBuddy负责帮你做到。