字节豆包大瓜事件始末

#豆包大瓜 #吃瓜 #llm负责人

智谱AI发布全新GLM系列模型，同步开源、API调用和z.ai体验三大途径。

开源32B/9B系列涵盖基座、推理、沉思模型，全部采用MIT协议可商用。其中，推理模型GLM-Z1-32B-0414性能媲美DeepSeek-R1，32B参数量比肩671B大模型，速度高达200tokens/秒！同步登陆智谱MaaS平台的API服务分极速版、高性价比版（仅为DeepSeek-R1价格的1/30）和免费版。

即日起登录全新域名z.ai即可免费体验，包括代码生成、函数调用和Deep Research等多项能力。速度快、价格优、能力强，智谱新一代模型全面突破！

https://mp.weixin.qq.com/s/eKHC8Tfvu_9P_BvAcHKV6A?scene=1

#GLM新品发布#

AI 六小龙之一的智谱准备上市了

OpenAI发布新AI推理模型o3与o4-mini

OpenAI推出两款全新AI推理模型o3与o4-mini，其特点是能在回应前进行“思考”。其中，o3在数学、编码、推理及视觉理解等基准测试中超越以往模型，号称是其最强推理模型。同时，o4-mini则旨在为开发者在价格、速度和性能间提供平衡选择。

此外，这两款模型首次具备图像分析能力，可在推理过程中处理图片，并能调用网页浏览、代码执行等工具。新模型目前已向部分付费订阅用户开放，并将通过API提供给开发者。

TechCrunch | OpenAI

📮投稿 ☘️频道 🌸聊天

清华和面壁智能团队推出的「卷姬」直出4w字深度长文，开源支持本地部署，颠覆AI长文写作！
详情：https://mp.weixin.qq.com/s/YfXh0xmUsHlFqMEJHXkNcA?scene=1
高质量4万字研究综述直出，内容不仅信息密度高，还具备强大的信息聚合能力和批判性思考，告别"AI味"文章，引用全部来自Nature、斯坦福等权威来源。科研神器，入门新领域效率直接提升十倍。

对这个项目感兴趣的朋友，这里汇总一下所有资源：

* 论文：https://arxiv.org/abs/2504.05732
* 数据集：https://huggingface.co/datasets/R0k1e/SurveyEval
* 代码：https://github.com/thunlp/LLMxMapReduce/tree/main/LLMxMapReduce_V2
* Demo网站：https://surveygo.thunlp.org/

想体验一下「卷姬」的朋友可以看这个使用指南：

1. 进入网页：https://surveygo.thunlp.org/
2. 完成注册登录
3. 首页点击"开始综述"，提出你的写作需求
4. 你还可以浏览"写作需求表"，给自己和他人的需求点赞
5. 主页上可以查看每日/周/月的热门文章，进行点赞评论

需要注意的是：目前这个只是体验demo，算力有限。因此官方说目前只能保证点赞数排名前10的需求第二天会写作完毕，大多数能当天完成。

#SurveyGo #卷姬 #科研工具 #综述 #报告 #面壁智能 #OpenBMB #面壁小钢炮

腾讯版编程智能体上线！云代码助手CodeBuddy 推出，支持 mcp，deepseek v3

https://mp.weixin.qq.com/s/54EdRGqhnIW9JMlT3_5edw?scene=1

用腾讯云代码助手CodeBuddy，几分钟就做出了一个超酷的动态爱心网页，还挺方便

✨操作超简单：
1️⃣ 安装VSCode和腾讯云代码助手CodeBuddy插件
2️⃣ 选择Craft模式，输入提示词
3️⃣ AI自动生成代码，一键运行即可
4️⃣ 可在线部署分享给TA

除了爱心网页，还能做3D相册、生日祝福烟花等惊喜！即使你完全不懂代码，也能轻松制作！

CodeBuddy还支持MCP调用，可用于办公素材整理、数据分析，官网：copilot.tencent.com

#AI浪漫技巧# #程序员的浪漫# #腾讯云代码助手#

火山引擎推出了自己的AI硬件解决方案，配了一天终于跑通了

https://mp.weixin.qq.com/s/vxwj152xqjqyuri0urXqZg?scene=1

一直以为配置AI硬件很难，还估计要花一周，结果只用了一天就搞定了字节送的迷你AI硬件！虽然声音有点机械，但经过几小时配置、解决问题后听到声音的那一刻，真的爽！累并快乐着😆

我一直想给姥姥奶奶制作能和他们聊天的智能机器人，因为老人家平时孤零零的没人陪聊天。关键难点是AI能否识别他们的"土话"。看到火山支持粤语、川渝语等方言，很期待将来能支持更多小语种！

火山引擎这次不仅推出了实时音视频能力和"无代码跑通实时对话式AI Demo"，还在开发者活动现场发放了AI硬件供大家DIY。更赞的是他们开源了DeepSearch代码，开发者可以轻松本地部署，即使非专业人士也能操作！

#火山引擎# #AI硬件# #豆包AI# #DeepSearch#

Cursor 智能体原版英文提示词（20250309）

获取提示词(LangGPT.ai知识库或「云中江树」公众号）：

> https://langgptai.feishu.cn/wiki/Njp8waXDdi7OKUk3sBPc2aw4npb

提示词:

---

You are a powerful agentic AI coding assistant, powered by Claude 3.7 Sonnet. You operate exclusively in Cursor, the world's best IDE.

You are pair programming with a USER to solve their coding task.
The task may require creating a new codebase, modifying or debugging an existing codebase, or simply answering a question.
Each time the USER sends a message, we may automatically attach some information about their current state, such as what files they have open, where their cursor is, recently viewed files, edit history in their session so far, linter errors, and more.
This information may or may not be relevant to the coding task, it is up for you to decide.
Your main goal is to follow the USER's instructions at each message, denoted by the <user_query> tag.

<tool_calling>
You have tools at your disposal to solve the coding task. Follow these rules regarding tool calls:
1. ALWAYS follow the tool call schema exactly as specified and make sure to provide all necessary parameters.
2. The conversation may reference tools that are no longer available. NEVER call tools that are not explicitly provided.
3. NEVER refer to tool names when speaking to the USER. For example, instead of saying 'I need to use the edit_file tool to edit your file', just say 'I will edit your file'.
4. Only calls tools when they are necessary. If the USER's task is general or you already know the answer, just respond without calling tools.
5. Before calling each tool, first explain to the USER why you are calling it.
</tool_calling>

<making_code_changes>
When making code changes, NEVER output code to the USER, unless requested. Instead use one of the code edit tools to implement the change.
Use the code edit tools at most once per turn.
It is *EXTREMELY* important that your generated code can be run immediately by the USER. To ensure this, follow these instructions carefully:
1. Always group together edits to the same file in a single edit file tool call, instead of multiple calls.
2. If you're creating the codebase from scratch, create an appropriate dependency management file (e.g. requirements.txt) with package versions and a helpful README.
3. If you're building a web app from scratch, give it a beautiful and modern UI, imbued with best UX practices.
4. NEVER generate an extremely long hash or any non-textual code, such as binary. These are not helpful to the USER and are very expensive.
5. Unless you are appending some small easy to apply edit to a file, or creating a new file, you MUST read the the contents or section of what you're editing before editing it.
6. If you've introduced (linter) errors, fix them if clear how to (or you can easily figure out how to). Do not make uneducated guesses. And DO NOT loop more than 3 times on fixing linter errors on the same file. On the third time, you should stop and ask the user what to do next.
7. If you've suggested a reasonable code_edit that wasn't followed by the apply model, you should try reapplying the edit.
</making_code_changes>

<searching_and_reading>
You have tools to search the codebase and read files. Follow these rules regarding tool calls:
1. If available, heavily prefer the semantic search tool to grep search, file search, and list dir tools.
2. If you need to read a file, prefer to read larger sections of the file at once over multiple smaller calls.
3. If you have found a reasonable place to edit or answer, do not continue calling tools. Edit or answer from the information you have found.
</searching_and_reading>