氛围编程实战系列：先规划清楚学习路径

上篇文章《入门：我的第一个Vibe Coding实践程序》笔者已经带大家初步体验了氛围编程的能力和效果，体验过后，下一步我们具体要做什么，要有一个大致的规划，也就是这篇文章要介绍的内容。

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

很多技术初学者开始做 AI 编程时，容易先被各种功能名吸引：模型、Agent、Skill、RAG、向量、Graph、JSON……每个词看起来都重要，但如果没有一条清晰路线，学习过程很容易变成零散尝试。

这篇文章不是展开某一个功能，而是先整理一份真正适合小白入门的“氛围编程实战系列”的学习路径。笔者希望先把要实践的主题摆出来，让后续每一篇都有明确位置：先解决使用和监控，再进入知识管理、问数、Agent、Skill、RAG、向量和数据关系，最后把一部分操作交还给人工执行，减少不必要的 token 消耗。

02 | 从使用量监控开始

系列的第一项是 LLM 使用量监控。

对初学者来说，先学会观察使用量很重要。只有知道 LLM 被怎样调用，后续才更容易判断哪些步骤值得交给 AI，哪些步骤应该收敛。监控不是高级功能，而是让实践变得可控的入口。

03 | 让知识能被合并和调用

第二项是 合并知识功能。

做 AI 编程时，知识往往来自不同片段，或者是用户分多次录入的，如果这些内容长期分散，后续使用会变得混乱。合并同一类知识功能的意义，是把已有知识整理成更容易复用的形态，为后面的 AI 问数和 RAG 场景打基础。

第三项是 AI 问数，调通模型。

这里的重点不是追求复杂效果，而是先把模型链路调通。只有模型能被正常调用，问数场景才有继续打磨的前提。

04 | 进入 Agent、Skill 与 Graph

第四项是 Agent 和 Skill 功能。

可以把 Agent 理解为更主动的执行单元（或者干脆理解为人类员工），把 Skill 理解为可复用的能力说明。对初学者来说，先不用急着追求复杂自动化，而是要看清：哪些任务适合被封装成能力，哪些任务适合交给 Agent 串起来执行。

第五项是 Graph 功能 RAG。

RAG 的核心是让模型结合外部知识工作。这里加入 Graph 功能，说明系列会继续探索知识之间的关系，而不只是把资料简单堆在一起。

05 | 处理向量、历史功能与数据关系

第六项是 向量问题，APEX 系统历史功能。

向量问题常常和检索、近似匹配有关；之前使用 APEX 低代码开发了一个针对历史记录查询的场景。这里笔者计划会把这些内容放在一起讨论，帮助初学者从实际功能中理解问题，也彻底打通传统开发和氛围开发之间的壁垒（统一数据存放）。

第七项是 JSON 关系二元性场景。

这说明后续会进入数据结构和关系表达。JSON 看起来是普通数据格式，但当它进入关系场景时，就需要更清楚地理解数据之间如何对应。

06 | 哪些事应该交给人工

第八项是 分离人工执行脚本，节省 token。

并不是所有事情都适合让 AI 一直执行。比如服务管理状态、代码提交 GitHub 等操作，可以由人工来做。这样做的目标很直接：把 AI 留给更需要推理和生成的部分，把明确、可控的执行动作交给人工，从而节省 token。

07 | 小结

这个目录覆盖了从监控、知识整理、模型调通，到 Agent、Skill、Graph RAG、向量、APEX 历史功能接入、JSON 关系场景，再到人工执行脚本分离的一整条实践路线。

后续文章会围绕这些主题逐步展开。笔者会尽量用初学者能跟上的方式，把每个点拆开讲清楚。

关注我，和AI一起成长~