最近看到一则消息，快手研发线发了公告限制使用 Cursor 等第三方 AI 编程工具。不少工程师发现，只要在办公电脑上打开 Cursor，程序就会直接闪退。
对此我并未感到意外。为求证虚实，我特意向快手内部的朋友确认，得到了肯定的答复。背后的逻辑其实不难推演：
表层原因：推动内部自研工具的使用与沉淀（统一入口、统一能力、统一数据闭环）。
更核心的原因：代码安全与数据边界。第三方工具在“代码上下文读取、片段上传、日志回传、模型侧训练/评估”等环节存在天然的不确定性；对大厂而言，这类风险往往比“效率提升”更难接受。
这也并非孤例。过去一年里，字节跳动、微软、亚马逊等多家科技公司都在收紧对外部 AI 开发工具的管控，并逐步转向自研或内建方案。趋势很明确：AI 能用，但必须在可控边界内用。
当然，对于企业而言，若想完全替代外部工具，前提是必须将自研产品打磨得足够出色，否则糟糕的体验只会适得其反，引发一线开发者的抵触。
据我了解，国内某大厂也曾强制推广自研工具，但因体验不佳，遭到一线研发人员的强烈吐槽。
这件事让我想起最近一位粉丝的提问，非常有代表性：年底我聊了几家公司，发现一个明显的趋势：即使是传统的后端工程岗位，面试中也越来越多地考察 AI 相关能力。
目前被问得最多的，主要是Vibe Coding（氛围编码）的使用经验以及AI 在业务中的实际落地。
我的困扰在于：
日常辅助编码（Vibe Coding）还能积累经验，但业务层面的落地机会很少。
目前工作中不需要进行复杂的 Agent 编排，若非 AI Infra 或应用层岗位，接触 LLM 的机会很浅。
相比传统电商或 OA 系统有海量开源项目可参考，LLM 应用类的开源项目往往领域太细分，缺乏通用性。
在这种情况下，我是否有必要在工作之余，针对求职业务场景单独开发一些 AI 应用？
我的看法是：有必要，但不必奔着“做大项目”去；重点是做“能讲清楚、能复现、能工程化”的微落地。
AI 相关能力的考察确实越来越普遍，尤其是在当前技术快速演进的背景下。对于传统工程方向的后端岗位来说，面试中出现这类问题，更多是出于以下几个方面的考量，而不是要求你已经是 AI 领域的专家。
首先，是工具使用能力。面试官希望了解你是否具备运用 AI 工具（如 Cursor、Claude Code、Codex、Copilot 等）提高开发效率，将其转化为实际生产力，而不是停留在“写两句 prompt 让它补全代码”。这类能力往往可以直接反映你对新技术的接纳程度以及实际落地的能力。
其次，是技术敏感度。也就是说，你能否从工程视角理解 AI 会如何改变业务流程，哪些地方适合用、哪些地方不适合用。很多人的误区是：一谈落地就想到“Agent 编排”“多模型协同”“端到端自动化”。但现实里，真正能稳定创造价值的，往往是那些不起眼但高频的微场景：不改主流程、不动核心链路，但能显著提效、降低沟通成本或减少人工重复劳动。
最后，是学习能力。AI 相关技术更新迅速，面试官希望看到你是否具备主动学习新技术、快速适应变化的能力，这是优秀程序员很重要的一个特质。
至于绝大部分开发者担心的“业务场景缺乏”，其实 AI 的落地并不一定非要宏大的 Agent 编排，真正的突破口往往隐藏在不起眼的“微场景”中。
你完全可以跳出纯技术的视角，在现有的存量业务中寻找那些“非核心、但能显著提效”的切入点，例如：
智能审批建议：辅助人工进行初步判断；
知识库问答系统（RAG）：解决内部文档检索难的问题；
日志智能分析：快速定位异常堆栈；
Code Review 智能助手：自动化检查代码规范和潜在 Bug；
SQL/报表智能生成：降低运营人员的数据查询门槛。
这些场景在传统的电商或 OA 系统中随处可见，且开源社区已有大量成熟的“轮子”可供参考。关键在于你是否有心去发掘需求，并对其进行工程化改造。
即便公司暂时没有明确的 AI 项目立项，你也可以基于这些点自己动手做一个小型 Demo，在团队内部分享，既能展示你的技术敏感度和工程能力，也能为团队带来启发。
==好了，给粉丝个福利==
==打车千万别直接去APP，记得先领券== 亲测一单省了30块钱
