最近比较闲,所以就开了这么一个专题,主要是分享一个平常开发时候的一些思路,希望可以帮到大家.
今天说的东西叫做需求和计划解耦
cc和codex都有写plan的功能,或者说superpower里面有一个叫头脑风暴的东西,但是有的时候属实不太好用,特别烧token,问题出在哪里呢?
1,不停的读代码,写代码plan
2,不断的内容不停的挤压上下文,清除了上下文又会导致agent丢失对前面上下文的了解
所以我们在某一些时候可以采用需求和计划(plan)解耦的方式来提效.
简单来说,需求是宏观的设计,plan是代码的实现.
需求这部分不需要代码参与,可能在刚开始,agent需要读一部分代码来看现在这里是怎么设计的(当然如果有这里原本的设计文档就更好了)

第一次也许需要一段时间,这里是正常的,然后我们要做的,就是和agent对清楚需求(这里注意不是plan),agent也不需要思考任何代码,除非agent对某一些业务的理解不太清楚,那就确实要读代码了(因为没有沉淀下来设计文档),
然后就是和agent不停的头脑风暴探讨需求了,这里就是这样开发优势的地方之一了,你会发现因为没有代码的干预,基本agent回复你一轮的时间被压缩到了20s-2min以内,20-40s是agent思考的正常时间,而2min是agent需要简单的读一部分代码的时间.
如果一开始就让agent写代码呢?他会疯狂的读代码,然后写个几十几百字符,但是也有可能后面发现写错了,而且一次需要n分钟-十几几十分钟.
就这样,我们在制定需求的时间被压缩到了直接写plan的十几分之一,同时上下文基本是干净的没有代码,只有你们讨论的需求文档,
当需求文档沉淀下来并且没问题之后,就是写plan的时候了,plan是你代码的沉淀,这个时候,agent应该会去读你的代码,然后去看一些代码架构方面的设计,或者说,如何实现你的需求
这里基本包含下面的几个方面:
1,表结构设计:我是建表呢?还是复用呢?因为我们已经有了一个完整的需求文档,所以理论上可以避免agent因为遵守当前最好使的原则来写一些屎山.
2,代码内部实现:包含各层之间的整套流程,因为是一次性成型,理论会比直接写plan更优秀,因为不会因为多次实现而导致前后写的内容矛盾或者没有理解你的需求
其他还有很多小细节,其实没有什么必要细聊了,这里只简单定义框架,至于需求文档里面包含什么,计划文档里面包含什么,是以文件还是文件夹的形式,就看佬友自己玩了,
好了,现在我们又要头脑风暴了,与上面的那次不一样的是,我们这次是探讨的现在我们的代码.
现在我们的plan已经写完了,我们发现里面的逻辑基本没有偏差很大的内容,不会出现前后冲突太大的问题,
然后就是愉悦的coding阶段了.然后一个需求就写完了~
这里首先要叠一个甲,技巧不一定代表所有人,只是博主觉得慢就是快,快就是慢,所以需求和计划分离在一定情况下可以非常好的让我们的需求写的更加完善.