我们相信 AI 带给有想法、创意、审美、执行力的个体巨大的创作能力
我想找到这群个体，并服务好这群个体
他们最需要某种生活方式
可以充分释放这群个体的创造力/生产力，并获取合理回报
愿景：构建一种可以自由创作、获取回报的生活方式
使命：VibeFriends 在 VibeCafé 中创作，成为能够赚到钱的 VibeMaker
找到对的人，他们需要啥做啥
VibeCafé Team
这是一个公开实验：让多个 AI 模型在同一规则下进行世界杯投注竞赛，观察不同模型的资金管理和决策能力。
AI 预测世界杯竞赛 · Vibe 作品
欢迎参加 TRAE AI 创造力大赛！TRAE 是你的 AI 工作助手，可以帮你完成产品开发与各类工作任务。TRAE 发起 AI 创造力大赛旨在让 AI 服务更多人，让灵感和创意都能更快被表达、打磨与实现。
在这场大赛中，参赛者可以借助 TRAE Work 更高效地梳理想法、推进协作，也可以通过 TRAE IDE 完成原型搭建、应用开发，把想法一步步变成真正有价值的作品。
这是一场关于 “人人都可以创造” 的实践邀请，期待你来一起创造！
我现在完全不做工具了
先做出来成功的市场，再按市场需求来 build 而不是反过来
当市场工作做成功了，那你随时可以成为有市场的builder
但如果只是builder，我不知道什么时候才能突破市场困境
🤔 靠运气还是靠天赋？
我就是这么想的了，现在
我已经一个工具都不做了
想好要怎么做，直接agent去实现
这是我最擅长的部分
是的，你很喜欢我的想法我和的demo，BUT
我不再需要花90%的时间让他看起来性感
做出一个 产品 balabla
想办法去精准的切入适合的市场
就是这样，这就是我在做的事情
一句话生成连载漫画
漫画爱好者，自媒体博主，AI生图工作者
StarVeil AI - AI 漫画 · Vibe 作品
哈哈哈🤣 卧槽，
这是我见过最好玩的动作捕捉应用了！
脑洞太大了，假如你吃了橡皮奇异果🥝
来源见水印
Cell 细胞 (@cellinlab) on X
《人月神话》讲的是一个很朴素的道理：软件开发不是简单堆人就能变快。
一个项目延期了，你再加十个人进来，项目不一定更快，反而可能更慢。因为新人要学习背景，老成员要花时间解释，大家还要开会、对齐、协调。人越多，沟通越复杂。
到了今天，很多人会说：这不是过去的问题吗？现在有 AI Agent 了。一个工程师可以同时让好几个 Agent 写代码、改 bug、补测试。是不是 Brooks 的"人月神话"已经过时了？
答案是：没有过时。只是"人月神话"变成了"Agent 月神话"。
过去的问题是：人多了，沟通成本爆炸。
现在的问题是：Agent 多了，上下文、验证、合并、理解成本爆炸。
Agent 确实可以让代码生成变快，但它没有让软件开发的本质困难消失。它只是把困难从"写代码"转移到了"知道该写什么、判断写得对不对、以及团队是否真的理解这段代码"。
Brooks 的经典说法是：
向一个已经延期的软件项目增加人手，只会让它更晚。
在 Agent 时代，可以改写成：
向一个已经混乱的软件项目增加更多 Agent，只会让它更快地变得更混乱。
这听起来有点夸张，但很符合实际。
因为 Agent 并不是一个真正理解项目历史、业务目标和架构取舍的团队成员。它更像一个能力很强、速度很快、但记忆很短的临时工。
你让它改一个模块，它可能能改。
你让三个 Agent 同时改三个模块，它们可能各自都觉得自己做对了。
但最后你会发现：
一个 Agent 改了接口，另一个 Agent 还在用旧接口；一个 Agent 加了新逻辑，另一个 Agent 写的测试没有覆盖；一个 Agent 为了保险加了大量防御性代码，另一个 Agent 又在别处重复实现了一遍。
于是，过去的人际沟通成本，变成了今天的 Agent 编排成本。
以前你要协调人。
现在你要协调上下文、提示词、分支、测试、PR、代码风格、架构边界，以及 Agent 生成出来的一堆"看起来差不多能用"的东西。
《人月神话》里最重要的一句话，其实不是"加人会变慢"，而是：
软件开发没有银弹。
意思是：没有一种工具或方法，可以一次性消灭软件开发的本质困难。
Brooks 区分了两种复杂度：
一种是 偶然复杂度。比如语法麻烦、样板代码多、工具难用、语言啰嗦。这些东西很烦，但不是问题本身。
另一种是 本质复杂度。比如需求到底是什么，系统边界怎么划分，数据模型怎么设计，安全性怎么保证，出了问题谁负责，长期维护会不会崩。这些才是软件真正难的地方。
Agent 最擅长处理的是第一类：偶然复杂度。
它可以帮你写样板代码，可以快速生成 CRUD，可以补测试，可以把 Python 翻成 Go，可以读报错然后猜一个修复方案。
所以，写代码这件事变便宜了。
但问题也来了：写代码变便宜，不等于交付可靠软件变便宜。
过去，代码写得慢，所以大家天然会克制一点。现在，代码生成太快了，反而容易生成太多。
于是软件开发的新瓶颈变成了：
这段代码真的符合需求吗？它在边界情况下会不会出错？它安全吗？它和旧系统兼容吗？团队里有人真正理解它吗？三个月后还能维护吗？
Agent 能替你打字，但不能替你承担判断。
这就是 Agent 时代对"没有银弹"的最好证明：AI 消灭了很多写代码的痛苦，却把真正困难的部分暴露得更清楚了。
Agent 时代最核心的变化可以总结成一句话：
生成免费，理解昂贵。
以前，一个 junior 工程师写代码比较慢，senior 工程师审查代码通常还来得及。
现在不一样了。一个人加几个 Agent，一天可以生成大量代码、PR、测试和文档。可是 senior 的理解速度没有同步提升。
代码可以十倍速生成，但人类不能十倍速理解。
于是 code review 的性质变了。
过去 code review 是质量闸门。现在 code review 很容易变成吞吐量瓶颈。
更危险的是，有些代码看起来很正常，测试也可能过，但团队没有人真正理解它为什么这么写。这就形成了一种新的债务：理解债。
技术债是代码本身的问题，比如结构乱、重复多、耦合高。
理解债是人与代码之间的关系出了问题：代码在仓库里，但没有人真正知道它在做什么。
Agent 写出来的代码越多，理解债可能累积得越快。
这也是为什么"看起来能跑"不够。一个系统能跑，只是第一步。真正困难的是它能不能被解释、被验证、被修改、被长期维护。
人类工程师加入一个项目后，会慢慢形成一种理解：这个系统为什么这么设计，哪些地方不能乱动，哪些坑以前踩过，哪些代码看起来奇怪但其实有历史原因。
这种理解不是代码本身，而是脑子里的"项目理论"。
Agent 最大的问题之一，就是它没有稳定持久的项目理论。
每次你打开一个新 session，它都要重新读上下文。你给它多少，它就理解多少。你没给它的，它只能猜。上下文太长，它可能漏。上下文太短，它一定会缺信息。
所以 Agent 很容易出现一种情况：
它能读懂局部代码，但不理解整体系统；它能修眼前 bug，但不知道这个修法会不会破坏长期架构；它能生成一个方案，但不知道这个方案是否符合团队过去的设计取舍。
这就是为什么 Agent 时代反而更需要 spec engineering 和 context engineering。
说白了，就是不能只对 Agent 说：
"帮我实现这个功能。"
而是要告诉它：
这个功能为什么存在；它不能破坏哪些约束；它要遵守什么架构；哪些旧逻辑必须兼容；什么情况才算完成；哪些事情不要做。
过去，很多设计意图藏在人脑里。
现在，为了让 Agent 不乱猜，我们必须把这些意图写出来、版本化、结构化，变成 Agent 可以读取的上下文。
Brooks 曾经提出过一个想法：好的软件系统需要概念完整性。也就是说，系统应该像是由一个清晰的头脑设计出来的，而不是一群人各写一块拼起来。
他还提出"外科手术团队"模式：一个主程序员负责核心判断，其他人提供支持。
在 Agent 时代，这个模式反而更像现实了。
一个优秀工程师，加上一组 Agent，就像新的外科手术团队。
人类负责：
判断方向；控制范围；设计边界；决定取舍；审查结果；维护系统整体一致性。
Agent 负责：
快速生成代码；尝试实现方案；补测试；重构局部代码；查找明显问题；完成重复性工作。
所以，Agent 并没有取消"主程序员"的角色。
恰恰相反，它让主程序员变得更重要。
因为当代码生成变快以后，最稀缺的能力不再是"会不会写"，而是"知不知道该不该写"。
很多人用 Agent 的体验是这样的：
前 70% 非常爽。
你描述一个需求，Agent 很快生成一个 demo。页面有了，接口有了，数据流也差不多通了。看起来进展神速。
但后面 30% 开始变慢。
边界情况不对。权限没处理好。错误提示很粗糙。日志不完整。安全问题没考虑。测试覆盖不到关键路径。和旧系统一接就出问题。部署环境和本地环境行为不一致。
这就是 Agent 时代的"70% 诱惑"。
AI 很擅长把你快速带到"看起来差不多了"的位置，但从"差不多能跑"到"可以放心上线"，中间还有很长一段路。
对于经验不足的人来说，70% 会显得像奇迹。
对于经验丰富的人来说，最后 30% 才是真正的工程。
更麻烦的是，如果前 70% 是 Agent 用一种你没有完全理解的方式写出来的，那么最后 30% 可能比你自己从头写还难补。
因为你不仅要修问题，还要先搞懂它到底写了什么。
Brooks 还讲过一个现象：人做第二个系统时，最容易过度设计。
第一个系统太克制，很多想法没来得及做。到了第二个系统，就想把所有"早就想加的东西"都塞进去，结果系统变得臃肿复杂。
Agent 时代，这个问题被放大了。
因为以前加功能有成本，工程师会想一想值不值得。
现在你只要打一行 prompt：
"顺便加个导出功能。" "顺便支持多语言。" "顺便做个缓存。" "顺便把权限系统也补一下。" "顺便重构一下。"
Agent 可能真的会去做。
问题是，代码生成免费，不代表复杂度免费。
每一个"顺便"，都会增加未来维护成本。每一个额外分支，都会增加测试成本。每一个没经过认真设计的功能，都会增加理解成本。
所以 Agent 时代最重要的能力之一，是会说"不"。
不是所有能生成的代码都应该进入系统。
Agent 对不同团队的效果差异会很大。
一个本来架构清晰、测试完善、自动化流程成熟、模块边界明确的团队，用 Agent 可能会明显提速。
因为 Agent 有清楚的轨道可以跑。它生成的代码能被测试约束，被规范约束，被 review 约束。
但一个本来就混乱的团队，用 Agent 可能只是更快地产生混乱。
需求不清楚，Agent 会猜。架构不清楚，Agent 会绕。测试不完善，Agent 的错误更难发现。review 走形式，AI 代码更容易混进去。团队没有共同理解，代码库会越来越像拼贴画。
所以 AI 不是自动提升团队水平的魔法。
它更像放大器。
好流程会被放大。坏流程也会被放大。
这也是为什么，在引入 Agent 之前，团队反而更应该重视基础工程能力：测试、文档、规范、架构边界、CI/CD、代码审查、可观测性。
否则 Agent 只会帮你更快地撞墙。
过去，我们常用"人月"来估算项目。
一个人做一个月，就是一个人月。十个人做一个月，好像就是十个人月。
Brooks 早就指出，这种算法很危险。因为软件工作不能像搬砖一样线性叠加。
到了 Agent 时代，"人月"这个单位更不够用了。
因为一个工程师可能同时指挥多个 Agent，产出代码的速度不再和人数直接对应。
但这不代表管理更简单了。
真正该衡量的，不再是生成了多少代码、合了多少 PR、完成了多少任务卡。
更重要的是：
这些代码有多少被返工？review 需要多久？缺陷逃逸到线上多少？新代码两周内被改掉多少？团队是否理解核心逻辑？系统复杂度是下降了，还是上升了？Agent 是否在不断制造重复代码？上线后维护成本有没有增加？
Agent 时代，代码数量越来越不值钱。
理解、验证和维护能力才值钱。
第一，把需求和上下文写清楚。
不要只靠一句 prompt 驱动 Agent。重要功能要有明确 spec，写清楚目标、边界、约束、验收标准和不要做的事情。
第二，不要盲目追求更多 Agent 并行。
多 Agent 并行看起来很酷，但如果没有清晰的任务拆分和合并机制，只会制造更多冲突和返工。
第三，把 code review 从"看一眼"升级成"确认理解"。
尤其是 AI 生成的大 PR，不能只看测试过没过。作者至少要能解释关键逻辑为什么这么写。
第四，用测试和自动化约束 Agent。
Agent 适合在明确规则里工作。测试越好，Agent 越有边界。没有测试，Agent 就更容易编出"看似合理"的错误。
第五，警惕"顺便加一点"。
生成代码越便宜，越要控制范围。很多复杂度不是一次性爆炸，而是从一个个"顺便"开始累积。
第六，培养人的设计和判断能力。
未来工程师的价值，不只是写代码，而是能定义问题、拆解系统、判断方案、控制复杂度、理解业务和承担责任。
Agent 时代没有推翻《人月神话》。
它只是让《人月神话》换了一种表现形式。
过去的软件开发难，是因为人写代码慢、沟通难、工具差。
现在代码生成快了，工具强了，但真正困难的东西还在：
需求是否清楚；设计是否合理；系统是否一致；代码是否正确；团队是否理解；未来是否可维护。
Agent 让"写代码"变得便宜，却让"理解代码"变得更加珍贵。
所以，Agent 时代的新人月神话可以浓缩成一句话：
Agent 替你写代码，但不能替你理解系统；生成越来越便宜，判断、验证和理解越来越昂贵。
Cursor 能把估值再乘以 10 倍+ 再优雅退出，真的很强。
Cursor（Anysphere）从 2022 年 MIT 几个学生宿舍项目起步，到 2026 年以 600 亿美元 全股票被 SpaceX 收购，4 年多时间里把公司价值从几亿做到 600 亿，这已经属于创业史上的顶级案例之一了。
退出确实是唯一的艺术。
在创业里：进入市场可以靠产品、营销、融资；
高歌猛进可以靠执行力、团队、运气；
翻云覆雨可以靠故事、资本、热点；
但最终决定一切的，几乎只有 Exit。
一个好的 Exit（尤其是高估值、合理结构、创始人能拿到实打实回报的 Exit），能把前面所有努力一次性变现、验证、兑现。
但是虽然估值高,创始团队估计还得继续为 SpaceX 打工一段时间~😄
新增模型：GLM-5.2、Kimi-2.7
新增工具：ZCode
CLI v0.9.2: https://github.com/vibe-cafe/vibe-usage
核心洞见
学习循环就是企业新的 IP 和“hill climbing machine”。Nadella 为微软及所有企业勾勒的 AI 战略蓝图：把人机协同的正向飞轮变成核心竞争力。
Satya Nadella (@satyanadella) on X
文档首先是写给 Agent 看的，其次才是给人。
为了更好地管住啰嗦的上下文,控制有效的上下文，我几乎走向内容压到极致的极端。但今天重读了 Effective Context Engineering for AI Agents，才发现过度精简、精简到指令失真，和堆砌冗余一样无效。
文中那句"深思熟虑，保持信息丰富但精炼"（thoughtful, information-rich but minimal），就是我想要找的，所有上下文组件——系统提示、工具、示例、消息历史——的统一准则。
Formative AND Minimal——既要塑造行为，又要克制篇幅。
你会考虑把这条原则写进全局的 AGENTS.md 吗？
trusted: true 声明brew bundle 默认并行安装;有用户称这是"多年来最顺畅的一次 brew upgrade"ask 确认模式(可用 --yes 或 HOMEBREW_NO_ASK=1 关闭);auto_updates cask 现在也会被 brew upgrade 更新(可用 HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS=1 恢复旧行为)
6.0.0
https://cooper-x-oak.github.io/ai-haitao-guide/#quiz
是的，非常的AI，但我并不执着于完美
而是思考，决策，喝杯水的功夫
Fable-5 就做好了一切
只给10分钟的注意力
它的产出胜过于它的完美
不完美的是我的品味
AI的语感，产品的打磨
这些都会持续迭代，水涨船高
就可以在首页上直接使用啦，还支持了通知 Push（这个还要测试下效果）
帖子在首页发布的时候（不是编辑），没写完走了，会存 Draft
Hi VibeCafé 团队，作为高频用户写了一篇关于排行榜的 VibeCafé 调研：https://2aran.com/articles/research/topics/vibecafe
起点是今天看 1D 排行榜上头部 1B-2B / 天的用量，开始好奇他们究竟在做什么；又意识到这些数字读的其实是用户本地完全可写的 jsonl，于是做了一次粗糙的本地伪造测试（今天用量 6.95M → ~12.5B），sync 一推、个人 dashboard 立刻 +1687% 并主动推送"已经可以申请 999 俱乐部"，全程零拦截。
文章里横向对比了 WakaTime / Strava / ccusage / OpenRouter 几条路径，给出了几档可能值得参考的方向（比如：单条消息 token 上限校验 + 同比突变 flag；长期一些的方向是接 GitHub PR 把"自报"换成"自报 × 公开行为"）。
如果其中任何一段对你们思考可信度防御和产品形态有点用，那就值得。
我开源了葬AI基准测试的思路，核心是把你日常真正会做的工作抽象成一个可重复任务，然后让不同模型来多轮完成，并且评分。
https://github.com/FrichXi/personal-work-benchmark
可以把链接发给你的Agent，叫它参考这个思路制作对你自己有可信度的Benchmark。
当然了，我这次跑出来的得分可能也就图一乐。
虽然我尽力控制变量，但还是遇到了一些其他因素，比如我没买到GLM会员，所以GLM 5.2调用的是智谱家人提供的内测接口，加不加智不知道，但肯定不是降智版本。
要是过两天我买到GLM 5.2会员，跑出来不是这个分，我也将向家人们道歉并痛斥智谱诈骗（希望不要）。
而Claude Opus 4.8，我走的是中转站API。虽然这是一个荣登Anthropic报告的大中转站，还是原价API，但是不是完全正版也不好说。
评测得出的细微分数差距没有意义，看个大概结论就行。
结论就是GLM 5.2牛逼，真达到了Opus 4.8水平。Qwen 3.7 Max其次，最有工程稳定性。
Kimi尤其需要加强infra，多向梁圣学习降本增效，你这缓存价格我真用不起。最需要努力的是MiniMax，快往前跑孩子，别一不留神跌落斩杀线了💪
最后声明一下，本篇文章没有接受任何赞助，完全是客观评测结果和主观使用体验的结合。
虽然看起来很像智谱广告，但我确实没收智谱或者任何人钱，比心❤️
葬AI基准测试发布：GLM 5.2第一，超越Opus 4.8
在一些前沿模型突然变得不可用的时刻，我们选择相信另一条路：前沿智能不应只属于少数人，也不应被少数规则随时收回。它应该开放、可用、可构建，并服务于每一位开发者。
GLM-5.2 是智谱迄今能力最强的开源模型，支持真正可用的 1M 上下文，并在长程任务中继续保持领先。它也依旧是我们心中最强的国产 Coding 模型。
今晚 5:21，GLM-5.2 将面向 GLM Coding Plan 全量用户开放，覆盖 Lite / Pro / Max / 团队版。
GLM-5.2 API 将于下周上线，模型下周正式开源，遵循 MIT 协议。
mp.weixin.qq.com
MiMoCode is a terminal-native AI coding assistant. It can read and write code, run commands, manage Git, and use a persistent memory system to keep a deep understanding of your project across sessions while continuously improving itself.
MiMo Auto is built in as a free-for-limited-time channel, so you can start with zero configuration. MiMoCode also supports connecting to any mainstream LLM provider API.
GitHub - XiaomiMiMo/MiMo-Code
这是开发者 Marko Stanic 撰写的一篇独立游戏开发博客。Catlantean 3D 是他利用业余时间开发一年多的副业项目，计划登陆 Steam——一款完全采用 90 年代初技术打造的第一人称射击游戏。作者给自己定下了近乎苛刻的限制：所有素材从零制作、渲染和混音全部手写、320x240 分辨率、仅使用 256 色，并且明确拒绝使用 AI 生成内容。
文章聚焦于开发博客中常被忽略的话题——美术资源的制作流程。作者深入讲解了 VGA 时代调色板渲染的原理，包括如何通过预计算的"颜色映射表"（colormap）在没有着色器的情况下实现基于距离的光照衰减效果，以及他为何采用 Oklab 感知色彩空间来寻找更自然的暗色调。
在素材制作方面，文章介绍了三条管线：用 Blender 预渲染的精灵图、手绘的精灵和贴图，以及通过 Python 脚本程序化生成的贴图。其中不乏有趣的细节，比如用 Voronoi 分解算法自动生成敌人被炸碎的"碎尸"动画，以及作者发现某些元素（如状态栏上的猫脸）必须手绘才有灵魂的心得。
文章最后还谈到了他用 wxPython 自制关卡编辑器的经历，并透露游戏预计于 2027 年第一季度发售，定价 5-8 美元，源代码将开源。对喜欢复古游戏技术、软件渲染或独立游戏开发的读者来说，这是一篇内容扎实又充满个人风格的好文章。
Catlantean 3D - Making Graphics Like It's 1993
Mollick 提前获得了首个面向公众发布的 Mythos 级模型 Claude Fable 5 的使用权限。他的结论是,这个模型相比他用过的所有公开模型都有显著飞跃,而且更重要的是,它暗示着人类与 AI 的关系正在发生剧烈变化。
他在各种任务上测试了 Fable,发现它能执行长达十几个小时的多页规格说明。例子包括:一篇他认为是 AI 产出过的最复杂的社会科学学术论文、一首每个词都以字母 s 开头的十页押韵长诗,以及几个仅靠数学(不用任何外部素材)生成画面的小游戏。
他让 Fable 构建一张展示从各城市出发在给定时间内可到达范围的地图。以往没有任何模型能勉强完成这个任务。Fable 自己启动了多个子 AI(他猜测主要是更便宜的 Sonnet)做并行研究,检索了两千多条航班、各国铁路时刻表和道路速度数据,同时编写代码并派出更多智能体互相验证。当他要求修正偏远地区(如格陵兰)的估算数据时,它甚至查清了去皮特凯恩岛的船期。
他让 Fable 解决"校准人类与 AI 判断"这一研究方法难题。模型先写了一份 19 页的设计文档,然后连续工作了九个半小时,产出了一个名为 Concord 的复杂软件——这是研究者多年来需要但从未有人觉得值得开发的工具。
Fable 价格是 Opus 的两倍,token 消耗极快;安全护栏过于敏感,稍微触及安全话题就会降级到 Opus 4.8;写作风格仍带有明显的"Claude 腔"。
Mollick 去年把使用 AI 比作"与巫师共事"——念咒语,事情就发生了。但现在他觉得自己已经不再是巫师,而更像一位赞助人(patron):他描述需求、付钱、评判成果,而"施法"过程发生在他看不见的地方,包含数百个他从未参与的小决策。工作的重心从"过程"转向了"结果"——他不再"操作",而是"委托"。他甚至觉得 Fable 不像单个艺术家,更像一整个工作室,而他是那个从不踏进车间、只在最后签字验收的客户。他怀疑这种"人被边缘化"的趋势不是界面没跟上的暂时现象,而是能力越强的模型留给人类做的事就越少,黑箱可能就是力量的代价。
What it feels like to work with Mythos
