2025年第31周 X 推文精选

@HiTw93 好的AI代理依赖“上下文工程”：智能体的“上下文”设计，比模型本身更决定成败。如何保留、使用和演化上下文，就是塑造AI行为、效率与可成长性的“土壤”。

高效“模式识别”优于死记硬背：无论模型如何强大，“反馈循环”才是进步的关键——快速试错+保留经验 (包括失败!)，让智能体持续进化，不断自我修正。

硬核又软萌！假如编程语言有自己的毛绒挂件🤣

一直觉得技术圈也需要更多好玩、可爱的周边。

昨天看到了宝藏同学阿真的分享，很有启发🎉。

于是动手搞了一套，评论区有提示词👇 https://t.co/kmSLJTjoSM

Vibe Coding 黑客松投票倒计时！发个产品视频介绍一下，欢迎大家PC端体验🤣 @Jackywine

投票通道，19号：https://t.co/nCDduKKtYK https://t.co/pTbRsXddOR

又有人搞了一个 Claude Code 镜像服务，搞活动？

最近用了不下5个镜像站，现在做镜像站的成本很低吗？VPS All In One？短期能回本吗？针对 CC 这个月的订阅策略，不知道是否影响账号池的成本💰 https://t.co/OyxBEmDBuh

别再逐行 Review AI 代码了？Anthropic 研究员揭示的「Vibe 编程」新范式。

今天看完了 Anthropic 研究员 Erik Schulntz 关于 《在生产环境中进行 Vibe 编程》 的分享。

有几个观点值得分享下👇 https://t.co/5YNhA5xlJV

什么是真正的「Vibe 编程」？

很多人以为，大量使用 AI 生成代码就是 Vibe 编程。比如用 Copilot 或者 Cursor 写了大部分代码。但 Erik 指出，这不完全对。

当你还处于和模型进行高频、紧密的反馈循环时，你并没有真正进入 Vibe 的状态。

Erik 分享了一个惊人的数据：AI 能独立完成的任务时长，每 7 个月就翻一倍。

今天它能帮你写一个花一小时的函数，你还能 review。

明年呢？后年呢？当 AI 能在几分钟内生成一个普通工程师一周的工作量时，你还怎么去逐行检查？

我们如果想利用好这个指数级增长的红利，就必须找到一种方法，去负责任地“放手”。

这就像当年编译器刚出现的时候。最早那批程序员肯定也不信任编译器，他们会去读编译后的汇编代码，确保跟自己手写的一样好。

但很快，系统变得越来越复杂，没人再这么干了。

我们学会了信任这个工具。

适应一个新角色：AI 的产品经理

Erik 提出了一个让我茅塞顿开的思维模型：

我们可以忘记代码的存在，但绝不能忘记产品的存在。

这其实不是一个新问题。一个公司的 CTO 不可能是所有技术领域的专家，他怎么管理手下的数据库大神？一个产品经理看不懂所有代码，他怎么验收一个复杂的功能？

答案是，他们都在自己能理解的抽象层面上进行验证。

CTO 会设定验收测试 (Acceptance Tests) 来确保功能符合预期。

PM 会亲自使用产品，确保用户体验和设计稿一致 。

CEO 会抽查他能理解的关键数据和财务切片，来建立对整体模型的信心。

所以，我们的角色需要转变。不要再把自己当成一个码农，要把自己当成 AI 的产品经理。

别总问 Claude 能为你做什么，要问问你能为 Claude 做什么。

在你让 AI “开工”之前，花 15-20 分钟像给一个新同事做入职培训一样，把项目的背景、需求、约束、代码库里的相关模式、需要注意的地方，一次性喂给它

从哪里开始？先拿“树叶”开刀

当然，这个过程有个巨大的障碍：技术债 (Tech Debt)。这是目前唯一一个除了阅读代码，几乎无法在外部验证的东西 。

那怎么办？Erik 给出了一个非常聪明的实践策略：从“叶子节点” (Leaf Nodes) 开始你的 Vibe 编程 。

在这些“叶子”上，即使 AI 写的代码有点技术债，也无伤大雅。

因为它不会影响到你系统的核心“树干”和“分支”。

我们人类工程师，应该把精力聚焦在核心架构的稳定、可扩展和优雅上，而把大量的、一次性的、边缘的开发工作，放心交给 AI 去“Vibe”。

今天的《Vibe Coding 迷你黑客松_奇思妙想秀-WaytoAGI晚8点共学》见到了好多有创意的作品！感谢优秀主持人！感谢各位大佬的精彩点评！感恩主办方和各位组织者，期待下一届😂 https://t.co/fJsz3xWFrt