永远雪山1. 聊聊这期选题的由来
先交代一下背景。我做“代码之外”这个周刊，本来是想给自己每周的碎片阅读做个归档，写点技术圈之外的东西——书、电影、工具、生活里跟代码沾边又不完全是代码的观察。结果写着写着，发现一个越来越明显的现象：技术正在让很多东西变得一模一样。
这期标题起得有点大，“当技术让一切趋同，我们还剩什么”，其实是一次实实在在的困惑。上周我在做一个很小的前端项目，需求很简单，一个小团队内部用的数据看板。按惯例，我该用 React 配一套现成的组件库，拉个状态管理，再上个 CSS 框架，项目骨架二十分钟搭完。这是标准做法，网上所有教程都在这么教你。但我忽然停下来想：为什么是 React？为什么一定是这套组合？如果换成十年前的技术栈，这个看板照样能写，甚至写得更随意、更有个人风格。可我根本没有犹豫，顺手就上了那套被重复了无数次的模板。
这不是我的问题，是整个行业的标准姿势。技术人的日常，就是不断选择“标准答案”，然后在这套标准答案上叠加自己的小改动。这个过程本身没什么不好，它能保证效率、稳定、可维护性。但当你在这个行业待得够久，你会发现一个让人有点不安的事实：我们输出的代码越来越像，我们解决问题的路径越来越像，连我们思考问题的方式，都在被工具和技术范式悄悄塑造成同一个形状。
这期周刊就是围绕这个感受展开的。我不想写“技术到底好不好”这种没有意义的话，技术当然好，没有技术我连这篇东西都写不出来。我想聊的是更具体的事：在技术趋同的大背景下，作为个体的工程师、创作者、普通人，那些没有被标准化、没有被框架覆盖、没有被最佳实践收编的东西，到底是什么。以及，这些东西在什么情况下会被真正用到。
以下几节的内容，有我对技术工具链的观察，有对创造力与代码关系的反思，也有从实际案例里提炼出的一点方法论。不保证绝对正确，但每一段都是这几年真实踩坑、真实思考后留下的东西。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 说几个“趋同”的具体切面
2.1 代码层的趋同：框架、模板与最佳实践
代码层面的趋同，是最容易被感知的一层。仔细想想，你今天手头项目里的技术栈，和隔壁公司某个不相关项目的技术栈，有多大概率是高度重叠的？你打开 GitHub 看热门的仓库，清一色的 React、Vue、Spring Boot，业务各不相同，但骨架惊人地一致。
这里面有历史的必然性。框架本身就是为了“消除差异”而设计的——它提供一套固定的约定，让你不必每次从零开始解决同样的问题。20 年前写 Java Web，每个团队都有自己的封装习惯，登录怎么做、权限怎么做、数据库连接池怎么配，各搞一套，代码风格千奇百怪，协作成本极高。Spring 出现以后，这些被统一了，好处是新人上手快，项目之间迁移平滑，坏处是你很难再看到那种充满个人理解的、有鲜明风格的代码。
到前端更明显。几年前还有“原生 JS 党”和“jQuery 党”之争，后来 React 一家独大，再后来 Next.js 把 React 的工程化问题也收编了。现在你让一个新人从零搭一个前端项目，他大概率会用 create-next-app 一键生成，里面已经配好了 TypeScript、ESLint、Tailwind、路由、优化方案。他的首个个人项目，长出来的模样和教程示例几乎一样。
这就是趋同。它不坏，它是行业发展成熟的标志。但你要意识到一件事：当你所有的代码都是用同一套模板生成的，你的项目之间就没有个性可言，你作为开发者的独特价值也会慢慢被稀释。 打个比方，今天会写 React 组件的人到处都是，但能徒手设计一个高性能渲染方案、能在没有框架约束下重新发明一套优雅结构的人，越来越少。不是说后者一定比前者厉害，而是在技术环境变化时，前者的技能迁移能力会弱很多。
2.2 体验层的趋同：设计规范把产品磨成了一个模子
代码趋同连带的另一个结果，是用户体验也在趋同。你打开任意一个 SaaS 后台，左侧是菜单栏，顶部是搜索框和头像，右侧是数据卡片，底下是表格——这套模板你闭着眼睛都能画出来。你刷短视频，点赞在右边评论区在左边，关注按钮永远在头像旁边，划走是下一条。你逛电商 App，首页是搜索框、轮播图、金刚区、信息流，连配色和圆角都出奇地一致。
这背后是一套“被验证过的成功范式”在起作用。 产品经理和设计师都知道，用户已经习惯了这套模式，贸然创新意味着学习成本，意味着留存率可能下降。于是所有人都在同一个收敛方向上不断打磨，界面越来越像，交互越来越一致，最后连差异化都只能靠运营活动撑起来。
这不算错，商业上这是最稳妥的选择。但站在一个长期观察者的角度看，这种趋同悄悄限制了我们的想象力。你很难再看到十年前那种“打开网站会哇一声”的惊喜感，也很难看到界面表达与产品气质深度绑定的那种设计。大家都选了同一条安全的路，安全到无聊，安全到没有记忆点。
2.3 内容层的趋同：AI 正在加速同质化
这一层是最近热度最高的。ChatGPT 类的工具普及后，写文章、做 PPT、写代码注释、生成短视频脚本，都能一键完成。效率是实实在在提升了，但每天涌入信息流的 AI 生成内容，读起来是什么感觉？——格式统一、结构工整、几乎所有段落都在用同样的句式展开，观点正确但毫无棱角。
我和几个做内容的朋友聊过，大家有个共同的体验：现在分辨一篇文章是 AI 写的还是人写的，很多时候只需要看前两段。AI 写的文章开头永远在“随着……的发展”，中间永远是“首先……其次……最后”，结尾永远是“综上所述”。不是 AI 做不到更有创意的表达，而是它训练语料的均值就是如此，它在模仿海量文本的“最大公约数”。
技术在降低创作门槛的同时，也在制造一种新的“模板化”。过去写文章靠的是个人积累和语感，同一件事一百个人写有一百种味道。现在你输入同样的关键词，十个人用 AI 生成出来的底稿可能只有细节上的差异，大框架完全相同。如果不去刻意做“反模板”处理，内容领域的同质化会越来越严重，最终连观点都会被抹平。
3. 当一切都标准了，独特性和创造力的位置在哪里
3.1 标准化解决的是效率问题，不是创造问题
很多人会把“标准化”和“正确”画上等号。在工程实践中，标准化确实意味着更少的 bug、更低的维护成本、更容易的团队协作。但把它上升到个人成长层面，你会发现标准化只是一个起点，它从来不是终点。
我做过一个比喻，标准化相当于给每个人发了一套同样的画板和基础颜料。你确实可以用这套工具画出不错的作品，但真正让人记住你的画作的，是你如何在这套标准工具之上，形成自己的笔触、自己的构图习惯、自己对色彩的特殊理解。代码框架也是同理，框架定义的是基础设施，你怎么用它来解决问题，依然是你自己的事。
拿我比较佩服的一个开源项目举例。它用的技术栈非常主流——Python、Django、PostgreSQL，没有任何冷门工具。但它的代码风格极其鲜明：模块拆分的边界非常独特，注释里经常能看到作者对业务场景的个人解读，甚至错误处理的方式都和一般项目不一样。读这个项目的代码，你明显能感受到“背后有个人在思考”，而不是“这是一套脚手架生成的文件”。这就是标准化之上的创造力。
很多技术人工作三五年后陷入瓶颈，本质原因不是技术不够好，而是过早地把“能用”当成了“足够”。能用标准方案搭一个系统，和能在标准方案之上提出更好的设计、更优的取舍，是两个完全不同的层级。
3.2 技术会让工具变强，不会让思考变深
这句话我想强调再强调。技术的每一次演进，本质上都是工具能力的跃升，而不是思考能力的跃升。 你用了更好的 IDE、更智能的代码补全、更强大的 AI 辅助编程，你写代码的速度确实上去了，但你对业务本质的理解、对系统设计原理的把握、对复杂问题的分析能力，不会因为这些工具而自动提升。
一个很现实的例子：现在用 Copilot 写 CRUD 接口，效率是手写的好几倍。但如果你没有想清楚这个接口的业务含义、数据权限边界、异常场景覆盖，写出来的代码即使语法正确、能跑通主流程，依然是一个埋着雷的“标准答案”。工具帮你完成了“怎么写”，但“为什么这么写”永远要靠你自己。
创造力本质上是一种“在约束中做选择”的能力。技术提供的约束越多，表面的选择越少，你就越需要深入底层去理解那些约束的来源，才能找到真正有创造性的解法。这一点在任何时代都不会变，只是今天的技术让这个过程变得更容易被跳过罢了。
3.3 那些“标准之外”的能力，正在变得更加值钱
最近几年行业里有一种声音，说基础程序员会被 AI 替代。我部分同意，但我觉得更准确的表述是：只会做“标准操作”的程序员会被替代，而能在标准操作之上提供独特价值的工程师，反而会变得更重要。
什么是独特价值？最直接的一种，是你对一个具体业务领域有远超平均水平的理解。同样写一个交易系统，知道怎么在极端行情下保证资金安全的人，和只会拿着框架按部就班实现需求的人，产出的系统完全不是一个东西。这种差距不体现在代码风格上，而是体现在无数个微小的决策里：这个字段该不该加索引，这个缓存失效策略会不会导致数据不一致，这个重试机制在最坏情况下会放大多少倍流量。这些决策，标准答案给不了你，只有靠深度思考沉淀下来。
再说一个更生活化的例子。我认识一个用 Obsidian 做个人知识库的朋友，他有自己一整套的笔记组织方法，什么内容进哪些文件夹、标签怎么命名、双链怎么建立，都有他自己的一套逻辑。别人照搬他的模板也能搭出类似的东西，但如果搭完就当收藏夹用，那它和价值两万块的思维导图课程没有区别。让他这套系统真正起作用的，是他在一个具体领域里持续积累的判断力——知道什么值得记、什么不记、什么和什么之间有关联。这种判断力不可能通过某一套通用工具获得，它必须靠长年累月的主动思考来积累。而今天，拥有这种积累的人，正在变得稀有。
4. 面对趋同的技术世界，普通人该如何自处
4.1 别急着追新，先把一条线打透
每次有新技术发布，总有人焦虑：我是不是跟不上时代了？这种焦虑大部分是被营销和流量放大的。我自己的经验是，在同一个技术领域里深耕至少三年以上，你才有可能形成真正属于你自己的方法论。 半年一换技术栈的人，永远在应对“新东西怎么用”的问题，没有余力去思考“这个东西为什么这么设计”“它解决了什么问题”“它的边界在哪里”。
拿数据库来说。如果你只在项目里用过 MySQL 的 CRUD，你很难理解为什么有人愿意花大量时间研究查询优化、索引底层结构、隔离级别与并发控制之间的关系。但这些“标准操作之外”的知识，才是一个后端工程师真正值钱的部分。它不会让你在简历上多一行亮点，但会在你处理线上性能问题时，成为别人全无头绪而你能快速定位根因的底气。
建议只有一个：选一个你每天都会用到的技术，把它研究到“比文档再多一层”的程度。这个“多一层”，就是你的独特性的起点。
4.2 留一点属于你自己的“非标准”项目
技术人很容易被工作裹挟，所有写代码的时间都花在公司项目上。但长期来看，那些能保留“个人项目”习惯的人，往往拥有更强的问题定义能力和更独立的技术品味。个人项目不需要遵循公司的技术规范，不需要迁就别人的代码风格，你可以完全按照自己的想法来设计。
哪怕一个小到只有自己用的工具脚本都行。我曾经为了一键备份家里的照片写过一个 Python 脚本，技术上没有任何亮点，但我自己设计了去重逻辑和文件夹组织方式。一年后回看，那个脚本虽然结构粗糙，却让我重新理解了“技术是为需求服务的”这句话的真实含义。
这种非标准项目，最重要的意义不是产出多厉害的东西，而是它是你“趋同”的日常中，少数完全由你掌控的小世界。它提醒你技术最初的乐趣是什么，也帮你建立不依赖外部评价体系的创作自信。
4.3 用跨界的视角对抗单一标准
还有一个对抗趋同非常有效的方法，就是有意识地接触“技术之外”的领域。这件事不需要很正式，看书、看电影、逛博物馆、学一门乐器、研究做菜，都算。
为什么有用？因为跨领域的体验能迫使你的大脑进行类比迁移。你看建筑学里的“空间动线”，会突然理解代码里数据流设计的问题；你研究香水前中后调的层次感，会对交互设计里“渐进 disclosure”有更直观的感受。这些类比不会直接提升你的技术能力，但它们会让你在遇到问题时，多一个跳出标准方案思考的入口。
我现在写代码遇到瓶颈的时候，会去翻一些非技术类的书，比如人类学、行为经济学的东西。这个过程不解决具体的 bug，但经常能让我从更宏观的角度重新审视问题本身，很多时候答案反而自己浮出来了。
5. 最后想说的话
这一期周刊写到这里，我重读了一遍开头的问题：“当技术让一切趋同，我们还剩什么？”
答案其实不难找。我们会剩下那些没法被算法散步、没法被框架规范、没法被 Prompt 生成的判断力与个人经验。技术可以帮你把代码写得越来越标准，但不会告诉你这个东西到底值不值得做；可以帮你处理海量信息，但不会替你决定什么值得被记住；可以让一切界面都平整顺滑，但抹不掉你对“美”和“独特”的偏好。
这些剩下的东西，才是你在技术浪潮里真正的锚。它们不会出现在你的技术栈列表里，不会出现在项目代码的注释里，但它们决定了你会成为什么样的工程师、什么样的创作者、什么样的人。
最后再分享一个小技巧：从今天起，给自己建立一个固定的“非标准时间”，每周抽一个下午或晚上，不用任何通用模板，不用任何现成框架，纯粹凭自己的兴趣和直觉去写点东西、做点东西。这个习惯不会立竿见影，但坚持一年后，你会重新认识自己。 到那时候，大概就不会再为“趋同”这件事焦虑了。