我是 Ubug ，一名前端开发工程师👨‍💻，用高质量的技术和代码改变世界。

💬 最近闲说查看更多闲说

🚲 新开发范式探索

2026-02-20 13:23:00

领域与规范先行：依照领域模式而不是技术类型组织代码，高内聚低耦合，比如不区分组件pages、components、utils等大文件夹，转为业务驱动的页面文件夹和 shared 通用功能。
逻辑与视图分离：在组件中只调用 hooks 的逻辑封装，视图和状态严格分离；
测试和评审优先：在视图的实现之前，先对 hooks 进行测试和评审，可行之后再考虑视图的实现；

这几点目前还在探索中，不太符合快速实现的逻辑，但是感觉已经能明显提升代码质量了，尤其配合 AI 的能力。对于人来讲，先搭视图，然后做交互更符合直觉，但是代码质量方面后期需要不少的逻辑抽取和重构优化，但是 AI 去做逻辑层面的快搭，然后测试验证，然后再去做视图，这样反而能提升代码质量，也能提升整体的开发效率。

🚗 重新理解“工程化”

2026-01-12 21:23:00

一直以来，我对工程化这个词的理解就是通过工具、流程、规范和约定，实现一套从研发到部署的流程，把一个复杂的事情平铺成简单的事情，让人的部分聚焦在业务的实现上，从而快速拆解然后实现复杂的需求。

现在 AI 时代的各种新鲜概念，真的让我心灵剧烈重构。这种把不确定的事情，通过精心的编排、解构和Loop等手段，变成确定的方向的能力，很像一种把小老鼠装在一个机甲身体中，让它去当个扫地机器人的感觉。

🐎 2025 to 2026

2026-01-01 12:13:00

25 年结束了，总结一下技术上面的心得吧：

搭了很多有意思的底层支持，从端侧到部署层，感觉在重构团队的开发模式，灵活和敏捷成为了关键词；
用 AI 提了很多效率，不过 VibeCoding 还是没能找到比较满足交付的介入点，做一些技术的预研快搭还是挺合适；
年尾集中做了一大波的用户体验升级行动，用户层面感知很明显，这个让我觉得很开心，希望明年能够轻装上阵。

展望一下 2026 的未来：

希望能够再多探索一些业内比较好的 AI 工作范式，把团队的开发模式给再提个效率；
希望做点 AI 方向的探索，无论是业务层还是架构层面，AI 的发展是未来，打造 AI 时代的超级团队；
说个不是 AI 的方向，计划明年把老旧项目给升级一下，不仅要用户体验升级，技术开发体验也要照顾得到。

💡 AI 时代，

2025-12-20 12:13:00

Vibe Coding 现在能做的很棒了，让很多不熟悉编程的人也能做出很多有意思的演示，我也毫不怀疑可能在不久的将来真的可以代替人工编码，仅限此时此刻：

“我用 AI 做了个大概，你完善一下就上线吧”，然后传给我一个三五千行的 html 文件。
“跟 AI 聊了很多轮，给出了好多改进方案，你们照着弄就行”，然后一大段看似正确，但都是废话的文字列表。

这些话是有点危险的，倒不是说能不能做的问题，而是 AI 让你误解了我们实际产品开发交付的流程，“看起来可以”和“能上线”中间隔着无数的环节，不是 AI 根据一句话就能解决的。如果“Demo”想放到生产环境里面用，那些被 AI 平滑带过的边界条件、异常处理和隐含假设，都是不定时爆炸的黑盒。

仅限此时此刻，未来的哪天我坚信 AI 能够和人协同，一起做出健壮、可靠、可维护的代码（也可能不需要人的协同┑(￣Д ￣)┍）。

💡 概念和产品的鸿沟

2025-11-29 19:13:00

“概念”也并不是天马行空，也能落到地上，只是概念更多表达是一种“可以用这个东西做什么事”，在成为真正“产品”之前，还需要真的有人去用，真的成为很多人工作生活的一部分。

“我的某个 idea 很好，是一个什么什么概念”。我并不是在吐槽各种天马行空，而是在强调概念并不是一切，还需要额外的落地、细节验证、迭代改进等等不确定的东西，才能成为产品。

🎯 把过程当作了目的

2025-11-15 12:13:00

需求拆分的时候，用户目标可能变成了偏离的任务目标。从诉求的起点，拆解成任务的终点过程中。可能损失了很多有效信息，导致任务完成之后，并不能解决诉求。

接到用户的反馈或建议之后，我们自然的想等价于一个可以度量衡的标准需求，可以直白的告诉每个项目成员要做什么的需求任务。理想情况下，每个人完成任务之后，这个反馈或建议就能够被解决，但是很多情况下，都是事与愿违，变成了开发组的自说自话，也就是在需求拆解的过程中，把过程当作了目的。

🥗 生活技巧常年践行

2025-11-10 12:43:00

做点脏活累活：愿意做一些简单却繁复的脏活累活，能更好的推进各种事（比如生活中的刷碗、和工作中的各种衔接）。
积极反馈：把不想动，换成我还没累到不想动。
传播幸福：更愿意去传播美好，同时放下对细节和不公的执念。

你做这些可以减少80%的争吵。如果你觉得不公平，那么可以用这80%的争吵来换？我觉得为了减少争吵，这些值得去践行。

🥪 有用 !=== 有价值

2025-10-20 12:43:00

产品开发的过程中，涉及到很多功能点的设计，有些是产品规划的版本里程碑、有些是用户需求驱动、有些是领导想法驱动，大部分在需求评审立项的时候，都要各种需求分析、成本预估，之后再是预研、排期，稍大的项目更是要跨部门协作。

在各种眼花缭乱的需求评审的时候，吵架频繁到“累了”“算了”的时候很容易会忘了一件事，那就是要做的这个东西好像有用，但是有价值吗？

协作环节上的每个做没用功能的傻子早都被开了，所以决定要做的产品功能都是“有用的”，但是有没有价值这个就值得说道说道了，因为从后续数据来看，并不是每个“有用的”功能，都是“有价值的”。大把的时间浪费在了好像有用，但是花了人效后没任何可见的业务增长。

解决方法呢，就是理性分析（不自以为是）+beta验证（不眼高手低）。

🐴 AI 时代的敏捷开发

2025-10-12 12:36:10

产品越来越复杂，核心MVP功能跑了出来，基础功能稳固无需大规模的开发量，业务关注点逐步从功能细节到业务方向转变，大部分的开发工作从核心转移到边缘补充、到体验提升，主力开发也大部分开始尝试新业务，敏捷开发的逐步放缓。

AI时代没有标准清晰的产品路线，严格产品规划和稳定开发流程意味着守旧和落后。这个时代基础架构、云原生都是太成熟的东西了，产品关注点更强调的是快速验证和试错。

手段：

完成远大于完美：
1. 产品只提供给核心用户，不需要千万级别的系统架构涉及
2. 云原生，架构的事情让专业的人做，用适当的【预算】换产品验证的【时间】。
渐进式开发：
1. 小团队密集开发：不划分大功能，拆解为产品+开发的小团队，AI 提效。
2. 面向实验版发布：beta版本推进，提前在开发阶段收集产品反馈数据。
3. 不追求集体共识：不表决功能，产品负责制，快速决策+快速验证。
追求人效：
1. 每个人都要快速行动起来，AI 辅助，超级个体。
2. 沟通流动起来，多人协作，沟通机制。

基于这些敏捷开发，产品的推进速度能快很多倍，意味着用更少的机会成本更高效的追求时代的机遇。