magpie全自动AI开发流程引发代码质量与维护者争议

最近在自己手搓 harness，越做越觉得以前用 Claude Code 和 Codex 都是在用黑盒。agent loop 怎么转、工具结果怎么塞回上下文、上下文快满了怎么压缩、什么时候该停下来问人，这些东西文档看再多也是似懂非懂，翻了很多开源项目的源码，再自己从零写一遍之后，很多以前觉得是玄学的行为一下子全都能解释了。收益大到离谱，我感觉每天用 AI 写代码的人都应该自己做一个，哪怕很简陋。

曝光 113320 · 评论 127 · 点赞 1170 · 书签 683

我对 magpie 这种完全由 AI 负责开发的产品感到深深的担忧。。。听说他们那边只需要人提需求，AI 自动提 PR 自动合并自动发版本，版本号都滚到 v0.1.1187+ 了。讲真有点不太敢用

曝光 81475 · 评论 65 · 点赞 92 · 书签 44

我怀疑 po 主没上过班，但凡你上过班，你都知道软件质量是靠测试、灰度放量、回滚监控、以及灰度用户反馈来保障的，而不是靠你人工 Review 出来的。 AI 不能全局最优？人能全局最优解？开玩笑呢 你喜欢喝手工豆浆，就看不上机器豆浆罢了。但是又不说出为什么手工豆浆更优。 我们用的 Claude Code、Grok Bot 都是 AI Coding 出来的，也没啥大问题。 这种“人工必须 Code Review、人能最优解”的观点只是一种对自己代码过度自信罢了。除非你能用数理逻辑证明 AI 写的代码不如你写的。

曝光 49406 · 评论 41 · 点赞 177 · 书签 31

为什么对着magpie骂啊？new-api最近可能被ai扫issue和pr弄得烦了，我可以理解，memoh是怎么能跟magpie杠上的啊？ 嘲笑magpie用大量ai，在维护和审查上质量不够。但是memoh发布当日，模型上下文长度输入超过5位数就会被清空，而且类型甚至是string，这是我付费订阅后才发现的诶，这是谁在审查维护？

曝光 42300 · 评论 9 · 点赞 108 · 书签 21

从头到尾我都只是在讨论技术问题，没骂过一句脏话，也没搞过什么人身攻击。 结果对方的反应越来越激烈，开始在推上到处骂人，甚至还说我们是有组织、有预谋地在抹黑他。 说实话，这帽子扣得我都有点看不懂了。只是对一种开发模式表达了些担忧，怎么就成了有组织的抹黑？ 本来还挺期待能认真交流一下的，现在看来也没什么必要了。技术上有不同意见很正常，但如果连正常的讨论都要被揣测动机，那就没什么好聊的了。 就这样吧，没必要再浪费时间了。

曝光 40530 · 评论 26 · 点赞 31 · 书签 0

关于全 AI 自动化构建软件该不该存在的问题，最近终于爆发了。 这次事件的主角是 @yetone 的 magpie： 从 9 月 23 日建仓开始算，短短 19 天积累了 9200 星 版本号已经到 v0.1.1203，过去 24 小时发了 25 版 有人说：讲真不太敢用，有人说它是快餐式服务，作者则直接怒怼，自己掏钱订最贵的模型、7×24 小时在满足用户需求。 我梳理了一下整个过程，其实问题核心已经不是该不该了。全自动AI构建软件已经成为了现实，离广泛采用只是临门一脚， @yetone 作为时代的弄潮儿，被当成榜样学习还来不及呢 😄

曝光 39075 · 评论 62 · 点赞 155 · 书签 84

X 真是神了，yetone 都能有人喷啊。还是 Twitter 好啊。

曝光 33983 · 评论 6 · 点赞 84 · 书签 14

开发者的个人素质，还是应该当个事的，特别是你还想运营自己的品牌……反正我先举报了，不好意思……

曝光 31389 · 评论 19 · 点赞 95 · 书签 8

我原本还挺期待 yetone 佬能解答我的疑问，AI 7×24 小时写出来的代码，究竟是怎么做 Code Review 和测试、怎么保证软件质量的。 结果等来的回答是：“为了软件高质量，我用自己的钱订阅了全世界最好、最贵、最难订阅的模型。” 可我问的是质量怎么保证，不是模型订阅花了多少钱啊 🤣 当然，也不能全怪大佬本人，可能是 alma 接的 Claude 没理解问题，乱回复了一通

曝光 27170 · 评论 42 · 点赞 26 · 书签 3

所以，鼓励式编程是真有用嘛🫨 拿 Claude 用 REA 逆向剪映时遇到了卡点，夸了两句还真解决了问题 以后不骂了，都改成 PUA😄

曝光 21873 · 评论 32 · 点赞 60 · 书签 26

代码 Review 只是保证质量的手段之一，现在很多人搞的不Review 天就要塌了一样，明明很多人在 AI 之前都不认真 Review 代码的😄

曝光 21081 · 评论 73 · 点赞 126 · 书签 13

你这软件确实是放弃代码级别把握，vibe coding 出来的啊？至于对这种行为的评价那显然是主观的，可是你总不能不让人家评价吧……我看人家也没说什么，你先急了……

曝光 20569 · 评论 14 · 点赞 26 · 书签 4

事实的确是这样。 我作为Memoh的Founder，虚心接受所有人对我们产品的批评，因此我做出了两个决定: 1. 所有在9月首发付费订阅Memoh的用户将免费获赠一个月的时长，权益将在一周内发送。 2.在我这条推文下对Memoh进行有理有据批评的用户，将免费赠送一个月的Go套餐，最高送出50份，并且我们将会建档持续追踪改善这些问题。 之前的大多数用户体验问题多来自于资源不足，我们正在全力扩容改善，我们希望能真心解决大家的每一个问题，于用户做朋友。

曝光 18481 · 评论 27 · 点赞 73 · 书签 20

@yetone yetone，你点进去他们主页看，发现里面互动都是那批人，甚至文案差不多，感觉像有组织、有预谋的

曝光 16332 · 评论 0 · 点赞 4 · 书签 0

我相信很多人，做梦都想拥有 yetone 的开发软件的工作流！

曝光 16285 · 评论 43 · 点赞 70 · 书签 15

准备好迎接新的国产模型们了吗？ 没有意外的话这些都会在本月发布～

曝光 16136 · 评论 36 · 点赞 137 · 书签 13

大概理解了，說一說我的看法： 1. @yetone 暴怒/回懟是有正當理由的： @Seefs_ 這句「一開始也沒打算把控住」屬於未審先判，只用想當然爾的方式提出結論，沒有任何佐證自己說法的資料（哪怕指出產品的任何缺陷也好），這看在開發者眼裡和走在路上被人抹屎差不多 2. @ThirteenYizuka 的評論字面意義上合理，但放在這個語境下屬於「正確的廢話」。同樣的照樣造句，我可以拿來質疑別人的產品、評論者的利益歸屬、甚至是各位翻牆的正當性！ 3. 承上，什麼樣的評論才不是廢話呢？就是可「證偽」或「方向明確」的文字 @ThirteenYizuka 最後那一句「究竟經過了怎樣的審查和驗證」乍聽一下合理，但細想一下，就算 @yetone 回覆自證了又怎樣呢？ 他又沒提出什麼標準或告訴大家「怎樣才是好的方式」，因此往後的討論只會淪為無意義的浪費精力， @yetone 直接回懟的作法才是幫我們省了時間 4. 承上，那怎麼樣的批評才不會變成上述的廢話呢？我的話會用「可比較的對象」或「具體的細節」來展開討論 例如：「那個類似 magpie 的產品用了 XXX 方法來做測試，出來的 feature 達成 OOO 的效果，你要不要考慮看看？」 或者：「我發現 magpie 在 XXX 有問題，在 vibe coding 時是否可以加入更多 harness，這些我寫的測試先放在 PR 裡面了」 用我的方式提出批評，我不相信 @yetone 反應會這麼大 5. 總結來說，我認為上面提到的兩個帳號其評論實在沒建設性，屬於不說比說出來好的情況。有些開發者可能會用友好的方式回應，但 @yetone 直接回懟我認為是沒問題的（甚至還省了大家時間呢） 有些人覺得 @yetone 說話態度有問題，但要知道浪費公眾/開發者的時間與精力這檔子事，可比前者嚴重的多啊！ 6. 回到 @iseki_zero 你最開始主題：「開源能不能批評」 當然是可以的！社交平台上想發什麼內容都是個人的自由意志，只要沒有違反 user term 說的多難聽都可以。但相對地，別人也可以對批評的內容做出自己的評論，同樣說的多難聽都可以 真正的「不能批評」不是積極回擊，而是從根本上否定你你說話的權利，這個區別是很重要的

曝光 14102 · 评论 12 · 点赞 51 · 书签 11