第 1 篇：读懂「仓颉三方库共建计划」
本系列第 1 篇。我认领了活动，却完全没搞懂它是做什么的。这篇把活动、我的任务、完整流程彻底讲清楚。
一、事情的起因
我报名了华为仓颉生态的 「三方库共建计划」，还认领了一个叫 dd-plist 的仓库。
然后我就疑惑了——这个活动到底是做什么的？我认领了要做什么？
于是我一点点把它搞明白了，记录如下。
二、这个活动到底在做什么？
一句话：
把一个用别的语言写的开源库，用「仓颉语言」重新实现一遍，然后提交上去，通过审核就能拿奖品。
拆开解释：
- 仓颉（Cangjie） 是华为推出的一门新编程语言，主要面向鸿蒙 HarmonyOS 生态。
- 新语言最大的痛点是**「轮子少」**——没有现成的库，开发者做什么都得从零造轮子。
- 所以官方发起了「共建计划」：把一批成熟的、其他语言写的库列出来，号召社区开发者用仓颉把它们移植（翻译 + 适配）出来，丰富仓颉的生态。
- 你完成一个库、通过官方验收，就能拿到对应档位的奖品（等值电子产品，注意：不是现金）。
三、几个关键的活动信息
结合官方活动说明，挑出对新手最重要的几点：
活动周期：2026 年 7 月 15 日 — 10 月 30 日（88 个库全部完成会提前截止）。
参与对象：社区开发者、高校学生、企业职员，人人可参与。
共建范围：88 个三方库的适配开发、测试、文档、发布到中心仓。
两条技术路线：
- 纯仓颉：需要同时适配两个版本 —— LTS 1.0.5 和 STS 1.1.3，并上传到「仓颉中心仓」。
- 鸿蒙仓颉：基于 DevEco Studio + 仓颉插件，面向 HarmonyOS。
奖励档位（按代码量/难度分三档）：
难度 大致代码量 名额 参考奖品（等值电子产品） 简单库 约 2000 行 58 价值 1000 元 中等库 约 5000 行 20 价值 2000 元 较难库 约 10000 行 10 价值 3600 元
四、我认领的 dd-plist 是什么？
简单说：dd-plist 是一个 Java 写的开源库，用来读写苹果的 .plist 配置文件。
（这个库具体是做什么的，会在 第 3 篇 详细讲，这里先知道它是「要被我翻译成仓颉的原材料」就行。）
我的工作区里有两个关键文件夹：
| 文件夹 | 是什么 | 状态 |
|---|---|---|
dd-plist/ | 原版 Java 库源码，28 个 .java 文件，约 9000+ 行 | 参考原材料 |
plist4cj/ | 我要产出的成果——用仓颉重写的版本 | 一开始是空的 |
所以我的核心任务就是：
把
dd-plist（Java）翻译成plist4cj（仓颉），功能保持一致。
按代码量看（约 9000~10000 行），这大概率属于**「较难库」**档位。不过原库里有个 2000 多行的 Base64.java 其实可以用仓颉标准库替代，实际工作量会小一些。
五、完整流程（我需要做的 6 步）
官方文档把流程分成 6 步，我翻译成人话：
1. 前置准备 ── 加官方交流群、注册 AtomGit 账号、装仓颉开发环境
2. 项目认领 ── 在 Issue 区提认领、在群里锁定库（我已完成 ✅）
3. 本地开发 ── 🔥 核心：把 Java 代码翻译成仓颉代码
4. 提交成果 ── Fork 仓库 + 提交 PR 到官方仓库
5. 审核验收 ── 维护者审核，按意见修改，直到通过
6. 激励发放 ── 验收通过后发奖品其中几个硬性要求必须记住：
- ✅ 要同时适配两个仓颉版本（LTS 1.0.5 和 STS 1.1.3）。
- ✅ 目录结构要规范（
src/、test/、doc/、README.md、LICENSE、CHANGELOG.md、README.OpenSource等）。 - ✅ 最后要把库发布到「仓颉中心仓」（类似 npm / maven 那样的包仓库）。
- ✅ Issue 和 PR 的标题都要带
【共建】前缀。
认领的几条规则（避免踩坑）
- 每人同一时间只能认领 1 个库，合入后才能认领下一个，最多认领 2 个。
- 认领后 5 天内要提交开发计划，10 天无进展会被自动释放。
- 认领后记得在交流群通知小助手锁定，同一个库以最早提 Issue 时间为准。
六、目录结构规范（纯仓颉，以群内最新公告为准）
提交成果时，仓库要长这样：
{package}4cj/
├── cjpm.toml # 仓颉工程配置文件（必须）
├── README.md # 说明文档
├── README.OpenSource # 上游库信息，JSON 格式（必须）
└── src/
├── example/ # 使用示例（建议有，不强制）
├── {package}/ # 功能实现目录（必须）
└── test/ # 测试用例（必须）⚠️ 注意几个易踩的点（都是群内补充公告强调的）：
test/和实现代码都放在src/里面（src/{package}、src/test），不是和src平级。README.OpenSource是 JSON 格式，登记上游库的名称、版本、协议、地址等信息，必须有。- 工程里凡涉及仓库平台品牌的地方，统一写 AtomGit，禁止出现 GitCode（翻译原库文档里的
github链接时要注意替换）。
一条最重要的验收红线：功能全量一致
共建库需要与上游库对外接口的名称、参数（名称和类型）、功能定义保持一致，并实现上游全量的功能和测试用例。若某功能仓颉暂时实现不了，推荐（不强制）用 FFI 兜底，保证与上游一致，后续可无感切换。
换句话说：不能只挑简单的功能做、也不能随意改接口名。这是审核的核心标准。
七、这一步的收获
搞懂活动后，我心里就有底了：
- 这不是什么高深的事，本质就是**「代码翻译 + 适配 + 规范提交」**。
- 我完全可以借助 AI 工具辅助翻译代码（活动本身也鼓励用 AI）。
- 最难的不是写代码，而是理解原库 + 保证功能一致 + 符合提交规范。
下一篇：搭建仓颉开发环境 —— 在 Windows 上把仓颉装起来，并验证装成功了。