码厩开发者笔记

#1272 中国劳务派遣制度的发展、争议与未来走向

中国劳务派遣制度本质上是市场经济发展过程中，为满足企业灵活用工需求而形成的一种特殊劳动用工形式。它并非中国独有，但在中国的发展路径具有明显的国企改革和劳动力市场转型特征。

中国现代意义上的劳务派遣最早可追溯至改革开放后的涉外劳务服务。20世纪80年代末至90年代，随着外资企业进入、劳动力市场逐步建立，劳务派遣开始出现并逐渐扩大。与此同时，国企进入“减员增效”和改制重组阶段，部分企业通过人员分流、调整劳动关系等方式降低传统用工模式的负担，劳务派遣也逐渐成为灵活用工的重要方式之一。因此，国有企业确实是中国劳务派遣早期的重要需求方和推动力量。

2008年，《劳动合同法》正式确立劳务派遣制度。但随着制度快速发展，一些企业开始利用劳务派遣规避正式用工责任，出现“同工不同酬”“假外包、真派遣”“长期派遣”等问题。

2012年，《劳动合同法》修订后进一步强化监管，明确劳务派遣应主要用于“临时性、辅助性、替代性”岗位。2014年实施的《劳务派遣暂行规定》又明确，用工单位使用被派遣劳动者的数量原则上不得超过其用工总量的10%。中国劳务派遣制度由此开始从快速扩张转向严格规范。

PS：现实中，很多企业将劳务派遣统称为“外包”，但两者并不相同。一些所谓外包员工虽然劳动合同签在第三方公司，却长期在甲方工作，接受甲方直接安排、考勤和管理，本质上仍属于劳务派遣。这种“假外包、真派遣”现象，也可能被用于规避派遣岗位和用工比例限制。

劳务派遣并非中国独有。日本、美国、德国、法国等国家都存在类似制度，日本甚至形成了规模庞大的派遣产业。但不同国家的监管模式存在明显差异，通常围绕派遣岗位、使用期限、工资待遇、社会保障以及实际用工责任进行规范。

因此，真正的问题并不是“是否应该存在劳务派遣”，而是劳务派遣是否被企业异化为长期压低人工成本、规避劳动责任的工具。如果派遣工长期承担企业核心业务，却在工资、福利、晋升和职业保障方面长期低于正式员工，那么劳务派遣实际上就可能形成新的劳动身份分层。

从社会主义发展目标来看，劳务派遣制度本身并不天然与社会主义相违背。社会主义市场经济同样需要劳动力合理流动，也需要企业根据经营变化进行灵活用工。问题的关键在于，市场效率不能以牺牲劳动者基本权益为代价。

如果大量企业将派遣工长期固定在核心岗位，并形成身份分层、待遇分层和保障分层，那么问题已经不再只是灵活用工，而是劳动权益分配失衡。这确实会与共同富裕、劳动者权益保护以及劳动价值应得到尊重的社会目标形成矛盾。

未来，中国劳务派遣制度大概率不会取消，而是继续收紧和规范。核心方向应该包括：严格限制派遣岗位范围，落实同工同酬原则，压实实际用工企业责任，提高违法成本，并防止劳务派遣成为企业的基础用工模式。

长期来看，劳务派遣应当回归临时性和补充性的定位，而不是成为企业长期替代正式劳动关系的工具。只有在企业灵活用工需求与劳动者权益保障之间建立合理平衡，劳务派遣制度才能真正服务于经济发展，而不是制造新的劳动不平等。

思考：为什么劳务派遣、年龄门槛、编外人员与正式编制身份分层、长期临时工等用工做法，在政府机关、国有企业和公共部门同样普遍？作为以社会主义和劳动者权益保护为重要价值目标的国家，政府及国有企业为何也会采取这些容易造成劳动身份和待遇差异的用工方式？

#1271 NGINX 1.31.5 Predicate Location：从按 URL 路由到按条件路由

#1270 为什么 Linux 有优秀工程师，却缺少优秀的桌面产品？

Linux 在服务器、云计算等领域无处不在，也拥有大量优秀工程师，但桌面产品长期难以与 Windows、macOS 竞争。问题未必是技术能力不足，而是：

1. Linux 缺少一个真正对完整产品体验负责的主体。

   Windows 有微软，macOS 有苹果。界面不好用、软件体验不统一，最终都有人负责。

   Linux 则涉及内核、桌面环境、发行版、软件包和大量社区成员，常常是每个组件都有人维护，但整个产品没人负责。

2. 开源社区擅长技术决策，却不一定擅长设计。

   技术问题可以讨论、测试甚至投票，但审美和产品体验往往需要取舍。优秀设计必须有人敢说：“这个功能不需要，这个设计不行。”

   但社区文化强调包容和尊重不同需求，结果容易形成“功能越来越多，默认体验却越来越平庸”的局面。

3. Linux 有时会把技术路线放在产品体验之前。

   一个软件是否适合作为默认应用，讨论的不只是好不好用，还可能涉及许可证、Mono、微软等技术路线争议。

这也是 Omarchy 这类“强主张软件”受到关注的原因。像 Omarchy，由 DHH 直接决定默认桌面、快捷键和软件组合。用户当然可以修改，但默认答案只有一个。

Linux 桌面真正的问题不是民主，而是责任被稀释。可以广泛讨论，但产品最终必须有人拍板。

设计不是投票。Linux 擅长给用户选择，却不擅长替用户做决定。而优秀的消费级产品，往往不是提供最多选择，而是在无数选择中，坚持做出一个足够好的默认答案。

以上观点，根据微信公众号文章《Ubuntu设计团队往事：品味是如何死在投票箱里的？》整理。

#1269 ESP: Resend

Resend 不是传统的企业邮箱服务，而是一个面向开发者的 Email Infrastructure 平台，定位类似 SendGrid、Mailgun、Amazon SES。

#1268 主流 LLM API 风格详解：Chat Completions、Messages 与 Responses

目前主流大模型 API 大致有三种风格：OpenAI 的 Chat Completions / Responses（新版本）和 Anthropic 的 Messages。

#1267 独立开发者 MVP 工具链

微信推送的两种图片中展示了一个“独立开发者穷鬼套餐（2026版）”，我让 GPT 重新给我整理了一个版本：

程序主要运行在 Serverless / Edge 环境，依赖的数据库、KV 等服务也基本都是白嫖。

#1266 Stalwart + Bulwart Webmail 搭建邮件系统

• Stalwart Mail Server
  https://github.com/stalwartlabs/stalwart
  All-in-one Mail & Collaboration server. Secure, scalable and fluent in every protocol (IMAP, JMAP, SMTP, CalDAV, CardDAV, WebDAV).

  Stalwart 是采用 Rust 开发的开源邮件与协作服务器，集成 SMTP、JMAP、IMAP、POP3、Sieve，以及 CalDAV、CardDAV、WebDAV 等协议，同时提供反垃圾邮件、反钓鱼、DKIM/SPF/DMARC/ARC、OIDC、2FA、Prometheus 等能力。它既可以单机运行，也支持进一步扩展到集群。

• Bulwark Webmail
  https://github.com/bulwarkmail/webmail
  Self-hosted JMAP webmail for Stalwart Mail Server. Mail, calendar, contacts, and files in one client.

  Bulwark 是面向 Stalwart 的现代化自托管 Webmail，基于 Next.js 开发，以 JMAP 作为主要通信协议。除了邮件，还提供日历、通讯录和文件管理，并支持 SSO/OIDC、2FA、多账号、全文搜索、Sieve、PWA 等功能。

方案

可以采用 Stalwart Mail Server 作为邮件系统核心服务，Bulwark Webmail 作为统一 Web 邮箱前端，构建一套轻量、现代化、可自主管理的企业邮件平台。

整体方案的主要价值是减少邮件系统组件数量，同时保持标准协议兼容性。对于个人邮件、企业内部邮箱、小型邮件服务平台以及需要自建 Webmail 的场景，这套组合值得优先进行 PoC。

部署层建议采用 Docker Compose + Nginx。
DNS 配置 MX、SPF、DKIM、DMARC、PTR/rDNS，并根据实际业务配置 SMTP 出站策略。

mail.example.com
├── :25   SMTP
├── :587  Submission
├── :143  IMAP
├── :4190 Sieve 邮件过滤规则管理
└── :443  HTTPS（Nginx）
           ├── Stalwart JMAP
           ├── Stalwart CalDAV
           ├── Stalwart CardDAV
           ├── Stalwart WebDAV
           └── Bulwark Webmail

存储方面，初期可采用单机部署，邮件数据、索引和附件使用本地磁盘（嵌入式 KV 数据库 RocksDB）。

可以通过 Docker 部署 https://hub.docker.com/r/stalwartlabs/stalwart，也可以直接在服务器上安装：

curl https://get.stalw.art/install.sh -o install.sh
sudo sh install.sh

• /usr/local/bin/stalwart
• /etc/stalwart/stalwart.env
• /etc/stalwart/config.json
• /var/lib/stalwart/ (数据)
• /var/log/stalwart/ (日志)

#1265 AI 时代程序员的未来

AI 写代码已经越来越强，但截至目前，并没有出现有些人预言的大规模程序员失业潮。美国 BLS 数据显示，2025 年软件开发者就业人数约 168.8 万，预测 2025—2035 年软件开发者就业仍预计增长约 10%。

原因并不复杂：AI降低的是软件开发成本，而不一定降低软件需求。 当一个功能从过去需要3个人做一个月，变成一个程序员借助AI几天完成，公司未必选择裁掉3个人，也可能选择同时开发更多功能、尝试更多产品、服务更多客户。过去因为“开发成本太高”而放弃的需求，现在可能都变得值得做。

真正值得警惕的是，AI正在改变程序员内部的就业结构。

斯坦福数字经济实验室 2026 年 8 月基于数百万名员工的 ADP 工资数据发现，整体就业尚未出现大规模 AI 替代，但 22—25 岁、处于 AI 高暴露职业的年轻人，就业水平已经比低暴露职业同龄人低约 19%；而有经验的劳动者没有出现类似幅度的缺口。软件开发者属于 AI 暴露程度最高的职业之一，其中 22—25 岁开发者下降尤其明显。

这意味着，AI首先冲击的可能不是35岁以上的老程序员，而是原本负责简单CRUD、改页面、接接口、补测试的初级岗位。

那么，新老程序员应该何去何从？

• 新人不能再把“会写代码”当成核心竞争力。 AI已经可以承担大量基础编码工作，新人的价值必须从“执行任务”转向“理解问题”：

  • 学习计算机基础、数据库、网络、操作系统、工程规范，
  • 同时利用AI快速完成实现，并通过真实项目积累业务经验。

• 老程序员也不能躺在经验上。 AI确实放大了经验的价值，但前提是你能够驾驭AI。

  • 未来更值钱的能力，是架构设计、复杂系统排障、业务理解、技术决策、风险控制，
  • 以及把模糊需求转化成可靠系统的能力。

所以，AI时代真正危险的不是“老程序员”，也不是“年轻程序员”，而是只会写代码、却不知道为什么写，以及不会利用AI提高生产力的人。

三年前大家问的是“AI什么时候替代程序员”。现在更应该问的是：当代码越来越便宜之后，你还能解决什么过去解决不了的问题？这才是新老程序员真正需要回答的问题。

#1264 中国与俄乌战争

朝鲜、伊朗、白俄罗斯向俄罗斯提供了实质性的军事支援。朝鲜提供了武器和军队，伊朗提供Shahed系列攻击无人机及相关技术，帮助俄罗斯在本土建立了无人机生产体系。白俄罗斯则是提供领土、基地、后勤和军事设施。

中俄历史上存在领土争端、边界冲突和意识形态对立，例如沙俄时期的领土扩张、中苏交恶及珍宝岛冲突。但今天两国已经通过边界谈判解决主要领土问题。当前中俄关系更多建立在现实利益和战略合作基础上，而非传统意义上的军事同盟。

中国没有直接军事援助俄罗斯，主要是因为战略收益与潜在风险并不对称。俄罗斯对中国具有能源、地缘和战略价值，但如果向俄罗斯提供大规模致命性武器，中国可能面临美国及欧洲的制裁和次级制裁风险，影响对外贸易、金融体系和全球供应链，同时进一步卷入俄乌战争。

因此，中国采取的是“维持与俄罗斯合作，但不直接参战”的策略：继续能源贸易和正常经贸往来，对军民两用产品实施出口管控，同时保留外交斡旋空间。

从现实利益看，中国既没有必要为了俄罗斯的战争目标与西方全面摊牌，也不希望俄罗斯在战争中被彻底削弱。一个长期存在、具有较强军事能力且依赖中国经济合作的俄罗斯，对中国具有一定战略价值。这就是网友所说的“半死不活的毛熊才是好毛熊”。话糙理不糙，这背后其实就是大国之间复杂的战略利益：一个足以牵制西方、但没有能力威胁中国的俄罗斯，对中国的战略价值可能最大。

中国在俄乌战争中的作用可以概括为：没有直接参战，却在经济和供应链层面提高了俄罗斯的战争承受能力。

俄乌战争爆发后，俄罗斯受到西方大规模制裁，欧洲市场和部分供应链受到严重冲击。中国成为俄罗斯最重要的贸易伙伴之一。中国持续进口俄罗斯能源，同时向俄罗斯出口机械、汽车、电子产品以及部分军民两用商品，使俄罗斯能够维持相当规模的对外贸易、工业生产和经济循环。2026年1—7月，中俄贸易额达到约1590亿美元。

但必须区分“经济合作”与“军事援助”。目前没有可靠证据表明中国政府向俄罗斯提供大规模成套致命武器并直接用于乌克兰战场。西方国家主要关注的是中国企业向俄罗斯出口的无人机、电子元件、机床等军民两用产品。中国则强调这些属于正常贸易，并对军民两用物项实施出口管制。

更关键的是能源。中国长期进口俄罗斯石油、天然气等能源，为俄罗斯提供了重要的亚洲出口市场。虽然俄罗斯失去了部分欧洲市场，但通过扩大对中国等亚洲市场的出口，在一定程度上缓冲了西方制裁对其能源收入造成的冲击。

因此，中国对俄乌战争最大的影响并不是“替俄罗斯打仗”，而是通过贸易、能源和供应链合作，降低西方制裁对俄罗斯经济和工业体系的冲击。与此同时，中国也从俄罗斯能源和扩大对俄出口中获得了自身的经济利益。

#1263 朝鲜援俄与俄朝军事合作

俄罗斯与朝鲜的军事合作，真正大规模升级是在2023年以后。俄乌战争进入消耗阶段后，俄罗斯对炮弹和导弹的需求巨大，而朝鲜恰好拥有庞大的苏式口径弹药库存和生产能力。2023年起，朝鲜开始向俄罗斯大规模提供炮弹，随后又扩大到火箭炮弹、弹道导弹等武器。到2025年，韩国方面估计朝鲜已经向俄罗斯提供超过1200万发炮弹；俄罗斯部分部队在一段时期内甚至高度依赖朝鲜弹药。

朝鲜提供的不只是弹药。根据韩国、美国及乌克兰方面的评估，朝鲜还向俄罗斯提供了KN-23、KN-24等短程弹道导弹，以及火箭炮、重炮等装备。2026年8月，路透社进一步报道，朝鲜仍在向俄罗斯提供大量炮弹和短程弹道导弹，并出现朝鲜导弹部队部署到俄罗斯的情况。

真正具有战略意义的变化，是朝鲜开始直接派兵参战。

2024年秋季，朝鲜向俄罗斯派出约1.4万至1.5万名军人，主要参加库尔斯克方向作战。韩国情报部门和西方国家此前判断，这些部队主要来自朝鲜第11军，也就是著名的“暴风军团”。它并不是简单抽调几个连、几个营作为雇佣兵，而是以较大规模的成建制部队投入，但在俄罗斯战场上接受俄军统一指挥，因此不能简单理解为一个独立的朝鲜“军”在独立作战。

从公开信息看，朝鲜派出的核心作战力量更接近旅级规模的成建制战斗单位，并由更高层级指挥体系统一协调。不同阶段的部队规模有所变化，因此不能简单说“朝鲜派了一个师”或者“一个军”。2025年又出现增派约3000人的报告；随后朝鲜还派出工兵和军事建设人员，其中包括约1000名扫雷人员和5000名军事建设人员。

朝鲜部队参战的最大价值，并不是改变俄乌战争的战略平衡，而是帮助俄罗斯解决兵力和消耗战压力，同时获得极其宝贵的现代战争实战经验。朝鲜士兵第一次大规模面对无人机、电子战、卫星侦察、现代炮兵协同和高强度火力环境。韩国和美国认为，这些经验将直接反馈到朝鲜未来的训练和战术体系中。

代价也非常高。韩国情报部门2025年估计，朝鲜部队已经出现约4700人伤亡，其中约600人死亡、约2000人受伤后被送回朝鲜。也就是说，朝鲜实际上用人员伤亡换取现代战争经验和俄罗斯的战略回报。

那么俄罗斯给了朝鲜什么？

目前已经有比较明确证据的包括防空武器、电子战设备、无人机以及卫星和导弹技术支持。2024年11月以后，俄罗斯被报告向朝鲜提供了“铠甲”近程防空系统及电子战装备；联合国相关报告还称，俄罗斯向朝鲜提供了弹道导弹性能反馈，帮助改善其导弹制导表现。韩国方面同时判断，俄罗斯可能帮助朝鲜提升侦察卫星能力。

经济方面，俄罗斯也向朝鲜提供石油、粮食以及其他经济支持。2025年的韩国研究估算，朝鲜向俄罗斯提供的武器和人员价值可能达到约98亿美元，而俄罗斯直接给予朝鲜的补偿约12亿美元，主要包括能源、食品以及部分军事装备。这个数字属于外部机构估算，并非双方公布的官方结算数据，但可以说明双方交换的大致结构：朝鲜提供俄罗斯急需的“人和弹药”，俄罗斯提供朝鲜急需的“能源、粮食、技术和安全保障”。

2024年6月，普京访问平壤，两国签署《全面战略伙伴关系条约》，其中包含一方遭受武装侵略时，另一方立即提供军事及其他援助的条款。这意味着俄朝关系已经从过去的政治合作，正式升级为带有军事同盟性质的战略关系。

因此，这场合作真正值得关注的不是“朝鲜帮了俄罗斯多少”，而是双方正在形成一个互补体系：俄罗斯拥有能源、军工、导弹、航空航天和军事技术，却缺少部分弹药产能和人员；朝鲜拥有庞大的炮弹生产能力、可动员兵力，却缺能源、资金、先进技术和现代战争经验。

俄乌战争反过来成为朝鲜军队的一次“实战训练场”，而朝鲜则成为俄罗斯战争机器的重要外部补充。

这也是为什么俄朝关系近年来发展得如此迅速：俄罗斯得到的是可以直接用于战争的弹药和兵力，朝鲜得到的则可能是未来几十年影响其军事实力的技术、能源和实战经验。