企业官网建设流程全解析

简介：面向鸿蒙开发者的阅读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 path="entry/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-Release，API 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。半年下来，这个文件夹就是团队的“鸿蒙仓库阅读手册”，比任何外部培训都贴地气。希望这套方法帮你在鸿蒙开发里少走一段弯路。

本文还有配套的精品资源，点击获取