很容易提取一个相对漂亮的色盘，配合一些想象，就可以大致确定出配色了。
##### 高亮悬停
- Magpie 的悬停高亮。初期 AI 挑选了一个没有动画的实现，且高亮部分只是链接部分。问题不大，但是不好：没有动画的高亮显得十分急躁，高亮区域是一个孤岛。
- 后来进行了重新设计，添加了和呼吸节奏相近的缓慢淡入淡出，希望读者能够以更平和的状态进行阅读。同时让高亮和边栏采用同样的颜色，让高亮时融为一体，不那么突兀。
##### 小设计增加“交互感”
AI 在实现基础功能和调整布局时非常好用，但是生成的页面总会有些冰冷。我在 [Magpie](https://onevcat.link/) 中加入一些悬停动效，增加页面的趣味性。
对于[「AI贼船」](https://ai.onev.cat)，希望能更专注提供的内容。在页面顶部我添加了大范围的留白，这让站点标题更加突出；为了让页面不要全是文字，结合站点标题准备了一艘小船图标作为标题的补充；为了能让站点具备一定的动态感，为标题和图标添加了悬停动画，让小船能真正“出航”。
在 vibe coding 的环境下，对这些细节的思考和实现所花的时间，甚至超过了页面的业务逻辑本身。不过也正是这些地方，才能让你的 app 免于千篇一律。
#### 我当前使用的工具
Codex 为主力，GLM-4.6 作为补充，达到相对平衡。由于个人感情和可能的法律风险，以后应该也不再会使用 Claude Code。Magpie 的前半程使用的是 Claude Code，后半程切换到 Codex 接手；而「AI贼船」则是完全的 Codex 产物。
当前的 LLM 用户忠诚度接近于零，新模型吊打旧模型是业界常态，于是用户也像候鸟一样来回迁移。除了年付费的那些可怜孩子受伤之外，这种激烈的竞争态势对于用户其实是好事。一些厂商试图通过应用层来建立一些使用壁垒（比如引导用户创建 commands 或 subagent 等），但是这种努力在模型的差距或者性价比等更重要的指标面前，往往显得苍白无力。
当一个新的模型在核心能力上实现突破时，用户迁移的成本其实很低。那些精心设计的 commands、subagent 配置，在新的模型面前可能只需要几分钟的复制粘贴就能达到类似的效果。这种"降维打击"让应用层的护城河变得异常脆弱。真正能够留住用户的，还是模型本身的能力和性价比。
而模型显然具有"个性"，在长时间使用后，你会逐渐发现每个模型都有自己独特的"脾气"。Claude 相对啰嗦但细致，它喜欢把每个决策的前因后果以及自己正在做什么都给你解释清楚，有时候还能提供一些 "You are absolutely right" 的情绪价值。这种特性在需要对项目理解和或是实现一些简单的测试和挖掘任务时表现出色，但处理困难任务时可能会让人觉得效率不高，且容易被用户带偏。
Codex 则完全是另一种风格——人狠话不多，总是直达要害。它几乎不解释为什么这么做，往往就自己闷头苦干十来分钟，然后直接给出的一个简洁有效的解决方案。这种特性就仿佛再和一个扫地僧对话，一个眼神胜过千言万语。不过，有时候这种"含蓄"也会带来问题，比如架构设计或是研究时，除非明确要求解释，否则缺少互动可能会让开发者难以理解其思路。
想要高效使用某个模型，确实需要一定时间进行习惯。你需要了解它们的强项和弱项，以及边界大概在哪里，并在不同的任务中选择最合适的工具。有时候，甚至需要在同一个项目中混合使用不同的模型，让它们各自发挥所长。
### 当代码变得廉价时
在这一节里，我想跳出刚才这两个具体的项目，来说一些“形而上”的东西，谈谈新时代里我们一般开发者所面临的困境。
其中最大的疑惑应该是：AI 写的代码往往又快又好，作为工程师，应该怎么办？当代码的生成成本趋近于零时，我们的价值在哪里？这可能是每个开发者都需要重新思考的问题。
#### 精确表达和快速验证
如果要说最应该学习的一项技能，我认为会是如何**向 AI 清晰地表达需求**。一个模糊的需求会产生模糊的代码，而一个清晰的需求则能产生高质量的有效代码。表达能力是高效正确使用 AI 的基石。（所以大家多写博客锻炼吧！😂）
现在真的是一个有点子就能实现的世界：不会有人再喊“就差一个程序员”了，也不会有人再有借口能说“我不懂设计，所以就先做个凑合的”。当代码书写和设计修改都变得廉价时，实现的速度不再是瓶颈，验证的速度反而变得更加重要。AI 可以在几分钟内生成上千行代码，但验证这些代码的正确性、安全性和性能，可能需要数倍的时间。
在 AI 时代，程序员的角色正在从“代码编写者”转变为“代码验证者”和“需求定义者”。我们需要能够快速判断 AI 生成的代码是否满足需求，是否安全可靠，是否易于维护。这种验证能力，新时代里会比单纯的编码能力更加重要。而这正是当下的软件开发者相较其他直接所掌握的核心优势：我们理解 AI 的运作方式和我们自己产品的运作方式，这种验证天然是开发者的任务。
#### 尝试掌握复合型的知识
单一的技术栈知识现在正在快速贬值。AI 可以轻松掌握某个具体框架的用法（比如使用 effect 改变 UI），帮助你完成某个明确的任务（比如将按钮改成圆角），但它其实还很难理解不同领域之间的内在联系和权衡取舍。
举个例子，当你要设计一个高并发的系统时，AI 可以帮你写出漂亮的代码，但它可能无法理解为什么在某些场景下选择 Redis 而不是 MySQL，为什么在某些情况下需要引入消息队列，以及这些技术选型背后的业务逻辑和团队能力考量，这是你需要指挥 AI 去完成的。
复合型知识意味着你要能够跨越多个技术领域，理解它们之间的协同效应。你要知道前端性能优化如何影响后端架构，数据库设计如何影响应用层代码，以及安全考虑如何贯穿整个技术栈。这种跨领域的理解能力，是 AI 目前难以企及的。
更重要的是，复合型知识还包括对业务领域的深入理解。AI 可以写出完美的代码，但它无法理解你的用户为什么需要某个功能；AI 可以帮你把某个按钮往上往右调整一些，但它也无法理解为什么这个按钮需要在这个位置才是最优。这种业务、技术和设计结合的能力，是人类工程师当前的真正价值所在。
#### 依靠工程师的嗅觉生存
虽说没有自己亲手写代码，但我仍然会看一眼生成结果。在完成一块需求后，我会要求 AI 把实现思路讲给我听，从架构、边界条件到异常处理都过一遍，再凭经验判断这种实现方式是否合理、是否容易在未来出问题。这其实就是“工程师嗅觉”——一种对代码质量、架构平衡和潜在风险的直觉判断。这其实需要实际的工程经验和踩过一些坑。
在 AI 时代的原生项目里，几乎可以让 AI 参与到每一个环节：从需求分解、接口设计到代码实现与文档生成，自动化程度非常高。但也正因为如此，更需要人为地去思考「扩展」与「维护」的问题。AI 能在一天内产出一个看似完美的功能模块，却未必考虑到未来的扩展性、性能瓶颈或团队协作成本。这会为未来埋下隐患，今天的小错误会积累到明天后天，然后在某个时刻不受控地爆炸。
相比之下，已有项目虽然 AI 的参与度会低一些，却能受益于既有的架构规范和代码风格。指挥 AI 遵守当前的模块边界、命名规则和测试策略，反而能让它成为一个合格的“团队成员”，而不是一个失控的自由开发者。这样生成的代码更容易被接手、被复用，也能在长期维护中保持方向一致，不至于被一次次“聪明”的生成结果带偏。
利用独特的工程师嗅觉，分辨 AI 写出的 good code 和 bad code，是 copilot 和 vibe coding 中工程师的新责任。
### 总结
在此刻，其实我又不禁回想起 20 年前乔布斯的那句“求知若饥，虚心若愚” (Stay hungry. Stay foolish.)（2005 年）。可能你有所不知，这句话其实最早是半个世纪前《全球概览》休刊时的封底告别语（1974 年）。它穿越过 1976 年 Apple I 诞生所引领个人电脑革命，见证了 2007 年 iPhone 横空出世所划破的长空。如果说这几个月以来，在我和 AI 高强度共生后所能参悟到的新的“信条”的话，我希望能以这一句话作为暂时的小结：
{: .alert .alert-info}
AI 的强大在于它的“全知”，而人类的优势则在于“通识”。AI 的全知确实让人可以无知，但其实唯有那些不甘于无知的人，才有资格在新的时代立足。
「Stay hungry. Stay foolish.」我感觉，在今天，这句话的分量无比之重。你，我，我们，甚至于整个人类，可能比以往更需要保持不断学习和虚心。
URL: https://onevcat.com/2025/08/claude-code/index.html.md
Published At: 2025-08-03 18:00:00 +0900
# 一个半月高强度 Claude Code 使用后感受
六月中旬某个闷热的夜晚，在初浅尝试使用 API Key 帮我迅速完成了一个任务后，我毫不犹豫地点下了 Claude Max 的订阅按钮。作为一个“买断制”时代的遗老，每月一两百美金的订阅对当时的我来说还是太超前了。但是在一个半月之后回头望去，看着那些按照 API 计价的被我烧掉的价值 3000 多美金的 token，我似乎捡到了一个超大便宜？不过最近 Anthropic [宣布了新的 weekly 限制](https://x.com/AnthropicAI/status/1949898502688903593)，想来大概针对的就是我这种“重度”用户吧。所以近几天来我也在研究有没有其他替代方案，可以让我从这种限制中解脱出来。不过尝试了一圈下来（包括 CC 接其他 API，也包括像 Codex/Gemini/Qwen/Crush/Amp/AugmentCode 等等），似乎一时半会儿在这个领域 Claude Code (后文用 CC 指代) 还是没有竞争对手。既然还得续费，那不如阶段性地做一个总结，来记录下这一个半月使用 CC 的一些感受吧。
## Vibe Coding 的迭代速度
说到 vibe coding，最让我震撼的其实不是模型有多智能或者是能完成什么尖端任务，而是由它带来的产品迭代速度的提升。有个有意思的现象：Claude Code 本身就是 Anthropic 内部 dogfooding 的产物：从六月中旬我开始使用到现在，短短一个半月时间里，我们见证了很多崭新的功能：自定义命令让我们避免重复输入一样的 prompt，Hooks 功能可以在各种事件触发时自动执行命令，Subagent 则解决了上下文窗口的限制问题。这种更新频率，放在传统软件开发时代简直是天方夜谭。
不光是 CC，整个 AI 辅助开发领域都在以令人眩晕的速度前进。几天甚至几小时完成一个产品，不再是不可能的任务。
不过，这种加速带来了一个有趣的悖论：AI 确实解放了开发者的双手，让我们不用再纠结于那些繁琐的样板代码。但另一方面，当所有人都开上了“法拉利”，赛道上的竞争反而变得更加激烈了。以前你可以精心打磨一个功能，现在？竞争对手可能已经用 AI 快速迭代了三四个版本了。手工匠人式的打磨方式，无疑将被卷死在沙滩上。
说实话，有时候我会怀念那个慢工出细活的年代。但现实就是这样，技术的车轮滚滚向前，你要么跟上，要么被碾过。去适应和利用它，而不是被裹挟前进，可能才是新时代的立命之本。如果这篇文章你只能记住一句话，那我希望是这句：**在 vibe coding 时代，千万别让工具把自己逼死。**效率是提高了，但人还是人，我们需要的不仅仅是更快的开发速度，还有思考的时间和生活的空间。
## 从传统 Editor AI 的转换
在投身 CC 之前，我也算是各种 AI 编辑器的老用户了。从最早期的 Cursor，到后来的 Windsurf，再到 GitHub Copilot 和各种 VS Code 插件如 Cline，基本上市面上叫得出名字的我都试过。但说实话，这些 Editor AI 工具并没有像 CC 这样给我带来那么大的冲击和震撼。。
我想，这类编辑器工具最大的问题是可能是**缺少全局感**。想象一下你使用这些编辑器 AI 时的经典场景：打开一个文件，选中几行代码，然后让 AI 帮你改改。这种交互模式天然就把开发者的思维框在了**当前文件**甚至**当前这几行**的范围内。这种模式对于刚从传统编程过渡到 AI 辅助编程的开发者来说，确实是个不错的起点。毕竟，你还保留着对代码的掌控感：AI 写得不好？没关系，我随时准备自己上。但问题是，如果你真的想进入深度的 vibe coding 状态，让 AI 发挥最大潜力，这种随时准备接管的心态反而会成为阻碍。人类开发者的干预时机和直接下场写代码的时候越少，最终呈现出的效率和效果反而越好。
另外更致命的是同步问题：AI 在上下文中认为文件是 A 状态，实际文件已经被开发者插手改成 B 状态了，然后你让 AI 基于它的认知继续修改，结果可想而知：要么产生混乱，要么 AI 需要再读一遍所有内容。有时候光是解决这种不同步带来的问题，花的时间就比写代码还多。
而命令行工具从理念上就不同：没有华丽的界面，没有实时的代码提示，开发者在过程中难以直接插手“微调”。但恰恰是这种简陋，反而让它能够更深入地理解和操作整个项目。它不会被某个文件或某几行代码限制视野，而是从项目的根目录开始，建立起对整个代码库的认知。没有了编辑器这个中间层，开发者想直接修改代码变难了，这在某种程度上“强迫”你更多地依赖和使用 AI，给它更多信息和反馈，这反而能发挥出更大的效能。
当然，我不是说编辑器 AI 就一无是处。本质上，当前两者的差异更多来自于使用方式和模型质量，而非架构设计。CC 背靠 Anthropic 这棵大树，模型质量自然没得说。更关键的是，它可以肆无忌惮地使用 token（虽然最近加了 weekly 限制），这种量大管饱的豪横，确实在末端引起了质变，让最终效果好了不止一个档次。如果让编辑器 AI 也能随便烧 token，可能效果未必会差到哪里去。
但现实就是现实，至少在当下，如果你想体验真正的 vibe coding，CC 可能是唯一选择。
## 认识 CC 的边界和长处
就像所有工具一样，CC 或者说 AI 辅助编程，也有自己擅长和不擅长的领域。认清这些边界，才能让你的 vibe coding 之旅更加顺畅。
如果你让 CC 分析一段复杂的代码逻辑，理解各个模块之间的调用关系，然后画一张时序图或者架构图，它会完成得相当出色。这种需要理解和总结的任务，正是 LLM 的看家本领。又或者，你想快速实现一个算法、搭建一个项目框架、编写测试用例，CC 都能给你满意的答案。
但是，千万别指望它在所有场景下都能大杀四方。比如说，你想在整个代码库里做一次全局的变量重命名，或者进行某些需要精确匹配的复杂重构，那老老实实用 IDE 的重构功能会靠谱得多。LLM 毕竟说到底也只是一个概率生成器，这类需要 100% 准确性的任务，从起源上就不是 LLM 的强项。如果你真的需要使用 AI 帮助完成这类任务，那么请它写一段脚本去执行并修改代码，往往会比直接指挥它去修改文件，要来的靠谱。
还有个更现实的问题：训练数据的偏差。CC 在处理前端代码或者 TypeScript 时简直如鱼得水，各种框架信手拈来，CSS 炫技让人眼花缭乱，最新的 API 也了如指掌。但换成 iOS/Swift 开发？那可就是另一番景象了。各种过时的 API 用法是家常便饭，有时干脆臆造一些不存在的方法，幻觉严重，而更冷门的语言和框架情况则更加糟糕。训练集丰富程度的差异直接决定了模型在不同领域的表现。
市面上也存在着其他不少基于命令行的 code agent，像是 Crush，Gemini CLI 等等。但实测下来，它们现在和 CC 还存在很大差距。CC 作为“软硬件一体”解决方案带来了巨大的优化空间：Anthropic 既是模型提供方，又是工具开发方，这种垂直整合让他们可以针对具体使用场景进行深度优化。这就像苹果的生态系统——当你同时控制硬件和软件时，能做到的事情远超各自为战的组合。其他竞品要么受限于模型能力，要么受限于工具设计，很难达到 CC 这种浑然一体的使用体验。
## 思考先行还是实践先行
CC 提供了一个很有意思的功能：Plan Mode。在这个模式下，你可以先和 AI 进行充分的讨论，制定详细的实施计划，然后再开始实际的编码工作。这就引出了一个有趣的话题：我们是应该追求先想清楚再动手，还是先动手搞出东西来之后再慢慢改？
在传统软件开发领域，这个争论也由来已久。瀑布派说要先设计后实现，敏捷派说要快速迭代。到了 AI 时代，这个问题又有了新的含义。
我见过两种极端的使用方式。第一种是“规划魔”：进入 Plan Mode 后，和 AI 讨论个把小时，上下文用光两三次，从架构设计到具体实现，从错误处理到性能优化，事无巨细地规划每一个细节。等到真正开始写代码时，基本上 AI 就是照着计划一步步执行。另一种则是“莽夫流”：上来就是一句“给我实现一个 XXX 功能”，然后就看着 AI 噼里啪啦地写代码，写完了发现不对再改，改完了又发现新问题，如此循环往复。
哪种方式更好？也许乍看下来先规划再执行更好？但我的答案可能会让你失望：要看情况。
如果你是个经验丰富的开发者，对项目架构已经有了清晰的认识，那么先进行充分的规划确实能让后续的实现更加顺畅。特别是对于那些需要遵循特定架构模式的既有项目，Plan Mode 能帮你确保 AI 生成的代码符合项目规范。我自己就经常在 Plan Mode 里和 AI 讨论：“我们的项目使用了 MVVM 架构，新功能应该怎么拆分到各个层？” “这部分内容已经有类似实现了，你需要参考现有实现和模式”， 这种讨论能让 AI 更好地理解项目的整体结构，生成的代码质量更高，开发者对具体代码的掌控也更好。
但如果你对某个技术栈完全不熟悉，或者正在做一个全新的探索性项目，那么“先干起来”可能反而是更好的选择。这种情况下，很多时候你根本不知道自己不知道什么。所以与其空想，不如让 AI 先写个原型出来，跑起来看看效果，发现问题再迭代。这种方式特别适合那些“短平快”的项目，或者你只是想快速验证一个想法。
我个人的偏好？我更喜欢先进入 Plan Mode，和 AI 讨论后再开始实施。对我来说，日常维护已有代码库的工作是占大头的，我需要更稳定和可靠的迭代，先 plan 有利于我掌控全局。但在接触新技术栈时，我也不太愿意直接莽起来。不同技术栈下，很多开发的理念是共通的：如何组织可维护的架构（不仅为了人类，也为了 AI 今后进行维护，合理的组织结构还是必要的），如果调度和安排代码以保证高效，各个模块的连接方式等。就算是新技术栈，适当的讨论相比无脑梭哈，也提供了一种更有效的学习方式。但是这样做的代价是慢，如果着急上线功能，或者写的是可以无视代码质量的“快消品”，那么事无巨细的 plan 可能就不太适用了。
最后想说的是，Plan Mode 还有个隐藏的好处：它能帮你整理思路。有时候你觉得自己想清楚了，但真要说出来或者写下来，才发现还有很多细节没考虑到。和 AI 的对话过程，其实也是一个自我梳理的过程。这算是“橡皮鸭调试法”的变种，在 vibe coding 时代依然很有价值。
Claude Code 的 Best practices [官方博文](https://www.anthropic.com/engineering/claude-code-best-practices)中介绍了几种常见的 workflow，比如：
- 探索，计划，编码，提交
- 编写测试，提交，编码，迭代，提交
- 编写代码，截图，迭代
相比于直接用 prompt 命令 CC 开始干活，先指导它对代码库的现状进行理解，往往会得到更好的结果。参考这些常见 workflow 并逐渐发展出自己的使用 AI 的 style，也是一种成长。
## 小步迭代还是放飞自我
在手工编程时代，一天能写几百行代码就算是高产了。但 vibe coding 彻底改变了游戏规则：现在，你可以在十几分钟内生成上千行代码，甚至一口气完成整个项目。这种“生产力爆炸”带来了一个新问题：我们应该如何使用这种能力？
我见过的使用方式大致分两派。一派是“小步快跑”：每次只让 AI 完成一个小功能，验证没问题后再进行下一步。另一派是“一步到位”：直接把整个需求扔给 AI，让它一次性生成所有代码。更极端的，还有人会开启 `--dangerously-skip-permissions` 模式（也就是所谓的 yolo 模式），让 AI 可以不经确认就执行任何操作。
两种方式我都深度尝试过，结论是：**如果能选，小步迭代往往总是更好的选择**。
举个例子，有次我想重构一个模块，大概涉及七八个文件的修改。我当时想，既然 AI 这么厉害，那让它一次性搞定吧！于是我详细描述了需求，然后就看着 CC 开始疯狂输出代码。几分钟后，上千行代码的修改完毕，编译也通过了。我心想：这也太爽了吧！
然而，实际开始尝试时，噩梦开始了。首先是一个小 bug，因为上千行的修改肯定是懒得看的，所以只能描述情况，让 AI 去修复；修复过程中又引入了新问题；再修复，又有新问题...几轮下来，代码库已经面目全非。由于一次性改动太多，开发者失去了掌控，对于修改不理解，也就无法辨别哪些修改是必要的，哪些又是 AI 为了修复新 bug 临时加上的。最后的结果，往往只能是 git reset 整个修改，重新开始。
这类经历让我明白了一个道理：AI 生成代码的能力很强，但它对整体架构的把握和长期维护的考虑还是有限的。一次性生成太多代码，就像是在黑暗中狂奔——你可能跑得很快，但也可能一头撞上墙。而且，当出现问题时，调试的复杂度会呈指数级增长。
相比之下，小步迭代的好处显而易见：
1. **可控性高**：每次只改动一小部分，出问题了也容易定位和回滚。
2. **能够理解**：你能跟上 AI 的思路，理解每一步在做什么。
3. **质量保证**：可以在每一步后进行测试，确保代码质量。
4. **学习机会**：通过观察 AI 的实现方式，你也能学到新东西。
当然，我不是说“放飞自我”就完全不可取：在进行新功能实现时，如果已经进行了充分讨论和规划，那么确实不太需要人类的监督，CC 就可以完成大部分工作。如果你真的想尝试“放飞自我”的开发方式，我有几个建议：
1. **必须有完善的测试**：采用 TDD 的方式，先写测试（当然这也是 AI 来写），再让 AI 实现功能。这样至少能保证基本的正确性。
2. **做好版本控制**：在开始之前创建新分支，随时准备回滚。
3. **分模块进行**：即使要一次性完成很多功能，也尽量按模块来组织，不要把所有东西混在一起。
4. **交叉评审**：AI 生成的代码看起来能跑，但可能隐藏着各种问题，对于生成的代码，不要照单全收。最简单的方式，就是找到另一个 AI，将变更喂进去，看看有什么需要改进的地方，这种迭代往往能收获不错的结果。
## 任务规模和上下文制约
人类和 AI 在某个方面惊人地相似：处理小任务时游刃有余，面对大项目就容易手忙脚乱。对 CC 来说，这个问题更加明显，因为它还要面对一个硬性限制——200k 的上下文窗口。在当前动辄模型给 1M 窗口的年代，这个限制又是确实相当痛苦。
体感上来说，普通使用个十几二十分钟，你就会看到上下文使用量飙到 90% 以上。这时候 CC 就像一个塞满东西的行李箱，再想往里装点什么都困难。更糟糕的是，如果在执行任务的过程中触发了自动压缩，整个 agent 可能会陷入混乱，忘记自己在做什么，或者陷入死循环重复做一件事。
所以，如何在有限的上下文窗口内完成复杂任务，就成了使用 CC 的一门必修课。
### 任务拆解是关键
与其给 AI 一个笼统的“帮我完成 XXX 系统”的需求，不如先把大任务拆解成具体的小任务。这一步最好在 Plan Mode 中进行，让 AI 帮你一起梳理。比如：
```
我：我想实现一个用户认证系统，帮我拆解需求
AI：好的，让我们拆解一下需要完成的任务：
1. 设计数据库表结构（用户表、会话表等）
2. 实现注册功能（验证、加密、存储）
3. 实现登录功能（验证、生成 token）
4. 实现中间件（验证 token、刷新机制）
5. 添加测试用例
...
```
对于一个 session 难以完成的任务，可以让 AI 把讨论内容进行文档化，保存到项目里（比如 `dev-note/auth-implementation-plan.md`）。这样，即使换了新的 session，你也可以让 AI 读取这个文档，快速恢复上下文。
### 使用 Subagent
CC 最近推出的 Subagent 功能在一定程度上缓解了这个问题。在以前，当 CC 使用 Task 工具进行任务时，实际上是在一个全新的上下文中进行工作。这相当于扩展了主 Session 的上下文窗口。
以前我们只能通过 prompt 技巧来“诱导”CC 使用 Task 工具，效果时好时坏。现在有了专门的 subagent 配置，稳定性大大提升。你可以为不同类型的任务创建专门的 agent：
- 代码分析 agent：专门负责理解现有代码结构
- 代码审查 agent：检查代码质量和潜在问题
- 测试 agent：编写和运行测试用例
- Git agent：处理代码提交和 PR
通过合理链式调用这些 agent，即使是大型任务也有机会能在同一个 Session 里有条不紊地完成。每个 agent 都在独立的上下文中工作，不会相互干扰，也不会耗尽主 session 的上下文。
### 在合适的时机手动 compact
虽然 CC 会自动进行上下文压缩，但我的经验是：主动出击会更好。当你看到上下文使用量接近用满时，不妨手动执行 `/compact` 命令。这可以让压缩发生在一个更自然的断点进行。比如刚完成一个功能模块，或者刚跑完一轮测试。这时候压缩，AI 不太会丢失重要信息。而如果等到自动压缩，可能正好在你改代码改到一半的时候触发，那就很容易出问题。
另一个技巧是：对于相对独立的任务，干脆新开一个 session。反正你已经把任务计划文档化了，新 session 读取文档就能快速上手。这比在一个快要爆炸的 session 里硬撑要明智得多。
当前在 AI 辅助编程中，上下文窗口依然是稀缺资源，要像管理内存一样管理它。合理规划、及时清理、必要时“换个房间”，才能让 vibe coding 的体验保持流畅。
## 善用命令和周边工具
### Command 和 Hooks
我有个暴论：**凡是重复了两次以上的类似 prompt 都应该用命令来表述！**
每次都输入类似的 prompt 真的非常无趣：“运行测试并修复失败的用例”、“提交代码时请使用规范的 commit message”...如果你发现自己在重复类似的请求，立刻停下来，花一分钟配置一个 command。
Command 相比 subagent 有个巨大的优势：它拥有完整的当前会话上下文。如果你的任务和当前正在进行的工作高度相关，那么 command 的效率会更高。比如我常用的几个：
- `/test-and-fix`：运行测试，如果有失败自动尝试修复
- `/review`：对当前修改进行代码审查，给出改进建议
- `/commit-smart`：分析改动，生成合适的 commit message 并提交
至于 Hooks，说实话我用得不多。理论上它能在特定事件触发时自动执行命令，比如每次提交前自动运行测试。但实际使用中，我更喜欢保持一定的控制权，不太喜欢太多自动化的东西在背后悄悄运行。不过这纯属个人偏好，如果你的工作流比较固定，Hooks 确实能省不少事。
### MCP
通过 [MCP](https://onevcat.com/2025/02/mcp/) 补充模型不知道的知识。我最常用的几个场景：
**1. 最新的 Apple 文档**
Apple 的文档页面大量使用 JavaScript 渲染，因此 CC 的 WebFetch 抓不到内容。但通过 [apple-docs-mcp](https://github.com/kimsungwhee/apple-docs-mcp)，我可以获取最新最准确的 API 文档。这对 iOS 开发来说简直是救命稻草。
**2. 项目管理集成**
通过 [mcp-atlassian](https://github.com/sooperset/mcp-atlassian) 连接 JIRA，可以让 CC 直接读取和更新任务状态，或者自动将分析的情况和实现进行回复，保持沟通畅通。
**3. LSP 支持**
CC 暂时还原生支持 LSP，但通过 [mcp-language-server](https://github.com/isaacphi/mcp-language-server)，可以获得准确的代码补全和类型信息。特别是对于那些 CC 不太熟悉的语言，这个功能价值巨大。
配置 MCP 可能需要一点时间，但绝对物有所值。它让 CC 从一个通用的工具变成了为你量身定制的助手。
### 编译、分析和测试
永远记住：AI 生成的代码，未经测试都是废品。
我的工作流程通常是这样的：
1. 在 CLAUDE.md 中详细列出项目的编译命令、测试命令、linter 配置
2. 每完成一个小功能，立即编译
3. 编译通过后，运行相关测试
4. 测试通过后，运行 linter 和 formatter
听起来很繁琐？其实配置好之后，这些都可以通过简单的命令完成和 subagent。关键是要让这些步骤成为习惯，而不是等全部写完再说。
如果你的项目支持 TDD，那就更好了。先让 AI 根据需求写测试，然后再实现功能。这样生成的代码质量通常会高很多，因为 AI 有了明确的目标。
当然，根据编译器的废柴程度（你们大概应该知道我在说谁..）和项目的规模，编译一次的时间代价可能会很大。这种情况下，我会拆分模块，尽量只去编译改过的模块。如果这比较困难，那么也可以使用 `git worktree` 来创建多个工作目录：这样你可以让多个任务并行进行，互不干扰，也算是弥补等待编译所带来的时间损失。
### Code 之外，大有可为
别把 CC 只当成写代码的工具，它的能力远不止于此。
我现在的日常使用场景：
- 代码提交和 PR：写完代码后，直接让 CC 分析改动、生成 commit message、推送代码、创建 PR。它生成的 PR 描述往往比我自己写的还要清晰。
- 撰写技术文档和 wiki: 让 CC 分析代码生成 API 文档、更新 README、编写使用示例。它的文档往往更加规范和完整，甚至不会出现语法错误。
- JIRA 更新：完成任务后，让 CC 更新 ticket 状态、添加评论回复用户、甚至创建新的子任务。再也不用在网页上点来点去了。
- 数据处理：需要批量处理文件、转换格式、清洗数据？以前我会写脚本，现在直接描述需求让 CC 来做。而且每次需求不同时，不用维护一堆一次性脚本了。
更有意思的是 CC 解锁了随时随地工作的可能性。通过像是 [VibeTunnel](https://vibetunnel.sh/) 或者任意手机 SSH 客户端，配合 Tailscale，我可以在任何地方连接到家里的工作机器，用手机指挥 CC 干活。虽然不适合与 CC 进行复杂的计划和交互，但处理一些简单的需求，比如跑个脚本、修个小 bug，更新下文档什么的，是完全没问题的。出门在外突然想到什么，立刻就能实现，这种感觉很奇妙。
最后，个人强烈推荐配一个好的麦克风。在 vibe coding 时代，用语音输入描述需求，比打字更加自然流畅。现在的语音识别已经很准确了，而中英文混杂也能处理得很好。想不到当年为了当游戏主播买的麦克风，吃灰这么多年后，终于在今天找到了真正的用武之地。
当然，Mac 系统自带的语音输入是幼儿园级别，从准确性和易用性上都不值一提。你肯定需要一款 AI 转译的 app，我也试用过一些，总结几个当前市面上的优秀选择：
- [MacWhisper](https://goodsnooze.gumroad.com/l/macwhisper?a=864919667)：以前买的，现在在用，原生 macOS app，作者支持速度很快。
- [VoiceInk](https://tryvoiceink.com?atp=k3GcF3)：提供开源以供确认，隐私安全，付费省心。
- [Wispr Flow](https://ref.wisprflow.ai/wei-wang-onevcat)：订阅制，小贵，但胜在 UI 漂亮，UX 流畅。
它们都是很不错的选择，功能也都类似。除了基础的语音识别和输入外，再配合转译后接入 LLM 进行文本润色/修改的能力，根据不同场景将我的语言自动转为合适的文字和格式。这些 app 把人机交互提升了一个档次，语音输入的内容往往比我自己劳心劳力组织的文字还要清晰精确。现在，绝大多数情况下，我和同事用不同语言交流时，以及自己在书写 PR 和各种文档时，我几乎也都是说中文，然后让 AI 当我的“同传”转换为合适的目标语言，以此确保准确和及时。
## 体感降智和更多限制
接下来要说的内容，有些是我自己的感受，有些是社区里朋友们的吐槽。很多东西无法证实或证伪，大家权且一听。
### Opus 远强于 Sonnet
这几乎是板上钉钉的事实：Opus 的效果比 Sonnet 好很多。毕竟价格摆在那里，Opus 是 Sonnet 的 5 倍。100 美金的 max 订阅，5 小时时间窗口的 Opus 只能跑几个小任务额度就用光了。200 美金的订阅也只是勉强够用。
如果你是 100 美金档的用户，建议养成手动切换模型的习惯。日常用 Sonnet 处理简单任务，遇到复杂的架构设计或者棘手的 bug，再切到 Opus。
### 时间玄学
这个听起来很离谱，但确实有体感：美国半夜（也就是北京时间的白天）的效果比美国白天要好。实际上软件开发最活跃的还是中美两国，而 Anthropic 在中国其实是没有正规渠道能用的。所以可能是因为美国夜里使用的人少，服务器压力小，从而模型性能不会退化？总之，如果北京时间大清早遇到无法解决的问题，留到下午时段处理，可能会有惊喜。
### 降智疑云
最让人担心的是这个：个人体感，前一个月的使用体验明显比最近两周要好。开始我以为是自己的错觉，但社区里抱怨的声音也越来越多。合理的猜测是大量开发者涌入导致的资源紧张。就像一个原本只供应 100 人的自助餐厅，突然来了 1000 人，菜品质量下降几乎是必然的。结合最近 Anthropic 寻求新的融资的新闻和推出 weekly 限制的政策，想要在这个定价和使用策略下盈利，似乎是不太可能的。
### 限制的阴霾
从 8 月底开始，weekly 限制正式实施。虽然官方说是为了公平使用，但谁都知道这背后是算力不足的无奈。而且不排除未来会有更严格的限制。
这让我想起一个老段子：中国先解决显卡问题，还是美国先解决电力问题？在这两个问题解决之前，AI 发展的瓶颈可能不是算法，而是最基础的硬件资源。
### 一些应对策略
面对这些限制，可能我们不得不采取一些“省着用”的技巧：
1. **分级使用**：简单任务用 Sonnet，复杂任务才上 Opus
2. **错峰使用**：避开美国工作时间，选择服务器负载低的时段
3. **提高 prompt 质量**：一次说清楚，减少来回对话消耗的 token
4. **合理使用 subagent**：把消耗大的任务分配给 subagent
5. **保持多个选择**：虽然 CC 目前最强，但保持对其他工具的关注
## 总结和未来展望
一个半月的 CC 使用经历，有惊喜，有担忧，有对未来的憧憬，也有对现实的无奈。但总的来说，我感受到的是自己切实地站在在历史的进程之中。Vibe coding 不仅仅是一种新的编程方式，更是一种全新的思维模式。它要求我们重新思考什么是编程、什么是创造、什么是价值。在这个 AI 与人类共舞的时代，愿我们都能找到属于自己的节奏。
最后，回到文章开头的那句话：在 vibe coding 时代，千万别让工具把自己逼死。技术是为人服务的，不是相反；工作是让人有机会追寻和思考自我的，而不是让自己迷失。保持这份清醒，可能比掌握任何具体的技巧都更重要。
URL: https://onevcat.com/2025/06/foundation-models/index.html.md
Published At: 2025-06-17 21:00:00 +0900
# Foundation Models：苹果设备端模型的边界探索
WWDC 2025 上，苹果公布了设备端的 Foundation Models 框架，可以让开发者们使用离线模型完成一些基本的 AI 任务。虽然各个 session 已经详细介绍了基本用法，但作为开发者，我们更关心的往往是：这个框架的边界在哪里？什么情况下会出现问题？实际性能如何？
经过近一周的测试和探索，我有了一些有趣的发现。这些发现可能对你在实际项目中使用 Foundation Models 有所帮助。
> **重要提醒**：本文所有结论基于 macOS/iOS/Xcode 26 Beta 1，实际发布版本可能会有变化。苹果在 lab 中也明确表示，模型会随着 iOS 版本更新而持续改进。
## 结论先行
**Foundation Models 已经可以用于生产环境了吗？** 我的答案是比较乐观：虽然还是 beta 1，但框架的稳定性出人意料地好。Apple 一改往年 beta 约等于 alpha 的特性，这次端出了大体能用的东西，让人喜出望外。不过，你还是需要了解它的边界和限制。
**核心发现汇总：**
- **内存消耗**：总运行时内存约 1.0-1.5GB（模型权重 750MB + KV cache + 框架开销）
- **上下文窗口**：实际限制为 4096 tokens，不是训练时的 65K
- **并发性能**：多 session 并发会严重影响性能，从 10-30 tokens/s 降至约 1 token/s
- **Schema 开销**：每个 @Generable 属性约增加 30 tokens 开销
- **温度敏感性**：意外地不敏感，0.0-2.0 范围内表现稳定
- **安全防护**：相当严格，会删除违规的 transcript 条目
## 性能特征：数字背后的真相
### 内存使用：不只是模型权重
苹果宣传的是 3B 参数、2-bit 量化的模型，按理说模型权重约 750MB。但实际运行时的内存占用要大得多：
```
模型权重: ~750MB (3B params × 2-bit)
KV Cache: ~300-600MB (8-bit 量化, 37.5% 减少优化)
框架开销: ~100-200MB
────────────────────────────────────
总计: ~1.0-1.5GB
```
这意味着在内存受限的设备上，你需要仔细考虑何时加载和释放 session。好消息是苹果做了很多优化，比如 KV cache 的 8-bit 量化和 37.5% 的 block sharing 减少；而 base 模型本身似乎在不用时也会自动 unload。
### 上下文窗口：训练 vs 部署的差异
这里有个容易被误解的地方。苹果提到模型训练时支持最高 65K tokens 的上下文，但实际部署到用户设备上时，**硬限制是 4096 tokens**。
```swift
// 超出上下文窗口时会抛出这个错误
catch LanguageModelSession.GenerationError.exceededContextWindowSize {
// 需要总结对话历史，重新开始 session
}
```
对于一般的对话场景，4096 tokens 大约能支持 10-20 轮对话。但如果你的 instructions 很长，或者需要处理大量上下文，就需要提前设计好上下文管理策略。
### 并发性能：单 session 为王
测试中最意外的发现之一是多 session 并发的性能下降。
**单 session 性能：**
- iPhone：约 10-30 tokens/s
- M2 Pro：约 30 tokens/s
**3 个并发 session：**
- 所有设备：**每个** session 的性能都骤降到约 1 token/s
显然，苹果只考虑了单 session 的使用场景。如果你的应用需要处理多个并发的 AI 任务，建议全局管理**一个 session**，使用队列去串行访问，避免任何并发 session。
```swift
// 推荐：使用队列管理请求
actor SessionManager {
private let session = LanguageModelSession()
private var requestQueue: [AIRequest] = []
func processRequest(_ request: AIRequest) async -> AIResponse {
// 串行处理，不要并发
}
}
```
当然，不排除这只是 beta 阶段的 bug，或者 Apple 未来会在底层帮我们实现一个串行队列的使用方式。否则，多 session 并行导致的性能瞬间恶化，还是相当出乎意料的。
### Guided Generation：Schema 的代价
`@Generable` 宏是 Foundation Models 的亮点之一，但要注意它并非完全 free。保持简短的属性名和描述时，每个 @Generable 属性依然大约会增加 30 tokens 的 schema 开销。一些 Input Prompt token 数的实测数据（同样的 prompt，逐个增加 Generable 的属性数量）：
```
1 属性: 313 tokens
2 属性: 345 tokens
3 属性: 374 tokens
4 属性: 417 tokens
5 属性: 442 tokens
```
单个属性开销不大，但累加起来并不断发送的话，在 4k 这个上下文窗口限制下还是不容小觑。特别对于复杂的数据结构，这些开销可能会快速消耗你的上下文窗口。
### includeSchemaInPrompt 优化
苹果提供了一个优化选项 `includeSchemaInPrompt: false`，理论上可以减少 input tokens。但在测试中发现，这个选项在 beta 1 中**没有按预期工作**。
```swift
// 在 beta 1 中，这样的调用完全没有减少 input prompt
let response = try await session.respond(
to: prompt,
generating: MyType.self,
includeSchemaInPrompt: false // 可能不会显著减少 tokens
)
```
这可能是因为底层的约束解码（constrained decoding）机制仍需要完整的 schema 信息，即使不在 prompt 文本中显示。不过也有可能是 beta 1 的 bug。
> Bug Reported: FB17935029
## Tool Calling：隐藏的宝石
虽然 WWDC session 中对 Tool Calling 的介绍相对简短，但我认为这是 Foundation Models 最有价值的功能之一。它在概念上与 [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) 相似，但具有 Swift 的类型安全优势。
Tool Calling 让用户能通过自然语言控制应用功能，这可能是"工具导向编程"时代的开始。
## 温度与创造力：意外的发现
在创造性任务测试中，我发现 Foundation Models 对温度参数的敏感性比预期要低：
- **0.0-0.7**：输出几乎相同，遵循指令
- **0.7-1.5**：逐渐增加创造性，但仍然可控（默认 0.7）
- **1.5-2.0**：最大创造性，偶尔会有意外惊喜
这与一些其他温度相对敏感的模型的表现有明显差异，在整个支持范围里，模型对于指令的跟随都还不错。
对于需要创造性输出的场景，适当调高温度到 1.5 左右会有更好的结果。
> 当使用大于 2.0 的温度时，系统会给出运行时的警告。
## 安全防护：严格但有副作用
苹果的安全防护相当严格，但有一个值得注意的行为：**当触发安全防护时，transcript 中违规的条目会被完全删除**。
```swift
// 防护触发前
session.transcript.entries.count // → 10
// 防护触发后
session.transcript.entries.count // → 9 (违规条目被删除)
```
这意味着你很难调试安全防护的触发原因。建议在开发阶段保留一份对话日志，以便分析和改进。
当然，重点还是调试更好的 instruction 和 prompt，以及合理的错误处理机制。
## 开发中的坑和解决方案
### 问题 1：Playground 支持问题
虽然 Session 里所有人都在尝试教你使用 Playground 调试 Prompt，但 beta 1 里在独立的 Swift Playground 中无法直接使用 Foundation Models：
```swift
import FoundationModels
import Playgrounds
#Playground {
// ❌ 在独立 Playground 中会失败
// Couldn't look up symbols: Playgrounds.init(...
let session = LanguageModelSession()
// ...
}
```
**解决方案**：在 Xcode 项目内创建 Playground，或直接在项目中测试。目测后续版本大概率会修复这个问题（看起来修复会比较容易，赚 KPI 嘛，不寒碜）。
> Bug Reported: FB17969152
### 问题 2：语言检测误报
有时候长文本（80+ 字符）会触发"不支持的语言"错误，即使内容是支持的语言。
实测中一些很正常的文本，比如把这个放到 prompt 中：
```
我在开发一个quiz的游戏app，现在有个统计界面，需要显示如下数据：
- 完成挑战天数
- 最高连续正确
- 完成挑战次数
我现在需要把这三项翻译成英文，帮我挑选合适的词句。因为要显示在手机屏幕UI上，不能太长，但是也还是要保持清晰
```
beta 1 中稳定触发错误：
看起来是语言识别为了 `zh-Hans` (这是正确的)，但是 `SystemLanguageModel.default.supportedLanguages` 列表里定义的是 `zh-CN`。
但是奇怪的是，不在支持列表里繁体中文的 `zh-Hant` 或者 `zh-TW` 却又能工作，没搞太懂。但是应该不是很难修。
其他还有一些例子，不再展示了。
**临时解决方案**：
- 缩短输入文本
- 在 prompt 中明确指定语言
> Bug Reported: FB17874349
### 问题 3：工具调用不太稳定
```swift
// 根据提示词的细微差别，有时候会调用，但有时候又不会
let session = LanguageModelSession(
tools: [WeatherTool()]
)
let response = try await session.respond(
to: "What's the weather like in Tokyo?"
)
// Response: I don't have the weather information for Tokyo right now.
```
虽然从人类的角度来看提示词已经很明确，但是根据某些难以察觉的细微不同，有时候工具调用不太稳定，
这应该还是模型性能的限制，估计没有太多办法。如果你确定某个工具调用应该优先，可以尝试在提示词中
明确进行指示，来辅助模型做出调用工具的决策。
> Bug Reported: FB17964201
## 一些体会和思考
Foundation Models 给我最大的感受是：**这是一个为了实用而设计的框架，而不是为了炫技**。3B 参数在当今的大模型时代看起来不大，但苹果针对设备端的场景做了大量优化：
1. **2-bit 量化**：保持了模型质量的同时大幅减少了存储和内存需求
2. **推测解码和草稿模型**：在 3B 模型外，还搭配了一个 300M 的 draft model，提升了推理速度
3. **约束解码**：确保了结构化输出的可靠性
4. **Tool Calling**：为应用集成提供了优雅的解决方案
不过，也要认识到它的限制：
- **世界知识有限**（训练数据截止到 2023 年 10 月，美国总统还是拜登！）
- **不适合数学计算和代码生成**
- **复杂推理能力有限**
但对于文本摘要、内容分类、结构化数据提取这些任务，它的表现相当不错。
## 未来展望
苹果明确表示模型会随着系统更新持续改进，这意味着你针对旧版本模型调好的 prompt 可能会在新版本模型上不太适用。Apple 建议
我们设定 test set，在每次模型更新时进行确认和调整。考虑到模型的更新间隔大概是半年到一年，因此每年可能会有两个新版本模型
需要确认，这也是一定工作量。
如果模型变化很大，导致无法同时针对新旧模型寻找到同样好的 prompt，我们可能甚至需要针对不同的系统版本使用不同的提示词，这
也会带来额外的维护开销，值得注意。
另外，macOS 上搭载的本地模型也是这个 3B 的小模型（同时也提供给 macOS 26 上的模拟器使用），这让人有一些失望：作为性能
更加强劲的“生产力级别”设备，却使用了和手持设备一样的方案。希望今后能看到 macOS 上有更强力，至少是上下文窗口更大的模型，
并发挥出隐私优先和本地运行的优势吧。
## 给开发者的建议
如果你正在考虑在项目中使用 Foundation Models：
1. **现在就可以开始实验**，框架已经相当稳定
2. **围绕 4096 token 限制设计应用流程**，不要指望短期内会有大幅提升
3. **优先考虑 Tool Calling**，这可能是最有价值的功能
4. **准备好上下文管理策略**，如果存在对话式的场景，几乎必须处理上下文溢出
5. **在真机上测试性能**，模拟器版本跑的是 macOS 搭载的模型，性能结果可能不准确
Foundation Models 不是万能的，但它为 iOS 应用带来了前所未有的 AI 能力。关键是理解它的边界，并在这些边界内发挥创造力。
---
**参考资料：**
- [Meet the Foundation Models framework - WWDC25](https://developer.apple.com/videos/play/wwdc2025/248/)
- [Deep dive into the Foundation Models framework - WWDC25](https://developer.apple.com/videos/play/wwdc2025/259/)
- [Code-along: Bring on-device AI to your app using Foundation Models - WWDC25](https://developer.apple.com/videos/play/wwdc2025/286/)
- [Explore prompt design & safety for on-device foundation models - WWDC25](https://developer.apple.com/videos/play/wwdc2025/301/)
**再次强调**，本文基于 macOS/iOS/Xcode 26 Beta 1 的测试结果，后续版本可能会有所不同。如果你有不同的发现或问题，欢迎讨论。
URL: https://onevcat.com/2025/04/llmtxt/index.html.md
Published At: 2025-04-01 20:00:00 +0900
# 通过 llms.txt 引导 AI 高效使用网站内容
> 作为示例，本站也开始提供 `llms.txt` 和 `llms-full.txt` 的支持，可以参看下面的链接获取相关文件。
>
> llms.txt
>
> llms-full.txt
## 什么是 llms.txt
大型语言模型（LLMs）是截止至训练日期时的人类知识的总集。而如果想要精确地解决更加实时的问题（比如在进行代码生成、研究辅助等任务中），我们可以通过搜索最新知识，依赖网络信息，来极大提升模型的准确性。然而，标准的 HTML 内容通常包含导航元素、JavaScript、CSS 和其他对于 LLMs 而言非必要的信息。这些冗余信息会在对话中占据 LLMs 有限的上下文窗口，也会干扰和降低处理效率。此外，LLMs 直接抓取和解析完整的 HTML 页面效率也很低下。为了应对这些挑战，`llms.txt` 应运而生，它是一个[正在讨论的标准（参见 llms-txt.org）](https://llmstxt.org/)，旨在为 LLMs 提供一个简洁、专业的网站内容概述，以单一且易于访问的 Markdown 文件格式呈现。`llms.txt` 就像一个网站的“指南”，引导 AI 系统找到站点上的关键信息，并以易于阅读和分析的结构化格式提供这些信息。
### llms.txt 的目的与益处
在使用带有搜索的 LLMs，或者是通过其他的搜索服务 API 将搜索内容传递给不带搜索的 LLMs 时，被搜索的网站内容是面向人类进行渲染的，它包含大量无关的视觉要素（CSS 样式，动画等）和功能性的内容（JavaScript，操作交互等），且主题往往不太明确，这会给 LLMs 增加理解难度。我们需要一种更加面向 AI 的网站内容检索方式。
`llms.txt` 是**放置在网站根目录下的一个文件**，它的核心目标是向 LLMs 提供结构化的、机器可读的信息，从而帮助它们在推理阶段更有效地利用网站内容。与面向搜索引擎的 `robots.txt` 和 `sitemap.xml` 不同，`llms.txt` 专为推理引擎优化，它的目标是通过以 AI 能够高效处理的格式提供内容结构，解决了 AI 相关的挑战。这种（还在提出阶段的）标准标志着一种向 AI 优先的文档和内容策略的转变。随着 AI 在网络内容消费中扮演越来越重要的角色，针对 AI 的理解进行优化将变得与针对人类用户和搜索引擎进行优化同样关键。
网站所有者也能从实施 `llms.txt` 中获益匪浅：AI 聊天机器人更有可能在其回复中引用那些提供了 `llms.txt` 文件的网站，从而提高网站在 AI 平台上的可见性。优化后的 `llms.txt` 文件还有可能在 AI 驱动的搜索体验中带来更好的可见性、更高的排名和更强的可发现性。
更清晰地理解 `llms.txt` 在网络标准中的定位，可以参考下表：
| **名称** | **目的** | **目标受众** | **格式** |
| ------------- | ---------------------------------- | ------------ | -------- |
| `robots.txt` | 控制搜索引擎爬虫对网站的访问 | 搜索引擎 | 文本 |
| `sitemap.xml` | 列出网站上所有可索引的页面 | 搜索引擎 | XML |
| `llms.txt` | 为大型语言模型提供结构化的内容概述 | 大型语言模型 | Markdown |
## 解剖 llms.txt 标准：关键组件与结构
`llms.txt` 标准现在定义了两种不同的文件：`/llms.txt` 和 `/llms-full.txt`。
- `/llms.txt` 提供了一个精简的网站文档导航视图，旨在帮助 AI 系统快速理解网站的结构，它通过链接提供了一个简洁、结构化的关键内容概述。
- `/llms-full.txt` 是一个包含所有文档内容的综合性文件，它将所有文档整合到一个单独的 Markdown 文件中，这个文件需要“包罗万象”，因此尺寸一般比较大。
这两种版本的存在使得网站所有者可以根据不同的用例和内容结构，选择向 LLMs 提供的信息详细程度。对于拥有大量文档的网站，以导航为中心的 `/llms.txt` 可以提供快速的路线图，而 `/llms-full.txt` 则提供完整的原始内容以供深入处理。
### llms.txt 的内容
对于 `/llms.txt` 文件，其必须遵循特定的 Markdown 语法和结构。
1. 文件应以网站或项目名称的一级标题（`#`）开头，随后可以有一个简短的项目描述的块引用（`>`），通常一到三句话即可。
2. 接下来的内容应使用二级标题（`##`）组织，例如“文档”、“示例”等，用于列出文档链接，创建逻辑区块（例如，“主要文档”、“产品”）
3. 这个二级标题下应该是一个列表，它包含相应的链接和简短的描述，格式为 `- [文档名称](URL): 简短描述`。此处的 URL 应该是等同于为人类准备的网页地址所等同的该文档的 md 格式文件。
4. 此外，还可以包含其他的二级区块，例如“可选资源”、或“隐私政策”等其他部分。一般会使用 `## Optional` 部分用于表示当上下文长度受限时可以省略的次要链接。
一个典型且简单的 `llms.txt` 文件内容如下：
```md
# 我的博客
> 这是我的博客，用来记录一些个人感兴趣的内容。
## 博客文章
- [什么是 llms.txt](https://example.com/article-1.md): 介绍什么是 llms.txt 以及它的主要特性
- [从监督学习到加强学习](https://example.com/article-2.md): 回顾和比较训练 LLM 时的主流学习方法和变迁过程
## 其他页面
- [关于我](https://example.com/about/index.html.md): 介绍博客站点作者：简单的生平和其他著作。
- [许可证](http://example.com/license/index.html.md): 描述网站内容的许可证信息
## 可选
- [GitHub 源码](https://github.com/example): 网站源代码
```
这种结构化的 Markdown 格式确保了 LLMs 可以轻松地解析和理解 `/llms.txt` 文件的内容和层级结构。Markdown 清晰的语法和明确的层级关系（标题、列表、链接）为 AI 模型提供了一种一致且易于处理的格式，从而减少了歧义并提高了信息提取的效率。
### llms-full.txt 的内容
相比之下，`/llms-full.txt` 的格式则更为直接，它是一个**包含所有文档内容**的单一、全面的 Markdown 文件。它应包含网站的所有文档，并整合到一个单独的 Markdown 文件中。为了优化 AI 的处理效率，建议移除文件中的非必要标记和脚本。最简单的方法，就是将所有驱动站点的内容（比如很多 markdown 文件）进行合并，然后生成这个巨大的内容文件。
`/llms-full.txt` 为 LLMs 提供了对完整内容的直接访问，无需进行额外的导航。对于需要深入理解所有可用信息的任务，以单一、清晰的格式提供完整的文档对于 LLMs 来说非常有益。常见的例子，比如某个技术产品（可以是编程语言，库，或者是面向用户的软件等）将文档和说明合并到一个 `llms-full.txt` 中，以供 AI 进行参考。
### 创建和放置 llms.txt
按照上述内容创建好文件后，就可以将它们放置在网站的根目录下，并公开给互联网访问了。llms.txt 的标准约定了文件的位置就是网站根目录，这类似于 `robots.txt` 和 `sitemap.xml` 的存放方式，简化了 LLMs 的发现过程。
另外，我们还可以在服务器配置中添加 `X-Robots-Tag: llms-txt` HTTP Header。这个值可以向 LLM 发出信号，表明网站提供了 `llms.txt` 文件。这并不是一个严格要求，但这个 header 值可以明确表明网站已采用 `llms.txt` 标准。
我们可以使用一些工具来验证某个网站是否实现了 llms.txt 标准，比如[这个 extension](https://chromewebstore.google.com/detail/llmstxt-checker/klcihkijejcgnaiinaehcjbggamippej?pli=1)。
## 在 AI 中使用 llms.txt
和主动抓取网络的搜索引擎或者爬虫不同，目前 LLMs 还不会自动发现和索引 `llms.txt` 文件（毕竟 llms-txt 还没有成为被完全认可的标准）。因此，我们还需要手动将文件内容提供给 AI 系统。这可以通过以下方式完成：
1. 直接向可以访问互联网的 AI 提供 `llms.txt` 或 `llms-full.txt` 文件的链接；
2. 对不能访问互联网的 AI，将 `llms.txt` 文件的内容直接复制到提示词中；
3. 或者，如果 AI 工具支持文件上传功能，则可以使用该功能上传 `llms.txt` 文件。
目前该标准仍处于早期阶段，但随着标准的普及，我们可能会看到 AI 系统发展出自动发现和使用 `llms.txt` 文件的能力，这会类似于搜索引擎处理 `robots.txt` 和 `sitemap.xml` 的方式。
值得注意的是，一些工具和平台已经开始支持 `llms.txt` 的集成。例如，Cursor 等平台允许用户添加和索引第三方文档（包括 `/llms-full.txt`），并在聊天中使用它们作为上下文。也有一些类似于 [llms.txt hub](https://llmstxthub.com/) 的网站为 llms.txt 提供了更方便的检索方式。
这些平台的出现表明人们越来越认识到 `llms.txt` 的价值。随着更多 AI 工具和平台集成对 `llms.txt` 的支持，其采用率和实用性可能会显著提高。因此，尽早完成适配，可能会对你的网站内容在 AI 时代占有一席之地提供帮助。
### llms.txt 工具与实际案例
目前有多种工具可以帮助生成 `llms.txt` 文件，从而简化了创建过程，使得网站所有者更容易采用该标准。例如：
- dotenv 开发的 `llmstxt` 是一个开源的命令行工具，可以基于网站的 `sitemap.xml` 文件生成 `llms.txt`。
- Firecrawl 也提供了一个名为 `llmstxt` 的工具，它使用 Firecrawl 的爬虫来生成 `llms.txt` 文件。Firecrawl 还提供了一个功能齐全的 AI 爬虫，可以创建 `llms.txt` 文件，并为大型平台提供在线生成器。
- Mintlify 是一个文档平台，内置了 `llms.txt` 的生成功能，可以为托管的文档自动生成 `/llms.txt` 和 `/llms-full.txt`。
- Microsoft 的 MarkItDown、Jina AI 的 Reader API 等，可以把任意内容转换为 Markdown，适合用来从没有直接纯文字驱动的网站生成 llms-full.txt。
- 也有一些 WordPress 插件可以用来创建和管理 `/llms.txt` 文件。
下表列出了一些可用于生成 `llms.txt` 文件的工具：
| **工具名称** | **描述** | **生成方法** | **参考链接** |
| ----------------------- | ----------------------- | --------------------------- | ------------------------------------------------------------ |
| `llmstxt` by dotenv | 开源命令行工具 | 基于 `sitemap.xml` 文件生成 | https://github.com/dotenvx/llmstxt |
| `llmstxt` by Firecrawl | 使用 Firecrawl 爬虫生成 | 抓取网站内容 | https://llmstxt.firecrawl.dev/ |
| Mintlify | 文档平台 | 自动生成 | https://mintlify.com/ |
| MarkItDown by Microsoft | 内容转换为 Markdown | 手动转换内容 | https://github.com/microsoft/markitdown |
| SLM (Reader API) by Jina AI | 内容转换为 Markdown | 手动转换内容 | https://jina.ai/reader/ |
| LLMs.txt Generator | WordPress 插件 | 自动创建和管理 | https://wordpress.org/plugins/llms-txt-generator/ |
当然，这个领域还有很多空白。因此，为你喜欢的网站内容生成工具添加 llms-txt 的支持，也许是一个你向这个项目开始进行贡献的很好的途径。
许多网站已经开始实施 `llms.txt` 标准，并展示了其在不同场景下的实际应用。我们可以在 [llms.txt hub](https://llmstxthub.com) 上找到很多现成的示例，比如：
- [Cloudflare](https://llmstxthub.com/website/cloudflare)
- [Anthropic](https://docs.anthropic.com/llms.txt)
- [Perplexity](https://llmstxthub.com/website/perplexity)
- [ElevenLabs](https://llmstxthub.com/website/elevenlabs)
- [Cursor](https://llmstxthub.com/websites/cursor)
这个标准非常适合用来帮助 LLM 在上下文中索引文档，如果你的网站也实现了 llms.txt，不妨尝试将它们也提交到 llms.txt hub，让大家更容易发现它！
### 维护有效的 llms.txt
为了确保 `llms.txt` 文件的有效性，定期更新至关重要。当网站结构发生变化时，应及时更新 `llms.txt` 文件，以确保 AI 系统获得最新的信息。我们应该使用自动化的工具来生成和更新 `llms.txt`。过时的 `llms.txt` 文件可能会误导 LLMs，反而抵消其带来的益处。
在 `/llms.txt` 文件中，应有选择地包含最重要的资源，并将不太重要的内容放在可选部分。`/llms.txt` 的目标是提供精简的概述，因此只包含最关键的资源可以使其保持简洁有效。
对于 `/llms-full.txt` 文件，建议对其进行优化以提高 AI 的处理效率：移除不必要的标记和脚本，使 AI 模型能够专注于重要的核心内容。
## 总结：面向 AI 的网络内容
采用 `llms.txt` 标准为 LLMs 和网站所有者都带来了显著的优势。对于 LLMs 而言，它提供了结构化的、易于理解的内容概述，提高了信息检索的效率和准确性。对于网站所有者而言，它可以提高在 AI 平台上的可见性，优化资源利用，并可能带来潜在的 SEO 优势和用户信任度的提升。
`llms.txt` 代表着一种向 AI 优先的文档策略的转变。正如面向搜索引擎的 SEO 曾经至关重要一样，拥有 AI 可读的内容在很近的未来也会变得举足轻重。随着越来越多的网站采用该文件，相信新的工具和最佳实践将会涌现。`llms.txt` 为帮助 AI 系统更好地理解和利用网络内容（特别是技术文档和 API）提供了一个切实可行的解决方案。各行各业对 `llms.txt` 的采用正在加速。通过提供对机器友好数据的确定性访问，`llms.txt` 降低了延迟，提高了准确性，并使组织能够站在 LLM 优化网络的前沿。
可以预见，随着 AI 与网络的融合不断加深，和 [MCP 一样](https://onevcat.com/2025/02/mcp/)，`llms.txt` 也会成为一个越来越重要的标准。
URL: https://onevcat.com/2025/02/mcp/index.html.md
Published At: 2025-02-23 12:20:00 +0900
# MCP 是什么，现状和未来
MCP (Model Context Protocol，模型上下文协议) 是由 Anthropic 在 2024 年底推出的一种开放协议，它通过提供一种标准化的接口，旨在通过标准化的接口实现大语言模型 (LLM) 与外部数据源及工具的无缝集成。
最初推出时，仅有 Claude 的桌面应用支持，市场反响平平，且不乏质疑之声。但近期，随着诸多 AI 编辑器 (如 Cursor、Windsurf，甚至 Cline 等插件) 纷纷加入对 MCP 的支持，其热度逐渐攀升，已然展现出成为事实标准的潜力。本文将帮助你快速了解 MCP 是什么、它的功能，以及笔者对未来的预测与展望。
### 三分钟看懂 MCP
LLM 的模型参数蕴含丰富的通用知识，但通常无法掌握以下两类信息：
- LLM 无法访问你的专属内容，例如文件系统中的文件、数据库里的订单，或私有 wiki 和笔记中的文本。
- 若无法联网，LLM 也无法获取实时信息，例如当前股价、最新财报、明日天气预报或前沿科技新闻。
此外，LLM 的核心功能是生成 token 和提供答案，因此它无法直接执行一些精细且需操作的具体任务，这也不是当前 LLM 的强项：
- 比如调用其他服务的 API 帮你完成订餐和购票。
- 又比如比较 9.8 和 9.11 哪个大，或者计算 Strawberry 中到底有几个 r
MCP 提供一套标准协议来解决这些问题。简而言之，它通过一组外部工具，帮助 LLM 获取其无法直接知晓的信息或者难以执行的操作。
下面是一个基本的 MCP 工作流程图，其中：
- User：当然就是用户你啦。
- MCP Client：实现了 MCP 的客户端，也就是上面提到的 Claude 桌面 app，Cursor 等一众 app，以及未来可能进行支持的各个 Chat box app 等。
- MCP Server：通常是一段运行在本地的 Python 或 JavaScript 代码。为确保安全，Anthropic 当前仅支持 MCP 在本地运行。该 Server 既可执行本地操作 (如浏览文件系统)，也能通过网络访问 API (包括第三方 API 或远程数据库)。
- 支持了 MCP 的 LLM。当前主要是 Claude 的系列模型。
启动客户端后，客户端读取配置文件，连接 server 并按照协议获取工具列表。和传统一问一答或者推理模型不同，当存在可用的 MCP 工具时，在发送用户问题时，需要把可用工具列表一并发送。LLM 将判断是否需要调用工具完成任务，并把这个指示返回给客户端。客户端如果接受到需要调用工具的指示，则按照 LLM 的指示和 MCP 中规定的调用方式，配置好参数联系 server 进行工具调用，并将调用结果再次发给 LLM，组织出最后的答案。
MCP 的具体使用以及 Server 和 Client 的实现方法并非本文重点。Anthropic 作为该协议的主要推动者，提供了详尽的文档和 SDK，开发者只需遵循这些资源即可轻松实现 MCP。
- [Model Context Protocol 介绍](https://modelcontextprotocol.io/introduction)
- [MCP Server 开发](https://modelcontextprotocol.io/quickstart/server)
- [MCP Client 开发](https://modelcontextprotocol.io/quickstart/client)
### 现状
MCP 因能有效弥补 LLM 的部分缺陷，逐渐从最初的质疑转为广受认可与欢迎。社区对 MCP 也有 awesome 的定番 repo 和同好社群，可供搜索已有的 server。最后，像是 Cline 这样的插件，甚至提供了 MCP Market。
- [awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers)
- [MCP Directory](https://mcp.so/)
- [Cline - MCP Marketplace](https://github.com/cline/mcp-marketplace)
不过，MCP 目前仍存在一些不足：
#### 安全性 vs 易用性
MCP 的设计初衷是通过本地运行服务器来确保用户数据的安全性，避免将敏感信息直接发送给 LLM，这在理论上是一个强有力的安全保障。然而，尽管服务器被限制在本地运行，其权限范围却相当广泛，例如可以非沙盒化地访问文件系统，这可能成为安全隐患。
对普通用户来说，判断 MCP 服务器是否安全颇具挑战，因他们往往缺乏评估代码或行为所需的技术能力。此外，当前 MCP 的认证和访问控制机制仍处于初步阶段，缺乏详细的规范和强制性要求。
根据当前安全标准，用户需手动克隆仓库、安装依赖并运行代码来启动 MCP Server。Cline 提供的 MCP Market 则可以让用户一键部署服务器。这种“应用商店”式的体验极大降低了技术门槛，让普通用户也能快速上手。然而，这种便利性也带来了双刃剑效应：一键部署虽然方便，但可能加剧安全隐患，因为用户可能在不完全理解服务器功能或来源的情况下就运行它。
目前，Anthropic 仅支持本地运行服务器，并计划于 2025 年上半年正式支持远程部署。不过，像是 Cloudflare 已率先推出了[远程部署 MCP 服务器](https://developers.cloudflare.com/agents/capabilities/mcp-server/)的功能，这不仅提升了易用性，还为未来的云端集成铺平了道路。但是如何在安全和易用之间寻找平衡，有没有人愿意花大力气在架设“商店”的同时进行必要的代码审核，将会是个难题。
#### 开放标准 vs AI 竞赛
目前，支持 MCP 的客户端数量非常有限，如果更多的 LLM chat app 甚至各 LLM 的 web app 能够集成 MCP，并提供一些默认的 MCP 服务器，将显著增强 LLM 的能力并推动生态发展。然而，定义和主导 MCP 的 Anthropic 自身也是模型厂商，其他模型提供商很大可能并不愿意让自家生态接入到 MCP 里。这对普通消费者来说当然不是利好，如果各家厂商更愿意提供自己的解决方案，那么混乱的生态将会成为进一步发展的阻碍。
最后，Anthropic 作为 MCP 的主要推动者，其闭源模型的背景及其 CEO 的[右倾立场](https://darioamodei.com/on-deepseek-and-export-controls)可能对这一开放协议的长期发展构成风险。MCP 作为一个开源协议，需要广泛的社区支持和信任来维持生态系统的生命力，而 Anthropic 的闭源文化可能让一些开发者对其主导地位产生疑虑。虽然开源社区强调开放和包容，但 MCP 的未来仍高度依赖 Anthropic 的持续投入。
### 未来
不管是使用 XML 还是 JSON，不管是本地二进制中寻找 symbol 还是通过 HTTP 进行交换，我们一路走来，早已习惯了使用结构化的数据格式和预先定义的 API 完成各种任务。在 API 的调用方和提供方，都需要人工维护及稳定的接口契约来规定参数类型、格式、调用方式。
随着 LLM 和 AI 时代的到来，无论是 function calling 还是 MCP 定义的协议，都迈出了新一步：它们在现有 API 上新增了 AI 友好层 (如自然语言代理端点)，实现了对传统 API 设计的渐进式改进。在调用 API 时，我们使用自然语言描述，并交由 LLM 为我们生成结构化的调用方法和参数，从而简化了 API 使用侧的负担。
但是当前 MCP 下的服务提供方 (也就是 server) 依然需要人为开发。个人预测，接下来的革命可能会发生在 API 供给侧：我们为什么一定需要结构化的调用？随着 LLM 能力越来越强，如果某些经过特别训练能够完成任务的 LLM 自身就具备当前 MCP Server 的能力，那么我们是不是可以借助模型间的对话，直接完成任务？
我愿意把这种未来形态叫做 “原生的 AI API”：各个模型理解自己擅长的能力范围，人类在使用模型时，呈现的形态同时接触分布式的多个模型，人类与一个通用模型对话，然后通用模型再选择具体的擅长该任务的“专用”模型直接进行对话或者 Token 交换。
乍听之下，这似乎与 MoE (Mixture of Experts) 相似，但这里的“专家”并非同一 LLM 中的参数，而是可能运行于其他云端甚至本地的独立模型。各部分通过自主协商来确定数据交换的方式，并可以自主寻找或者委托更合适的 agent 来完成任务。这样，多个 agent 自主组合服务链，并将信息提供给别的 agent 或者 LLM 使用。
> MCP Server 在一定程度上已经接近这个设想了，不过它现在并不是模型，只是一段固定的带有“副作用”的代码。另外，MCP Server 的通讯和发现也都是单向的。
MCP 可能只是最终通往 AI 原生 API 旅途中最初的一小步，不过多年后我们回望，可能这也会是相当重要的一步。
URL: https://onevcat.com/2025/02/reasoning-model/index.html.md
Published At: 2025-02-11 22:25:00 +0900
# 关于推理模型的一些误解和盲区
DeepSeek 给国内带来的 AI 普及和升级还在持续，虽然对于 AI 从业者和一些一直关注前沿的科技工作者来说，不论是传统 LLM 还是推理模型都不是什么太新鲜的概念了，但是对于行业外的长辈和小辈，或者是专注点刚被吸引到 AI 的业内人士来说，DeepSeek，特别是 DeepSeek-R1 的出现和爆火，可能是他们第一次真正在生活和工作里认真地接触和使用 AI。
可最近在和很多朋友交流的过程中，我也发现了大家 (其实有时候也包括我自己) 对推理式模型存在着一些常见的误解。本来其实这些疑问也可以通过询问 AI 得到解答，但是我还是把它们整理汇总一下放在这里，一方面为新接触 AI 的小伙伴们提供参考，另一方面也算是为给这个世界提供一些语料。
## 对比推理模型和通用模型
最常见的一个现象，就是大家都倾向于无脑点上“深度思考 (R1)”。其实这个行为有待商榷。
### 推理式模型一定比通用模型好吗？
不一定。它们有各自擅长的方向，无脑使用推理模型并不可取。
比如 OpenAI o1 和 DeepSeek-R1 这样的推理模型，在数学、逻辑、代码等可以明确定义正确与否的领域，表现远超通用 AI。但是在创意、写作、翻译等这类“偏文科”和内容创造性的方面，通用 AI 可能表现得更好。究其原因，这是训练方法和训练数据的不同。
通用大模型更多是使用全网文本+多领域语料综合训练。而推理模型，我们暂时不清楚 o1 的训练方式，但是 R1 在推理方面采用了纯的强化学习 (RL)，而非人类的监督微调 (SFT)；在 RL 部分，采用的数据也大多是数学和代码这类强逻辑的语料。这样的训练方法，所得到的自然是能力不同的模型。
### 那就是说我需要精心选择用哪种模型？
这倒也没有。
因为 R1 其实是在 V3 的基础上训练出来的，所以它当然也具备了 V3 的一些能力，只不过是侧重不同。相信 OpenAI 的 o1/o3 这样的推理模型，也不会是凭空而起的，它们应该也是基于前一代的通用模型进行训练的。因此虽然在本文中区分了“推理模型”和“通用模型”，但是更正确的说法应该是 R1 或者 o1 其实是“带有推理能力”的通用模型。
所以如果需要和希望进行推理，则使用推理模型会得到好得多的结果。
### 那还是无脑选推理模型就行了呗！
非也。
推理模型因为有额外的推理过程，响应速度会更慢，成本也更高。相信大家这近在使用 DeepSeek 时也深有体会，R1 常常“服务器繁忙，请稍后再试”，但 V3 就好很多。所以在响应时间比较重要的情景下 (比如使用 AI 架设客服)，通用模型能提供快得多的速度。
另外就是上面提到过的，进行创意性工作时，通用模型的没有受到太多“理科思维”影响的大脑，可能可以提供更好的创意。比如用同样的“以雪景和冰冻的河水为题，写一首借景抒情的七言绝句。”为要求，让 R1 和 V3 作诗一首，可以对比一下结果：
> DeepSeek-R1 (用时 51.6 秒)
>
> ---
>
> 飞花一夜下瑶台，冻合冰河未拟开。
>
> 欲问天涯何处是，琼林尽染待春来。
> DeepSeek-V3 (用时 1 秒)
>
> ---
>
> 寒风裹雪落长天，河水冰封漫白烟。
>
> 野树凝霜鸦雀静，苍茫一片锁江川。
从景至情，遣词造句上 R1 显是落了下风，更遑论 R1 接近一分钟的耗时对比 V3 一秒出诗的洒脱。
### 有没有什么两全其美的方法
业界已经有一些混合架构的趋势，比如使用通用 LLM 进行问题理解，然后把逻辑思考部分拆分给推理模型，最后再用通用模型组织语言润色输出，这样我们可能就可以兼得鱼与熊掌。这类混合架构是一个研究方向，但是市面上好像还没有成熟的消费级产品，也许可以期待一下。
在这样的新产品出现之前，可能人类还能够再发挥一段时间的主观能动性：对于需要探索需求边界和创意性工作时，手动切换到通用模型，然后在识别出需要精准推理的子任务时，再切换到专用模型。
## 关于 AI 的日常使用
### 使用网页版和官方 app，还是使用 API
最方便的当然是使用网页版和对应的官方 app，可以最快最直接地用上，也能在未来新特性推出时第一时间跟进。但是官方 app 隐藏了很多的细节和选项，比如定义聊天温度或者上下文数量；而使用 API 的话，可以让你根据需求自行设置这些参数。
> 声明：下面一段中提到的一些 app 和服务，是笔者认为的同类中的优秀者。笔者没有收任何广告费！
当然，使用 API 并不意味着需要你开发一个自己的聊天 app，市面上已经有不少优秀的解决方案了，比如 [Cherry Studio](https://cherry-ai.com/)、[Chatbox AI](https://chatboxai.app/zh#)、[OpenCat](https://opencat.app/zh-Hans/)、[NextChat](https://github.com/ChatGPTNextWeb/NextChat?tab=readme-ov-file) 和 [ChatWise](https://chatwise.app/) 等等。它们一般都支持填入 API Key 的无缝集成。如果你同时需要使用和管理不同平台的 API Key，选择一些聚合类的平台，比如 [SiliconFlow](https://siliconflow.cn/zh-cn/)、[OpenRouter](https://openrouter.ai/) 或者 [OneAPI](https://github.com/songquanpeng/one-api)。
使用 API 和第三方工具能够让你实现一些更进阶的能力：比如定义和保存不同的专门负责某一项事务的聊天角色，这样你就不需要每次为了类似任务重复输入提示词了。 另外，它们也会允许你调整使用模型时的参数，来获得更精准的能力。
### 自定义温度
通用模型中一个很重要参数：温度 (temperature)。温度控制文本生成的随机性，温度越高，得到的回答越发散，或者说越具有创造性；而温度越低，回答则越聚焦和合理。官方网页和 app 提供的一般都是通用问答的温度值，而如果想要更改温度值，往往我们就需要使用 API 了。一般情况下的温度设置可以参考：
| **温度值** | **生成效果** | **典型场景** |
|------------|------------------------------|-------------------------|
| **T→0** | 选择最高概率词（贪婪搜索） | 代码生成/数学解题 |
| **0