FIT 框架自动化发布指南：用 /create-release-note 一键生成结构化 Release Notes-北京尧图网络

人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载导读本指南围绕 FIT 框架仓库内置的 Claude Code 自定义命令.claude/commands/create-release-note.md完整讲解如何从 PR、commit 与 Issue 中自动收集变更信息按平台与类型分类最终生成符合项目规范的 Release Notes并可一键创建 GitHub Draft Release。读完本文你将掌握/create-release-note version [prev-version]的两种执行路径常规路径与 x.y.0 合并路径、模块/类型分类规则、输出模板格式以及它与/release发布命令的完整衔接方式。一、命令定位为什么需要自动化的 Release NotesFIT 框架是一个包含多平台、多模块的企业级 AI 开发框架Java/Python 双语言的 FIT 函数平台、Waterflow 流调度平台、FEL 表达式语言以及 AI 开发配置模块。每个发布周期内合并的 PR、直接提交的 commit 和关联的 Issue 数量庞大手工整理 Release Notes 不仅耗时还容易遗漏或分类混乱。/create-release-note命令正是为了解决这一问题而设计它从 PR、commit 和 Issue 中自动收集变更信息按模块和类型分类生成符合项目格式的 Release Notes并支持创建 GitHub Draft Release。值得特别说明的是该命令的规则并非凭空设定而是与仓库的协作规范深度绑定提交信息遵循 Conventional Commits 规范格式为type(scope): subject其中type包括feat、fix、docs、refactor、test、chore等scope对应fit、waterflow、fel、framework、ohscript等模块——这正是命令中按类型分组与按模块分组的判断基础参见 CONTRIBUTING.md 与 .claude/CLAUDE.md仓库标签管理规范要求纯数字版本以v开头如v3.6.0发布分支与标签名保持一致——这与命令中上一版本 tag 推断逻辑一致参见 CONTRIBUTING.md当前仓库主版本为3.7.0-SNAPSHOT见根 pom.xml对应的正是x.y.0 合并路径这一典型场景。二、用法与参数说明基本用法/release-notes version # 自动推断上一版本 /release-notes version prev-version # 手动指定版本范围使用示例/create-release-note 3.6.3 # 自动推断上一版本为 3.6.2 /create-release-note 3.6.3 3.6.2 # 手动指定范围 /create-release-note 3.7.0 # x.y.0 版本合并 3.6.x 系列的所有 release notes参数说明参数含义格式必填version当前发布版本号X.Y.Z必需prev-version上一版本号X.Y.Z可选不提供则自动推断参数来源$ARGUMENTS。从源码看参数格式校验要求X、Y、Z均为非负整数若格式不正确命令会报错退出并提示错误版本号格式不正确期望格式为 X.Y.Z例如 3.6.3。这一校验规则与 .claude/commands/release.md 中/release命令的版本校验逻辑保持一致两个命令共同构成了先发布、后生成 notes的完整闭环。三、执行流程总览十五条步骤的双路径设计命令的执行逻辑可以概括为公共步骤 → 分流 → 公共步骤步骤 1-3 为公共步骤解析参数、确定版本范围、判断版本类型。步骤 3 根据 PATCH 位分流合并路径PATCH 0如3.7.0执行步骤 4-7然后跳到步骤 14常规路径PATCH 0如3.6.3执行步骤 8-13然后继续步骤 14。步骤 14-15 为公共步骤展示确认、创建 Draft Release。这种分流设计非常务实x.y.0版本通常是对上一个 minor 系列所有补丁版本的汇总Major release因此直接合并已有 release notes 而非重新计算而普通修订版本则基于 tag 之间的 PR/commit 精确计算。四、公共步骤详解步骤 1解析参数从$ARGUMENTS中提取参数支持两种形式单参数version— 当前版本号双参数version prev-version— 当前版本号和上一版本号。版本号格式验证必须匹配X.Y.Z格式X、Y、Z 均为非负整数。格式不正确时报错退出。步骤 2确定版本范围当前版本 tag为vversion如v3.6.3。上一版本 tag 推断逻辑仅当未指定prev-version时先获取所有已排序的 taggit tag --sort-v:refname然后按 PATCH 位分别处理如果 PATCH 0如3.6.3查找同一 minor 系列中的前一个 tag如v3.6.2如果 PATCH 0如3.6.0查找前一个 minor 系列的最后一个 tag如v3.5.x中最大的。验证 tag 存在git rev-parse vversion git rev-parse vprev-version如果任一 tag 不存在报错退出错误Tag vversion 不存在请确认 tag 已创建。步骤 3判断版本类型并选择路径根据版本号的 PATCH 部分选择不同的生成路径如果 PATCH 0如3.7.0→ 走合并路径从步骤 4 开始如果 PATCH 0如3.6.3→ 走常规路径从步骤 8 开始。五、合并路径PATCH 0x.y.0 版本步骤 4查找前一 minor 系列的所有已发布 releasegh release list --limit 50 --json tagName,isDraft,isPrerelease从结果中筛选满足以下条件的条目tagName以vX.(Y-1).开头例如版本3.7.0则筛选v3.6.开头isDraft falseisPrerelease false。如果未找到任何已发布的 release提示用户并回退到常规路径步骤 8。步骤 5按版本号升序获取各 release body对步骤 4 筛选出的每个 release tag按版本号升序获取其内容gh release view vtag --json body --jq .body步骤 6合并所有 release body将各版本的 release notes 合并为一份完整文档按版本顺序拼接按v3.6.1、v3.6.2、v3.6.3... 的顺序处理同平台同类型条目合并将各版本中相同平台如 FIT Function Platform相同类型如 Enhancement的条目合并到一起去重 Contributors合并所有❤️ Contributors段落中的贡献者去重后按贡献量出现次数降序排列。步骤 7生成 Overviewx.y.0 版本始终视为 Major release在顶部添加 Overview总结段落AI 根据合并内容生成 2-3 句话概括整个 minor 系列的核心主题和亮点每个平台添加 Features Overview要点列表从该平台的 Enhancement 条目中提炼 3-5 个关键特性要点。完成后跳到步骤 14。结合仓库现状当前根 pom.xml 的版本为3.7.0-SNAPSHOT若发布3.7.0合并路径将自动汇总 3.6.x 系列的所有已发布 release notes无需重复计算——这正是该路径的核心价值为 minor 系列收官版本生成一份总览式的完整发布说明。六、常规路径PATCH 0步骤 8收集合并的 PR主要数据源—— 获取两个 tag 之间的日期范围然后用ghCLI 查询合并的 PR# 获取两个 tag 的日期 git log vprev-version --format%aI -1 git log vversion --format%aI -1 # 获取目标分支从当前版本号推断如 3.6.x # 分支名格式: X.Y.x # 获取合并到目标分支的 PR gh pr list --state merged --base branch \ --json number,title,body,author,labels,mergedAt,url \ --limit 200 --search merged:YYYY-MM-DD..YYYY-MM-DD补充数据源—— 获取没有关联 PR 的直接 commitgit log vprev-version..vversion --format%H %s --no-merges对比 PR 列表和 commit 列表找出没有关联 PR 的 commit这些 commit 也应纳入 release notes。这里的目标分支名X.Y.x如3.6.x与仓库的分支管理规范一致版本分支的命名格式就是主版本号.次版本号.xx代表该 minor 系列下的所有修订版本均在该分支上开发参见 CONTRIBUTING.md。步骤 9收集关联的 Issue从每个 PR 的 body 中提取关联的 Issue匹配模式Closes #N、Fixes #N、Resolves #N不区分大小写也匹配close #N、fix #N、resolve #N及其复数形式。对每个提取到的 Issue 编号gh issue view N --json number,title,labels,url收集 Issue 详情用于丰富 release notes 的描述。这一步的意义在于PR 描述中常用Closes #N等关键词关联 Issue把这些 Issue 的标题与标签纳入 notes可以让读者同时看到修复了什么和关联的需求背景。步骤 10分类 —— 按模块分组根据以下优先级判断每个 PR/commit 所属模块优先级判断依据示例1PR title 中的模块标签[fit],[FEL],[waterflow][fit] 修复空指针→ FIT2Conventional commit scopefeat(fit):,fix(waterflow):feat(waterflow): xxx→ Waterflow3PR 变更文件路径使用gh pr view N --json filesframework/fel/**→ FEL4默认归入 FIT Function Platform模块到平台的映射关键词 / 路径平台名称fit,python,docker,fit-launcher,framework/fit/**FIT Function Platformfel,FEL,framework/fel/**FIT Expression for LLMwaterflow,framework/waterflow/**Waterflow Flow Scheduling Platformclaude,.claude/,.ai-agents/, AI 相关配置 AI Development Configuration从仓库结构看这套映射与实际的代码目录划分完全对应framework/fit/java、framework/fit/python、framework/waterflow/java、framework/fel/java等目录与 CONTRIBUTING.md 中约定的模块名fit、waterflow、fel、framework、ohscript一一对应因此基于PR title 标签 → commit scope → 变更文件路径的优先级推断通常足够准确。复杂的跨模块 PR 仍可能需要人工调整这一点在命令的注意事项中也有明确说明。步骤 11分类 —— 按类型分组根据 PR title 的 conventional commit type 分类PR Title 前缀 / 特征分类feat,perf,refactor,chore(deps), 依赖升级✨ Enhancementfix✅ Bugfixdocs Documentation如果条目少于 3 个并入 Enhancement对照 .claude/CLAUDE.md 中定义的提交规范type:feat,fix,docs,refactor,test,chore可以发现 Release Notes 的类型分类正是对项目提交规范中type字段的进一步归并feat/perf/refactor/chore(deps)归为 Enhancement功能增强fix归为 Bugfix缺陷修复docs单独归为 Documentation且条目过少时会并入 Enhancement避免出现内容单薄的章节。步骤 12判断发布级别根据变更数量和性质判断输出详细程度Major release合并 PR 15 个生成 Overview总结段落2-3 句话概括本次发布的核心主题每个平台生成 Features Overview要点列表Regular release直接列出 Enhancement / Bugfix 条目不加 Overview。步骤 13生成 Release Notes按照项目已有格式输出 markdown。完整模板## FIT Function Platform ### ✨ Enhancement - [fit] 描述内容 by author1 and author2 in #123 - Upgrade xxx from v1 to v2 by author in #456 ### ✅ Bugfix - [fit] 修复xxx问题 by author in #100 and #789 ## FIT Expression for LLM ### ✨ Enhancement - [FEL] 描述内容 by author in #234 ## Waterflow Flow Scheduling Platform ### ✨ Enhancement - [waterflow] 描述内容 by author in #345 ## AI Development Configuration ### ✨ Enhancement - 描述内容 by author in #567 ## ❤️ Contributors contributor1, contributor2, contributor3格式规则从现有 release notes 中提炼条目格式- [module] 描述 by author1 and author2 in #N关联 Issue 和 PRin #Issue and #PR没有关联 PR 的 commit省略in [#N]部分直接写描述描述内容优先使用 PR title去掉type(scope):前缀首字母大写贡献者列表去重按贡献量PR 数量降序排列空平台如果某个平台没有任何变更不输出该平台的章节多作者如果 PR 有多个 co-author用and连接by a and b。七、公共步骤续步骤 14展示并确认将生成的 release notes完整输出给用户查看然后询问用户是否需要调整内容修改描述、调整分类、增删条目等是否创建 GitHub Draft Release。如果用户要求调整根据反馈修改后重新输出。这是一个AI 生成人工把关的环节——自动分类基于 title/scope/文件路径推断复杂 PR 可能存在误判人工确认可保证最终发布的 notes 准确无误。步骤 15创建 Draft Release用户确认后将 release notes 写入临时文件然后创建 Draft Releasegh release create vversion \ --title vversion \ --notes-file /tmp/release-notes-vversion.md \ --target release-branch-or-tag \ --draft输出结果✅ Draft Release 已创建 - Release URL: draft-release-url - 版本: vversion - 状态: Draft草稿 ⚠️ 请在 GitHub 上最终审核并发布 1. 打开上述 URL 2. 检查 Release Notes 内容 3. 确认无误后点击 Publish release注意--target release-branch-or-tag草稿可以指向发布分支或 tag配合--draft参数确保不会直接发布到正式版本必须经过人工审核。八、注意事项需要ghCLI本命令依赖 GitHub CLIgh请确保已安装并认证Tag 必须已存在运行本命令前确保vversion和上一版本的 tag 已创建通常由/release命令完成Draft 模式创建的是草稿 Release不会自动发布需要人工审核后在 GitHub 上发布PR 搜索范围基于日期范围搜索可能包含少量超出范围的 PR命令会尽力过滤模块分类准确性自动分类基于 title/scope/文件路径推断复杂 PR 可能需要人工调整x.y.0 合并路径依赖前一 minor 系列的 release 已在 GitHub 上发布非 Draft如果没有已发布的 release 则回退到常规路径。九、错误处理错误场景处理方式版本号格式错误提示正确格式并退出Tag 不存在提示确认 tag 已创建可能需要先执行/releaseghCLI 未安装或未认证提示安装/认证方法无合并 PR提示版本范围内没有找到合并的 PR建议检查 tag 和分支GitHub API 限流提示稍后重试x.y.0 无已发布 release提示前一 minor 系列没有已发布的 release回退到常规路径十、与发布流程的完整衔接/create-release-note并不是一个孤立的命令而是 FIT 框架发布流程的最后一环。配套的 /release 命令负责执行版本发布SNAPSHOT 版本替换、创建 Release commit 与 tagvX.Y.Z、创建发布分支release-X.Y.Z、准备下一 SNAPSHOT 版本。该命令输出总结时会明确提示后续手动操作# 可选生成 Release Notes 并创建 Draft Release /create-release-note X.Y.Z两个命令各司其职/release只做版本号替换和 Git 操作不含构建验证、不含自动推送/create-release-note负责在 tag 就绪后生成发布说明并创建草稿。仓库中同一目录下还提供了配套命令参见 .claude/commands//release version- 执行版本发布流程创建 tag 和发布分支/commit- 提交代码/create-pr- 创建 Pull Request。它们与/create-release-note共同构成提交 → 建 PR → 发布 → 生成 notes的完整自动化闭环确保每次发布既有规范的版本号管理又有结构清晰、可供社区检索引用的 Release Notes。赞分享人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载相关推荐OpenFGA 发布自动化指南用 create-release-pr.sh 一键完成版本发布 PR 与自动化接力OpenFGA 发布自动化指南用 create release pr.sh 一键完成版本发布 PR 与自动化接力本指南围绕 OpenFGA 仓库 scrip认证鉴权后端Apache TVM 发布自动化实践用 release 脚本生成 Release Notes 并验证候选发布包Apache TVM 发布自动化实践用 release 脚本生成 Release Notes 并验证候选发布包本文聚焦 Apache TVM 仓库 test编译器深度学习模型优化使用 rnw-scripts/generate-release-notes 自动化生成 React Native Windows 发布说明使用 rnw scripts/generate release notes 自动化生成 React Native Windows 发布说明本篇技术指南围绕跨平台前端上一篇RedwoodJS Logger 完全指南基于 pino 的 API 侧日志配置、脱敏与生产实践下一篇Meshery Catalog 实战ms-emails-grpc 设计在 Kubernetes 上的 gRPC 邮件微服务部署创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

FIT 框架自动化发布指南：用 /create-release-note 一键生成结构化 Release Notes

相关推荐

2007年C语言编码考试复盘：从链表反转到边界测试的核心考点

SpringBoot+Vue+MySQL构建电商平台毕业设计实战

别让Excel拖垮你的报税季——报税自动化实例演示

更多资讯

Windows 10家庭版中文用户名改英文：避坑指南与实操

AI对话记忆管理：有界与冻结双闸设计，稳定用户画像与跨会话上下文

openGauss逻辑存储结构全解：从表空间到数据块

如何用“五看”方法论做扎实的信息化三年战略规划？

数据库全局唯一存储方案

PyPTO入门：用Hello World理解结构化步骤调用与批量处理

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？