标签 开发效率 下的文章

从上次说起

我的skill都可以在这里看到

安装也是非常的简洁

npx skills add BenedictKing/codex-review
npx skills add BenedictKing/tavily-web
npx skills add BenedictKing/context7-auto-research
npx skills add BenedictKing/exa-search
npx skills add BenedictKing/firecrawl-scraper

上下文占用非常少,主打的就是一个省钱还好用


📌 转载信息
原作者: Foward
转载时间: 2026/1/25 08:04:37

在经济下行的大背景下,越来越多的中小型企业开始放弃“前后端分离”的人员配置,开始采用“全栈式开发”的模式来进行研发费用的节省。

这方法真那么好吗?

作为一名从“全栈开发”自我阉割成“前端开发”的逆行研发,我有很多话想说。

先从一个活生生的真实案例开始吧。

我认识一个非常优秀的全栈开发,因为名字最后一个字是阳,所以被大家称为“阳神”。

  1. “阳神”的“神狗二相性”

阳神当然是牛逼的。

他不仅精通后端开发,更是对前端了解的非常深。这样来说吧:

当他作为后端开发时,他可以是那群后端同事里库表设计最清晰,代码最规范,效率最高的后端。

当他作为前端开发时,他除了比几位高级别前端稍逊一点外,效率和UI还原性都非常高,还会主动封装组件减少耦合。

但是非常奇怪的事情总是会发生,因为一旦阳神不是全职的“后端”或者“前端”时,一旦让他同时操刀“后端+前端”开发任务,作为一名“全栈”来进行业务推进时,他的表现会让人感到惊讶:

他会写出设计糟糕,不规范,职责混乱的代码。

这个现象我把他戏称为“阳神”的“神狗二相性”,作为单一职责时他是“阳神”,同时兼任多职时,他就有非常大的可能降格为“阳狗”。

为什么呢?这是阳神主观上让自己写更糟糕的代码吗?

不是的兄弟,不是的。

这是系统性的崩塌,几乎不以人的意志为转移。换我去也是一样,换你去也是一样。

  1. 分工粗化必然导致技术细节的差异

从前,在软件开发的古老行会里,一个学徒需要花很多年才能出师,专门做一把椅子,或者专门雕一朵花。现在,你被要求从伐木到抛光,从结构力学到表面美学,全部一手包办。

生产力在发展,对人的技能要求也在发展。

因此“分工细化”成为了工业革命之后完全不可逆的趋势。

在 IT 产业上也是如此。

“软件开发”经过多年被细化出了前端开发、后端开发、客户端开发、大数据开发 等等多种不同的细分职业。

但是现在有人想通过 粗化 职业分功来达到 “提效” 的目的,在我眼中这就是和客观规律对着干。

人的精力是守恒的。当你需要同时关心useEffect的依赖数组会不会导致无限渲染,和kubectl的配置能不能正确拉起Pod时,你的注意力就被稀释了。你不再有那种“针对一个领域,往深里钻,钻到冒油”的奢侈。

当你脑袋里冒出了一个关于前端工程化优化的问题时,身为全栈的你会本能地冒出另一个念头:

在整个全栈体系内,前端工程化优化是多么边角料且无关痛痒的问题啊,我去深入研究和解决它的性价比实在太低了,算了不想了。

如此一来,无论是后端的性能问题还是前端的性能问题都会变得无关紧要。

结果是,只有业务问题是全栈开发要关心的问题。

  1. “岗位对立”与“自我妥协”

在日常开发中,前端开发和后端开发之间互相吐槽争论是再正常不过的话题,而且争论的核心非常简单易懂:

前端:这事儿不能在后端做吗?

后端:这事儿前端不能做吗?

可以的,兄弟,最后你会发现都是可以的,代码里大部分的事情无论是在浏览器端完成还是在服务器里完成都是可行的。

但是,总有一个“哪方更适合做”吧?

一个大屏页面的几万几十万条的数据统计,是应该后端做还是前端做?
业务数据到Echarts展示数据的格式转换应该后端做还是前端做?
用户数据权限的过滤应该后端做还是前端做?
一个列表到底要做真分页还是假分页?
列表已经返回了全量实体信息,为什么还要再增加一个详情接口?

这都是日常开发时前端和后端都会去争论思考的问题,身处不同的职位,就会引入不同的立场和思考。

前端需要去思考页面刷新后状态的留存,js单线程下大量数据处理的卡顿,页面dom树爆表的困境。
后端也需要思考并发下服务器资源和内存的分配,可能的死锁问题,以及用户的无状态token如何处理等。

前后端的“争吵”和观点输出是不可避免的。

真理总是越辩越清晰的,后续讨论出的结果多半是最有利于当前现状的。

但如果“前后端”都是同一个人呢?

全栈模式,完美地消灭了这种“有益的摩擦”。当你自己和自己联调时,你不会给自己提挑战灵魂的问题。你不会问:“这个API设计是否RESTful?”因为你赶时间。你也不会纠结:“这个组件的可访问性够好吗?”因为你还得去部署服务器。

这两种思想在你的大脑里打架,最终往往不是最优解胜出,而是最省事的那个方案活了下来。

于是,你的代码里充满了“差不多就行”的妥协。这种妥协,一两个无所谓,当成百上千个“差不多”堆积起来时,质量的基础就酥了。

内部摩擦的消失,使得代码在诞生之初就缺少了一道质量校验的工序。它顺滑地流向生产环境,然后,在某个深夜,轰然引爆。

插播机-会

技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~

  1. 工程的“不可能三角”

软件开发领域有一个著名的“不可能三角”:

快、好、省,你只能选两样。

全栈模式,在管理者眼中,完美地实现了“省”(一个人干两个人的活)和“快”(省去沟通成本)。那么,被牺牲掉的是谁?

雪崩时,没有一片雪花是无辜的。但更重要的是,当结构性雪崩发生时,问责任何一片雪花,都意义不大。

至于“快、好、省”这三兄弟怎么选?

那主要看老板的认知和他的钱包了。

——转载自:摸鱼的春哥

我的工作流是一个围绕 superpowers 插件Loop,superpowers 的理念是:先思考再动手。当你提出一个需求,不会急于写代码,而是先退一步问你"你真正想要实现什么",通过对话梳理出完整的设计方案,再分步执行。

核心设计是 masterworker 分离。

  • 脑暴会话 (master):专注于思考和设计,输出高质量的设计文档和执行计划
  • 执行会话 (worker):专注于代码实现,执行详细的计划

分享一下我的 ClaudeCode 工作流:Kitty + Zed + superpowers,可以减少和 AI 的反复拉扯,一次做对1

1、需求录入 - 首先我会在 Zed 上进行需求录入,采用 md 格式。这一步非常重要,我大概有 30% 的时间花在需求录入上,我会把能想到的关于此需求的背景、最终目标、可行的技术方案、风险点、外部 API 文档等等一切资源,都在需求文档中说明。对于需求文档,我不会太在意格式,会有比较多口语化的表达。

2、脑暴阶段 - 把需求 MD 喂给 Claude,调用 /superpowers:brainstorm 和 claude 进行思维碰撞。这个阶段不写任何代码,只讨论设计方案和实现细节,最终输出 design.mdimplement.md,保证最终的实现方案是完美符合我的预期的。

3、 执行阶段 - 这里我会选择新起一个 ClaudeCode 会话,而不是在脑暴会话中进行代码实现。新会话的好处:一、原先脑暴会话已经经过多轮对话了,一般情况下上下文会比较满,新会话响应更快,并且不会“犯傻”;二、implement.md 足够详细,无需额外上下文

4、 CodeReview - 在 Zed 中进行代码审查和功能验收。关于代码审查,对于一些代码细节和实现原理,这里我会使用 zed-agent 来辅助我进行代码 review,当然,你也可以在终端新建一个 ClaudeCode 会话或者使用 Zed 的 Claude Agent。原则是尽量不在脑暴和执行会话中引入太多不必要的问题,保持这两个会话的「干净」。发现问题后,将改进项写入新的需求 MD

5、 LOOP - 改进项 MD 喂回脑暴会话,开始下一轮脑暴迭代

非常简单,但是效果超群。充分的前期设计可以提升 AI 的效率和质量,避免多次的来回拉扯。

举个真实案例:我用这套工作流将个人博客从 Quarz 框架迁移到 Astro 框架。脑暴阶段确认好设计方案后,我让 Claude 执行计划,然后就去睡午觉了。醒来发现 Claude Code 已经完美完成任务——中间零中断,一次成功,共计 5000+ 行代码变更。