聊聊我为什么总在下班后折腾那些"没用"的新技术

一键启动人生

2026-07-03 03:05

阅读 545

一个刚入职两个月、白天写CRUD、晚上玩AI编程工具的前端打工人的碎碎念

先说点背景

入职新公司刚好两个月，工位上的绿萝都还没养死，我已经把团队的代码仓库翻了个底朝天。

说实话，这家公司技术栈还算稳定，React + Node.js + MySQL 的老三样，没什么特别让人兴奋的东西。但我这人有个毛病——看到新东西不折腾一下就浑身难受。上周我在 Hacker News 上刷到 Claude Code 的早期体验申请链接，手一抖就提交了，没想到还真通过了。

现在我每天下班后的日常就是：打开 Mac 终端，敲 claude 命令，然后看着 AI 帮我在命令行里写代码、改 Bug、甚至重构祖传屎山。那种感觉怎么形容呢？就像你带了个不要工资的初级程序员，虽然偶尔会给你整出点幺蛾子，但大部分时候还是挺靠谱的。

今天这篇文章，其实是我上周五晚上加班到十一点半，在等 CI/CD 跑完的间隙，脑子里突然冒出来的一个想法：我们这帮程序员，到底为什么要花自己的时间去折腾那些看起来"没什么用"的新技术？

这篇文章不会给你列什么"技术探索的五大好处"、"实践出真知的三个步骤"这种八股文。我就想聊聊我自己的真实感受，聊聊我这段时间折腾 Claude Code、MCP、v0 这些东西的心路历程，顺便做个技术分享。

事情是这样的

上个月，我们组接了个内部效率工具的需求。产品经理（我们叫他老王吧）在周会上说："这个工具很简单，就是个表单配置平台，两周能上线吧？"

我当时心里就咯噔一下。根据我多年的经验，产品经理嘴里的"很简单"和"两周"，翻译成程序员语言大概是"很复杂"和"两个月"。但新入职嘛，不好怼回去，就硬着头皮接了。

结果一拆需求，好家伙，光是动态表单渲染那块就有二十多种字段类型，还要支持拖拽排序、条件显隐、数据联动。我估摸着两周肯定搞不定，但转念一想——这不正好是个试验田吗？

那段时间正好是 MCP（Model Context Protocol）刚火起来的时候。我之前在 Claude Code 里用过它的 MCP 集成，感觉这东西有点意思。简单说，MCP 就是让 AI 模型能以标准化的方式访问外部工具和数据源的一个协议。你可以把它理解为 AI 世界的"USB 接口"——不管什么工具，只要实现了 MCP 协议，AI 就能直接调用。

我当时脑子里冒出一个大胆的想法：能不能用 MCP 把我们的表单配置逻辑抽象成一套工具集，然后让 AI 直接通过 MCP 来生成表单配置 JSON？

说干就干。

MCP 初体验：理想很丰满

先简单说下 MCP 的核心概念。MCP 定义了三种原语：

原语	说明	类比
Tools	AI 可以调用的函数	后端 API
Resources	AI 可以读取的数据	数据库表
Prompts	预定义的提示词模板	快捷指令

我的思路是这样的：

把表单字段类型的定义、校验规则、联动逻辑这些封装成 MCP Tools
把已有的表单模板数据作为 MCP Resources 暴露出去
然后在 Claude Code 里通过 MCP 连接，让 AI 直接帮我生成配置

先看看 MCP Server 的核心代码长什么样：

// form-mcp-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "form-config-server",
  version: "1.0.0",
});

// 定义一个 Tool：获取所有可用的字段类型
server.tool(
  "list_field_types",
  "列出所有支持的表单字段类型及其配置参数",
  {},
  async () => {
    const fieldTypes = [
      {
        type: "input",
        label: "单行输入",
        props: ["placeholder", "maxLength", "required"],
      },
      {
        type: "select",
        label: "下拉选择",
        props: ["options", "multiple", "required", "remote"],
      },
      {
        type: "date_range",
        label: "日期范围",
        props: ["format", "disabledDate", "required"],
      },
      // ... 还有十几种，这里省略
    ];
    return {
      content: [{ type: "text", text: JSON.stringify(fieldTypes, null, 2) }],
    };
  }
);

// 定义一个 Tool：根据描述生成表单配置
server.tool(
  "generate_form_config",
  "根据自然语言描述生成表单配置 JSON",
  {
    description: z.string().describe("表单的自然语言描述"),
    template_id: z.string().optional().describe("可选的模板 ID"),
  },
  async ({ description, template_id }) => {
    // 这里调用我们内部的配置生成逻辑
    const config = await buildFormConfig(description, template_id);
    return {
      content: [{ type: "text", text: JSON.stringify(config, null, 2) }],
    };
  }
);

// 定义一个 Resource：暴露已有的表单模板
server.resource(
  "form-template",
  "form://templates/{template_id}",
  async (uri) => {
    const templateId = uri.path.split("/").pop();
    const template = await getTemplateFromDB(templateId);
    return {
      contents: [
        {
          uri: uri.href,
          text: JSON.stringify(template),
          mimeType: "application/json",
        },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

然后在 Claude Code 里配置 MCP 连接：

// .claude/mcp.json
{
  "mcpServers": {
    "form-config": {
      "command": "npx",
      "args": ["tsx", "src/form-mcp-server.ts"],
      "env": {
        "DB_HOST": "localhost",
        "DB_PORT": "3306"
      }
    }
  }
}

配好之后，我在 Claude Code 的终端里试了一下：

$ claude
> 帮我生成一个员工入职登记表，需要包含姓名、工号、
  部门（下拉选择）、入职日期、紧急联系人、
  其中部门需要远程搜索，入职日期不能选过去的日期

# Claude 会自动调用 list_field_types 和 generate_form_config
# 然后返回完整的表单配置 JSON

第一次跑通的时候，我真的在工位上差点叫出声来。 那种感觉就像——你写了一个机器人，然后它真的听懂了你的话，帮你把活干了。

但是，现实给了我一巴掌

兴奋了大概三天之后，问题开始暴露了。

第一个坑：上下文窗口爆炸。 我们的表单配置 JSON 结构其实挺复杂的，一个中等复杂度的表单配置就有 2000 多行。当 AI 需要同时理解字段定义、校验规则、联动逻辑的时候，context 很快就爆了。有一次我让 AI 改一个联动规则，它改着改着把前面的字段定义给忘了，直接给我生成了一段"幻觉"配置——字段类型是 super_select，这玩意儿压根不存在。

第二个坑：调试地狱。 MCP Server 是通过 stdio 通信的，出了问题你很难知道是 AI 的理解有误，还是 Tool 返回的数据不对，还是 Resource 读取失败。有一次我排查了整整一个下午，最后发现是 zod 的 schema 校验把一个可选参数给拦截了，报错信息还没打到 stdout 里。当时真的想砸电脑。

# 调试 MCP 的小技巧：加上 --verbose 参数
$ npx tsx src/form-mcp-server.ts --verbose 2>&1 | tee mcp-debug.log

# 或者用 MCP Inspector 来可视化调试
$ npx @modelcontextprotocol/inspector npx tsx src/form-mcp-server.ts

第三个坑：团队接受度。 我把这个方案在组内做了个技术分享，大家的反应基本是："哇，好酷"，然后——"但是线上能用吗？"、"AI 生成的配置谁来 review？"、"出了线上事故算谁的？"

说实话，这些问题我都答不上来。

退一步，换个思路

被现实教育之后，我冷静下来想了想。问题不在于 MCP 本身不好用，而在于我太想一步到位了。

我想要的终极形态是：AI 全自动生成表单配置 → 自动部署 → 自动上线。但现实是，这个链条上的每一环都有不确定性，串起来之后不确定性就指数级放大了。

于是我调整了策略：把 AI 当成"高级实习生"，而不是"自动驾驶"。

具体来说，我把整个流程拆成了几个阶段：

阶段	AI 做什么	人做什么
需求理解	解析产品需求，生成字段列表	确认字段是否完整
配置生成	根据字段列表生成初始 JSON	Review 并微调
校验检查	自动跑 schema 校验和逻辑检查	处理校验不通过的 case
预览确认	生成预览链接	在浏览器里确认效果

这个调整之后，体验好了很多。AI 不需要一次性理解所有东西，而是分步骤来，每一步都有人兜底。

顺便说一下，在这个过程中我还发现了 v0 这个工具。v0 是 Vercel 出的一个 AI UI 生成工具，可以根据描述直接生成 React 组件代码。虽然它生成的组件不能直接用（毕竟我们的设计系统和它默认的 Tailwind 风格差别挺大的），但用来快速出原型、和产品经理对齐 UI 预期，真的非常好使。

有一次老王又提了个"很简单"的需求，说想要个数据看板的 UI。我直接在 v0 里描述了一下，两分钟就出了个像模像样的原型。拿着这个原型去和老王对，他一看就说："对对对，就是这个感觉！"然后我拿着这个原型去写真实代码，效率比以前对着 Figma 稿子写快了不少。

这里有个小经验：v0 生成的代码不要直接用，但它生成的组件结构和样式思路可以参考。 我一般会把它生成的代码丢给 Claude Code，让它按照我们项目的组件规范重构一遍，这样省去了很多从零搭结构的时间。

说回正题：为什么要技术探索？

好了，铺垫了这么多，终于要说回这篇文章的主题了。

你可能会问：你一个刚入职两个月的新人，白天 CRULD 都写不完，晚上还折腾这些有的没的，图啥？

说实话，我也问过自己这个问题。特别是那次 MCP 调试到半夜，bug 还没解，第二天还要早起开站会的时候，我确实怀疑过人生。

但后来我想明白了几个事情：

第一，技术探索是抵抗"工具人化"的唯一方式。

这话听着有点夸张，但你仔细想想——如果我只做分内的需求，写写业务代码，跑跑测试，那我和 AI 有什么区别？甚至不如 AI，毕竟 AI 写 CRUD 比我快，还不要五险一金。

我见过一些工作五六年的同事，技术栈还是三年前那一套，每天重复着"接需求 → 写代码 → 提测 → 修 Bug"的循环。不是说这样不好，但如果行业发生变化——比如现在 AI 编程工具越来越强——他们的处境就会很被动。

第二，探索新技术能让你在"稳定"的工作中找到突破口。

我们公司的技术栈确实稳定，但这不代表没有优化空间。比如我折腾 MCP 这件事，虽然最后没有直接上线，但我把其中的一些思路用到了日常开发中——用 Claude Code 来辅助写单元测试、生成 API 文档、甚至帮忙 review 代码。这些小小的改进，积少成多，确实提升了我的工作效率。

上周我用 Claude Code 帮我把一个老模块的重构方案给梳理了出来。那个模块是两年前一个已经离职的同事写的，代码逻辑绕得像迷宫。我把代码丢给 Claude Code，让它分析依赖关系和调用链路，十分钟后它给我画了个清晰的调用图（虽然是文本版的），还指出了几个潜在的内存泄漏点。我自己看可能要看一天，它十分钟就搞定了。

第三，也是最重要的一点——折腾新技术真的很好玩。

我知道这个理由听起来很不"职业"，但事实就是这样。当我第一次在终端里通过 MCP 让 AI 成功生成表单配置的时候，那种兴奋感是真实的。当我用 v0 两分钟出个原型把产品经理唬住的时候，那种成就感也是真实的。

程序员这个职业，如果不是因为"好玩"，那真的很难坚持下去。你想想，我们每天面对的是一堆报错日志、需求变更、线上告警，如果工作之外没有一点让自己兴奋的东西，那得多枯燥。

给想折腾但又犹豫的同学几点建议

如果你也是那种看到新技术就心痒痒，但又怕"不务正业"的人，我有几点实操建议：

1. 用"二八法则"分配精力

80% 的时间做好本职工作，20% 的时间探索新技术。不要本末倒置，毕竟咱们是来赚钱的，不是来搞科研的。我一般利用通勤时间看技术文章，午休时间写 demo，晚上回家后再深入折腾。

2. 找到和工作的结合点

纯粹为了好玩而学习当然没问题，但如果能和工作结合起来就更好了。像我这次把 MCP 和表单配置结合，虽然没完全落地，但过程中的思考和对工具的理解，是实打实的收获。

3. 做技术分享，倒逼自己输出

这一点真的很重要。我为了准备组内的技术分享，把 MCP 的文档翻了好几遍，还画了架构图。这个过程中发现了很多之前没注意到的细节。教是最好的学，这话真不是随便说说的。

4. 接受"半途而废"

不是每次探索都会有结果。我折腾 MCP 这件事，最后并没有在生产环境中用起来，那这段时间白费了吗？并没有。我理解了 MCP 的设计思想，知道了它的优势和局限，这些认知本身就是价值。下次遇到类似的技术，我能更快地做出判断。

5. 命令行党福利：善用 CLI 工具

如果你也像我一样喜欢命令行，那现在真的是好时代。Claude Code 本身就是个 CLI 工具，MCP 的配置和调试也都在终端里完成。配合 tmux、zsh 这些老伙计，开发体验真的很丝滑。

# 我日常的工作流大概长这样
$ tmux new-session -s work
# 窗口 1: Claude Code
$ claude
# 窗口 2: 项目代码 + 热更新
$ npm run dev
# 窗口 3: git + 提交
$ lazygit

最后说两句

写这篇文章的时候，已经是凌晨一点了。CI/CD 终于跑完了，绿色的 ✅ 看着让人安心。

回头看看这两个月，我折腾了 Claude Code、MCP、v0，虽然没有什么惊天动地的成果，但确实让我对"AI 辅助编程"这件事有了更深入的理解。我不再是那个看到 AI 生成代码就无脑复制粘贴的人了，我知道了它的边界在哪里，知道了怎么和它协作效率最高。

可能有人会觉得，这些"探索"在 KPI 面前一文不值。但我觉得，一个程序员的长期竞争力，不在于他当前会什么技术，而在于他探索新技术的能力和意愿。

技术浪潮一波接一波，今天火的是 AI 编程，明天可能是别的什么。但那些保持好奇心、愿意动手折腾的人，永远不会被淘汰。

好了，不说了，我得去睡觉了。明天还要和老王对需求，估计他又会说"这个很简单"。

晚安，各位打工人。🌙

P.S. 如果你也对 MCP 感兴趣，可以看看我整理的一些资源链接。另外，Claude Code 的早期体验申请现在好像还在开放，感兴趣的可以去试试，命令行里用 AI 写代码的体验真的很上头。

P.P.S. 下次技术分享我准备聊聊怎么用 Claude Code 做代码审查，有兴趣的同学可以来听听，顺便帮我提提意见。

标签:MCPv0Devin技术分享

最热最新

暂无评论

为你推荐

暂无相关推荐