前言

很明显，AI带来的影响已经远远超出了几年前所有人的预期。在几年前，大家还在用着经典的BERT、YOLO模型，做一些最简单的人工智能任务（比如那个最经典的手写数字识别任务，或者是比较简单的情感分析任务），而现在已经开始大面积被AI取代。金融人引以为傲的数据搜索，建筑师们的建筑设计，程序员的代码编写，画师们的精美插图……一概被AI如同秋风扫落叶一般碾压过去。某种意义上来说，如果不能适应AI，那大家确实已经成为原始人了。

那么在新的AI时代里面，我们怎么样尽可能的提升我们的工作效率？我摸索了三个月，有了一些心得体会，现在分享给大家。

同步工作与异步工作

一般而言，作为程序员的我在全面拥抱AI之前，工作流大概是这么一个样子：

接到一个需求
->
开始制定demo计划
->
和同事/领导进行讨论
->
(不同意)进行修改
(同意)写出一个详细的计划
->
审批通过
->
开始实现
->
交付成品

可以看到，这个工作流完全是同步的。每一件事在完成前都无法去提前做下一件事，这导致了工作上的低效。假设AI能让我（开始实现）这个步骤的用时降低70%，我的总用时可能只降低了20%。毫无疑问，这是不可接受的。

怎么提升效率呢？我们首先要知道AI可以让实现变得极快，其次是现在经过多次升级后的模型在计划上有着很大的优势，可以轻松把一个你没有完全说明白的细节进行事无巨细的讨论，从而制定出一个看上去很完美的计划。

那么，我们就可以从“计划驱动的实现”工作流转化为“实现驱动的计划”。如果你的计划本身的同意概率很高，或者说你的计划不太需要进行修改，那么我们可以提前进行预实现，从而加速整个流程的速度。

接到一个需求
->
AI开始制定demo计划
->
和同事/领导进行讨论
(同时)AI进行代码实现
->
(不同意)计划进行修改，让AI去对你实现的代码进行修改以符合计划
(同意)AI通过总结你的实现的代码，反推写出一个详细的计划
->
审批通过
->
质量检测(稍微看一下当前实现)
->
交付成品

通过这种基于实现的工作流，我们可以发现：

代码实现的时间几乎完全不见了（因为第二步就开始实现代码了）
你与AI实际上只有第一步制定demo计划时是同步的，剩余的所有事情几乎都是异步的
你的代码实现不会成为这个流程的慢速瓶颈，而你的讨论会成为瓶颈

总而言之，这种方案经过实践，我完全可以说我的整体工作效率有着超过50%的提升。

提升讨论效率

通过我们对工作流的改善，我们可以发现：现在的瓶颈由程序员本人的工时（写代码），转移到了“讨论实现方案”这件事上。这件事偏偏又没法节省掉，毕竟人工智能读取不了大家的思维，可能同一个服务大家的定位、预期、架构思考都是不一样的，这就导致了这件事本身不可替代。那我们怎么尽量节省用在这件事上的时间呢？

首先我们得知道，存在一种AI Agent工作模式:YOLO。这个工作模式让AI完全自主的去进行全面的工作，人工完全不进行干预。在容器里这么做一般是十分安全的（或者你的工作不太涉及到和互联网之间的交互），那么我们就可以在非工作时间，让AI去进行代码实现，而讨论本身则可以填满你的常规工作时间——毕竟大家一下班就影踪不见了，本身讨论是依赖于上班的，节假日这种就成为了阻碍工作速度的一部分。但这个也没啥办法。

通过这么做，我觉得至少常规8小时上班的时间里面，可能可以填充50%的会议时间，从而极大提升工作效率。

旁路工作

在工作中，除了我说到的既定的，有较长截止日期的工作，也有那种临时的、紧急的需求。如何平衡这两者从而提升整体工作效率，我经过实践想到了一个方案。

紧急工作一般有两种：一种是临时的，小于4小时操作时间的工作，这种一般要当日交付；一种是任务重的紧急工作，大概是一周内交付的中型工程。

第一种情况下，首先进行一个理论判断，一般来说这种小活难度不高，可以完全依赖于AI去做。这时我一般会花费5-10分钟写一个比较详细的执行流，相当于一个小型计划，提出需求和大致的实现方案和验证方案，然后开一个工作空间然后完全交给AI去做。事实证明，现在AI的能力已经基本足够进行这种工作了，我这三个月内的大部分这种工作都可以被我这个流程解决。

第二种情况下，对于这种截止日期比较近的工作，我的方案会更接近于同步工作。因为这个时候，你得确保AI不会天马行空的替你搞一些烂活，所以这个时候跑AI模型我会使用能用的最高级模型，在上班时间跑从而进行随时干预，放弃那些快速模型。但这种方式会因为模型本身跑的速度极慢，从而很耽误你的时间，可能跑了一个小时才进行了个位数的命令操作。这时候我偶尔就会放弃CLI进行工作，而是在网页版AI里进行计划讨论，毕竟这种工作不是修改代码所以不追求完全的精确性。这样至少在计划制定层面会快一些，实现的话慢也没啥好办法。

Be aggressive

这一块怎么说呢，是我的一些体验分享。我认为，当下的AI时代毫无疑问是日新月异的，几家头部大模型厂商的发布速度已经达到了月级别甚至是半月级别，而功能需求的开发速度甚至达到了周级别。如果说当前状态下，你还使用那种传统的软件开发周期（大型需求要一个季度去做）进行推进，那可以说就是往失败一路前进。在现在这个时候，“速度就是生命”这句话可以说是完全实现，如果不能有一定的侵略性，你的工作将完全无法推进，或者说落后于竞争对手。这是不可接受的。

平衡质量和速度

另一方面是关于“质量”和“速度”的平衡。当前AI生成代码，在某些时候是相当不错的，但更多的时候只是差强人意，如果我们依旧追求极高的代码质量，那么我们就会成为代码实现上的一个瓶颈。对于大部分的需求，实际上我们没有高代码质量的需求，而只是需要“可堪一用”的成品。所以，我编写了几个专门进行检查代码质量的AI Agent作为代码提交的门控，只要他们认为没啥问题的话，我几乎不会干预AI写代码本身，也就是某种意义上的全自动代码编写。虽然这个和Cursor，CoPilot这些工具本身所体现的价值观完全相反，但市场已经证明了这一点的正确性。所以，我们要在“可堪一用”的质量控制下，用最快的速度进行代码输出（前提是非核心服务）。