最近AI vibe coding多了发现一些问题，其中包括AI生成代码的review问题。目前我对于AI代码的态度偏谨慎，大部分AI代码会review一遍，但毕竟人工review费时费力，代码量大了之后review就更痛苦了。
于是想到了之前博文提到的让AI去review的方式，尝试了在AI coding ide上通过skill来review，发现效果不太好，最近看到阿里发布了open-code-review的开源智能体，试了下好奇这个agent的逻辑，便写篇文章分析下。

项目地址: open-code-review，分支main，当前版本commit 1c8f930，go语言编写，以下简称ocr，官方介绍：

Open Code Review 是一款 AI 驱动的代码审查 CLI 工具。它的前身是阿里集团内部官方 AI 代码审查助手，过去两年在内部服务了数万开发者，识别了数百万个代码缺陷。经过大规模充分验证后，我们将其孵化为开源项目，对社区开放。只需配置一个模型端点即可使用。
它读取 Git diff，通过具备工具调用能力的 Agent 将变更文件发送至可配置的 LLM，生成具有行级精度的结构化审查意见。Agent 可以读取完整文件内容、搜索代码库、检查其他变更文件以获取上下文，从而进行深度审查——而非仅停留在表面的 diff 反馈。除了 diff 审查，ocr scan 可以审查整个文件，适用于审计不熟悉的代码库或没有有意义 diff 的目录。

源码解析

大致走一遍代码：

在2023年4月时，我曾在工作上搞过一次当时的AI辅助开发调研，调研对象是Github Copilot X及ChatGPT，彼时我的结论是Copilot的代码提示与补全可以一定程度提高软件开发效率。

但当时的模型幻觉频次较高且智能程度有限，让我觉得LLM（Large Language Model，大语言模型）的代码补全甚至不如LSP（Language Server Protocol）补全来的实际有效，所以23年到现在这三年里，大部分时间LLM在我的开发场景中是扮演着一个高级Google的角色。

时间来到了2025年12月，工作上的的一些脚本类工作让我又捡起了AI辅助开发，在使用了一两个月之后，我想我需要写些东西聊聊当前大模型时代下的软件开发。

C++20前模板需要给类型添加限制时，比如需要给一个函数模板的参数类型限制为整形，可以使用c++11中的std::enable_if和std::is_integral：

1
2

template <typename T, typename = std::enable_if_t<std::is_integral_v<T>>>
void foo(T t) { /*...*/ }

即通过额外的类型匹配来完成类型约束，你可以在stl源码中找到大量的enable_if约束。
但这种做法有几个问题：

1. 复用麻烦，当多个模板需要相同的类型约束时，只能将相同代码复制多份
2. 约束失败时错误不明了，如上模板传入浮点类型时，编译器只会抱怨enable_if<false, void>内没有type类型，如果约束条件更复杂，得到的编译错误将更难以阅读

综上原因，20标准往前走了一步，将类型约束（Constraint）进行了规范，并提出了新的“概念”（Concept）。

在20标准刚发布时，我曾读过几篇介绍20标准协程的文章，那时感觉标准里的协程难用，离开箱即用还很远，且当时编译器还没支持协程。
写本文时重读标准的协程方案，有了不同的看法，对于语言标准来说，20标准中的coroutine是一个基础设施，作为基础设施只需要提供足够的自由度就行。
那么废话少说，以下是c++20标准的协程详解。

why coroutine

本想在第一章系统介绍下协程这个概念，写写发现这话题太大，况且对于老码农来说也不需要我在这啰嗦（Go的goroutine、lua的coroutine）。如果你不知道协程，只需要知道协程是一个用户态的可挂起可恢复执行的函数即可。
本节聊聊为什么c++在要加入协程：

背景

c++一直以来使用c风格#include头文件方式引入依赖，而#include的方式存在诸多问题长期被程序猿吐槽，细数下来，这些问题包括不只限于：

include方式存在的问题

拖慢编译速度

这也是标准委员会引入module的主要原因，#include只是把头文件贴过来将代码段变成一个拥有完整上下文定义的整体，编译时就会出现引用的某个代码段在多个编译单元内重复编译然后链接时再合并的过程，重复编译自然会拖慢效率。