企业官网建设流程全解析

1. 从“open-code-review”这个名字说起：它到底想解决什么问题

第一次看到“open-code-review”这个标题，我脑子里冒出来的第一个念头是：这大概率不是一个具体的工具名，而是一类工程实践的统称。事实也确实如此。它指向的是**把代码评审这件事从“闭门造车”变成“开放协作”**的一整套方法论和工具链组合。说白了，就是让代码评审不再局限于两三个人的小圈子，而是让更多相关方——包括测试、产品、运维甚至安全同学——都能在一个透明、可追溯、低门槛的流程里参与进来。

我之所以对这个话题有感触，是因为过去几年里，我参与过不少团队的代码评审流程改造。有的团队用商业化的代码托管平台自带评审功能，有的团队自己搭了一套基于Git钩子和CI流水线的轻量方案，还有的团队干脆用聊天工具加截图来“评审”。结果呢？用聊天工具评审的那个团队，三个月后代码库里出现了至少五处因为评审意见没落地而导致的线上问题。这件事让我意识到，代码评审的核心矛盾从来不是“有没有评审”，而是“评审过程是否开放、可追溯、可度量”。

“open-code-review”这个标题里的“open”至少有三层含义。第一层是流程开放：评审不是某个人的特权，任何有权限的开发者都可以发起、参与、评论。第二层是工具开放：不绑定特定平台，可以用开源工具组合出一套适合自己的方案。第三层是文化开放：评审意见对事不对人，新人也能大胆提问，资深工程师也能坦然接受质疑。这三层缺一不可，少了任何一层，评审都会退化成形式主义。

这篇文章适合谁看？如果你是一个中小型研发团队的Tech Lead，正在为代码质量发愁；或者你是一个刚接触代码评审的新人，想知道一套完整的评审流程长什么样；又或者你是一个工具链爱好者，想自己搭一套不依赖商业平台的评审系统——那这篇内容应该能给你不少可直接抄作业的细节。我会从核心需求拆解开始，一步步讲到工具选型、流程设计、实操步骤，最后分享几个我踩过的坑和对应的解法。

2. 拆解“开放代码评审”的四个核心需求层级

2.1 第一层：让评审请求“找得到人”

很多团队在推行代码评审时遇到的第一个问题不是技术问题，而是社交问题。开发者提交了一个评审请求，结果不知道该指派给谁，或者指派了但对方没看到通知，评审请求在列表里躺了三天没人理。这种情况在远程办公和跨时区协作的团队里尤其常见。

解决这个问题的关键不是“催得更勤”，而是建立明确的评审责任矩阵。我的做法是：在项目根目录放一个CODEOWNERS文件（大多数代码托管平台都支持这个机制），按目录或文件类型指定默认评审人。比如前端代码默认指派给前端组的两位资深工程师，数据库迁移脚本默认指派给DBA，安全相关的配置文件默认指派给安全负责人。这样一来，每个评审请求在创建时就会自动带上合适的评审人，不需要发起者手动去猜。

但光有CODEOWNERS还不够。我见过一个团队，CODEOWNERS里写了八个人，结果每个评审请求都同时通知八个人，大家都觉得“别人会看”，最后谁都没看。所以还需要配合轮值评审人制度：每周从每个领域组里选一个人作为“当周评审负责人”，CODEOWNERS里只写这个人的名字，每周轮换。这样责任明确，不会出现“三个和尚没水喝”的局面。

2.2 第二层：让评审意见“落得了地”

评审意见提了，代码改了，但改得对不对？有没有遗漏？这是第二个核心需求。我见过太多这样的情况：评审人在评论区写了一大段建议，开发者回复“好的，已修改”，然后评审人就点了“批准”。但实际上开发者只改了其中一半，另一半因为理解偏差或者疏忽漏掉了。

要解决这个问题，必须把评审意见结构化。我的经验是：每条评审意见都应该是一个独立的“线程”，并且带有明确的状态标记。比如用[必须修改]、[建议修改]、[仅讨论]三种前缀来区分优先级。[必须修改]的意见在开发者标记为“已解决”之前，评审请求不能合并；[建议修改]的意见可以由开发者决定是否采纳，但需要回复理由；[仅讨论]的意见不阻塞合并，只是作为知识分享。

这套标记法看起来简单，但效果非常明显。我所在的团队引入这套标记之后，评审意见的遗漏率从之前的将近三成降到了不到百分之五。原因很简单：当每条意见都有了明确的“归宿”，开发者就不会在“改还是不改”之间反复纠结，评审人也不用担心自己的意见被忽略。

2.3 第三层：让评审过程“看得见”

“看得见”有两层意思。第一层是进度可见：一个评审请求从创建到合并，中间经历了哪些状态变化，谁在什么时候做了什么操作，这些信息应该在一个地方集中展示。第二层是质量可见：这个评审请求的代码变更量有多大？涉及哪些模块？有没有配套的测试？这些信息应该帮助评审人快速判断“这个变更的风险等级”。

大多数代码托管平台自带的评审界面已经提供了基础的进度展示，但质量维度的信息往往需要自己补充。我的做法是在CI流水线里加一个“评审摘要”步骤：每次有新的提交推送到评审分支时，自动生成一份摘要，内容包括变更文件列表、新增/删除行数、测试覆盖率变化、静态扫描告警数量。这份摘要会作为评论自动贴到评审请求下面。评审人打开页面第一眼就能看到这些关键指标，而不是自己去翻文件列表。

2.4 第四层：让评审数据“用得上”

最后一个需求层级经常被忽略，但长期来看价值最大：评审数据的沉淀和利用。一个团队每个月产生几百条评审意见，这些意见里藏着大量关于代码规范、架构决策、常见错误的信息。如果只是让它们散落在各个评审请求里，那就太浪费了。

我的做法是定期（比如每两周）做一次“评审意见聚类分析”。把这段时间内出现频率最高的几类问题整理出来，更新到团队的编码规范文档里。比如发现最近很多人都在犯“数据库查询没有加索引”的错误，那就把这条写进规范，并且在CI里加一个自动检查。这样一来，评审不仅解决了当下的问题，还预防了未来的问题。

3. 工具选型：自建评审系统还是用现成平台

3.1 现成平台的优缺点对比

说到代码评审工具，大多数人第一反应是那些主流的代码托管平台自带的评审功能。这些平台的优势很明显：开箱即用，界面成熟，和代码仓库无缝集成，通知机制完善。对于大多数团队来说，直接用现成平台是最省事的选择。

但现成平台也有明显的短板。第一是定制化困难：你想在评审流程里加一个“安全扫描通过才能合并”的检查，平台可能不支持，或者需要付费升级到企业版。第二是数据主权问题：有些团队对代码数据的存放位置有严格要求，不希望放在第三方平台上。第三是成本问题：当团队规模扩大到几十人以上时，商业平台的按人头收费模式会变得相当可观。

我参与过的一个项目就遇到了这种情况：团队有四十多个开发者，用的商业平台每人每月费用不低，一年下来是一笔不小的开支。后来我们评估了自建方案，用开源工具组合出了一套评审系统，虽然初期搭建花了两周时间，但长期来看成本降低了很多，而且定制化能力大大增强。

3.2 自建方案的核心组件

如果你决定走自建路线，下面这几个组件是必不可少的。我用一个表格来对比它们的作用和常见选择：

这里重点说一下评审界面的选型。如果你不想自研，可以考虑一些开源的代码评审工具，它们通常提供代码差异高亮、行内评论、评审状态管理这些核心功能。但要注意，这些工具和你的代码托管服务之间的集成可能需要自己写适配层。我的经验是：如果团队规模在二十人以下，直接用现成平台更划算；如果超过二十人，或者有特殊的合规要求，再考虑自建。

3.3 混合方案：用现成平台做托管，用自建工具做增强

还有一种折中方案，我个人比较推荐：代码托管用现成平台，但在评审流程上叠加自建工具。具体来说，代码仓库放在现成平台上，利用平台自带的评审功能做基础的差异展示和评论。同时，通过平台的Webhook机制，把评审请求的状态变化推送到自建的服务里，由自建服务来做更复杂的检查、通知和数据分析。

这样做的好处是：你不需要重新发明轮子去写一个代码差异展示界面，但你又能在评审流程上做深度定制。比如你可以写一个自建服务，在评审请求创建时自动检查“这个变更是否修改了数据库 schema”，如果是，就自动给DBA发一条即时通讯消息，并且在评审请求上打一个“需要DBA审核”的标签。这种定制化能力是现成平台很难提供的。

4. 一套可落地的开放评审流程设计

4.1 评审请求的创建规范

评审请求的创建是整个流程的起点，这个环节的质量直接决定了后续评审的效率。我见过太多评审请求只写了一个标题“修复bug”，正文一片空白，评审人打开之后完全不知道这个变更的背景是什么、为什么要做、影响范围有多大。

我的团队强制要求评审请求必须包含以下四个部分：

• 变更背景：为什么要做这个变更？是修复线上问题、实现新功能，还是重构代码？如果是修复问题，附上问题追踪链接。
• 变更内容概述：用三到五句话说明这个变更做了什么，不需要逐行解释，但要让人快速理解核心逻辑。
• 测试情况：新增或修改了哪些测试？手动验证了哪些场景？有没有未覆盖的边界情况？
• 影响范围：这个变更会影响哪些模块、哪些接口、哪些用户？有没有需要同步更新的文档或配置？

这四部分看起来简单，但坚持执行下来，评审效率会有明显提升。评审人不需要再去翻代码猜意图，开发者也能在写评审请求的过程中重新审视自己的变更是否完整。

4.2 评审人的选择与轮值机制

评审人的选择有两个极端：一种是每次都找同一个人，结果这个人成了瓶颈；另一种是随机指派，结果指派人完全不熟悉相关代码，评审质量堪忧。

我的做法是按领域分组加轮值。先把代码库按业务领域或技术栈分成几个区域，每个区域指定一个三到五人的评审小组。然后每周从每个小组里轮值选出一名“当周评审人”，所有涉及该区域的评审请求都默认指派给这个人。如果当周评审人觉得某个变更超出了自己的知识范围，可以主动邀请小组内其他成员参与。

这套机制的关键在于轮值周期不能太长也不能太短。太长了（比如一个月），轮值人压力太大；太短了（比如一天），轮值人还没进入状态就换人了。一周是我试过比较合适的周期。另外，轮值人应该有一定的“豁免权”：如果当周工作特别忙，可以和其他成员换班，但需要提前在小组里说明。

4.3 评审意见的撰写与响应

评审意见的撰写是一门手艺。我见过两种极端的评审风格：一种是只写“这里不对”，不解释为什么不对、怎么改；另一种是写了一大段代码示例，要求开发者完全照搬。这两种都不好。

好的评审意见应该包含三个要素：指出问题、解释原因、给出方向。比如不要只说“这个变量名不好”，而要说“这个变量名data太泛了，建议改成userProfile，因为这里存的是用户资料，后面维护的人能一眼看懂”。如果问题比较严重，可以给出一个简短的代码片段作为参考，但要说明“这只是其中一种写法，你可以根据实际情况调整”。

开发者对评审意见的响应也有讲究。我的团队要求：每条[必须修改]的意见，开发者必须回复“已修改”并附上修改后的代码行链接，或者回复“不修改”并说明理由。评审人看到回复后，如果认可就标记为“已解决”，如果不认可就继续讨论。这个“回复-确认”的闭环非常重要，它确保了每条意见都有明确的结论。

4.4 合并前的最终检查清单

评审请求在合并之前，应该有一份检查清单来确保没有遗漏。这份清单不需要很长，但每一条都应该是“一票否决”的硬性条件。我常用的清单是这样的：

1. 所有[必须修改]的意见是否都已标记为“已解决”？
2. CI流水线是否全部通过（包括单元测试、集成测试、静态扫描）？
3. 测试覆盖率是否达到项目设定的阈值？
4. 是否有配套的文档更新（如果变更涉及接口或配置）？
5. 是否有数据库迁移脚本（如果变更涉及schema）？迁移脚本是否经过审核？
6. 是否有回滚方案（如果变更涉及线上部署）？

这份清单可以做成一个评审请求的模板，每次创建时自动带上，合并前由合并者逐条确认。看起来有点繁琐，但比起线上出问题后紧急回滚，这点繁琐完全值得。

5. 实操中容易踩的五个坑与对应解法

5.1 坑一：评审请求太大，评审人直接放弃

这是最常见的问题。一个评审请求改了三十个文件、上千行代码，评审人打开一看就头大，要么草草扫一眼就批准，要么拖到最后不了了之。我见过一个极端案例：一个评审请求改了将近五千行代码，在列表里躺了两周，最后被强制合并，结果上线后出了三个严重问题。

解法是“小步提交”。我的经验是：单个评审请求的变更行数最好控制在四百行以内，最多不超过八百行。如果一个大功能需要改很多文件，就拆成多个评审请求，按依赖关系依次提交。比如先提交数据模型变更，再提交业务逻辑，最后提交接口层。每个评审请求都聚焦在一个明确的主题上，评审人更容易集中注意力。

但“小步提交”说起来容易做起来难，因为开发者往往倾向于一次性写完所有代码再提交评审。我的做法是在团队里推行“草稿评审请求”机制：开发者开始写代码时就可以创建一个草稿状态的评审请求，每完成一个小模块就推送一次，评审人可以提前看到进展并给出早期反馈。这样等到代码写完时，大部分问题已经在过程中解决了，最终评审只需要做一次整体确认。

5.2 坑二：评审意见变成“个人风格之争”

代码评审中最容易引发争议的不是逻辑错误，而是风格问题。比如“这个函数应该用箭头函数还是普通函数”“变量名应该用驼峰还是下划线”“注释应该写在行尾还是单独一行”。这些争论一旦升级，就会变成人身攻击，严重影响团队氛围。

解法是“自动化风格检查加规范前置”。把所有能自动化的风格检查都交给工具去做：代码格式化工具、静态检查工具、提交钩子。开发者在提交代码之前，工具已经自动把风格问题修掉了，评审人就不需要再在评论里提这些。对于工具无法覆盖的风格问题，提前写进团队的编码规范文档，评审时直接引用规范条款，而不是说“我觉得这样不好”。

我所在的团队有一个原则：评审评论里不允许出现“我觉得”三个字。要么引用规范条款，要么给出具体的、可验证的理由。比如不要说“我觉得这个函数太长了”，而要说“这个函数有八十行，超过了规范里建议的五十行上限，建议拆成两个函数”。这样就把主观判断变成了客观标准，争议自然就少了。

5.3 坑三：评审人只关注代码，忽略了测试和文档

很多评审人在看评审请求时，只盯着代码差异看，忽略了测试用例是否充分、文档是否更新。结果代码逻辑没问题，但上线后发现边界情况没覆盖，或者接口文档和实际行为不一致。

解法是在评审界面上把测试和文档的变更“高亮”出来。我的做法是在CI流水线里加一个检查：如果评审请求修改了业务代码但没有修改对应的测试文件，就自动在评审请求上打一个“缺少测试”的标签，并且这个标签会阻塞合并。同样，如果修改了接口定义但没有修改API文档，也会打标签阻塞。

这个机制刚推行时，有开发者抱怨“太严格了”。但运行一段时间后，大家发现线上问题的数量明显下降，因为很多边界情况在写测试的时候就被发现了。而且文档和代码同步更新，后续维护的人也不用再去猜接口的实际行为。

5.4 坑四：评审请求被“遗忘”在列表里

评审请求创建之后，如果评审人没有及时处理，很容易被新的评审请求淹没，最后被遗忘。我见过一个评审请求在列表里躺了整整一个月，最后开发者自己都忘了这个变更的内容。

解法是“超时自动提醒加升级机制”。我的团队设置了两级提醒：评审请求创建后二十四小时内没有评审人响应，自动给评审人发一条即时通讯提醒；四十八小时内还没有响应，自动给评审人的主管发一条提醒。如果七十二小时内还没有响应，评审请求会被自动升级为“高优先级”，在团队的每日站会上专门讨论。

这套机制听起来有点“咄咄逼人”，但实际运行下来，评审人的响应速度明显提升。而且因为大家都知道有超时机制，评审人在收到请求时会尽快处理，而不是拖到最后一刻。当然，如果评审人确实因为休假或其他原因无法处理，可以提前在系统里设置“请假状态”，超时机制会自动跳过。

5.5 坑五：评审数据没有沉淀，同样的问题反复出现

最后一个坑是“评审做了很多，但经验没有积累”。同一个类型的错误，这个月张三犯了，下个月李四又犯，评审人每次都要重复解释一遍。时间长了，评审人会觉得疲惫，开发者也会觉得“怎么老针对我”。

解法是建立“评审知识库”。每次评审中出现的典型问题，由评审人整理成一条简短的“评审笔记”，包括问题描述、错误示例、正确写法、参考链接。这些笔记按类别归档，比如“数据库相关”“并发相关”“安全相关”。新加入团队的开发者可以先阅读这些笔记，避免重复犯错。同时，在CI流水线里尽可能把这些笔记里的检查项自动化，能自动拦截的就不需要人工评审再提。

我所在的团队每季度会做一次“评审笔记回顾”，把出现频率最高的前十个问题整理成一份“季度常见问题清单”，在团队内部分享。这份清单也会作为新员工培训材料的一部分。这样一来，评审不仅解决了当下的问题，还变成了团队知识积累的渠道。

6. 从零搭建一套轻量评审系统的关键步骤

6.1 环境准备与基础服务部署

如果你决定自建一套评审系统，第一步是准备好基础环境。我假设你已经有了一台可以运行服务的服务器（物理机或云主机都可以），并且有基本的Linux操作经验。下面是我常用的部署步骤，以开源工具组合为例。

首先安装代码托管服务。大多数开源代码托管工具都支持Docker部署，这是最省事的方式。你需要准备一个域名（或者用IP加端口），配置好HTTPS证书。数据库建议用PostgreSQL，因为它在处理并发写入和复杂查询时表现更稳定。安装完成后，创建一个管理员账号，并且关闭公开注册功能，只允许管理员邀请加入。

接下来部署CI流水线服务。CI服务需要和代码托管服务打通，通常是通过Webhook机制。在代码托管服务的管理后台配置一个Webhook，指向CI服务的接收地址，事件类型选择“评审请求创建”和“评审请求更新”。这样每次有新的评审请求或新的提交推送时，CI服务就会自动触发流水线。

6.2 评审流程的自动化配置

基础服务跑起来之后，下一步是配置评审流程的自动化规则。我通常会在代码仓库的根目录放三个配置文件：

• CODEOWNERS：定义不同目录的默认评审人。
• .ci-config.yml：定义CI流水线的步骤，包括代码检查、测试、构建。
• .review-rules.yml：定义评审规则，比如“修改了数据库迁移文件必须由DBA审核”“修改了安全配置必须由安全负责人审核”。

.review-rules.yml这个文件需要配合一个自建的“评审规则引擎”来使用。这个引擎可以是一个简单的脚本，在CI流水线里运行，读取评审请求的变更文件列表，和规则文件做匹配，如果命中规则就在评审请求上打标签并通知对应的人。这个脚本用Python或Node.js写都可以，核心逻辑就是“读取变更文件列表、匹配规则、调用代码托管平台的API打标签”。

6.3 通知与提醒机制的实现

通知机制是评审系统里最容易被低估的部分。我的经验是：通知要“恰到好处”，既不能太少导致评审人被遗忘，也不能太多导致大家麻木。

我的做法是分三个渠道发送通知：

• 即时通讯工具机器人：用于实时提醒，比如“你有一个新的评审请求”“你的评审请求有一条新评论”。这类通知要简短，只包含关键信息和跳转链接。
• 邮件：用于每日汇总，比如“你今天有五个评审请求待处理”“你发起的评审请求中有两个已经超过四十八小时未响应”。邮件不需要实时发送，每天固定时间发一次即可。
• 评审请求页面内的通知：用于状态变化，比如“这个评审请求已被批准”“这个评审请求需要你重新审核”。这类通知直接显示在评审请求的评论区，不需要额外推送。

即时通讯工具机器人的实现方式取决于你用的即时通讯工具。大多数主流即时通讯工具都提供了机器人接口，你只需要写一个简单的HTTP服务来接收代码托管平台的Webhook，然后调用即时通讯工具的接口发送消息即可。

6.4 数据看板与度量指标

评审系统跑起来之后，你需要一些度量指标来评估它的运行效果。我常用的指标有四个：

这些指标可以通过代码托管平台的API定期拉取数据，然后在一个简单的看板上展示。看板不需要很复杂，一个静态页面加几个图表就够了。关键是定期回顾这些指标，比如每两周在团队会议上花十分钟看一下趋势，如果发现某个指标异常，就深入分析原因并调整流程。

7. 几个让我印象深刻的评审案例复盘

7.1 一个“小改动”引发的连锁反应

有一次，一个开发者提交了一个看起来很小的评审请求：只改了一个配置文件里的一个参数值。评审人扫了一眼，觉得没什么问题就批准了。结果上线后，这个参数导致了一个下游服务的超时设置失效，进而引发了一连串的连锁反应，最后花了两个小时才恢复。

复盘的时候我们发现，问题出在评审人没有理解这个参数的影响范围。这个参数虽然在当前仓库里只是一个数字，但它会被下游服务读取并用于设置网络超时。评审人只看了当前仓库的代码，没有意识到这个参数的“外部消费者”。

从那以后，我们在评审请求模板里加了一条：“这个变更是否会影响其他服务或系统？如果是，请说明影响方式和验证情况。”同时，在CODEOWNERS里把配置文件的评审人指定为对系统间依赖关系最熟悉的架构组成员。这个改动之后，类似的“小改动大影响”的问题再也没有出现过。

7.2 一次“评审意见被忽略”的教训

还有一次，评审人在一个评审请求里提了一条[必须修改]的意见，指出某个数据库查询没有加索引，在数据量大的时候会拖慢整个页面。开发者回复“已修改”，评审人就批准了。结果上线后，那个页面确实变慢了，排查发现开发者只改了查询语句的写法，但没有加索引。

这件事让我意识到，“已修改”这三个字太模糊了。后来我们规定：对于[必须修改]的意见，开发者不能只回复“已修改”，必须附上具体的修改内容，比如“已在users表的email字段上添加了索引，迁移脚本见附件”。评审人需要确认修改内容确实解决了问题，才能标记为“已解决”。

7.3 一个“跨团队评审”的成功实践

最后一个案例是关于跨团队评审的。有一次，我们团队的一个变更需要修改一个公共库，而这个公共库被另外三个团队使用。按照常规流程，只需要我们团队的评审人批准就可以合并。但我们主动邀请了另外三个团队的负责人参与评审。

结果其中一个团队的负责人指出，这个变更会破坏他们正在使用的一个接口的向后兼容性。如果我们没有邀请他们评审，这个变更合并后，他们的服务就会出问题。这件事之后，我们建立了一个“公共库变更评审群”，任何涉及公共库的变更都必须邀请所有使用方参与评审。虽然流程变长了，但避免了跨团队的事故。

8. 关于开放代码评审的一些个人体会

写了这么多，最后分享几点我在实际操作中积累的体会，不一定对所有人都适用，但至少是我踩过坑之后总结出来的。

第一，评审流程的复杂度要和团队规模匹配。五个人的团队不需要搞一套复杂的规则引擎和看板系统，用现成平台的默认功能就够了。五十人的团队如果还用“口头通知加截图评审”，那迟早会出问题。关键是找到适合当前阶段的方案，然后随着团队成长逐步迭代。

第二，评审文化的建设比工具选型更重要。我见过工具很先进但评审流于形式的团队，也见过工具很简陋但评审质量很高的团队。区别在于团队成员是否真正认同“评审是为了提高质量，而不是为了挑毛病”。这种认同需要时间培养，也需要Tech Lead以身作则——自己提交的评审请求也要认真写描述，自己评审别人的代码时也要给出建设性的意见。

第三，不要追求“零缺陷”。评审能发现很多问题，但不可能发现所有问题。把评审当作质量保障体系中的一环，而不是唯一的一环。配套的自动化测试、静态扫描、灰度发布、监控告警，这些加起来才能构成完整的质量防线。评审的价值在于“人”的判断力，在于发现那些自动化工具发现不了的设计问题、逻辑问题和边界问题。

第四，定期回顾评审流程本身。每季度花一个小时，把团队聚在一起，讨论一下“当前的评审流程哪里好、哪里不好、怎么改进”。我保证你会发现一些意想不到的问题，比如某个评审人长期负担过重、某个类型的变更总是被遗漏、某个检查项已经过时了。流程不是一成不变的，它需要随着团队和业务的变化而调整。

如果你正在考虑引入或改进代码评审流程，我的建议是：从小处着手，先跑起来，再优化。不要一开始就追求完美的流程和工具，先让评审这件事在团队里发生，然后根据实际反馈逐步调整。评审的本质是沟通和协作，工具只是辅助。只要团队成员愿意花时间认真看别人的代码、认真写评审意见，哪怕用最简单的工具，也能取得很好的效果。