| name | oo |
| description | 总结当前打开的网页、用户提供的链接，或某个产品、工具、库、文章、教程与研究页面，生成适合个人网页收藏的原始标题清理版和大纲式中文描述。用户输入 `$oo`、要求“收藏这个网页”“总结这个工具/链接”“生成网页收藏标题和描述”，或希望留下半年后仍能看懂的网页批注时使用。 |
网页收藏标注
根据当前网页内容，生成标题和描述。写给未来的自己看——半年后扫到这条记录，只看描述就能想起这是什么、当时为什么存的。
获取内容
- 如果用户指的是当前打开的网页，使用可访问当前浏览器状态的工具读取页面正文；需要现有登录状态时，优先使用对应的浏览器控制工具。
- 如果用户给出链接，打开链接并读取正文。不要只根据搜索摘要、链接文本或已有印象总结。
- 如果页面无法访问、正文缺失，或内容主要藏在无法读取的交互界面中，明确说明缺少什么，不要编造。
- 识别页面类型，再决定描述的结构和详略。不要把采集过程写进结果。
标题
使用网页原始标题，仅做清理：
- 去掉站点后缀，如
- Medium、 | GitHub
- 去掉营销修饰词
- 不重新创作
描述
用大纲短句写描述，每行一个信息点。需要展开的点用缩进的子层级补充，层级不限。不要套固定模板——根据内容自己决定结构、层级和长度。
写什么
- 产品/工具：解决什么问题 → 怎么做的 → 有什么限制或取舍
- 文章/观点：核心发现或论点 → 关键证据和数字直接写出来
- 教程/技术：核心机制 → 容易踩的坑
怎么写
- 解决什么问题一句话带过，不要展开铺垫痛点细节
- 重心放在描述这个东西本身怎么运作
- 保留原文的独特术语，不替换成通用说法
- 语气平实，像笔记本里给自己写的批注
- 只写从页面中读到、可合理归纳的事实；不要用常识补出页面未提供的机制、数字或限制
不要
- 痛点展开：
原来的做法是…、哪怕一个组件只是…
- 意义/影响：
直接改变了…、这意味着…
- 推荐语气：
值得一读、强烈推荐
- 夸张用词：
颠覆、宝藏、神器、必备
- 第二人称：
你、你会、适合你
- 空话概括：把具体发现替换成
研究表明、文章探讨了
- 在最终结果中添加来源说明、分析过程、推荐理由或未要求的
slug
写完自测
- 半年后只看这段，能想起这东西具体怎么运作吗？
- 有没有在展开铺垫痛点或吹影响？删掉。
- 每一行是不是都在描述机制或事实？
示例
产品页
标题：Linear
描述：
- 项目管理工具，主打键盘操作和响应速度
- 固定的 opinionated workflow，不提供 Jira 式的自由配置
- 面向中小团队
技术文章
标题：How React Server Components Work
描述：
- 把 React 组件分成 server 和 client 两类，让不需要交互的代码不进 bundle
- server 组件在服务端执行，渲染结果以 RSC Payload 格式传给浏览器
- 浏览器端再和 client 组件拼接成完整页面
研究/观点文章
标题：Chinchilla's Wild Implications
描述：
- 模型参数量和训练数据量应该等比扩大
- GPT-3：1750 亿参数，3000 亿 token
- Chinchilla：700 亿参数，1.4 万亿 token，效果更好
- 推论：之前大多数大模型训练数据量不足
- LLaMA 按这个思路做——更小的模型，喂更多数据
工具/库
标题：tRPC
描述：
- 去掉全栈 TS 项目里前后端之间重复的 API 定义
- 后端写函数，前端直接调，类型自动贯通，不需要写接口定义或跑 codegen
- 要求前后端在同一个 monorepo，锁定 TypeScript
教程
标题：Git Rebase in Depth
描述：
- 逐个重放选定的 commit，每一步可以暂停
- reword：改提交信息
- squash：合并多个提交
- edit：暂停在某个 commit，可以拆分或修改
- 冲突时 ours/theirs 指向和 merge 相反
- rebase 站在目标分支上重放变更，所以
ours 是目标分支
输出格式
严格只输出以下内容，不加代码围栏或开场、结尾说明：
标题：...
描述：
