#鸿蒙 #HarmonyOS 7（API 26） 

我想给 Agent 钉一份「先读白皮书哪几块、API 去哪一仓查」的索引。文档站 tip 已经是 1.1.3（门户下拉，发布日期 2026/05/29），白皮书卡片却还没跟上 tip。白皮书是短文，字数以门户实开为准，别当厚手册。阅读入口走门户 tip 1.1.3 文档站的「仓颉编程语言白皮书」卡片；开发指南 / API / 工具经门户打开，或走可实开的深链 初识仓颉语言。废弃静态站不当主路径，也不拿它当手册。

更麻烦的是：标准库不在一个叫 cangjie_std 的仓里——它在 cangjie_runtime。Agent 搜错仓，会空转一整轮。

所以这篇不是迁栈故事，也不是框架安利。它是一张地图：白皮书按用途怎么读，GitCode 上公开仓各管什么。

先分清：两本都叫「白皮书」

门户和社区里至少会撞上两本：

• 仓颉编程语言白皮书——门户五维文案（高效编程、安全可靠、轻松并发、卓越性能、敏捷扩展）对应几大块，不是厚手册。地图对准这一本。不要求短文里出现「敏捷扩展」四字。

• 鸿蒙编程语言白皮书——鸿蒙多语言总览（ArkTS + 仓颉 + C/C++ + 互操作）。可一句区分，勿混写进同一条阅读路径。

我自己查资料时吃过亏：把「鸿蒙总览」当成「语言白皮书」翻，结论会对不齐编译器仓与 std API。入口以 cangjie-lang.cn/docs 卡片「仓颉编程语言白皮书」为准。

文档	是什么	本稿
仓颉编程语言白皮书	门户五维文案 + 短文几大块	主对象
鸿蒙编程语言白皮书	ArkTS + 仓颉 + C/C++ 总览	只作区分，不混读

两层版本钉：语言 tip 1.1.3，白皮书仍滞后

两层要分开钉：语法与工具链跟 tip 1.1.3；白皮书从门户卡片进，内容仍短、链仍滞后——不要把「还能打开的旧静态页」误当成最新语言版，也不要把废弃静态站当阅读入口。

钉哪一层	跟哪	依据（2026-09-12）
语言 / SDK / 开发指南 / API / 工具	tip 1.1.3	门户文档下拉；发布日期 2026/05/29。下载中心 cangjie-lang.cn/download/1.1.3。指南经门户打开；深链：初识仓颉语言
白皮书	门户 tip 1.1.3 文档站卡片	入口：cangjie-lang.cn/docs「仓颉编程语言白皮书」。短文，字数以门户实开为准；内容/链尚未对齐 tip

优点：人与 Agent 都从门户卡片 + tip 指南 host 进，少绕废弃站。缺点：白皮书仍短、仍滞后，不能当 API / Kit 手册；文档漂了要再核门户实开。

白皮书怎么读：三条路径，不搬 TOC

白皮书是短文，字数以门户实开为准，按几大块扫即可，别当厚手册或 API。我按用途压成三条可读路径。

路径	谁用	建议顺序（几大块）
A	鸿蒙仓颉应用	摘要 → 高效编程 → 安全（空安全/动态检查）→ 声明式 UI → 工具 →（可选）并发
B	游戏 / Canvas·规则	摘要 → 高效编程（ADT/值类型）→ 安全 → 测试框架 →（可选）性能
C	AI / Agent 协作	摘要 → 测试/包管理 → 安全动态检查 → 宏/DSL → 未来章（仅规划）

下面三条把顺序展开成可执行清单；表上已够扫一眼。

标白皮书三读法：应用 / 游戏·规则 / AI 协作按用途选路题

路径 A · 做鸿蒙仓颉应用

1. 开篇定位（对照门户五维文案，不搬短文用词）

2. 高效编程 + 多范式（类 / 接口 / ADT·模式匹配 / 泛型）

3. 安全可靠：空安全 + 动态检查（溢出 / 越界）——给「cjc 绿仍可能运行时炸」找语言侧锚

4. 声明式 UI 相关（若短文有这一块再读；没有就去 Kit / 工程文档）

5. 工具：测试框架 / 包管理 / IDE 插件边界

6. 需要并发再读「轻松并发 / 用户态线程」

语法细则并行看开发指南（门户「开发指南」或 cangjie_docs）；白皮书不替代 API。

路径 B · 游戏 / Canvas·规则引擎

1. 摘要

2. 高效编程（ADT / 模式匹配 / 值类型）

3. 安全与值类型

4. 测试框架——规则层要能单测

5. 性能敏感再读性能 / 运行时章

声明式 UI 章可以扫一眼；不要从白皮书期待完整游戏引擎或 Canvas API 表——那在 Kit / 工程文档。

路径 C · AI / Agent 协作写仓颉

1. 摘要：能力边界

2. 测试框架 + 包管理：可机器验收的面

3. 安全 / 动态检查：运行时检查清单

4. 宏 / DSL 相关：扩展边界

5. 「未来工作」链上的 AI Native / IDE→AI：只当规划读

优点：Agent 有「先读哪几章」的合同，少空翻。缺点：未来章在公开材料里停在规划 / 建设中，不把它列入已交付能力。

公开仓地图：先认组织

• gitcode.com/Cangjie——语言编译器 / 运行时 / 扩展库 / 工具 / 文档 / 测试

• gitcode.com/CJMP——跨平台 UI+逻辑框架，早期 / 建设中；与鸿蒙仓颉 App 主线分开写

Cangjie-SIG / Cangjie-Retired 旁支不展开。三方库走 Cangjie-TPC，下一节写。

公开代码仓地图：Cangjie 六件套 · TPC 三方库 · ArkTS 借用 · CJMP 早期另线

语言核心：六件套 + 常被问混的两处

每仓只记一句职责，方便丢进 Agent memories：

仓	职责（一句）	Agent 何时开
cangjie_compiler	编译器前端 + 改过的 LLVM 组件	语义 / CHIR / 报错是否「语言真有」
cangjie_runtime	运行时 + 标准库 std（无独立 cangjie_std 仓）	std.* / 线程 / GC / 编码
cangjie_stdx	官方扩展库（net/crypto/actors 等）	std 不够时；勿与 std 混仓
cangjie_tools	CLI：cjpm / cjfmt / LSP / cjlint…	包管理与静态检查；≠ DevEco 插件包
cangjie_docs	开发指南 / 工具指南源	语法教程、cjpm/LSP 用法
cangjie_build	从源码拼 SDK 的集成构建指导	自编译 SDK、多仓版本钉齐

常一起被问：

• cangjie_test / test_framework——语言行为金标与自动化

• llvm-project（Cangjie fork）——后端依赖；日常业务 Agent 少碰

• cangjie_deveco_plugins——DevEco 侧插件相关；与开源 cangjie_tools 分线

三方库仓：源码在 TPC，制品在中心仓

主仓六件套管语言本体。业务三方库不在那里。三条入口分开记：

入口	管什么	不管什么
Cangjie-TPC	基于仓颉的开源三方库源码组织	不等于主仓；质量与维护看各仓 README，常按 SDK 分支拆
TPC-Resource	已发布组件的分类目录（网络 / DB / 安全 / UI…）	不是安装器；从目录找库名再回组织开仓
pkg.cangjie-lang.cn（仓颉中心仓）	制品发布、展示、发现、依赖解析	与 Git 源码仓互补，不是同一入口；对接以 cjpm / SDK 配置为准

怎么找：组织页浏览库卡片，或从 TPC-Resource 分类跳到 gitcode.com/Cangjie-TPC/<repo>，或在中心仓搜制品。

示例仓	一句职责
hyperion	仓颉 TCP 通信框架（编解码 + IoFilter 链）
redis-sdk	仓颉 Redis 客户端；依赖 hyperion
httpclient4cj	HTTP 客户端（HTTP/2、连接池、响应缓存）
markdown4cj	Markdown 解析与展示
microservice	微服务框架（注册发现、RPC、负载均衡）

源码 git 依赖以各仓 README 为准。hyperion README 写过：hyperion = {git = "https://gitcode.com/Cangjie-TPC/hyperion.git", branch = "master", version = "3.0.0"}，放在 cjpm.toml 的 [dependencies] 里再 cjpm update。出处：gitcode.com/Cangjie-TPC/hyperion（2026-09-12 采证摘录）。组织页上的库数量会漂，这里不报瞬时规模，只钉入口与示例。

主仓 / TPC 不够时：ArkTS 仓只能借用，不能 cjpm 直依

先钉死一句：不能在 cjpm.toml 里直接依赖任意 ArkTS HAR / ohpm 包。HAR 写在 oh-package.json5，由 ohpm + DevEco/Hvigor 解析，不是 cjpm 的 [dependencies]。也不能把 ArkTS 源码当仓颉模块 import。

路径	做什么	去哪找
A 混编 Interop	ArkTS 工程里嵌仓颉模块，或反过来；走官方互操作宏 / 生成声明	arkcompiler_cangjie_ark_interop
B 仓颉调 ArkTS	仓颉侧起 ArkTS 运行时再加载模块，复用 ArkTS 库生态	同上互操作仓；示例库如 ohos_axios、lottieArkTS
C 只参考、用仓颉重写	对照 ArkTS 实现，在 TPC 找同类或自研纯仓颉	OH 侧索引：openharmony-tpc/tpc_resource；回 Cangjie-TPC 对同类

包清单不要写串：仓颉通用 / TPC 用 cjpm.toml + cjpm；ArkTS / OH 用 oh-package.json5 + ohpm；混编两边都有，DevEco 协调 Interop 生成物。互操作仓写明当前开放接口仅支持 standard 设备；跨语言调用有线程亲和，不能假设 clone 一个 ArkTS 仓就能 cjpm 即用。OHPM 首页可达性以实开为准，这篇不以它当唯一入口。

Agent「先开哪仓」决策表

你要查什么	先开	备注
std.* / 线程 / GC	cangjie_runtime	不够再 cangjie_stdx
语法语义 / 编译报错是否语言真有	cangjie_compiler	官方怎么测 → cangjie_test
教程与 cjpm / LSP 用法	cangjie_docs	与白皮书互补
自编译 SDK、多仓版本钉齐	cangjie_build	对照各仓发行说明
鸿蒙装插件 / 体验版	门户 + DevEco 插件线	可对照 cangjie_deveco_plugins；勿把 tools 源码当安装包
仓颉三方库（HTTP / Redis / Markdown…）	Cangjie-TPC / TPC-Resource / 中心仓	cjpm git 或制品 version；看各仓 README 分支
ArkTS 生态库（axios / lottie…）	互操作仓 + OH TPC 索引	不能 cjpm 直依 HAR；混编或参考重写

CJMP：早期如实，一句边界

CJMP/Docs、Engine、CJFrontend、OpenSDK 等构成跨平台另一条线。白皮书没有 CJMP 专章。鸿蒙仓颉 App（DevEco + ohos 能力）可以完全不经过 CJMP。任务真走跨平台框架再开这些仓。这里把它与鸿蒙仓颉 App 主线分开写——公开材料也未呈现「已统一替代」。

诚实段：地图好用，也容易踩

• 入口分流：白皮书走门户 tip 1.1.3 卡片。开发指南走门户或可实开深链 初识仓颉语言。静态站当废弃。

• 多仓版本钉：compiler / runtime / stdx / tools / docs / llvm 要对齐发行说明；只升一仓易编不过。

• std 不在独立仓：Agent 搜 cangjie_std 会空，应搜 runtime。

• DevEco 插件 ≠ 开源工具仓：体验版 / 公测 → 插件 → SDK（常见如 ~/.cangjie-sdk）是一条线；cangjie_tools / cangjie_build 是自建工具链另一条线。白皮书「IDE 插件」章不等于自动等于下载中心。

• 白皮书 ≠ Kit 手册：无完整 ArkUI/Canvas 表，无「如何过应用市场」。

• cjpm ≠ ohpm：不能把 HAR 写进 cjpm.toml；互操作仅 standard 设备口径（ark_interop README）。

• 未来章是规划：AI Native / ide2ai / dslkit 等在公开材料里停在「规划 / 建设中」，不列入已交付。

收束

我把这张地图当协作前置：人先钉「白皮书从哪张卡片进、API 开哪一仓」，再让 Agent 长跑——比空喊「去看官方文档」省一轮空转。语法与工具链跟 tip 1.1.3；白皮书从门户卡片进（短文，字数以门户实开为准）；三方库走 TPC / 中心仓，ArkTS 库走互操作或重写，不走 cjpm 直依。优点是索引短、可写进 memories；缺点是文档与仓都会漂，要以门户实开为准。能力边界写到「能读懂短白皮书、能找对仓」为止，不等于零坑，更不等于停在 cjc 就算交付。

参考链接

• 仓颉文档门户

• GitCode · Cangjie

• GitCode · Cangjie-TPC

• TPC-Resource

• 仓颉中心仓

• arkcompiler_cangjie_ark_interop

• GitCode · CJMP

• cangjie_runtime

• cangjie_compiler

• cangjie_stdx

• cangjie_tools

• cangjie_docs