wwwgoubuli发布的内容- news.news·换个方式看新闻|AI看新闻、实时追踪事件后续

wwwgoubuli

统计数据

13

文章

0

粉丝

0

获赞

12

阅读

1天前

退订了 cursor，trae ，copilit 等所有AI coding IDE。短期内除了评测，把玩，学习借鉴，其他情况下干活应该只考虑 cc 了。也想过这个问题，既然现在最顶级的那些模型，大家其实都有办法用，为什么最终呈现出来的效果却还是差那么多。写提示词，我相信大家的能力不会差，实在不行抄都可以。然后Tool calling 这件事情上，我也相信不会有太大的差距，有反而就奇怪了。暂时能想到的答案只剩一个，就是以前别人提过的，一个是靠提问数量来挣钱，在token的消耗上是有限的，另外一个是近乎奢侈的挥霍token。从表象上看，答案不止这一个，但深究下来，好像还真的都指向了他。我能力有限，我找不出其他答案来解释为什么大家同样的模型，同样的提示词，同样的工具调用，效果出来就是不一样。

AI编程工具激战：Claude Code、Gemini Cli崛起· 372 条信息

#AI编程：Kimi搅局，Claude封号，群雄逐鹿· 514 条信息

#AI coding IDE #模型效果差异 #Token消耗 #CC #编程工具评测

2天前

去年离职后，很快进入了焦虑期，也想过要不要做自媒体博主，当时有一点小小的努力和尝试。做不来，也做不起来，固然是我能力有限，但更重要的是，我发现我自己根本就不想往这个上面投入精力。我在互联网上干的熟练的事，无非就是工作、学习、思考，得出一些想法，发出来和人交流，再去实践。当然，也有只靠这个闭环就能够把自媒体做起来的，思考与输出是相辅相成的，我很佩服这样的人，但我的工作性质做不到这一点。后来就放弃了。我想要不然我就做另外一种人吧，在互联网上也积极发声，让自己的观点言之有物，最后成为那个会被大V们关注的人，我的言论会被他们讨论、传播、转载，那也算是某种程度上实现的一种媒体吧。目前看来，初步做到了。一方面，我目前的生活状态可以让我保持还算良好的实践与司法的杰作，还不用去操心做自媒体不得不面对的平台监管规则，然后因为我很认真的思考，再给出想法，这些都是我实践中得出来的一手的结论，算是言之有物，得到一些认可，意外的直接认识了不少大V，产生了私交。甚至连变现都变得比我想象的要容易一些了。人啊，果然还是应该在自己擅长的事情上发力。

#离职焦虑 #自媒体尝试 #互联网发声 #观点交流 #擅长领域

6天前

最近的习惯在 Next.js 里是，放弃 MVC ，压扁层级。 common / utils / db 不算，往上就一层 actions。也没那么多角度考虑，就 actions 里创建根据业务的子目录，把 schema 结构和需求丢给 AI，一个需求一个文件，给我生成。大量冗余，复用极少。但初期起项目超快。抽象？复用？后面会慢慢搞，因为现在有充足的时间了。但在 vibe 的时候，扁平的一级结构，直接串联 client 侧的需求和 db 操作，就一个 action，干净利落。冗余重复没关系，AI 不关心，而且这种结构下，明显 vibe 的成功率高了好多。至于重构，反而变的可行了起来。以前我们说以后重构，基本是没有这个以后的。但这种形态下，我确实可以抽出时间来，一点点修改，慢慢倒腾。如果这个项目起都没起得来，不值得重构，那也没关系，起码我有一个层级简单，脉络清晰，每个文件给 AI 看都上下文完整，职责单一的项目架构在。真诚推荐。 vibe 有自己的最佳实践，尊重传统软件工程的同时，也要结合 AI 喜欢的方式来。

#Next.js #MVC放弃 #AI辅助开发 #快速启动项目 #扁平架构

1周前

有个人给了我 trae 的邀请码，测下 solo 模式。几天过去了，kol 们早吹完了。该我来喷了。 1 solo 模式并不算好用。愿景不错，实现全流程闭环。几个项目综合体验下来，和别家半斤八两。不过这不是 trae 的锅。而是目前这个阶段，全地球，没有任何一个模型+产品，能实现一个基本靠谱的闭环。一个都没有。有特例，但那是用的人牛逼，不是产品。 2 但这个新 solo 模式吧，印证了字节的产品力是真的强。那个 solo 模式吧 chat 抬到主位置，右边像是“artifact”一样。虽然不是我理想中的那个样子，但确实是同类产品里，可能是最合理的一种布局模式了。激进又合理。也好看。但这些“artifact”其实还是一种 debug ，而不是最终产物，现在混在一起，还是有点别扭。 3 solo 的效果如何？第一条说了一半了，一般，和别人家不相上下。人不行的话还是用不好。不过有个特点，它特别善于查漏，但不善于补缺。如果不说 solo 模式，就 ide 模式下，我得说，这一版其实很好了。使用时候的心流有点接近 windsurf 的 flow 的意思了。不想吹捧，但产品里，综合体验看来，trae 就是国内第一。同行们还是比较不争气的。北京目前遥遥领先杭州和深圳。

#Trae #SOLO模式 #字节产品力 #IDE模式 #国内第一

2周前

看了几个非程序员的纯 vibe coding 作品，尤其是我在群里是看过他们的吐槽还有探索的过程的。降低了入门的门槛已经是老生常谈了，我也不想多说，AI的效率和速度也不用提，但有一个有趣的现象。和AI一起合作到最后，每个人的表达都更清晰了，对自己做的作品的思考明显比初期要全面的多。以前和人类协作的时候，因为巨大的成本问题，我们不得不在开始动手做之前就正常先去battle，来避免后续更大的成本投入和时间浪费。但AI不一样，极低的成本和极快的速度，还有他总是好好好行行行对对对的习惯，让你可以非常轻易的拿到一个demo。但和很多人一开始想的我在一个demo基础上再去优化改进不太一样的是，基本上还没轮到你去优化呢，他已经暴露了大量的问题出现。事实上就形成了一种倒逼，你不得不去重新梳理自己的想法，重新用更明确更清晰的逻辑来讲给他听你的一厢情愿，以前是别人直接反驳你，现在是AI拿结果赤裸裸的来打脸。你没有办法再继续含糊下去。挺好，我感觉AI可以让行业内还在做的人的综合能力又能普遍提升一次。

2周前

我是一个完整的应用都没有，不过几个现存项目都有大量的 AI 参与。别人 vibe 出来的东西。怎么说呢…… 基本没什么有用的。不是否定降低门槛低的价值，但可能很多人没意识到—— AI 已经很强了，看起来可以参与非常多的流程。但 vibe 出来的东西，只是代码。碰巧可以执行，可以构成一个应用的一部分。但一个软件应用，代码从来只是一部分。我看很多人是忘了这一点。 AI 能写的出来，能构建，能部署，就完事了。当然，确实也能用，也确实有人需要。也确实不是所有的应用都要做的很大，很复杂，简单和轻量的东西也有人需要。但这和“复杂应用”本来也不是非黑即白的关系。 AI 写出来的东西，就只是代码，和看起来说的头头是道的文档，流程。有很多人会自比为产品经理，PUA AI 写东西。这个比喻我觉得不是很恰当。产品经理们以往确实有时候会提出匪夷所思的想法，但起码会多少对自己想要的东西有个一二。因为程序员会反驳你，和你 argue ，给你解释，你们吵来吵去的过程里，这个东西是什么，会越来越清晰。但 AI 不会，AI 是你作为“产品经理”能遇到的脾气最好，最吃苦耐劳的“程序员”了（加引号因为它不是程序员，它只是写代码的，程序员的活儿只有一小部分是写代码）。你多离谱的需求，它都尽力实现。事实上你命令下的越多，写的越快，你反而离你想要的那个东西，可能离得越来越远。表面上看起来很像，但它是个你越来越看不清的东西。不只是代码层面的看不清，而是它的运作机制，流程，你都未必清晰。你委托出去了思考流程，你委托的越多，你对产品的思考就越少。你以为你在思考，你很努力，其实那是幻觉。 vibe coding 的价值，是给会的人助力。给不会的人以入场的机会。但对结果——这个东西能不能成，没什么影响。能不能成，还是 no pain no gain 那套。你必须从委派给 AI 的任务里，努力的抢回一些东西，自己拒绝，思考，然后不要心疼自己花掉的 token，宁可推倒重来，反复的折腾自己，你才可能最后得到一个有用的东西。所以我是不相信任何人——无论他是 AI 大厂的意见领袖，编程大师，网络 KOL ，对 vibe 的吹捧的。这和技术没什么关系。你的东西得你自己做，才是你的。这个做，不是说你非要自己写代码。得你自己深入的参与，痛苦的理解每个你知道不知道的点。每个你试图模糊过去，觉得表现一样就行的东西，都不属于你。你根本不知道你得到的是什么。事后补救也是不存在的。所有的人，每一个会编程的人都说过同样的话：以后再改进。再优化。再看细节。然后每个人也就到此为止了。你也不会例外。这就是今天我要泼的冷水。好了，继续 vibe 去了。

3周前

其实吧，workflow 才是 agent 的高级和成熟形式。不要想着拿现在已有的workflow和agent来对比，都还处在不成熟的阶段。我描述的不是目前已有的场景。这两者也没有什么取代关系，谁比谁更高级，但从原本的定义，以及我们人类解决问题的方式来讲，workflow就是我们以agent的形式横冲直撞，吃过无数亏总结出来的高效的面对一些特定问题的快速解法。还是那句话，不要拿现有的我们人类编排的那些东西去看待未来的workflow，从复杂度和能力上都不是一个量级的东西。我说的 workflow 是业务的高效解法，近乎最优解，无需试探，已经成熟的业务流程。而这本来就是 agent 试图达到的目的。也可以理解成，未来我们仍然需要专家系统，只不过他不再是我们需要手动精心的编排才能达到。我们很可能让大量的代理自己跑出这样的解法，并把这个解法固定下来，成为一个确定的工作流。这个世界上的问题，有很多答案也是开放式的，但这并不影响他们中间有一些固定的范式、高效的解法，这些就是我理解的 workflow。

1个月前

虽然。 claude code 很强，很好用。但我观察了几个小时一直读。它和前代们一样。 80% 以上的时间做的是无用功。纯纯的力大砖飞。我知道有 plan / todo 的加持。我知道它是最能出成果的，过程和结果并不冲突。我说的只是过程。和前代们还是一样的。我有 rule，有指定，我还算比较熟悉技巧的。但不改变它本质上还是愚蠢的暴力突进。

AI编程工具激战：Claude Code、Gemini Cli崛起· 372 条信息

#AI编程：Kimi搅局，Claude封号，群雄逐鹿· 514 条信息

#Claude #代码能力强 #效率低 #暴力破解 #有待改进

1个月前

说实话我已经有接近半年没有研究过提示词工程了。可见的未来大概率也是放弃的。不是不写提示词，前两年每天卷出来的经验，一部分已经内化到我的提问方式里了。我随便打打字，只要知道面对的是 AI ，大概能自然而然的知道怎么写——哪怕每次表达方式不一样。似乎对那种核心有了一种玄妙的感受。另外一个原因是确实不那么重要。 LLM 的纠错能力很强。虽然你的初始引导可能还会把它带往不同的方向，但我确实能在我打完字发出去后，大概就知道它会跑到哪个区域，大差不差。如果我现在去参加 AI 产品经理的面试，大致是答不上来怎么写提示词好的。它越来越成为了我的个人感受，别人在把玄学提炼成为可复现的系统工程的时候，我反而在反过来把工程丢掉，走玄学道路了。

1个月前

说实话当我接受了 LLM 无状态这个“第一性原理”之后，并且我也练出了相对熟练的技能后：我是不需要且反对记录我的行为的，我不喜欢 memory 。工作中构造上下文我自有方法。生活中你个 AI 最好不要知道我是谁。

#无状态 #LLM #记忆 #上下文 #AI隐私

1个月前

菜才有坑。

1个月前

很久没聊 RAG 了，随便说点。 RAG 里的分块技术，某种程度上看起来确实显得越来越过时了。不是说完全抛弃不要，只是分块带来的弊端越来越明显，多高超的技巧都救不回来“信息完整度”的缺失。当然总有上下文窗口不够的情况，完整的大型文档丢进去，确实吃不下怎么办？凉拌。你就用最简单粗暴的方法，按长度来，丢过去做点预处理，总结，然后差不多行了。这种方法下，切割的问题依然存在，会有把完整信息切错乱，让上下文不精准的可能。但首先，影响真的不大。这种方法会有信息折损，但不会比你以前精妙的各种分块技术，各种组合，效果差到哪里去。不同的场景下会有差别，肯定有赶不上传统方案的时候，但——无伤大雅。以前的 RAG 到底做到了个什么水准，那么多雕花，最后的成果如何，大家心里都有数。其次，你要相信今天的模型。论聪明程度，这个意义不大。但论长上下文的处理，对超长文本的高维关系分析，人类已经连 LLM 的尾灯都看不到了。不会差到哪里去的。节省下来的时间力气，都足以在其他方面做很多新的探索。比如 PDF 不做 OCR，不分块，而是直接转图片给多模态。也不是说传统 chunk 技术就有什么问题，那里面其实已经诞生了很多可靠的实践，可以对不少效果兜底。但大多数情况下，做的就还是雕花的工作。原始数据有多脏，各种格式有多奇葩，各位应该多少有耳闻。雕花的事，少干点，有这技术就行，没必要天天弄。你看 Apple 刚 WWDC 上端出来的顶级雕花，真的一言难尽。

#RAG #分块技术 #信息完整度 #上下文窗口 #预处理 #切割问题

1年前

冷知识：nextjs 诞生比微信小程序还要早