本案例由开发者:胡琦提供,华为开发者空间案例中心优化并收录。
本案例将基于 AI IDE 华为云码道(CodeArts)代码智能体,直接安装并调用 typos-skill,在一个开源仓库中完成拼写问题识别、修改建议复核、差异检查、本地修复与 Pull Request 提交,帮助开发者快速完成一次开源贡献实践。
一、概述
1.1 适用对象
- 个人开发者
- 高校学生
- 企业
1.2 案例时间
本案例总时长预计45分钟。
1.3 案例流程
华为云码道(CodeArts)代码智能体:是华为云打造的智能编码产品,深度融合IDE、自主开发模式与代码大模型能力,支持项目级代码生成、代码续写、研发知识问答、单元测试用例生成等核心功能,可高效提升开发者研发效率,带来优质的智能化编码体验。
对于刚开始参与开源协作的开发者来说,直接修改核心逻辑往往门槛较高,而文档、注释、提示文案中的拼写错误,则是更适合作为切入点的贡献类型。这类问题定位清晰、修改成本低、验证路径短,既能帮助开发者快速熟悉项目结构,也能以较低风险完成一次真实的开源贡献。
但在实际操作中,如果完全依赖人工排查,不仅效率较低,还容易遗漏上下文,甚至误改变量名、项目术语或接口标识。typos-skill 则可以很好地解决这一问题。根据仓库 README,typos-skill 是一个将 typos CLI 与大模型复核结合的拼写检查 Skill,支持“先检查、再复核、最后显式应用”的安全工作流,并支持 --diff 与 --apply 两种模式。
本案例将基于 AI IDE 华为云码道(CodeArts)代码智能体,直接安装并调用 typos-skill,在一个开源仓库中完成拼写问题识别、修改建议复核、差异检查、本地修复与 Pull Request 提交,帮助开发者快速完成一次开源贡献实践。
typos-skill 的核心能力,是将拼写扫描工具的高效率与大模型的上下文理解能力结合起来。我们先使用 typos-skill 为我们想要贡献的开源项目做一次全面的“检查”,抓到拼写错误“虫子”之后可以提交 PR 。
本案例的整体流程如下:

说明:
- 完成 AI IDE 华为云码道(CodeArts)代码智能体环境准备;
- 在 CodeArts 中直接安装 typos-skill;
- 打开一个待贡献的开源项目仓库;
- 调用 typos-skill 检查仓库中的拼写问题;
- 对建议项进行人工复核并生成差异结果;
- 应用修复并提交 Pull Request。
1.4 资源总览
本案例预计花费0元。
| 资源名称 | 规格 | 单价(元) |
|---|---|---|
| 华为云码道(CodeArts)代码智能体 | IDE版 | 免费 |
二、安装配置华为云码道
二、基础环境与资源准备
2.1 华为云码道安装部署
本案例基于华为云码道代码智能体完成开发改造,案例开始前请按照以下两步操作开通并使用工具:
2.1.1 一键开通华为云码道体验版
访问此专属开通链接,免费开通华为云码道(CodeArts)代码智能体体验版,无需复杂配置:
一键开通华为云码道体验版!

2.1.2 AI IDE华为云码道安装部署
参考案例《AI IDE华为云码道(CodeArts)代码智能体安装部署》完成Windows版AI IDE华为云码道(CodeArts)代码智能体安装部署。

2.2 领取华为云MaaS平台大模型Tokens福利(任选其一)
方式一: 登录华为开发者空间,参考案例《华为开发者空间 - ModelArts Studio大模型通用代金券领取使用指导》中的“二、 开通MaaS平台大模型”章节内容领取代金券,获取到模型的API地址、模型名称和API Key。
方式二: 登录华为开发者空间,参考案例《华为云MaaS平台大模型Tokens领取使用指导》中的“二、 领取MaaS平台大模型Tokens”章节内容,领取MaaS平台DeepSeek V3系列大模型Tokens代金券,购买ModelArts Studio DeepSeek Tokens套餐包,开通模型服务,最后获取到模型的API地址、模型名称和API Key。


注意:记录API Key、API地址以及模型名称留作后面步骤使用。
2.3 准备待贡献的开源项目
在本案例中,需要准备一个待检查的开源仓库作为实践对象。建议优先选择以下类型的项目:
- README、docs 文档较丰富的项目;
- 最近仍在维护的项目;
- 有明确 PR 协作流程的项目;
- 自己较熟悉、便于快速判断术语的项目。
先将目标项目 fork 到自己的仓库并克隆到本地:
git clone
后续将使用码道在该仓库内直接调用 typos-skill 完成拼写检查与修复。
本案例用此示例
先 fork jiuwenClaw 到我的仓库


接着把项目克隆到本地
git clone https://gitcode.com/huqi/jiuwenclaw.git
当然也可使用码道自带的克隆仓库功能

根据 jiiuwenClaw 的开源贡献指引我们需要切换到 develop 分支,然后再继续或许的“抓虫”

2.4 在 CodeArts 中安装 typos-skill
打开 AI IDE 华为云码道(CodeArts)代码智能体对话窗口,直接输入如下内容:
将 https://atomgit.com/huqi/typos-skill 安装到 ~/.codeartsdoer/skills/

从仓库首页可以看到,typos-skill 是一个公开 Skill 项目,仓库中包含 scripts/、.typos.toml、skill.json和typos-skill 等文件,并以 Shell 为主要实现语言。README 说明该 Skill 的定位是“find typos and fix typos”。(GitHub)
安装成功后,我们可以再设置那确定是否启用成功。

三、使用 typos-skill 快速修复开源项目拼写错误
3.1 识别适合新手参与的开源贡献点
对于第一次参与开源的开发者,建议优先从低风险、可快速验证的问题入手,例如:
- README 中的英文拼写错误;
- docs 文档中的单词错误;
- 注释与提示文案中的拼写问题;
- 报错信息或说明文字中的常见拼写错误。
这类修改通常不会影响业务逻辑,但能够提升项目的专业度、可读性与用户体验,也更容易被维护者接受。
3.2 调用 typos-skill 检查当前仓库
在目标仓库根目录下,返回 CodeArts 对话窗口,输入如下提示词:
请使用 typos-skill 检查当前仓库中的拼写错误,优先检查 README、docs、源代码注释和提示文案,先输出建议修改项,不要直接应用修改。

一般来说,首次调用时,码道会先帮我们安装 typos-cli ,然后再运行拼写检查。
3.3 查看拼写检查结果并进行人工复核
运行拼写检查后,会得到一个 review.jsonl , 并看到结果。


在实际开源贡献中,不建议看到结果后立即批量应用修改,而应重点检查以下内容:
- 是否为项目特定术语;
- 是否为约定俗成的变量名或接口名;
- 是否为产品名称、缩写、协议名;
- 是否只适合修改文档,而不适合修改代码标识符。
这一步的核心目标,是确保最终提交的是“高质量文本修复”,而不是“无差别替换”。
以这次的结果为例,当前认为有价值的是:
Clinet → Client(第10项):文件名和文档标题都需修改,影响范围较大。
3.4 确定范围并修改
接下来让码道只改这个错误。
只需修改 **`Clinet` → `Client`(第10项)**

当前案例中可以看到 diff 区有三处修改,其实 review.jsonl 我们是不需要提交的,只需提交这次修复的拼写问题。当然为了保险起见,还是需要二次确认一下这次文件名的修改影不影响其他,比如需同步修改引用这个 ACP_Client_Config.md 的文件,好在这里是没有的。
3.5 让码道提交修改并发起 Pull Request
以当前案例为例,因只需提交修复的 typos 问题,所以只需提交最小改动:
帮我提交修改到仓库,只需提交 ACP_Client_Config.md 的改动

这里有个小插曲,可以看到 commit 信息是:
git commit -m "$(cat <<'EOF'
fix: 修正文件名拼写错误 ACP_Clinet_Config -> ACP_Client_Config
Generated with CodeArts Agent
EOF
)"
明确表示这是码道生成的,但我不希望被别人知道我是用 AI 在做开源贡献,怎么办呢?
其实很简单,输入以下提示词:
修正 commit 信息,不要有 Generated with CodeArts Agent

接着让码道帮我们提交 PR 到源仓库:
帮我 push这次 commit 并给源仓库 https://atomgit.com/openJiuwen/jiuwenclaw 提交 pr

注意: glm-5.1 模型下码道会自动去找 atomgit 的 api 文档,并调用 api 提交 pr,这里可能需要鉴权,也就是需要 atomgit 的 token,请参考 atomgit 的官方文档获取。给到 AI 时,注意 token 可能有泄露的风险,请自行设置安全策略如 token 设置成最短时效失效。
我们可以访问码道给出的链接再确认一下 PR 是否提交成功:

完成以上步骤后,一次完整的开源文本修复贡献就完成了。
四、结果验证与实践建议
4.1 如何判断这次贡献是否高质量
一次高质量的拼写修复贡献,通常应满足以下要求:
- 修改范围清晰;
- 不混入无关格式化变更;
- 不误改项目特定术语;
- 不影响业务逻辑;
- 提交说明清晰;
- PR 描述完整。
4.2 如何持续使用 typos-skill 参与开源
typos-skill 很适合以下场景:
- 为文档型项目持续修复英文拼写问题;
- 在发版前批量检查 README 与说明文档;
- 为国际化项目修正文案与提示信息;
- 在提交正式 PR 前做一次文本质量扫描。
对于希望建立开源贡献记录的开发者来说,这是一条非常适合长期实践的路径。
4.3 释放资源
本案例不涉及收费云资源,无需额外释放。
如不再使用本地测试项目,可手动删除临时克隆仓库与本地 skills。
4.4 扩展资料
typos-skill GitHub 仓库: github.com/luojiyin1987/typos-skill
typos-skill AtomGit 仓库: atomgit.com/huqi/typos-skill
AtomGit 文档: docs.atomgit.com
码道 SKill 文档:https://support.huaweicloud.com/usermanual-codeartssnap/codeartsdoer_ug_0024.html
反馈改进建议
如您在案例实操过程中遇到问题或有改进建议,可以到 论坛帖评论区反馈即可,我们会及时响应处理,谢谢!

32

被折叠的 条评论
为什么被折叠?



