AI代码审查工具Continue：将AI检查像单元测试一样代码化

1. 项目概述什么是 Continue如果你和我一样每天都要在 GitHub 的 Pull Request 海洋里游泳那你肯定对“代码审查”这件事又爱又恨。爱的是它能帮你发现潜在问题恨的是它耗时耗力尤其是在面对海量、重复性的检查任务时——比如“有没有硬编码的密钥”、“新增的 API 有没有做输入校验”。这些检查至关重要但手动去做或者写一堆零散的脚本去自动化维护成本又很高。最近我在一个开源项目里发现了一个叫Continue的工具它提出了一种非常有意思的思路把 AI 驱动的代码检查AI Checks像单元测试一样用源代码进行管理和强制执行。简单来说你可以在项目根目录下创建一个.continue/checks/文件夹里面放一些用 Markdown 或 YAML 写的“检查描述文件”。然后Continue 会在每次 PR 提交时自动运行一个 CLI 工具调用配置好的大语言模型比如 GPT-4、Claude 等根据你的描述去审查代码变更。检查通过就是绿色勾不通过则直接给出一个建议性的代码差异Diff告诉你哪里有问题、可以怎么改。这不再是另一个孤立的 AI 代码补全插件而是一个将 AI 能力深度集成到团队开发工作流和 CI/CD 管道中的基础设施。它的核心价值在于“可版本控制”和“可强制执行”让 AI 审查从个人辅助工具变成了团队共享、可迭代、可信任的质量关卡。2. 核心设计思路与工作原理拆解2.1 核心理念AI as CodeContinue 最吸引我的地方是它的理念AI as Code。我们习惯于将基础设施Infrastructure as Code、配置Configuration as Code进行代码化管理现在它将“AI 审查逻辑”也进行了代码化。版本控制与协作所有的检查规则都以纯文本文件.md或.yml的形式存放在.continue/checks/目录下。这意味着你可以用git来管理它们的变更历史用 Pull Request 来讨论和更新检查规则团队中的任何成员都可以清晰地看到当前生效的检查项是什么、为什么这么设置。这解决了传统 AI 工具配置散落、难以同步和审计的问题。强制执行与一致性通过集成到 CI如 GitHub Actions中这些 AI 检查不再是可选项而是每次代码合并前必须通过的关卡。这确保了代码库在特定质量或安全标准上的一致性无论提交者是谁。可解释性与迭代检查失败后Continue 不仅会说“不通过”还会生成一个具体的代码 Diff 建议。这个建议本身就是对“为什么失败”的最佳解释。同时由于规则是代码你可以很容易地根据实际误报或漏报情况去调整检查的描述让 AI 的理解更精准实现规则的持续迭代优化。2.2 架构与工作流程Continue 的架构非常清晰主要由两部分组成Continue CLI (cn)这是一个开源命令行工具是执行 AI 检查的核心引擎。它负责读取项目中的检查定义文件获取当前 PR 的代码差异调用配置的 LLM API解析模型的响应并最终输出通过/失败的结果以及建议的修改。检查定义文件位于.continue/checks/目录下是用户编写的“任务说明书”。文件格式支持 YAML Frontmatter 的 Markdown结构清晰易读。其工作流程可以概括为以下几步我画了一个简单的示意图来帮助理解[开发者提交PR] - [CI 系统如 GitHub Actions触发] - [运行 cn 命令] - [CLI 读取 .continue/checks/*.md 文件] - [CLI 获取 PR Diff结合检查描述构造 LLM 提示词] - [调用 LLM API如 OpenAI, Anthropic] - [解析 LLM 响应判断通过与否] - [通过更新状态为成功] - [不通过生成建议 Diff更新状态为失败并输出详情]这个流程将一次性的、模糊的“让 AI 看看代码”变成了一个结构化的、可重复的、结果可预期的自动化检查任务。2.3 与现有工具链的对比你可能用过 GitHub Copilot 或者 Cursor它们擅长在编码时实时提供建议。你也可能用过 SonarQube 或 Semgrep 这类静态分析工具它们基于固定的规则进行模式匹配。Continue 处在两者之间一个独特的位置vs. 实时 AI 辅助工具Continue 是“异步”和“批处理”的。它不在你写代码时打扰你而是在代码提交、准备合并这个关键节点进行集中审查。它的目标是保障合并到主分支的代码质量而非辅助编写过程。vs. 传统静态分析静态分析工具规则强大但相对僵化对于需要理解代码语义、上下文和意图的复杂检查例如“这个错误处理是否用户友好”、“这个函数命名是否清晰反映了其职责”往往力不从心。Continue 利用 LLM 的自然语言理解能力可以处理这类更抽象、更基于语义的检查其规则用人类语言编写灵活度极高。简单说Continue 用 AI 填补了那些“重要但用传统自动化手段难以实现”的代码审查空白。3. 从零开始上手安装与基础配置3.1 安装 Continue CLI (cn)Continue CLI 是这一切的基础。官方提供了几种安装方式都非常简单。macOS / Linux 用户推荐使用一键安装脚本这通常是最快最省事的方式。打开你的终端执行以下命令curl -fsSL https://raw.githubusercontent.com/continuedev/continue/main/extensions/cli/scripts/install.sh | bash这个脚本会自动下载适合你系统的最新版cn可执行文件并将其放到你的系统路径下。Windows 用户在 PowerShell建议以管理员身份运行中执行irm https://raw.githubusercontent.com/continuedev/continue/main/extensions/cli/scripts/install.ps1 | iex通过 npm 安装如果你已经安装了 Node.js (版本 20 或以上)也可以使用 npm 进行全局安装npm i -g continuedev/cli安装完成后在终端输入cn --version或直接输入cn如果看到帮助信息说明安装成功。注意安装脚本可能会请求权限将二进制文件写入/usr/local/bin或类似目录。如果你在非管理员权限环境下或者更喜欢手动管理也可以从项目的 GitHub Releases 页面直接下载对应平台的二进制文件然后手动将其移动到你的 PATH 环境变量包含的目录中。3.2 初始化项目与编写第一个检查安装好 CLI 后我们不需要在全局做复杂配置。所有的配置都是基于项目的。让我们在一个现有的 Git 仓库中开始。创建检查目录 在你的项目根目录下创建.continue/checks/目录。这个点号开头的文件夹通常是隐藏的用于存放配置。mkdir -p .continue/checks编写第一个检查文件 让我们创建一个最基本的安全检查。在.continue/checks/目录下新建一个名为security-basics.md的文件。检查文件的基本结构是顶部的 YAML Frontmatter 用于元数据后面跟 Markdown 格式的检查指令。一个最简单的例子如下--- name: Security Basics Scan description: 检查本次变更中是否存在基础安全漏洞 --- 请仔细审查本次代码提交的差异Diff并检查 - 是否有任何硬编码的密码、API密钥、令牌或密钥如果有请指出并建议使用环境变量或安全的密钥管理服务。 - 新增的数据库查询是否使用了参数化查询或ORM的安全方法以防止SQL注入 - 新增的API接口是否对用户输入进行了验证或清理这就是一个完整的检查定义。name和description会在 CI 状态中显示方便识别。而---之后的内容就是发给 AI 模型的“任务指令”。本地试运行 在提交到 CI 之前我们可以先在本地模拟运行看看效果。首先你需要设置 LLM 的 API 密钥。Continue 默认支持 OpenAI也支持其他如 Anthropic 的模型。设置环境变量以 OpenAI 为例export OPENAI_API_KEY你的-sk-...密钥或者更安全的方式是使用cn的配置命令。首次运行cn时它可能会引导你进行配置。你也可以手动创建或编辑~/.continue/config.json文件来配置模型和密钥。然后在项目根目录下运行cn --local这个--local参数会让cn分析你当前 Git 工作区与最新提交之间的差异即你尚未暂存或提交的修改并应用所有.continue/checks/下的检查。它会输出每项检查的结果如果发现问题会给出建议的代码修改。3.3 核心配置详解模型与上下文要让cn正确工作关键在于配置它如何与 LLM 对话。这主要通过配置文件完成。配置文件可以放在两个位置用户全局配置~/.continue/config.json项目本地配置项目根目录/.continue/config.json项目本地配置的优先级更高。一个典型的配置示例如下{ models: [ { title: GPT-4, provider: openai, model: gpt-4-turbo-preview, apiKey: ${OPENAI_API_KEY} } ], contextProviders: [ { name: diff, params: {} }, { name: github, params: { repo: 你的用户名/你的仓库名 } } ] }models定义可用的模型。provider可以是openai,anthropic,ollama(本地模型) 等。apiKey可以直接写不安全更推荐用${ENV_VAR_NAME}的格式引用环境变量。contextProviders这是 Continue 非常强大的一个特性。它定义了在执行检查时除了 PR Diff 本身还要给模型提供哪些上下文信息。diff这是默认且必须的提供本次提交的代码差异。github提供 GitHub Issue、PR 描述、相关评论等上下文。这对于让 AI 理解本次修改的“目的”至关重要能极大提升审查的准确性。例如AI 知道这个 PR 是为了修复某个特定的 Bug它就会更关注修改是否真正解决了问题而不会对重构代码提出无关的“风格建议”。实操心得在配置githubcontext provider 时你需要在 CI 环境中提供 GitHub Token通常通过GITHUB_TOKEN环境变量自动提供或在 GitHub Actions 中通过secrets.GITHUB_TOKEN传递。确保你的 CI 工作流文件中有正确的权限设置允许读取仓库内容。4. 深入实战编写高效的 AI 检查规则编写检查规则文件本质上是“提示词工程”在代码审查领域的应用。写得好AI 就是火眼金睛写得模糊就可能产生大量误报或漏报。4.1 检查文件的结构与语法进阶除了基本的name和descriptionFrontmatter 还支持更多参数来精细控制检查行为--- name: Code Style Clarity Review description: 检查代码风格、命名清晰度和函数复杂度 model: gpt-4-turbo-preview # 可选为此检查指定特定模型覆盖全局配置 context: - diff - github # 指定此检查需要的上下文提供者 temperature: 0.1 # 可选控制模型输出的随机性审查任务建议调低如0.1-0.3以获得更确定的结果 --- ### 审查目标 请扮演资深代码审查员的角色专注于代码的可读性和可维护性。 ### 审查规则 1. **命名检查** - 变量、函数、类名是否清晰描述了其目的 - 避免使用 data, info, temp 等模糊名称。 - 布尔变量名是否以 is, has, can 等开头 2. **函数复杂度** - 新增或修改的函数是否过长建议超过50行需警惕 - 函数的圈复杂度是否过高一个函数是否做了太多事情 3. **注释与文档** - 新增的复杂逻辑是否有必要的注释解释“为什么”这么做 - 公共API函数、类的文档字符串是否更新 ### 输出要求 - 如果发现问题**必须**在回复中首先以“**问题[简短标题]**”的格式列出。 - 对于每个问题**必须**提供具体的代码行引用例如文件:行号和清晰的解释。 - 最后**必须**提供一个完整的、可直接应用的代码 Diff 建议用于修复所有已发现问题。这个例子展示了如何通过更结构化的提示词来引导模型进行更聚焦、更一致的审查。temperature参数调低可以让模型的输出更稳定减少“这次通过下次不通过”的随机性。4.2 不同场景的检查规则示例让我们看几个针对不同场景的、更具体的检查规则示例。示例一面向特定框架的检查如 React Hooks--- name: React Hooks Rules Check description: 确保 React Hooks 使用符合规则 --- 你是一个 React 专家。请检查本次代码变更中所有与 React 组件相关的部分确保 1. **规则检查**Hooks 只能在函数组件顶层或其他 Hooks 中调用不能在循环、条件或嵌套函数中调用。 2. **依赖数组**useEffect, useCallback, useMemo 的依赖数组是否完整列出了所有在回调中使用的外部变量是否有不必要的依赖导致重复渲染 3. **状态更新**对于基于前一个状态更新的情况是否使用了函数式更新例如 setCount(prev prev 1) 4. **清理副作用**useEffect 中创建的订阅、定时器等是否返回了清理函数 如果发现任何违反上述规则的情况请明确指出文件、行号和具体问题并提供修正后的代码 Diff。示例二数据库迁移或数据模型变更审查--- name: Database Migration Review description: 审查数据库迁移脚本和数据模型变更 context: - diff - github # 特别需要PR描述来理解变更背景 --- 请结合本次 PR 的描述和代码变更审查所有 .sql 迁移文件或 ORM 模型定义文件的更改 **安全性检查** - 是否有删除大量数据的 DELETE 或 DROP 语句是否提供了回滚方案或已在 PR 描述中明确说明 - 新增的列是否有合理的默认值或设置为 NULLABLE以避免在已有数据上执行失败 - 是否添加了必要的索引特别是对用于查询条件WHERE或连接JOIN的列。 **性能检查** - 新增的索引是否过多是否可能影响写性能 - 对大数据表执行的 ALTER TABLE 操作是否考虑了锁表时间和对线上服务的影响如果 PR 描述未提及请提出疑问 **一致性检查** - 模型定义如 Prisma Schema、SQLAlchemy 类的变更是否与迁移脚本同步 - 枚举类型的变更是否考虑了已有数据的兼容性 请将发现的问题分为【阻塞性问题】必须修复和【建议性问题】两类。示例三API 变更兼容性审查--- name: Public API Compatibility description: 检查对公共API的变更是否破坏向后兼容性 --- 你负责维护一个面向外部用户的 API 的向后兼容性。请检查本次变更 1. **破坏性变更识别** - 是否**删除**了任何公开的 API 端点、字段、枚举值或参数 - 是否**重命名**了任何公开的类、方法、属性或参数名 - 是否**改变**了现有 API 端点、方法的请求/响应结构或数据类型例如将字符串字段改为整数 - 是否**收紧**了输入验证例如原来可选的参数变为必填或允许的字符串长度变短 2. **如果存在破坏性变更** - 检查 PR 描述或关联的 Issue 中是否明确声明这是一次破坏性变更Breaking Change - 是否提供了迁移指南或替代方案 - 如果这是一个库版本号是否按照语义化版本SemVer规则进行了主版本号升级 请列出所有识别的潜在破坏性变更并评估其影响程度。4.3 编写技巧与注意事项具体化、场景化避免“检查代码质量”这种模糊指令。要具体如“检查函数长度是否超过50行”、“检查是否有未处理的Promise拒绝”。提供正面范例如果可能在指令中给出“好代码”的例子这比单纯说“不要怎么做”更有效。例如“错误信息应该帮助用户解决问题例如‘文件未找到请检查路径 XXX’而不是简单的‘操作失败’。”分步骤、结构化像上面的例子一样用列表、分类来组织你的审查要点这有助于模型系统性地思考。明确输出格式严格要求模型以特定格式如“问题...建议...”输出这便于 CLI 解析结果并生成报告。Continue CLI 依赖模型输出中的特定标记来识别“通过”或“失败”以及建议的 Diff。迭代与优化第一批规则上线后肯定会遇到误报False Positive和漏报False Negative。不要气馁这是正常过程。将出错的案例记录下来回头优化你的检查描述。例如如果 AI 总是误判某个特定模式你可以在指令中加入例外说明“注意在utils/legacy/目录下的old_*.js文件中的getData函数调用可以忽略这是待重构的遗留代码。”踩坑记录初期我们曾写过一个检查“确保所有错误都被妥善处理”。结果 AI 对很多仅仅打印日志的try-catch也报错认为“打印日志不是处理”。后来我们将指令修改为“检查是否有同步函数中未捕获的异常抛出或异步操作中未处理的 Promise 拒绝.catch或await在try中。对于已记录日志的错误视为已处理。” 误报率大大降低。5. 集成到 CI/CD实现自动化强制执行本地测试通过后下一步就是将其集成到团队的协作流程中通常是 GitHub Actions其他 CI 如 GitLab CI、Jenkins 原理类似。5.1 配置 GitHub Actions 工作流在你的项目.github/workflows/目录下创建一个新的 YAML 文件例如continue-checks.yml。name: Continue AI Checks on: pull_request: types: [opened, synchronize, reopened] # PR创建、新推送、重新打开时触发 push: branches: [main, master] # 也可在直接推送主分支时进行检查作为额外保障 jobs: continue-checks: runs-on: ubuntu-latest permissions: contents: read pull-requests: write # 需要此权限以发布检查状态和评论 statuses: write steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 # 获取完整历史cn可能需要 - name: Setup Node.js (if installing via npm) uses: actions/setup-nodev4 with: node-version: 20 - name: Install Continue CLI run: npm install -g continuedev/cli - name: Run Continue Checks env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # 在仓库Settings/Secrets中配置 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # 由GitHub自动提供用于读取PR信息 run: | cn --github-pr ${{ github.event.pull_request.number }} --github-repo ${{ github.repository }}这个工作流做了以下几件事在 PR 相关事件触发时运行。获取代码。通过 npm 安装cnCLI。运行cn并传递两个关键参数--github-pr: 指定要检查的 PR 编号。--github-repo: 指定仓库全名如owner/repo。通过环境变量传递必要的密钥OPENAI_API_KEY需要你在仓库的 Settings - Secrets and variables - Actions 中手动添加GITHUB_TOKEN是 GitHub 自动为工作流生成的具有访问当前仓库的权限。5.2 理解检查状态与结果工作流运行后cn会为.continue/checks/目录下的每个检查文件单独创建一个状态检查Status Check。成功绿色勾表示该检查项下未发现任何问题。失败红色叉表示 AI 根据检查规则发现了问题。点击详情你可以看到问题摘要AI 列出了它发现的所有问题点。建议的 Diff这是最实用的部分Continue 会尝试生成一个修复这些问题的代码补丁。在 GitHub 的检查详情页面这个 Diff 通常可以直接被应用或作为进一步修改的参考。分支保护规则你可以在仓库的 Settings - Branches - Branch protection rules 中为主分支如main设置保护规则要求必须通过“Continue AI Checks”中的所有状态检查才能合并 PR。这是实现“强制执行”的关键一步。5.3 高级 CI 配置与优化缓存与性能安装continuedev/cli可能会成为工作流中耗时的一步。可以考虑使用 GitHub Actions 的缓存功能来缓存 npm 全局安装目录。- name: Cache Continue CLI uses: actions/cachev3 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles(**/package-lock.json) }} restore-keys: | ${{ runner.os }}-node-选择性运行如果项目检查很多或者模型调用成本较高你可能希望只在某些情况下运行检查。可以通过路径过滤或标签过滤来实现。on: pull_request: paths: - src/** # 只当 src 目录下的文件有变更时才运行 - .continue/checks/** # 或者检查规则本身有更新时也运行使用更快的模型或本地模型对于早期、快速的检查可以使用 GPT-3.5-Turbo 等更快、更便宜的模型。对于关键、复杂的审查再用 GPT-4。这可以在项目级的.continue/config.json中为不同的检查文件指定不同的model参数来实现。对于追求零成本和隐私的团队可以配置ollamaprovider 来使用本地运行的 Llama 2、CodeLlama 等模型。处理大 Diff如果 PR 变更非常大可能会超出模型的上下文长度。Continue 的策略通常是会将大 Diff 分块处理。但在 CI 中你可能需要设置超时时间并为cn命令添加--max-tokens或--timeout参数来控制单次检查的规模。6. 常见问题排查与实战技巧在实际部署和使用 Continue 的过程中我遇到并总结了一些典型问题和解决方案。6.1 模型相关问题问题现象可能原因解决方案检查失败报错Invalid API KeyAPI 密钥未设置或错误。1. 确认环境变量名是否正确如OPENAI_API_KEY。2. 在 GitHub Actions 中确认 Secret 的名称与工作流中引用的名称完全一致。3. 尝试在本地用echo $OPENAI_API_KEY或cn --local测试密钥是否有效。检查超时或无响应PR 变更太大或模型服务响应慢。1. 在 CI 中增加 job 的超时时间timeout-minutes。2. 考虑在检查规则中通过context限制只关注核心目录如--context diff:src/或拆分检查规则每个规则关注一个特定方面减少单次提示词复杂度。3. 换用响应更快的模型。模型输出格式不符合预期导致 CLI 解析失败提示词中没有明确要求输出格式或模型“自由发挥”了。在检查规则的提示词末尾强制规定输出格式。例如“请严格按照以下格式回复如果通过第一行写CHECK_PASS。如果发现问题第一行写CHECK_FAIL随后列出问题并以--- SUGGESTED_DIFF ---开头给出一个统一的 diff 块。” Continue 有内建的解析逻辑但清晰的指令能提高稳定性。6.2 CI/CD 集成问题问题现象可能原因解决方案GitHub Actions 报错提示权限不足GITHUB_TOKEN默认权限可能不足以发布状态检查或评论。确保工作流 YAML 中permissions部分包含了pull-requests: write和statuses: write。对于更早的版本可能需要配置token参数。检查状态没有出现在 PR 上CI 工作流被触发但cn命令可能没有正确识别 PR 上下文。1. 确认--github-pr和--github-repo参数传递正确它们应分别对应${{ github.event.pull_request.number }}和${{ github.repository }}。2. 确保触发事件是pull_request类型。push事件到主分支不会关联到具体的 PR。每次运行都重新安装 CLI速度慢工作流未配置缓存。按照前面“高级配置”部分为 npm 全局安装目录添加缓存步骤。6.3 检查规则效果优化问题现象可能原因解决方案误报太多AI 对没问题的地方报错检查规则描述过于宽泛或存在歧义。1.收窄范围在规则描述中增加限制条件如“仅检查src/app/api/目录下的新文件”。2.提供反例明确说明哪些情况不算问题例如“忽略测试文件*.spec.js中的硬编码字符串”。3.迭代提示词根据误报案例不断修正和细化你的规则描述语言。漏报太多AI 没发现明显问题检查规则描述不够具体或者 AI 未能理解某些复杂模式。1.具体化、场景化不要只说“检查安全”要说“检查是否有eval()函数调用、是否直接拼接 SQL 字符串”。2.分步骤引导将复杂的检查拆解成多个逻辑步骤让 AI 逐步推理。3.提升模型能力尝试换用更强大的模型如从 GPT-3.5 切换到 GPT-4来处理复杂审查。AI 给出的修复建议 Diff 质量不高模型可能没有完全理解代码上下文或提示词未强调生成高质量 Diff。1.强化上下文确保启用了githubcontext provider让 AI 能看到 PR 描述和讨论。2.明确 Diff 格式在提示词中要求“以标准的 Unified Diff 格式输出更改并确保代码语法正确、可直接应用”。3.人工审核作为补充将 AI 检查视为“第一道过滤器”其建议需要经过开发者最终判断。可以在团队内建立规范对于 AI 建议的复杂修改仍需人工确认。6.4 成本控制与监控使用商业 LLM API 会产生费用。以下是一些控制成本的技巧选择性运行如前所述通过路径过滤只在关键目录变更时触发检查。模型分级为不同重要性的检查配置不同价位的模型。例如“代码风格”检查用便宜的模型“安全审查”用贵的模型。设置预算与告警在 OpenAI 或 Anthropic 的控制台设置每月使用预算和告警。本地模型替代对于内部项目或对延迟不敏感的场景强烈考虑使用 Ollama 部署本地模型如 CodeLlama。在.continue/config.json中配置provider: ollama,model: codellama:13b并将baseUrl指向本地服务地址。这可以实现零 API 成本审查虽然效果可能略逊于顶级商业模型但对于许多规则明确的检查已经足够。7. 扩展与生态不只是 GitHub ChecksContinue 的核心是 CLI 和“AI as Code”的理念这使其应用场景不止于 GitHub PR 检查。VS Code / JetBrains 插件Continue 也提供了 IDE 插件。在 IDE 中它可以基于你项目中的.continue/checks/规则在你编写代码时提供实时、上下文相关的建议。这相当于将 CI 中的“事后检查”部分能力前置到了“事中编写”形成了开发流程的闭环。你可以在编辑器中快速得到类似“你这里可能漏了错误处理”的提示。自定义工作流cnCLI 可以集成到任何你能运行命令的地方。比如你可以创建一个预提交钩子pre-commit hook在本地git commit前运行快速检查或者集成到你的内部代码评审平台中。规则共享与社区由于检查规则是简单的文本文件团队之间、甚至开源社区之间可以很容易地分享和复用那些被验证有效的检查规则。你可以想象未来会出现一个“最佳实践 AI 检查规则库”。在我个人的使用体验中Continue 最大的价值在于它将 AI 能力工作流化、标准化了。它不再是一个黑盒魔法而是一个你可以精确控制、持续改进的工程组件。初期投入时间去打磨检查规则是值得的一旦这套体系运转起来它能像一个不知疲倦的资深同事一样帮你守住代码库质量的底线让团队成员可以更专注于更有创造性的逻辑构建。