本文作为 AI协作工程 系列的起点，想回答的不是“有哪些好的 AI 编码工具”，而是一个更基础的问题：当 Coding LLM 进入开发流程之后，软件开发到底是怎么被重新组织起来的。全文会围绕三个主题展开：先界定 Coding LLM 为什么不同于普通聊天模型，再解释为什么理解 LLM 的工作机制 是学习 prompt 的前提，最后通过 Ollama、本地模型和三个小案例 few-shot、chain-of-thought、tool calling，说明 agent 更适合被理解为 prompt 工程进一步工程化之后的结果。
自主飞行系统的智能程度，首先受限于其对环境的感知能力。无论后续定位、规划或控制算法多么复杂，如果输入的信息本身不稳定、不完整或不可用，系统整体都将建立在不可靠的基础之上。因此，在讨论自主飞行之前，有必要首先厘清一个核心问题：无人机在工程意义上究竟“看到”了什么，又能在多大程度上信任这些信息。
与人类直觉中的“看见”不同，无人机的环境感知并非对现实世界的直接理解，而是通过一组传感器对物理量进行采样、处理与抽象后的结果。这种结果往往是不完整的、带噪声的，且强烈依赖具体应用场景。本章将从工程角度出发，系统性地分析自主飞行对感知信息的真实需求，不同传感器所提供的数据特征，以及在实际系统中感知模块的布置原则与失效风险。
在 CLIP 出现之前，让计算机同时“看懂图像、理解文字”，其实已经是一个被研究了很多年的问题。只要稍微想一想就能明白：如果模型既能处理图像，又能处理语言，那它就有可能完成图文搜索、图片描述、视觉问答等各种任务，这听起来非常有吸引力。
也正因为如此，计算机视觉和自然语言处理领域的研究者，早早就开始尝试“跨模态学习”，也就是把图像和文本放在同一个模型里一起建模。然而，有些尴尬的是：这些方法虽然在论文里能跑出不错的结果，但很难真正变成一种稳定、通用、可以长期复用的基础能力。模型往往是“为某个任务量身定做的”，而不是“可以反复拿来用的工具”。
系统集成并不是从接线或上电开始，而是从空间与结构层面的约束开始。 对于无人机而言，布局与布线并非单纯的机械装配问题，而是决定系统稳定性、电磁环境可控性以及后续调试难度的基础工程环节。本章从系统工程视角出发，讨论布局与布线在无人机系统集成中的核心作用，并阐明其对飞控算法、传感器可靠性以及通信稳定性的深远影响。
在系统生命周期中，布局一旦确定，后续可调整的空间将急剧收缩。因此，合理的布局与布线设计，本质上是在系统早期为稳定性与可维护性预留自由度。更进一步，布局与布线决定了系统中干扰源如何产生、如何传播以及如何被感知，从而决定后续软件配置与参数调节的难度上限。为了使讨论具有工程可复用性，本章在原则陈述之外，将若干关键点表达为可复核的空间与走线约束，使其能够在装配阶段被直接检查与确认。