先坦白：我真不是什么技术达人——光看文章标题里"全球最差程序员"这个称号，你大概也感受到了。但我愿意把这当作某种人格魅力，就像科技圈里的小天真——不算精通，但真诚又好奇。正如我的编辑 Ryan Donovan 所说："你不怕问那些简单的问题。" 说白了，Ryan 是在用一种委婉的方式说我"不怕问蠢问题"。而他没说错——我确实不怕。类似这样的：
- Node.js 到底是干嘛的？
- 前端和后端开发有什么区别？
- 怎么把文件上传到 GitHub？
- 等下，你帮我确认一下我到底上传成功没有？
- 怎么把我写的代码分享给你审核&查验？
好在 AI 如今已经非常擅长回答这类问题，像我这样好奇心旺盛的人能快速得到解答。实际上，AI 大大降低了科技领域各种事物的入门门槛——不只是知识层面。哪怕是零编程经验的人，也能在几小时内 vibe-code 出一个能跑的应用，就像我一样。
对于我这样的科技小白来说，这意味着曾经完全触不可及的可能性如今近在咫尺。正所谓"世界是我的软件牡蛎"。然而，我这个人吧，创意能力实在堪忧（比如之前 vibe-code 的那个"便便追踪"应用），而且对 AI 工具有点挑剔。迟迟不愿拥抱 AI 或许让我损失了一些生产力，但说真的，我只是不想让脑子变成浆糊——好吧，比现在更浆糊一点。
即便如此，我相信 AI 能帮上忙的地方一大堆，包括帮我打造定制化的专属 AI。既然我自己不擅长产生有用的点子，又因为缺乏技术经验导致对软件的想象空间极为有限，那我干脆请 Gemini 帮我出主意，看有什么值得一做的东西。
遗憾的是，Gemini 也没能充当什么创意大师——它给我列出的一些概念简直莫名其妙。当时我真想大喊"看吧，我就说 AI 不靠谱"，但还是忍住了。
回到起点。我开始认真琢磨：定制 AI 智能体究竟能在哪些事情上帮到我？那些我一直想做却因为太忙、太缺乏经验、太没信心或太懒而搁置的事情是什么？
然后灵光乍现：Stack Internal Leaderboard（排行榜）。
先交代一下背景。如果你不了解 Stack Internal ，这是我们公司推出的企业知识管理产品。保留了 Stack Overflow 广受好评的知识分享机制，同时确保商业机密不会泄露到外部。企业用它来存储和验证组织内部信息——从休假政策到编码规范无所不包。各团队可以向其他部门记录和分享重要上下文，员工则可以提问或查找关于公司动态的问题和答案。用户可以对答案进行采纳、投票和评论，让最有价值的内容浮到顶部。这就是所谓的人类验证机制。
既然 AI 智能体已经无处不在，积累在企业 Stack Internal 中的知识便有了新的用武之地。企业可以通过 Stack Internal MCP 服务器 将其知识库与 AI 智能体连接起来。
这可不是 Stack Internal 的软广。我们公司上下都在用 Stack Internal，而每周声誉积分排行最高的人会在 CEO Prashanth Chandrasekar 的每周邮件中获得亮相机会。这就是"The Leaderboard"。我第一次注意到这个排行榜，是替一位休假中的 Stack 同事代班——他让我帮忙拉取每周的排行榜数据。第一眼望去，我只认识其中少数几个名字，而且都是曾与我共事过的人。但随着时间推移，我认得的名字越来越多。看到那些反复出现的名字，我愈发好奇，于是会在 Slack 上查找他们的信息，或者点击他们的 Stack Internal 个人主页，阅读那些让他们稳坐排行榜的问答内容。
我开始想：这算是 Stack 达人的一种名望吗？
在这一年里，我在 Stack Internal 上从未发布过一条问题或答案，只是偶尔更新一些已有 Q&A 的最新信息。整整 365 天就这么浪费了！我把自己辛苦积累的声誉积分拱手让给了前辈们的帖子，等于是在给别人打工的同时遮蔽了自己的光芒。但这种日子到头了。我要冲击排行榜，杀进 Prashanth 的每周邮件。我的名字将被全体 Stacker 看到并记住。如果我创建一个连接 Stack Internal MCP 服务器的 AI 智能体，每周 CEO 邮件中的位置——以及随之而来的应有荣耀——就在几个精心设计的提示词之外向我招手。但首先，我得搞清楚一件事……
MCP 服务器到底是个啥？
尽管这个问题上网一搜就能找到答案，但我总觉得浪费我"无畏问蠢"的天赋有点可惜。为此，我跑去骚扰了好友 Ben Marconi——他是 Stack 的生态系统战略总监。我带着明确目标开始了这通电话：尽可能多地了解 MCP，这样我就能打造出完美的排行榜冲击智能体。
我对 Ben 有一肚子问题。说实话，打这通电话前我在这方面几乎一无所知。稍后我会在博客上分享完整采访内容（敬请期待），这里先让我把学到的东西总结给你。首先，我笨拙地问了 Ben："呃，MCP 服务器到底是什么？" Ben 人很好也很有耐心，他给了我以下解释：
MCP 的核心价值：让 AI 与外部工具「无缝对话」
MCP（Model Context Protocol，即「模型上下文协议」）本质上是一个 AI 标准，它让大语言模型能够安全地连接外部数据源。用 Ben 的话说，这就像一座「标准化桥梁」——一端连接前沿 AI 能力，另一端连接软件世界中已有的各种工具。这样做的目的很简单：让 AI 代理更实用、更高效。要实现这一点，AI 需要访问外部信息源，甚至需要获得代表用户在这些系统中执行操作的权限。
传统方式的困境：每个 API 都要「定制开窗」
过去，如果想让大语言模型访问外部信息或执行任务，开发者必须为 AI 逐一构建定制连接器——本质上是一个代码接入点，对接外部公司的 API。Ben 用了一个生动的比喻：「你可以把 API 想象成餐厅与厨房之间的窗户。信息以代码形式通过窗户传递，然后在另一侧被结构化。两个系统之间可以反复重复这个过程。」 问题在于，每个 API 都可能有自己的配置方式，兼容性参差不齐。假设有产品 A、B、C，来自三家不同公司，各自有不同的 API。当你想把它们全部接入一个更高层的工具（比如某个 AI 代理）时，传统的做法是为每个 API 单独编写定制代码，以理解其接口规范并进行双向通信。这种工作在大规模场景下变得极其复杂——需要手动为成百甚至上千个工具分别构建连接器，才能让 AI 代理用上我们日常依赖的整套工具。
MCP 的解决思路：统一「翻译层」
MCP 的做法是在现有 API 之上架设一层标准化抽象。它接收来自各个 API 的外部数据，将其统一整理为 AI 代理能够自动理解的格式，从而实现与外部工具和数据源的快速连接。换句话说，不再需要为每个 API 单独打造连接器，而是把所有 API 接入一个「通用翻译器」——MCP 服务器。这样一来，用极少的配置工作就能让大语言模型连接任意外部数据源，获取真正有用的上下文信息。
Ben 强调，MCP 是 Anthropic 在几年前才推出的新标准，但仍被他称为「相对优雅的解决方案」，业界对它的兴奋不无道理。「我们需要一种更高效的方式，向代理层供给上下文，」Ben 指出，「一种有望让代理之间互相共享信息的方案。这样就能把过去需要人类知识工作者完成的定制配置工作卸载掉。」他补充道：「整个理念是，为使用这些新工具打造一个更具可扩展性的未来。」
编程之难：逻辑不是我的强项
编程需要逻辑和规则。一旦弄清楚什么逻辑导致什么结果、需要遵循什么规则，代码读起来几乎像看书一样。但问题在于——编程真的很难。
我并不是一个特别有逻辑思维的人，也没有学语言的天赋。为了记住几个简单的代码块，我花了大量时间学习和练习。哪怕给自己布置了课外作业，整个过程也只能说"还算有趣"。
然而，手头所有的变量、字符串和 text.uppers 并不足以让我独立写出自己的编码代理。我那些磕磕绊绊的 Python 尝试，反而更确认了一件事：真正有用的软件开发，需要逻辑、架构和远见——而这些恰恰是我不具备的。14 小时的 Udemy 课程终究无法替代计算机科学学位，更别说多年的开发经验了。
AI 介入：初学者的挫败与惊喜
作为"世界上最差的程序员"最有意思的地方在于，作为新手能收获大量"哇哦！"的成就感。但 AI 编码助手出现后，这类时刻少了很多。每次挣扎着让三行代码跑起来时，我都会眼巴巴地看着编辑器里的 Claude Code 按钮。即使代码跑通了，成功的喜悦也被焦躁冲淡——因为我知道，CLI 里就有个现成的解决方案。说白了，在"不需要真正学编程"的时代学着编程，这就是现实。
最后，我大概花了 20 分钟让 Claude Code 帮我构建了 Leaderboard agent。当然过程中有不少调试，但先说最酷的部分：我竟然能读懂 Claude Code 写的部分代码。
这就是我的"哇哦！"时刻。虽然 Cher Hin Chong 是位出色的讲师，但我真没想到学过的 Python 知识还真留下了些什么。当 Claude Code 生成了 Stack Internal Leaderboard 所需的全部代码时，我居然能理解。不是全部——毕竟是入门课——但基本架构我能看明白。我能看出循环在哪里、为什么断裂，能追踪条件判断的大致含义，能解读特定代码块的目的。对一个几年前连 Python 是什么都不知道的人来说，这太令人激动了。突然之间，我看到的不是一堆乱七八糟的单词和括号，而是一个故事。代码里有情节、有主题、有起伏，甚至有高潮和尾声。
这让调试和运行 agent 变得格外有意思。Claude Code 做重活，我则阅读它的思考过程，尽量跟上它的编辑和建议。大多数时候我都在迷路，但每当理解了一处需要修复的地方，都会感到一丝自豪。说不定有一天，我真能成为"世界上最一般的程序员"。
在本地跑起来：一连串意外
有了代码不等于代码能跑，尤其是用 vibe coding 写出来的。我的第一个任务是搞清楚怎么在浏览器本地运行，看看实际效果是否符合预期。这一跑起来就触发了一连串事件：安装 Streamlit、求 IT 审批 Python 3.14 下载、第一次用 API key、不小心把 API key 暴露给了 Gemini、被 Gemini 骂蠢货、求 IT 帮我重连 Claude Code（怕 Gemini 再骂我）、终于在 localhost 上跑起来了。
Caption: 哪个更可怕：Claude Code 抛弃我，还是 Gemini 骂我？
中间遇到了各种小 bug。我花了大量时间哄 Claude Code 把东西调对，才能按我的预期运行。承认吧，有些问题确实是水平问题（参见：前文提到的 API key 事件）。但当它真正跑起来的那一刻，真是大饱眼福。
我的 agent 做到了我期望的一切。它不仅能快速精准地搜索和发现内容，还能帮我挖掘趋势、找出现有问答库的空白、推荐发帖选题、检查重复问题、对草稿问答进行相关性评分和点赞概率预测，甚至能替我撰写和编辑问答内容，并代我发布。
内部测试：自我约束的两天实验
agent 跑通后，我给 Ben 和 Johno Hawkinson（负责 MCP 服务器的产品经理）做了演示。这个项目最酷的地方之一，就是给产品团队"吃自己的狗粮"。我还顺便给 Johno 提了几条改进 MCP 服务器的意见。在演示过程中，我隐约看到了两人眼中的骄傲。
Ben 给我的建议是："尽管放手去用。"他和 Johno 都希望我把 Leaderboard agent 用到极致，包括通过双向服务器让它替我发帖。于是我放手干了。
在为期两天的短暂实验中，我写了 5 个问题、1 个答案。数量不多是有原因的——我给自己定了严格规则：
- 不会在 Stack Internal 实例上刷帖或制造垃圾内容，尊重产品和其中的宝贵知识。
- 只提与自己相关的问题，只分享自己真正懂的答案。
- 严格保密，只告诉少数信任的人——Ben、Johno、Ryan 和博客作者 Eira——看看在不知情的 Stacker 眼里，我的 AI 使用是否明显。
从担忧到惊喜：AI 搭档带来的意外收获
在用极少的时间和精力取得大量发帖成果之后，我一直在思考一个潜在的风险：我会不会因此变得更懒，对 Stack Internal 和同事们的内容失去关注，把阅读和总结的工作全交给 AI 代劳？更让我不安的是，用自己的名字发布 AI 撰写的内容，我会不会因此丧失对文章的所有感和责任感？作为一个以写作为生的人，后者尤其让我感到不快。
然而，这些担忧完全是多余的。实际情况恰恰相反——我现在比以前更频繁地刷 Stack Internal，主动寻找可以回答的问题，并痴迷地追踪自己的声望得分。更重要的是，AI 助手提升了我发帖的精准度和清晰度，让我更有信心以更真实的风格表达观点。一位同事 Ryan 在读了我的一篇帖子后评价道："我就喜欢这种开放场域里的尖锐提问。"
登顶 Leaderboard：意外之喜
我不仅登上了 Stack Internal Leaderboard，而且一路冲到了 第一名。
坦白说，我为自己感到非常骄傲。看看那个榜单——我居然在榜首！
除了这份"绝对霸主"的成就感之外，这次项目还给我带来了一种更加特殊而意料之外的自豪感。这是一种我只在最珍视、最个人化的写作作品上才会体验到的骄傲——仿佛我为自己创造了一件真正美妙的东西。
我从未想过，为自己打造一个简单的小工具、帮助达成目标，竟会如此令人愉悦。这就像在对自己说"独行太危险，带上这个吧"的同时，也送给了自己一份小小的礼物。尽管这个项目除了挑战自我（以及获得第一名的吹牛权利）之外没有什么实际意义，但它让我看到了软件开发的不同侧面——一种在精神上更接近我毕生所从事的创意工艺的形态。这难道不酷吗？
在我向 Ben 和 Johno 演示了我的 AI 助手之后，Ben 停顿了一下说道："Phoebe，我觉得你并不是'世界上最差的程序员'。"我笑着摇头，但他继续说道："看看你做出来了什么。你应该感到骄傲！别看轻自己……你看起来已经挺会写代码了。" 我个人认为自己离"世界上最差的程序员"还很远（哈哈），不过现在这似乎也没那么重要了。我为自己创造的东西感到骄傲，也为由它带来的成果感到自豪。就算我真的是"世界上最差的程序员"……嘿，至少我还是 Stack Internal 的第一名。
评论