KeyChan's blog

1. 为什么代码越写越多，反而离能赚钱的产品越远？

在工程环境里，评价一段工作的标准通常很清晰：逻辑是否严密、功能是否完整、结构是否合理、系统是否稳定。只要这些条件成立，就可以认为“做得不错”。

但当同样的标准被带入个人产品或创业项目时，结果往往令人困惑：投入了大量时间，写了很多代码，技术上几乎没有明显短板，产品上线后却几乎没人用，更谈不上付费。

这并不是因为技术不够好，而是因为工程问题和产品问题本质上并不是同一类问题。用解决工程问题的方式去做产品，往往会在一开始就偏离方向。

1. 布局与布线设计：系统稳定性的第一道约束

系统集成并不是从接线或上电开始，而是从空间与结构层面的约束开始。 对于无人机而言，布局与布线并非单纯的机械装配问题，而是决定系统稳定性、电磁环境可控性以及后续调试难度的基础工程环节。本章从系统工程视角出发，讨论布局与布线在无人机系统集成中的核心作用，并阐明其对飞控算法、传感器可靠性以及通信稳定性的深远影响。

在系统生命周期中，布局一旦确定，后续可调整的空间将急剧收缩。因此，合理的布局与布线设计，本质上是在系统早期为稳定性与可维护性预留自由度。更进一步，布局与布线决定了系统中干扰源如何产生、如何传播以及如何被感知，从而决定后续软件配置与参数调节的难度上限。为了使讨论具有工程可复用性，本章在原则陈述之外，将若干关键点表达为可复核的空间与走线约束，使其能够在装配阶段被直接检查与确认。

1. AI 带来的阅读悖论：更快，却更空洞

我们已处于一个新的阅读环境中：很多时候，章节还没细读，就已经能知道要点，书还没读完，就已经知道它要说什么。 AI（大语言模型）在进入知识生产与传播之后，不只改变了写作，也在悄悄重塑阅读——尤其是非虚构阅读。它能把一个章节快速压缩成要点，能把复杂推理变成顺滑的叙述，把原本需要耐心理解的内容，提前整理好。

这提高了效率，但当它成为默认选项时，一个新的问题开始出现：阅读的速度是在加快，理解的深度却可能在变浅。读得更快却不等于理解得更好。

1. 视觉分割任务回顾：从像素预测到结构理解

视觉分割是计算机视觉体系中一类基础而关键的任务。与图像分类主要回答“图像中包含哪些语义概念”不同，分割进一步要求回答“这些对象在图像中的具体位置、形状与边界是什么”。这意味着分割并非以整幅图像或候选框为单位进行判断，而是直接作用于像素层面，需要对图像中每一个像素给出明确的归属结果。

正因为输出粒度从“区域”细化到“像素”，视觉分割不仅考验模型的语义理解能力，更对其空间表达能力、上下文建模能力以及结构化预测能力提出了更高要求。在进入可提示分割与通用分割模型的讨论之前，有必要首先对分割任务本身的定义、输出形式以及任务类型进行系统回顾，从而为后续模型结构与问题设定的演进奠定清晰而统一的概念基础。

回看整个 2025 年，感觉这一年很难用具体结果来概括。更多时候，我还是在投入去做一件不太显眼、却有点基础的事情：在 AI 的辅助下，重新整理学习新事物的方式。

1. 逐渐理解“广泛”的价值

这一年，我对“学习”本身的看法有了一些变化。过去，我更习惯把学习理解为获取知识点，但在实际过程中逐渐发现，这样的理解有些片面。真正影响学习效率的，似乎并不是知道了多少信息，而是这些信息在大脑中是否能够形成稳定的连接，并且在适当时候否能被成功调用。

从这个角度看，学习更像是在不断构建的网络。每一次学习，本质上都是在神经元之间建立新的连接，或强化已有的连接。当连接逐渐增多、结构逐渐清晰，新东西带来的认知负荷就会减轻，理解也会变得顺畅一些。

1. 地面站的角色与系统位置

无人机的飞行并不是由单一模块“完成”的。飞控依靠高速传感器与控制算法维持姿态稳定；任务系统通过算法或人工设定飞行目标；机体结构与动力系统负责把这些指令转化为推力与力矩。除此之外，还有一个位置很特别、却经常被低估的环节——地面站（Ground Control Station, GCS）。

地面站不是飞行之外的附属软件，更像无人机系统的外环控制中心：状态如何被看见、参数如何被管理、任务如何被配置、风险如何被提前预知处理，几乎都从这里进入。把它放回系统整体去理解，是构建可靠无人机体系的第一步。

1. DETR 出现的原因

在目标检测的发展历程中，YOLO 与 DETR 往往被视为两种截然不同的技术路线，其差异不仅体现在网络结构或训练策略上，更反映了对“目标检测这一问题应当如何建模”的根本理解差别。

直观而言，YOLO 系列方法遵循的是一种密集预测思路：模型在图像的各个空间位置上独立判断是否存在目标，并同时回归其类别与边界框位置。这种做法强调局部决策与并行计算，因而具备极高的推理效率，但也不可避免地会对同一目标产生多次冗余预测，必须借助非极大值抑制等后处理机制进行去重。具体可参考： 物体检测评估指标和YOLO-v1实现思路

1. 从物理世界到“可控信息”——飞控软件的使命

在前几篇内容中，我们已经从系统工程视角初步对无人机有了一定的理解，从空气动力学角度探讨了“为什么能飞”，从传感器与硬件角度认识了无人机如何感知世界，并在控制算法篇中建立了“飞控如何决策与调节”的基础框架。

然而，所有物理量、传感器读数与控制规律最终都必须通过软件进行组织、调度与执行，才能形成一个真正稳定、可控的飞行器。本章从软件角度展开，属于飞控软件的基础部分，为保证后续章节的连贯性，建议完整阅读，使后续的体系结构、调度机制、通信框架等内容更易衔接。

1. 为什么 async/await 不能解决并发问题

Swift Concurrency 带来的第一个直观变化，是 async/await 让异步调用读起来像同步代码。之前一长串回调嵌套，现在可以按顺序写清楚：先请求网络，再解析，再更新状态。但在真实项目里，异步“写起来舒服”只是表面，很多时候真正的痛点不在于“怎么写异步逻辑”，而在于“多个任务同时访问同一份状态时发生的问题”。线程变多、任务变多、入口变多之后，只要可变状态没有明确的限制，就可能带来问题。

获取服务端配置就是一个非常典型的并发场景：有本地缓存，有后台刷新，有多处调用，有UI依赖结果，还有可能叠加服务端推送。表面上只是“拉一份配置下来”，但内部状态在多个任务之间来回穿插，如果不做隔离，async/await 并不能有效处理这些逻辑。

1. 为什么 UIKit 项目也需要现代异步能力？

现在的应用，无论是前端、Flutter 还是移动端原生，都有一个共同趋势：异步操作越来越多、界面状态变化也越来越频繁。Web 有 async/await + Promise 统一异步流程，用事件流和状态管理驱动 UI；Flutter 用 sync/await + Future/Stream 处理异步，用 BLoC、Provider、Riverpod 聚合状态并更新界面。这些体系之所以能稳定，是因为都遵循了同一种现代异步模型：异步逻辑线性化、事件流可组合、UI 完全由状态驱动。

UIKit 项目同样也面临这些问题，随着 Swift Concurrency、Combine 和 @Published 逐渐成熟，UIKit 也具备了和 Web、Flutter 类似的现代异步能力：async/await 负责逻辑，Combine 管事件流，状态集中在 ViewModel，由 UI 自动响应变化。