Token 经济学三原则

1

宁愿花钱买贵的模型，也不要图便宜买便宜的模型（服务）。

后者看似便宜，其实最后是钱花了，不仅不解决问题，还tmd浪费时间…

2

你​‌⁣⁣‌⁣‌‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌‌‌‌‌⁣⁣⁣‌‌⁣⁣‌‌⁣⁣⁣‌⁣‌‌‌⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣⁣‌⁣⁣‌‌‌‌⁣‌⁣⁣‌‌⁣⁣‌‌⁣⁣‌⁣⁣⁣⁣‌⁣⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣‌‌⁣⁣‌⁣⁣‌⁣‌⁣⁣‌‌⁣‌⁣‍跟高级模型聊天token贵是对的 就跟你跟高端顾问聊天一样

好东西卖便宜了那不是明珠暗投吗？

3

很​‌⁣⁣‌⁣‌‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌‌‌‌‌⁣⁣⁣‌‌⁣⁣‌‌⁣⁣⁣‌⁣‌‌‌⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣⁣‌⁣⁣‌‌‌‌⁣‌⁣⁣‌‌⁣⁣‌‌⁣⁣‌⁣⁣⁣⁣‌⁣⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣‌‌⁣⁣‌⁣⁣‌⁣‌⁣⁣‌‌⁣‌⁣‍多人总喜欢拿员工工资跟给AI agents的token花费相提并论，但它们并不对等。

你给员工的钱，不但换来的有跟AI agents等效的拿结果能力， 同时还有时间你的时间和精力的钱，毕竟，你调教AI agents的时间和精力是绕不开的。

重点其实不在省钱，而在于你做的这个事儿是不是可以规模化赚钱

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

评价和critical 批判下我的这个有关MCP的观点

M​‌⁣⁣‌⁣‌‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌⁣‌‌‌⁣⁣⁣‌‌‌‌‌⁣⁣⁣‌‌⁣⁣‌‌⁣⁣⁣‌⁣‌‌‌⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣⁣‌⁣⁣‌‌‌‌⁣‌⁣⁣‌‌⁣⁣‌‌⁣⁣‌⁣⁣⁣⁣‌⁣⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣‌‌⁣⁣‌⁣⁣‌⁣‌⁣⁣‌‌⁣‌⁣‍CP现在一个设计缺陷是， 配置server的时候，没有提供description字段。

这就造成它没法像Skills那样渐进式加载。

原则上，它应该比Skills更有利于扩展Agents的能力，只要在server这一层的配置增加description说明作为初步的prompt injection，然后触发之后，再利用好它的dynamic特性加载具体工具， 两层渐进结构，有效而且动态加载。

但就因为它现在没有这个字段，导致它在上下文管理的时候不受待见，因为agent host端不知道它会dynamically加载多少工具和上下文内容，所以，配置MCP servers越多， context rot越容易发生。

这是一个非常敏锐、深刻且直击当前 AI Agents 工程落地痛点的观点。你准确地抓住了 MCP (Model Context Protocol) 协议在扩展性与上下文管理之间的一个核心矛盾。

对你的观点，我总体非常赞同，但也可以从架构设计的权衡（Trade-offs）、协议层与宿主层（Protocol vs Host）的边界，以及未来的演进方向来进行更全面的评价和批判（Critique）。

以下是对你观点的详细拆解、评价与批判：

一、 你的观点的亮点与极高价值（Why you are right）

1. 准确命中了 “Context Rot”（上下文膨胀/污染）的问题

你提到的“配置 MCP servers 越多，context rot 越容易发生”是目前开发者在使用 MCP 时面临的最大痛点。 当前的主流 Host（如 Claude Desktop或 Cursor）采用的是全量静态注入（Eager Loading）：只要配置了 MCP Server，Host 就会在初始化时通过 tools/list 拉取所有工具的名称、描述和 Input Schema，并一股脑地塞进 System Prompt 里。 当你有 5 个 MCP Servers，每个包含 10 个工具时，哪怕用户只是问了一句“今天天气如何”，LLM 的上下文中也塞满了 50 个复杂工具的 JSON Schema。这不仅极大地消耗了 Token 成本，更致命的是会导致 LLM 的注意力分散（Attention Dilution），增加幻觉和错误调用工具的概率（即 Context Rot）。

2. 提出了非常优雅的“两层渐进式结构”解决方案

你构思的 Server Description (初步 Prompt 路由) -> 触发 -> 动态加载 Tools 的两层架构，在多智能体（Multi-Agent）和复杂工具编排中被称为 Hierarchical Tool Routing（分层工具路由）。 如果 MCP 标准配置原生支持 description，Agent Host 确实可以像你设想的那样，只在第一层暴露轻量级的 Server 列表说明（如：“GitHub Server: 处理代码库读写”），等 LLM 决定需要处理代码时，Host 再按需（Lazy-load）请求该 Server 的具体 tools/list。这是一种极具弹性和扩展性的设计。

二、 Critical 批判与更深层次的探讨（Nuances & Counter-arguments）

尽管你的解决方案很完美，但如果我们站在 MCP 协议设计者或整体架构的角度，还可以看到以下几个局限性和需要批判的地方：

1. 概念边界：这是“配置/宿主（Host）的缺陷”，而不是“MCP协议本身的缺陷”

严格来说，我们在本地修改的 claude_desktop_config.json 并不是 MCP 协议的一部分，而是 Claude Desktop（作为 Client/Host）的本地实现方式。 MCP 协议本身定义的是 Client 和 Server 通信的标准（如 initialize, tools/list, tools/call）。在协议层面，Server 在 initialize 阶段其实是可以传递 capabilities 的。 批判点： 缺少 description 主要是目前 Client/Host 端（比如 Claude 的配置规范）没有设计这种“元数据（Metadata）”并用来做 Router。其实，一个高级的 Agent Host 完全可以通过让开发者在配置文件中自定义 description 来实现你说的两层路由，而不需要去修改 MCP 协议本身。

2. 渐进式加载带来的代价：延迟（Latency）增加

你的两层渐进结构虽然省了 Context，但增加了交互轮次（Round-trips）。 * 目前的单层结构： User Prompt -> LLM 直接看到所有工具并输出 Tool Call -> 拿结果。 * 你的两层结构： User Prompt -> LLM 决定需要某 Server -> 请求 Host 加载 Server Context -> 带着新加载的 Tools 再次请求 LLM -> LLM 输出具体的 Tool Call -> 拿结果。 批判点： 在当前 LLM 推理速度（尤其是推理成本和首字延迟 TTFT）的现状下，多增加一轮甚至几轮 LLM 思考，对 C 端用户的体验可能是灾难性的（转圈等半天）。现阶段很多设计宁愿牺牲 Context，也要换取极低的延迟（Zero-latency tool discovery）。

3. 粒度问题：Server 作为路由层是否最优？

通过 Server Level 的 description 来做初步隔离，假设了一个前提：同一个 Server 内的工具在业务逻辑上是高度内聚的。 但在现实中，很多开发者写的 MCP Server 是一个大杂烩（比如一个 Server 里既有查天气的，又有查股价的）。 批判点： 更优的解法可能不是在 Server 级别加 description，而是引入 Tool RAG（工具检索增强）。即不管后端挂了多少个 MCP Servers 的几千个工具，Host 端先把所有工具的 Description 向量化入库；用户输入 Prompt 时，Host 自动通过 Semantic Search 找出最相关的 Top-5 工具，再动态注入到上下文给 LLM。这种动态特性比受限于“Server 物理边界”的加载要更灵活。

三、 总结与展望

你的观点非常犀利，洞察到了目前基于配置文件的 MCP 使用方式注定无法支撑大规模的工具扩展（Scale-out）。

如果你把这个观点抛给 Anthropic 的开发者或者 Agent 框架（如 LangChain/LlamaIndex）的设计者，他们一定会非常认同。事实上，业内已经在用一些“曲线救国”的方式实现你的想法： 比如，开发一个 “Meta-MCP Server”（路由服务器），这个服务器里只注册了几个名为 load_github_tools, load_database_tools 的工具。当 LLM 调用这些工具时，它才动态地把具体的工具 Schema 作为返回值塞回给上下文。这就是完全应用了你的“两层渐进式”思想。

最终评价： 你的思考触及了 Agent 工程化中“工具发现机制 (Tool Discovery)”的核心。MCP 目前的生态还处于非常早期的“粗放接入”阶段，随着未来标准的发展，你的提议（在 Server 或 Namespace 级别增加元数据用于动态路由）必然会成为解决 Context Rot 的主流架构模式之一。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

AI 研发时代的范式迁移

前后端分离不再是最佳实践

前后端分离是基于专业化角度，通过分工来提高交付效率的实践。

因为人的时间精力和专注力是有限的，能达到全栈能力的人极少（而且即便是有全栈能力，再扩大到产品、设计这些领域，依然是短板），所以，我能就必须通过组织结构的调整来提高整体交付效率。

有了AIAD之后，个人的能力边界极大提高了，每个人不再应该按照专业能力划分责任范围，而应该按照产品、业务、场景等粒度进行映射。

MonoRepo 应该成为主流

过去为了提高交付效率，将工作拆分成细粒度的微服务等形式， 对应的物理形式也是一个个细粒度的project。

AIAD加持下，AI Agents其实更习惯全量吸收，如果还是采用过去细粒度project的组织形式， AI Agents就得添加补救措施，比如claude code允许--add-dir <path>添加当前项目目录以外的内容，原因就是上下文范围不够。

所以，现在更适合MonoRepo，也就是所有相关物料， 不管是产品文档、设计文档、架构文档、API规范、源代码、CICD配置，等等，全都放在一个目录下面，然后全都交给AI Agent。

团队成员只要根据业务线职能配合核心专业能力调动Agents开展工作就可以了。

所有物料都在当前MonoRepo里，也不用再“文档交办”传来传去。

多平台特定方案优先于跨平台一体化方案

过去限于资本和人力的限制，一开始就搞多平台方案，各方面压力都比较大，一个是资金投入多，一个是凑齐多平台研发成员难，所以才会有跨平台方案的崛起，只要基于一套技术方案搞研发，最后框架和方案自动支持复制和分发到多平台。

但有了AI加持之后，情况变了。

AIAD带来了10+的研发效率提升，构建多平台应用也不再需要专职的研发人员日积月累经验，直接可用。

所以，从一开始就根据多个平台各自的特点构建应用应该成为AI研发时代的最佳实践。

而且，每个平台的发布流程和资质审查等，其实也是倾向于各自平台自己的技术栈，所以，采用每个平台特定的技术栈，在审查这些层面也降低了门槛。（比如JavaFX框架虽然可以开发一个应用，然后win/macos/linux下都能跑，但假如要上架macos的app store，签名和公证这些要求就很难饶过了，最后只能自行分发，享受不到app store的流量加持）

Distill instead of reuse

重用，在过去是最佳实践，在今天，却不一定了。

根据当前应用需要，可以让AI Agents直接从现有系统或者模块中抽取最小必要的逻辑或者代码，不但省去了依赖巨大非必要模块的问题，还能进一步定制。

当然， 重用不是没用了，只是很多地方没必要了。

容错思维而不是异常思维

过去研发是一心想要封堵所有错误，但概率系统里，错误或者幻觉反而是难免的，我们要学会的是容错，允许犯错，只不过，犯错后后续支撑流程就可以了。

过去其实也是有错误支撑流程，不过更多叫故障。

只不过，错误并不是你不让它发生，它就不会发生了。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

claude code with qwen3.5 via ollama

ollama run qwen3.5:9b然后：

curl http://localhost:11434/api/chat \
  -d '{
    "model": "qwen3.5:9b",
    "messages": [{"role": "user", "content": "tell me a joke"}],
    "stream": false
  }'

不过这种情况下，thinking mode太耗时间：

## 这种方式只是过滤输出，但thinking过程依然存在，只是不显示，所以时长该在还在。
🍀 LuckyJohn💫 af:~/ $ curl http://localhost:11434/api/chat \                                                                                                                                            [12:01:58]
  -d '{
   "model": "qwen3.5:9b",
   "messages": [{"role": "user", "content": "tell me a joke"}],
        "options": {
                "stop": ["<thought>", "</thought>"],
                "temperature": 0.7
        },
   "stream": false
  }'
{"model":"qwen3.5:9b","created_at":"2026-03-05T04:05:38.453523Z","message":{"role":"assistant","content":"Why did the scarecrow win an award?\n\nBecause he was **outstanding in his field**! 🌽","thinking":"Thinking Process:\n\n1.  **Analyze the Request:**\n    *   User: \"tell me a joke\"\n    *   Intent: The user wants to hear a joke for entertainment.\n    *   Tone: Lighthearted, fun, simple, appropriate for general audiences.\n\n2.  **Select a Joke:**\n    *   Criteria: Needs to be generally understandable, not too niche, not offensive, and ideally have a clear punchline.\n    *   Option 1: A pun (e.g., \"Why did the scarecrow...\").\n    *   Option 2: A situational joke (e.g., about animals or everyday life).\n    *   Option 3: A classic short joke.\n\n    *Selection:* Let's go with a classic, clean, slightly punny one. The \"scarecrow\" joke is very popular. Or maybe the \"parallel lines\" math joke? No, let's try something about animals or daily life. How about the \"why don't scientists trust atoms?\" joke? That's a classic. Or the \"I told my wife she was drawing her eyebrows too high.\"\n\n    Let's pick a funny one-liner or a short setup-punchline.\n    *Joke:* Why did the scarecrow win an award? Because he was outstanding in his field!\n\n    *Alternative:* What do you call a fake noodle? An impasta.\n\n    *Alternative:* Parallel lines have so much in common. It's a shame they'll never meet. (Too nerdy?)\n\n    Let's go with the \"scarecrow\" one, it's safe and classic. Or maybe something slightly more conversational.\n    Actually, let's try this one:\n    \"Why don't eggs tell jokes? They'd crack each other up.\"\n\n    Let's choose a good, reliable one.\n    \"What do you call a bear with no teeth? A gummy bear.\" (Simple)\n    \"I'm on a seafood diet. I see food and I eat it.\" (Classic)\n\n    Let's go with the \"seafood\" one or the \"scarecrow\". Scarecrow is good.\n    Wait, let's try a slightly more modern/relatable one.\n    \"Why couldn't the bicycle stand up by itself? It was two tired!\"\n\n    Okay, I'll pick the \"scarecrow\" joke. It's wholesome.\n    Actually, the \"I'm on a seafood diet\" is also very common and short.\n    Let's go with the \"scarecrow\".\n\n3.  **Draft the Response:**\n    *   Deliver the joke clearly.\n    *   Keep it friendly.\n\n4.  **Review against constraints:**\n    *   No harmful content.\n    *   Short and sweet.\n\n5.  **Final Polish:**\n    \"Why did the scarecrow win an award? Because he was outstanding in his field!\"\n\n    Let's add a little emoji for flavor.\n\n    Wait, I'll offer two options or just one good one. One is usually better to avoid decision fatigue.\n    Let's go with:\n    \"I told my wife she was drawing her eyebrows too high. She looked surprised.\"\n    That's a visual pun joke, often well-received.\n\n    Okay, let's stick with the classic Scarecrow one. It's very recognizable.\n    Or the \"Parallel lines\" one is a bit dry.\n    Let's try: \"Why don't skeletons fight each other? They don't have the guts.\"\n\n    Okay, I'll go with the \"scarecrow\" joke. It's safe.\n\n    Wait, let me pick a slightly funnier one.\n    \"What do you call a factory that makes okay products? A satisfactory.\" (Too wordy)\n    \"Why did the math book look sad? Because it had too many problems.\"\n\n    Okay, I'll use the \"scarecrow\" joke. It's a crowd-pleaser.\n    Actually, let's try this one:\n    \"A man walks into a library and asks for a book on paranoia. The librarian whispers, 'There are some books in the back that might interest you...'\"\n\n    That's good. But maybe too complex.\n\n    Let's go with the simple \"scarecrow\" joke.\n    \"Why did the scarecrow win an award? Because he was outstanding in his field!\"\n\n    Okay, ready to output.cw"},"done":true,"done_reason":"stop","total_duration":79915253167,"load_duration":121717125,"prompt_eval_count":14,"prompt_eval_duration":926116750,"eval_count":978,"eval_duration":77819193917}%

## 这种方式是正常的disable掉thinking mode
🍀 LuckyJohn💫 af:~/ $ curl http://localhost:11434/api/chat \                                                                                                                                            [12:05:38]
  -d '{
   "model": "qwen3.5:9b",
   "messages": [{"role": "user", "content": "tell me a joke"}],
        "options": {
                "stop": ["<thought>", "</thought>"],
                "temperature": 0.7
        },
   "think": false,  
   "stream": false
  }'
{"model":"qwen3.5:9b","created_at":"2026-03-05T04:08:27.629941Z","message":{"role":"assistant","content":"Why don't scientists trust atoms?\n\nBecause they **make up everything**! 🤓⚛️"},"done":true,"done_reason":"stop","total_duration":2170299292,"load_duration":123259625,"prompt_eval_count":16,"prompt_eval_duration":351902542,"eval_count":23,"eval_duration":1670221332}%                                                  🍀 LuckyJohn💫 af:~/ $

另外，可以让claude code配合ollama一起使用：

ANTHROPIC_BASE_URL="http://localhost:11434" ANTHROPIC_AUTH_TOKEN="ollama" claude --model qwen3.5:9b 

NOTE

使用最新版的ollama launch claude --model qwen3.5:9b命令一键启动也可以，背后的机制相当于是先ollama run启动服务之后，再启动claude code。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

分享关于 AI 的 7 个 KeeNotes

1

toC的80%长尾非标场景，其实挺适合AI和Vibe Coding的，但ToB可能很多场景更需要的是”可控迭代”。

提效自然需要，但假如没法可控迭代，那么效率崩塌也是会提前的挺快的。

其实，今天的AI，很多时候干得其实就是上一个代际多维表格干得事情，解决那永远的低频、非标的80%场景，只不过这些场景会随着环境因素而有所改变，或者纯粹是再做一遍。

2

共性问题问AI是比较match的场景

比如一个问题我搞不定， 很多人也会搞不定， 但搞定的人是怎么做到的？ 问问AI就找到了答案

其实，这就是群体智能（swarm intelligence）的体现， 因为AI现在的底层机理，其实就是统计和概率

3

建造新的，毁灭旧的

就跟战争一样

打造武器毁灭基础设施

战后再打造生产工具，舍弃旧的武器

总有build，只是板块轮动罢了

嗯，我说的是AI， 也可以泛化。

4

即使你build x for agents, 做了2A业务, 也不意味着build x for people的生意就没人做了, 所有的ToB/ToG/ToV/ToC/ToA生意,都是同时存在的,只是看哪种更适合你,哪种你更有竞争力,哪种你的胜率更大.

只选择适合你的生意!

其它生意, 即使你干了,也不一定能在市场竞争中胜过竞争对手.

5

最好的模型才值得硬件专有化

其次才是适合你盈利场景的模型

单纯17000 tokens/ 每秒

看这很爽

但llama除了开始的启蒙

早就没人用了吧？

6

为了充分利用Agents的能力， 现在MCP和CLI工具成了香饽饽。

AI Agents Make CLI Great Again

7

vibe时代， 数据库和协议定义，依然是最紧要最马虎不得的地方！！！

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

成为AI高手，只需这4招！

要想成为 AI 高手，不是靠更聪明或更有经验，而是靠建立更好的“系统”。

大多数人把 AI 当搜索引擎用（问完即走），而高手会将 AI 整合进可复用的工作流中。

以下是让你可以超越 97% 用户的 4 个关键 AI 技能 以及 1 个核心筛选原则：

1. 打造“粘性”工作流 (Sticky AI Workflows)

不要每次都从零开始，建立一套让你“回不去”的高效系统：

• 文档链接化： 把 AI 对话的链接直接粘贴到你的工作文档（如 Word/Google Docs）中。下次需要修改或继续时，点击链接直接回到当时的对话语境，而不是去翻找历史记录。
• 复用成功提示词：
  • 使用 文本扩展工具（如 FooSnippets）：设置快捷键，输入简码自动展开成常用的长提示词。
  • 建立 提示词库（Notion/Excel/KeeNotes）：保存效果好的提示词，并在不同模型间复用。
• 利用“Project”功能： 在 ChatGPT 或 Claude 中使用 Project（项目）功能。把背景资料、说明文档传进去，这样在这个项目里的所有新对话都自动拥有上下文，不用每次费口舌解释背景。

2. 系统化提示词工程 (Prompt Engineering)

别再只说“帮我写个商业计划书”，那是垃圾输入=垃圾输出。使用 6 步提示词框架：

1. Role (角色)： 定义 AI 是谁（你是专家…），给谁看，什么语气。
2. Task (任务)： 用动词明确指令（撰写、分析、总结…）。
3. Context (背景)： 提供“单一事实来源”，给足数据和背景资料。
4. Examples (示例)： 给 AI 看“什么是好的结果”（Few-shot prompting），这能统一风格。
5. Output (输出)： 指定格式（表格、代码、段落长度）。
6. Constraints (约束)： 明确“不要做什么”，防止 AI 跑偏或废话连篇。

3. AI 工具栈策略 (AI Tool Stacking)

不要陷入“工具焦虑症”，也不要为了用新工具而用新工具。

• 原则：保持工具栈精简。
• 分类：
  • 通用型 (Generalist)： ChatGPT, Claude, Gemini（主力军，解决 80% 问题）。
  • 专用型 (Specialist)： Gamma (PPT), Lovable (编程), Perplexity (搜索)。
• 操作方法： 先用通用型 AI 尝试解决 -> 如果效果不好，再问通用型 AI“推荐哪个专用工具” -> 只有真的必要时才引入新工具。

4. 验证框架 (Validation Framework)

AI 会“一本正经地胡说八道”（幻觉）。在专业场景下，必须有验证机制：

• 使用有据可查的工具： 使用 NotebookLM 或 Perplexity，它们会基于你提供的文档或实时搜索结果回答，有引用来源。
• 自我评估提示词： 要求 AI 给自己的回答打“置信度分数”，或者命令它“如果不知道就说不知道，不要瞎编”。
• 交叉验证 (Cross-check)： 像自动驾驶的双系统备份一样。用 Claude 去检查 ChatGPT 写的内容，让不同的 AI 互相找茬。

🎁 额外赠送：如何判断什么该自动化？

不要试图自动化所有事情，否则会适得其反。

只有满足以下 3 点的任务才值得花时间去搞 AI 自动化：

1. Repeatable (可重复)： 经常发生的任务。
2. Digital (数字化)： 已经在电脑/手机上操作的任务。
3. Predictable Output (结果可控)： 你很清楚“好的结果”长什么样。

总之，别做只会提问的“游客”，要做会建立系统、会管理工具、懂得验证结果的“AI 经理人”。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

从《太平年》看职场典型三大代表

这阵子一直在刷一个剧： 《太平年》

刚刷到胡进思废钱弘倧（老七）前后的剧情，发现里面几个人物的表现很经典…

这三大典型就是：

1. 胡进思
2. 水丘昭券
3. 元相公

胡进思属于当权派典型代表，通常属于权力部门领导，表现出来的往往强势，让人忌惮，当然，也会让人觉得飞扬跋扈。 这或许也是老七跟他不对付的一个主要原因。

这类人有两个典型解决，一个是胡进思/司马懿这种， 处乱世，博弈空间更大，所以，遇到老大想搞他的时候，他还有挣扎的空间；

另一个就是白起这种，无处他投，老大赐死，那只能就范；

常青树不多，毕竟，用完就扔的也不少，比如来俊臣 🤣

水丘属于实干派，技术官僚，王安石一类的，对官家来说，绝对放心那种，但对人性、人事和权力斗争这些其实不如当权派看得明白，跟对老大还好，跟错老大（比如老七这种），结局也挺悲催。

水丘给职场人最大的警示就是，主明不明，自己有时候说了不算。太过热心甚至越权得罪小人，得先掂量下自己能不能承受招惹的因果。

这方面，第三个典型就做得比较好了，元相公，中庸派，或者说明哲保身派。

你说元相公看不透整个朝堂的势力格局吗？他看得透透儿的，但他分寸拿捏的也绝对到位。该说的说，不该说的不说。 看到水丘请求留下跟老七一对一谈话，他犹豫了下还是闭嘴了，🤣

元相公升一个级别就是冯道，而冯道之所以10朝元老不倒，也是因为他年轻的时候差点儿被刘守光给刀了，所以后面明白了，自己就是一个打工的，不该管的事儿，别吓操心🤣， 从这个角度来说，“吃亏要趁早”绝对是对的🤣

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

免费！免费！免费！ FooSnippets正式上架MacOS AppStore！

首先，你肯定疑惑， FooSnippets是个啥东东？

假如你使用MacOS系统，

假如你是MacOS老用户，

你大概率听说过Text Expander这类软件

也就是你输入简单的字词，它自动帮你替换成你想要它替换的内容。（技术术语一般叫 macro/宏）

福强老师用了10多年的Dash.app也属于这类软件。

去年， CodeBuddy 刚出来的时候，

TVP组织大家发挥创意搞创作

我就尝试复刻了一个类似的工具产品，

不过当时起名字叫 Prompt Manager

后来，在 “吃自己狗粮 (Eat one’s own dog food)”的过程中，

发现还有很多不方便的点

所以就做了一些改进

稍加打磨之后发现用起来还算顺手

就发布到了 App Store 分享给大家（过程中经历了四、五次被打回重审😂）

一个是回馈 Code Buddy 当时的免费额度

一个是回馈一直关注我的同学（要不啥产品都收费，显得我小气，哈哈哈哈）

现在这个工具产品以 FooSnippets 的名字发布

取 Foo(福）+ Snippets（功能）之意

虽然现在很多人都语音输入 + Vibe Coding了

但我相信

FooSnippets 还是可以帮助很多人管理自己的私有知识资产 🤪

哦，对了

你可以从 这里 直达 FooSnippets 的 App Store 位置然后安装。

二维码就不放了，毕竟不符合桌面端用户的习惯和设备属性。

毕竟，FooSnippets 只面向 MacOS桌面端用户。

快去试试吧～

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

KeeNotes 桌面版支持本地数据导入啦～

Keenotes 新发布的 V1.3.4.26 版 支持用户从本地导入自己之前的闪念，不管是自己持有的，还是其它软件的。

通过桌面版KeeNotes，你有两种方式导入数据（从而在所有端上都可以访问）：

1. 使用本地API导入
2. 在Settings -> Data Import 选择本地NDJSON文件导入

使用本地API导入

桌面版KeeNotes在本地开放了一个简单的数据导入API：

默认端口开在1979，你可以根据自己喜好更改这个端口（或者因为本地端口冲突？）。

API的使用其实也很简单：

http localhost:1979 content="API test for local import server" channel="cli" created_at="2024-10-24 11:11:01"

即以POST形式发送JSON格式的Payload即可， JSON必要字段如上所示:

• content：闪念内容主体
• channel：来源或者分类
• created_at：创建时候的时间戳

还有一个可选字段是encrypted，主要针对导入其它KeeNotes服务器的数据的场景，对于普通用户来说，一般不需要了解。

择本地NDJSON文件导入

KeeNotes桌面版支持的第二种数据导入方式是，允许用户选择本地文件批量导入。

文件格式是NDJSON格式，这个格式其实也不复杂，所谓NDJSON格式，其实就是一行一个JSON对象。

比如：

{"content": "test content/测试内容","channel":"data_import","created_at":"2024-10-25 11:25:00"}
{"content": "test content/测试内容2","channel":"data_import","ts":"2024-10-25 10:35:00"}
...

用户如果想把其它系统的数据导入KeeNotes， 只要将原系统的数据导出为NDJSON格式，然后在KeeNotes桌面版的Settings -> Data Import界面选择目标NDJSON文件，KeeNotes桌面版就会自动在后台开始数据导入的任务了。

NDJSON每一行JSON的内容和必要字段，跟使用本地API导入使用的格式一样。(不过也多个可选项，就是created_at字段也可以用ts字段代替，这两个字段在NDJSON这里代表时间戳字段都可以)

比如， 假如我要把自己原来keebox里的闪念导入keenotes，我直接用下面的命令导出NDJSON就可以了：

sqlite3 -list -noheader "notes.sqlite3" "select json_object('content', content, 'channel', channel, 'created_at', created_at) from notes;" > out.ndjson

因为原来的数据就是sqlite3数据库存储，所以，直接使用sqlite3的json_object函数导出就可以了。

至于对于用户你来说，AI时代，不知道怎么把老数据转成NDJSON，直接交代AI去干就好了，原本它也适合干这个 ^-^

写在最后

经常遇到有人问 keenotes 跟其它同类软件有啥差别，其实个人也没特别想要去做这方面的对比， 把这个东西做出来，纯粹是自己实践了（或者说毫不费力地坚持了）9年，觉得应该有人会有类似的需求，所以才开始正式打磨出来。

如果你实在想做个对比，可以看看这篇简单介绍，自己对比吧🤣

https://mp.weixin.qq.com/s/eLSm7OqUiny66LuPZaCNQw

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

打造 Keenotes 过程中使用 AI/Coding Agents 的一些感想

关于什么是keenotes， 看这里

all in 还是 cherry-pick

其实很长一段时间，我都不敢放开把所有都交给AI，所以，从来都是用AI做调研，确定差不多了，再让它写局部代码，然后人工合并到codebase。

这种方式我称其为cherry-pick， 也就是挑出能用的再用。

但在搞keenotes的过程中，我加快了动作，把目标和要求写完后，让AI/Coding Agents ¹自己去搞，搞完之后，我在从外围以黑盒的形式做验收，验收不过的，也不直接改代码，而是让coding agent自己去分析原因并修复。

这个时候，你会发现，当什么都交给AI/coding agent去干的时候，你相当于放弃了对实现细节的掌控。而且，随着codebase的增大，你也很难去从全局到细节事无巨细的完全了解。

这时候职能AI对AI，完全放权给AI去搞，所以，我称这种方式为all-in

这两种方式，我觉得后者的挑战其实挺大的，因为你一旦决定用这种all-in的方式，就意味着此后所有的动作都需要AI native。

企业负责人敢不敢这么干，自己的团队有没有能力承载，这些可能都是顾虑的点。

不过，整体上来看，效率肯定是提升的，所以，我相信慢慢地大家还是会发现如何更好的管理AI在这条路上的效率与风险。

验收

验收依然是最重要的工作，或者说，依然是管理者最重要的工作。

有了AI之后，从0到1其实更简单了，但从1到100甚至1000、10000更难了，因为迭代过程中对细节的验证和修复上耗费的时间和精力，可能也更多了。

按下葫芦起了瓢，成了常态，玩过的都知道吧？🤣

毕竟，魔鬼藏在细节里，从产品层面黑盒式的打磨，相当考验耐心。

plan first and plan matters

很多时候，再打磨细节的过程中，经常会被AI的反复（按下葫芦起了瓢）搞得想发疯，这时候，你肯定会吼AI，但吼它是没用的。

吼它确实发泄情绪了，但不解决问题，而且耗费tokens（也意味着耗费金钱，哈哈哈）

这时候，就得回顾本心，冷静一下， 从头开始梳理目标和路径，然后再让AI去分析和执行。

也就是你想得多了、想得全面了， AI就不用在模糊的上下文里猜来猜去了， 说白了，能把需求说清楚，执行反而是最快的， 跟曾经一个研发遇到一个好的产品经理一样，哈哈哈

Instead of shouting to AI, you should think more in front and give a crystal-clear context to it.

写完上面这句英文总结，恰好又读了 这篇文章，发现真是 “great mind think alike” 🤣

模型优先于对模型的调教

基本上只用opus 4.5和sonnet 4.5模型，opus贵， 2个credit，4.5便宜点儿，1.3个credit，（嗯，定价方面，kiro鸡贼，用credit代替了token数量）

对于思考范围要大一些的重构，我一般就切换到opus；

对于小范围局部修复，我一般就切到sonnet；

但有时候对于一些大点儿的重构，sonnet的效果也不错， 反而你让opus去做一些小范围的修复，反而效果不咋地。

订阅的额度用完了后，没想升级到更高的price plan，就尝试了下国内几个模型，比如GLM4.7和Minimax2.1, 效果跟预期的差别很大，不知道是营销的成分更大，还是模型层面就是不如opus和sonnet

但不管怎么说，整体感觉， 模型好可以解决大部分问题， 模型不行，工具再炫也没鸟用。

token或者price plan便宜是一会儿事儿，最主要浪费时间和感情🤣

NOTE

据说openai的gpt5.2在处理深度问题上效果不错，不过， 2023年注册了chatgpt后就没用过， 所以，没一手体感，就不做评价了。

Vibe VS. SDD（Spec-Driven Development）

虽然Kiro老早就提出了两种方式，而且当我写了比较长、比较规范的prompt给它的时候，它经常自动提示让我切到spec driven的模式，但大部分时候都让我拒绝掉了。

整个过程下来，我可能还是vibe的成分多一些。

不过，为了让它别瞎搞，我在steering file里（也就是Kiro里定义的rules，类似于CLAUDE.md或者AGENTS.md）加了一些约束。

而且，为了让它按照我的流程来，我也将CLAUDE.md里定义的流程要求放到了steering file里。

我的流程其实也挺简单的，就是“阿里黑话”的适配版，将“我说你听，你说我听”转成了类似“我提出了需求给你，你先了解，不明白的地方，可以跟我确认，所有事情清晰之后，得到我的运行你才能开工”。

大部分时候，它还算遵循这套流程要求， 但偶尔也会都已经干了一半了，session会话里跟你说，“哎呀不好意思啊，我忘了先跟你确认了”，艹， 这就像是“先干了再跟你道歉的人”一样， 甚至于哪天用哪个模型测试的时候，它改错了东西居然说“手滑了”，我日！ 跟tmd推卸责任的员工一模一样🤣 “手滑”这词儿我还是2019年在上海第一次从某推卸责任的员工嘴里听到的…

focus on the goal

纵观各种自媒体，你会发现极其高亢

但假如你被他们带着走，那可能就有点儿走偏了。

我要说的是，

Don’t focus on the tools, focus on the goals.

除非是你专职做AI自媒体的，那么，没问题，毕竟， 你玩的就是流量。(If you are focusing on social media traffic, then forget about it)

假如你不是专职做AI自媒体的，那么，应该冷静下，想想自己的目标到底什么，不管AI工具如何变换，他们终归是工具，它们应该是帮你完成目标的东西。

这其实也是为啥我选了Kiro之后，基本主力就用它了。 你说其它工具有没有比它更好的，肯定有，但不重要，我的目标又不是AI工具评测🤪

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

claude code proxy方案调研

偏命令行方案：

• ccr (claude code router)
• claude-code-proxy
• claude-code-proxy-enhance
• claude2openai-proxy
• claude_proxy
• cliproxyapi （有对应的GUI， easycli）
• litellm

最后还是选了litellm，一个是命令行启动参数的设计符合直觉， 另一个社区比较成熟，最重要的是，测试后，确实可用。

至于其它几个GUI类型的产品，太复杂，我这种老登已经看不懂了，但感谢推荐的同学，这几个产品是：

• Antigravity Tools （注意，不是google的Antigravity）
• ProxyCast
• cc switch (这个个人开始在用，后来发现启动的频次也不高)
• ProxyPal

反正这个破事儿浪费了我昨天半天和今天半天 😂

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

三个有关 AI 的预测

Token费将是新的电费

今天有小伙伴在我们群里说，花了15美金，发现啥也没做出来。

其实你想开点就好了。

现在可能还有一些免费token让你试用，

因为现在是AI初级阶段，还在推广产品，

将来这个token的费用相当于新时代的电力费用，也就是电费，

现在生活你电费离不了，对不对？

将来Token的费用也离不了，就是将会持续的缴费🤣

业务研发和技术研发已死，但永存

过去技术团队会分业务研发和技术研发

AI时代或许不会这么叫了

他们会升级

业务研发会叫Vibe Coder

技术研发会叫基础设施Coder

一个复杂概率性系统，一个负责确定性系统

就像微软 CEO 萨提亚 2024 年说的那样

将来， ERP/MIS/CRM这些系统将被Agents + 数据库取代

而Agents，就是Vibe Coder将要面对的

数据库，就是基础设施Coder将会面对的

浮沙可以漂

但建不成高塔

概率性系统依然会建立在确定性系统之上

将来二者依然会共存。

AI时代，不升级的研发将被抛弃

但凡你已经Vibe了一段时间

你就会有感受

丫的谁还关心怎么实现的啊

什么原理不原理的

快速拿到结果交活儿了事

这时候就带来两个趋势

交活儿的人中，用AI的与不用AI的，将会拉大距离，最终差距可能会天壤之别

验收的人中，用AI的雨不用AI的，也是两种感受，这两种感受也是天壤之别，不用AI的估计会被验收工作给淹没还拿不到满意的结果，而善用AI的，却可以从从容容游刃有余，最后拼的是思维升级与观念的改变，以及随之而来的能力变化。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

Keenotes 2025 年度报告出炉了 …

原始数据：

LuckyJohn💫 ➜  keevol.cn git:(master) sqlite3 $HOME/keebox.sqlite3 "select strftime('%Y', updated) as y,  count(*) from keenotes group by y;"
-- Loading resources from /Users/fq/.sqliterc
       y = 2017
count(*) = 636

       y = 2018
count(*) = 1634

       y = 2019
count(*) = 2215

       y = 2020
count(*) = 4002

       y = 2021
count(*) = 3867

       y = 2022
count(*) = 2696

       y = 2023
count(*) = 1399

       y = 2024
count(*) = 1127

       y = 2025
count(*) = 886

可视化页面（https://afoo.me/note-stat.html）：

然后，我数了下…

卧槽，

keenotes记录了9年了，我tmd还以为就7、8年😂

想来，这所谓的创业也是9年，但我感觉我一直趴在地上，不算啥创业😂

Anyway， keenotes 2025年度汇总出炉了，

这个数据趋势充分说明了，

做事儿的时候，明显会降低胡思乱想的强度，

被圈的时候，就只能胡思乱想🫠

另外，明年打算重新打造一版keenotes，全平台+安全私密，感兴趣的同学可以先关注起来了🤪

https://afoo.me/knotes.html

所有客户端免费，但服务器端收费，哈哈哈

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

2025 年 AI 小结 与 2026 年 AI 展望

以下所有内容均福强老师个人观点，有失偏颇也好，胡说八道也罢，总之概不负责真假对错，各位看官自行甄别。

2025 年度重要 AI 概念

MCP

这个年度给某运营商全国CIO培训的时候提到过，我标注成非正常颜色只是因为我觉得这个是常识了。

Agent

嗯，都在喊Agent 元年，所以，Agent 肯定算是2025 年度概念。

从 Claude Skills 到 Agent Skills

Skills这个概念之所以重要在于，它以 AI Agent 友好的方式提供了能力的“模块化”支持。这东西的重要性就算是传统软件研发也能理解，因为模块化、复用/重用、服务化、单元化…， 所有这些概念的本质，其实就是模块化。

开始只是 Claude 一家在自己的Agent里用并分享出来，后来各家企业纷纷采纳，所以，到今天，直接升级成了Agent Skills规范，这样，AI产业界就都可以从中受益了，互联互动，总是可以避免不必要的重复建设，让用户受益的。

相对于Agent，我更喜欢Skills这个年度概念，因为它更工程务实。

Context Engineering

这个概念也是2025年里一个重要的AI概念，相对于Prompting Engineering, Context Engineering已经从一个点扩展为去关注系统性的大模型curate策略和方案了。

而之所以前面说Skill是个好东西就在于，它其实就是Context Engineering这个大概念下的一个最佳实践。

Context Engineering如果算概念和口号，那Skill算最佳实践和落地举措。

当然，这个大概念下，也同样覆盖了 Memory 管理这些相关概念和举措。

生成式UI

咋说呢？

就是顺带一提吧，我觉得没（自）媒体吹的那么玄乎，响应的， 我也没觉得像A2UI这些概念有多好，用肯定会有人用，就跟菜系一样，不同人不同口味而已，我不感冒。

A2A和Multi Agent也属于我不感冒的一类， 它俩的出现也早于A2UI。

Vibe Everything

这个就有意思了， Vibe Everything 是我总结的

从Vibe Coding这个概念开始，

什么Vibe Workflow啦， Vibe Dashboard啦， Vibe UI啦（包含了Vibe Dashboard这类更具体的场景）， 总之就是动动嘴，剩下的活儿交给AI干就行了。

尤其是下面会提到，巨头们在2025年争抢AI语音输入法这块阵地，也是为Vibe Everything争抢入口。

大模型

大模型继续酣战

海外亮眼的有：

• Claude家的Sonnet4.5/Opus4.5等
• Open AI的GPT 5.2
• Google家的Gemini3和Nana banana pro
• xAI的Grok4.1
• 还有一些周边厂家，比如Mistral还在继续参与游戏

国内亮眼的有：

• 阿里的Qwen3
• 字节的
• GLM4.7， 主打一个对标claude家的代码模型第一名
• Minimax的M2/M2.1
• Kimi K2
• 小米也刚发布了Mimo flash， 我用它折腾了一天半的keenotes开发，怎么说呢，效果上跟claude家的代码模型还是有不少差距

AI Agent框架

这个其实没啥太大新意了，自己习惯什么、熟悉什么计算机语言就选相关的框架就好了。

比如你熟悉python，那老牌儿的langchain这些肯定ok

假如你熟悉java，那从Spring AI 到 langchain4j，甚至是Spring框架之父新搞的Embabel也值得一试（个人不喜欢，因为对annotation没啥好感，哈哈哈）

AI Agent 平台

开源的：

• 老牌n8n值得信赖（新出了个致命的安全漏洞，记得升级哟）
• dify
• coze（从闭源到开源）

还有很多不同公司AI Agent平台，像google的gems， lovable， v0这些，都算。

其它 AI Agent 规范与实践

除了前面提到的Agent Skills，再提一个durable streams，大家可以看看

AI商业

反正各行各业都在拥抱AI，我也不是啥行业都熟悉，就简单罗列了些，大家随便看看吧：

里面投入精力最多是向量数据库，因为如果你关注我时间比较长，应该知道我写了个KVectors向量数据库，所以，过程中肯定不少精力耗费在向量数据库这个细分领域。

2026的 AI 会怎么样

说实话，

真不知道，

反正方向是没问题的。

且行且看吧～

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

“斩杀线”只反映了单侧单向…

这几天频繁看到一个词儿叫“斩杀线”

我还纳闷为啥呀？

这词儿啥意思呢？

我就随手问了下Grok， 它给我的回复是这样的：

“斩杀线”是一个源于游戏的网络术语，主要有两种常见用法：

1. 游戏原意（最常见的来源）：
   • 在各种游戏（如《魔兽世界》、《炉石传说》、《英雄联盟》（LOL）、《王者荣耀》、《DNF》等）中，指敌方单位（英雄、怪物、BOSS）的血量降到一个特定临界值时，可以被玩家的一套技能组合或特定大招瞬间击杀（秒杀）的血量阈值。
   • 例如：
     • 《英雄联盟》里，盖伦、诺手、派克等英雄的大招有百分比斩杀效果，当敌人血量低于一定比例时，就能直接处决。
     • 《王者荣耀》里，召唤师技能“终结”（以前叫“斩杀”）造成已损失生命值14%的真实伤害，当敌人血量剩约12-13%时，就能用它收割。
     • 玩家常说“进入斩杀线”意思是血量危险了，一不小心就被秒；高手会精确计算伤害，预判是否能一套带走对手。
   • 这个词强调“一旦跨过这条线，就没悬念了，直接死”。
2. 近期网络热梗延伸（尤其是2025年底在中国社交平台流行）：
   • 借用游戏概念，比喻现实生活（特别是美国社会）中，一个人的财务或生活状态到达某个临界点后，会触发连锁反应（如失业+大病+债务+失去住房），迅速从普通中产滑落到底层（破产、无家可归），几乎无法翻身。
   • 常称为“美国斩杀线”或“中产斩杀线”，用来调侃或批评美国的社会保障薄弱、医疗昂贵、容错率低等问题。一旦“掉血”到这条线，就被“系统一套连招秒杀”。

原来就是下坠方向上不可逆的那个点（或者说线）啊…

但大家为啥只关注这个点和线呢？

其实全貌应该是“雪锦霜花”线啊，只有雪上加霜这个方向上到了那个点，才不可逆的，但大多数时候你还是可以在“雪锦霜花”之间颠倒颠啊！

Never give up，bro～

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

M4芯片上跑了下KVectors向量数据库的性能测试，没想到…

正好前阵子有哥们儿给了我台M4，就用它来跑下KVectors向量数据库的性能测试，预期肯定比我这老Intel款MBP强，但强到我看到这个结果还是好好数了下数字的个数🤣

search 10000 vectors in 4399 milli
press any key to exit...

平均0.4毫秒 😆 (依然是基于100万向量的sift small数据集，从中查询10000条向量的相似向量)

不过这个性能结果还算符合预期啦，毕竟之前在老款Intel芯片的MBP上跑IVF_FLAT索引测试，结果也是1.1毫秒 ～ 1.3毫秒这个区间， M4再怎么样硬件性能上要好的多得多。

不过M4在IVF_RABITQ索引的向量集合测试上折戟了，我还不确定是为啥：

=> M4 上kvectors IVF_RABITQ性能测试

search 10000 vectors in 381487 milli // without indexing 
press any key to start to build index
...
search 10000 vectors in 206182 milli
press any key to exit...

为啥感觉性能还不如intel款的老MBP测试的性能？！ 我记得之前是13毫秒左右，这个直接干到了20毫秒左右。

向量压缩后做ANNS反而慢了？！

可能百万级别不值得搞向量压缩和ANNS？

又或者我的RABITQ压缩算法还有很大的改进空间？

Anyway，埋头拉磨的模式该休一休了，后面得多想想怎么让KVectors这款产品给客户创造价值，让客户愿意埋单 🤣

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

KVectors向量数据库准备开源啦～

前阵子老王说，

KVectors可以搞开源+商业服务的模式

虽然这个产品从一开始构思、设计到实现就没考虑过开源

但“听人劝吃饱饭”嘛

这几天简单思考了下

决定这样…

开源版 KVectors 向量数据库（kvectors-oss）

开源版KVectors向量数据库是最初版设计和实现，当时的设计前提是：

1. 模型更新迭代太快，向量数据库中的向量可能因模型变更原因需要全量重新处理和存储；
2. 数据衍生系统，所以，数据变更可以通过从原始数据源重新加载；
3. 阶段性重新构建索引以提高性能与数据的新鲜度；

在这些前提下， 最初版的KVectors向量数据库的存储是APPEND_ONLY的，也就是只追加，不提供更新与删除等操作。（这也是前阵子金总说要基于这版打造商业方案，我心里没底儿的原因，因为还没经过实际场景检验。）

当然，除了APPEND_ONLY向量存储，还支持TRANSIENT类型的向量存储，这更多是便于测试或者用完即弃的场景。

向量索引方面，最初版支持如下索引类型：

1. FLAT索引
2. HNSW索引

看起来很少，对吧？

但其实这两个索引 + APPEND_ONLY 向量存储 已经可以满足大部分场景的需求，要知道头部向量数据库产品weaviate，其实也就是支持这两种索引，虽然它声称可以支持三种，但其实就是FLAT和HNSW再根据数据的生命周期再组合一下。

如果配合应用架构设计，这一版的KVectors向量数据库基本可以满足8成以上 AI 场景需求。

企业版 KVectors 向量数据库（kvectors-enterprise）

企业版 KVectors 向量数据库会在开源版基础上在如下方面进行增强：

1. 更多的向量索引类型。除了支持开源版支持所有向量索引类型，企业版KVectors向量数据库还支持如下向量索引（Scala 版 IVF 索引和 IVF_RABITQ 索引，完全自主设计与实现！）：
   • IVF(IVF_FLAT)
   • IVF_RABITQ
   • LSH
   • 更多…
2. 更强劲的向量存储引擎
   • 支持全面CRUD操作的向量存储引擎与向量集合， 既允许用户极速向KVectors向量数据库注入高维向量，又支持根据业务场景对向量的数据与元信息进行更改。
3. 更全面的商业服务与支持
   • 除了提供开箱即用的极速向量数据库产品，还为用户提供AI智能体与技术体系内的架构咨询与商业支持。
   • 总之，力求客户的钱花得值！

后续工作

1. codebase 整理
2. 相关文档整理
3. 社区反馈与持续迭代

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

AI、开源与微服务：老王两个观点，谈谈个人想法

在我还混过一段时间大中华区运维圈的时候，

有“南王北萧”的江湖称号

这里的老王就是当时的“南王”

现在是优维的老总

“感觉有用，但用处不大”

背景是成哥的SRE群里有人讨论AI到底有没有用

老王说：“感觉有用，但用处不大”

蚂蚁的一位同学说：“非常非常有用， 一天都少不了”

这里我觉得有意思的点是，

老板可能吃老王观点的比较多，

职场人士则是后面的观点比较多，

至于为啥，

自己想🤭

“开源+企业版和企业服务”

背景是群里聊到kvectors向量数据库，

我说还没想好怎么卖，

老王说： “开源+企业版和企业服务”

咋说呢

这确实过去的经典打法，

但我从一开始就没想走这条路，

为什么呢？

一个是时代变了

一个是成本结构不一样

再一个，前面有杭州智总的前车之鉴，

我也得清楚什么是自己的优势、什么又是自己的劣势，

如果劣势补不上，

起码别把自己的优势也扔了…

微服务

发现到了AI时代，

很多同学依然喜欢用微服务来打比方，

其实，

微服务没啥问题

中台也没啥问题

但小马想拉大车，

通常成了问题。

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。

看了方三文对话段永平完整视频，谈几点给我的启发和感想

经营企业与投资企业

你不懂企业，搞投资其实也投不明白（就算赚钱了，也只是撞大运）。

智者迟疑

你看段的观点很多时候不会很确定的讲，绝对不会很绝对的非黑即白，看不懂的就是看不懂，不会用自己的hindsight（事后诸葛亮）来渲染最初决策的迟疑和忐忑。

没有差异化，就没有超额利润

但差异化又很难维持，没有差异化就是卷，卷完剩下的，才能开始赚钱。

关于AI和泡沫

跟我前几天的观点类似

• https://mp.weixin.qq.com/s/LLPIc5A0fP5uGtxbYdwWlA?scene=1
• https://x.com/afoo_me/status/1986621585919529032

阿朱说明年可能AI泡沫，我倒是比较乐观。就算是泡沫，也会是回调。AI的趋势是不可逆的，只要电力和算力成本将来下落，AI的普及会是everywhere现在能源和算力标品对于AI的普及，还是太“贵”了。

关于效率

效率的观点我是认同的，我一直觉得可口可乐其实就是靠效率构建了自己最稳定的护城河。

了解自己在竞争态势中的位置

段说：“不要觉得自己就是天选之子”，哈哈哈，但年轻人都是“我命由我不由天”，所以…🤪

「福强私学」来一个？

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

福强老师的 AI 通识课

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。