背景：在用华为云码道（CodeArts）代码智能体（GLM-5.2）开发仓颉语言项目时，常常被两个问题反复折磨——生成的 cjpm.toml 总有字段错误、一旦用到 stdx 的 HTTP/JSON 就各种编译报错。直到装上 CangjieSkills，这两个痛点被一次性解决。本文记录安装过程与实测对比。

---

一、CangjieSkills 是什么

CangjieSkills 是仓颉 SIG 维护的一套面向 AI 开发工具的 Skills 包，覆盖仓颉语言从建工程、写代码、配依赖、到编译测试的全流程。它把仓颉语言核心特性、标准库（std）、扩展标准库（stdx）、项目规范、工具链（cjpm/cjc/cjfmt/cjlint 等）的权威文档，按 AI Skill 的格式组织好，让智能体在写仓颉代码时"有据可查"。

仓库内 .agents/skills 下包含 6 个 Skill：

Skill	作用
cangjie-lang-features	仓颉语言核心特性文档（类型/控制流/泛型/宏/并发等）
cangjie-original-docs	仓颉官方原始文档（语言/标准库/stdx/工具链）
cangjie-std	标准库 std 常用功能速查
cangjie-stdx	扩展标准库 stdx 速查（HTTP/JSON/TLS/日志等）
cangjie-regulations	仓颉项目规范准则（命名/格式/测试/安全等）
cangjie-toolchains	工具链用法（cjpm/cjc/cjdb/cjfmt/cjlint/cjprof）

装上之后，智能体在生成仓颉代码时会优先检索这些 Skill，而不是凭"记忆"瞎猜——这正是后面两个收益的根因。

---

二、安装：一行命令最方便

官方 README 给出的安装命令是：

npx skills add https://gitcode.com/Cangjie-SIG/CangjieSkills.git -a opencode -y

其中 -a 选项指定目标 AI 工具（opencode / claude-code / cursor / trae 等）。如果你用的是华为云码道智能体（CodeArts），把 -a 换成 codearts-agent 即可，这是最省事的方式：

npx skills add https://gitcode.com/Cangjie-SIG/CangjieSkills.git -a codearts-agent -y

• -y 跳过确认提示，静默安装全部 6 个 Skill；
• 安装完成后，码道智能体会自动识别这些 Skill，无需额外配置；
• 前提：本机已装好仓颉通用版工具链，cjpm、cjc 全局可用。

小贴士：没有 node 环境时，也可以手动把仓库 .agents/skills 目录复制到码道智能体的 Skills 搜索路径下（全局路径或项目 .agents/skills/），效果一致。

---

三、收益一：cjpm.toml 生成不再出错

痛点回顾

装 Skill 之前，让 GLM-5.2 直接生成一个仓颉工程的 cjpm.toml，经常会出这些问题：

• output-type 漏写或写成 binary（仓颉只认 executable / static / dynamic）；
• cjc-version 与本机 cjc -v 对不上，导致编译直接报版本不匹配；
• 依赖 stdx 时，[target.xxx.bin-dependencies] 的 path-option 路径写错平台标识（例如把 x86_64-w64-mingw32 写成 x86_64-unknown-windows-gnu），链接阶段找不到库；
• [package] 与 [workspace] 互斥字段同时出现。

这些错误往往要反复编译、看报错、改 toml、再编译，来回好几轮才消停。

装上 Skill 之后

智能体在创建工程时会先检索 cangjie-toolchains 和 cangjie-regulations，直接走 cjpm init 生成骨架，再按需补字段。实测在 D:\Test\cj\fun 下创建一个可执行工程：

cjpm init --name funtest --path funtest --type=executable

生成的 cjpm.toml 字段完整、类型正确：

[package]
  cjc-version = "1.0.0"
  name = "funtest"
  description = "nothing here"
  version = "1.0.0"
  output-type = "executable"
  ...
[dependencies]

cjpm build 一次通过，再没出现因 toml 字段导致的编译失败。根因在于 Skill 把 cjpm.toml 的字段表、[package]/[workspace] 互斥规则、各平台 target 标识都写死了，智能体不再靠"印象"填字段。

---

四、收益二：stdx 的 HTTP/JSON 使用不再踩坑

痛点回顾

仓颉标准库 std 不含高层 HTTP 客户端和 JSON 解析，这两块在 stdx（扩展标准库）里：

• HTTP 客户端：stdx.net.http（ClientBuilder / HttpRequestBuilder / HttpResponse）；
• JSON：stdx.encoding.json（JsonValue / JsonArray / JsonObject）。

装 Skill 之前，码道智能体写 stdx 代码时经常犯这些错：

• 以为 HttpResponse 有 close() 就随便调，实际调用方式不对，报 no matching function for operator '()'；
• 用 == / != 比较 JsonKind 枚举，但仓颉 enum 默认没派生 Equatable，直接编译失败；
• 把 JsonArray.size 当属性用，实际是 size() 方法；
• Array<Bool>(n, item: true) 写错构造参数名（正确是 repeat: true）；
• 忘记 HTTPS 需要 TlsClientConfig，或者 TrustAll 模式导入路径不对。

一个 HTTP+JSON 的小工程，往往要来回改五六次才能编译过。

装上 Skill 之后

智能体写 stdx 代码前会检索 cangjie-stdx 的 HTTP 客户端、JSON 文档，必要时还会查 cangjie-original-docs 里的原始 API 签名。下面是一个实测工程：访问 https://gitcode.com/dashboard 并打印项目名称和地址。

工程结构：

httptest/
├── cjpm.toml              # 配置 stdx 动态库依赖
└── src/
    ├── main.cj            # 主入口
    ├── gitcode.cj         # HTTP 客户端 + JSON 解析
    └── gitcode_test.cj    # 单元测试

cjpm.toml 里 stdx 依赖路径一次写对（Windows 平台）：

[target.x86_64-w64-mingw32.bin-dependencies]
  path-option = ["D:/CangjieMagic/libs/cangjie-stdx-windows-x64-1.0.0.1/windows_x86_64_llvm/dynamic/stdx"]

HTTP 客户端 + JSON 解析核心代码（智能体生成，一次编译通过）：

package httptest

import stdx.net.http.*
import stdx.net.tls.*
import stdx.encoding.json.*
import std.collection.*
import std.io.StringReader

public func createClient(): Client {
    var tlsConfig = TlsClientConfig()
    tlsConfig.verifyMode = TrustAll
    return ClientBuilder().tlsConfig(tlsConfig).autoRedirect(true).build()
}

public func fetchUserRepos(client: Client, token: String, page: Int64): ArrayList<Project> {
    let url = "https://gitcode.com/api/v5/user/repos?per_page=100&page=${page}"
    let req = HttpRequestBuilder()
        .get()
        .url(url)
        .header("private-token", token)
        .build()
    let resp = client.send(req)
    let body = StringReader(resp.body).readToEnd()
    return parseRepos(body)
}

public func parseRepos(jsonStr: String): ArrayList<Project> {
    let result = ArrayList<Project>()
    if (jsonStr.size == 0) {
        return result
    }
    var arr: JsonArray
    try {
        let jv = JsonValue.fromStr(jsonStr)
        arr = jv.asArray()
    } catch (_) {
        return result
    }
    let n = arr.size()
    for (i in 0..n) {
        try {
            let obj = arr[i].asObject()
            let name = getStringField(obj, "name")
            let url = getStringField(obj, "html_url")
            let desc = getStringField(obj, "description")
            result.add(Project(name, url, desc))
        } catch (_) {
            continue
        }
    }
    return result
}

几个关键点，都是 Skill 帮忙"踩过的坑"：

1. 不用 resp.close()：文档明确"读完 body 后无需再调 close 释放资源"，直接 StringReader(resp.body).readToEnd() 即可；
2. 不用 == 比较 JsonKind：改用 try { jv.asArray() } catch (_) 做类型转换，避开 enum 未派生 Equatable 的问题；
3. JsonArray.size() 是方法：带括号调用；
4. HTTPS 必须配 TlsClientConfig：tlsConfig.verifyMode = TrustAll（测试用）。

实测结果：

cjpm build  → cjpm build success
cjpm test   → 3/3 PASSED
cjpm run    → GET https://gitcode.com/dashboard -> HTTP 200

从写代码到跑通，一轮过。这在装 Skill 之前几乎不可想象。

---

五、一点补充：dashboard 是 SPA，项目列表要走 API

顺带提一个实战中容易踩的认知坑。https://gitcode.com/dashboard 是 Vue 单页应用，服务端返回的 HTML 只有一个 <div id="app"></div> 空壳（约 3.5KB），项目数据是前端登录后通过 AJAX 调 API 加载的。所以"用 HTTP 客户端 GET dashboard 然后解析 HTML 提项目名"这条路走不通。

正确做法是调 GitCode API v5：

GET https://gitcode.com/api/v5/user/repos
Header: private-token: <你的GitCode私有令牌>

返回 JSON 数组，每个元素含 name、html_url、description 等字段，解析后即可打印项目名称和地址。令牌在 GitCode → 设置 → 私有令牌生成。

---

六、总结

维度	装 Skill 前	装 Skill 后
cjpm.toml 生成	字段常错，反复编译改	cjpm init 骨架 + 按文档补字段，一次过
stdx HTTP/JSON	close/枚举比较/size 等坑连环踩	查文档后写法正确，编译一轮过
智能体知识来源	凭模型"记忆"瞎猜	检索权威 Skill 文档，有据可查

一句安装命令：

npx skills add https://gitcode.com/Cangjie-SIG/CangjieSkills.git -a codearts-agent -y

换来仓颉工程创建、编译、测试、stdx 高级库使用的全流程顺畅。对于用码道智能体做仓颉开发的同学，这属于"装了就回不去"的必备增强。