Token 经济学三原则

2026-04-08 00:00:00

Token 经济学三原则 -王福强的个人博客：一个架构士的思考与沉淀

Token 经济学三原则

王福强

2026-04-08

1

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

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

2

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

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

3

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

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

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

>>>>>> 更多阅读 <<<<<<

核酸码系统拆解与设计推演

介于极端之间的是什么

人设、流量与成交

「福强私学」来一个？

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

福强老师的 AI 通识课

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

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

2026-03-31 00:00:00

评价和critical 批判下我的这个有关MCP的观点 -王福强的个人博客：一个架构士的思考与沉淀

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

王福强

2026-03-31

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 的主流架构模式之一。

>>>>>> 更多阅读 <<<<<<

也谈三观

ChatGPT的宿命

使用反射（Reflection）改进项目代码架构

「福强私学」来一个？

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

福强老师的 AI 通识课

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

AI 研发时代的范式迁移

2026-03-17 00:00:00

AI 研发时代的范式迁移 -王福强的个人博客：一个架构士的思考与沉淀

AI 研发时代的范式迁移

王福强

2026-03-17

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

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

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

有了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直接从现有系统或者模块中抽取最小必要的逻辑或者代码，不但省去了依赖巨大非必要模块的问题，还能进一步定制。

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

容错思维而不是异常思维

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

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

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

>>>>>> 更多阅读 <<<<<<

自用二维码Chrome插件/扩展 (A Chrome Extension of QR Code)

战投部没了，大家后面的日子还会好吗？

沉睡的周末

「福强私学」来一个？

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

福强老师的 AI 通识课

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

claude code with qwen3.5 via ollama

2026-03-05 00:00:00

claude code with qwen3.5 via ollama -王福强的个人博客：一个架构士的思考与沉淀

claude code with qwen3.5 via ollama

王福强

2026-03-05

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

2026-02-24 00:00:00

分享关于 AI 的 7 个 KeeNotes -王福强的个人博客：一个架构士的思考与沉淀

分享关于 AI 的 7 个 KeeNotes

王福强

2026-02-24

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招！

2026-02-11 00:00:00

成为AI高手，只需这4招！ -王福强的个人博客：一个架构士的思考与沉淀

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

王福强

2026-02-11

要想成为 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 步提示词框架：

Role (角色)： 定义 AI 是谁（你是专家…），给谁看，什么语气。
Task (任务)： 用动词明确指令（撰写、分析、总结…）。
Context (背景)： 提供“单一事实来源”，给足数据和背景资料。
Examples (示例)： 给 AI 看“什么是好的结果”（Few-shot prompting），这能统一风格。
Output (输出)： 指定格式（表格、代码、段落长度）。
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 自动化：

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

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

>>>>>> 更多阅读 <<<<<<

今天,你被宰了吗?

小米发布会有哪些历史经验值得关注？

技术成长路线图真的有用吗？

「福强私学」来一个？

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

福强老师的 AI 通识课

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

afoo | 王福强修改

afoo | 王福强的 RSS 预览

Token 经济学三原则

王福强

1

2

3

「福强私学」来一个？

福强老师的 AI 通识课

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

王福强

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

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

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

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

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

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

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

三、 总结与展望

「福强私学」来一个？

福强老师的 AI 通识课

AI 研发时代的范式迁移

王福强

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

MonoRepo 应该成为主流

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

Distill instead of reuse

容错思维而不是异常思维

「福强私学」来一个？

福强老师的 AI 通识课

claude code with qwen3.5 via ollama

王福强

「福强私学」来一个？

福强老师的 AI 通识课

分享关于 AI 的 7 个 KeeNotes

王福强

1

2

3

4

5

6

7

「福强私学」来一个？

福强老师的 AI 通识课

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

王福强

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

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

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

4. 验证框架 (Validation Framework)

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

「福强私学」来一个？

福强老师的 AI 通识课

该作者的社会化媒体

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

三、总结与展望