Vibe Coding on KnightLi的博客

easy-vibe：给 Vibe Coding 初学者的一张学习地图

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 开源的 Vibe Coding 学习项目。它面向的不是已经熟练使用 AI 编程工具的开发者，而是刚开始接触 Vibe Coding 的学生、产品经理、设计师、运营、独立开发者和普通技术爱好者。

这个项目的价值不在于又列出一批 AI 工具，而是把“怎么开始用 AI 做项目”拆成了更容易理解的学习路径。对很多新手来说，真正困难的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道应该先学什么、怎么练、什么时候进入进阶工具。

Vibe Coding 新手最缺的是路径

Vibe Coding 这几年很火，但它对新手并不友好。

表面上看，只要会描述需求，就可以让 AI 写代码。实际上，只要任务稍微复杂一点，问题就会出现：需求说不清，模型改错文件，项目结构看不懂，报错不会处理，依赖装不上，提示词越写越乱，最后只能回到“复制代码到聊天框”的状态。

所以 Vibe Coding 入门不能只教“怎么写提示词”。它至少要解决几件事：

如何把想法拆成可执行任务；
如何让 AI 理解项目结构；
如何看懂模型生成的代码；
如何处理报错和迭代；
如何使用终端和本地开发环境；
如何从网页聊天过渡到真正的 AI 编程工具。

easy-vibe 的意义就在这里：它试图把这些内容整理成一条学习路线，而不是让新手自己在工具、教程和术语里迷路。

它不是单点教程，而是路线图

从项目介绍看，easy-vibe 覆盖了基础教程、交互式练习、可视化内容、RAG、终端工具、AI 编程工具，以及更进阶的 Claude Code、MCP、Skills、Agent Teams 等主题。

这类组织方式比较适合初学者。因为 AI 编程不是一个单独技能，而是一组能力的组合：

会描述需求；
会拆任务；
会读项目；
会让模型改代码；
会运行和验证；
会根据错误继续迭代；
会把常用流程沉淀成工具或技能。

如果只学某一个工具，很容易被工具界面限制住。换一个模型、换一个编辑器、换一个 CLI，就又不知道怎么做。路线图的好处是先建立工作方式，再把工具放到合适的位置。

对非程序员尤其有用

Vibe Coding 最大的吸引力，是让非专业程序员也能做出原型。

产品经理可以把产品想法变成可交互 demo，设计师可以验证交互逻辑，运营可以写内部工具，学生可以快速做课程项目，创业者可以在早期验证需求。这些人不一定要成为传统意义上的全职工程师，但需要掌握一套“让 AI 帮我把想法落地”的方法。

这也是 easy-vibe 适合中文社区的原因。很多中文用户已经知道 AI 能写代码，但还缺少系统入门材料：从开发环境、提示词、项目结构、调试方法到 Agent 工具使用，最好能用中文解释清楚，并配合练习逐步推进。

对这类用户来说，最重要的不是一上来学复杂框架，而是先跑通完整闭环：提出需求、生成项目、运行起来、发现问题、继续修改、最终得到一个可用版本。

进阶部分开始靠近真实 AI 开发工作流

easy-vibe 里提到的 Claude Code、MCP、Skills、Agent Teams，已经不只是入门概念。

Claude Code 代表的是终端编程 Agent：模型可以进入本地项目，读取文件、修改代码、运行命令。MCP 解决的是工具和数据源接入，让模型不只停留在聊天框里。Skills 则把可复用流程沉淀下来，例如固定的项目生成、文档整理、测试检查或内容生产流程。Agent Teams 进一步把任务拆给多个智能体协作。

这些内容对新手来说可能有点远，但它们值得提前了解。因为 Vibe Coding 的发展方向已经很清楚：从“让 AI 写一段代码”，走向“让 AI 参与一个完整项目流程”。

如果学习路线只停留在提示词层面，很快就会跟不上工具演进。反过来，如果一开始就把所有高级概念塞给新手，又会让人无从下手。easy-vibe 的合理价值，是把这些内容放在一条逐步升级的路径里。

学习时要避免两个误区

第一个误区，是以为 Vibe Coding 等于不会代码也能完全不管代码。

AI 可以生成很多内容，但用户仍然需要判断结果是否正确。至少要能看懂项目结构、知道怎么运行、知道错误大概发生在哪里。即使不写复杂代码，也要具备基本的工程常识。

第二个误区，是以为工具越高级越好。

新手不一定一开始就需要 Claude Code、MCP 或多 Agent。更好的顺序是先用简单项目建立反馈循环，再逐步引入终端、版本管理、测试、工具调用和自动化流程。工具要跟任务复杂度匹配，否则很容易变成“看起来很强，但不知道用来做什么”。

适合怎么用

如果你刚接触 Vibe Coding，可以把 easy-vibe 当作学习清单来用。

先从基础概念和简单练习开始，不急着追所有工具。做一个小项目，例如个人主页、数据看板、表单工具、自动化脚本或知识库 demo。过程中重点观察 AI 在哪些地方帮得上忙，哪些地方需要你自己确认。

等你能稳定完成小项目，再开始学习更复杂的内容：

用终端工具处理本地项目；
用 Git 管理每次修改；
用 RAG 接入自己的资料；
用 MCP 连接外部工具；
用 Skills 固化重复流程；
用 Agent Teams 拆分复杂任务。

这样学出来的 Vibe Coding 才不只是会问 AI，而是能把 AI 放进自己的工作流程里。

总结

easy-vibe 适合被看作 Vibe Coding 的中文入门地图。它把零散的 AI 编程概念、工具和练习组织成一条路径，让新手更容易从“听说 AI 能写代码”走到“我能用 AI 做出一个项目”。

Vibe Coding 真正有价值的地方，不是让人跳过所有学习，而是降低从想法到原型的门槛。你仍然需要理解需求、组织任务、验证结果和控制风险，但很多重复、枯燥、容易卡住的步骤，可以交给 AI 协助完成。

如果你想系统入门 AI 编程，又不想一开始就陷入工具名词和复杂工程配置，easy-vibe 是一个值得收藏的起点。

别把 API Key 推上 GitHub：AI 写代码时代的密钥泄露防坑指南

Sat, 16 May 2026 16:26:50 +0800

AI 写代码降低了动手门槛，也把很多原来只会发生在工程团队里的安全问题，带到了新手和非工程用户面前。

最常见的一类事故，是把 API Key、Secret、Token、数据库连接串或 .env 配置文件一起推到公开仓库。对本地项目来说，这些文件只是“能让程序跑起来的配置”；一旦进了 GitHub 公共仓库，它们就变成了可以被自动扫描、自动调用、自动滥用的凭证。

密钥泄露不是小概率事件。GitGuardian 的 2026 年度报告提到，2025 年公共 GitHub 提交里出现了约 2865 万个新增硬编码凭证，AI 服务相关凭证泄露同比增长 81%。这说明问题不只是“有人粗心”，而是 AI 编程、快速原型和公开托管叠加后，泄露规模正在被放大。

为什么新手更容易泄露 Key

很多 AI Agent 或小工具都有两套“仓库”：一套在本地硬盘里，另一套在 GitHub 上。问题在于，新手经常没有意识到二者的边界。

本地运行时，config.json、.env、settings.yaml 里放着 API Key，好像只是开发习惯；执行 git add .、git commit、git push 之后，这些文件就可能被完整上传。仓库一旦公开，扫描机器人不需要理解你的业务，只要匹配到密钥格式，就能把它抓走。

AI 编程还会放大这个问题：

AI 生成示例代码时，可能直接把 OPENAI_API_KEY = "sk-..." 这类写法放进源码。
新手为了“先跑起来”，容易把密钥硬编码在前端、脚本或配置文件里。
很多 vibe coding 平台可以直接部署应用，不一定经过 GitHub 的推送保护流程。
用户可能不知道 AI 生成的项目里到底有哪些文件、哪些接口、哪些默认权限。

换句话说，AI 可以帮你更快写出能跑的东西，但不会自动替你承担安全责任。

`.gitignore` 不是装饰

Git 负责版本管理，GitHub 负责托管代码，.gitignore 则是告诉 Git 哪些文件不要纳入版本历史。

一个最基本的 AI 项目，至少应该把这些内容排除掉：

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

但只写 .gitignore 还不够。它只能阻止“尚未被 Git 跟踪”的文件继续进入提交。如果某个密钥文件已经被提交过，后来再把它写进 .gitignore，并不能把历史记录里的密钥抹掉。

所以更稳妥的习惯是：

新项目一开始就创建 .gitignore。
API Key 只放在环境变量或本地配置里。
示例文件只提供 .env.example，里面写占位符，不写真实密钥。
提交前运行一次密钥扫描工具，比如 gitleaks、trufflehog 或 GitHub Secret Scanning。

Key 推上去以后，删除文件不等于安全

如果密钥已经推到公开仓库，第一反应不应该是“删掉文件再提交一次”，而应该是立刻吊销或轮换密钥。

原因很简单：Git 记录的是历史。即使你在最新提交里删除了文件，旧提交、fork、clone、缓存和扫描系统里仍可能保留那段内容。GitHub 官方文档也明确建议：如果泄露的是密码、Token 或凭证，第一步应该撤销或轮换。

处理顺序建议这样做：

立即去服务商后台吊销旧 Key，生成新 Key。
检查账单、调用日志、异常 IP 和异常用量。
从代码中移除硬编码密钥，改用环境变量或密钥管理服务。
用 git filter-repo 或 BFG 清理仓库历史中的敏感文件。
开启 GitHub Secret Scanning 和 Push Protection。
检查 CI/CD、部署平台、云函数、前端构建产物里是否也包含旧 Key。

对于 OpenAI、Anthropic、DeepSeek、云厂商、支付、邮件、数据库等服务，泄露 Key 的后果可能不只是被刷额度，还可能包含数据读取、服务滥用、供应链污染或业务账号封禁。

前端代码里不能放真正的密钥

很多新手以为“只要页面能跑就行”，于是把 API Key 写进前端 JavaScript：

`1`	`const apiKey = "sk-xxxxxxxx";`

这基本等于公开。浏览器里的代码、网络请求、Source Map、构建产物都可以被查看。只要是真正需要保密的 Key，就不应该出现在客户端。

正确做法是让前端请求自己的后端接口，由后端读取环境变量并调用第三方 API：

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

后端再使用环境变量：

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

这样做不是为了形式好看，而是为了把密钥留在服务器环境里，避免直接暴露给所有访问页面的人。

Vibe Coding 的安全责任不会自动消失

vibe coding 的问题不只是 GitHub 泄露。很多应用直接从 AI 编程平台发布到公网，跳过传统代码审查、仓库扫描和安全测试。

RedAccess 近期披露的研究显示，公开网络上可以找到大量由 AI 编程工具生成或托管的应用资产，其中一部分暴露了企业数据、个人信息或内部文件。它提醒的是同一件事：当“能上线”变得太容易，“是否应该上线”“是否只该内网访问”“是否有权限控制”就更容易被忽略。

如果你用 AI 生成应用，至少要在发布前问自己几个问题：

这个应用是否真的需要公开访问？
是否有登录、鉴权和权限隔离？
是否把数据库、API Key、Token、Webhook 地址暴露在前端？
是否限制了第三方 API 的额度、域名、权限和有效期？
是否能在发现异常后快速禁用密钥和回滚部署？

AI 写出来的代码也需要安全审查。越是“我一行代码都没写”，越不能假设它天然安全。

现在就该做的检查

可以先从自己的 GitHub 账号查起。搜索用户名加上这些关键词：

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

如果发现真实密钥，不要犹豫：先轮换，再清理。只要它进过公开仓库，就按已经泄露处理。

以后新建 AI 项目时，也建议固定一套流程：

先写 .gitignore，再写业务代码。
用 .env.example 说明需要哪些变量。
所有密钥放环境变量，不写进源码。
给 API Key 设置最小权限、额度限制和过期时间。
开启 GitHub Secret Scanning 和 Push Protection。
发布前让 AI 再帮你做一次安全检查，但不要只相信 AI 的结论。

AI 编程真正危险的地方，不是它会写错代码，而是它让很多人第一次拥有了把不安全应用快速发布到公网的能力。写得快不是问题，把密钥、数据和权限一起交出去才是问题。