企业官网建设流程全解析

我最近在好几个开发者社区看到同一条讨论：某团队在引入 Claude Code 之后，PR（Pull Request，代码合并请求）数量增加了 67%。底下评论吵成一锅粥，有人说这是 AI 编程助手提升工程效率的铁证，有人嘲讽说 PR 变多只能证明代码被拆得更碎了，还有人直接说这是把效率指标玩坏了。

先别急着站队。我在一线带过工程团队，也给不少团队搭过研发效能度量体系，看到这种数字的第一反应不是兴奋，而是想追问三个问题：这 67% 是哪些类型的 PR？它们合入之后质量怎么样？团队的实际交付周期有没有变短？答案不同，结论可能完全相反。

这篇文章就围绕这个“PR 增加 67%”的现象展开，我会先拆解这个数字到底在说什么，再给出真正值得跟踪的工程效率指标组合，最后把 Claude Code 从安装配置到省 token 的完整使用路径过一遍。如果你正在用 Claude Code、准备引入它，或者负责团队的研发效能度量，这篇应该能帮你少走不少弯路。

1. 先说结论：67% 的 PR 增量，证明的是工作方式变了，不是效率提升

1.1 PR 数量为什么会被当成效率指标

很多团队把 PR 数量当成“产出数”来统计，原因很简单：它好数。Git 平台天然记录每一个 PR，写个查询语句就能按人按月拉出来，不需要额外埋点，不需要人工填表，还能按开发者排名，做成绩效看板特别方便。

但这种“方便”掩盖了一个本质问题：PR 像代码仓库里的一个动作记录，它度量的是“变更被提交了多少次”，而不是“业务价值交付了多少”。一个 PR 可能是一份 2000 行的新功能模块，也可能是把文档里一个错别字改成正确写法。前者可能是团队一周的心血，后者可能只需要 30 秒。当 PR 数量增加 67% 时，我无法从数字本身看出这增长来自哪种类型的变更。

在软件协作语境下，PR 的标准定义是开发者完成一段代码修改后，向团队发起的“请审查并合并”请求。它包含了完整的 diff（代码差异）、提交信息、审查讨论记录和合并状态。好团队会用 PR 来做代码评审、质量把关、知识传递，所以我在讨论效率之前，必须先清楚这个数到底代表什么。

1.2 为什么说“PR 增加等于效率提升”是偷懒的推理

效率的标准定义是产出除以投入。如果把 PR 数当成产出，那 PR 数增加了，逻辑上似乎效率就提升了。但问题在于：第一，PR 数不是产出，它只是变更请求数；第二，这个等式完全忽略了投入侧，也就是花费的时间、人力、token 消耗和返工成本。

我举个生活化的例子你就明白了。一个快递站以前每天送 100 个包裹，现在把每个包裹拆成两个小包裹送，数量变成 200，配送距离和总重量没变，甚至因为要跑两趟反而更累了。这时候你说快递站效率提升了一倍，快递员第一个不同意。

工程场景里这个逻辑更隐蔽。团队用了 Claude Code 之后 PR 变多，可能的原因是：开发者把一个大需求拆成了多个小 PR，这符合最佳实践；也可能是 AI 生成的代码经常有小问题，开发者不得不反复开新 PR 修复；还可能是 AI 让改代码的成本变低了，开发者顺手做了一堆低价值重构。同样是 +67%，三种机制背后的效率含义完全不同。

更危险的是，一旦把 PR 数量写进绩效考核，团队会很快进化出“空心 PR”：改一行变量名开一个 PR，把注释当成任务交一个 PR，甚至为了凑数把一个完整功能硬切成五个互相依赖的碎片。这些 PR 对业务毫无贡献，反而增加审查负担，让整个开发节奏变慢。

所以我的结论很明确：PR 增加 67% 是一个有价值的信号，它告诉我“团队的提交行为确实发生了变化”，但它是信号，不是证据。真正的问题需要继续追问：这个增长有没有伴随更短的交付周期、更低的事故率、更少的返工？如果有，那 67% 就是效率提升的伴随现象；如果没有，它可能只是工作方式改变带来的统计口径变化。

2. 拆开看：PR 增加 67% 的典型场景复盘

2.1 引入 Claude Code 前后的工作流差异

我自己在项目里实际对比过“纯手工开发”和“用 Claude Code 辅助开发”两种工作流，差异最大的不是写代码的速度，而是时间分配结构。

纯手工开发时，一个典型需求的路径是：读需求文档、设计接口、手写代码、本地调试、修 bug、写测试、提交 PR、根据评审意见修改、合入。这个流程里，开发者的大部分精力花在“把想法变成代码”这一环，也就是从 0 到 1 的生成过程。

引入 Claude Code 之后，路径变成了：读需求文档、把需求拆成可执行的小任务、在终端里向 Claude Code 描述第一个子任务、审查它生成的代码、指出问题、让它修改、继续下一个子任务、统一跑测试、把多个子任务的成果整理成若干 PR 提交、处理评审意见。

发现没有？劳动力的重心从“写”变成了“读和审”。Claude Code 帮你把 70% 的代码骨架生成了，但你必须看懂它写的东西，确认有没有埋雷，逻辑是否符合预期。一个没经验的开发者可能会被 AI 生成的代码带着跑，最后合入一堆自己都讲不清楚的实现；一个有经验的开发者会把 AI 当成“打字速度极快的实习生”，自己负责架构设计和代码审查。

时间分配一旦发生这种变化，PR 数量的自然变化就来了。以前一个需求对应一个 PR，因为开发者一口气写完了；现在一个需求被拆成“实现主体逻辑”“补充边界处理”“添加单元测试”“更新接口文档”四五个子任务，每个子任务独立提交，PR 数自然就多了。

2.2 PR 变多的三类现实来源

我把实际使用中 PR 数量的增长来源分成三类，你可以对照自己的仓库看看属于哪一类。

第一类是需求被拆解成可验证的原子提交。这是健康的变化。AI 的上下文窗口有限，一次让它处理一个文件、一个函数比让它一口气改十个文件更可靠。拆出来的每个 PR 都有明确的改动范围和测试覆盖，审查者也更容易理解。这类 PR 增加意味着团队的工程实践在变好，是值得鼓励的。

第二类是 AI 自动补充的附属产物各自成 PR。Claude Code 在帮你完成主逻辑之外，经常会顺手补充测试用例、修改依赖配置文件、调整代码格式。如果你让它分开提交，这些附属改动就会变成独立的 PR。它们本身有价值，但对“交付功能”这件事来说属于副产品。这类 PR 增加不能说明核心业务交付变快，只能说明 AI 帮你做了不少周边工作。

第三类是返工与修正 PR。这是我最警惕的一类。配置不够熟练、提示词写不清楚、或者没有给足够上下文时，AI 生成的代码可能不符合项目规范，需要开发者开了新 PR 去修正。它们和前面两类有本质区别：前面的 PR 是“构建”，这类 PR 是“修补”。修补型 PR 越多，说明 AI 生成的初始质量越低，或者说人与工具之间的磨合成本越高。

怎么区分这三类？最简单的办法是抽查 PR 的 diff。健康 PR 的 diff 应该是有逻辑的、围绕一个目标的；噪音 PR 的 diff 则是零散的、重复修改相同文件的。另外一个判断标准是 PR 合入之后功能是否立即可用，如果合入后还需要紧接着再开 PR 才能跑起来，前面的 PR 就是没做完的碎片。

2.3 哪些 PR 增长属于假性提升

“假性提升”这个词可能不太好听，但现实中确实大量存在。我见过不少团队从“PR 效率报表”上看到了明显增长，实际交付速度却没有变化，甚至因为审查负担变重而变慢了。这种增长就属于假性提升。

假性提升的典型形态有三种。

第一种是噪音提交。一行代码、一个空格、一个注释的修改都单独开 PR，理由是“保持提交粒度小”，实际上是在训练 AI 配合自己的个人偏好，把 AI 生成的代码逐步改到符合自己的风格。这种 PR 对业务没有独立交付价值，纯粹是过程性调整。

第二种是工具链拼凑。把 AI 徒手生成的一个临时脚本、一个验证用的一次性代码也按流程走 PR。这类代码本来不需要进入主仓库，但开发者图省事，或者想用 PR 记录留个底，于是仓库里多了一堆永远不会被维护的死代码。

第三种是伪原子化。有些团队把“小而美的 PR”当成了教条，一个功能明明可以整体提交，非要用“先加接口、再写实现、再补测试、再改文档”的顺序拆成 4 个 PR，每个 PR 单独看都不能编译、不能运行。这种拆法在表面上符合工程最佳实践，实际上违背了“每个 PR 应该是可独立合入的增量”这一基本原则。

判断真假提升的标准并不复杂：看 PR 的描述和目标，看合入后系统是否保持可用，看这些 PR 是否对用户可见的功能产生了累积效果。如果一个 PR 合入后需要第二次 PR 来“救火”，那它在增长统计里只是数字，在效率账本里却是负债。

3. 真正能反映工程效率的指标组合：为什么 PR 不该背锅

3.1 从产出数量转向时间与质量

如果你是真的想度量工程效率，而不是做一个漂亮的汇报 PPT，那我建议你放弃对 PR 数量的执念，转向下面三个指标。

第一个是变更周期（Cycle Time）。它指的是从代码提交到合并上线的总时长，一般取中位数，单位为小时或天。这个指标直接反映“一个想法变成用户可用功能的速度”，和团队协作效率、审查效率、CI/CD 自动化程度都强相关。采集方式很简单：Git 平台的合并时间减去首次提交时间，按 PR 汇总即可。

第二个是返工率（Rework Rate）。它衡量的是合并后的代码在短期内被再次修改或回滚的比例。比如统计“合入后 7 天内同一文件又被修改的 PR 占比”，如果一个 PR 合入后频繁被后续 PR 修正，说明原始提交的质量不高，或者是需求本身不稳定。返工率高的时候，PR 数增加得越多，团队浪费越严重。

第三个是缺陷逃逸率（Defect Escape Rate）。它统计的是缺陷在哪个阶段被发现：是在开发自测、代码审查、测试环境，还是线上。如果大量缺陷都逃逸到了线上，说明前面的质量门槛都在失效。这个指标需要配合缺陷管理工具使用，但数据准确性相对可控。

这三个指标的核心逻辑是：把注意力从“做了多少”转到“多久做成”和“做得怎么样”。它们在工程经济学上的意义更接近真实效率。

3.2 个人使用 AI 时的自评框架

如果你是个人开发者，没有团队数据平台，那上面的指标就显得有点重。我自己实践下来，个人场景更适合用三个更轻量的自评信号。

第一个是评审意见平均轮次。在 GitHub 或 GitLab 上，审查者对你的 PR 提出一轮意见，你修改后再提，这叫一轮。如果引入 AI 之后，你的 PR 平均审查轮次从 2.5 轮降到了 1 轮，说明交付质量在提升。反之，如果轮次变多了，说明 AI 帮你生成的代码和团队预期的差距在拉大。

第二个是完成一个需求的墙钟时间。从接到需求到功能上线，中间有多少个小时或天。这个时间包含开发、审查、修改、部署全过程。AI 工具好不好用，最终要看这个时间有没有显著缩短。

第三个是同类任务的重复度。如果每天都花大量时间做同类型的小改动，比如调样式、补常量、改文案，这些任务交给 Claude Code 处理之后，你节省的时间是实打实的提效。但如果你的工作内容是算法设计、架构演进这类高度依赖上下文和决策的任务，AI 对你的提效幅度会小很多，这不代表工具不好，只是匹配度问题。

所以个人用 AI 提效的正确姿势是：优先把低认知密度、高重复度的任务交给 AI，把自己省下来的时间投入到审查、设计、沟通这类高价值环节。你省下的时间才是效率，AI 产出的 PR 数量不是。

3.3 指标组合要按团队成熟度调整

不同规模的团队，指标的优先级应该不一样。我给几个可落地的建议。

三五人小团队，核心关注变更周期和返工率就够了。这两个指标不需要额外工具，用 Git 平台的查询功能就能拉出来，每周花 30 分钟看一眼趋势，比搭一个花哨的指标面板有用得多。

十人以上的中大型团队，在加上评审覆盖率、CI 失败率、故障后的根因分析结果。评审覆盖率统计有多少 PR 真正经过了人工审查（而不是直接合入），它衡量质量门槛的执行力度；CI 失败率统计流水线红灯的比例，如果这个值过高，说明提交质量整体偏低，自动化测试在替团队兜底。

特别要提醒的是，不要为了指标去搭建复杂的仪表盘。我见过不少团队把 DORA 指标、SPACE 框架、线性提交图全塞进一个实时大屏，最后团队为了指标好看做了各种扭曲行为，成本远超收益。我给的建议是：先用两周到一个月的时间，用表格手动统计，看看哪些指标对你团队有解释力，再决定要不要自动化。指标是为决策服务的，不是给管理层心理按摩用的。

4. Claude Code 上手实操：从安装配置到省 token 的完整路径

4.1 安装与初始化：最常见的问题集中在这三步

我知道你看到这里可能有点着急，心想“指标的事我先消化一下，现在能不能告诉我 Claude Code 到底怎么装、怎么用”。没问题，这部分我直接给实操路径。

Claude Code 是 Anthropic 官方推出的命令行 AI 编程助手，名字里的 CLI 提醒你，它不是一个图形界面软件，而是一个跑在终端里的工具。这也是很多新手第一个劝退点：看着黑框框里一串串文字输出，总觉得不如 VSCode 里的插件友好。但实际用下来你会发现，终端形态恰恰是它的优势，它可以随时接管文件读写、运行命令、处理 Git 操作，比对话框式的助手更接近“代理”的定位。

安装之前先确认 Node.js 环境，要求 18 及以上版本。在终端里执行：

node -v

如果显示版本号，说明环境没问题。接着用 npm 全局安装：

npm install -g @anthropic-ai/claude-code

安装完成后输入claude就能启动交互界面。第一次启动会要求登录账号，登录后进入项目目录，用/add-dir命令添加允许 Claude Code 读取和修改的目录。这个步骤很重要，它等于告诉工具“哪些范围你可以碰”，能从权限层面控制 AI 的越界行为。

如果你在国内网络环境下执行 npm 安装遇到超时，可以把 npm 源切换到国内镜像：

npm config set registry https://registry.npmmirror.com

Windows 用户经常碰到的一个坑是：npm install成功了，但输入claude提示“不是可识别的命令”。这通常是 npm 全局包的 bin 目录没有加入系统 PATH。解决办法是用 Node 自带的 npx 调用：

npx @anthropic-ai/claude-code

或者手动把 npm 的全局 bin 路径加进 PATH，具体路径可以用npm prefix -g查出来。不要因为这一个小报错就放弃，环境和路径问题占了安装事故的一半以上。

4.2 换模型、接 DeepSeek、本地模型：省钱和隐私的完整方案

默认情况下 Claude Code 调用 Anthropic 的官方 API，按 token 计费。如果你觉得费用压力大，或者希望在网络环境上更可控，社区里最常用的一招是更换 API 端点，让它走国内可直连的兼容服务，比如 DeepSeek 等厂商提供的 Anthropic 兼容接口。

原理很简单：Claude Code 支持通过环境变量指定 API 的基础地址、认证令牌和模型名称。只要目标服务提供 Anthropic API 兼容层，就可以无缝切换。以 DeepSeek 为例，在 macOS 或 Linux 终端执行：

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKEN=你的API密钥 export ANTHROPIC_MODEL=deepseek-chat claude

Windows PowerShell 下对应：

$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" $env:ANTHROPIC_AUTH_TOKEN="你的API密钥" $env:ANTHROPIC_MODEL="deepseek-chat" claude

如果想永久生效，不要每次开终端都手动 export，可以把这些变量写进 shell 配置文件（比如~/.zshrc，或 Windows 的环境变量面板）。也可以使用 Claude Code 自带的配置命令：

claude config set --global env.ANTHROPIC_BASE_URL https://api.deepseek.com/anthropic claude config set --global env.ANTHROPIC_AUTH_TOKEN 你的API密钥 claude config set --global env.ANTHROPIC_MODEL deepseek-chat

关于本地模型，社区里流行的做法是 Ollama 加转换层。Ollama 本身跑在本地，能加载 Qwen、Llama 等开源模型，再用 CC Switch 这类配置切换工具，快速在不同 API 端点之间切换。这套方案的好处是数据不出机器，隐私安全，适合处理敏感代码；代价是本地模型的编码能力和 Claude 这种顶级模型差距明显，在复杂任务上经常答非所问，只建议做简单任务或纯实验用途。我个人的观点是：本地模型方案适合学习工具原理，生产环境直接依赖它，还需要再观望。

4.3 省 token 的几个实用方法：控制上下文的学问

用 Claude Code 时间一长，你会发现 token 消耗的大头不是“生成答案”，而是“反复发送上下文”。每次对话它都要把你项目里的相关文件、历史消息、工具调用结果打包发给模型，上下文越长，费用越高，响应还越慢。所以省 token 的核心不是少问问题，而是控制每次请求的载荷。

最有效的一招是给它划清工作边界。启动之后用/add-dir而不是直接给它整个仓库的访问权，只把当前任务涉及的文件目录放进来。在权限控制界面里，把自动读取的选项关掉，不要让它每次都全库搜索。这样它只能看到你允许它看的内容，误读和 token 浪费都能减少。

第二招是把任务拆小。不要上来就一句“帮我重构整个项目”，而是说“先看一下paymentService.js里getBalance函数的问题，给出修改方案”。单次任务的上下文越小，模型的表现越稳定，token 消耗也越可预测。这和我前面说的 PR 变多逻辑是一致的，微小的任务粒度对 AI 工作流更友好。

第三招是善用会话管理。/compact命令可以把当前对话的历史记录压缩成摘要，释放上下文窗口；/clear则直接清空会话重新开始。每完成一个子任务就清一次上下文，避免上一个任务的细节污染下一个任务。

第四招是给项目写一份 CLAUDE.md。这是 Claude Code 支持的项目级说明文件，写清楚项目的目录结构、代码风格、测试命令、常见约定。它会被作为固定上下文注入，越精准，模型就越不需要反复去翻代码猜你的意图，也就省掉了大量无效的探索性请求。

第五招是强调“只读模式”。如果某个任务你只是想让它帮忙分析代码，不希望它真的改文件，启动时加--dangerously-skip-permissions的相反选项，或者直接在权限设置里把“文件写入”设为拒绝。这能防止 AI 自作主张地改一堆东西，同时省下权限确认的往返开销。

4.4 常见报错与乱码问题：我在真实环境踩过的坑

安装和运行 Claude Code 的过程中，有几个问题属于“高频高发”，我单独列出来给你排雷。

输出乱码是 Windows 用户最容易碰到的。在 PowerShell 里跑 Claude Code，中文输出经常变成乱码，原因是终端编码默认不是 UTF-8。解决办法是在运行之前执行：

chcp 65001

切换到 UTF-8 代码页，然后再启动claude。如果你用的是 Windows Terminal，还可以在设置里把默认编码直接调成 UTF-8。

另一个高频问题是权限拦截。Claude Code 默认是安全优先的，它要执行 Shell 命令、写文件之前会向你请求权限，这是它负责任的表现。但如果你在无人值守的脚本场景里希望它自动执行，可以用-p参数进入非交互模式，配合沙箱环境使用。日常开发建议保持权限确认开启，别图省事直接关掉，代价是 AI 可能在仓库里乱跑命令，造成不可控的后果。

Flutter 项目里常见的failed to apply plugin 'dev.flutter.flutter-gradle-plugin'类报错，经常被误认为是 Claude Code 的问题。实际上这类报错基本是 Android SDK 路径缺失、Gradle 版本不匹配或 JDK 版本不对导致的，和你用什么 AI 工具无关。排查时先检查flutter doctor，确认整套 Flutter 环境没问题再怀疑 AI。我的经验是，AI 生成的配置代码出错率确实存在，但底层的环境问题往往被忽略了。

最后一种情况是我最近经常看到的：终端提示your limits are temporarily boosted. your weekly claude code limit is 50%。这是免费账户的周使用上限提示，意思是本周额度已经用了一半，不是错误，也不代表账号异常。如果你高频使用，考虑订阅专业版，或者通过更换 API 端点的方式绕开这个限制。关于额度问题，最直观的办法是在官网后台查看使用量，不要凭感觉猜。

5. 团队落地复盘：如何让效率提升可观察、可信任

5.1 在真实代码库中 Claude Code 的表现如何

如果前面四部分你都看进去了，接下来要回答的问题是：一个真实团队把 Claude Code 引入工程流之后，到底会发生什么。

先说结论：它在不同任务上的表现差异非常大。根据我的实际观察，Claude Code 最适合的任务排序是：跨文件重构、补单元测试、生成脚手架代码、整理和格式化代码、解释陌生的老代码。这些任务有个共同点：目标明确、边界清晰、有标准模式可以遵循，AI 很容易从训练数据中找到类似范例。

它在这些任务上能直接把开发者的时间砍半。我见过一个团队从接到 Spring Boot 项目的初始化任务，到生成完整的目录结构、配置文件、基础测试用例，全程用了不到 30 分钟，而同类任务以前要花一个下午。

但它不适合的任务也很明确：需要大量业务上下文和历史决策依据的遗留系统改造、架构级别的高风险变更、以及需求本身还在摇摆的功能开发。在这些场景里，AI 生成代码的出错率会显著上升，开发者需要投入比手工开发更多的精力和它反复对齐，结果反而更慢。

团队引入 AI 工具之后最重要的一个前置动作，就是先写好 CLAUDE.md。很多团队跳过这一步，直接把整个仓库丢给 Claude Code，结果它在无关文件里乱翻，在错误的位置修改代码，给出的建议充满“猜测感”。项目约定越清晰，AI 的行为越可控。这个前置工作看起来不起眼，却是决定工具落地成败的分水岭。

5.2 度量机制如何避免“指标污染”

现在回到我们最初的问题。你管理一个团队，老板看到“PR 增加了 67%”，跑来问你效率是不是提升了。这时候你怎么回答？

我的建议是，你按这三步走。

第一步，收集基线数据。翻出过去一个月的 PR 合并周期、返工率、线上事故数，和启动 AI 工具后的一个月做对比。注意，对比的奖赏窗口不要卡得太死，团队有学习曲线，前两周的指标往往波动很大，看月度趋势更可靠。

第二步，区分“采集”和“考核”。给管理层的汇报可以用一套数据，给团队设置目标时千万不要直接用“PR 数增长”作为 KPI。一旦考核指标定下来，团队就会想办法刷指标，这是人性。最稳妥的做法是：采集数据但不公开排名，只看趋势，不针对个人，重点观察合并周期和返工率的变化，而不是 PR 数量本身。

第三步，形成“证据组合”再下结论。只有 PR 数量增长，什么也说明不了；但如果同时看到合并周期下降、返工率下降、评审轮次减少，这三个信号组合在一起，才能构成“AI 工具提高了工程效率”的有力证据。效率提升从来不是靠单一数字证明的，而是靠一组彼此呼应的信号共同佐证的。

5.3 给管理者的简单决策公式

如果你是被团队管理者，我送你一条经验公式：在引入 AI 编程助手的前两个月，每周花 30 分钟记录三个数——完成一个中型需求的耗时、合并后一周内的返工 PR 数、线上故障数。如果它们一起下降，这个工具就值得继续投入；如果只有 PR 数升了，其他没变化，那大概率是流程在空转。

现在我们可以回答最初的问题了：PR 增加 67%，能不能证明 Claude Code 提高了工程效率？答案是，单单这一个数字，不能。但如果这个数字伴随着合并周期缩短、返工率下降、线上缺陷减少，那它就构成了效率提升的侧面印证。工具是放大器，不是魔术师。一个团队本来就有清晰的拆分逻辑、良好的测试覆盖、严格的代码审查习惯，AI 会把这种优势放大，PR 数量和交付速度都会变好；一个团队流程松散、测试缺失、交接靠口口相传，AI 只是让团队更快地制造混乱。

我个人在实际操作中的一个体会是：不要在指标上花太多功夫，要在动作上花功夫。把时间花在写清楚 CLAUDE.md、设计好每个任务的边界、培养组员审查 AI 代码的能力上，这些动作做对了，指标是水到渠成的副产品。相反，指标定得很细、监控做得很重，团队的动作却没有实质变化，那只是在用好看的报表安慰管理层。

最后分享一个小技巧。Claude Code 有一个非交互模式，可以在 CI 脚本里直接调用，自动为代码变更生成规范的 PR 描述。我把这个命令挂在 Git 的 hook 里，每次 push 前自动生成提交说明，描述里写清楚改了什么、为什么改、风险点在哪。这个不起眼的自动化，节省的团队沟通成本比那 67% 的 PR 增量实在多了。工具终究是帮人省时间，省下来的时间用在哪里，才是效率的真正答案。