vibe-coding-cn 是面向中文开发者的 Vibe Coding 资源与工具箱，整理 Context、Skills 和 Extensions 三类内容，并以 Pi Agent 与 OpenAI GPT 作为示例基座。它提供从环境准备、CLI 配置、第一个项目到 Git 闭环的入门路线，也收录提示词、思维模型、工程实践和质量门禁资料，强调先规划、固定上下文，再让 AI 结对执行。仓库主张用测试、CI、脚本、类型、Schema 和提交记录核对结果，适合想把 AI 编程从聊天式尝试变成可维护流程的人。它本身是资料与流程集合，不承诺一键安装或统一效果。
git submodule update --init --recursive| 入口 | 你该怎么理解 |
|---|---|
| Context | 既有资料按需读取；功法、法器、入门、研究、提示词、资源、引用、索引及附件 |
| Skills | 所有既有Skill平铺治理；指令引用单一程序源，不自动执行 |
| Extensions | 所有既有程序、小工具、检查器与适配；不是Pi原生扩展盲扫目录 |
| Wiki | 独立导航仓库，不作为第四种资源或第二份正文源 |
⚡ 1 分钟快速开始
git submodule update --init --recursive。AGENTS.md和当前任务所需Context；需要既有Skill时，从仓库根显式加载：pi --skill .github/skills
/model选择已授权的OpenAI模型。先明确任务和验收，再让Agent按需读取资料、使用相应Skill并显式调用现有程序。加载不是执行许可，也不是运行或效果测试。不要把.github/extensions/整体传给-e。
从零开始保留具体CLI的入门资料；原Codex配置基线及安装脚本已移除，不再提供一键安装入口。
完全新手？按顺序完成以下步骤：
📺 演示与产出
一句话：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行，让「从想法到可维护代码」变成一条可审计的流水线，而不是一团无法迭代的巨石文件。
你能得到
🗂️ 项目目录结构概览
资源只有三个域；下面列出域边界与Context的全部9个集合，不展开各原生包内部源码。完整对象分别在三个域的README中导航。
法器与功法的工具解释模板v0已登记：保留15项原名原序；Markdown中每个对象使用一张严格表格，不合并对象或新增栏目。
Extensions当前保留17个一级对象；用户点名的8项程序/配置/图文文件已移除，历史资料不代表当前可用入口。
原Actions定义已移入Extensions保全，自动CI、打标签及欢迎流程已停用；本地make test保留。
.
├── README.md # 项目主文档
├── AGENTS.md # AI Agent 行为准则
├── llms.txt # 面向 AI 助手的短上下文入口
├── Makefile # 自动化脚本
├── LICENSE # MIT 许可证
├── CODE_OF_CONDUCT.md # 行为准则
├── CONTRIBUTING.md # 贡献指南
├── .gitattributes # GitHub Linguist 语言统计规则
├── .gitignore # Git 忽略规则
├── .lychee.toml # 外部链接检查配置
└── .github/ # GitHub 配置与仓库内容
├── AGENTS.md # 本目录规则、维护入口和平台边界
├── CONTRIBUTORS.md # 独立的项目贡献者名单与鸣谢
├── check-ai-citation.py # AI引用校验
├── check-directory-docs.py # 目录文档校验
├── check-doc-structure.py # 文档结构校验
├── check-external-resources.py # 外部资源校验
├── check-gongfa.py # 功法协议校验
├── check-local-links.py # 内链与锚点校验
├── check-markdown-details.py # 折叠块与围栏校验
├── check-metadata.py # 机器导航校验
├── check-research-raw.py # 研究原始事实校验
├── check-source-facts.py # 源事实镜像校验
├── check-wiki.py # 独立Wiki校验
├── test-faqi-catalog.py # 法器维护测试
├── test-gongfa-catalog.py # 功法总表测试
├── test-gongfa.py # 功法协议测试
├── test-markdown-details.py # 折叠块与围栏测试
├── test-source-archive.py # 原始资料档案测试
├── source_boundaries.py # 共享第三方与来源检查边界
├── taxonomy.py # 共享分类与文档导航读取
├── source_archive.py # 原始资料读取与完整性保护
├── book_views.py # 文集阅读视图与历史导航
├── requirements-faqi.txt # 法器维护依赖
├── requirements-gongfa.txt # 功法维护依赖
├── context/ # 按需读取的既有资料
│ ├── README.md # 资料导航
│ ├── AGENTS.md # 原始数据、来源与信任规则
│ ├── gongfa/ # data.json + 轻量README导航 + 天地玄黄正文
│ ├── faqi/ # data.json + 轻量README导航 + 天地玄黄正文
│ ├── getting-started/ # 原入门与实例
│ ├── prompts/ # 原云端提示词入口
│ ├── research/ # 原研究、事实镜像和缓存
│ ├── external-resources/ # 原外部资源登记
│ ├── ai-citation/ # 原AI引用语料
│ ├── metadata/ # 原分类、术语与重定向
│ └── assets/ # 原图片、数据与模板
├── skills/ # 仅保留auto-skill、auto-tmux两个自有入口
├── extensions/ # 原程序与公共维护工具；自有Skill封装已退役
├── CODEOWNERS # 路径级 owner 评审基线
├── ISSUE_TEMPLATE/ # Issue 模板
├── PULL_REQUEST_TEMPLATE.md # PR 模板
├── SECURITY.md # 安全政策
├── FUNDING.yml # 赞助配置
├── WIKI.md # GitHub Wiki 独立仓库说明
└── labeler.yml # 原PR标签规则（自动流程已停用）
⚙️ 架构与工作流程
核心资产映射是context/的资料、skills/的指令和extensions/的现有实现。相邻步骤按输入输出合同连接，失败和外部副作用不能隐去。
下面保留既有提示词转换程序的架构示意；图中的历史预留节点不是本次新增能力，也不代表整个工具箱均采用该转换流程。
graph TB
%% GitHub 兼容简化版（仅使用基础语法）
subgraph ext_layer[外部系统与数据源层]
ext_contrib[社区贡献者]
ext_sheet[Google 表格 / 外部表格]
ext_md[外部 Markdown 提示词]
ext_api[预留：其他数据源 / API]
ext_contrib --> ext_sheet
ext_contrib --> ext_md
ext_api --> ext_sheet
end
subgraph ingest_layer[数据接入与采集层]
excel_raw[prompt_excel/*.xlsx]
md_raw[prompt_docs/外部MD输入]
excel_to_docs[.github/extensions/prompts-library/scripts/excel_to_docs.py]
docs_to_excel[.github/extensions/prompts-library/scripts/docs_to_excel.py]
ingest_bus[标准化数据帧]
ext_sheet --> excel_raw
ext_md --> md_raw
excel_raw --> excel_to_docs
md_raw --> docs_to_excel
excel_to_docs --> ingest_bus
docs_to_excel --> ingest_bus
end
subgraph core_layer[数据处理与智能决策层 / 核心]
ingest_bus --> validate[字段校验与规范化]
validate --> transform[格式映射转换]
transform --> artifacts_md[prompt_docs/规范MD]
transform --> artifacts_xlsx[prompt_excel/导出XLSX]
orchestrator[main.py · .github/extensions/prompts-library/scripts/start_convert.py] --> validate
orchestrator --> transform
end
subgraph consume_layer[执行与消费层]
artifacts_md --> catalog_coding["prompts(在线)/编程提示词"]
artifacts_md --> catalog_system["prompts(在线)/系统提示词"]
artifacts_md --> catalog_meta["prompts(在线)/元提示词"]
artifacts_md --> catalog_user["prompts(在线)/用户提示词"]
artifacts_md --> docs_repo[.github/context/*]
artifacts_md --> new_consumer[预留：其他下游渠道]
catalog_coding --> ai_flow[AI 结对编程流程]
ai_flow --> deliverables[项目上下文 / 计划 / 代码产出]
end
subgraph ux_layer[用户交互与接口层]
cli[CLI: python main.py] --> orchestrator
makefile[Makefile 任务封装] --> cli
readme[README.md 使用指南] --> cli
end
subgraph infra_layer[基础设施与横切能力层]
git[Git 版本控制] --> orchestrator
deps[.github/extensions/prompts-library/requirements.txt · .github/extensions/prompts-library/scripts/requirements.txt] --> orchestrator
config[.github/extensions/prompts-library/scripts/config.yaml] --> orchestrator
monitor[预留：日志与监控] --> orchestrator
end
📈 性能基准 (可选)
本仓库是既有资源工具箱，不对模型或程序效果作统一性能保证；可在具体任务中跟踪下列可观测指标（当前主要依赖人工记录，可在 progress.md 中打分/留痕）：
| 指标 | 含义 | 当前状态/建议 |
|---|---|---|
| 提示命中率 | 一次生成即满足验收的比例 | 待记录；每个任务完成后在 progress.md 记 0/1 |
| 周转时间 | 需求 → 首个可运行版本所需时间 | 录屏时标注时间戳，或用 CLI 定时器统计 |
| 变更可复盘度 | 是否同步更新上下文、文档和 Git 提交 | 通过 commit、CHANGELOG 与必要的 tag 留痕 |
| 例程覆盖 | 是否有最小可运行示例/测试 | 建议每个示例项目保留 README+测试用例 |
以下是 2025 Q4–2026 Q2 的历史规划，不代表当前进度或交付承诺；原日期仅用于回溯。 当前交付以仓内文档、代码与提交记录为准，新排期待确认。
gantt
title 历史规划（非当前进度）
dateFormat YYYY-MM
section 原计划 (2025 Q4)
补全演示GIF与示例项目: 2025-12, 30d
外部资源聚合完善: 2025-12, 20d
section 原计划 (2026 Q1)
prompts 索引自动生成脚本: 2026-01, 15d
一键演示/验证 CLI 工作流: 2026-01, 15d
文档索引与引用门禁增强: 2026-02, 10d
section 原计划 (2026 Q2)
模板化示例项目集: 2026-03, 30d
多模型对比与评估基线: 2026-04, 30d
📚 功法体系
| 序号 | 说明项 | 内容 |
|---|---|---|
| 1 | 工具的名称 | 功法体系。本区块说明的是一组可复用内容，不对应单一功法。 |
| 2 | 是什么 | 统一导航思想、准则、思维模型、方法与工程流程；经验、道法术器、实验性方法和哲学作为同一集合中的原始文集保留。 |
| 3 | 为什么 | 让读者按当前问题选用适用内容，避免从首页分散的旧栏目或独立分库中查找。 |
| 4 | 怎么做 | 先明确当前任务的问题，再从功法体系目录选择文集或条目；具体用法以条目说明和来源为准。 |
| 5 | 扩展 | 需要继续阅读时进入相应原始文集；文集归并本身不创建新的功法身份或登记条目。 |
| 6 | 关联信息 | 工具解释模板 v0规定说明结构；具体类型和边界见功法体系目录。 |
| 7 | 出处 | 功法原始资料记录逐条身份、内容版本、冻结来源与已有意见；生成总表用于浏览。 |
| 8 | 相关图书 | 本区块未列集合级书目；具体书目须按对应条目的来源核实，未核实前不补列。 |
| 9 | 它要解决什么问题？ | 帮助读者从统一入口按任务找到可参考的思想和方法；集合本身不是单一问题求解器，具体问题由各条目说明。 |
| 10 | 为什么这样设计？ | 把既有内容保留在同一集合中，既维持原文可追溯，也不恢复经验、道法术器、实验性方法和哲学的首页独立栏目或分库入口。 |
| 11 | 内部如何实现？ | 以data.json为唯一维护数据，由生成器输出轻量README导航页和天、地、玄、黄四阶正文；逐条身份、内容版本和来源绑定仍按原登记记录维护。 |
| 12 | 付出了什么代价？ | 现有总览没有集合级成本测量；不能据此认定维护或应用成本为零，具体限制以各条目来源为准。 |
| 13 | 比较不同技术与方法。 | 应在同一问题和适用条件下比较具体条目；不同任务中的效果或品级不能直接互比。 |
| 14 | 提炼共同规律。 | 当前可归纳的共同做法是先看问题，再选择方法；不把目录归类或已有初评当作统一效果证明。 |
| 15 | 明确这些规律成立的前提与适用条件。 | 选择依赖具体任务和条目的适用条件、限制；文集归并不等于全部内容已经逐条登记，已有初评也不等于正式效果验证。 |
🧰 法器体系
| 序号 | 说明项 | 内容 |
|---|---|---|
| 1 | 工具的名称 | 法器体系。本区块说明工具、入口和依赖的集合，不对应单一产品。 |
| 2 | 是什么 | 整理 Vibe Coding 流程中使用或依赖的工具、可调用入口和依赖类别；固定来源实现、当前运行实例、候选对象与抽象类别分别记录。 |
| 3 | 为什么 | 帮助读者理解各对象在 Vibe Coding 工作流中的位置；重要性分级不代表实现质量、运行状态或任务效果。 |
| 4 | 怎么做 | 先明确任务，再核实具体对象的来源、版本、可用性和权限；选用流程见法器体系说明。 |
| 5 | 扩展 | 新增或延伸说明须先明确对象身份和来源；抽象依赖类别不自动代表具体产品、部署或已启用能力。 |
| 6 | 关联信息 | 工具解释模板 v0、法器体系说明（分类、重要性、选用方式与固定 MCP 源码副作用边界）及法器类型与正式效能规约。 |
| 7 | 出处 | 法器登记源是唯一可编辑数据源；法器重要性总表是生成视图。固定来源和选区按登记记录核对，不据此推断当前运行。 |
| 8 | 相关图书 | 本区块未列集合级书目；具体书目须按对应对象的来源核实，未核实前不补列。 |
| 9 | 它要解决什么问题？ | 帮助读者识别 Vibe Coding 工作流中的工具角色、可调用入口和依赖类别；它不是某个工具，也不保证对象当前可用。 |
| 10 | 为什么这样设计？ | 将固定来源实现、运行实例、候选对象和抽象类别分开记录，避免把来源、依赖关系或名称相似误当成同一对象。 |
| 11 | 内部如何实现？ | 登记数据生成浏览总表；具体实现机制须根据各对象对应的固定来源、版本和选区说明，不能从集合摘要推断。 |
| 12 | 付出了什么代价？ | 本区块没有集合级成本或效能测量；具体资源代价和副作用须按对象来源核实。文件级许可线索仅作支持证据，不等于许可批准或再分发授权。 |
| 13 | 比较不同技术与方法。 | 30 项分级比较的是 Vibe Coding 重要性，不是质量或效能；方案比较须限定同一任务、对象层级和适用条件。 |
| 14 | 提炼共同规律。 | 应分别核对对象身份、重要性、当前运行状态、许可和效果证据；其中一项不能替代其他项。 |
| 15 | 明确这些规律成立的前提与适用条件。 | 当前 30 项按重要性暂分天阶 4 项、地阶 12 项、玄阶 9 项、黄阶 5 项；重要性不代表实现质量、运行可用性或效能验证。正式效能量表仍为草案，评级尚未完成。 |
如果这个项目对您有帮助，请考虑为其点亮一颗 Star ⭐！
内容由编辑整理，部分信息来自 GitHub 与项目官网，版权归原作者所有。发现错误？报告问题