<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>随笔 - Category - 帅说帅话</title><link>https://xiaoshuai1024.github.io/categories/%E9%9A%8F%E7%AC%94/</link><description>随笔 - Category - 帅说帅话</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Tue, 24 Mar 2026 21:16:33 +0800</lastBuildDate><atom:link href="https://xiaoshuai1024.github.io/categories/%E9%9A%8F%E7%AC%94/" rel="self" type="application/rss+xml"/><item><title>前端工程师如何打破职业天花板</title><link>https://xiaoshuai1024.github.io/posts/front-end-enginer-self-improving/</link><pubDate>Tue, 24 Mar 2026 21:16:33 +0800</pubDate><author>Author</author><guid>https://xiaoshuai1024.github.io/posts/front-end-enginer-self-improving/</guid><description>我在多次技术评审和团队分享中都会提到一个话题：前端工程师的职业天花板在哪里，如何突破？ 这并不是危言耸听，而是中国互联网行业中一个不争的事实。今天我想和大家深入探讨这个话题。
前端天花板：真实存在的困境 曾在述职时我提出过“前端工程师如何打破职业天花板”这个问题，评委们一致表示不存在这个天花板。但现实往往比理想骨感得多——前端天花板不仅存在，而且比后端更低。
为什么会这样？我从以下几个维度来分析：
第一，门槛低导致的竞争激烈。前端开发入门门槛相对较低，HTML、CSS、JavaScript 几天就能上手，Vue、React 框架更是让“速成”成为可能。这直接导致了初级前端岗位供过于求。根据 2025 年招聘平台数据，传统 Web 前端岗位的投录比超过 50:1，远高于后端开发岗位。
第二，技术深度相对有限。相比后端复杂的服务架构、分布式系统、数据库优化等核心技术，前端在很长时间内被认为是“写页面”的工作。虽然近年来 Node.js、SSR、Serverless 等技术拓展了前端边界，但在技术深度上，前端依然面临认可度不足的问题。
第三，工程化体系成熟度。后端有完善的 DevOps 体系、微服务架构、云原生实践等一套完整的技术生态。而前端的工程化实践虽然在不断进步，但在系统级复杂度上仍与后端存在差距。
这些因素叠加在一起，造就了前端职业发展路径上的隐形天花板。
两条不同的职业轨迹 让我们正视一个现实：前端和后端存在着两种截然不同的职业发展路线。
后端的晋升路径相对清晰：
初级研发 → 中级研发 → 高级研发 → 架构师 → 技术总监 → 技术副总裁（CTO） 这个路径在互联网行业已经被验证了无数次，每一步都有明确的技术能力和业务贡献标准。
而前端的路径呢？很多从业者会发现：
初级研发 → 中级研发 → 高级研发 → 前端组长 → 前端主管 → 前端负责人 然后呢？很多人就卡在了“前端负责人”这个层级，很难再往上走。因为在大多数公司的组织架构中，前端团队的规模和影响力天然小于后端团队，向上晋升的通道自然变窄。
这，就是前端职业天花板的真实写照。
打破天花板：三位一体的破局之道 既然天花板真实存在，我们该如何打破它？我总结出三位一体的破局策略：
1. 技术要全面：撕掉“前端”标签 我们应该是工程师，而不是“前端工程师”。
在中国互联网行业，有一个奇怪的现象：很多人给自己打上了“前端工程师”的标签后，就再也不愿意触碰其他技术领域。这实际上画地为牢。
真正有竞争力的前端工程师，应该具备以下技术广度：
后端基础：理解 RESTful API 设计、GraphQL、微服务架构，掌握至少一门后端语言（Node.js、Java、Go 均可） 运维能力：了解 Docker 容器化、K8s 基础、CI/CD 流水线、Linux 服务器运维 数据处理：掌握前端数据可视化（D3.js、ECharts）、了解大数据基础概念 移动端：熟悉 React Native、Flutter、uni-app 等跨端开发技术 2025 年的今天，企业对前端工程师的要求已经今非昔比。仅仅“会写组件”已经不够了，你需要能够参与产品设计讨论、理解后端服务架构、甚至独立完成小型全栈项目。</description></item><item><title>AI编程之我见</title><link>https://xiaoshuai1024.github.io/posts/ai-programming/</link><pubDate>Mon, 17 Mar 2025 21:00:00 +0800</pubDate><author>Author</author><guid>https://xiaoshuai1024.github.io/posts/ai-programming/</guid><description>作为一名常年和代码打交道的全栈开发，最近这一年，最明显的感受就是：AI 已经彻底走进了编程的日常，不再是当初那个“听起来很厉害、用起来很鸡肋”的噱头了。今天就以我自己的使用经历，跟大家聊聊 AI 编程那些事儿，轻松唠唠，不聊复杂理论，只说真实体验。
先说说现状吧。现在 AI 编程工具真的是百花齐放，不用再像几年前那样，翻来覆去就那几款凑合用的工具。最常用的应该就是 Cursor 了，主打一个轻量、精准，专门针对代码场景优化，不像有些通用 AI 工具，写代码还要反复调试提示词；还有 GitHub Copilot，适合和 IDE 深度绑定，比如 VS Code 里装个插件，写代码的时候自动联想补全，有时候甚至能猜到你下一行要写什么；另外像 CodeGeeX、通义千问代码版，也各有侧重，有的擅长多语言适配，有的在国内网络环境下更流畅，总之选择很多，总能找到一款适合自己的。
我真正开始深度用 AI 编程，是源于我个人的全栈项目——luban。熟悉我的朋友知道，这个项目我一个人扛了大部分开发，涉及好几个子系统，前端要用 Vue3 + Nuxt3，后端要写 SpringBoot，偶尔还要用 Node.js 写个 BFF 层，甚至有时候要补点 golang 脚本处理数据，多种语言来回切换，有时候写着写着就卡壳，尤其是一些不常用的语法，还要翻文档、查博客，特别耽误时间。
最开始是抱着试试看的心态，下载了 Cursor，本来只是想用来补补语法、调试个小 bug，结果用了不到半天，就果断开通了 Cursor Pro。说实话，一开始没抱太大期望，毕竟之前也用过不少 AI 工具，要么答非所问，要么代码报错，但 Cursor 给我的感觉完全不一样——我只要把需求说清楚，比如“用 SpringBoot 写一个站点列表查询接口，带分页和条件筛选，关联用户表”，它就能直接生成可运行的代码，甚至连异常处理、参数校验都帮我写好了，省去了大量重复编码的时间。
聊到效果，用“惊人”来形容一点都不夸张。以前我写一个完整的后端接口，从定义实体类、Mapper、Service 到 Controller，再到调试通过，至少要半个小时，现在用 Cursor，10 分钟就能搞定，而且代码结构很规范，不用我再手动调整格式。尤其是写前端组件，有时候我只需要描述“写一个 Vue3 的表单组件，包含输入框、下拉框，带表单校验，提交按钮禁用逻辑”，它就能生成完整的代码，我只需要根据项目的样式规范，微调一下类名和样式，就能直接复用。
效率提升最明显的，还是多语言切换的时候。比如我刚写完 Java 代码，突然要写 Node.js 的 Egg.js 接口，语法细节很容易记混，这时候只要让 Cursor 帮我生成一个基础模板，再根据我的需求修改，就能快速上手，不用再去翻 Egg.js 的官方文档，节省了大量的时间成本。可以说，自从用了 AI 编程，我这个“单兵作战”的全栈项目，进度至少提速了 40%。
当然，AI 编程也不是完美的，它的问题也很突出，最常见的就是两个：一是容易出现“幻觉”，二是代码质量参差不齐。所谓的幻觉，就是 AI 会编造一些不存在的 API、方法，或者引用一些不存在的依赖，比如我让它写一个 Redis 缓存的工具类，它居然生成了一个不存在的 Redis 方法，我复制过去直接报错，一开始没注意，排查了半天才发现是 AI 编的；还有代码质量，有时候它生成的代码虽然能运行，但不够优雅，比如重复代码太多、没有做优化，甚至有潜在的性能问题。</description></item></channel></rss>