01 | 为什么先规划学习路径

很多技术初学者开始做 AI 编程时容易先被各种功能名吸引模型、Agent、Skill、RAG、向量、Graph、JSON……每个词看起来都重要但如果没有一条清晰路线学习过程很容易变成零散尝试。这篇文章不是展开某一个功能而是先整理一份真正适合小白入门的“氛围编程实战系列”的学习路径。笔者希望先把要实践的主题摆出来让后续每一篇都有明确位置先解决使用和监控再进入知识管理、问数、Agent、Skill、RAG、向量和数据关系最后把一部分操作交还给人工执行减少不必要的 token 消耗。氛围编程实战系列路线02 | 从使用量监控开始系列的第一项是 LLM 使用量监控。对初学者来说先学会观察使用量很重要。只有知道 LLM 被怎样调用后续才更容易判断哪些步骤值得交给 AI哪些步骤应该收敛。监控不是高级功能而是让实践变得可控的入口。LLM 使用量监控入口03 | 让知识能被合并和调用第二项是 合并知识功能。做 AI 编程时知识往往来自不同片段或者是用户分多次录入的如果这些内容长期分散后续使用会变得混乱。合并同一类知识功能的意义是把已有知识整理成更容易复用的形态为后面的 AI 问数和 RAG 场景打基础。第三项是 AI 问数调通模型。这里的重点不是追求复杂效果而是先把模型链路调通。只有模型能被正常调用问数场景才有继续打磨的前提。知识合并到问数和 RAG04 | 进入 Agent、Skill 与 Graph第四项是 Agent 和 Skill 功能。可以把 Agent 理解为更主动的执行单元或者干脆理解为人类员工把 Skill 理解为可复用的能力说明。对初学者来说先不用急着追求复杂自动化而是要看清哪些任务适合被封装成能力哪些任务适合交给 Agent 串起来执行。第五项是 Graph 功能 RAG。RAG 的核心是让模型结合外部知识工作。这里加入 Graph 功能说明系列会继续探索知识之间的关系而不只是把资料简单堆在一起。05 | 处理向量、历史功能与数据关系第六项是 向量问题APEX 系统历史功能。向量问题常常和检索、近似匹配有关之前使用 APEX 低代码开发了一个针对历史记录查询的场景。这里笔者计划会把这些内容放在一起讨论帮助初学者从实际功能中理解问题也彻底打通传统开发和氛围开发之间的壁垒统一数据存放。第七项是 JSON 关系二元性场景。这说明后续会进入数据结构和关系表达。JSON 看起来是普通数据格式但当它进入关系场景时就需要更清楚地理解数据之间如何对应。06 | 哪些事应该交给人工第八项是 分离人工执行脚本节省 token。并不是所有事情都适合让 AI 一直执行。比如服务管理状态、代码提交 GitHub 等操作可以由人工来做。这样做的目标很直接把 AI 留给更需要推理和生成的部分把明确、可控的执行动作交给人工从而节省 token。人工执行脚本节省 token