在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只是把头文件贴过来将代码段变成一个拥有完整上下文定义的整体，编译时就会出现引用的某个代码段在多个编译单元内重复编译然后链接时再合并的过程，重复编译自然会拖慢效率。

三年一度的C++标准文章这回在不到两年的时间点就开始了（请想象自嘲口吻），这次是一个持续更新形式，主要由于本就是利用业余时间写的，近两年家里又多了个小淘气，闲暇时间就越发少了，尽早更新完吧。这次看到中文维基百科上C++标准的条目内容有所缺失，所以同时还会持续更新这个页面维基百科 C++20，当然维基百科上不能像这篇文章里一样这么多废话。😂

新的语言特性

特性测试宏

或称功能特性测试，在c++标准中增加了预处理宏用以检测当前的c++功能支持情况，以往这些预处理都是根据编译器版本宏来控制，现在标准中增加了这些宏。
这些宏包含：

1. 属性检测宏__has_cpp_attribute，形式是宏函数内传递属性token：