简介面向鸿蒙开发者的阅读APP鸿蒙版仓库资源覆盖书源、订阅源、替换规则、本地TXT目录规则、在线朗读引擎、主题排版和添加到书架等核心功能适合需要二次开发或学习鸿蒙应用架构的开发者。资源内置Web与Content Provider两种API调用方式支持通过legado://import/{path}?src{url}格式的URL实现书源、订阅源等配置的一键导入便于快速理解鸿蒙阅读应用的扩展机制。整个压缩包共886个文件、约5.58MB以334个ets界面逻辑文件与305个svg矢量图标为主同时包含png图片、js脚本、json/json5配置、vue组件、css样式、ttf字体等类型与界面、脚本、配置模块一一对应css、vue与html文件支撑Web方式页面的展示与交互ets与ts承担鸿蒙原生逻辑整体分层清晰。目前已有229人学习下载仓库目录结构完整既可用于对照研究鸿蒙版阅读3.0的模块划分与配置规则也能为后续功能扩展和自定义书源管理提供参考。1. 人工智能与鸿蒙开发相遇阅读鸿蒙版仓库到底在解决什么问题做鸿蒙开发的同学大概都遇到过这种场景打开一个几十万行的 OpenHarmony 仓库想弄清楚某个模块是干什么的、被谁调用、改哪里会炸靠人肉翻源码要磨一两天而人工智能刚好能接住这个活。但现实是很多人把仓库源文件直接拖进对话窗口里问几分钟后 AI 就开始一本正经地编造接口最后还得自己对着oh-package.json5一行行核对。问题不在大模型不够聪明而在没有人教它“怎么读鸿蒙版仓库”从拉取官方源码、过滤第三方目录、切片控制上下文到用证据链约束它不许瞎猜每一步都有章法。这套流程适合正在做鸿蒙应用二次开发、要给开源鸿蒙 PC 版迁移评估、或者想把手头业务仓快速交底给智能体开发的工程师——看完就能照着复现。2. 给 AI 准备“干净且可索引”的鸿蒙仓库源码拉取、白名单与上下文预算想让 AI 读得懂得先让仓库处于“可读”状态。鸿蒙版仓库和普通安卓工程最大的差别是它同时混着 ArkTS 页面代码、C 底层 NAPI、.json5配置文件以及大量来自third_party的第三方组件。如果不做清洗AI 会把“开源项目里的修改版”当成“鸿蒙系统自带能力”后续分析全跑偏。所以第一步不是提问而是把仓库整理成一份干净、带版本、能控制长度的输入。2.1 先从 OpenHarmony 官方仓库拉一个稳定分支别用网上剪出来的 mini 包常见做法是直接用repo工具拉 OpenHarmony 主仓。我一般不会选择默认主干分支而是锁定一个已经发版的 Release 分支这样 AI 在回答 API 时不会把开发中的废弃接口当成当前能力。mkdir -p ~/harmony-workspace cd ~/harmony-workspace # 用 repo 工具拉取主仓 manifest-b 指定发版分支这里以 4.1 Release 为准 repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-4.1-Release repo sync -c -j8这里-c表示只同步当前分支避免把全部分支的历史都拉下来-j8是并发任务数如果磁盘写入慢可以降到-j4。如果只是读应用层代码不需要全量系统仓那直接拉applications_app_samples更便宜git clone --depth 1 -b OpenHarmony-4.1-Release \ https://gitee.com/openharmony/applications_app_samples.git--depth 1只保留最新一次提交对“阅读代码”完全够用还能省掉.git对象里的大量历史包袱。拉完以后先记录基线方便后面跟 AI 对齐版本cd applications_app_samples git log --oneline -1把这一行提交号抄进之后的所有提问提示词里。AI 只要看到“当前基线是哪次提交”在遇到仓库里已改动的接口时就会主动说“源码与标准 API 不一致”而不是默认拿自己训练数据里的老版本来回答。2.2 生成阅仓白名单过滤 third_party、prebuilts 与测试目录仓库拉下来之后我建议先跑一个白名单脚本而不是直接开始翻代码。这个脚本只做一件事把“真正需要交给 AI 理解的文件”过滤出来把外部依赖和构建产物挡在外面。#!/bin/bash REPO~/harmony-workspace/applications_app_samples find $REPO -type f \ \( -name *.ts -o -name *.ets -o -name *.c -o -name *.h \ -o -name *.json5 -o -name *.cpp \) \ | grep -vE (/third_party/|/prebuilts/|/test/|/ohos_test/|/.git/|/oh_modules/|/.hvigor/) \ /tmp/harmony-whitelist.txt wc -l /tmp/harmony-whitelist.txt-vE的作用是排除多个目录其中oh_modules是鸿蒙的依赖安装目录里面有成百上千个第三方包不排除的话 AI 会把别人写的 openharmony 扩展当成你的业务代码。test和ohos_test排除则是因为单元测试里的 mock 经常覆盖真实调用链容易带偏分析。生成白名单后再按模块进一步挑选grep -E /(Camera|Media|Audio)/src/main/ /tmp/harmony-whitelist.txt | head -n 100这样筛选出的文件才是 AI 真正需要“精读”的。剩下的事情不是把白名单全塞给模型而是先统计在这些文件里有多少候选文件数越多后续的上下文预算策略就越重要。2.3 上下文预算切片 摘要 二次检索别整包喂给模型很多 NLP 模型都有上下文窗口限制哪怕标称支持 128K tokens塞进鸿蒙仓库这种含大量import和类型定义的后端源码时有效理解长度会明显缩水。我的经验是按“模块目录”来切片而不是按文件名排序。先看模块边界find ~/harmony-workspace/applications_app_samples/Camera \ -maxdepth 3 -name oh-package.json5 -exec echo {} \;oh-package.json5相当于鸿蒙工程的依赖声明文件。找到它就知道这个模块依赖了哪些ohos系统包和业务包。然后从这个模块中挑选文件时先看代码行数再决定切片方式find ~/harmony-workspace/applications_app_samples/Camera/entry/src/main \ -type f \( -name *.ets -o -name *.ts \) -exec wc -l {} \ | sort -n | tail -n 20这个命令列出行数最大的 20 个文件。超过 300 行的文件不要整文件直接丢进提示词而是先让 AI 对文件的“头部导入区 类声明 方法列表”做一次摘要再根据摘要按需读取某个方法的局部片段。如果真要整文件读最好控制在一个输入批次里不超过 2 万个中文字符——切多了AI 的注意力一分散就会拿代码里的变量名去“脑补”不存在的实现。另一个实用的做法是把“切片”和“检索”分开先用grep -rn查到某几个文件涉及同一功能点再把这些文件的相关几段贴给 AI。不是先贴文件再让 AI 找线索那样既浪费 token又容易得到含糊答案。3. 让 AI 回答“这个文件在干什么”结构化提示词与跨模块证据链仓库整理好以后真正的难点在于提示词。很多人直接贴一段.ets文件然后问“这代码有什么问题”AI 会输出一大段模棱两可的“可能存在风险”毫无可执行性。我尝试下来的有效做法是先要求 AI 复述结构再回答具体问题涉及跨模块时先用 grep 固定证据再让 AI 基于证据归纳。这样得到的答案不仅可核对还能直接落进代码审查记录里。3.1 单文件结构与职责提示词模板先复述再答题一个能稳定复用的单文件提示词模板如下只需要把文件路径和问题填进去。你是 OpenHarmony 应用侧代码评审助手。请阅读下面这个文件的内容路径是 entry/src/main/ets/pages/Index.ets。仓库基线为 git log 中看到的最新提交。 第一步只输出文件结构按照“导入依赖 / 常量配置 / 状态变量 / 生命周期 / 业务函数 / 对外接口”六段分别列出。 第二步回答具体问题这个页面的数据流入口在哪里是从哪个事件开始触发 状态更新并写回 UI 的 约束 - 未在代码中出现的符号标注 NOT_FOUND不允许猜测。 - 不确定的逻辑分支标注 UNKNOWN并说明需要额外查看哪个文件。 - 不要编造 API 清单。 文件内容如下 file pathentry/src/main/ets/pages/Index.ets ...粘贴实际代码 /file这个模板核心价值在“第一步必须先列结构”。AI 在复述结构时会把导入依赖、状态变量、生命周期这些骨架理一遍之后再回答问题它就不容易把State装饰器的作用记错成Prop。如果跳过结构直接问数据流得到的回答往往把aboutToAppear和onPageShow混在一起。提示词里的NOT_FOUND和UNKNOWN是给模型画的红线逼着它只根据眼前代码作答而不是靠训练时的通用记忆补全。提示别在提示词里只写“请分析文件”。要让 AI 明确知道“先回答结构、后回答问题”输出才稳定。3.2 跨模块调用链追踪用 grep 建立“证据链”再交给 AI单文件分析解决的问题很有限“阅读鸿蒙版仓库”的核心是搞懂模块间的调用链。比如读相机应用样例仓库时想知道CameraManager的实例到底在哪个页面创建、在哪里释放硬搜源码会花不少时间但如果直接让 AI 猜它又会基于别的项目经验编造调用位置。所以我会先用 grep 固定搜索范围cd ~/harmony-workspace/applications_app_samples/Camera grep -rn CameraManager --include*.ets --include*.ts \ entry/src/main | head -n 30然后把这份带文件路径:行号:内容的 grep 结果原样贴在提示词里不要做任何截断。让 AI 只基于这些“证据”回答调用链以下是 Camera 模块中所有出现 “CameraManager” 符号的位置每条格式为 “文件路径:行号:代码”。请根据这些证据回答 1. 哪个文件负责创建 CameraManager 实例 2. 创建后实例被传递到哪个页面 3. 何时释放如果没有释放逻辑请直接指出代码缺失。 只依据下方证据回答问题不要引入本列表之外的内容。这样做的好处是把 AI 的能力限制在“归纳与抽象”上而不是让它去“联想”。调用链属于必须真实的结构关系靠猜会有九成概率出错。证据链里一旦出现多个文件引用同一个符号再让 AI 画一个“创建点 - 传递路径 - 释放路径”的文字描述准确性会高很多而且每个结论都能在 IDE 里按行号验证。3.3 让 AI 输出结构化结论JSON 字段固化便于回到 DevEco Studio 里核对对话式的问答不便于沉淀第二周回来看就不知道当时为什么那样改。我建议在提示词里明确要求输出固定结构的 JSON把结论变成可搜索的记录。{ module: Camera, entryPoint: pages/Index.ets, entryFunction: onCameraReady, calls: [ cameraManager.getCameraList, cameraManager.createCameraInput ], dependencies: [ ohos.multimedia.camera, ohos.abilityAccessCtrl ], risks: [ CameraInput 释放逻辑缺失切后台可能占满连接数, 回调中直接修改 State 变量未确认是否在主线程 ] }收到 JSON 后不是直接采信而是拿里面的字段回仓库核对dependencies要跟oh-package.json5比对少一个都说明 AI 漏读了依赖entryPoint要跟resources/base/profile/main_pages.json对照路径不一致说明入口猜错了risks里的线程问题和释放问题则需要用 DevEco Studio 自带的代码检查器再跑一遍。这样把 AI 当作“读代码的协作者”而不是“答案生成器”每次生成的结构化结论都进版本库旁边的.repo-qa目录一个月后就能形成团队自己的鸿蒙仓库知识库。4. 阅读鸿蒙仓库时的避坑清单5 个高频翻车场景与排查路径这个环节能帮人省下最多时间。我见过的国产 IDE 社区提问里大量问题都出在 AI 对鸿蒙仓库的误解上。下面五条是我在实际把源码喂给不同大模型后反复踩过的坑每条都按“现象 - 原因 - 解决”写给同路人。4.1 现象一AI 把 API 9 的语法当成 API 12 输出编译直接红现象让 AI 给一个鸿蒙页面代码加“权限请求”它写出了requestPermissionsFromUser但在当前仓库的 API 版本中这个接口已经改名为requestPermissions编译直接报错。原因模型训练数据里的鸿蒙 API 版本跨越太大。如果提示词里没有明确告诉它“这个仓库基于 OpenHarmony-4.1-ReleaseAPI Level 10”它就会用自己最熟悉的版本作答。解决提问前先在仓库根目录执行git log --oneline -1和grep apiVersion oh-package.json5把提交基线和 apiVersion 一起写进提示词第一行。遇到ohos.*系统包的接口差异还可以让 AI 先 grep 这类符号出现的仓库片段再给出结论。这不是 AI 弱是我们没把关键版本上下文交给它。4.2 现象二third_party 代码混入主仓AI 把“第三方组件”当成鸿蒙系统组件现象在 OpenHarmony 主仓里问“这个模块用了哪些系统能力”AI 回答里出现了libavcodec、libpng、Libxml2甚至还说“建议直接修改系统编解码器”。原因仓库中的third_party目录体积很大AI 在未过滤的情况下抓取了大量第三方库的源码把外部依赖误判成了系统模块。解决严格用白名单过滤在第 2 章 2.2 节生成的/tmp/harmony-whitelist.txt基础上执行grep -vE third_party且分析时只允许 AI 引用白名单范围内的文件。对于提示词里的dependencies字段可以要求 AI 只列出ohos、kit、hms前缀的包遇到其它前缀一律标注THIRD_PARTY。这一步能直接砍掉一半以上幻觉回答。4.3 现象三ArkTS 与 C 的 NAPI 接口断链AI 找不到注册函数现象看一个包含相机底层能力的仓库AI 能读懂.ets里调用的nativeCamera.getCameraList()但问“这个 native 方法的实现在哪里”它给出了一个不存在的.cpp路径来回几次都定位不到。原因鸿蒙应用的性能关键路径经常通过 NAPI 在 ArkTS 与 C/Rust 之间传递调用。AI 擅长的是单语言理解跨语言调用时它缺少“符号在哪份代码中注册”的证据。解决不要问“实现在哪”改问“这个符号的 NAPI 注册入口在哪个文件”。然后先在仓库里执行grep -rn getCameraList --include*.cpp --include*.h --include*.ts \ --include*.ets ~/harmony-workspace/applications_app_samples/Camera把结果直接贴给 AI让它基于注册位置反推调用链。经验是跨语言问题必须先把“注册函数所在文件”作为前提喂给模型否则它只会在 ArkTS 那侧打转。4.4 现象四仓库过大切片顺序混乱AI 用“猜测”填洞现象把某个模块的所有.ets文件按字母序切成若干段分批发给 AI问“这个模块的启动流程是什么”它给出的步骤里有几个文件根本不存在过程倒是看起来很连贯。原因切片顺序不等于代码执行顺序。AI 看到一段入口页面、一段工具类、一段回调文件它会下意识按“自己想象的业务逻辑”拼出一条链路而不是按照真实调用顺序。解决列表顺序应该按依赖方向排列。先找module.json5里的入口abilities再找main_pages.json里的页面路由再找页面里调用的 service 层。可以先用grep -rn import.*from.*service entry/src/main/ets拿到 service 层的文件清单再按“页面 - 服务 - 模型”的顺序向 AI 描述并要求 AI 每次回答时先写出“我推断的调用顺序依据是哪些文件”。4.5 现象五把私有业务仓全文发给公有模型出现许可与泄密风险现象把公司内部的鸿蒙支付模块源码直接发给线上 AI 助手几天后发现模型回答里能原样复述出手写密钥的占位符名称和内部接口名。原因很多线上 AI 服务会把用户输入用于质量改进内部代码一旦提交就等于把核心资产交给外部。解决涉及敏感代码时先做脱敏摘要再让模型分析。常见的做法是写一个脚本把仓库里的字符串常量、资源文件路径、签名哈希值替换成REDACTED再保留函数名和调用关系。技术团队也可以在自己内网部署一个开源的代码问答模型输入输出都在本地才能根本解决合规问题。我个人的底线是私有仓库只把代码结构 JSON 化后交给公有模型完整源码一律留在本地。5. 把“阅读鸿蒙版仓库”变成可复用资产一条随身可带的阅仓问答脚本到这一步你已经能把一个鸿蒙仓库拆成 AI 能理解和追问的形态。真正拉开差距的是“可复用性”每次阅仓后的碎片问答能不能沉淀成团队可视的文档能不能在下次看另一个模块时直接调用上回的结论。我的做法是给每个仓库写一个轻量的问答脚本把每次分析的过程和结果都落盘。5.1 用一次阅仓问答脚本固定你的分析流程先建一个脚本放到全局可调用的位置比如~/bin/ask-repo.sh#!/bin/bash # 用法cat entry/src/main/ets/pages/Index.ets | ask-repo.sh 这个文件的释放逻辑在哪 timestamp$(date %Y%m%d-%H%M) qa_dir$PWD/.repo-qa mkdir -p $qa_dir echo ## Question: $* $qa_dir/$timestamp.md echo $qa_dir/$timestamp.md cat - $qa_dir/$timestamp.md脚本的作用不是直接调用大模型 API而是把“这次问了什么 喂了什么文件”记录下来。后面无论用哪个人工智能工具作答都能把回答追加到同一个.md文件里。这个文件放进 Git 仓库或 GitLab 仓库后团队里每个人都能知道“哪个模块被认真读过、当时的结论是什么”。调用方式很简单当你要让 AI 分析某个文件时先跑一遍脚本再复制内容去提问cat entry/src/main/ets/pages/Index.ets | ~/bin/ask-repo.sh 分析页面生命周期与释放路径这样经过一段时间.repo-qa目录下积累的就是最贴近真实仓库的问答记录比任何离线文档都可靠因为它记录的是“当时确实存在的代码形态”。花不了几分钟坚持三个月后新人接手时先翻.repo-qa再决定要不要打扰老同学。5.2 每次阅仓后落三条结论模块职责、调用边界、待补文档不要贪心每次分析完只写三条结构化结论模块职责Camera 模块负责相机输入流与预览核心实例为 CameraManager。 调用边界页面层通过 Manager 访问系统相机服务业务层不直接调用 NAPI。 待补文档CameraInput 的释放逻辑在异常路径没有覆盖需要补充 try/finally 测试。这三条写进一个叫REPO-README-ai.md的文件放在仓库根目录。第二次再看同一个仓库时先让 AI 基于旧的REPO-README-ai.md做增量分析问“仓库修改后之前三行结论哪些仍成立哪些已过时”。这样每次迭代都站在上一次的结论上而不是把前面所有坑再踩一遍。我自己的习惯是每个星期五下午固定抽半小时打开这一周碰过最多的那个鸿蒙模块用ask-repo.sh把遗留问题重新过一遍顺便把发现的坑补进.repo-qa。半年下来这个文件夹就是团队的“鸿蒙仓库阅读手册”比任何外部培训都贴地气。希望这套方法帮你在鸿蒙开发里少走一段弯路。本文还有配套的精品资源点击获取