工作流 14：从本地项目到 GitHub 开源仓库的 AI 发布工作流¶

适用岗位：开发者、开源作者、参赛者、技术写作者

真实场景：你在本地完成了一个项目，想把它发布成 GitHub 开源仓库，但不确定目录结构是否合适、README 怎么写才专业、License 怎么选、Git 怎么初始化和推送，以及发布后还需要做什么。

最终目标：一个结构规范、文档完整、可被他人理解和使用的 GitHub 开源仓库，包含：规范的目录结构、专业的 README、合适的 License、清晰的提交历史、可运行的 CI 配置（如适用）和 Release 说明。

输入材料清单¶

本地项目（项目目录 + 现有文件）
项目基本信息（项目名、一句话定位、目标用户）
技术栈（语言、框架、运行环境）
仓库可见性意向（公开 / 私有）
GitHub 账号情况（用户名、是否已配置认证方式）

工作流总览¶

节点 1：仓库定位专家
  ↓ 输出：仓库定位 + 命名 + 可见性建议
节点 2：目录结构检查专家
  ↓ 输出：目录结构评估 + 整理建议 + .gitignore
节点 3：README 生成专家（招牌节点）
  ↓ 输出：完整开源 README
节点 4：License 与原创性说明专家
  ↓ 输出：License 选择 + 原创性声明
节点 5：Git 初始化与远程绑定专家
  ↓ 输出：Git 初始化与远程绑定步骤（含三种认证路径）
节点 6：提交信息专家
  ↓ 输出：提交信息规范 + 首次提交建议
节点 7：GitHub Actions 检查专家
  ↓ 输出：CI 配置检查 / 建议
节点 8：Release 说明专家
  ↓ 输出：Release 说明 + 版本号建议
节点 9：发布后复盘专家
  ↓ 输出：发布检查清单 + 后续维护建议
最终交付：可发布的 GitHub 开源仓库

专家节点详解¶

每个节点包含六部分：节点定位、输入与输出、使用顺序、提示词包（A 快速 / B 专家 / C 自查 / D 返修）、交付给下游节点、人工验收清单。

C 自查审稿版和 D 返修优化版是当前节点内部的工作模式，不是新的专家角色。

命令使用提示

本工作流包含 Git 和 GitHub CLI 命令示例。所有命令中的仓库名、用户名、路径都需要替换为你自己的实际值。命令不假设你已完成认证——节点 5 提供 HTTPS、GitHub CLI、SSH 三种认证路径。

节点 1：仓库定位专家¶

1.1 节点定位¶

明确仓库的定位、命名和可见性，为后续所有工作定下基调。一个好的仓库名和清晰的定位，是开源项目被发现和理解的第一步。

1.2 输入与输出¶

输入：项目基本信息 + 技术栈 + 可见性意向

输出：仓库定位陈述 + 命名建议 + 可见性建议 + Topics 标签建议

1.3 使用顺序¶

先用「快速生成版」得到定位初稿。
需要斟酌命名和定位差异化时，改用「专家增强版」。
用「自查审稿版」检查命名是否规范、定位是否清晰。
有问题则用「返修优化版」调整。
对照 1.6 验收清单确认，通过后交给节点 2 和节点 3。

1.4 提示词包¶

A. 快速生成版¶

你是一位开源项目顾问。请为以下项目确定仓库定位。

项目信息：【填入项目名、一句话定位、目标用户】
技术栈：【填入】

输出：
1. 仓库定位陈述（这个仓库是什么、给谁用）
2. 命名建议（符合开源命名惯例，小写+连字符）
3. 可见性建议（公开/私有及理由）
4. Topics 标签建议（5-8个，便于被搜索）

B. 专家增强版¶

你是一位资深开源项目顾问。

任务：为以下项目确定清晰的仓库定位和规范命名。

输入：
- 项目信息：【填入项目名、定位、目标用户】
- 技术栈：【填入】
- 可见性意向：【填入】

处理步骤：
1. 提炼一句话定位（解决什么问题，给谁用）
2. 评估命名（是否符合开源惯例：简洁、小写、连字符分隔、避免歧义、检查是否易与知名项目混淆）
3. 给出可见性建议（公开的好处/风险，私有的适用场景）
4. 推荐 Topics 标签（技术栈 + 用途 + 领域，便于 GitHub 搜索发现）
5. 提示需注意的事项（如名称是否可能涉及商标）

输出格式：
- 定位陈述
- 命名建议（含理由，可给 2-3 个备选）
- 可见性建议
- Topics 标签清单

约束：命名遵循开源惯例；可见性建议需说明权衡；不臆断商标问题但提示需自查。

质量标准：他人看到仓库名和定位即可判断这个项目是否对自己有用。

常见失败情况：仓库名含大写或空格不规范；定位模糊（"一个工具"）；忘记设置 Topics 导致难以被发现。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下仓库定位是否存在以下问题：
1. 命名是否符合开源惯例（小写、连字符、无空格、简洁）？
2. 定位陈述是否清晰说明了"解决什么问题、给谁用"？
3. 可见性建议是否说明了权衡？
4. Topics 标签是否覆盖了技术栈和用途？

【粘贴仓库定位】

逐条说明问题。

D. 返修优化版¶

根据自查意见修改仓库定位。规范命名，明确定位陈述，补充可见性权衡，完善 Topics 标签。

原始定位：【粘贴原始定位】
自查意见：【粘贴自查结果】

1.5 交付给下游节点¶

将仓库定位陈述和命名建议复制，交给节点 2（目录结构检查专家）和节点 3（README 生成专家）。README 的一句话介绍来自这里的定位陈述。

1.6 人工验收清单¶

[ ] 仓库命名是否符合开源惯例？
[ ] 定位陈述是否清晰（解决什么问题、给谁用）？
[ ] 可见性建议是否说明了权衡？
[ ] 是否给出了 Topics 标签建议？

节点 2：目录结构检查专家¶

2.1 节点定位¶

检查本地项目的目录结构是否符合开源项目规范，识别应忽略的文件，生成 .gitignore。整洁的目录结构和正确的 .gitignore 能避免敏感文件泄露和仓库臃肿。

2.2 输入与输出¶

输入：本地项目目录结构 + 技术栈

输出：目录结构评估 + 整理建议 + .gitignore 内容

2.3 使用顺序¶

先用「快速生成版」检查目录结构。
项目复杂或多语言混合时，改用「专家增强版」。
用「自查审稿版」检查是否遗漏了敏感文件、.gitignore 是否完整。
有问题则用「返修优化版」补充。
对照 2.6 验收清单确认，通过后交给节点 5。

2.4 提示词包¶

A. 快速生成版¶

你是一位项目结构顾问。请检查以下目录结构。

目录结构：【粘贴 ls / tree 输出】
技术栈：【填入】

输出：
1. 结构评估（是否符合该技术栈惯例）
2. 整理建议（哪些文件该移动/删除/补充）
3. .gitignore 内容（排除依赖、构建产物、敏感文件、IDE 配置）

B. 专家增强版¶

你是一位资深开源项目结构专家。

任务：检查本地项目结构，确保符合开源规范且不会泄露敏感文件。

输入：
- 目录结构：【粘贴 tree 或 ls -R 输出】
- 技术栈：【填入语言/框架】

处理步骤：
1. 对照该技术栈的标准项目结构，评估当前结构
2. 识别应补充的标准文件（README、LICENSE、.gitignore、必要时的 CONTRIBUTING）
3. 识别不应提交的文件（依赖目录、构建产物、日志、本地配置、.env、密钥文件、IDE 配置、操作系统文件）
4. 生成完整 .gitignore（覆盖该技术栈的常见忽略项 + 敏感文件）
5. 标记任何疑似含敏感信息的文件（提醒检查 .env、配置文件、密钥）

输出格式：
- 结构评估（符合/需调整项）
- 整理建议清单
- 完整 .gitignore 内容（代码块）
- 敏感文件警示（需在提交前确认的文件）

约束：.gitignore 必须覆盖该技术栈的依赖目录、构建产物和常见敏感文件；对疑似敏感文件必须警示而非忽略。

质量标准：按建议整理后，仓库结构规范、不含依赖/产物/敏感文件。

常见失败情况：.gitignore 漏掉 .env 或密钥导致凭据泄露；提交了 node_modules/venv 等依赖目录导致仓库臃肿。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下目录结构评估是否存在以下问题：
1. .gitignore 是否覆盖了 .env、密钥、本地配置等敏感文件？
2. 是否排除了依赖目录和构建产物（避免仓库臃肿）？
3. 是否警示了疑似含敏感信息的文件？
4. 是否识别了缺失的标准文件（README/LICENSE/.gitignore）？

【粘贴目录结构评估】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善目录结构评估。补全 .gitignore 中的敏感文件和依赖产物，补充敏感文件警示，标记缺失的标准文件。

原始评估：【粘贴原始评估】
自查意见：【粘贴自查结果】

2.5 交付给下游节点¶

将 .gitignore 内容和整理建议复制，交给节点 5（Git 初始化专家）。整理目录和确认无敏感文件后，再进行 Git 初始化。

2.6 人工验收清单¶

[ ] .gitignore 是否覆盖了敏感文件（.env/密钥/本地配置）？
[ ] 是否排除了依赖目录和构建产物？
[ ] 是否警示了疑似敏感文件？
[ ] 是否标记了缺失的标准文件？

节点 3：README 生成专家（招牌节点）¶

3.1 节点定位¶

这是本工作流的招牌节点。 生成专业的开源项目 README，而不是普通说明文。一个合格的开源 README 必须包含以下要素，让陌生访问者在几分钟内理解项目价值并上手：

要素	作用
一句话介绍	访问者 3 秒内判断是否相关
解决什么问题	说明项目存在的理由
核心功能	项目能做什么
快速开始	让用户最快跑起来
项目结构	帮助理解代码组织
技术栈	让人判断技术契合度
使用示例	展示真实用法
原创性说明	说明原创性（尤其参赛/开源场景）
Roadmap	展示项目方向
License	明确使用授权

3.2 输入与输出¶

输入：节点 1 仓库定位 + 项目信息 + 技术栈 + 目录结构

输出：完整 README.md（含上述全部要素）

3.3 使用顺序¶

先用「快速生成版」生成 README 初稿。
正式开源或参赛项目，使用「专家增强版」。
用「自查审稿版」检查是否包含全部要素、示例是否可运行。
有问题则用「返修优化版」补充。
对照 3.6 验收清单确认，通过后交给节点 4。

3.4 提示词包¶

A. 快速生成版¶

你是一位开源文档工程师。请为以下项目生成 README。

项目定位：【粘贴节点1定位】
技术栈：【填入】
核心功能：【填入】

README 必须包含：
1. 项目名 + 一句话介绍
2. 解决什么问题
3. 核心功能
4. 快速开始（安装 + 运行）
5. 项目结构
6. 技术栈
7. 使用示例
8. 原创性说明
9. Roadmap
10. License

用 Markdown 输出，可直接作为 README.md。

B. 专家增强版¶

你是一位资深开源文档工程师，写过多个高质量开源项目的 README。

任务：为以下项目生成专业的开源 README，让陌生访问者快速理解并上手。

输入：
- 仓库定位：【粘贴节点1】
- 项目信息：【填入项目名、目标用户】
- 技术栈：【填入语言/框架/版本】
- 目录结构：【粘贴节点2整理后的结构】
- 核心功能：【填入功能列表】

README 结构（按此顺序）：
1. 标题 + 一句话介绍（醒目，3秒理解）
2. 徽章（可选：License、构建状态等）
3. 解决什么问题（背景 + 痛点）
4. 核心功能（要点列表，每条具体）
5. 快速开始（前置依赖 → 安装 → 运行，命令可直接复制）
6. 使用示例（真实场景的代码/命令示例 + 预期输出）
7. 项目结构（目录树 + 关键目录说明）
8. 技术栈（用了什么，版本要求）
9. 原创性说明（项目原创性、参考来源声明）
10. Roadmap（已完成 / 进行中 / 计划中）
11. License（授权方式）

要求：
- 命令示例可直接复制（提醒需替换的占位符）
- 使用示例展示真实用法，不是 "hello world" 占位
- 快速开始要让用户用最少步骤跑起来
- 语言简洁，避免营销腔

输出：完整 Markdown，可直接作为 README.md

约束：所有命令必须标注需用户替换的部分；不编造不存在的功能；示例必须与实际项目一致。

质量标准：陌生开发者凭 README 即可理解项目价值、独立完成安装运行。

常见失败情况：快速开始步骤跑不通；使用示例是占位符；缺少原创性说明；功能描述夸大。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下 README 是否存在以下问题：
1. 是否包含全部要素（一句话介绍/解决问题/功能/快速开始/示例/结构/技术栈/原创性/Roadmap/License）？
2. 快速开始的命令是否可直接复制并跑通（占位符是否标注）？
3. 使用示例是否是真实用法（而非 hello world 占位）？
4. 是否描述了不存在的功能（夸大）？
5. 是否包含原创性说明？

【粘贴 README】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善 README。补全缺失要素，修正跑不通的快速开始步骤，将占位示例改为真实用法，删除夸大描述，补充原创性说明。

原始 README：【粘贴原始 README】
自查意见：【粘贴自查结果】

3.5 交付给下游节点¶

将 README.md 复制，交给节点 4（License 与原创性说明专家）。README 中的 License 章节和原创性说明需与节点 4 保持一致。

3.6 人工验收清单¶

[ ] 是否包含全部 10 个要素？
[ ] 快速开始命令是否可直接复制并跑通？
[ ] 使用示例是否是真实用法？
[ ] 是否没有夸大不存在的功能？
[ ] 是否包含原创性说明？

节点 4：License 与原创性说明专家¶

4.1 节点定位¶

帮助选择合适的开源 License，并撰写原创性声明。License 决定他人能怎么用你的代码，原创性说明在开源和参赛场景尤为重要。

4.2 输入与输出¶

输入：项目信息 + 使用的第三方依赖 + 使用场景（开源/参赛）

输出：License 选择建议 + LICENSE 文件内容 + 原创性声明

4.3 使用顺序¶

先用「快速生成版」得到 License 建议。
涉及商业使用或复杂依赖许可时，改用「专家增强版」。
用「自查审稿版」检查 License 是否与依赖兼容、原创性声明是否完整。
有问题则用「返修优化版」修正。
对照 4.6 验收清单确认，通过后交给节点 5。

4.4 提示词包¶

A. 快速生成版¶

你是一位开源许可顾问（注：以下为参考，重要法律问题请咨询专业人士）。请为以下项目推荐 License。

项目用途：【填入开源/参赛/商业】
是否希望他人可自由使用/修改/商用：【填入】

输出：
1. License 推荐（如 MIT/Apache-2.0/GPL，说明区别）
2. 推荐理由
3. 原创性声明草稿（说明哪些是原创、哪些参考了第三方）

B. 专家增强版¶

你是一位开源许可与合规顾问（注：以下为参考意见，正式合规问题请咨询法律专业人士）。

任务：为项目推荐合适的 License 并撰写原创性声明。

输入：
- 项目用途：【填入开源/参赛/商业】
- 第三方依赖：【填入主要依赖及其 License，如已知】
- 使用意向：【填入是否允许商用、是否要求衍生作品开源】

处理步骤：
1. 根据使用意向推荐 License（MIT 宽松 / Apache-2.0 含专利条款 / GPL 强 copyleft）
2. 说明各 License 的核心区别和适用场景
3. 检查与主要依赖的 License 兼容性（如 GPL 依赖会影响整体许可）
4. 撰写原创性声明（原创部分、参考/引用部分、依赖致谢）
5. 如为参赛项目，强调原创性声明的重要性

输出格式：
- License 推荐（含理由和区别说明）
- 依赖兼容性提示
- 原创性声明草稿

约束：明确标注这是参考意见而非法律意见；原创性声明必须真实，不得为了"显得原创"而隐瞒第三方来源。

质量标准：用户能理解 License 选择的影响，并有一份诚实的原创性声明。

常见失败情况：选了与 GPL 依赖不兼容的宽松 License；原创性声明隐瞒了实际参考的来源。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下 License 与原创性方案是否存在以下问题：
1. 推荐的 License 是否与主要依赖的 License 兼容？
2. 是否说明了所选 License 的核心影响（能否商用、是否要求衍生开源）？
3. 原创性声明是否诚实（如实说明参考来源，未隐瞒）？
4. 是否标注了"参考意见，非法律意见"？

【粘贴 License 与原创性方案】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善 License 与原创性方案。修正许可兼容性问题，补充 License 影响说明，使原创性声明如实完整，加上免责标注。

原始方案：【粘贴原始方案】
自查意见：【粘贴自查结果】

4.5 交付给下游节点¶

将 License 选择和原创性声明复制，交给节点 5（Git 初始化专家）。LICENSE 文件将随首次提交一起加入仓库。

4.6 人工验收清单¶

[ ] License 是否与主要依赖兼容？
[ ] 是否说明了 License 的核心影响？
[ ] 原创性声明是否诚实完整？
[ ] 是否标注了非法律意见？

节点 5：Git 初始化与远程绑定专家¶

5.1 节点定位¶

提供 Git 初始化和远程仓库绑定的完整步骤，覆盖 HTTPS、GitHub CLI、SSH 三种认证路径。不假设用户已配置认证，让任何认证状态的用户都能完成发布。

5.2 输入与输出¶

输入：节点 1 仓库命名 + 节点 2 .gitignore + GitHub 账号情况

输出：Git 初始化与远程绑定步骤（三种认证路径）

5.3 使用顺序¶

先用「快速生成版」得到初始化步骤。
用户认证情况不明或需要多路径说明时，使用「专家增强版」。
用「自查审稿版」检查步骤是否完整、命令是否标注替换项。
有问题则用「返修优化版」补充。
对照 5.6 验收清单确认，通过后交给节点 6。

5.4 提示词包¶

A. 快速生成版¶

你是一位 Git 操作向导。请提供本地项目初始化并推送到 GitHub 的步骤。

仓库名：【填入】
GitHub 用户名：【填入】

请提供步骤，并说明命令中需要替换的部分。
注意：不要假设用户已配置认证，简要说明 HTTPS 和 SSH 的区别。

示例命令格式：
git init
git add .
git commit -m "..."
git remote add origin <仓库地址>
git push -u origin main

B. 专家增强版¶

你是一位 Git 与 GitHub 操作专家。

任务：提供从本地项目到 GitHub 远程仓库的完整初始化和推送步骤，覆盖三种认证路径。

输入：
- 仓库名：【填入】
- GitHub 用户名：【填入】
- .gitignore：【确认已就位】
- 默认分支偏好：【main】

提供以下内容：

【第一步：本地 Git 初始化】（认证无关）

确认 .gitignore 已就位，且无敏感文件被纳入¶

git init git add . git status # 推送前务必检查：确认没有 .env、密钥等敏感文件 git commit -m "Initial commit"

【第二步：在 GitHub 创建远程仓库 + 推送】（三种认证路径，选其一）

路径 A — GitHub CLI（推荐，最简单）：

gh repo create <仓库名> --public --source=. --remote=origin --push

路径 B — HTTPS（需 Personal Access Token）：

先在 GitHub 网页手动创建空仓库¶

git remote add origin https://github.com/<用户名>/<仓库名>.git git branch -M main git push -u origin main

推送时输入用户名和 Personal Access Token（不是密码）¶

路径 C — SSH（需配置 SSH key）：

前提：已生成 SSH key 并添加到 GitHub 账号¶

git remote add origin git@github.com:<用户名>/<仓库名>.git git branch -M main git push -u origin main

要求：
- 明确标注每条命令中需替换的 <占位符>
- 说明三种路径各自的前提条件
- 强调 push 前用 git status 检查无敏感文件
- 如果用户认证未配置，指明对应路径的配置入口（不展开详细配置）

约束：不假设用户已认证；提醒推送前检查敏感文件；命令需可直接复制并替换占位符。

质量标准：不同认证状态的用户都能找到适合自己的路径完成推送。

常见失败情况：直接 push 前没检查导致敏感文件入库；假设用户已配置认证导致卡在认证环节。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下 Git 初始化步骤是否存在以下问题：
1. 是否提供了三种认证路径（GitHub CLI / HTTPS / SSH）？
2. 是否在 push 前包含了 git status 检查敏感文件的步骤？
3. 命令中的占位符（用户名/仓库名）是否都标注了需替换？
4. 是否说明了各认证路径的前提条件？

【粘贴 Git 初始化步骤】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善 Git 初始化步骤。补全缺失的认证路径，增加 push 前敏感文件检查，标注所有占位符，补充各路径前提条件。

原始步骤：【粘贴原始步骤】
自查意见：【粘贴自查结果】

5.5 交付给下游节点¶

将 Git 初始化步骤复制，交给节点 6（提交信息专家）。首次提交的信息规范由节点 6 提供。

5.6 人工验收清单¶

[ ] 是否提供了三种认证路径？
[ ] 是否在 push 前包含敏感文件检查（git status）？
[ ] 命令占位符是否都标注了需替换？
[ ] 是否说明了各路径的前提条件？

节点 6：提交信息专家¶

6.1 节点定位¶

提供规范的提交信息（commit message）写法，让提交历史清晰可读。良好的提交历史是项目可维护性的体现，也方便协作者理解变更。

6.2 输入与输出¶

输入：项目变更情况 + 团队协作情况

输出：提交信息规范 + 首次提交建议 + 后续提交示例

6.3 使用顺序¶

先用「快速生成版」得到提交规范。
多人协作或需要规范化历史时，改用「专家增强版」。
用「自查审稿版」检查规范是否清晰可执行。
有问题则用「返修优化版」调整。
对照 6.6 验收清单确认，通过后交给节点 7。

6.4 提示词包¶

A. 快速生成版¶

你是一位 Git 提交规范顾问。请提供提交信息规范。

项目情况：【填入单人/多人，是否需要规范化】

输出：
1. 提交信息格式（推荐 Conventional Commits：type: description）
2. 常用 type 说明（feat/fix/docs/refactor/test/chore）
3. 首次提交建议
4. 几个提交示例

B. 专家增强版¶

你是一位 Git 工作流规范专家。

任务：为项目提供清晰的提交信息规范。

输入：
- 协作情况：【填入单人/多人】
- 是否使用自动化（如根据 commit 生成 changelog）：【填入】

提供内容：
1. 提交信息格式（推荐 Conventional Commits：`<type>(<scope>): <description>`）
2. type 类型表（feat 新功能 / fix 修复 / docs 文档 / style 格式 / refactor 重构 / test 测试 / chore 杂项）
3. 编写原则（描述用动词开头、简洁、说明"做了什么"而非"怎么做"）
4. 首次提交建议（"Initial commit" 或更具体的描述）
5. 正例与反例对比

输出格式：
- 格式规范
- type 类型表
- 正例/反例对比表
- 首次提交建议

约束：规范要可执行、不繁琐；适配项目协作规模（单人项目不必过度规范）。

质量标准：照此规范，提交历史清晰，他人浏览即可了解项目演进。

常见失败情况：提交信息写成 "update"、"fix bug" 这类无信息量的描述；规范过于繁琐导致难以坚持。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下提交规范是否存在以下问题：
1. 是否提供了具体的提交信息格式和 type 类型？
2. 是否有正例/反例帮助理解？
3. 规范是否适配项目规模（单人项目是否过度繁琐）？
4. 首次提交建议是否给出？

【粘贴提交规范】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善提交规范。补充格式和 type 说明，增加正反例，调整繁简度以适配项目规模。

原始规范：【粘贴原始规范】
自查意见：【粘贴自查结果】

6.5 交付给下游节点¶

将提交信息规范复制，交给节点 7（GitHub Actions 检查专家）。

6.6 人工验收清单¶

[ ] 是否提供了具体的提交格式和 type？
[ ] 是否有正例/反例？
[ ] 规范是否适配项目规模？

节点 7：GitHub Actions 检查专家¶

7.1 节点定位¶

检查或建议 GitHub Actions CI 配置，确保自动化流程正确。CI 能在每次提交时自动验证代码，是开源项目质量的保障。

7.2 输入与输出¶

输入：技术栈 + 现有 CI 配置（如有）+ 项目需求

输出：CI 配置检查结果 / CI 配置建议

7.3 使用顺序¶

先用「快速生成版」检查或建议 CI 配置。
需要完整 CI 流程或多环境时，改用「专家增强版」。
用「自查审稿版」检查配置是否正确、权限是否合理。
有问题则用「返修优化版」修正。
对照 7.6 验收清单确认，通过后交给节点 8。

7.4 提示词包¶

A. 快速生成版¶

你是一位 CI 配置助手。请检查/建议 GitHub Actions 配置。

技术栈：【填入】
现有配置（如有）：【粘贴 .github/workflows/*.yml 或留空】
需求：【填入：测试/构建/部署】

输出：
1. 配置检查结果（如有现有配置）或推荐配置
2. YAML 是否正确（缩进、语法）
3. 需要的权限说明

B. 专家增强版¶

你是一位 CI/CD 工程师，熟悉 GitHub Actions。

任务：检查或生成 GitHub Actions 配置，确保正确可运行。

输入：
- 技术栈：【填入语言/框架/版本】
- 现有 CI 配置：【粘贴或留空】
- CI 需求：【填入测试/构建/lint/部署】

处理步骤：
1. 如有现有配置：检查 YAML 语法、缩进、action 版本、触发条件、权限设置
2. 如无配置：生成适配技术栈的基础 CI（安装依赖 → lint → 测试 → 构建）
3. 检查权限设置（最小必要权限原则，部署类需要的权限单独说明）
4. 检查触发条件（push/PR 的分支限制是否合理）
5. 提示常见陷阱（依赖缓存、矩阵测试、secrets 使用）

输出格式：
- 配置检查结果 / 推荐配置（完整 YAML，代码块）
- 权限说明
- 常见问题提示

约束：YAML 必须语法正确、缩进规范；权限遵循最小必要原则；不在配置中硬编码 secrets。

质量标准：配置可直接放入 .github/workflows/ 并成功运行。

常见失败情况：YAML 缩进错误导致 workflow 不触发；权限过大；secrets 硬编码在配置中。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下 CI 配置是否存在以下问题：
1. YAML 语法和缩进是否正确？
2. 权限是否遵循最小必要原则？
3. 是否在配置中硬编码了 secrets（应使用 GitHub Secrets）？
4. 触发条件（分支限制）是否合理？

【粘贴 CI 配置】

逐条说明问题。

D. 返修优化版¶

根据自查意见修正 CI 配置。修复 YAML 缩进/语法，收紧权限，将硬编码 secrets 改为引用 GitHub Secrets，调整触发条件。

原始配置：【粘贴原始配置】
自查意见：【粘贴自查结果】

7.5 交付给下游节点¶

将 CI 配置检查结果复制，交给节点 8（Release 说明专家）。

7.6 人工验收清单¶

[ ] YAML 语法和缩进是否正确？
[ ] 权限是否遵循最小必要原则？
[ ] 是否没有硬编码 secrets？
[ ] 触发条件是否合理？

节点 8：Release 说明专家¶

8.1 节点定位¶

撰写 Release 说明和确定版本号。规范的 Release 让用户清楚每个版本的变化，版本号传达兼容性信息。

8.2 输入与输出¶

输入：项目变更内容 + 当前版本情况

输出：版本号建议（语义化版本）+ Release 说明

8.3 使用顺序¶

先用「快速生成版」得到 Release 说明。
首次发版或有重大变更时，改用「专家增强版」。
用「自查审稿版」检查版本号是否符合语义化规范、说明是否完整。
有问题则用「返修优化版」修正。
对照 8.6 验收清单确认，通过后交给节点 9。

8.4 提示词包¶

A. 快速生成版¶

你是一位发布说明撰写助手。请撰写 Release 说明。

本次变更：【填入新功能/修复/变更】
当前版本：【填入或首次发布】

输出：
1. 版本号建议（语义化版本 MAJOR.MINOR.PATCH）
2. Release 说明（新增/修复/变更分类列出）

B. 专家增强版¶

你是一位发布管理专家，熟悉语义化版本规范。

任务：确定版本号并撰写 Release 说明。

输入：
- 本次变更内容：【填入】
- 当前版本：【填入或首次发布】
- 是否有破坏性变更：【填入】

处理步骤：
1. 按语义化版本（SemVer）确定版本号：
   - MAJOR：不兼容的破坏性变更
   - MINOR：向后兼容的新功能
   - PATCH：向后兼容的问题修复
   - 首次发布建议 0.1.0（开发中）或 1.0.0（稳定）
2. 撰写 Release 说明，分类组织（✨ 新增 / 🐛 修复 / ⚠️ 破坏性变更 / 📝 文档）
3. 破坏性变更需单独突出并说明迁移方式
4. 标注已知问题（如有）

输出格式：
- 版本号 + 理由
- Release 说明（分类列出变更）
- 破坏性变更迁移说明（如有）

约束：版本号必须符合 SemVer；破坏性变更必须明确标注；不夸大变更。

质量标准：用户读 Release 说明即可判断是否升级、升级有何影响。

常见失败情况：破坏性变更只升 PATCH 号误导用户；Release 说明只写 "bug fixes" 无具体内容。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下 Release 说明是否存在以下问题：
1. 版本号是否符合语义化版本（破坏性变更升 MAJOR，新功能升 MINOR）？
2. 破坏性变更是否明确标注并说明迁移方式？
3. 变更说明是否具体（而非笼统的 "bug fixes"）？

【粘贴 Release 说明】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善 Release 说明。校正版本号，突出破坏性变更并补充迁移说明，将笼统描述改为具体变更。

原始说明：【粘贴原始说明】
自查意见：【粘贴自查结果】

8.5 交付给下游节点¶

将版本号和 Release 说明复制，交给节点 9（发布后复盘专家）。

8.6 人工验收清单¶

[ ] 版本号是否符合语义化版本规范？
[ ] 破坏性变更是否明确标注并有迁移说明？
[ ] 变更说明是否具体？

节点 9：发布后复盘专家¶

9.1 节点定位¶

提供发布后的检查清单和后续维护建议，确保发布真正完成且可持续维护。发布不是终点，而是项目生命周期的开始。

9.2 输入与输出¶

输入：全部前序节点产出 + 仓库 URL

输出：发布检查清单结果 + 后续维护建议

9.3 使用顺序¶

先用「快速生成版」做发布检查。
正式开源项目需要长期维护时，改用「专家增强版」。
用「自查审稿版」确认检查无遗漏。
有缺口则返回对应节点补齐。
对照 9.6 验收清单确认。

9.4 提示词包¶

A. 快速生成版¶

你是一位发布检查员。请提供 GitHub 发布后的检查清单。

仓库情况：【填入已完成的内容】

输出发布后检查清单：
- [ ] README 在 GitHub 上渲染正常
- [ ] LICENSE 已识别
- [ ] 无敏感文件被提交
- [ ] CI 运行通过（如有）
- [ ] Topics 已设置
+ 后续维护建议

B. 专家增强版¶

你是一位开源项目运营专家。

任务：提供发布后检查清单和后续维护建议。

输入：
- 全部前序产出：【粘贴各节点关键结果】
- 仓库 URL：【填入】

发布后检查清单：
1. 渲染检查（README/文档在 GitHub 上渲染是否正常）
2. 文件检查（LICENSE 是否被 GitHub 识别、.gitignore 是否生效、无敏感文件入库）
3. CI 检查（Actions 是否运行通过）
4. 可发现性（Topics 是否设置、描述是否填写）
5. 可用性（按 README 快速开始能否真的跑起来——建议在干净环境验证）
6. 链接检查（README 中的链接是否有效）

后续维护建议：
- Issue / PR 响应机制
- 版本发布节奏
- 文档更新习惯
- 安全方面（依赖更新、敏感信息定期排查）

输出格式：
- 发布后检查清单（可勾选）
- 后续维护建议清单

约束：检查项必须可执行；建议适配项目规模（个人项目不必照搬大型项目运营）。

质量标准：完成清单后可确信项目已正确发布且具备基本可维护性。

常见失败情况：发布后才发现 README 渲染异常或敏感文件已入库；没有验证快速开始能否跑通。

C. 自查审稿版¶

此为当前节点的自查模式，不是新的专家角色。

请检查以下发布检查清单是否存在以下问题：
1. 是否包含"无敏感文件入库"的检查（最关键）？
2. 是否包含在干净环境验证快速开始能否跑通？
3. 是否检查了 README 渲染和链接有效性？
4. 后续维护建议是否适配项目规模？

【粘贴发布检查清单】

逐条说明问题。

D. 返修优化版¶

根据自查意见完善发布检查清单。补充敏感文件检查和快速开始验证，增加渲染和链接检查，调整维护建议的规模适配。

原始清单：【粘贴原始清单】
自查意见：【粘贴自查结果】

9.5 交付给下游节点¶

本节点是工作流终点。检查通过后，仓库即完成发布。存在缺口时返回对应节点补齐。

9.6 人工验收清单¶

[ ] 是否确认无敏感文件入库？
[ ] 是否在干净环境验证了快速开始能跑通？
[ ] README 渲染和链接是否正常？
[ ] CI（如有）是否运行通过？

节点交接说明¶

上游节点	交接内容	下游节点
节点 1 仓库定位	定位陈述 + 命名 + Topics	节点 2、节点 3
节点 2 目录检查	.gitignore + 整理建议	节点 5
节点 3 README	完整 README.md	节点 4
节点 4 License	License + 原创性声明	节点 5
节点 5 Git 初始化	三种认证路径的初始化步骤	节点 6
节点 6 提交信息	提交规范	节点 7
节点 7 Actions	CI 配置检查/建议	节点 8
节点 8 Release	版本号 + Release 说明	节点 9
节点 9 发布复盘	发布检查清单 + 维护建议	最终输出模板

最终输出模板¶

【项目名】GitHub 发布包

━━ 仓库定位 ━━
仓库名：【填入】
一句话定位：【填入】
可见性：【公开/私有】
Topics：【列出】

━━ 仓库文件清单 ━━
- README.md（节点3）
- LICENSE（节点4）
- .gitignore（节点2）
- .github/workflows/（节点7，如有）

━━ 发布步骤 ━━
1. 整理目录，确认无敏感文件（节点2）
2. git init / add / commit（节点5）
3. 创建远程仓库 + push（节点5，三选一认证路径）
4. 设置 Topics 和描述（节点1）
5. 创建 Release（节点8，如需要）

━━ 原创性声明 ━━
【节点4内容】

━━ 发布后检查 ━━
- [ ] 无敏感文件入库
- [ ] README 渲染正常
- [ ] LICENSE 已识别
- [ ] 快速开始可跑通
- [ ] CI 通过（如有）

常见错误¶

错误 1：敏感文件随代码一起提交

表现：.env、密钥文件、本地配置被推送到公开仓库，造成凭据泄露。

修复：节点 2 生成完整 .gitignore，节点 5 在 push 前用 git status 检查，节点 9 发布后再次确认。三道关卡确保敏感文件不入库。

错误 2：README 写成普通说明文

表现：README 只有一段项目描述，没有快速开始、使用示例、原创性说明，访问者看不懂怎么用。

修复：执行节点 3（招牌节点），按 10 要素结构撰写，尤其确保快速开始可跑通、有真实使用示例。

错误 3：假设用户已配置 Git 认证

表现：发布步骤直接 git push，但用户没配置认证，卡在认证环节不知所措。

修复：节点 5 提供 HTTPS、GitHub CLI、SSH 三种认证路径，用户按自己的情况选择，并标注各路径前提条件。

人工验收清单¶

[ ] 仓库命名和定位是否规范清晰？
[ ] .gitignore 是否覆盖敏感文件，且确认无敏感文件入库？
[ ] README 是否包含 10 要素且快速开始可跑通？
[ ] License 和原创性声明是否完整诚实？
[ ] 发布步骤是否提供了适配用户认证情况的路径？

延伸玩法¶

变体 1：参赛项目版：强化节点 4 的原创性说明（参赛场景的关键），在 README 中突出参赛说明、Demo 链接和演示视频，节点 8 的 Release 对应提交版本。
变体 2：已有仓库规范化版：对已发布但不规范的仓库，重点走节点 2（目录整理）→ 节点 3（README 重写）→ 节点 4（补 License），跳过初始化步骤。
进阶组合：与"工作流 15（MkDocs 发布工作流）"结合，发布代码仓库的同时配套发布文档站点；与"工作流 11（程序员开发工作流）"结合，将开发工作流的交付物直接进入本发布工作流。

工作流 14：从本地项目到 GitHub 开源仓库的 AI 发布工作流¶

输入材料清单¶

工作流总览¶

专家节点详解¶

节点 1：仓库定位专家¶

1.1 节点定位¶

1.2 输入与输出¶

1.3 使用顺序¶

1.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

C. 自查审稿版¶

D. 返修优化版¶

1.5 交付给下游节点¶

1.6 人工验收清单¶

节点 2：目录结构检查专家¶

2.1 节点定位¶

2.2 输入与输出¶

2.3 使用顺序¶

2.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

C. 自查审稿版¶

D. 返修优化版¶

2.5 交付给下游节点¶

2.6 人工验收清单¶

节点 3：README 生成专家（招牌节点）¶

3.1 节点定位¶

3.2 输入与输出¶

3.3 使用顺序¶

3.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

C. 自查审稿版¶

D. 返修优化版¶

3.5 交付给下游节点¶

3.6 人工验收清单¶

节点 4：License 与原创性说明专家¶

4.1 节点定位¶

4.2 输入与输出¶

4.3 使用顺序¶

4.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

C. 自查审稿版¶

D. 返修优化版¶

4.5 交付给下游节点¶

4.6 人工验收清单¶

节点 5：Git 初始化与远程绑定专家¶

5.1 节点定位¶

5.2 输入与输出¶

5.3 使用顺序¶

5.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

确认 .gitignore 已就位，且无敏感文件被纳入¶

前提：已安装 gh 并登录（gh auth login）¶

先在 GitHub 网页手动创建空仓库¶

推送时输入用户名和 Personal Access Token（不是密码）¶

前提：已生成 SSH key 并添加到 GitHub 账号¶

C. 自查审稿版¶

D. 返修优化版¶

5.5 交付给下游节点¶

5.6 人工验收清单¶

节点 6：提交信息专家¶

6.1 节点定位¶

6.2 输入与输出¶

6.3 使用顺序¶

6.4 提示词包¶

A. 快速生成版¶

B. 专家增强版¶

C. 自查审稿版¶

D. 返修优化版¶

6.5 交付给下游节点¶

6.6 人工验收清单¶

节点 7：GitHub Actions 检查专家¶

7.1 节点定位¶

7.2 输入与输出¶

7.3 使用顺序¶

7.4 提示词包¶