以前我们总觉得专业是道门槛，学计算机的写代码，学中文的写文案，各走各的路。但现在你看那些AI公司招人，反而更愿意要“懂技术的文科生”——因为大模型调教得好不好，很多时候不取决于你会不会写算法，而取决于你能不能把需求描述清楚、有没有语感、懂不懂用户心理。反过来，那些“有产品感的程序员”也特别抢手，代码写得溜的人很多，但能坐下来琢磨“这个功能用户真的会用吗”“这里交互是不是反人性”的，确实不多。那个脑机接口公司说的“具备科学家思维的工程师”，听起来玄乎，我理解就是：光会实现功能不够，得知道为什么做；光有前沿想法不够，得能把它落地成代码跑起来。现在AI行业不缺单一技能的人，缺的是能把两端连起来的人——懂技术也懂场景，会动手也会动脑。

字节、腾讯几家大厂加起来放了快3万个实习岗，AI相关的职位比去年暴涨了14倍。有个叫万格智元的创业公司，给大模型算法实习生开到日薪3000，算下来月薪6万。不是年薪，是月薪。但是招不到人，是金三银四没有了吗？不，有。但是不是单一的某个岗位，而是“复合”型。

没有，不但没有感觉到金三银四，现在还非常有危机感。听说好多公司裁员、毁约，大多都是实习生，恐怖。感觉现在大环境越来越难了。

AI Agent，我理解它就是从“动嘴”到“动手”的质变。LLM再聪明，也就是个话痨，你问它答。但Agent不一样，你跟它说“帮我订一家周六晚上能带狗狗一起吃饭的餐厅”，它能自己打开浏览器、搜索餐厅、比对哪些允许宠物、筛选评价高的、甚至自动打电话确认，最后把结果告诉你。它替你干活，不是只跟你唠嗑。这东西门槛确实比Prompt工程高不少，涉及规划、调用工具、记忆、决策这些模块。但好玩就好玩在，它把AI从“聊天框里”解放出来了。你可以让Agent定时去抓你关注的游戏服务器状态，发现异常自动发警报；也可以让它每天爬社区玩家反馈，自动整理成表格发你邮箱。作为游戏后端，其实有天然优势——Agent的调度逻辑，跟游戏里的行为树、任务系统特别像。都是“如果满足条件，就执行某个动作”。只不过Agent调的是API，不是游戏动画。天花板高，是因为它指向了真正的“数字员工”。现在只能干点简单跑腿的活，未来能帮你写代码、修bug、处理客服，甚至替你开会。虽然现在搞起来有点折腾，但看着自己搭的Agent真的跑起来那一刻，那种“它在替我干活”的感觉，确实挺上头的。

用AI工具用多了，会忍不住琢磨：为什么这个产品火，那个就没人用？比如同样做PPT，有的AI工具让你输个主题就全自动生成，看起来很酷，但做出来的东西根本没法用。有的则让你一步步选风格、调细节，把控制权留给你。琢磨多了你会发现，好的AI产品不是炫技，是懂人心——知道什么时候该替用户干活，什么时候该闭嘴让用户自己来。这种思考很有意思。你会发现很多AI产品表面在卖模型，实际在卖“安全感”——让用户感觉一切还在掌控中。也会发现有些产品明明技术很强，但就是没人用，因为把用户当成了调试工程师。培养这种产品感，可以让你多一双眼睛看这个行业。以后无论创业、转行还是跟产品经理吵架，这双眼睛都能帮你看清：什么是真需求，什么是伪痛点。以后机会多，说的就是这个。

从Prompt工程入门，确实是普通人最快能摸到AI温度的路。它不需要你会写代码，也不需要懂什么神经网络，本质上就是学一门“跟AI好好说话”的艺术。为什么说它快？因为你打开对话框的那一刻，就已经开始实践了。比如你想让它帮你写工作周报，以前可能只说“写周报”，出来的东西又空又泛。但稍微琢磨一下Prompt的技巧，你会说“我是一名游戏后端，这周主要修复了三个服务器崩溃的bug，优化了玩家匹配算法的响应时间，请帮我写成一份给项目经理看的周报，要突出技术价值和稳定性成果”——出来结果完全不一样，基本拿来就能用。这种即时反馈很上头。今天让它写邮件，明天让它润色文案，后天让它解释一段复杂代码。每次对话都是一次练习，每次优化都能看到输出质量肉眼可见地提升。学一周就能帮朋友写情书、帮同事写会议纪要，这种“立马能用上”的感觉，是支撑人继续往下学的最大动力。

“您好，我是XX，投了贵司游戏后端岗。我做过XX项目，熟悉XX技术，和岗位匹配度挺高的。方便的话，想问问您对我简历什么看法？或者约个时间聊聊？不白嫖你时间，几分钟就行。”

工作快两个月了，发现写代码只是工作的一部分。还有好多事情，学校没教过。比如怎么在群里问问题，又清楚又不会打扰别人。比如怎么估算一个需求要多久，既不让产品觉得太慢，又不让自己加班。比如怎么拒绝不合理的排期，又不得罪人。比如怎么在周报里把自己的小进步写得像回事。这些没人教，全靠自己悟。有一次我估算一个任务要两天，同事建议我再加两天。我觉得两天应该够了。他说：“你算了自测吗？算了联调吗？算了上线观察吗？算了万一出问题回滚的时间吗？”我沉默了。后来果然两天完全不够。不是因为代码多难，是因为那些“写代码之外”的事，比写代码本身更花时间。

组会的时候，大家聊一个新项目。有人问：“这个用Kafka做消息队列怎么样？”我听到“Kafka”三个字，立刻低下头，假装在看笔记本。其实脑子里在想：Kafka是什么？消息队列我知道，但Kafka是什么？不敢问。组里都是老员工，就我一个菜鸟。我怕一问就暴露自己“连这都不知道”。会开完了，我偷偷百度：Kafka是什么。看完介绍，大概懂了。就是一个专门处理消息的东西，挺适合我们那个场景的。后来我跟同事聊天说：“我今天开会听到Kafka，之前不知道是什么，偷偷查了一下。”他说：“那你怎么不问？”我说：“不好意思，觉得应该知道。”他看了我一眼，说：“你觉得应该知道的东西，多了去了。不知道就学，学了就知道。不问，就永远不知道别人在聊什么。”职场里最亏的，不是为了“应该知道”而硬撑，而是为了“显得知道”而错过真正知道的机会。

事情是这样的：要配一个本地环境，文档写了一半，我照着做，卡住了。试了三种方法都不行。带我的同事就在旁边工位，我扭头就能看见他。但我就是张不开嘴。我怕问题太蠢。怕他心想“这都不会”。怕他放下手头的事来帮我，结果发现只是我漏了一个逗号。怕他觉得招我进来是个错误。于是我继续自己折腾。又试了两种方法，还是不行。时间已经过去两个小时，我连代码都没开始写。最后还是去问了。他走过来，看了一眼我的配置文件，说：“哦，这个路径写错了，应该是斜杠不是反斜杠。”十秒钟解决。我坐在那里，有点想笑。两个小时的挣扎，十秒钟的答案。我那两个小时到底在怕什么？我害怕的不是问问题本身，而是问问题之后，那个想象中的自己被否定。但想象终归是想象，现实是，别人根本没空judge你，大家都在忙自己的事。纠结，比解决问题更浪费时间。

同事扔给我一个模块，说：“你看看这个，下周可能要改。”我盯着屏幕上密密麻麻的代码，像在看一本天书。每个单词都认识，连在一起就不知道在干什么。我一行一行地读，像小学生读课文那样，用手指指着屏幕，小声念出来。念到第十行，忘了第五行在说什么。往上翻，再看一遍。再往下，又忘了。来来回回翻了十几遍，最后还是没搞懂这个函数到底要返回什么。我有点慌。不是怕做不完任务，是怕被发现自己其实“看不懂”。面试的时候说的那些“熟悉C++”“了解游戏后端”，现在想起来都有点虚。我真的熟悉吗？为什么连别人写的代码都看不明白？中午吃饭，同事看我蔫蔫的，问怎么了。我憋了半天，说：“我感觉我看不懂代码。”他笑了，说：“正常，我看了三年有时候也看不懂。看代码不是看书，不用从头读到尾。先跑起来，打日志，改几个值看看有什么变化。”下午我试了试。加了几个打印，改了几个参数，看着控制台输出的东西一点点变样。好像，真的没那么难了。看不懂的时候，别硬看。慢慢来，心急吃不了热豆腐。

入职第一个难关不是适应新代码，而是记人名、认脸、搞明白谁负责什么。刚分清产品和运营，发现还有个“项目统筹”角色。最耗token的是在群里提问@人，生怕@错人显得尴尬。还有搭建开发环境，文档写着“参考wiki”，wiki链接点进去是404，只好挨个问同事要安装包——这时候无比怀念老东家那个虽然烂但至少能跑的开发环境。

我们一个活动模块要上线，需要存玩家临时数据。我选了MongoDB，理由很简单——不用建表、结构灵活、听说读写都快。选型的时候我还挺得意，觉得终于用上了“时髦”的技术。结果活动第三天，查询开始变慢了。一开始只是偶尔卡一下，后来越来越频繁。我盯着监控面板，看到那个爬坡的延迟曲线，手心开始冒汗。是数据量太大了？是我索引没建对？还是——MongoDB根本就不该用？那天晚上我躺床上，眼睛闭着，脑子却像跑满线程的服务器：要是当初用MySQL，现在会不会稳一点？MySQL我熟啊，至少知道怎么优化。或者用Redis？虽然要处理持久化，但至少快啊。要不明天一早上线把数据全迁了？翻来覆去到两点，甚至开始回忆选型那天：我当时是不是脑子一热？是不是被“大家都用NoSQL”带偏了？我一个小小的初级开发，凭什么自己拍板用MongoDB？要是活动崩了，玩家骂的是游戏，老板找的是我。第二天顶着黑眼圈到公司，第一件事就是查日志。结果发现，是我一个查询没加索引，全表扫描把数据库拖垮了。加完索引，性能立马恢复正常。问题不在MongoDB，在我自己，我一整晚的内心戏、一整晚的自我怀疑、一整晚的“如果当初”，全都白演了。同事说：“你这就是典型的选型后遗症。选A怕B更好，选了B又怕A更稳。其实大多数时候，技术本身没毛病，是你对自己没信心。”用自研框架，新同事上手慢，你就想：要是用开源的，人家可能自己就会了；用开源方案，遇到一个解决不了的bug，你就想：要是自己写，至少能控制每一行代码；用MySQL，担心扛不住QPS；用Redis，担心丢数据；用MongoDB，稍微慢一点就整晚失眠。内心戏太过丰富，全是各种想象。其实哪有完美的技术选型。每个选择都有代价，选了就得认。最累的不是做决定那一刻，而是决定之后，用放大镜盯着那个选择，生怕它出一点问题。做决定之前多调研，做决定之后少纠结。出了问题先查日志，别先查自己的心理阴影。毕竟，我的token还要留着写代码，不能全烧在那些“如果当初”的平行宇宙里。

作为一个开发菜鸟，我第一次在组会上正式讲技术方案。我紧张得周五晚上都没睡好，脑子里反复过每一页内容。架构图画了又改，生怕箭头指错方向；技术选型那页，我特意把Redis、MySQL、MongoDB的对比列成表格，还从网上扒了几篇博客佐证；性能评估的数据，是我自己在测试环境跑了一下午压测跑出来的，虽然可能不太准，但至少有个参考。开会前我还偷偷在工位上默念了两遍：如果有人问缓存策略、数据一致性，我就翻ppt给他看。会议开始。我讲到第4页，正在解释为什么这次不用Redis——因为我们这个模块需要强持久化，玩家充值记录丢了赔不起。这时候，一位老同事举手了：“为什么不直接用Redis啊？Redis快啊。”我心想可能是我没讲清楚，赶紧补充：“因为这个数据要存盘，Redis是内存数据库，宕机会丢数据，风险有点大。”老同事点点头，我以为这页翻篇了。结果过了两分钟，他又开口了：“那你用MySQL不行吗？MySQL也能做缓存吧？”我脑子嗡一下。MySQL？缓存？我小声解释：“MySQL确实能存，但是QPS高了扛不住，我们预估峰值可能有几千的请求……”我偷偷瞄了一眼我的PPT第6页，上面确实有压测数据：MySQL到2000 QPS就开始慢了。老同事看了看屏幕，然后说了一句让我当场破防的话：“那我觉得还是Redis好。”那一刻，我感觉自己像一台卡死的服务器——CPU满了，内存爆了，但还得硬撑着保持在线状态。合着我刚才讲的，您一个字没听进去吗？我说了要持久化，说了QPS压力，说了数据一致性，您就记住一个“Redis快”？而且我已经解释了为什么不能用，您为什么还要坚持“觉得它好”？最消耗token的从来不是解释技术有多难。让我CPU过载的，是这种反复回答那些根本没认真听的问题——你准备了半天，把思路捋得清清楚楚，结果人家压根没在听，随口抛一个问题，你解释完，他再随口抛一个，最后回到原点。就像你费劲把一堆拼图拼好了，有人过来哗啦推散，问你：“这个拼图为什么不直接堆在盒子里？”会议结束后，我坐在工位上发了会儿呆。后来带我的大哥路过，拍拍我肩膀：“别往心里去，有些人开会就这样，习惯就好。”可能职场就是这样，别把心思放在那些不值得的人和事上。