氛围编程实战系列:先规划清楚学习路径
上篇文章《入门:我的第一个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一起成长~