即刻App年轻人的同好社区
下载
AI探索站
116352人已经加入
- 众所周知，搜索是 Agent 最基础的能力之一。模型的知识停在训练截止那天，那之后的事全靠检索补回来。
但是这个行业最吊诡的事情是大家都在做 Agent，快没人做搜索了，甚至连搜索起家的 Google 做的 Gemini，其搜索效果都越来越差。
如果真的要给 Agent 接起来会发现，光有网页的搜索结果其实很不够用。
比如 Agent 要处理的很多信息其实不是网页。汇率现在多少，股票今天涨跌多少。这些答案可能网页里都不能及时出现。
Agent 是个推理系统，Context 决定了一切。要提高 Agent 的信息检索能力，就得从 AI 搜索结果这一端做提升。
搜索这块，海外基本以 Google 为中心，但很少有人直接对着 Google 用，一般都会包一层。薄的像 Serper、SerpAPI，把 Google 的原始结果整理成 JSON 交给你；厚的像 Tavily、Exa、Brave Search API，会自己做召回和排序，Exa 还自建了索引。国内也有几家，博查、豆包搜索，智谱和阿里云也都开了搜索 API。
我这次以 Serper 和豆包搜索为例，做了一轮综合评测。选 Serper 是因为它够薄，基本等于直接看 Google 的原始结果；选豆包搜索是因为它是国内这批里刚正式开放、可控参数给得最全的一家，这里只是作为示例，你可根据自己的业务类型自行选择任意搜索。
mp.weixin.qq.com
32 1312 - 随着 AI 代码产能的日渐暴增，为了守住入库代码质量的最后底线，我给自己做了一个代码审查工具 Duetlens。它的核心设计理念是：和 agent 一起看透每一处改动。
🔍 Duetlens 是一个本地审查优先的代码审查工具。以 GitHub PR 审查流程举例话，agent 在一轮 review 结束后报告的问题，会在 Duetlens 里形成一张张本地的 finding 卡片。我们人类 Reviewer 则可以对 agent 发现的问题，以及任何一段代码进行追问讨论，比如觉得 agent 的修复建议不合理，让它改评审结论，或者直接动手编辑、甚至剔除觉得不需要修复的问题。最后汇总结论，把经过人审的 review 意见一起提交到 GitHub 上，让 PR 作者可见。
🔍 Duetlens 也能支持本地分支的代码审查，也能方便的把审查意见一键导出给我们的 coding agent 去做修复。 不得不提 Duetlens 的开发就是用 Duetlens 的审查反复敲打过来的。
Duetlens 的重跑复审能力也是一大亮点，它会综合 Reviewer 的意见和 PR 作者的评论意见一起研判之前的 finding 结论。
还有更多功能可以看项目主页：
github.com
目前已发布第一个正式版本。永久开源，欢迎大家来体验和提意见
107 730 - 我做了一套小红书起号的 Skill。
结合我运营小红书三年多，三个万粉账号的经验。
。覆盖定位、选题、写作、视觉、复盘 五个环节。
每个环节做一两个 Skill，再加一个总控把它们串起来，一共 10 个。
xhs-buddy：小红书起号总控：判断当前卡点，路由并串起完整运营工作流
xhs-positioning：账号定位：拆解赛道、人设、内容支柱，确定长期增长方向
xhs-hotspot：热点选题：挖掘热门趋势、判断内容机会，生成高互动选题
xhs-title：爆款标题：批量生成标题候选，评分筛选，优化点击吸引力
xhs-writer：笔记写作：生成正文框架、优化表达，适配小红书内容模型
xhs-cover：封面制作：提炼核心卖点，推荐视觉风格，提升首图点击率
xhs-html：图文排版：拆解多页笔记结构，生成 3:4 图文排版方案
xhs-image：AI 配图：生成笔记插图、信息图和系列视觉素材
xhs-account-audit：账号体检：分析账号定位、内容表现和增长卡点
xhs-note-analytics：笔记复盘：拆解数据表现，定位问题，沉淀优化规律
地址：github.com59 246 - 分享一套我整理电脑的方法，爽点在于：你几乎什么都不用做。
第一步，打开 AI，把你是谁全都说一遍——在做什么业务、经营哪几件事、什么最重要。想到哪说到哪，不用组织语言，AI 会帮你结构化成清清楚楚的几个板块。
但是有几个要点需要说清楚：我是谁，我现在在做什么，我有哪些身份和项目，长期想经营什么，平时会反复生产什么，哪些事情希望慢慢形成资产。
第二步，没有第二步。让 AI 直接用 Computer Use 上手，它当场就把文件夹建好，还把你电脑里现有的东西全部分好类，马上分完。我用的产品是Floatboat。
走完这一遍你会发现，电脑不再是一个装文件的盒子，而是你这个人的延伸。要人剑合一，首先要让你的剑非常的了解你。
于是我的电脑最后长成了这样：
01-产品｜我在做的产品，核心资产放这
02-好事引力｜我的主业务，现金流引擎
03-内容与课程｜能沉淀、能复利的内容资产
04-个人品牌｜对外表达和影响力的一切
05-学习与参考｜输入区
06-行政与个人｜个人事务区
07-归档
这套结构不一定适合别人。它本来就不是通用模板，而是「我」被翻译成电脑之后的样子。
它的好处也不只是更容易找文件。
每次保存东西，我都会被迫想一下：这属于我正在经营的哪件事？它只是一次性的任务，还是会慢慢变成我的资产？
更好的管理电脑，也更好的管理时间和注意力。
如果对你有启发的话，给我点个赞吧。
147 3456 - 很多提示词和 Skill，都已经过时了。
Anthropic 的工程师发了一篇文章，提到他们针对 Claude Opus 5、Claude Fable 5 这一代新模型，团队把 Claude Code 的系统提示词删掉了 80% 以上，结果在代码评测里没有看到明显损失。
这件事至少说明，在 AI 快速变化的节奏里，很多所谓的最佳实践，保质期可能非常短。
模型能力一直在提升，一些过去必须反复强调的规则，今天可能已经没有价值，甚至会限制模型的表现。
我也想借这个机会，写一下最近关于提示词和 Skill 的一些真实经验和思考，希望能够给大家一些启发。
一、提示词依然重要
现在很多人会觉得，提示词已经没有什么意义了。
这话对了一半。过去那种八股文式的提示词，价值确实越来越低。比如先给 AI 设定一个复杂角色：
你是一位资深的新媒体编辑，熟悉互联网行业，拥有十年写作经验，请帮我优化这篇文章。
这类角色预置，在新模型上的作用已经没有过去那么明显。模型本身知道编辑是怎么工作的，也知道一篇文章大概要怎么修改。
但这不代表提示词不重要。
如果把提示词换成另一个词，它其实就是：我们怎么跟 AI 沟通。
就像我们和人沟通一样，同样让一个人完成一件事，不同的沟通方式，最后得到的结果也可能完全不同。
所以，我现在更愿意把提示词理解成一种沟通思路。你怎么描述问题，怎么拆解任务，怎么告诉 AI 你真正关心什么，这些依然无比重要。
比如，我想让 AI 帮我总结一篇论文，我很少只说总结一下这篇论文。
我通常会告诉它：
这篇论文主要解决了什么问题？作者是怎么解决的？这个方法和过去的方法相比，真正的变化是什么？
这样问之后，AI 的回答通常会更容易抓住论文的主线。
因为我没有只给它一个模糊的动作，而是告诉了它，我想从哪些角度理解这篇论文。
二、少做角色预置，把任务说清楚
过去写提示词，大家喜欢铺垫很多背景。
先设定角色，再描述能力，然后补充语气、风格、工作流程，最后才说真正要完成什么。
提示词写了几百字，核心任务可能只有一句。
现在我觉得，这些铺垫很多时候已经没有必要。
提示词里真正重要的，是把几件事情分开说清楚。包括这次要达到什么目标，规则或者流程是什么，怎么才算完成。
比如，整理一段语音底稿，可以这样写：
把下面的语音底稿整理成一篇可以继续修改的公众号初稿。
删除重复的口头禅，合并意思相近的内容，调整明显跳跃的段落。
注意保留原来的核心判断，不主动增加新的观点、案例和结论。
完成标准是读者能够看清文章在讨论什么，作者的核心判断是什么，以及这些判断之间有什么关系。
我现在越来越觉得，好的提示词不需要写得复杂，先把这几件事情想清楚，已经解决了大部分问题。
其实就像把一件事交代给同事，你怎么说，他才更容易理解。
三、规则需要有，但不要太多
有一段时间，我看到特别长的提示词，会觉得非常专业，恨不得马上保存下来。
现在的感受刚好相反。
一条提示词特别长，很多时候说明写提示词的人自己也没有完全想清楚。
他只是把可能遇到的问题全部堆了进去，希望模型自己处理。
规则当然需要。
比如我在写作时发现，模型经常大量使用单字动词，文章读起来会比较硬。
我不喜欢这种表达，就会明确告诉它尽量使用更准确的双字动词，但不要为了凑字显得生硬。
这属于稳定的个人偏好，告诉模型是有价值的。但规则太多就会出现问题。
比如你同时要求语言简洁、内容详细、不要长句、不要太口语、不要调整原文节奏、同时优化文章结构......
这些规则很容易打架。
毕竟模型必须先花费大量精力理解哪一条规则优先，最后可能每一条都照顾了一点，但整体效果反而下降。
新模型已经具备比较强的推理和判断能力。提示词不需要提前规定每一个动作，只需要保留那些真正重要的规则。
规则越多，不一定代表控制越精确，也可能代表人没有完成取舍。
四、要不要提供示例，要具体情况具体看
以前写提示词，还有一个非常常见的做法，就是提供大量示例。
这个方法当然有效，但我现在越来越谨慎。
因为示例一方面能够帮助模型理解我们的要求，另一方面也会限制模型的探索空间。
尤其是模型能力越来越强以后，它有时候会过度模仿示例，最后只能在示例附近生成答案。
所以，要不要提供示例，我觉得不能一概而论。需要自己结合具体的情况去试。
现在，我大部分的情况下，都默认不提供示例。
比如让 AI 帮忙写文章开头，我提供了示例，它基本就照猫画虎了，很刻意。
其实这时候，我们可以把自己思路说的更具体点，比如：
这个开头可以考虑从一个具体故事进入，也可以从一组反常的数据进入，或者从我最近的一个真实感受进入。
这并没有规定开头必须怎么写，但给了模型几个明确的思考方向。
所以，仍然是那句话，思路非常重要。
五、告诉模型，什么样才算完成
这也是我最近非常重视的一点。
我们经常告诉 AI 要完成什么，却很少告诉它，什么样的结果才算完成。
比如让 AI 总结一篇文章，最简单的提示词是：
总结这篇文章。
但你也可以写成：
总结这篇文章。完成后，我希望能够回答三个问题：作者发现了什么变化？为什么会发生这种变化？这件事对普通从业者有什么影响？
这相当于给模型提供了一个简单的验收标准。
再比如，让 AI 完成一份产品分析，可以说：
最终结论需要能够帮助团队做出产品决策，不能只介绍产品有哪些功能。
这个要求就比请深入分析这个产品清楚很多。
深入是一个非常模糊的形容词。什么叫深入，每个人的理解都不一样。但能不能支持产品决策，是一个可以检查的标准。
说完提示词，再说 Skill。Skill 就是一份按需加载的小型工作手册。但并不是每一个提示词、每一个场景，都适合做成 Skill。
一、经常发生、流程稳定的事情，才适合做成 Skill
我觉得一类任务想要做成 Skill，至少要满足几个条件：
第一，它经常发生。第二，它的工作流程相对稳定。第三，里面包含一些模型本身不知道的个人经验、团队经验或者业务知识。
这些事情会反复出现，处理方式也相对稳定，适合慢慢沉淀成 Skill。
但某一篇文章的具体观点和材料，没有必要放进 Skill。它们只和当前任务相关，直接作为参考材料提供给模型就可以了。
没必要把所有东西都做成 Skill。
Agent 在运行时，即便没有加载 Skill 的全部内容，通常也需要先读取它的名称、简介和适用范围。这些基础信息同样会进入上下文，对模型的判断产生影响。
Skill 越多，不代表 Agent 越强。大量边界模糊的 Skill，也可能让模型不知道该调用哪一个。
二、Skill 里要放独特经验
我觉得一个 Skill 最有价值的地方，绝对不是那些网上随便就能找到的常识。
比如你在写作 Skill 里写文章要有逻辑、标题要有吸引力，这些内容模型本来就知道，写进去不会带来太大帮助。
真正有价值的是你自己的经验。
比如，修改语音底稿时，要保留口语里的活人感，每个核心判断最好有一个事实、数据或者亲身经历支撑。
这些内容代表了我们的个人品味、工作经验和业务知识。把这些经验编码进 Skill，才是 Skill 真正的价值。
三、Skill 需要控制抽象程度和边界
很多 Skill 的问题，是解决问题的范围太大。
比如一个叫写作的 Skill，边界就非常模糊。写作包括选题、资料阅读、形成观点、整理初稿、修改结构、优化语言、生成标题、检查错别字。
每一个环节需要的经验和评价标准都不一样。
把所有东西都放进同一个 Skill，最后这个 Skill 只会越来越长。
所以我觉得，Skill 最好只解决一个相对明确的问题。比如口述内容整理 Skill、标题生成 Skill、事实核查 Skill。
Skill 的边界越清楚，模型越容易判断什么时候调用，也越容易把它做好。
四、Skill 的主文件应该尽量短
Skill 通常是一个文件夹。
里面可以包含主文件、参考案例、常见问题、风格规范、检查清单，以及其他辅助材料。
所以没有必要把所有内容都写进主文件。
主文件只需要告诉模型：这个 Skill 什么时候使用、它主要解决什么问题、有哪些核心原则、默认按照什么思路推进、遇到具体问题时，可以继续读取哪些参考文件。
至于详细示例、风格要求、常见错误，可以放进单独的文件，等模型真正需要时再加载。
主文件是一张地图。模型先看地图，判断这次任务需要哪些内容，再继续读取相应的文件。
这就是渐进式加载。
不需要的内容不要提前塞给模型。这样既能减轻上下文负担，也能够减少不同规则之间的冲突。
五、Skill 最好包含检查环节
这一点和提示词非常接近。
只告诉模型怎么生成，往往还不够。一个好的 Skill，最好包含一套简单的自检标准。
比如产品体验稿 Skill，可以检查：有没有写清楚真实使用场景、有没有说明过去的方法有什么问题、有没有只有功能，没有判断。
这些自检标准，也是在告诉模型什么样才算完成。
一个 Skill 的价值，不能只体现在生成过程，还要体现在它能够帮助模型判断结果是否合格。53 420 - 最近的烦恼从额度不够，变成额度怎么又重置了。如果你像我一样想知道 Codex 什么时候发粮，又懒得整天刷社交媒体，即友 @wong2 做了一个监控重置的专用网站 codex-resets.com。
Codex Resets 会持续盯着 Codex 负责人 Tibo Sottiaux 的 X 动态，只要他宣布重置 Codex 用量，网站就更新倒计时。页面统计了历史重置次数、平均等待时间、最长等待时间，以及过去 26 周的「发粮日历」。下面还完整保存了每次重置时 Tibo 的原帖，堪称 Codex 用户的民间气象台。
40 36 - 不搞抽象了，和各位解释下产品
关于登上 GitHub Trending 的这个项目 ego（lite），是一个同时友好于人类用户和 Agent 的浏览器，是我们更完整产品 ego 中的一个组件，不同于其他内置 Agent 的 AI 浏览器，ego（lite）没有内置的 Agent，而是被其他 Agent 操控，作为他们的眼睛和手脚。
所以，坦白说，它不适合所有人，使用它，或者说觉得它好用的先决条件是：你已经在高频让 Codex、Pi、Claude Code 等 Agent 产品去控制浏览器完成各种任务。
如果满足这个先决条件，那么你会体会到相对于 Chrome 桥接方案，它丝滑稳定，不抢占你的注意力；相对于 Codex 等 Electron 客户端内置的浏览器它更不容易触发__，Web 能力更健全；以及相对于以上所有方案，它都更快更省 token。具体实现思路可以看我前面发的博客链接。
如果不满足这个先决条件，你大概率会觉得这款产品有些莫名其妙。在这先向你报歉，或许可以等等我们的更完整产品。
【图1】ego（lite）的目标用户，图中的第四类
【图2】ego（lite）的留存，因为我们主要在面向第四类用户做增长，放留存主要是想说明我们确实在被四类用户高频的使用（前期的日新增绝对值不高，所以留存比例会有跳变，不影响看整体趋势）
71 1736 - 发现了一些非常有意思的个人网站，每一个点进去都是宝藏，这些网站让觉得 很多设计 VibeCoding 是没有办法超越的
希望给大家做设计和产品有些启发
echoecho.space
www.jesse-zhou.com
nityasnotes.com
harinisk.com
www.vvisual.biz
rona.wang
joeyderuiter.me
charliedean.com
sumatran.cat
itomdev.com
interactive.matteosantoro.dev
www.moncy.dev243 12128 - Opus 5 + Codex 吓到我了！
我们用 WebGL / Three.js 写了一个 3D 网页游戏，爱丽丝的茶话世界。
目前还在制作过程中，但迫不及待先和大家分享一下录屏，这是一个晚上的成果。
真的可以尝试太多太多的事情了！
created by 我和@Simon阿文00:4659 213