diff --git a/articles/301-join-code-review.md b/articles/301-join-code-review.md
index 962bd507ad2153f5653979f6d39e0d1bee724718..de4c80e77e585eb858f77d2dcd887545e8871540 100644
--- a/articles/301-join-code-review.md
+++ b/articles/301-join-code-review.md
@@ -1 +1,82 @@
 # 参与 Review 其他社区贡献者的代码
+
+## 介绍
+OpenAnolis 分为两个维度：source tree 和 rpm tree。其中，source tree 是指在龙蜥社区进行源码级维护的软件，rpm tree 是指将软件构件成发行版中的 RPM 形态所需的代码。本文将从这两个维度提供 Review 模版。
+
+## 使用规则
+本文提供 Review 模版，前期 maintainer 可以根据自己的意见填写审核结果，[+] 代表满意，[-] 代表不满足。每条规则都有个满足程度 [must] 或 [should]，对于 must 标记的规则必须满足，should 标记的规则建议满足。
+补充：后期工具会自动填写审核结果，工具判断不出来的需要 maintainer 在进行单独判定。
+
+## Review source tree code
+[ ] [must] PR 标题清晰 <br>
+[ ] [must] PR 内容描述详细具体 <br>
+[ ] [must] 代码实际修改内容与 PR 一致 <br>
+[ ] [must] 提交者不可以自己合并代码，需要指定其他 maintainer <br>
+[ ] [must] 有至少用过一种工具进行 code 扫描 <br>
+[ ] [must] 符合 gitee 的规范检查，包括源码仓的缺陷扫描和规范扫描 <br>
+[ ] [must] 满足命名规范（接口、类、方法名称、变量名称等）<br>
+[ ] [must] 满足代码格式规范（括号、换行、空格、锁进等）<br>
+[ ] [must] 满足日志规范（合理记录必要日志，且日志存放位置合理等）<br>
+[ ] [must] 代码简洁、易懂，可读性高 <br>
+[ ] [must] 代码支持扩展（不包含 hard code、魔鬼数字等）<br>
+[ ] [must] 和入主分支时，满足可测试性，新增代码有相关测试用例 <br>
+[ ] [must] 有存在三方引入时，声明来源 <br>
+[ ] [must] 不引入 license 不明的文件或者依赖 <br>
+[ ] [should] 每次提交仅解决单个问题，不夹带和入 <br>
+[ ] [should] 应该尽可能描述清楚 PR 的修改内容和影响性 <br>
+[ ] [should] 所有分支的代码都满足可测试性 <br>
+
+## Review rpm tree code
+[ ] [must] PR 标题清晰 <br>
+[ ] [must] PR 内容描述详细具体 <br>
+[ ] [must] 代码实际修改内容与 PR 一致 <br>
+[ ] [must] 提交者不可以自己合并代码，需要指定其他 maintainer <br>
+[ ] [must] 目录结构清晰，仅包括：spec、source.tag.gz、patch、source <br>
+[ ] [must] source.tag.gz 从上游开源社区下载，md5 值和上游相同 <br>
+[ ] [must] source 和 pacth 都有明确的来源 <br>
+[ ] [must] spec 的第一行增加 anolis_release 的定义：%define anolis_release 1 <br>
+[ ] [must] name 和 package 命名匹配 <br>
+[ ] [must] epoch 用来修正版本号，但不得过度使用 <br>
+[ ] [must] version 为正式发布的 release/tag 版本，如果采用 rc 版本，则 version 需要定义为 xx~rc1 <br>
+[ ] [must] release 使用 %{anolis_release}%{?dist} <br>
+[ ] [must] license 与实际的许可证相匹配，不存在缺失或者扩大 <br>
+[ ] [must] url 真实可用，属于上游源真实地址 <br>
+[ ] [must] source0 地址支持 curl 或者 wget 方式进行直接下载 <br>
+[ ] [must] buildrequires 中声明所有的第一层构建依赖，并以 rpm 形式存在相同 OS 版本构建源里，不允许其他方式引入 <br>
+[ ] [must] requires 中声明所有的第一层运行依赖，并以 rpm 形式存在相同 OS 版本的 yum 源里，不允许其他方式引入 <br>
+[ ] [must] patch 和 souce 采用序号区分自研和开源三方 <br>
+[ ] [must] 至少在一种架构上构建成功，如果存在仅在部分架构上构建，可以使用 BuildArch（白名单）或者 ExcludeArch（黑名单）<br>
+[ ] [must] 声明 devel 或其他子包对于主包或者 libs 的依赖时，需要增加版本限制: Requires: %{name} = %{verison}-%{release} <br>
+[ ] [must] 在 %build 阶段不允许随意修改 flags，如果要修改，需要在 spec 中备注原因 <br>
+[ ] [must] 在 %build 阶段不允许随意禁用 PIE <br>
+[ ] [must] 在 %install 阶段复制文件时，需要保留文件的时间戳，比如 cp -p 或者 install -p <br>
+[ ] [must] 如果存在动态库，则必须在 %post 和 %postun 阶段调用 %ldconfig <br>
+[ ] [must] 如果存在 service 文件时，需要在 %post、%postun 和 %preun 中对服务作出对应动作（比如：%post %systemd_post xxx.service）<br>
+[ ] [must] %files 阶段文件系统布局遵循 [FHS](https://yuque.antfin-inc.com/bobac/pm1qpi/xz4m02)，个别特殊情况可以加以说明 <br>
+[ ] [must] %files 阶段正确设置文件权限：目录 0755，文件 0644 root root，除非出于安全考虑需要使用特定的用户或组 <br>
+[ ] [must] %files 里不允许有重复文件，一个文件仅能有一个归属 <br>
+[ ] [must] %files 里不允许包含具有攻击性、歧义性、宗教性、色情性、受限制使用的文件等 <br>
+[ ] [must] %doc 存放 readme、changelog、authors 等文件 <br>
+[ ] [must] %license 存放 copying、license 等许可证文件 <br>
+[ ] [must] 可以使用 %find_lang 宏来处理 locale 文件，进行自动打包相关文件。例：%find_lang %{name} <br>
+[ ] [must] 如果存在需要保存配置的 conf 文件，需要声明 %config(noreplace) xxx.conf <br>
+[ ] [must] 如果存在头文件，则需要放置在 devel 包内 <br>
+[ ] [must] 如果有动态库，则包含后缀的库文件放在主包或者 libs 包，不包含后缀的库文件要放在 devel 中 <br>
+[ ] [must] 如果有静态库，则静态库需要放置在 static 包内 <br>
+[ ] [must] 公共的目录名称不可以通过 %dir 被重复定义，比如：%{_libdir}、%{_bindir} <br>
+[ ] [must] changlog 的格式正确，包括：日期、提交者个人信息、版本信息、描述信息等 <br>
+[ ] [should] 保持一次 commit 记录，保持 PR 整洁性 <br>
+[ ] [should] 如果存在多个 license，建议给多个 license 加以注释 <br>
+[ ] [should] patch 序号连续，并保持一种规范 <br>
+[ ] [should] 每个 patch 内有详细的修改原因和原链接地址 <br>
+[ ] [should] 声明 buildrequires 和 requires 时，不要添加 %{?_isa} <br>
+[ ] [should] 使用 provides 对外提供功能时，和以前版本保持一致，以前有加版本号，则需要一直加下去，如果以前没有加版本号，则不要增加 <br>
+[ ] [should] 使用 obsoletes 时，需要增加对应版本号 <br>
+[ ] [should] 在 %prep 阶段采用 %autospec 进行自动解压并打补丁，保持 spec 简洁，如果存在与架构相关的补丁时，可以不采用 %autospec <br>
+[ ] [should] 在 %build 阶段尽量采用 %make_build 进行编译，多线程可以提高构建速度 <br>
+[ ] [should] 在 %build 和 %install 阶段使用宏变量要保持一致，比如：%{buildroot} 或者 $RPM_BUILD_ROOT <br>
+[ ] [should] %check 阶段能开则开，如果不能开启，声明不能开启的原因 <br>
+
+## 友情链接
+1. source tree 代码仓在：[source tree](https://gitee.com/anolis)。
+2. rpm tree 代码仓在：[src-anolis-os](https://gitee.com/src-anolis-os) 、[src-anolis-sig](https://gitee.com/src-anolis-sig) 和 [src-anolis-dde](https://gitee.com/src-anolis-dde)。