当 AI大幅提升了写代码的效率，我们依然发现一个不合理的现象：写代码的速度可能提升了十倍，但发布产品的效率并没有提升十倍，传统“人月”的工程效率衡量指标正在被挑战。
这个现象的背后，有一个XEngineer营希望和大家一起去探索、去实践的话题——AI时代，我们该如何让软件工程的整体效率能得到倍增，甚至是十倍增？也许，我们该重新思考“怎么正确做事”。
这个话题，在7月6日的开营仪式上，七牛云CEO、XEngineer营发起人许式伟，带来了一些他的思考与分享。
01
AI时代，写代码不再是最大的瓶颈
也许我们每个人都应先拷问自己一个问题：你的时间，花在哪里？
当 AI已经能写很多代码，如果我们还是不自觉地将绝大部分时间用在写代码上，也许我们只是获得了一个“更快的键盘”，对于工程效率、团队成果、项目收益等并没有助益。
AI 让编码速度不再是团队产出的天花板。真正决定项目成败的，是产品判断、架构设计与团队共识——这些从未被自动化的部分。
因此，第六期XEngineer营将在实践中，将产品设计的比重将提升至50%(在曾经的1024实训营中，产品设计占比仅20%)，架构与开发过程占另外50%。
02
AI时代，没有“单人”软件工程
以前，也许存在“一个人”的软件工程，一个人维护一个小项目，想法在脑子里，直接开始写代码，也能跑得通。
AI 时代，这件事不再成立。不论我们处于一个怎样规模的团队中，我们都至少有一个非常明确的伙伴：AI。这意味着，无论是和团队成员，还是和AI，协作都必将发生。
团队高效的基础，是无歧义的共识。共识不是开会达成的感觉，而是每个人独立复述出来都一致的表达；共识需要载体，抽象的想法必须被表达成可检验的具体形式；共识是可以被验证的，如果两个人理解不一样，说明共识还没有达成。
我们得基于团队协作的逻辑，让团队伙伴和AI清晰地了解我们的意图、达成彼此的共识，我们才能彼此解耦、分工协作、事项并行、工作没有冲突，才有可能让“一个5人团队发挥出从前500人企业都难以企及的效能”变为现实。
因此，当我们在探索怎样提升软件工程效能的话题，我关心的是怎样去表达团队所需要的“共识”。
03
怎么表达“共识”？
软件工程领域的共识，核心涉及两个部分：产品设计的共识、架构设计的共识。
产品设计的共识，分为2个层次：
最重要的是抽象的“战略决策”——要什么、不要什么(做取舍)、谁是目标用户、用户有什么痛点、解决方案是什么。
其次，才是具象的“产品原型”——用图、用可交互的原型，把抽象的价值判断落成看得见、摸得着、可评审的东西，让所有人对着同一张图讨论，而不是各自脑补。
值得注意的是，先有取舍，再有原型——顺序不能倒。
架构设计的共识，则分为3个阶段：
第一阶段，是系统架构，我们需要定义模块的规格与连接方式，把一个复杂系统拆成边界清晰、职责单一的模块，模块之间靠明确的接口对话，而不是靠默契；
第二阶段，是模块架构，我们需要定义模块内部如何实现。在系统架构划定的边界之内，每个模块可以自由选择自己的实现方式——这是模块负责人的自治空间，不需要向全局暴露细节。
第三阶段，是代码实现。代码实现在架构设计之中，有点类似于原型图在产品设计里的原型图，已经是最后非常具象、可以看见、可以运行的产物了。
关于“共识”的表达方式，文档是表达共识的工具之一，但是，原型图、架构图、甚至一个空壳的代码、可运行的最小示例等，也都是非常好的表达方式。
04
一个核心问题：什么是好产品？
什么是好产品？这是产品设计中最关键的问题。
我们应当从用户价值出发，而不是从技术炫技出发：我们得思考谁真正需要它，目标用户会是具体的人，而不是抽象的“大家”；关于痛点，应当是被验证过的，不是想象出来的；我们甚至还需要问自己“为此放弃了什么”，因为好产品的边界，是靠取舍划出来的。
每次开营，我都会与大家分享的是：初级产品经理做的是加法，但顶级产品经理做的是减法。为什么呢？为什么顶级的产品经理做的是减法呢？
我有一个朴素的观点：好产品:=用最少的功能，实现最大化的需求覆盖。
强调“用最少的功能”可能是“逆直觉”的，大家常常会听到一些产品经理自夸“我这个产品有好多功能”。
但回到产品设计的本质，我们谈的其实是商业的ROI，也就是社会价值/用户价值(需求)除以实现代价(功能)。要想这个ROI足够高，就是要让开发成本等实现代价足够低，而社会价值足够高。因此，产品有很多功能，也许并不是一件值得炫耀的一件事情。
我一直非常推崇Go语言团队的Rob Pike所说的：“少，就是指数级的多”，这句话其实可以被看做一个产品设计的准则。当我们想清楚、真正知道用户需要的核心功能是什么，才能在更少功能的情况下又实现用户需求的覆盖。
最典型的案例，其实是电脑。大家仔细观察会发现，这么多年以来，电脑的架构其实没有怎么变，但电脑满足的社会需求的能力其实迭代了非常多。
05
系统架构如同地基，但非常难设计
系统架构比模块架构要难得多，很多团队在开发后期面临联调困难，就是系统架构没设计好的一个非常典型的后遗症。那么，系统架构到底该如何表达呢？
用文档表达的系统架构，还是有歧义的。其实系统架构更好的表达方式是用代码来写，当然会辅助以非常精简的文档，加上一个初步完成的整体系统结构(里面的代码可以是空的，但系统结构已经完成设计，可能还会吐出一些mock数据)然后，争取让整个系统跑起来。
不同级别的团建工程团队，做出来的系统架构截然不同：
能跑起来的系统架构，是最牛逼的。
跑不起来，但是设计好结构，谈清楚模块之间的耦合，这是一个次优解。
相对差的系统架构表达，只是用一份文档
当然，更差的是连文档都没有，直接(用AI)写了一堆代码，谁都不明白其中是怎么回事。
06
一个“异常”做法，不鼓励把产品和架构文档入库
工程习惯好的团队，通常会把产品和架构的文档入库，但XEngineer营将进行反其道而行之的实践。
我们的设计工作都将以PR来承载，产品设计讨论、产品原型、架构讨论都开一个PR来展开，评审意见直接留在PR里；但是，PR本身并不会被合并到库里，它只是讨论和评审的载体，而不是要合入代码库的正式文档；在产品设计和架构讨论形成定论后，定论将结论固化为Issue，作为后续编码实现的基础。
这么做的最核心的原因，是我们希望能构建一个可回溯的软件工程，让我们的共识有历史快照。
我们知道，文档会撒谎，入库的架构文档很快就和实际代码脱节，过时的文档比没有文档更危险。与其维护一份平行的描述，不如让架构从代码结构和演进历史中直接可读，代码本身就是真相。而且，共识需要新鲜度，架构是活的、持续演进的，把它钉死在一份静态文档里，反而固化了错误。
而当前的“异常”做法，可以让系统从Day1开始如何一步步发展到现在这样，被不断回溯，所有的历史都将被完整保留。
07
不只是学员，也是共建者
在 XEngineer营，也许会有一些“反直觉”的实践，我们将不断遇到跟固有习惯(这些固有习惯也许是在AI时代之前养成的)不一样的做法。
但所有探索和实践的底层逻辑，是为了回答最初的那个问题——AI时代，我们该如何让软件工程的整体效率能得到倍增，甚至是十倍增？
我们期待每一位学员，以及同样希望去探索这个话题的朋友们，一起参与实践，也提出改进做法。
