用AI编程 vs 构建AI：开发者必须厘清的两层能力

AI 正在重塑软件开发的方式，但很多人把两件不同的事混为一谈：用AI辅助写代码，和在代码里构建AI功能。这两者虽然都带"AI"，但对应的技能栈、思维方式和工程挑战截然不同。

两个层次，两种能力

据一位 YouTube 技术创作者的分析，AI 与软件开发的关系可以拆成两个主要层次。

第一层是"用AI来构建"（Building With AI） ——把 AI 当作工具，辅助完成软件开发工作。这包括用 Copilot 类工具写代码、用大模型做代码审查、借助 AI 进行调试和重构等。本质上，AI 在这里扮演的是"超级助手"的角色。

第二层是"构建AI"（Building AI） ——在代码中实际使用 AI 相关功能，或者构建 AI 功能本身。这涉及到调用模型 API、设计 prompt 流程、搭建 RAG 管道、处理推理延迟和成本等。AI 在这里不是工具，而是产品的一部分。

这个区分之所以重要，是因为它们对开发者的要求完全不同。第一层考验的是你如何高效地"指挥"AI；第二层考验的是你如何把 AI 能力可靠地"嵌入"系统。混淆两者，容易导致学习方向跑偏。

Copilot 类工具指的是以 GitHub Copilot 为代表的一类代码补全与生成工具。其底层通常由经过代码语料微调的大语言模型驱动，能够根据当前文件的上下文、光标位置以及注释实时预测并补全代码片段。它的工作模式大致分为两种：一是在你敲代码时给出灰字建议（inline completion），二是在对话框里根据自然语言指令生成或修改整段代码（chat 或 agent 模式）。理解 Copilot 类工具的关键在于，它并不真正"理解"你的项目，而是基于海量代码统计规律做概率预测，因此它的输出需要开发者审查、验证和修正，而非盲目接受。这也是把 AI 当工具使用时最需要建立的判断力。

RAG 管道（Retrieval-Augmented Generation，检索增强生成） 是一种让大模型在回答前先"查阅资料"的架构。由于模型的参数知识有截止日期、也无法覆盖你的私有文档，RAG 的做法是在用户提问时，先把问题转成向量，在向量数据库中检索出最相关的文档片段，再把这些片段作为上下文一起喂给模型，让它据此生成回答。一条完整的 RAG 管道通常包含文档切分（chunking）、向量化（embedding）、存入向量库、相似度检索、重排序（reranking）和拼接 prompt 等环节。它的工程难点在于切分粒度、检索召回质量以及对无效检索结果的处理——任何一个环节做不好，模型都会答非所问或产生幻觉。构建 AI 功能的开发者往往大部分时间都花在调优这条管道上。

77%的开发者已经在每天使用AI

第一层已经不是"要不要做"的问题了。该分析引用的数据显示，77% 的专业开发者声称他们每天都在使用 AI 工具，并且认为这对工作流产生了巨大影响。

这个数字意味着，用AI辅助开发已经从早期尝鲜阶段进入主流实践。对于还没有把 AI 工具纳入日常流程的开发者来说，差距只会越拉越大。

更关键的是，光"会用"还不够。该创作者指出，你需要真正理解一系列核心概念：skills（技能编排）、context windows（上下文窗口）、model choice（模型选择）、工具选型、sub-agents（子代理） 等等。这些构成了"用AI构建"这一层的核心知识体系。

上下文窗口（context window） 指的是大模型在一次调用中能够同时"看到"的最大 token 数量，包括你输入的 prompt 和它生成的回复。这个窗口有硬上限，超出部分会被截断。理解上下文窗口对用好 AI 工具至关重要：一是它决定你一次能塞进多少代码、文档或对话历史；二是随着上下文变长，模型对中间信息的注意力往往会衰减（业界称为"lost in the middle"现象），并非塞得越多越好。模型选择同样是核心概念——不同模型在推理能力、响应速度、上下文长度和调用成本上差异很大，简单任务用小模型更划算，复杂推理则需更强的模型。子代理（sub-agents） 则是指把一个大任务拆给多个专职的 AI 代理协作完成，例如一个负责检索、一个负责编码、一个负责测试，通过分工来突破单个代理的能力和上下文限制。

为什么这个区分对开发者重要

把这两层拆开看，能帮开发者更清晰地规划自己的学习路径。

如果你偏向第一层，重点应该放在：如何写好 prompt、如何管理上下文、如何选择合适的模型和工具链、如何设计 sub-agent 的协作方式。这些能力的回报是立竿见影的——直接提升你每天的编码效率。

如果你偏向第二层，重点则在于：理解模型的能力边界、设计可靠的 AI 交互流程、处理幻觉和错误、优化推理成本和延迟。这些是产品级的工程挑战，需要更深的系统设计能力。

当然，两层并非互斥。一个成熟的 AI 工程师往往两者兼备——既能用 AI 高效开发，也能构建出可靠的 AI 功能。但在入门阶段，分清主次、有的放矢，比眉毛胡子一把抓要有效得多。

幻觉（hallucination） 指的是大模型自信地生成看似合理、实则错误或凭空捏造的内容。在编程场景中，它可能表现为编造不存在的函数、API 或库，或者给出能通过语法检查但逻辑错误的代码。对于构建 AI 功能的开发者来说，幻觉不是可以忽略的小毛病，而是必须系统性应对的工程问题，常见手段包括引入 RAG 让回答有据可依、要求模型给出引用来源、增加输出校验与回退逻辑，以及在关键路径上保留人工确认。与此相关的是推理成本和延迟：大模型每次调用都按 token 计费，且生成速度受算力限制，这直接影响产品的可行性和用户体验。开发者需要在模型大小、调用频率、缓存策略和流式输出等方面做权衡，才能把 AI 功能真正做成可上线的产品，而非演示玩具。

一个务实的起点

无论你最终想往哪个方向发展，"用AI构建"都是绕不开的起点。77% 这个数字已经说明，不会用 AI 工具的开发者正在成为少数。从掌握上下文窗口的管理开始，到理解不同模型的适用场景，再到尝试 sub-agent 的编排——这些技能不需要你成为 ML 工程师，但能显著改变你的工作方式。

而当你对 AI 工具的能力和局限有了切身体感之后，再进入"构建AI"的层次，思路会清晰得多。