技术探索与实践的一些思考
上周五晚上十点半，我瘫在出租屋的椅子上，盯着 VSCode 里一片红的 ESLint 报错，心里默默问候了产品经理全家。事情是这样的：我们组接了个“高优需求”，要在两周内把一个原本只面向内部运营人员的管理后台，改造成支持外部商家入驻的 SaaS 平台。产品说：“前端同学，你们只要把 UI 换个皮肤，加几个表单就行。”——呵，说得好像后端 API 不用改、权限体系不用重构、性能压测不用做似的。
我是复旦计算机大三的学生，今年暑假在上海某一线大厂实习，坐标徐汇，租了个离公司步行十五分钟的小单间。白天写代码，晚上刷 LeetCode，周末偶尔和室友一起打《永劫无间》解压。最近因为秋招压力山大，领导又“委以重任”，被迫深入研究前端工程化和 AI 集成方案。今天这篇博客，就是想聊聊这段时间踩坑、填坑、再挖新坑的过程中，一些关于前端、产品和技术边界的碎碎念。
从“换皮”到“重构”：产品一句话，前端跑断腿
事情得从那个“只需要换个 UI”的需求说起。产品原型图确实就改了几个颜色、加了两个按钮，但实际开发时才发现，原来的前端架构是典型的“脚本式开发”——所有逻辑都塞在一个 .vue 文件里，状态管理靠 localStorage 硬扛，API 调用直接 axios.get() 写死在方法里。这种代码，在内部工具里跑跑没问题，但一旦要对外暴露，安全、性能、可维护性全崩。
更离谱的是，产品在周会上轻描淡写地说：“这个功能双11前必须上线，不然商家没法报名。”——现在已经是十月二十号了！我和后端兄弟对视一眼，内心 OS：这哪是做功能，这是修长城啊。
于是，我们决定趁机推一波技术升级。既然要重构，不如一步到位：引入微前端架构、统一状态管理、对接公司内部的低代码平台。但问题来了——时间只有两周，而微前端的学习曲线陡峭得像外滩的台阶。
我翻遍了 GitHub 上的 qiankun、Module Federation、Single-SPA，最后选了 Module Federation（MF）。原因很简单：我们项目基于 Webpack 5，而 MF 是原生支持的，不需要额外引入第三方框架，还能和现有 Vue 3 + TypeScript 项目无缝集成。虽然文档写得像天书，但好歹不用再装一堆插件（我的 VSCode 已经因为装了太多插件，启动速度比我家楼下那家永远排队的生煎包出锅还慢）。
// webpack.config.js (主应用)
new ModuleFederationPlugin({
name: "host",
remotes: {
sellerPortal: "sellerPortal@http://localhost:8081/remoteEntry.js",
},
}),
// 子应用配置
new ModuleFederationPlugin({
name: "sellerPortal",
filename: "remoteEntry.js",
exposes: {
"./SellerApp": "./src/main.ts",
},
shared: {
vue: { singleton: true, requiredVersion: "^3.2.0" },
},
}),
看起来很美，对吧？但现实狠狠打了我一耳光。第一次联调时，子应用加载出来一片空白，控制台报错：
Uncaught Error: Shared module is not available for eager consumption: vue
查了一晚上 Stack Overflow，才发现是因为入口文件用了 import('./bootstrap') 的异步加载方式，而 MF 要求共享模块必须 lazy load。改完之后，终于跑起来了——但样式冲突了。主应用的 Ant Design 和子应用的 Element Plus 在全局 CSS 上干架，按钮一会儿圆一会儿方，看得我血压飙升。
这时候我才深刻体会到：前端不只是“画页面”，更是“搭积木”。而产品经理眼中的“换个皮肤”，在工程师眼里，可能是一次架构级别的手术。
当 AI 开始“帮”你写代码：是解放还是枷锁？
说到技术探索，不得不提最近疯狂上头的 AI 编程。作为被秋招简历逼疯的人，我开始研究怎么把 LLM 集成到日常开发中。Copilot 早就装了，但它有时候生成的代码像是从十年前的 jQuery 教程里抄来的，比如：
// Copilot 建议我这么写表单校验
if (email.indexOf("@") === -1) {
alert("邮箱格式错误！");
}
大哥，现在都 2024 年了，咱们有 Yup、Zod、VueUse 啊！
于是我自己搭了个本地 RAG（Retrieval-Augmented Generation）系统，用 Ollama 跑 Llama3，结合项目代码库做向量检索。目标很明确：让 AI 理解我们项目的上下文，而不是瞎猜。
举个例子，我们有个商品配置表单，字段特别多，校验规则复杂。以前每次加新字段，都要手动写 validator、error message、UI 提示。现在我只要在注释里写：
/**
* @ai-generate-validator
* 字段：discountRate
* 类型：number
* 范围：0 ~ 100
* 必填：true
*/
然后运行一个脚本，AI 就会根据项目已有的校验模式，生成符合规范的 Zod schema 和 i18n key。虽然第一次跑出来的代码漏了边界值检查，但迭代两次后，准确率能到 90% 以上。
但这里有个致命问题：AI 无法理解“产品意图”。
有一次，产品说：“用户输入折扣率时，如果超过 50%，要弹个二次确认框。”我让 AI 根据这个描述生成逻辑，结果它直接在 input 的 change 事件里写了 confirm()。测试同事当场炸毛：“谁允许你在现代应用里用原生 confirm 的？而且这体验太打断了！”
我这才意识到：技术再先进，也绕不过“人”的沟通。AI 可以帮你写样板代码，但产品逻辑、用户体验、业务边界，这些模糊地带，依然需要人来拍板。这也是为什么我越来越觉得，优秀的前端工程师，必须具备一定的产品思维——不是替产品经理干活，而是能提前预判需求背后的合理性。
前端 vs 产品：相爱相杀的共生关系
其实我和我们产品经理关系还不错，他经常请我们喝瑞幸（虽然都是用优惠券）。但每次需求评审，总免不了“battle”。
有一次，他提出要做一个“动态表单生成器”，商家可以自己拖拽字段、设置规则。听起来很酷，对吧？但技术评估下来，光是前端就需要实现：
- 字段类型管理（文本、数字、下拉、日期……）
- 条件逻辑（A 字段选“是”，才显示 B 字段）
- 实时预览
- 表单数据持久化与反序列化
这工作量，至少三周起步。我试着跟他沟通：“能不能先做 MVP？比如只支持固定模板，后续再扩展？”他想了想，说：“行，但老板下周要看 demo，至少得看起来能动。”
于是我们搞了个“伪动态”方案：前端预置 5 个模板，商家只能选，不能自定义。但 UI 做得像真的能拖拽一样（感谢 Figma 高保真原型救我狗命）。demo 顺利过关，老板很满意。后来才知道，隔壁组因为硬上真动态表单，延期两周，全员加班到凌晨。
这件事让我明白：技术探索不是为了炫技，而是为业务服务。你可以用最前沿的 Web Components + Lit + WebAssembly 做一个超快的表单引擎，但如果产品周期等不起，那不如用 Vue + v-for + 动态组件快速交付。
下面是我总结的前端在面对产品需求时的“技术决策矩阵”：
| 产品需求紧急度 | 技术复杂度 | 推荐策略 |
|---|---|---|
| 高 | 低 | 直接干，别废话 |
| 高 | 高 | 降级方案 + 后续迭代 |
| 低 | 低 | 顺手优化一下体验 |
| 低 | 高 | 趁机做技术债清理 or 新技术试点 |
当然，这张表的前提是：你得有靠谱的产品经理愿意听你讲。如果遇到那种“我就要五彩斑斓的黑”的主，建议直接打开 Boss 直聘——秋招窗口快关了，别耗着。
实践出真知：从“能跑就行”到“值得交付”
回到开头那个 SaaS 项目。经过两周地狱式开发（期间我喝了 12 杯冰美式，掉了 3 斤肉），终于在双11前一周上线。虽然 MF 架构还有点卡顿，但核心功能稳住了。最让我自豪的不是技术多牛，而是我们建立了一套可复用的前端能力：
- 统一的权限指令
v-permission - 自动化的 API Mock 机制（基于 Swagger JSON）
- 埋点 SDK 封装，一行代码上报用户行为
- CI 流水线自动跑 Lighthouse，性能低于 80 分就阻断发布
这些看似“不直接产出业务价值”的东西，其实在长期维护中省了无数力气。上周测试同学发现一个边界 case，我改完代码提交，CI 自动跑通所有 E2E 用例，十分钟就合入主干——而隔壁组还在手动点页面回归。
这也让我反思：很多同学（包括半年前的我）总觉得“业务代码才是正经事，工程化都是虚的”。但现实是，没有工程化支撑的业务，就像没打地基的楼，风一吹就倒。
写在最后：技术人的浪漫，是解决问题
马上就要秋招了，我投了不少 AI 方向的岗位。有人说前端快被 AI 取代了，但我反而觉得，前端的价值正在从“实现 UI”转向“连接人与智能”。未来的前端，可能要懂 Prompt Engineering，要会设计 AI 交互范式，要能判断什么时候该让人介入、什么时候交给模型。
但不管技术怎么变，有一点不会变：我们存在的意义，是解决问题。不管是修复一个烦人的样式 bug，还是设计一个让商家效率翻倍的表单系统，亦或是用 AI 减少重复劳动——这些都是实实在在的价值。
此刻窗外上海的夜色很亮，我的 VSCode 还开着三个终端窗口。明天还要和产品对新一期的需求，据说这次要上“AI 自动生成商品详情页”。我深吸一口气，泡了杯枸杞茶（程序员养生从大三开始），准备迎接新一轮的挑战。
技术探索的路上，没有银弹，只有不断试错、学习、交付。而每一次搞定一个看似不可能的需求后，那种“老子天下第一”的爽感，大概就是支撑我们熬夜写代码的最大动力吧。
PS：如果你也在秋招，欢迎交流～ 我的 GitHub 主页写着“求 Star 求内推”，别笑，是真的。
评论 0