open-code-review：开源代码审查工具，规则引擎+AI双通道内网闭环

1. 为什么我会动手写 open-code-review：现有 Code Review 流程的三个硬伤

先说结论：代码审查这个环节，在小团队里基本是“名存实亡”的。我在带过几个 3 到 8 人的研发小组之后，对这一点体会特别深。不是大家不愿意 review，而是现行的流程和工作量根本不允许你认真 review。拿我自己举例，白天要开会、回消息、排需求，真正能安静坐下来看代码的时间只有下班后那一两个小时。在这种状态下，你面对一位同事提交的 800 行新增代码，能做的只有打开 diff 扫一眼命名规范、看看有没有明显的语法问题，然后点 Approve。这种流于形式的审查，说句实话，对代码质量的提升微乎其微。

后来我留意到团队里反复出现的线上故障，追根溯源，大部分在 review 阶段其实都有痕迹可循：有人把生产环境的日志级别改成了 DEBUG，有人在事务里塞了一个外部 HTTP 调用，还有人直接往代码里提交了带明文密码的配置文件。这些问题不是看不看得出来，而是人在疲劳状态下根本不会往那个方向想。我需要一个工具，能在我把代码提交上去之前，先用自动化的方式把这些“低级但致命”的问题扫一遍。这就是 open-code-review 这个项目最初的出发点。

1.1 硬伤一：Review 经常沦为“走形式”

你去看任何一个 GitHub 仓库，PR 合并记录里几乎全是绿色勾。但这并不代表代码质量好，只说明大家点了 Approve。为什么走形式？因为人脑在处理别人代码时需要上下文切换，你得先理解对方的业务背景、接口设计、异常处理逻辑，然后才能给出有价值的意见。这个认知负荷是很大的，而大多数团队的节奏根本不给这种深度思考留时间。

我的解决办法是：把机械化的检查交给工具，把人留给真正需要人判断的部分。比如格式、命名、明显的错误模式、潜在的安全隐患，这些统统让 open-code-review 在提交时先跑一遍。审查者打开 PR 的时候，看到的已经是经过过滤的问题列表，只剩下真正需要人做决策的部分，例如接口设计的合理性、业务逻辑的完整性。这样一来，review 的走形式问题就解决了一大半。

1.2 硬伤二：现有静态检查工具“只会挑刺”，而且误报率高

团队里其实不缺工具，ESLint、Checkstyle、SonarQube 都上过。但用过的朋友应该都有同感：这类工具的误报和“无价值提示”太多。SonarQube 能告诉你某个函数的圈复杂度太高，但它没办法告诉你这个函数里藏了一个忘记释放的连接；ESLint 会提醒你缩进不对，但它不会管你把不该打日志的循环体加了输出。审查者每天被鸡毛蒜皮的提示淹没，真正的关键问题反而被淹没了。

我理想中的工具应该区分“必须修的”和“建议看的”，并且允许团队自定义什么算问题。open-code-review 的规则引擎从一开始就设计成可配置、可裁剪、可分级的。每个团队有自己踩过的坑、自己约定俗成的规范，这些恰恰是通用静态分析工具覆盖不到的。自己写规则、自己维护规则库，才是让审查工具真正为团队服务的路。

1.3 硬伤三：云端 AI 审查服务和代码隐私的冲突

这两年基于大模型的代码审查服务很火，我也试用过几款。效果确实惊艳，尤其是对逻辑漏洞和潜在 bug 的敏感度远超传统静态分析。但问题来了：这类服务基本上都是把代码传到对方的服务器上做分析。对于核心商业代码或涉密项目，法务和安全部门那一关根本过不去。我们之前评估过某款服务，合同审核阶段就被安全团队拦下来了，理由是“代码出境风险不可控”。

这就促成了 open-code-review 的一个核心设计原则：审查链路必须能在内网闭环。代码解析、规则匹配在本地完成；如果要用大模型做智能审查，也要支持对接自建的内网模型服务，数据不出内网。这既是功能需求，也是很多企业会上手这个工具的直接原因。

2. open-code-review 的整体架构：规则引擎与 AI 模型双通道

open-code-review 的本质是一个命令行工具，用 Go 编写，编译后是单个可执行文件，没有任何运行时依赖。它的工作方式很简单：你给它一个代码目录或者一个 Git diff，它输出一份审查报告。但内部实现上，我把它拆成了两个并行的审查通道，各有各的职责，互不干扰。

2.1 双通道各自的职责边界

第一条通道是规则引擎通道，完全离线运行。它的输入是待审查的代码文本，输出是一系列问题条目。规则引擎里的每一条规则都是一个独立的检查器，负责匹配某种特定的代码模式。比如“禁止在代码中提交密钥”“禁止使用已被废弃的 API”“嵌套循环层数不能超过 3 层”等。这些都是确定性的判断，适合用正则表达式或者精确的 AST（抽象语法树）查询来表达。规则匹配的速度很快，上千行代码毫秒级出结果，适合嵌进 pre-commit 钩子里。

第二条通道是AI 模型通道，负责做那些规则引擎做不了的事情，比如跨函数的上下文分析、异常处理逻辑的合理性判断、数据库查询的性能隐患等。它的输入是代码片段加上下文提示词，输出是模型给出的问题和修改建议。AI 通道的延迟较高，通常在十几秒到一分钟不等，也消耗 API 配额，所以我默认建议把它放在 PR 审查阶段而不是本地提交阶段。

两条通道的产出最后都会汇入同一个问题列表，按照严重级别排序，再输出成你指定的格式。整个数据流大概是这样的：CLI 入口读入参数，交给语言检测器识别项目类型，然后把文件和 diff 分发给规则引擎和 AI 客户端，最后进入报告生成器，输出结果。每个模块都是独立的接口，你可以只启用规则引擎，也可以单独跑 AI 通道，甚至可以把两个通道替换成自己的实现。

2.2 可插拔的 AI 客户端设计

AI 通道这部分的架构我花了不少心思。市面上的大模型服务五花八门，有 OpenAI 兼容接口的，有 Azure 的，还有本地部署的 Ollama、vLLM 等。如果每个对接一个写一套代码，后面维护工作量很大。所以我定义了一个统一的 AI 客户端接口，只要实现了Chat(messages []Message) (string, error)这个方法，就能作为插件接入。

这个设计在实际使用中收益非常大。我在公司内网部署了基于 Ollama 的模型服务，在家里用的是公网 API，两边配置不一样，但指向同一个 open-code-review 二进制，仅仅是改一个base_url和model_name的参数。如果你想用自己微调的模型，甚至不需要改 open-code-review 的代码，只需要写一个适配层，把请求转换成你服务的格式即可。这一点对于工程团队来说非常实用，因为你永远不知道半年后公司的 AI 基础设施会变成什么样，但你这个审查工具不需要跟着重写。

2.3 报告输出：text、json 与 SARIF

工具跑完总要给人看结果，报告格式的设计直接决定了它能不能融入现有工作流。open-code-review 支持三种输出格式，适用于不同场景。

• text 格式：人类可直接阅读的纯文本报告，适合在终端直接跑、直接看。每条问题包括文件路径、行号、规则 ID、严重级别和描述。
• json 格式：结构化输出，适合在 CI 流水线里让下游程序消费。比如你可以在拿到 JSON 后根据严重级别决定是否让流水线失败。
• SARIF 格式：这是一个静态分析结果的标准交换格式，GitHub Code Scanning、GitLab SAST 等都支持直接导入。当 open-code-review 输出 SARIF 时，问题就能直接显示在 PR 的 Checks 页面或 Security 页面上，体验和商业工具几乎一样。

我们目前用的最多的是 SARIF 接 GitHub Code Scanning，PR 直接就能看到注释级的报告。当然如果你的 CI 用的是 Jenkins 这类老牌系统，用 json 格式回去自己写插件也很方便。

3. 十分钟跑通：安装、配置与首次审查

我写工具一直有一个原则：新用户从下载到第一次看到输出，不能超过十分钟。open-code-review 严格做到了这一点，因为它的所有功能都在一个单二进制里，没有编译环境的依赖，没有一堆 npm 包要装，也不需要你先起一个数据库。

3.1 安装方式：一条命令解决

在 macOS 或 Linux 上安装，最直接的方式是拉取 GitHub Release 里的预编译产物：

curl -sSfL https://github.com/yourname/open-code-review/releases/latest/download/ocr-linux-amd64 -o /usr/local/bin/ocr chmod +x /usr/local/bin/ocr

macOS 用户把linux-amd64换成darwin-amd64或darwin-arm64即可。如果你用的是 Go 环境，也可以直接源码编译：

git clone https://github.com/yourname/open-code-review.git cd open-code-review && make build

安装完后在终端输入ocr version，能看到版本号就说明没问题了。值得注意的是，这个工具没有任何配置文件之外的状态，你卸载它只需要删掉一个二进制和一个.open-code-review.yaml文件，不用担心留下什么系统垃圾。

3.2 配置文件：一页纸看懂核心参数

第一次运行之前，你需要建一个配置文件。open-code-review 会在当前目录下自动查找.open-code-review.yaml，找不到就使用内置的默认配置。这是我的推荐起步配置：

# .open-code-review.yaml language: auto # auto 时根据文件扩展名识别语言 severity_threshold: warning # 低于 warning 的问题不展示 rules: enabled: true # 是否启用规则引擎 custom_rules_path: ./rules # 自定义规则的存放目录 ai: enabled: false # 默认不启用 AI 通道 provider: openai # openai、ollama、azure 等 base_url: "" api_key_env: "OPENAI_API_KEY" # 从环境变量读 key，不要写进配置文件 model_name: "gpt-4o-mini" timeout_seconds: 60 max_tokens: 2000 context_lines: 30 # 每个问题点附带多少行上下文 report: format: text # text、json、sarif output: stdout include_ok: false # 是否展示通过的检查项

几个容易踩坑的地方我提前说一下。api_key_env指定的环境变量最好在 CI 平台的 Secrets 里配置，而不是写在 YAML 里，因为 YAML 文件通常会提交到仓库中。timeout_seconds建议不要设太短，大模型在代码分析任务上响应慢是常态，设 60 秒是一个比较稳妥的值。context_lines控制 AI 提示词里每个问题附带的上下文行数，加得越多越准，但 token 消耗也越多，30 行是一个平衡点。

3.3 首次审查实操：单文件、目录和 Git Diff

安装配置完成后，来跑第一个审查。假设你的项目根目录下有一个utils/logger.go文件，你想看看里面有没有明显问题：

ocr check --file utils/logger.go

这条命令会触发规则引擎，对该文件做全量检查。如果配置了rules.custom_rules_path，它还会加载你自定义的规则。输出大概长这样：

utils/logger.go:45 [error] sensitive-key Detected a hardcoded API key in log output utils/logger.go:78 [warning] deep-nesting Nesting depth is 5, exceeds the limit of 3

如果觉得单文件太片面，可以直接对目录做检查，这样会递归扫描所有匹配的文件类型：

ocr check --dir ./internal

但在团队协作中最常用的场景，其实是只看这次改动的内容。全量检查固然全面，但审查者真正关心的是本次提交引入的问题，而不是历史遗留问题。所以 open-code-review 提供了基于 Git 的审查模式，只分析工作区未提交的改动：

ocr review --staged

如果你想审查某个尚未合并的分支相对主分支的差异，可以这样写：

ocr review --base main --head feature/foo

这几种方式覆盖了日常开发的核心场景：提交前自查、分支合并前检查、CI 里自动审查。实测下来，一个中等规模仓库的 diff 审查，规则引擎部分耗时基本在 5 秒以内，完全不会让人等得烦躁。

3.4 接入 SARIF 并上传到 GitHub

如果你们团队用 GitHub，我强烈建议把 open-code-review 的输出接到 Code Scanning 上。你只需要让工具输出 SARIF 格式，然后引用github/codeql-action/upload-sarif这个 Action 来上传结果。我在 CI 里的做法是：

- name: Run open-code-review run: ocr review --base main --head ${{ github.event.pull_request.head.sha }} --format sarif --output ocr.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ocr.sarif continue-on-error: true

之后打开 PR 页面，就能在 Checks 标签中看到 open-code-review 的注解式评论。哪一行有问题，鼠标指上去直接显示详情，体验和 CodeQL 几乎一致。这个方案的额外好处是，历史报告会保留在 Security 页面里，你可以追踪某个规则命中次数的变化趋势，比如“硬编码密钥”这类严重问题有没有在持续下降。

4. 把审查嵌进 Git 工作流：Hook 与 CI 的完整接入

工具能手动跑是一回事，能让整个团队都用起来是另一回事。落地过程中最核心的一步是把 open-code-review 嵌入到大家每天都在用的 Git 工作流里，做到“无感使用，自动审查”。下面我分享两种已经经过实践验证的接入路径，以及团队推广时的门禁策略。

4.1 用 pre-commit 实现提交前自动拦截

团队里的规范，如果靠人自觉，基本等于没有。所以最好把检查推到提交之前，让不规范的代码根本没有机会进入提交历史。目前 Git 生态里最流行的钩子管理工具是pre-commit，open-code-review 提供了对应的 hook 配置。你需要做两件事。

第一步，在项目根目录建一个.pre-commit-config.yaml：

repos: - repo: local hooks: - id: open-code-review name: open-code-review entry: ocr review --staged --format text language: system stages: [pre-commit] pass_filenames: false

第二步，确保团队成员的$PATH里有ocr命令。之后每次执行git commit，pre-commit 都会先跑一遍 open-code-review，问题没清完就不让提交。这里有一个设计要点我特别说明一下：它的 trigger 是对 git index 里的和暂存区里的内容做扫描，而不是对已 commit 的内容，所以检查的恰好是你即将写入历史的那一份代码。

接完 hook 之后，最大的变化是“羞耻时刻”变多了。有些同事第一次提交时被拦截，提示他代码里带了调试日志和注释掉的代码块，面子上确实挂不住，但几次之后大家就形成了肌肉记忆，提交前先自己跑一遍。这套机制的价值在于，它把“代码规范”从抽象的口头要求，变成了可执行的技术约束。

4.2 在 GitHub Actions 中做 PR 级审查

本地钩子只管得了一时，总有人能绕过它，也总有不经过本地提交的场景（比如直接在 GitHub 网页上改代码）。所以 PR 级别的自动审查是必须补上的一环。我在项目里写了一个复用性很强的 GitHub Actions 工作流，核心步骤就三步：安装工具、跑 diff 审查、决定是否合并。

name: code-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 必须拉全量历史，才能计算基准差异 - name: Install ocr run: | curl -sSfL https://github.com/yourname/open-code-review/releases/latest/download/ocr-linux-amd64 -o /usr/local/bin/ocr chmod +x /usr/local/bin/ocr - name: Run review run: ocr review --base origin/${{ github.base_ref }} --head HEAD --format json --output report.json - name: Fail on blocking issues run: | count=$(jq '[.issues[] | select(.severity == "error")] | length' report.json) echo "Blocking issues: $count" if [ "$count" -gt "0" ]; then exit 1; fi

这里有三个细节决定这套流程能不能稳定运行。第一，fetch-depth: 0是必须的，因为git diff需要比较两个 commit，默认的浅克隆会让比较结果不正确。第二，base 必须是origin/mian而不是main，在 GitHub 云执行器上本地分支名不一定存在。第三，gate 的条件我用jq解析 JSON 里的error级别问题，数量大于零就让流水线失败。按我的经验，把门禁卡在“error”而不是“warning”这一步至关重要，否则第一天就会被大量历史遗留问题淹没，第二天团队就会集体要求下线这个工具。

4.3 GitLab CI 和本地 Git 钩子的替代方案

不是所有团队都在用 GitHub，GitLab 用户也非常多。GitLab CI 的配置思路类似，区别在于它原生支持rules按分支做条件执行，还能借助merge_request_events在 MR 创建或更新时触发：

review: stage: test image: golang:1.22 only: - merge_requests script: - go install github.com/yourname/open-code-review@latest - ocr review --base origin/main --head HEAD --format sarif --output gl-code-quality-report.json artifacts: reports: sast: gl-code-quality-report.json

如果你连 CI 平台都没有，那就退回到纯 Git 钩子。把ocr review --staged的逻辑写进.git/hooks/pre-commit脚本里，不依赖 pre-commit 框架，也能达到类似效果。但我还是推荐用 pre-commit 框架，因为团队还有人用 Sourcetree、GitKraken 这些 GUI 工具，pre-commit 能统一所有客户端的执行环境。

4.4 团队落地时的阈值与门禁策略

工具接入从来不是技术问题，而是节奏问题。我见过的失败案例都有一个共同特征：上线第一天就把门禁拉满，所有历史问题全部暴露，开发一提交就卡住，怨声载道，第二天就被投票下线。正确的落地策略是分三步走。

第一周，把 open-code-review 设为 Informational 模式，只报告问题、不阻断合并。让团队熟悉输出格式，同时让工具积累当前代码库的基线数据。第二周，把“error”级别设为阻断，但允许少数已知问题走白名单。第三周，再逐步把“warning”中一些明显有共识的规则提升为阻断。这个过程要给团队留出修历史债的时间，而不是逼他们一夜之间把十年老项目的债务全部清零。

5. 自定义规则：从零写一条团队专属检查项

内置规则再全，也覆盖不了每个团队自己趟过的坑。我在设计 open-code-review 的规则系统时，把它定位成一个开放平台：任何一个人都能花十分钟写出一条团队专属的检查项，并且能立刻在 CI 里生效。

5.1 规则文件的语法结构

规则存放在配置里指定的目录中，比如前面的custom_rules_path: ./rules。每个规则是一个独立的 YAML 文件，名字随意，结构如下：

id: no-http-api name: Block HTTP API calls severity: error scope: content enabled: true patterns: - pattern: | http\.(get|post|put|delete)\("http:// message: 禁止在代码中直连 HTTP 明文接口，请使用 HTTPS exclusion: | // 可以在这里放文本，表示当命中以上 pattern 时，匹配到这段文本的就不算问题

id是全局唯一的规则标识，scope决定这条规则作用在什么粒度上，目前支持content（对代码文本直接匹配）和ast（对抽象语法树操作）两类。patterns是核心，里面可以放多个 pattern，满足任意一个就视为命中。exclusion是一个可选的排除文本，用于处理误报场景，比如某些测试代码里刻意使用 HTTP 端口的情况。

5.2 实战示例：三条例行公事的老生常谈规则

第一条规则：禁止遗留 TODO。很多团队允许 TODO 出现在代码里，但一年后回头看，这些 TODO 变成了永恒 TODO。把 TODO 标记为 warning，提醒开发有未完成的工作需要处理：

id: no-todo-leftover name: Detect leftover TODO comments severity: warning scope: content patterns: - pattern: "TODO\\s*:?\\s*[\\u4e00-\\u9fa5A-Za-z]{5,}" message: 请勿在提交代码中遗留 TODO 注释，未完成事项请关联 Issue

第二条规则：限制函数行数。我知道会有人争论行数限制是否有意义，但在代码审查场景里，一个函数动辄上百行，本身就是可读性差的信号。规则引擎在 AST 模式下可以拿到函数的起止行号，做长度判断：

id: function-too-long name: Function exceeds 100 lines severity: warning scope: ast lang: [go, python, javascript] condition: type: function_length max_lines: 100 message: 函数长度超过 100 行，建议拆分

第三条规则：检测硬编码的数据库连接串。这个是真出过事故的。我们有一个同事把生产环境的数据库连接串直接写进了初始化代码里，合到主分支后，连接串被一个爬虫扫到，数据库被拖库。从那之后，我把这类规则设成了 error 级别：

id: hardcoded-db-dsn name: Detect hardcoded database DSN severity: error scope: content patterns: - pattern: "(postgres|mysql|mongodb)://[^\\s]{8,}" message: 检测到疑似硬编码的数据库连接串，必须通过环境变量或密钥管理服务注入

5.3 规则调试与误报调优

自定义规则大概率第一次就会产生误报。我的经验是，规则上线之前先在历史代码库上跑一遍全量扫描，统计一下命中数量。如果一条规则命中了一百处，那不太可能是代码问题，更可能是规则写得太宽泛。比如上面的数据库连接串规则，在测试项目里可能命中很多本地开发用的 docker compose 配置，这些其实是无害的。解决办法是利用exclusion字段加上排除条件，或者针对路径加白名单。

open-code-review 在规则调试上还有一个实用的--explain参数，它可以告诉你某一条问题命中的是哪条规则，规则的正则表达式匹配到了哪一段具体文本。这个参数在排查“为什么这里报错了”时价值极高，省去了你打开正则编辑器反复实验的时间。

6. 实测对比与踩坑记录

工具写出来是要在真实代码上跑的，不是拿来发文章的。我拿同一个后端仓库分别跑了 SonarQube、CodeRabbit 和 open-code-review，也把这段时间踩过的几个技术坑整理了出来，希望能帮你少走弯路。

6.1 同一份代码，三款工具的实际表现对比

我选取了一个中等规模的 Go 后端微服务仓库，大概 8 万行代码，选了一个 600 行的 PR 作为测试样本。结果值得参考。

结论说了可能有些偏颇，但这是我的真实观察：SonarQube 适合大企业做全量代码质量度量，重但稳；CodeRabbit 适合对代码隐私不敏感的开源项目或中小团队，AI 的分析能力确实强；而 open-code-review 最适合的是那些既想要自定义规则、又对代码隐私有要求、还不想维护一套重量级服务端的团队。

6.2 踩坑一：diff 解析时中文文件名导致的乱码与空白问题

开发过程中第一个让我头疼的 bug 出在 Git diff 解析。最初的实现直接按行切分git diff的输出，用正则提取+++ b/后面的路径。这在英文文件名下一切正常，直到某天我在一个中文项目里测试，发现文件名里的 UTF-8 字符被错误地截断，导致后续的规则引擎找不到目标文件，非直接跳过。

排查后发现根因是 Go 的字符串处理没问题，但我用的一个第三方 diff 解析库在计算文件路径时，对非 ASCII 字符的字节取舍有 bug。最后解决方案很笨但很有效：改为调用git diff --name-only先拿到权威的文件列表，再逐个文件做 diff 内容匹配。别迷信那些所谓的通用 diff 解析库，Git 自己的输出格式才是最稳定的。

6.3 踩坑二：AI 审查的 token 消耗失控

AI 通道刚上线时，我犯过一个低级错误：没有限制单次审查的文件数量，直接把整个 PR 的所有 diff 一次性塞给了模型。在一个 600 行 diff 的 PR 上，模型一次请求消耗了我 8 万多个 token，成本高得吓人，而且响应时间长达几分钟，CI 直接超时。

后来我加了两道闸门。第一道是分级截断：只把 rule 通道中标记为warning或error的代码片段发给模型，过滤掉完全没问题的部分；第二道是文件上限和行数上限，单次 AI 审查最多分析 20 个文件、每个文件最多取 200 行上下文。过了这个阈值，多余部分自动落到规则引擎，不再让 AI 逐行看。这个优化之后，一次 PR 审查的 token 消耗降到了原来的十分之一以内。

6.4 踩坑三：规则引擎的正则表达式灾难性回溯

写正则规则最怕遇到灾难性回溯。我在写“检测嵌套函数调用过深”这类规则时，用过一串带有多个嵌套分组和量词的正则。在短代码上跑没什么感觉，但遇到某段 200 行的复杂匿名函数嵌套代码时，规则引擎直接卡死了整整 40 秒。这不是 open-code-review 的问题，而是正则本身写得太丑陋。

经过这次教训，我对规则编写定了一条铁律：能用 AST 就不写正则在正文上，非要写正则，必须通过安全正则引擎做超时保护。open-code-review 内部给每条规则的正则匹配都设置了 200 毫秒的执行超时，一旦超时就跳过该规则并在日志中标记。这能避免一条烂规则拖垮整个审查流程。

用 open-code-review 跑完一个季度之后，回头看这件事

这个项目从最初我一个人的自用脚本，迭代到团队里日常运转的审查基础设施，前后大概花了三个月。现在回过头来复盘，最让我欣慰的一点是它真正改变了团队对代码审查的态度：以前大家把 review 当成任务应付，现在把工具输出的报告当成第一道防线，人会站在工具肩膀上做更高层次的判断。

如果你也想在团队里搞一套类似的机制，我的建议是从最小的闭环开始：先装好本地命令行，先把自己每天提交的代码跑一遍，感受一下规则引擎的输出是否能帮上忙。等你自己认可了这个工具的价值，再推给团队，再接入 CI，一步一步来。如果你用得不顺手，规则引擎那一层可以完全按你的习惯来调，我觉得这恰恰是 open-code-review 和那些“开箱即用但没法改”的商用工具最大的区别——它把代码审查的判断权，重新还给了写代码的人。