@
xiaket 我认为还好,因为网页版其实把文件直接上传进去就好了。这个是因为之前的这个 GPT 网页版是没有办法直接上传文件的时候,要手动复制代码的话比较麻烦。但是我现在如果要给它传这个上下文,我先在本地新建一个临时文件。然后我把我想改的,或者说具体范围的,因为我的项目的代码拆的比较的散,我是 Go 语言去写,然后呢我一个 Go 文件可能就只有 30~100 行。所以我其实从它的这个文件选取器里面去选这个文件,然后呢,一个上下文传个五六个文件,再说一段这个话,然后让它去给我做这个手术刀的修改。之后呢,它再把这个几个文件直接发回给我,我就直接去替换。然后呢,这个过程里面,我这个 GitHub 的这个仓库能够追踪这个 diff 。我习惯每一个小版本一个小改动就推一次这个仓库,这样的话我每一个 diff 之间都特别清楚,而且可以跨好几个 diff 去拉一个特别长的变更出来,很方便再发回这个 AI 里面,让它去这个再次消化,然后再次重新去对齐这个边界,跟我的这个边界去对齐
怎么说呢?实际上吧,这种独立开发的这种项目,我觉得其实在拼的不是写代码有多快。如果是要工作的话,或者说是需要这个短时间做大量的项目,把这个做项目当做是一种活来去做的话,我觉得像我这样的话可能效率就比较的低了。但是呢,不同的这个项目类型嘛,像是这种已经做了五六年的这种独立开发的个人项目,其实已经过了需要快速开发,需要这个效率的这个时候了。我现在每一天花在想,还有花在这个收集这个用户反馈,决定以后要写什么的这个时间,和我实际上按我的这种办法去写这个新代码的时间的比例,可能想和收集已经占到 95%更多了。
我一个月 30 天,可能就只有一两天熬熬夜写个代码。但这个代码是可能是我要剩下 25 天一直在想的。我这 25 天在做的就是,把边界梳理清楚,把这个设计闭环到没有再需要改的地方,把每一个细节都对齐到 AI 不会自己发挥的这种细节程度。然后在我就是我的这个项目还没有落到代码上的时候,我不知道怎么样去描述,就是在在我脑海里面,它是一个想法,它是一堆边界,它是一堆流程组成的那个状态的时候。
在那个状态我是可以对它进行 debug 的。我会不断地在这个构思的这个范围内去不断地去推它,不断地去模拟去运行它。然后呢,不断地把这种模拟的状态和人去,和用户去讨论。然后我就可以在没有代码的时候迭代我的功能。等到我把我能够想到的,就是这个功能可能要去新增的特性,比如说它可能 UX 上面要做得更好一点。它现在的 UX 的话,虽然它代码没写出来,但是呢,还有可以提升可以优化的地方。
我就会在写代码之前,我就去提前地去规划它。等到最后我花了 20 多天,我把它规划到很细的时候,我花一天的时间把它写出来。最后往往我写出来的这个代码,后期是很少需要去再去改代码的,因为我已经把它可能写出来以后可能会遇到的错误,可能会遇到的 bug 和问题,在还没有落成代码之前,我就已经提前能够把它想到了。最后我在提示词里面,还有我的这个设计里面,就已经把出现错误的这种,出现 bug 的这种,给它约束掉了。我很少看到有朋友,或者说有人像我这样子写代码。但是这几年的体验下来,就是这没有让我的项目更新变得很慢,相反,它让我的项目很少去改这个 bug
我觉得有的时候吧,这种人肉 harness ,短期看是慢,但是呢,长期看,可能还反而在某些方面能够省下一些时间。我觉得你说的一点很有道理,就是你说我如果能够忍住不去短时间增加大量代码。其实我觉得如果我用 CodeX 和这个克劳德,工具如果太方便了的话,人会天然的忍不住想要去大量的去增加代码。如果本身写代码就是有一定的门槛的,有一定的成本的,可能反而会约束项目的开发者能够更加内化的、更节制的去规划,去更多的思考。因为我想在生活里面,很多事情门槛也是有价值的,就好比去收集 CD 黑胶唱片,其实门槛就比较高。不仅仅是要去专门的这个唱片店,而且呢还要自己去维护一套听音乐的这个设备,音响。那可能一个人想要去听音乐的时候,如果他有这个这样的这种姑且算是仪式感吧,那他可能会对自己想要听什么音乐,用什么设备去听,他会想的更多一点,可能这个音乐就相比在手机上刷汽水音乐,要来的更深刻一点,
不过话说回来,这还是依然是一个个人选择的问题,每个人都可以自己去自由的选择自己喜欢的听音乐的方式。那么写代码也是一样,我觉得挺好的。其实现在能够看到写代码也开始有越来越多的不一样的写的方式。有的人还是喜欢复古手写,有的人开始去全部去 Vibe Coding ,有的人在这个 AI 写代码的同时呢,自己还要掌控这个项目的架构,还有的人开始去构造这个循环。Looping ,给 AI 设置目标,用目标去驱动代码开发的迭代。我觉得这些其实是可以同时存在的,不同的这种编程的风格