尧图网页设计 
CLIAI 应用MCP 服务【免费下载链接】OfficeCLIOfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.项目地址https://gitcode.com/GitHub_Trending/of/OfficeCLI点击查看免费下载本篇技术指南以仓库根目录 CONTRIBUTING.md 为核心骨架面向希望向 OfficeCLI 贡献代码的开发者与 AI Agent系统讲解其一 PR 一原子变更与每个 PR 必须附带可验证的验证方法两条硬性规范并结合仓库源码与示例脚本说明如何写出能快速通过维护者审查、可独立合入或回退的高质量 PR。读完本文你将掌握这套面向 AI 协作时代的贡献方法论如何用一条命令判断 diff 是否需要拆分、如何为 bug 修复与功能提交构造可复现的验证证据以及提交不合规时维护者的处理路径与贡献者权益保障。为什么 OfficeCLI 需要一套给 AI 看的贡献规范OfficeCLI 是一款定位为 AI Agent 而生的 Office 套件单一二进制、无需安装 Office即可让 AI 读写与自动化 Word、Excel、PowerPoint 文档见 README.md。项目的install命令会自动把技能文件安装进 Claude Code、Cursor、Windsurf、GitHub Copilot 等各类 AI 编码工具因此这个项目的主要贡献者很大概率就是 AI Agent而不是传统意义上逐行写代码的人类开发者。这带来一个真实的问题AI 生成的 diff 往往把多个不相关的改动揉进同一个 PR比如修了一个 bug 加了一个新功能 顺手改了个样式这会让审查、合入、回退变得极其困难。CONTRIBUTING.md 正是为此设计的一套极简但强制的协作契约——全文只强调两条规则其余代码风格、依赖、测试、文档都交由维护者在合入后的清理阶段处理贡献者无需为此焦虑。两条规则如下Rule 1One PR one atomic change一个 PR 只含一个原子变更Rule 2Every PR must include a verifiable validation method每个 PR 必须附带可验证的验证方法文档还提供了中文版 CONTRIBUTING.zh.md两条规则完全一致可直接对照阅读。Rule 1一 PR 一原子变更规则的准确含义一个 PR 必须且只能包含一个无法再分解的功能或 bug 修复。判断标准不是改动行数而是是否可以进一步拆分如果一次变更可以拆成多个各自具备独立价值的片段那么每一片都应该单独提交一个 PR。这条规则的收益是结构性的每个 PR 都能独立合入、独立回退revert。当一个 PR 只对应一个根因root cause时出了问题可以直接 revert 这一个 PR 而不影响其他已合入的功能反之若一个 PR 里塞了三个无关修复revert 它就会把三个修复一起撤掉审查者也无法判断某个行为变化到底来自哪一行。提交前的自检让 AI 帮你做拆分分析CONTRIBUTING.md 建议在开 PR 之前直接向你的 AI 工具提问Analyze this diff. Can it be decomposed into multiple PRs where each could be merged or reverted independently? If yes, list them.即分析这个 diff。它能否被拆分成多个可独立合入或独立回退的 PR如果可以把它们列出来。如果答案是可以拆成 N 个 PR就先把 diff 拆成 N 个再提交。这条自检流程与项目AI 优先的定位高度自洽——AI 生成的代码由 AI 做拆分审查形成生成 → 自检 → 拆分 → 提交的闭环。正反示例哪些算单 PR哪些必须拆分CONTRIBUTING.md 给出了三类清晰示例值得逐一记住✅ 单 PR 的 bug 修复一个根因一个修复Picture added with only width specified gets wrong default height只指定 width 的图片得到错误的默认高度Body-level find: anchor throws ArgumentException正文级查找anchor 抛出 ArgumentExceptionAddParagraph --index N is off-by-one when the body contains a table正文含表格时AddParagraph --index N存在 off-by-one其中第一条与仓库源码有直接对应在 src/officecli/Handlers/Word/WordHandler.Add.Media.cs#L396-L429 中AddPicture实现了只指定单轴时按图片原生像素宽高比自动推算另一轴的逻辑——hasWidth !hasHeight时cyEmu cxEmu * ratio两者都未指定时 width 默认 6 英寸5486400 EMU、height 默认 4 英寸3657600 EMU。若修复前 height 被写死为 4 英寸2:1 横幅图就会得到错误的10.2cm高度修复后按 2:1 像素比算出5.0cm。这个 bug 示例正是对源码行为的忠实概括。✅ 单 PR 的功能一个内聚能力query ole: list embedded OLE objects with ProgID and dimensionsquery ole列出嵌入的 OLE 对象及其 ProgID 与尺寸set wrap/hposition/vposition on floating pictures为浮动图片设置 wrap/hposition/vposition❌ 必须拆分把多个独立改动捆在一起Fix picture index bug add OLE detection add HTML heading numbering→ 应拆成 3 个 PR三者零共享代码Add OLE object detection add EMF→PNG conversion→ 应拆成 2 个 PR两个独立层次Add auto aspect ratio fix index off-by-one fix line spacing clipping→ 应拆成 3 个 PR三个无关根因 需要判断的边界情况默认倾向拆分Add helper function its first consumer新增辅助函数 其首个调用方→ 1 或 2 个 PR若该辅助函数有独立复用潜力就拆成 2 个Add read support add write support for the same property同一属性先加读支持再加写支持→ 1 或 2 个 PR如果你希望读支持先于写支持落地审查就拆成 2 个从源码结构看OfficeCLI 的命令实现本身是按格式与能力拆分的如src/officecli/Handlers/Word/下有WordHandler.Add.Media.cs、WordHandler.Add.Table.cs、WordHandler.Set.Revision.cs等几十个职责单一的文件这为按能力拆分 PR提供了天然的组织参照——一个 PR 通常只应触及一条职责线。Rule 2每个 PR 必须附带可验证的验证方法规则的意义仅凭 diff 无法证明修复有效。CONTRIBUTING.md 要求在 PR 描述或关联 issue中说明审查者如何确认你的变更确实生效。验证方法要具体到照着做就能看到结果而不是抽象的我已测试通过。Bug 修复 PR四种验证方式按优先级排序officecli 命令序列展示修复前broken与修复后fixed的输出对比——这是最理想的证据因为它可以直接复现Shell 或 Python 脚本能复现该 bug、且在修复后干净运行的脚本权威参考资料说明正确行为应当是什么OOXML 规范、Microsoft / ECMA 文档等截图仅当 bug 纯粹是视觉问题时才使用功能 PR最低要求一张功能实际运行时的截图Word / Excel / PowerPoint 窗口、HTML 预览或终端输出可选一条演示如何触发的命令序列官方示例命令序列形式bug 修复的理想模板CONTRIBUTING.md 给出了一个可直接照抄套用的模板主题正是只指定 width 时图片高度错误# Before my fix: officecli create test.docx officecli add test.docx /body --type picture --prop pathphoto-2x1.png --prop width10cm officecli query test.docx picture # → height: 10.2cm ❌ WRONG (hardcoded 4-inch default) # After my fix: officecli create test.docx officecli add test.docx /body --type picture --prop pathphoto-2x1.png --prop width10cm officecli query test.docx picture # → height: 5.0cm ✓ CORRECT (auto-computed from 2:1 pixel ratio)这个命令序列与仓库中真实示例脚本的写法完全一致。比如 examples/word/pictures.sh 中添加 Word 图片用的就是同款命令语法officecli create pictures.docx officecli add pictures.docx /body/p[3] --type picture \ --prop src$LOGO \ --prop width3cm --prop height3cm由此可见验证命令序列不是脱离项目的虚构产物而是 OfficeCLI 日常用法的直接浓缩。你可以在examples/目录的.sh与.py脚本对CLI 与 SDK 双胞胎中找到大量可复用的命令骨架把它们改造成修复前 vs 修复后的对比脚本即可。官方示例截图形式功能 PR 的理想模板对于功能 PRCONTRIBUTING.md 推荐的呈现方式是标题 前后对比截图 触发命令。官方示例以从样式链自动编号标题为例Heading auto-numbering from style chainBefore: 普通 Chapter One无编号 After: 1. Chapter One 带自动编号 spanHow to trigger:officecli create demo.docx officecli add demo.docx /body --type paragraph --prop styleHeading1 --prop textChapter One officecli watch demo.docx注意这里用到了officecli watch demo.docx——即 README 中介绍的本地实时预览默认http://localhost:26315每次add/set/remove后浏览器自动刷新。把功能演示与 watch 预览结合审查者可以立刻看到真实渲染效果这正是可验证的生动体现。验证方法与命令参考命令的合法用法可随时用内置帮助确认officecli help docx set paragraph、officecli help pptx set shape详见 examples/README.md 的 Getting Help 一节每个示例均提供.shCLI 脚本与.pyPython SDK 脚本两种等价实现验证方法可任选其一完整性校验所有示例脚本末尾都调用officecli validate file做 OOXML schema 校验可作为验证序列的收尾步骤不遵守规则的后果维护者的两条处理路径CONTRIBUTING.md 明确列出了维护者面对不合规 PR 的两个选项贡献者应提前知晓Option A — 拒绝并要求重新提交首选方案维护者会关闭该 PR附上本指南的链接要求你按要求拆分成规范的 PR 并附带验证方法后重新提交。贡献者权益重新提交后该 PR完全归你所有包括重新提交后获得的Merged 徽章。也就是说走正规流程不会损失任何贡献记录。Option B — 摘取有价值的部分最后手段如果 PR 中的某一部分确实有价值、值得保留维护者会对相关 commit 执行git cherry-pick直接合入main然后关闭原 PR。贡献者权益git cherry-pick保留原作者身份git log和git blame中仍显示你为这些代码的作者维护者的协调提交reconcile commit信息中会带有Co-authored-by: you your-email尾注计入你的 GitHub 贡献图contribution graph但原 PR 会显示为 Closed 而不是 Merged两条路径对比清晰规范的流程保住完整的贡献记录与 Merged 徽章走捷径则可能被 cherry-pick 摘走有价值的片段且原 PR 显示为 Closed。这套设计本质上是在用贡献记录这一开发者最看重的资产激励贡献者尤其是 AI Agent遵守原子化与可验证两条规则。小结这套规范如何塑造 AI 协作的开源实践OfficeCLI 的贡献指南篇幅不长却精准回答了 AI 原生开源项目最棘手的协作问题挑战CONTRIBUTING.md 给出的解法AI 生成的 diff 容易混杂多个无关改动Rule 1一个 PR 只含一个原子变更用能否独立合入/回退作为拆分判据并让 AI 工具自检审查者无法确认 AI 的修复是否真实生效Rule 2PR 必须附带可复现的验证方法优先级为命令序列 脚本 权威参考 截图不合规 PR 的处置与贡献者权益Option A 拒绝重提保留 Merged 徽章优先Option B cherry-pick作者与 Co-authored-by 保留但显示 Closed兜底维护成本代码风格、依赖、测试、文档统一由维护者在合入后清理贡献者专注内容正确性对于想为 OfficeCLI 贡献的开发者或 Agent最稳妥的工作流是先用officecli help确认命令与属性写法 → 在examples/目录找可复用的命令骨架 → 构造修复前/修复后对比命令序列或功能截图 → 用validate收尾 → 提交前让 AI 工具做一次 diff 拆分自检 → 一个 PR 只承载一个可独立回退的原子变更。这套方法论不仅适用于 OfficeCLI也是任何AI 生成代码为主的开源项目值得借鉴的协作范式。赞分享CLIAI 应用MCP 服务【免费下载链接】OfficeCLIOfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.项目地址https://gitcode.com/GitHub_Trending/of/OfficeCLI点击查看免费下载相关推荐OfficeCLI 贡献指南面向 AI Agent 的原子化 PR 拆分与可验证交付规范OfficeCLI 贡献指南面向 AI Agent 的原子化 PR 拆分与可验证交付规范 本篇指南以 CONTRIBUTING.md https://link人工智能AI 应用AI 技能CLIMCP 服务RTranslator完全指南Android离线实时翻译工具从安装到上手RTranslator完全指南Android离线实时翻译工具从安装到上手 RTranslator是一款完全在离线状态下运行的Android实时翻译应用。它把MCLIAI 应用MCP 服务Zod贡献指南如何为开源验证库提交PRZod贡献指南如何为开源验证库提交PR 作为开发者你是否曾遇到过数据验证的痛点是否想为开源社区贡献力量但不知从何入手本文将带你一步步了解如何为TypeS后端前端上一篇零基础玩转Wan2.1-Fun-1.3B-InP WebUI文生/图生/视频生视频全功能体验下一篇freeCodeCamp 课程文件拆解通过 “Headline with the h2 Element” 掌握 HTML 标题层级与挑战编写规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OfficeCLI 贡献指南实战解析：为 AI 原生 Office 自动化项目提交原子化、可验证的 PR
CLIAI 应用MCP 服务【免费下载链接】OfficeCLIOfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.项目地址https://gitcode.com/GitHub_Trending/of/OfficeCLI点击查看免费下载本篇技术指南以仓库根目录 CONTRIBUTING.md 为核心骨架面向希望向 OfficeCLI 贡献代码的开发者与 AI Agent系统讲解其一 PR 一原子变更与每个 PR 必须附带可验证的验证方法两条硬性规范并结合仓库源码与示例脚本说明如何写出能快速通过维护者审查、可独立合入或回退的高质量 PR。读完本文你将掌握这套面向 AI 协作时代的贡献方法论如何用一条命令判断 diff 是否需要拆分、如何为 bug 修复与功能提交构造可复现的验证证据以及提交不合规时维护者的处理路径与贡献者权益保障。为什么 OfficeCLI 需要一套给 AI 看的贡献规范OfficeCLI 是一款定位为 AI Agent 而生的 Office 套件单一二进制、无需安装 Office即可让 AI 读写与自动化 Word、Excel、PowerPoint 文档见 README.md。项目的install命令会自动把技能文件安装进 Claude Code、Cursor、Windsurf、GitHub Copilot 等各类 AI 编码工具因此这个项目的主要贡献者很大概率就是 AI Agent而不是传统意义上逐行写代码的人类开发者。这带来一个真实的问题AI 生成的 diff 往往把多个不相关的改动揉进同一个 PR比如修了一个 bug 加了一个新功能 顺手改了个样式这会让审查、合入、回退变得极其困难。CONTRIBUTING.md 正是为此设计的一套极简但强制的协作契约——全文只强调两条规则其余代码风格、依赖、测试、文档都交由维护者在合入后的清理阶段处理贡献者无需为此焦虑。两条规则如下Rule 1One PR one atomic change一个 PR 只含一个原子变更Rule 2Every PR must include a verifiable validation method每个 PR 必须附带可验证的验证方法文档还提供了中文版 CONTRIBUTING.zh.md两条规则完全一致可直接对照阅读。Rule 1一 PR 一原子变更规则的准确含义一个 PR 必须且只能包含一个无法再分解的功能或 bug 修复。判断标准不是改动行数而是是否可以进一步拆分如果一次变更可以拆成多个各自具备独立价值的片段那么每一片都应该单独提交一个 PR。这条规则的收益是结构性的每个 PR 都能独立合入、独立回退revert。当一个 PR 只对应一个根因root cause时出了问题可以直接 revert 这一个 PR 而不影响其他已合入的功能反之若一个 PR 里塞了三个无关修复revert 它就会把三个修复一起撤掉审查者也无法判断某个行为变化到底来自哪一行。提交前的自检让 AI 帮你做拆分分析CONTRIBUTING.md 建议在开 PR 之前直接向你的 AI 工具提问Analyze this diff. Can it be decomposed into multiple PRs where each could be merged or reverted independently? If yes, list them.即分析这个 diff。它能否被拆分成多个可独立合入或独立回退的 PR如果可以把它们列出来。如果答案是可以拆成 N 个 PR就先把 diff 拆成 N 个再提交。这条自检流程与项目AI 优先的定位高度自洽——AI 生成的代码由 AI 做拆分审查形成生成 → 自检 → 拆分 → 提交的闭环。正反示例哪些算单 PR哪些必须拆分CONTRIBUTING.md 给出了三类清晰示例值得逐一记住✅ 单 PR 的 bug 修复一个根因一个修复Picture added with only width specified gets wrong default height只指定 width 的图片得到错误的默认高度Body-level find: anchor throws ArgumentException正文级查找anchor 抛出 ArgumentExceptionAddParagraph --index N is off-by-one when the body contains a table正文含表格时AddParagraph --index N存在 off-by-one其中第一条与仓库源码有直接对应在 src/officecli/Handlers/Word/WordHandler.Add.Media.cs#L396-L429 中AddPicture实现了只指定单轴时按图片原生像素宽高比自动推算另一轴的逻辑——hasWidth !hasHeight时cyEmu cxEmu * ratio两者都未指定时 width 默认 6 英寸5486400 EMU、height 默认 4 英寸3657600 EMU。若修复前 height 被写死为 4 英寸2:1 横幅图就会得到错误的10.2cm高度修复后按 2:1 像素比算出5.0cm。这个 bug 示例正是对源码行为的忠实概括。✅ 单 PR 的功能一个内聚能力query ole: list embedded OLE objects with ProgID and dimensionsquery ole列出嵌入的 OLE 对象及其 ProgID 与尺寸set wrap/hposition/vposition on floating pictures为浮动图片设置 wrap/hposition/vposition❌ 必须拆分把多个独立改动捆在一起Fix picture index bug add OLE detection add HTML heading numbering→ 应拆成 3 个 PR三者零共享代码Add OLE object detection add EMF→PNG conversion→ 应拆成 2 个 PR两个独立层次Add auto aspect ratio fix index off-by-one fix line spacing clipping→ 应拆成 3 个 PR三个无关根因 需要判断的边界情况默认倾向拆分Add helper function its first consumer新增辅助函数 其首个调用方→ 1 或 2 个 PR若该辅助函数有独立复用潜力就拆成 2 个Add read support add write support for the same property同一属性先加读支持再加写支持→ 1 或 2 个 PR如果你希望读支持先于写支持落地审查就拆成 2 个从源码结构看OfficeCLI 的命令实现本身是按格式与能力拆分的如src/officecli/Handlers/Word/下有WordHandler.Add.Media.cs、WordHandler.Add.Table.cs、WordHandler.Set.Revision.cs等几十个职责单一的文件这为按能力拆分 PR提供了天然的组织参照——一个 PR 通常只应触及一条职责线。Rule 2每个 PR 必须附带可验证的验证方法规则的意义仅凭 diff 无法证明修复有效。CONTRIBUTING.md 要求在 PR 描述或关联 issue中说明审查者如何确认你的变更确实生效。验证方法要具体到照着做就能看到结果而不是抽象的我已测试通过。Bug 修复 PR四种验证方式按优先级排序officecli 命令序列展示修复前broken与修复后fixed的输出对比——这是最理想的证据因为它可以直接复现Shell 或 Python 脚本能复现该 bug、且在修复后干净运行的脚本权威参考资料说明正确行为应当是什么OOXML 规范、Microsoft / ECMA 文档等截图仅当 bug 纯粹是视觉问题时才使用功能 PR最低要求一张功能实际运行时的截图Word / Excel / PowerPoint 窗口、HTML 预览或终端输出可选一条演示如何触发的命令序列官方示例命令序列形式bug 修复的理想模板CONTRIBUTING.md 给出了一个可直接照抄套用的模板主题正是只指定 width 时图片高度错误# Before my fix: officecli create test.docx officecli add test.docx /body --type picture --prop pathphoto-2x1.png --prop width10cm officecli query test.docx picture # → height: 10.2cm ❌ WRONG (hardcoded 4-inch default) # After my fix: officecli create test.docx officecli add test.docx /body --type picture --prop pathphoto-2x1.png --prop width10cm officecli query test.docx picture # → height: 5.0cm ✓ CORRECT (auto-computed from 2:1 pixel ratio)这个命令序列与仓库中真实示例脚本的写法完全一致。比如 examples/word/pictures.sh 中添加 Word 图片用的就是同款命令语法officecli create pictures.docx officecli add pictures.docx /body/p[3] --type picture \ --prop src$LOGO \ --prop width3cm --prop height3cm由此可见验证命令序列不是脱离项目的虚构产物而是 OfficeCLI 日常用法的直接浓缩。你可以在examples/目录的.sh与.py脚本对CLI 与 SDK 双胞胎中找到大量可复用的命令骨架把它们改造成修复前 vs 修复后的对比脚本即可。官方示例截图形式功能 PR 的理想模板对于功能 PRCONTRIBUTING.md 推荐的呈现方式是标题 前后对比截图 触发命令。官方示例以从样式链自动编号标题为例Heading auto-numbering from style chainBefore: 普通 Chapter One无编号 After: 1. Chapter One 带自动编号 spanHow to trigger:officecli create demo.docx officecli add demo.docx /body --type paragraph --prop styleHeading1 --prop textChapter One officecli watch demo.docx注意这里用到了officecli watch demo.docx——即 README 中介绍的本地实时预览默认http://localhost:26315每次add/set/remove后浏览器自动刷新。把功能演示与 watch 预览结合审查者可以立刻看到真实渲染效果这正是可验证的生动体现。验证方法与命令参考命令的合法用法可随时用内置帮助确认officecli help docx set paragraph、officecli help pptx set shape详见 examples/README.md 的 Getting Help 一节每个示例均提供.shCLI 脚本与.pyPython SDK 脚本两种等价实现验证方法可任选其一完整性校验所有示例脚本末尾都调用officecli validate file做 OOXML schema 校验可作为验证序列的收尾步骤不遵守规则的后果维护者的两条处理路径CONTRIBUTING.md 明确列出了维护者面对不合规 PR 的两个选项贡献者应提前知晓Option A — 拒绝并要求重新提交首选方案维护者会关闭该 PR附上本指南的链接要求你按要求拆分成规范的 PR 并附带验证方法后重新提交。贡献者权益重新提交后该 PR完全归你所有包括重新提交后获得的Merged 徽章。也就是说走正规流程不会损失任何贡献记录。Option B — 摘取有价值的部分最后手段如果 PR 中的某一部分确实有价值、值得保留维护者会对相关 commit 执行git cherry-pick直接合入main然后关闭原 PR。贡献者权益git cherry-pick保留原作者身份git log和git blame中仍显示你为这些代码的作者维护者的协调提交reconcile commit信息中会带有Co-authored-by: you your-email尾注计入你的 GitHub 贡献图contribution graph但原 PR 会显示为 Closed 而不是 Merged两条路径对比清晰规范的流程保住完整的贡献记录与 Merged 徽章走捷径则可能被 cherry-pick 摘走有价值的片段且原 PR 显示为 Closed。这套设计本质上是在用贡献记录这一开发者最看重的资产激励贡献者尤其是 AI Agent遵守原子化与可验证两条规则。小结这套规范如何塑造 AI 协作的开源实践OfficeCLI 的贡献指南篇幅不长却精准回答了 AI 原生开源项目最棘手的协作问题挑战CONTRIBUTING.md 给出的解法AI 生成的 diff 容易混杂多个无关改动Rule 1一个 PR 只含一个原子变更用能否独立合入/回退作为拆分判据并让 AI 工具自检审查者无法确认 AI 的修复是否真实生效Rule 2PR 必须附带可复现的验证方法优先级为命令序列 脚本 权威参考 截图不合规 PR 的处置与贡献者权益Option A 拒绝重提保留 Merged 徽章优先Option B cherry-pick作者与 Co-authored-by 保留但显示 Closed兜底维护成本代码风格、依赖、测试、文档统一由维护者在合入后清理贡献者专注内容正确性对于想为 OfficeCLI 贡献的开发者或 Agent最稳妥的工作流是先用officecli help确认命令与属性写法 → 在examples/目录找可复用的命令骨架 → 构造修复前/修复后对比命令序列或功能截图 → 用validate收尾 → 提交前让 AI 工具做一次 diff 拆分自检 → 一个 PR 只承载一个可独立回退的原子变更。这套方法论不仅适用于 OfficeCLI也是任何AI 生成代码为主的开源项目值得借鉴的协作范式。赞分享CLIAI 应用MCP 服务【免费下载链接】OfficeCLIOfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.项目地址https://gitcode.com/GitHub_Trending/of/OfficeCLI点击查看免费下载相关推荐OfficeCLI 贡献指南面向 AI Agent 的原子化 PR 拆分与可验证交付规范OfficeCLI 贡献指南面向 AI Agent 的原子化 PR 拆分与可验证交付规范 本篇指南以 CONTRIBUTING.md https://link人工智能AI 应用AI 技能CLIMCP 服务RTranslator完全指南Android离线实时翻译工具从安装到上手RTranslator完全指南Android离线实时翻译工具从安装到上手 RTranslator是一款完全在离线状态下运行的Android实时翻译应用。它把MCLIAI 应用MCP 服务Zod贡献指南如何为开源验证库提交PRZod贡献指南如何为开源验证库提交PR 作为开发者你是否曾遇到过数据验证的痛点是否想为开源社区贡献力量但不知从何入手本文将带你一步步了解如何为TypeS后端前端上一篇零基础玩转Wan2.1-Fun-1.3B-InP WebUI文生/图生/视频生视频全功能体验下一篇freeCodeCamp 课程文件拆解通过 “Headline with the h2 Element” 掌握 HTML 标题层级与挑战编写规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考