35岁还在一线写代码的老程序员：技术探索与实践踩坑记录
上周五晚上十一点半，天通苑出租屋的窗外下着小雨，我刚把最后一行代码 push 到 GitLab，顺手关掉 MacBook 的屏幕。老婆在隔壁房间已经睡着了，房租3500一个月的房子隔音很差，但至少离回龙观地铁站近，通勤还能忍。我泡了杯速溶咖啡——不是为了提神，而是习惯性地想给自己一个“今晚又干了点正事”的心理安慰。
就在三天前，我差点被公司优化。
事情得从上个月说起。我们组接了个新项目，要用到大模型能力做智能客服系统。老板在周会上说：“现在谁不用 AI，谁就被淘汰。”语气里透着一股互联网中年焦虑。我心想，说得对，可你倒是给我配个 GPU 啊？我们开发机还是三年前的 Dell 台式机，跑个 Docker 都卡得像在放 PPT。
踩坑起点：Kimi + MCP 的组合拳
项目技术选型时，我提议试试 Kimi。原因很简单：它支持超长上下文（128K），而且免费额度够用。更重要的是，它不像某些国产大模型那样动不动就“内容安全策略限制”，连“登录”两个字都敏感。我们打算用它来解析用户历史对话，提取意图，再结合我们自研的 MCP（Multi-Context Processor，多上下文处理器）模块做路由分发。
MCP 是我自己折腾出来的小工具，核心逻辑是：当用户问题涉及多个业务域（比如既问账单又问物流），就拆成子任务，分别调用对应服务，最后聚合结果。听起来很 fancy，但实际一跑就崩。
第一次测试是在上个月15号下午。我写了个脚本，模拟 100 个并发请求，结果不到 30 秒，Kimi 的 API 返回 429 Too Many Requests。我懵了——文档里明明写着免费用户每分钟 60 次调用。后来翻 GitHub issues 才发现，有人提到“实际限流比文档严格得多，尤其是中文长文本”。
更糟的是，MCP 在处理 Kimi 返回的 JSON 时，因为没加异常兜底，直接抛出 KeyError: 'choices'，整个服务雪崩。运维同事在群里@我：“哥，线上告警了，用户进线全挂了。”
那一刻，我坐在工位上，手心冒汗。不是怕背锅，是怕被贴上“35岁还搞不定基础稳定性”的标签。你知道的，在北京，这个年纪要是被裁，下一份工作可能就得降薪到 18k，而我现在房贷+房租+孩子奶粉，每月固定支出 1.2w。
工具链的救赎：从裸奔到有盔甲
痛定思痛，我决定给这套流程加“盔甲”。首先，我用 Redis 做了两级缓存：一级缓存用户最近三次对话摘要（避免重复调用 Kimi），二级缓存常见问题的标准答案（比如“怎么退货”这种高频问题）。其次，我重写了 MCP 的错误处理逻辑，加了三层 fallback：
def safe_call_kimi(prompt):
try:
resp = kimi_client.chat.completions.create(
model="moonshot-v1-8k",
messages=[{"role": "user", "content": prompt}]
)
return resp.choices[0].message.content
except RateLimitError:
logger.warning("Kimi rate limit hit, using fallback LLM")
return call_fallback_llm(prompt) # 切换到本地 TinyLLM
except Exception as e:
logger.error(f"Kimi call failed: {e}")
return "抱歉，系统暂时无法理解您的问题，请稍后再试"
最关键的是，我引入了一个叫 RateLimiter 的小工具——其实就是一个基于令牌桶算法的装饰器，配合 asyncio 实现异步限流。代码不到 50 行，但效果立竿见影。现在即使突发流量，系统也不会直接跪了。
有意思的是，这个工具后来被隔壁组拿去用了。他们老大在茶水间碰到我，笑着说：“老张，你这工具不错啊，省了我们两周开发时间。”我嘴上说“小事小事”，心里却有点酸——如果早点系统化自己的工具库，是不是就不会总在救火？
面试题挑战：被年轻人反向教育
上个月底，我参加了公司内部的“技术分享会”，主题是“AI 工程化落地实践”。我讲完 Kimi + MCP 的优化方案后，有个刚毕业的实习生举手问：“为什么不直接用 LangChain？”
我愣了一下。说实话，我看过 LangChain 文档，觉得太重了，光依赖就三十多个。对我们这种小团队，引入一个重型框架风险太大。但那小伙子接着说：“其实 LangChain 最近出了轻量版，而且内置了 rate limiting 和 fallback 机制……”
我当场脸有点热。回家后我立刻试了，发现他说得对。LangChain 的 fallbacks 参数可以直接配置多个 LLM 提供商，自动切换。我花了一晚上把 MCP 重构进去，代码量减少了 40%，稳定性反而更高。
这件事让我意识到：35 岁不是经验的终点，而是学习方式的转折点。以前我总觉得自己“见得多”，但现在发现，很多新工具、新范式，年轻人比我们更敏感。与其固守“老子当年手写 ORM”，不如放下身段，承认“这玩意确实比我造的轮子好”。
真实的焦虑与微小的希望
说不焦虑是假的。去年十月，我面试过一家 startup，终面时 HR 问我：“你 35 了，能接受 996 吗？”我说：“能，但得看值不值。”她笑了笑，说：“我们更倾向 28 岁以下的候选人，体力好，薪资预期低。”那天走出中关村 SOHO，我在路边吃了碗 18 块的牛肉面，汤很咸，但没敢加醋——怕眼泪掉进去。
但也不是没有光。上个月，我把 MCP + Kimi 的整套方案整理成开源项目，发到 GitHub。没想到 Star 数一周破了 500，还有人 PR 修复了几个边界 case。最让我感动的是，有个 comment 写着：“感谢老哥，我们小团队终于能低成本接入大模型了。”
那一刻，我突然觉得，技术人的价值，不在于年龄，而在于能不能把复杂问题简单化，把坑填平，让后来者少摔一跤。
给同行的几点建议
结合这次踩坑，我总结了几点血泪经验，送给和我一样还在一线挣扎的兄弟们：
- 别迷信“免费”：Kimi 免费，但隐性成本（调试、兜底、监控）可能远超商用 API。算总账，别只看调用价格。
- 工具要“小而美”：自己造轮子没问题，但一定要考虑可维护性。MCP 之所以能活下来，是因为它只做一件事，且接口清晰。
- 面试题是镜子：别把面试题当考试，把它当学习机会。那个实习生的问题，让我重新审视了自己的技术偏见。
- 35 岁的优势是“稳”：年轻人冲得快，但我们知道哪里会塌方。把这种“预判风险”的能力产品化，就是你的护城河。
最后：写给未来的自己
写这篇文章时，已经是凌晨一点。窗外雨停了，只有空调外机嗡嗡作响。我打开招聘软件，看到一条新消息：“贵司 MCP 方案很赞，有兴趣聊聊架构师岗位吗？月薪 28k 起。”
我没立刻回复。不是不心动，而是想清楚：下一份工作，我要带工具去，而不是只带简历。
技术探索从来不是一帆风顺的。踩坑、填坑、再踩新坑，这就是我们这些老程序员的日常。但只要还能写出一行让别人受益的代码，我就觉得，这 35 岁，值了。
共勉。
评论 0