35岁还在写代码，聊聊我对技术探索的执念

成都的三月，天气终于暖和起来了。

上周五晚上九点半，我合上电脑，从公司楼下的全家买了个关东煮，边走边吃。路过天府三街的地铁口，看着成群结队下班的小伙子小姑娘，突然有点恍惚——十年前我也是这样，背着双肩包，脑子里还在想刚才那个Bug到底出在哪。

今年我35了。

在很多人眼里，这个年纪还在一线写代码，多少有点"不思进取"的意思。前两年同学聚会，当年一起进培训班的兄弟，有的去了管理层，有的转了销售，最夸张的一个去卖保险了，据说年薪比我高不少。我妈每次打电话也要念叨两句："儿子啊，你们公司那个什么架构师的位置，你到底去不去争一下嘛？"

争啥呢？我就喜欢写代码啊。

打开VSCode，看着左边那一排插件图标——ESLint、Prettier、GitLens、Todo Tree、Thunder Client、REST Client、Code Spell Checker、Bracket Pair Colorizer... 满满当当的，跟我的工具箱一样。有人说VSCode装太多插件会卡，我寻思着我这32G内存的机器，带得动。就像我这个人一样，啥都想学，啥都想试，脑子虽然不比二十岁的时候转得快了，但胜在底子厚。

今天想跟大家聊聊，我这十几年搞技术下来，对"技术探索与实践"这件事的一些看法。不是什么高屋建瓴的方法论，就是一个老码农的碎碎念，您凑合看。

---

从一次线上事故说起

去年双11期间，我们组负责的那个订单中台出了个P0级事故。

事情是这样的：大促开始后的第17分钟，监控突然报警，订单创建接口的RT从平时的50ms飙升到了2000ms+，紧接着数据库连接池被打满，整个服务开始雪崩。我当时在家里刚洗完澡准备刷会儿手机，看到钉钉消息弹出来，心里"咯噔"一下——完了。

赶紧打开电脑，连上VPN，一顿操作猛如虎。查日志、看监控、分析链路... 最后发现是一个同事新加的功能，在订单创建的链路里同步调用了一个第三方风控接口，而这个接口在大流量下响应极慢，直接把线程池耗尽了。

"你为啥不改成异步调用？"我在复盘会上问。

那个同事挠了挠头说："我... 我看文档上写的是同步调用，就没多想。"

这件事给我触动挺大的。不是说这个同事能力不行，他其实挺努力的，代码写得也算规范。问题出在哪呢？出在他对技术的理解停留在"会用"的层面，没有去想过"为什么"。同步调用在高并发下会有什么问题？线程池满了会怎样？服务降级的策略是什么？这些东西，文档上不会写，得靠自己去想、去探索。

我后来在组内分享的时候说了一句话："写代码谁都会，但写好代码，需要你对技术有敬畏心。"

---

技术探索，到底在探索什么？

很多人觉得"技术探索"就是追新——出了个新框架，赶紧学；出了个新语言，赶紧试。我不否认这也是一种探索，但我觉得这只是最表层的东西。

在我看来，技术探索至少包含三个层面：

第一层：知其然。 这个框架怎么用？这个API传什么参数？这个配置是什么意思？这是最基本的，也是大部分程序员日常在做的事。

第二层：知其所以然。 这个框架的底层原理是什么？为什么这么设计？跟同类框架比有什么优劣？到了这一层，你就开始有"技术判断力"了。

第三层：知其未尽然。 这个技术还能怎么用？有没有更好的方案？未来的发展方向是什么？能不能跟其他技术组合出新的玩法？这是最高层，也是真正拉开差距的地方。

拿我最近折腾的一个事来说。

今年年初，老板不知道从哪听了个AI的分享会，回来说我们也要搞AI赋能。得，任务就落到我们组了。一开始大家面面相觑，AI？我们一个做后台管理系统的，跟AI有啥关系？

后来我研究了一圈，发现其实能做的事情还挺多。比如我们的系统里有大量的表单配置、报表生成、数据查询的需求，这些其实都可以用AI来辅助。我花了大概两周时间，把市面上主流的几个AI平台都试了一遍，最后选了Coze来做一些初步的探索。

为啥选Coze？说实话，一开始我也犹豫过，毕竟市面上工具太多了。但Coze有几个点打动了我：一是它的Bot编排能力确实灵活，可以把多个插件和工作流串起来；二是它对国内生态的支持比较好，接个数据库、调个内部API什么的比较方便；三是上手门槛相对低，对于我们这种没有AI算法工程师的团队来说，能快速出活很重要。

我做的第一个Bot是用来辅助生成SQL的。我们后台有个自定义报表的功能，运营同学经常提需求说想查个什么什么数据，然后我们就得写SQL。很多时候其实就是简单的聚合查询，但运营同学不会写，我们写起来又觉得烦。我就用Coze搭了个Bot，把数据库的表结构信息喂给它，让它根据运营同学的自然语言描述生成SQL。

效果嘛，说实话没有想象中那么惊艳，但确实能解决一部分问题。大概60%的简单查询，它生成的SQL都能直接用或者稍微改改就能用。运营同学也挺高兴，说终于不用等我们排期了。

# Coze Bot 配置示例（简化版）
bot:
  name: "SQL助手"
  description: "根据自然语言描述生成MySQL查询语句"
  prompt: |
    你是一个专业的MySQL数据库专家。
    用户会用自然语言描述他们想查询的数据，
    你需要根据以下表结构生成对应的SQL语句。
    
    表结构信息：
    - orders: id, user_id, amount, status, created_at
    - users: id, name, phone, level, created_at
    - products: id, name, price, category, stock
    
    注意事项：
    1. 只生成SELECT语句
    2. 默认加上created_at的排序
    3. 如果涉及金额，保留两位小数
    
  plugins:
    - name: "knowledge_base"
      type: "dataset"
      config:
        dataset_id: "table_schema_v2"
        
  workflow:
    - step: "parse_intent"
      action: "llm_chat"
    - step: "generate_sql"  
      action: "llm_chat"
    - step: "validate_sql"
      action: "code_exec"
      config:
        language: "python"
        code: |
          import re
          sql = input_text
          # 简单的SQL安全检查
          dangerous_keywords = ['DROP', 'DELETE', 'UPDATE', 'INSERT', 'ALTER']
          for kw in dangerous_keywords:
              if kw in sql.upper():
                  raise ValueError(f"不允许的操作: {kw}")
          return sql

这个过程让我对"技术探索"有了更深的体会。探索不是闭门造车，你得带着问题去探索。我的问题就是"怎么让运营同学能自己查数据"，然后在这个问题的驱动下，我去了解了Coze、了解了Prompt Engineering、了解了RAG的基本原理。这些东西，如果让我干巴巴地去学，我可能看两篇文章就放弃了。但有了实际场景，学起来就特别有动力。

---

读书这件事，我坚持了十年

说到技术学习，就不得不提读书。

我有一个习惯，保持了很多年——每个月至少读一本技术书。不是那种翻翻目录、看看序言就算读过的，是真的从头到尾读完，还要做笔记、写总结。

我书桌上现在堆着一摞书，最近在读的是《Designing Data-Intensive Applications》（DDIA），这书我其实已经读了两遍了，但每次翻都有新的收获。旁边还有《Java并发编程的艺术》、《MySQL技术内幕：InnoDB存储引擎》、《Redis设计与实现》... 都是翻过很多遍的，书页都发黄了。

有人可能会说，现在技术更新这么快，看书来得及吗？网上那么多博客、视频、教程，看那些不就行了？

我的看法是，博客和视频适合学"术"，书籍适合学"道"。

博客文章，包括我自己写的这些，大多是在讲某个具体问题的解决方案，时效性强，但深度有限。你今天看了篇"Spring Boot 3.x新特性"的文章，可能过两年Spring Boot 4.x出来了，这篇文章就没啥价值了。但书籍不一样，好的技术书籍讲的是原理、是思想、是方法论，这些东西是不会过时的。

比如我读DDIA，里面讲的分布式系统的基本原理——副本、分区、事务、一致性... 这些东西，不管你是用MySQL还是PostgreSQL，用Kafka还是Pulsar，底层逻辑都是相通的。你把原理搞懂了，换什么技术栈都不怕。

再举个具体的例子。前几年微服务特别火的时候，我们团队也要搞微服务拆分。当时市面上有Spring Cloud、Dubbo、gRPC好多选择，大家争论不休。我就把之前读的《微服务架构设计模式》里的内容拿出来，对照着我们的业务场景，一条一条地分析。最后我们选了Spring Cloud Alibaba，不是因为它最好，而是因为它最适合我们当时的团队规模和技术储备。

如果当时我只是跟风选了个"最流行"的方案，后面肯定会踩很多坑。技术选型这件事，没有最好的，只有最合适的。而判断"合不合适"，靠的就是你对技术的理解深度，这种深度，很大程度上来自于阅读和思考。

当然，我也不是那种死读书的人。有些书读不下去，我就先放一放，过段时间再拿起来。还有些书，读第一遍似懂非懂，过半年再读一遍，突然就通了。这种感觉很奇妙，就像酿酒一样，需要时间发酵。

---

实践出真知，但别瞎实践

光读书不实践，那是纸上谈兵。但光实践不读书，那就是盲人摸象。

我见过不少同事，技术热情很高，什么新技术都要试一试。今天学个Rust，明天搞个Web3，后天又去研究量子计算了。问他学到了啥，支支吾吾说不出来。这种实践，我称之为"瞎实践"。

有效的实践，应该是有目标、有深度、有沉淀的。

拿我自己来说，我给自己定了个规矩：每学一个新技术，必须产出一个实际的东西。可以是一个小工具，可以是一篇总结文章，也可以是在项目里真正用起来。总之不能只是"看了看"就完了。

前面说的Coze那个SQL助手的Bot，就是我实践的一个例子。在这个过程中，我不光学会了Coze的使用，还深入了解了大模型的能力边界。我发现，对于SQL生成这种任务，Prompt的设计非常关键。一开始我写的Prompt很粗糙，生成的SQL经常有问题。后来我参考了一些Prompt Engineering的最佳实践，把Prompt改成了结构化的形式，明确了角色、任务、约束条件，效果就好了很多。

# 优化后的Prompt模板
SQL_GENERATION_PROMPT = """
## 角色定义
你是一个资深MySQL数据库专家，擅长将自然语言转换为精确的SQL查询语句。

## 任务描述
根据用户的自然语言描述和提供的数据库表结构，生成对应的MySQL SELECT语句。

## 表结构信息
{table_schema}

## 输出约束
1. 仅生成SELECT语句，禁止任何数据修改操作
2. 必须包含合理的WHERE条件，避免全表扫描
3. 时间范围查询默认最近30天
4. 金额字段保留2位小数，使用ROUND函数
5. 结果默认按created_at DESC排序
6. 如果用户描述模糊，主动询问澄清

## 输出格式
直接输出SQL语句，不需要解释。如果需要澄清，请用中文提问。

## 用户查询
{user_query}
"""

def generate_sql(user_query: str, table_schema: str) -> str:
    """
    生成SQL查询语句
    Args:
        user_query: 用户的自然语言描述
        table_schema: 数据库表结构信息
    Returns:
        生成的SQL语句
    """
    prompt = SQL_GENERATION_PROMPT.format(
        table_schema=table_schema,
        user_query=user_query
    )
    # 调用大模型API
    response = llm_client.chat(prompt)
    return response.text

这个经历让我对Prompt Engineering有了比较深的理解，后来我还写了一篇内部的技术分享，在组里反响还不错。你看，这就是一个完整的"学习-实践-沉淀"的闭环。

说到这，我想分享一个我实践新技术的方法论，我管它叫"三阶实践法"：

阶段	目标	具体动作	产出物
第一阶：跑通Demo	验证技术可行性	跟着官方文档跑通最小可用示例	可运行的Demo代码
第二阶：解决实际问题	验证技术实用性	将技术应用到真实业务场景中	实际可用的功能/工具
第三阶：总结与分享	沉淀知识体系	写技术文章、做团队分享	技术文章/分享PPT

这个方法听起来简单，但真正能坚持做下来的人不多。大部分人卡在第一阶，跑通个Demo就觉得自己会了；少部分人能到第二阶，但懒得做总结；只有极少数人能走完第三阶。但恰恰是这第三阶，才是让你真正掌握一门技术的关键。

为什么？因为教是最好的学。当你要把一个技术讲给别人听的时候，你会发现自己很多理解其实是不清晰的。你会被迫去思考"为什么"，而不只是"是什么"。这个过程会倒逼你把知识体系梳理清楚。

---

关于"35岁危机"这件事

写了这么多，肯定有人要问了：你都35了，还这么折腾，不累吗？

累，当然累。

体力上确实不如年轻时候了。以前通宵上线，第二天照样活蹦乱跳。现在熬个夜，三天缓不过来。眼睛也不行了，以前看代码不用戴眼镜，现在离开眼镜屏幕上的字都是糊的。去年体检，颈椎、腰椎都有点问题，医生让我多运动，我办了张健身卡，一周能去两三次就算不错了。

但心不累。

我觉得所谓的"35岁危机"，很大程度上是外界制造出来的焦虑。确实，有些公司招人卡35岁，确实有些岗位更青睐年轻人。但你仔细想想，那些被"优化"掉的35+程序员，真的是因为年龄吗？还是因为他们这些年一直在重复第一年的经验，没有成长？

我见过很多35+的程序员，活得挺好的。他们要么技术足够深，是某个领域的专家；要么业务理解足够透，能站在更高的视角看问题；要么带团队带得好，能把一群人的战斗力发挥出来。这些能力，都不是年龄能限制的。

拿我自己来说，我现在写代码的速度可能不如刚毕业那会儿，但我写出来的代码，Bug率明显更低，可维护性更好，考虑的问题更全面。为什么？因为我踩过的坑多啊。哪些设计模式在这个场景下不适用，哪些看似优雅的方案其实有性能隐患，哪些技术选型会在半年后让你后悔... 这些经验，都是真金白银换来的。

而且我发现，年龄大了有个好处，就是心态稳了。以前遇到个线上事故，急得手心冒汗。现在嘛，该查日志查日志，该回滚回滚，该摇人摇人，有条不紊。这种稳定性，在关键时刻是很值钱的。

---

写在最后

洋洋洒洒写了这么多，其实就想表达一个意思：技术探索这件事，没有捷径，但有方法。

方法是什么？就是持续学习、深入思考、勇于实践、善于总结。这十六个字，说起来容易，做起来难。难在坚持，难在抵御诱惑——外面的世界太嘈杂了，今天这个火，明天那个热，你如果什么都想追，最后什么都追不到。

我的建议是，找到你最感兴趣、最跟你工作相关的方向，扎进去，往深了挖。挖到一定程度，你会发现触类旁通，很多看似不相关的东西，底层都是相通的。

就像我现在，虽然主要写Java后端，但因为对底层原理比较感兴趣，前端的东西也懂一些，数据库的调优也能搞，运维的脚本也能写，最近又折腾了点AI的东西。这些东西单独看都不算精通，但组合在一起，解决复杂问题的时候就特别好用。

好了，不说了，成都的火锅在召唤我了。周末约了几个朋友，边吃火锅边聊技术，这才是生活该有的样子嘛。

对了，如果你也是三十好几还在写代码的"老程序员"，欢迎来找我交流。咱们这个群体，其实挺需要互相打气的。

毕竟，代码写一辈子，也挺酷的，不是吗？

---

本文首发于个人技术博客，转载请注明出处。如果文章对你有帮助，点个赞再走呗~