Posts

iOS 的 UISwipeActionsConfiguration API 自 iOS 11 以来几乎没有进化：按钮宽度固定、无法精确控制间距、视觉样式只支持 image + backgroundColor。本文记录通过 swizzle + KVC 的方式，在不重写整个 swipe 容器的前提下，精准扩展这些能力。

在 C 语言中， 常被翻译为“联合”或者“联合体”。它和 一样都可以声明多个成员，但两者的内存模型并不相同。 的关键不在于“同时拥有多个成员”，而在于多个成员共用同一块内存。

对于已经有静态类型语言经验的开发者来说，学习 TypeScript 的难点通常不在基础语法，而在于类型系统视角的切换。真正决定上手速度的，往往不是记住多少语法点，而是有没有先建立起正确的理解框架。

前五篇一直沿着同一条主线推进：先把任务说清楚，再让输出更稳定，再定义输入输出接口，再把复杂任务拆成流程，最后开始从工具和上下文的角度理解系统。继续往下，会遇到另一个容易被低估的问题：一个 Prompt 即使已经能跑通，也不代表它真的可上线、可维护、可长期使用。

前四篇一直沿着同一条主线推进：先把任务说清楚，再把输出收窄，再把返回结构定义清楚，再学会把复杂任务拆成流程。继续往下，会遇到一个新的问题：当模型不只是回答问题，而是要调用工具、读取上下文、访问外部知识、在多个步骤里持续动作时，Prompt 还只是“写一句话”吗？

前三篇分别在解决三个问题：第一，怎么把任务说清楚；第二，怎么让结果更稳定；第三，怎么把行为边界和输出契约定义清楚。继续往下，会遇到第四个问题：如果任务本身就不是单步能完成的，那么一个 Prompt 写得再完整，是不是仍然不够？

前两篇分别讨论了两件事：第一，Prompt 不是聊天技巧，而是结构化输入设计；第二，想让模型真正接入系统，就必须让输出更稳定。继续往下，会遇到第三个问题：如果目标不只是“答得差不多”，而是“行为边界清楚、输出结构稳定、结果能被程序消费”，Prompt 还需要向什么方向推进？

上一篇的核心结论是：Prompt 不是聊天技巧，而是结构化输入设计。这个视角解决了“怎样把任务说清楚”的问题，但当模型真正接入系统之后，还会遇到第二个问题：任务已经说明清楚，输出为什么仍然不稳定？

如果把大语言模型当成一个聊天对象，Prompt 的学习方向就很容易偏向“怎么说更像咒语”，而忽略“怎么让结果更稳定、更可控”。在 AI 应用开发场景里，Prompt 更适合被理解为一种接口设计能力，也可以把它视为一种写给模型的接口协议。

队列（Queue）是一种遵循先进先出（FIFO，First In First Out）原则的线性数据结构。在 iOS 开发中，我们经常需要使用队列来处理各种场景，比如：任务调度、消息队列、事件处理等。

MMap（Memory Mapping）是一种内存映射技术，它允许将文件或其他对象映射到进程的地址空间。在 iOS 开发中，mmap 是一个强大的系统调用，能够将磁盘文件的内容直接映射到内存地址空间，使得对文件的读写操作可以像访问内存一样简单高效。

循环数组（Circular Array），也称为环形数组或环形缓冲区（Ring Buffer），是一种特殊的数组结构。它在逻辑上将数组的首尾相连，形成一个环形结构。当数组索引到达末尾时，会自动回到数组的开头，实现循环访问。