❌

普通视图

发现新文章，点击刷新页面。
今天 — 2026年1月13日iOS

AT 的人生未必比 MT 更好 -- 肘子的 Swift 周报 #118

✇掘金 iOS
作者 东坡肘子
2026年1月13日 07:47

issue118.webp

AT 的人生未必比 MT 更好

学车时我开的是手动挡，起初因为技术生疏，常搞得手忙脚乱，所以第一台车就直接选了自动挡。但开了几年，我开始追求那种完全掌控的驾驶感，于是又增购了一台手动挡。遗憾的是，随着交通日益拥堵，换挡的乐趣逐渐被疲惫抵消，最终这台车也被冷落。算起来，我已经快二十年没认真开过手动挡了，但内心深处，我仍会时不时地怀念那段“人车合一”的时光。

随着 AI 深度介入我的工作与生活，我感觉自己的人生正从 MT 转向 AT。毫无疑问，AI 助我突破了许多能力瓶颈，也在熟悉领域带来了巨大的效率提升。但奇怪的是，我对它的“惊叹”却在与日俱减。看似它节省了我的时间，但我并未从这些“多出来的时间”里获得预期的满足感。也许是我对它的期望阈值不断提高，但一个不争的事实是：我已经有一段时间没有在学习和开发过程中，体会到那种单纯的快乐了。

幸好，几天前我又找回了这种久违的开心。在准备 iOS Conf SG 的 Keynote 时，由于 Keynote 在动画构建上相对“原始”且缺乏 AI 辅助，我难得地拥有一段完整的时间，去纯手工地尝试和修改。哪怕只是一个简单的并行动画，究竟是用转场、普通动画还是“神奇移动”，我都玩得不亦乐乎。那些在专家手里可能两三分钟搞定的设置，我折腾了大半天。尽管毫无效率可言，但我乐在其中。看着最终那个略显“简陋”的效果，我竟被自己感动了。

对于职场中人，效率和完成度固然是硬指标；但能否体会到过程带来的“实感”，或许才是作为“人”最朴素的追求。

我大概率不会再买 MT 的车了，但在我还能握紧方向盘的时候，也不会轻易让“智能驾驶”代劳。写代码也是如此，当初爱上它，正是因为它能给我带来纯粹的快乐。当所有工具都在催促我们变得更快更好时，我想应该给自己留一点变慢、变“笨”的空间——毕竟，AT 的人生未必比 MT 更好。

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

近期推荐

告别“可移植汇编”：我已让 Swift 在 MCU 上运行七年

从 2024 年开始，Swift 官方正式提供了对嵌入式系统的支持，但要在这个领域获得显著份额，仍有很长的路要走。其实，早在官方下场之前的 2018 年，Andy Liu 和他的 MadMachine 团队就开始在探索和实践将 Swift 应用于嵌入式领域，并陆续推出了相关硬件。他们坚信，在功能日益复杂的开发场景中，Swift 的现代语言特性将展现出巨大的优势。在本文中，Andy 分享了过去几年中在该领域的探索历程。我真心希望，Swift 能够在更多的场景中，展现其魅力。

在 SwiftUI 中构建基础拨号滑块组件 (Building a Base DialSlider Component in SwiftUI)

在 AI 功能越来越强大的今天，看到一个动效，让 AI 帮你实现已经越来越容易了。但每当看到开发者凭借自己的"奇思妙想"不断探索实现方式并打磨效果时，我仍会由衷赞叹。codelaby 在这篇复刻"老式电话拨号盘"的文章中，巧妙运用 SwiftUI 的 .compositingGroup() 和 .blendMode(.destinationOut) 实现了动态"镂空"效果，使旋转层下的静态数字清晰显现，相比单纯旋转图片更具灵活性和原生质感。此外，文章对环形手势处理、角度计算（atan2）以及限位逻辑（Stopper）的阐述也十分透彻清晰。

CKSyncEngine 答疑与实战经验分享 (CKSyncEngine Questions and Answers)

不少开发者对 Core Data 的 NSPersistentCloudKitContainer 颇有诟病，认为其不透明且缺乏定制性。但真正想自己着手解决 CloudKit 的数据同步问题时，才发现需要考虑的地方实在太多，难度远超想象。苹果在几年前推出的 CKSyncEngine 彻底打破了这个困境，提供了更清晰的状态管理和错误处理，并自动处理了诸多复杂的边缘情况，让开发者可以专心构建数据同步逻辑。

Christian Selig 通过自问自答的方式，分享了他在使用 CKSyncEngine API 时的经验，详细拆解了 CKSyncEngine 如何作为一个完美的中间层，在保留数据存储灵活性（你可以继续用 SQLite、Realm 或 JSON）的同时，接管了最令人头疼的同步状态管理。

我对 iOS 26 Tab Bar 的吐槽 (My Beef with the iOS 26 Tab Bar)

SwiftUI 在 iOS 18 中对 Tab Bar 的调整，其影响几乎堪比当年 NavigationStack/NavigationSplitView 取代 NavigationView，不仅改变了设计语言，对应用的实现方式和数据流走向都产生了颠覆性影响。而为 iOS 26 Liquid Glass 风格引入的"搜索标签"功能进一步推进了这种变革。Ryan Ashcraft 在这篇文章中直言不讳地指出了新 Tab Bar 设计的诸多问题：默认的浮动样式在某些界面中显得突兀，与应用整体视觉风格难以协调；新的边距和间距规则打破了长期以来的设计惯例，让开发者需要重新调整大量现有界面；更重要的是，这些改动并未明显提升用户体验，反而增加了适配成本。

我个人对新 Tab 的最大感受是，它会显著影响开发者在开发应用时对最低系统版本的决策。为 Tab 维护两套代码是否值得？如果为了简化实现而不得不将最低版本提高到 iOS 18，这或许正是 SwiftUI 团队的另一个设计意图？

Dia：深度剖析 The Browser Company 的 macOS 浏览器架构 (Dia: A Technical Deep Dive into The Browser Company's macOS Browser)

Arc 是第一个使用 Swift 构建的大型 Windows 平台应用，而且 The Browser Company 也因此为 Swift 社区的 Windows 工具链做出了突出贡献。在从 Arc 转型到 Dia 后，开发团队并没有放弃使用 Swift，那么 macOS 端的 Dia 具体使用了哪些开发框架呢？

Everett 在本文中揭示了 Dia 独特的技术架构：这是一个基于 AppKit + SwiftUI 的原生 macOS 应用，但其核心渲染引擎并非 WebKit，而是嵌入了自行修改的 Chromium（ArcCore）。此外，在 Dia 的二进制文件中发现了大量与本地 AI 相关的库（如 Apple MLX 和 LoRA 适配器），这预示着 Dia 并非只是为了"快"，而是已经为设备端 AI 推理做好了底层工程准备。

关于罗技开发者证书过期的迷思 (Myths about Logitech Developer ID certificate expiration)

几天前，不少 macOS 用户发现罗技鼠标的自定义按钮失效。由于控制台日志中充斥着代码签名（Code Signing）相关的报错，不少用户和媒体将其归咎于"苹果撤销了证书"。Jeff Johnson 通过分析系统日志为苹果在本次事件中的角色进行了平反：这并非苹果的证书服务故障，而是罗技自身软件工程问题导致的。Logi Options+ 的后台进程在更新后，未能通过 macOS taskgated 的代码签名有效性验证，从而被系统直接终止。这篇文章不仅是一份故障分析报告，更提醒开发者：在 macOS 严格的安全机制下，应用更新的签名验证流程容不得半点马虎。

“如果你的证书过期了，用户仍然可以下载、安装和运行用该证书签名的 Mac 应用程序版本。但是，你需要一个新的证书来签署更新和新申请。” —— 苹果官方文档

拒绝 LLM 生成的平庸代码 (Stop Getting Average Code from Your LLM)

不可否认，在人类长久以来累积的信息海洋中，高质量的数据与信息只占少数。对于个体来说，我们完全可以有目的地去甄别和学习这些优质内容。但是，受限于机制，LLM 默认倾向于训练数据的“平均值”，这就导致它生成的内容在各个方面都显得比较平庸。具体到 Swift 开发领域，这往往意味着它会生成大量旧版的、非结构化的代码。

要想获得高质量、符合 Swift 6 标准甚至特定架构风格的代码，关键在于对抗这种“回归均值”的本能。Krzysztof Zabłocki 详细介绍了如何利用 Few-Shot Prompting（少样本提示）和上下文注入技术，通过提供具体的代码范例和架构规范，强迫 LLM “忘记”平庸的默认设置，转而生成精准匹配项目标准的高质量代码。

工具

swift-effect: 一种基于类型驱动的副作用处理方案

Alex Ozun 长期关注 Swift 中的 类型驱动设计，这个库是他对“代数效应（Algebraic Effects）+ 处理器（Effect Handlers）”在 Swift 里的实践。 swift-effect 不是把副作用变成“数据结构再解释”，而是将副作用建模为可拦截的全局操作（@Effect），通过 handler 在运行时组合和替换行为，让业务代码保持线性/过程式风格，同时又能精细控制 I/O、并发等行为。

核心亮点：

  • 保持代码线性：调用 Console.print 等 effect 就像普通函数，但行为可由 handler 动态决定。
  • 无 Mock 的行为测试：用 withTestHandler 逐步拦截/断言 effect 序列，像“交互式脚本”一样测试流程。
  • 并发可控：支持对 Task/AsyncSequence 的确定性测试，解决并发顺序不稳定的问题。

Codex Skill Manager: 一款面向众多 CLI 的 macOS 工具

很多开发者都会同时使用多种 AI 编程服务，尽管它们拥有类似的概念、设定和工具类型，但在具体设置和细节描述上仍有差异，这导致开发者很难对所有服务进行统一管理。Thomas Ricouard 开发的 Codex Skill Manager 将 Codex、Claude Code（以及 OpenCode、Copilot）的技能集中在一个 UI 里查看、搜索、删除和导入，避免在多个隐藏目录中手动寻找。

核心功能

  • 本地技能：扫描 ~/.codex/skills/public、~/.claude/skills 等路径，展示列表与详情
  • 详情渲染：Markdown 视图+引用预览
  • 远程 Skill：Clawdhub 搜索/最新列表、详情拉取与下载
  • 导入/删除/自定义路径：支持从 zip 或文件夹导入、侧边栏删除、添加自定义路径
  • 多平台安装状态：为不同平台标记已安装状态

活动

LET'S VISION 2026｜邀请你与我们同行！

✨ 大会主题：Born to Create, Powered by AI

  • 📍 地点：上海漕河泾会议中心
  • ⏰ 时间：2026 年 3 月 27 日 - 3 月 29 日
  • 🏁 重点：汇聚顶尖创作者与 AI 技术大咖，共同探索 AI 应用的未来边界
  • 🌍 官网：letsvision.swiftgg.team

别走开！请关注官方账号和主理人 SwiftSIQI，我们将持续放送更多精彩内容！

Swift Student Challenge 2026

每年一度的学生挑战赛再次登场。挑战赛为数以千计的学生开发者提供了展现创造力和编程能力的机会，让他们可以通过 App Playground 呈现自己的作品，并从中学习在职业生涯中受用的实际技能。

今年作品提交通道将于 2026 年 2 月 6 日至 2 月 28 日开放。

往期内容

💝 支持与反馈

如果本期周报对你有帮助，请：

  • 👍 点赞 - 让更多开发者看到
  • 💬 评论 - 分享你的看法或问题
  • 🔄 转发 - 帮助同行共同成长

🚀 拓展 Swift 视野

iOS日志系统设计

✇掘金 iOS
作者 伟兮
2026年1月12日 16:34
软件系统的运行过程本质上是不可见的。绝大多数行为发生在内存与线程之中。在本机调试阶段，我们可以借助断点、内存分析、控制台等手段直接观察系统状态；而一旦进入生产环境，这些能力几乎全部
昨天 — 2026年1月12日iOS

AT 的人生未必比 MT 更好 - 肘子的 Swift 周报 #118

✇肘子的Swift记事本
作者 Fatbobman
2026年1月12日 22:00

学车时我开的是手动挡，起初因为技术生疏，常搞得手忙脚乱，所以第一台车就直接选了自动挡。但开了几年，我开始追求那种完全掌控的驾驶感，于是又增购了一台手动挡。遗憾的是，随着交通日益拥堵，换挡的乐趣逐渐被疲惫抵消，最终这台车也被冷落。算起来，我已经快二十年没认真开过手动挡了，但内心深处，我仍会时不时地怀念那段“人车合一”的时光。

Agent 模型的思维链是什么

✇bang’s blog
作者 bang
2026年1月12日 16:45

关于 Agent 模型的思维链，之前被几个高大上的词绕晕了，claude 提出 Interleaved Thinking（交错思维链），MiniMax M2 追随和推动标准化，K2 叫 Thinking-in-Tools，Deepseek V3.2 写的是 Thinking in Tool-Use，gemini 则是 Thought Signature（思考签名）。了解了下，概念上比较简单，基本是一个东西，就是定义了模型思考的内容怎样在 Agent 长上下文里传递。

是什么

在25年年初 deepseek 的轰炸下，思考模型大家都很熟悉了，在 Chatbot 单轮对话中，模型会先输出思考的内容，再输出正文。再早的 GPT-o1 也一样，只不过 o1 不把完整的思考内容输出。

在 Chatbot 进行多轮对话时，每一次思考的内容是不会再带入上下文的。每次到下一轮时，思考的内容都会被丢弃，只有用户 prompt 和模型回答的正式内容会加到上下文。因为在普通对话的场景下没必要，更倾向于单轮对话解决问题，长上下文会干扰模型，也会增加 token 消耗。

这些思考模型用到 Agent 上，就是下图这样，每次模型输出工具调用，同时都会输出 thinking 内容，思考应该调什么工具，为什么调，但下次这个思考内容会被丢弃，不会带入上下文：

Agent 的 loop 是：用户输入 → 模型输出工具调用 → 调用工具得出结果 → 模型输入下一步工具调用 → 调用工具得出结果 → …. 直到任务完成或需要用户新的输入。

这不利于模型进行多轮长链路的推理，于是 claude 4 sonnet 提出把 thinking 内容带入上下文这个事内化到模型，以提升 Agent 性能，上下文的组织变成了这样：

就这样一个事，称为 Interleaved Thinking，其他的叫法也都是一样的原理。

为什么要带 thinking

面向 Chatbot 的模型，倾向于一次性解决问题，尽量在一次 thinking 一次输出解决问题。

Agent 相反，倾向于多步不断跟环境( tool 和 user )交互解决问题。

Agent 解决一个复杂问题可能要长达几十轮工具调用，如果模型对每次调用工具的思考内容都抛弃，只留下结果，模型每次都要重新思考每一轮为什么要调这个工具，接下来应该调什么工具。这里每一次的重新思考如果跟原来的思考推理有偏移，最终的结果就会有很大的出入和不稳定，这种偏移在多轮下几乎一定会发生。

如果每一轮调用的思考内容都放回上下文里，每次为什么调工具的推理逻辑上下文都有，思维链完整，就大大减少了模型对整个规划的理解难度和对下一步的调用计划的偏差。

有没有带 thinking 内容，对效果有多大差别？MiniMax-M2 提供了他们的数据，在像 Tau 这种机票预订和电商零售场景的任务 benchmark 提升非常明显，这类任务我理解需要操作的步数更多（比如搜索机票→筛选过滤→看详情→下单→支付），模型在每一步对齐前面的思路很重要，同一个工具调用可能的理由随机性更大，每一步的思考逻辑带上后更稳定。

工程也能做？

这么一个简单的事，不用模型支持，直接工程上拼一下给模型是不是也一样？比如手动把思考内容包在一个标签(<think>)里，伪装成 User Message 或 ToolResult 的一部分放在里面，也能达到保留思考的效果。

很多人应该这样做过，但跟模型原生支持还是有较大差别。

工程手动拼接，模型只会认为这部分仍是用户输入，而且模型的训练数据和流程没有这种类型的用户输入和拼接，效果只靠模型通用智能随意发挥。

模型原生支持，训练时就可以针对这样规范的上下文训练，有标注大量的包含思考过程的 trajectory 轨迹数据训练，响应的稳定性必然会提升，这也是 Agent 模型的重点优化点之一。

签名

上述工具调用的 thinking 内容带到下一轮上下文，不同的模型做了不同额外的处理，主要是加了不同程度的签名，有两种：

thinking 内容原文，带签名校验

claude 和 gemini 都为 thinking 的内容加了签名校验，带到下一轮时，模型会前置判断思考内容有没有被篡改。

为什么要防 thinking 内容被篡改？毕竟 prompt 也可以随便改，同样是上下文的 thinking 内容改下也没什么。

主要应该是篡改了模型的 thinking 内容会打乱模型的思路，让效果变差，这也是需要避免的。

另外模型在训练和对齐时，已经默认 thinking 是模型自己的输出，不是用户随意的输入，这是两个不同类型的数据，如果实际使用时变成跟Prompt一样可随意篡改，可能有未知的安全问题。

不过国内模型目前没看到有加这个签名校验的。

thinking 内容加密

claude 在一些情况下不会输出自然语言的 thinking 内容，而是包在redacted_thinking里，是一串加密后的数据。

而 gemini 2.5/3.0 的 Agent 思维链没有明文的 thinking 字段，而是 thought_signature，也是一串加密后的数据。

用这种加密的非自然语言数据，一个好处是，它可以是对模型内部更友好、压缩率更大的数据表述方式，也可以在一些涉及安审的场景下内容不泄露给用户。

更重要的还是防泄漏，这就跟最开始 GPT o1 不输出所有思考内容一样，主要是为了不暴露思考过程，模型发布后不会太轻易被蒸馏。

最后

目前 claude 4 sonnet、gemini 3 在 Agent 工具调用的场景下，都强制要求带工具调用的思考内容和签名，这个链路正常是能很大程度提升整体的推理执行效果，是 Agent 多步骤推理的必需品。

但目前 Agent 模型的稳定性还是个问题，例如在某些场景下，业务逻辑明确需要下一步应该调工具 A，但模型思考后可能就是会概率性的调工具B，在以前是可以直接 hack 替换调工具调用，或手动插入其他工具调用，没有副作用。

但在思维链这套机制下比较麻烦，因为没法替模型输出这个工具调用的思考内容，一旦打破这个链，对后续推理的效果和稳定性都会有影响。

可能模型厂商后续可以出个允许上层纠错的机制，例如可以在某个实际告诉函数工具选择错误，重新思考，原生支持，弥补模型难以保障稳定的不足。

1月10日用户隐私保护新规出炉，政策解读

✇掘金 iOS
作者 CocoaKier
2026年1月12日 14:08

2026年1月10日，国家互联网信息办公室发布了《互联网应用程序个人信息收集使用规定（征求意见稿）》，进一步优化了个人隐私保护法案内容。

政策原文：mp.weixin.qq.com/s/epF6mh-Oc…

原文.png

一句话总结：这次的新政细化了隐私合规规则，堵住了一些规则漏洞，进一步保护用户隐私。对于大部分开展正规业务的开发者来说，无需特别的改动。后续可按渠道平台（华为、小米等）要求，做进一步调整。

内容概览：
1、明确禁止“无关场景调用相机/麦克风”，直击“偷听偷拍”乱象。——旧规：仅原则性要求“不得超范围收集”，但未明确哪些行为算违规。
2、位置权限分级管理：区分“实时定位”与“单次定位” ——旧规：仅笼统要求“最小必要”。
3、进一步强化了不允许获取用户全部相册权限，必须使用系统系框架Android SAF，只能获取用户授权后的部分照片。
4、操作系统厂商，需提供“精细化授权”选项，如 “仅本次允许”“仅今天允许”。
5、生物识别信息（人脸、指纹等）原则上只能本地存储，不能上传。除非法律允许或用户单独同意。
6、App运营者对第三方SDK负连带审核义务。用户向App提出对SDK的数据权利请求（如删除），App必须转达并督促SDK响应，不能再以“这是第三方SDK行为，与我无关”推责。
7、账号注销流程进一步简化：不得强制用户提供额外身份证明（如手持身份证、学历证明等）。堵住了一些App以“安全验证”为名设置注销门槛的做法。

下面是详细介绍

一、首次 明确禁止“无关场景调用相机/麦克风” —— 直击“偷听偷拍”乱象

  • 旧规：仅原则性要求“不得超范围收集”，但未明确哪些行为算违规。
  • 新规（第14条）：
    • 必须“用户主动选择使用拍照、语音、录音录像等功能时”才能调用相机/麦克风；
    • 禁止在用户停止使用相关功能后继续调用；
    • 禁止在无关场景（如浏览商品页、看新闻）调用音视频权限。

实质变化：这是首次以部门规章形式将“后台静默调用麦克风/摄像头”直接定性为违规。此前企业常以“预加载”“性能优化”为由辩解，今后不再成立。

二、位置权限分级管理：区分“实时定位”与“单次定位”

  • 旧规：仅笼统要求“最小必要”。
  • 新规（第14条）：
    • 实时定位类（导航、外卖） → 调用频率必须“限于业务最低频度”；
    • 单次定位类（搜索、推荐、广告） → 仅允许调用一次，且需用户进入界面或主动刷新；
    • 原则上禁止申请“后台持续获取位置”权限（除非法律另有规定或确需）。

实质变化：终结了“只要用户开了定位，App就可高频后台上报位置”的灰色操作。例如，电商App在首页展示附近门店，只能触发一次定位，不能持续追踪。

三、强制使用系统级存储访问框架（如Android SAF）

  • 新规（第14条）：
    • 用户上传图片/文件时，若系统提供标准存储访问框架（如Android的Storage Access Framework），App 不得再索要“相册”“存储”全权限。
    • 即使因文件编辑/备份获得存储权限，也不得访问用户未主动选择的其他文件。

实质变化：推动从“粗放式读取整个相册”转向“按需访问单个文件”，大幅降低隐私泄露面。这要求开发者重构文件上传逻辑。

四、操作系统需提供“精细化授权”选项（开发者需适配）

  • 新规（第14条）：
    • 操作系统在弹窗征得用户同意时，应提供基于时间、频度、精度的授权选项（如“仅本次允许”“仅今天允许”“模糊位置”）。

实质变化：虽然责任在OS厂商，但开发者需确保App能兼容这些细粒度授权（例如用户选择“仅本次允许位置”，下次使用需重新申请）。否则功能将异常。

五、生物识别信息默认本地处理，禁止网络传输

  • 新规（第15条）：
    • 人脸、指纹等生物特征信息，默认应在终端设备本地处理和存储；
    • 不得通过网络传输至服务器，除非：
      • 法律法规明确允许；或
      • 用户单独书面同意（且目的充分必要）。

实质变化：许多App当前将人脸照片上传服务器进行比对（如刷脸登录），今后必须评估是否真有必要。若非必要，必须改为本地验证（如Face ID/指纹API）。

六、SDK责任穿透：App运营者对第三方SDK负连带审核义务

  • 新规（第19条）：
    • App运营者必须审核嵌入的SDK，确保其行为符合公示规则；
    • 用户向App提出对SDK的数据权利请求（如删除），App必须转达并督促SDK响应。

实质变化：不能再以“这是第三方SDK行为，与我无关”推责。开发者需建立SDK准入机制，并保留沟通记录。

七、账号注销流程进一步简化（禁止设置障碍）

  • 新规（第18条）：
    • 注销后15个工作日内必须删除或匿名化数据；
    • 不得强制用户提供额外身份证明（如手持身份证、学历证明等）；
    • 若使用统一账号体系（如微信/QQ登录），必须支持单App注销，不影响其他服务。

实质变化：堵住了一些App以“安全验证”为名设置注销门槛的做法。

01-📝物联网组网 | 各类通信协议-知识体系导论

✇掘金专栏-没有故事的Zhang同学
作者 没有故事的Zhang同学
2026年1月12日 01:03
**物联网通信协议**是指在物联网系统中，用于实现`设备之间`、`设备与云端之间`数据传输和通信的标准化规则和约定。这些协议定义了`数据格式`、`传输方式`、`错误处理`、`安全机制`等技术规范，确保
昨天以前iOS

老司机 iOS 周报 #362 | 2026-01-12

✇iOS 老司机
作者 ChengzhiHuang
2026年1月11日 20:07

ios-weekly
老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

文章

🐎 我们如何使用 Codex 在 28 天内构建 Android 版 Sora

@Crazy：本篇文章简略的讲述了 OpenAI 的工程师团队是如何利用 CodeX 在 28 天内开发 Sora 的 Android 版本，主要可以分为以下四个部分

  1. 在 Codex 在整个代码库中创建和维护大量 AGENT.md 来引导新的开发工程师，减少重复的沟通和模版代码，增加测试量，让团队专注于架构、用户体验、系统性变更和最终质量。
  2. 利用项目的整体规则，编写部分具有代表性的端到端功能。通过将 Codex 指向具有代表性的功能，让 AI 在一个标准范围内工作，提高 AI 的生成准确性与工作效率。
  3. 在编写代码前使用 Codex 进行规划，利用相关文件并总结该功能的运作原理，即了解 CodeX 是如何从 API 到用户界面的生成过程，并且在生成后进行对应的架构纠正，利用这种可分享的动态策略让 CodeX 生成更加符合架构的代码。
  4. 同时运行多个 Codex 会话，一个会话负责回放，一个负责搜索，一个负责错误处理，还有一个则负责测试或重构。多会话会大大提高整体开发效率，并让开发人员处在审核的位置上，而不是开发的位置上。

最后是利用 CodeX 的上下文来让他发挥到最佳水平，也可以跨平台进行上下文分析，但没有上下文就是盲目猜测。

🐕 Tracking renamed files in Git

@Barney：本文聚焦 Git 不直接追踪文件重命名的核心特性，解析其通过文件内容相似度启发式算法推测重命名的逻辑。为确保历史追踪准确，核心建议将重命名单独提交，推荐借助 git mv 命令（暂存重命名操作、保留文件编辑未暂存状态）实现。同时提供替代脚本方案，解决无法使用 git mv 时，重命名与编辑同步进行导致的追踪难题，助力高效管理文件版本历史。

🐕 Replay

@Smallfly：这篇文章介绍了 Swift 生态中解决网络测试痛点的工具 Replay，通过记录与重放真实 HTTP 流量，为测试提供高效、稳定的解决方案。核心亮点包括：

  • 痛点解决：针对网络测试慢、依赖第三方服务不稳定、手动维护 JSON 响应文件易过时的问题，Replay 实现「记录一次，永久重放」，避免测试受网络波动影响。
  • 技术优势：采用行业标准 HAR（HTTP Archive）格式存储流量，兼容浏览器开发者工具、Charles 等工具；结合 Swift 6.1 的 TestScoping 协议与包插件，实现声明式测试配置。
  • 工作流程：首次运行测试时提示记录，后续自动使用本地 HAR 文件，测试速度从分钟级降至秒级。
  • 灵活配置：支持过滤敏感数据、自定义请求匹配规则，并提供内联存根功能，适配错误处理等边缘场景。

文章通过代码示例与实践建议，展示了 Replay 如何让网络测试更可靠、高效，是 Swift 开发者优化测试流程的实用参考。

🐎 Flutter 官方正式解决 iOS 26 上的 WebView 有点击问题

@david-clang：对于 Flutter WebView 在 iOS 26 点击失效和触摸穿透的问题，官方技术文档详细阐述了问题原因和解决方案，最终方案是 Flutter Engine + iOS embedder 新增 “同步 hitTest 回调” 能力，将手势决策从“异步协同”改为“同步拦截”，在触点处直接判断是否应拦截手势，从根本解决 WebView、AdMob 等 PlatformView 的手势冲突问题。

因为底层的重构方案还需要上层插件进行适配，官方又合入了个无需插件适配的临时方案作为补充：在 FlutterPlatformViews.mm 中实现了针对 WKWebView 手势识别器的递归搜索和“重启”机制，并在 blockGesture 中针对 iOS 26+ 启用了这个机制。

代码

React Native for macOS

@EyreFree：微软 react-native-macos 仓库值得关注！作为 Facebook React Native 的开源分支（MIT 许可），它支持用 React 快速构建原生 macOS 应用，兼容 macOS 11+。具备声明式 UI、组件化开发、热重载等优势，还能跨 iOS、Android 复用代码，配套完善文档与贡献指南，更新维护活跃，是 macOS 原生应用开发的高效选择，感兴趣的同学可以试试。

Skills Public

@含笑饮砒霜：这是一个聚焦于 SwiftUI UI 设计模式的代码仓库，核心围绕 SwiftUI 框架提供各类实用的 UI 实现方案、设计最佳实践和代码示例，面向 iOS/macOS 等平台开发者，旨在解决 SwiftUI 开发中常见的 UI 构建问题、统一设计范式。适合 iOS/macOS 开发者（尤其是 SwiftUI 初学者 / 进阶者），可作为 SwiftUI UI 模式的参考手册，快速复用成熟的设计和代码方案，避免重复踩坑。

内推

重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

iOS实现 WKWebView 长截图的优雅方案

✇掘金 iOS
作者 冰淇淋真好吃
2026年1月11日 00:26

在 iOS 开发中，为 WKWebView 实现长截图功能是一个常见且棘手的需求。开发者通常会遇到以下几个痛点：

  • 网页内容高度不确定
  • 滚动区域难以完整截取
  • 截图过程中的界面闪烁影响用户体验

本文将介绍一种高效、稳定的解决方案，通过分段渲染与图像拼接，完美捕获整个网页内容，并提供可直接集成的完整代码。

🎯 核心思路

我们的方案主要分为三个清晰的步骤：

  1. 布局调整：将 WebView 移至临时容器，为完整渲染做准备。
  2. 分段渲染：按屏幕高度分段捕获内容，生成多张切片图像。
  3. 图像拼接：将所有切片图像无缝拼接成一张完整的长图。

这种方法巧妙地绕过了直接截取 UIScrollView 的局限性，同时通过遮罩视图，保证了用户界面的视觉稳定性，避免闪烁。

💻 完整实现代码

WKWebView分类中添加长截图方法

  • WKWebView+Capture.h
#import <WebKit/WebKit.h>
#import <UIKit/UIKit.h>

NS_ASSUME_NONNULL_BEGIN

@interface WKWebView (Capture)

/**
 * 捕获 WKWebView 的完整内容并生成长截图
 * @param completion 完成回调，返回拼接好的长图（失败则返回 nil）
 */
- (void)captureEntireWebViewWithCompletion:(void (^)(UIImage * _Nullable capturedImage))completion;

@end

NS_ASSUME_NONNULL_END
  • WKWebView+Capture.m
#import "WKWebView+Capture.h"

@implementation WKWebView (Capture)

/**
 * 捕获 WKWebView 的完整内容并生成长截图
 * @param completion 完成回调，返回拼接好的长图（失败则返回 nil）
 */
- (void)captureEntireWebViewWithCompletion:(void (^)(UIImage *capturedImage))completion {

    // ⚠️ 关键：确保在主线程执行
    if (![NSThread isMainThread]) {
        NSLog(@"错误：WebView 截图必须在主线程执行");
        if (completion) completion(nil);
        return;
    }

    // 步骤1: 检查父视图并保存原始状态
    UIView *parentView = self.superview;
    if (!parentView) {
        if (completion) completion(nil);
        return;
    }

    CGRect originalFrame = self.frame;
    CGPoint originalContentOffset = self.scrollView.contentOffset;

    // 步骤2: 创建遮罩视图，保持界面"静止"的视觉效果，可以额外添加loading
    UIView *snapshotCoverView = [self snapshotViewAfterScreenUpdates:NO];
    snapshotCoverView.frame = self.frame; // 确保遮罩视图位置与 WebView 完全一致
    [parentView insertSubview:snapshotCoverView aboveSubview:self];

    // 步骤3: 创建隐藏的临时窗口和容器
    UIWindow *temporaryWindow = [[UIWindow alloc] initWithFrame:self.bounds];
    temporaryWindow.windowLevel = UIWindowLevelNormal - 1000; // 置于底层
    temporaryWindow.hidden = NO;
    temporaryWindow.alpha = 0;
    temporaryWindow.userInteractionEnabled = NO;

    UIView *captureContainerView = [[UIView alloc] initWithFrame:self.bounds];
    captureContainerView.clipsToBounds = YES;

    // 将 WebView 移入临时容器
    [self removeFromSuperview];
    [captureContainerView addSubview:self];
    [temporaryWindow addSubview:captureContainerView];

    // 步骤4: 获取完整内容高度并调整布局
    CGFloat fullContentHeight = self.scrollView.contentSize.height;
    self.frame = CGRectMake(0, 0, originalFrame.size.width, fullContentHeight);
    self.scrollView.contentOffset = CGPointZero;

    __weak typeof(self) weakSelf = self;

    // ⭐ 延迟执行，确保 WebView 内容布局与渲染完成
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.5 * NSEC_PER_SEC)),
                   dispatch_get_main_queue(), ^{
        __strong typeof(weakSelf) strongSelf = weakSelf;
        if (!strongSelf) {
            if (completion) completion(nil);
            return;
        }

        // 步骤5: 分段截图核心逻辑
        CGFloat pageHeight = captureContainerView.bounds.size.height; // 单屏高度
        CGFloat totalHeight = fullContentHeight; // 总内容高度

        NSMutableArray<UIImage *> *imageSlices = [NSMutableArray array];
        CGFloat offsetY = 0;

        while (offsetY < totalHeight) {
            CGFloat remainingHeight = totalHeight - offsetY;
            CGFloat sliceHeight = MIN(pageHeight, remainingHeight);

            // 处理最后一段高度不足一屏的情况
            if (remainingHeight < pageHeight) {
                CGRect containerFrame = captureContainerView.frame;
                containerFrame.size.height = remainingHeight;
                captureContainerView.frame = containerFrame;
            }

            // 移动 WebView，将当前要截取的区域"暴露"出来
            CGRect webViewFrame = strongSelf.frame;
            webViewFrame.origin.y = -offsetY;
            strongSelf.frame = webViewFrame;

            // 渲染当前分段到图像上下文
            UIGraphicsBeginImageContextWithOptions(
                CGSizeMake(originalFrame.size.width, sliceHeight),
                NO,
                [UIScreen mainScreen].scale
            );

            CGContextRef context = UIGraphicsGetCurrentContext();
            CGFloat scaleX = originalFrame.size.width / captureContainerView.bounds.size.width;
            CGFloat scaleY = sliceHeight / captureContainerView.bounds.size.height;
            CGContextScaleCTM(context, scaleX, scaleY);

            [captureContainerView.layer renderInContext:context];
            UIImage *sliceImage = UIGraphicsGetImageFromCurrentImageContext();
            UIGraphicsEndImageContext();

            if (sliceImage) {
                [imageSlices addObject:sliceImage];
            }

            offsetY += sliceHeight; // 移动到下一段
        }

        UIImage *finalImage = nil;

        // 步骤6: 图像拼接
        if (imageSlices.count == 1) {
            finalImage = imageSlices.firstObject;
        } else if (imageSlices.count > 1) {
            UIGraphicsBeginImageContextWithOptions(
                CGSizeMake(originalFrame.size.width, totalHeight),
                NO,
                [UIScreen mainScreen].scale
            );

            CGFloat drawOffsetY = 0;
            for (UIImage *slice in imageSlices) {
                [slice drawInRect:CGRectMake(0,
                                             drawOffsetY,
                                             slice.size.width,
                                             slice.size.height)];
                drawOffsetY += slice.size.height;
            }

            finalImage = UIGraphicsGetImageFromCurrentImageContext();
            UIGraphicsEndImageContext();
        }

        // 步骤7: 恢复原始状态
        [strongSelf removeFromSuperview];
        [captureContainerView removeFromSuperview];
        temporaryWindow.hidden = YES;

        strongSelf.frame = originalFrame;
        strongSelf.scrollView.contentOffset = originalContentOffset;
        [parentView insertSubview:strongSelf belowSubview:snapshotCoverView];
        [snapshotCoverView removeFromSuperview];

        // 步骤8: 在主线程回调最终结果
        if (completion) {
            completion(finalImage);
        }
    });
}

@end

📱 效果展示

长截图展示

🚀 使用方法

调用方式非常简单，只需一行代码。

// 在需要截图的地方调用
[webView captureEntireWebViewWithCompletion:^(UIImage *capturedImage) {
    if (capturedImage) {
        // ✅ 截图成功，处理结果
        // 例如：保存到相册
        UIImageWriteToSavedPhotosAlbum(capturedImage, nil, nil, nil);
        // 或：上传、分享、预览等
    } else {
        // ❌ 截图失败
        NSLog(@"截图失败");
    }
}];

📝 总结

本文提供的方案通过以下关键技术，优雅地解决了 WKWebView 长截图的难题：

  • 临时容器管理：隔离渲染环境，避免干扰主界面。
  • 分段渲染：将长内容分解为多个可管理的屏幕片段。
  • 状态恢复：完整保存并恢复 WebView 的原始状态，确保业务无感知。

如果你有更好的实现思路，或在实际应用中遇到了特殊场景，欢迎在评论区分享交流！

「共」型人才：AI 时代的个体进化论

✇Limboy
2026年1月11日 08:00

当 AI 能够完美代劳记忆型事务、高效处理逻辑琐事时，一个焦虑也随之而来：作为个体，我们的核心竞争力究竟还剩什么？

传统的「T」型或「π」型人才理论，关注的是技能树的形状（深度与广度），在 AI 时代，这两个模型的达成路径和价值权重发生了根本性变化。于是我构想出了一个「共」型人才理论，这可能更符合 AI 时代对个体的要求。

什么是「共」型人才？

将「共」字拆解：

  • 下半部分（基石）： 决定了一个人的底盘。只要基石稳固，即便行业被 AI 颠覆，也能迅速在新土壤中扎根。
  • 上半部分（建筑）： 决定了一个人的高度。这是利用 AI 杠杆构建的双专业壁垒，以及独属于人类的整合创造力。

第一部分：基石（下半部）—— 内核的修炼

基石分为左右两点的「生命力」、「元能力」，以及承载它们的「职场通用力」。

一、左边的点：生命力（韧性）

这是个体的反脆弱系统。在快速变化的 AI 时代，比拼的往往不是谁跑得快，而是谁在逆境中不崩盘，并能从混乱中获益。

1. 情绪调节能力

即对他人的情绪有觉察，对自己的情绪有掌控。面对批评或压力，能迅速通过深呼吸、肌肉放松等技巧避免被情绪劫持。也能够穿透情绪的迷雾，看到对方发火背后的真实需求，将冲突转化为增进信任的契机。

2. 认知重构能力

决定我们情绪和行为的，往往不是发生的事情本身，而是我们对这件事情的看法（认知）。认知重构就是给大脑换个滤镜。这不是「阿Q精神」式的自欺欺人，而是用更具适应性的视角替代单一的消极视角。

比如朋友圈经常看到某某在外面玩，就很羡慕甚至有点嫉妒，这是下意识的反应，但不是完整的视角。更完善的思考可能是：

  • 经常在外面玩其实也挺累的，可能光顾着拍照了，没有很好的感受当地的风景和文化。
  • 辛苦劳作后的休憩最为舒适，经常玩，新鲜感和愉悦感就没那么强了。
  • 人家无论是通过家里的支持或自己的努力赢得了经常出去玩的机会，这也是应得的。

3. 课题分离能力

这是切断精神内耗的利刃，他的核心是：分清楚什么是你的事，什么是别人的事。专注解决自己的事，不过度干预别人的事，并接受「我无法控制别人，别人也无法控制我」这一事实。我能控制的是我的态度和行为，我不能控制的是别人的评价和结果。就像你可以把马带到河边（你的课题），但不能强按着马头喝水（马的课题）。

4. 求助能力

求助不是示弱，而是懂得利用外部资源扩展生存边界。通过向合适的人寻求支持，不仅解决了问题，更建立了一次潜在的高质量的社会连接，这是构建韧性网络的重要一环。

二、右边的点：元能力

元能力对应的是学习能力。用来构建知识网络，增强调用和处理知识的能力，以下是我觉得最为重要的 4 种元能力。

1. 认知性好奇心

这个我认为是最重要的，它不是单纯的想知道 What 的感知性/消遣性好奇心，而是对运行机制、底层原理的好奇，关注的是 How 和 Why， 追求的是填补认知空白和解决智力上的难题。

认知性好奇心产生于「我知道一点，但又不知道全部」的时候， 这个差距会带来一种类似「认知瘙痒」的不适感， 学习的过程，就是「止痒」的过程，所以最好的学习区，是在「已知」和「未知」的边缘。

2. 专注力

如果把学习比作「吃饭消化」，那么专注力就是「牙齿」和「食道」。它决定了你能把多少食物（信息）吃进嘴里，以及嚼得有多碎，但前提得先张开嘴巴，因为未被关注的信息，大脑不会存储。

如果注意力的强度不够，效果也不会好，就像在沙滩上写字，潮水一来就没了。只有在高强度的专注下，神经元才会高频放电，突触之间的连接才会变强，所以，专注力是一个很重要的能力。

3. 思维模型

思维模型就像是安装在大脑里的「应用程序」或「工具箱」。拥有一套多元化的模型组合（查理·芒格所谓的「格栅理论」），能在面对复杂问题时更有洞察力。以下是我认为最重要的一些思维模型。

第 0 类：元思维模型
  • 系统思维： 帮助理解「事物之间如何连接」的宏观框架，而不是割裂地看问题，主张看整体、看动态。核心元素： 反馈回路、存量与流量、瓶颈理论、滞后效应。
  • 结构化思维： 能够将复杂的信息、问题进行逻辑拆解、分类和整理的能力。 非结构化思维就像走进一个堆满杂物的仓库，书本、衣服、工具混在一起，你想找把锤子，可能要翻半天。 结构化思维就像走进一个管理完善的图书馆或药房。每一个区域都有分类，每一层架子都有标签，你能迅速定位并解决问题。
  • 抽象思维： 透过现象看本质的能力， 将我们感知到的具体事物，剥离掉细节，提取出其共同规律、本质特征或概念的思维过程。
第 1 类：提升决策质量（如何思考）
  • 第一性原理：打破一切既定的假设和类比，将问题拆解成最基本的事实（公理），然后从这些基本事实出发重新构建解决方案。
  • 逆向思维： 许多难题正向思考很难，反过来想就容易了。不仅要问“我如何获得成功？”，更要问“我如何才能避免失败？”。
  • 二阶思维： 吃甜食的直接后果是快乐（一阶），但二阶后果是血糖升高、长期可能导致肥胖。为了长期的健康，可能会需要放弃短期的一阶快乐。
第 2 类：提升效率与效能（如何行动）
  • 帕累托法则 (80/20 Rule)： 在任何一组东西中，最重要的只占一小部分。约 80% 的产出源自 20% 的投入。
  • 复利效应： 只要坚持做正确的事，时间的加成会带来指数级的增长。这不仅适用于理财，更适用于知识积累、习惯养成和人际关系。
第 3 类：理解世界与自我（如何自处）
  • 地图不是疆域：地图只是对疆域的一种描绘，它永远无法包含疆域的所有细节。如果你看着地图以为这就是真实世界，你就会在现实中迷路。
  • 概率思维： 世界不是黑白分明的，而是由概率构成的灰色地带。不要追求 100% 的确定性，而要追求大概率正确的决策。
  • 汉隆剃刀： 能解释为愚蠢的，就不要解释为恶意。 同事没有回你邮件，不要觉得他是故意针对你（恶意），很可能只是他太忙漏看了或者系统出错了（疏忽/愚蠢）。这能帮你减少 90% 不必要的愤怒和冲突。

4. 认知偏误管理

认知偏误是大脑为了节省能量而采取的「思维捷径」。虽然它们在进化上曾帮助人类快速反应，但在现代复杂的决策环境中，它们往往会导致我们犯错。

第一维度：关于「自我认知」
  • 达克效应： 这是关于「无知者无畏」的经典解释。能力不足的人往往无法认识到自己的不足，因此会产生过度的自信；而真正的高手反而容易低估自己。
  • 确认偏误： 我们倾向于寻找、解释和记忆那些能够证实我们已有观点的信息，而自动过滤或忽略那些反驳我们的信息。
第二维度：关于「决策陷阱」
  • 沉没成本谬误： 我们会因为已经投入了时间、金钱或情感，而坚持继续做一件不理智的事情，即使它已经没有未来的价值。
  • 锚定效应： 我们在做判断时，极易受到获取的「第一条信息」（锚点）的影响，即使这个信息可能毫无关联。
第三维度：关于「看待世界」
  • 基本归因谬误： 就是我们在解释别人的行为时，倾向于高估其「内在性格」的影响，而低估「外部环境」的作用。 我们会想： “他做这件事，是因为他就是这种人。”。我们忽略：“他做这件事，可能是因为当时的情况迫使他这么做。”。
  • 幸存者偏差： 我们只看到了经过筛选后「活下来」的样本，而忽略了那些「死掉」的样本，从而得出错误的结论。

三、下面的一横：职场通用力

这是无论技术如何变迁，人与人协作都必须具备的接口协议。

1. 沟通能力

沟通能力是一个涵盖了输入、处理、输出、反馈四个维度的闭环系统，是一个高度复杂的复合能力。

  • 输入： 积极倾听，听懂话外音；敏锐观察，捕捉非语言信号。
  • 处理： 用同理心换位思考，用逻辑整理杂乱信息。
  • 输出： 精准表达，甚至用故事力包装枯燥逻辑。
  • 互动： 懂得即时反馈与冲突管理，将对抗转化为对话。

2. Sell 的能力

如果沟通能力是底层的基础设施（地基），那么 Sell 能力是在这个地基上盖起的、带有明确目的性的建筑。一个人可以沟通很好，但不会 Sell；但一个擅长 Sell 的人，一定是沟通的高手。

  • 认知引导： 沟通是基础，Sell 是目的。Sell 的本质是改变对方认知，促成决策。
  • 缔结结果： 不止于聊得开心，更在于能把对话推向一个确定的结论（Call to Action）。一个拥有 Sell 能力的人，具备更强的心理能量和目标导向。

3. 闭环思维

它不仅指把事情做完，更指把「事情做完」这个结果反馈给发起者，从而形成一个完整的圆环。也就是常说的： 凡事有交代，件件有着落，事事有回音。 如果没有「反馈」，这个环就是断裂的。在他人眼中，这就像把石头扔进深井里，听不到回声，不知道事情是成了、败了，还是被忘了。

4. Ownership

Ownership 精神的核心是：不给自己设限，着眼于全局目标，主动填补团队的「真空地带」。比如大家都在一条船上，船底漏了个洞。 打工心态：指着洞说“这不是我弄坏的，而且修船是维修工的事”，然后看着船沉。Ownership：哪怕不是我弄坏的，我也先想办法堵上，因为船沉了对谁都没好处。

有 Ownership 精神是好事，但需要很小心地处理好边界。

  • 是「负责结果」，不是「包揽一切」：Ownership 不代表你要亲自做每一件事，而是你要确保事情发生。如果资源不足，向老板争取资源、协调其他人来做，也是 Ownership 的体现。
  • 注意「越位」风险：当你插手别人负责的领域时，沟通方式很重要。不要直接替别人做决定，而是以「补位」和「协助」的姿态切入（例如：“我发现这里有个风险，需不需要我帮忙一起看一下？”）。
  • 自我保护：不要让 Ownership 成为别人甩锅给你的理由。在承担额外责任前，确保你的核心本职工作已经完成得很漂亮。 ⠀

第二部分：建筑（上半部）—— AI 时代的双核驱动

这部分是「共」型人才的核心差异点。在 AI 出现之前，成为「双专业人才」极难；但在 AI 时代，这变得触手可及。

一、两竖：AI 赋能的「双专业壁垒」

这两根柱子代表你在两个不同领域的专业深度。

1. 传统困境 vs. AI 破局

  • 过去（一万小时定律）： 想要跨界（例如从营销跨到编程），需要耗费数年去记忆语法、熟悉框架 API、调试环境。极高的沉没成本让大多数人望而却步，只能停留在「T」型（一专）。
  • 现在（AI 杠杆）： AI 极大地抹平了「硬知识」的门槛。
    • 以编程为例： 你不再需要背诵复杂的 API 或纠结于标点符号的 bug。AI 是你的超级助手，你可以更专注在架构设计（Architecture）、逻辑拆解和Prompt 指令。
    • 以设计为例： 你不需要精通每一笔的光影渲染，你更需要具备审美标准和创意构想，剩下的交给生成式 AI。

2. 新时代的「专业」定义

在 AI 的加持下，这两竖的构建不再依赖死记硬背，而是依赖：

  • 理解力与判断力： 你必须懂行，才能判断 AI 给出的结果是 60 分还是 90 分。
  • 逻辑互补性： 选择两个具备「中度相关性」的领域效果最佳。例如：心理学 + 算法，内容创作 + 数据分析。

AI 使得获取第二专业的成本指数级下降，为个体提供了前所未有的理论与工具支撑，让「共」型人才成为可能。

二、上面的一横：整合力

这是机器难以替代的人类高地。如果下面的一切是积木，那么这一横就是让积木变成摩天大楼的蓝图。它是 「1 + 1 > 2」 的化学反应。

1. 翻译器：降维打击沟通墙

在组织中，这种双语能力，可以让你在团队协作中成为了「节点型」人物，极大地降低了系统内的熵（混乱度）和沟通成本。

2. 迁移器：跨界降维打击

你拥有单领域专家不具备的独特视角。你可以拿着 A 领域的锤子（方法论），去解决 B 领域那颗顽固的钉子。这种跨界打击往往能产生奇效。

3. 孵化器：边缘创新的温床

当你打通了两根竖线，中间的空白地带就是创新的温床。

  • 懂代码 + 懂法律 智能合约专家 / 计算法学
  • 懂心理 + 懂产品 行为设计 / 增长黑客

结语

在「共」型人才模型中，AI 不再是我们的竞争对手，而是我们构建那「第二根竖线」的最强杠杆。

  • 下半部分（情绪、认知、沟通）让我们保持像人一样思考，拥有机器无法模拟的温度与韧性。
  • 上半部分（双专业整合）让我们像超级个体一样行动，利用 AI 快速拓展能力边界。

这不仅是职场竞争力的提升，更是一种更自由、更广阔的人生可能。

❌
❌