王福强的个人博客：一个架构士的思考与沉淀

GEO 是 SEO 的替代吗？

Mon, 21 Sep 2026 16:00:00 GMT

GEO 是 SEO 的替代吗？ -王福强的个人博客：一个架构士的思考与沉淀

GEO 是 SEO 的替代吗？

王福强

2026-09-22

我问了三家AI（deepseek, X 和 ChatGPT）如下三个问题，

下面几个问题帮我解答下呀？

1. 相对于SEO，现在的GEO有什么变化？
2. 各个通用agent的信息源头，是不是还是依托SEO，要持续做关键词监测和内容铺设？
3. 需要主动与各个要面向的公开agent聊天来引入要优化的内容吗？
注： 这里提到的agent是指豆包、grok、gemini、千问等直接面向C端的产品。

然后给我的内容基本上对齐了

里面最喜欢的答复是这句：不要把talk当feeding，而要当testing🤣

2013年还是2014年忘了，在天猫干了大半年的SEO，最后落得个3.25🤣

国际站的经验是牛逼

放国内就不好使了

尤其是你还是巨头平台的情况下

不花钱是不可能的🤣

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

游戏与业务系统的底层逻辑对比

第一次踢人

荒诞之梦

「福强私学」来一个？

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

福强老师的 AI 通识课

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

真教育引导，假教育约束。

Wed, 16 Sep 2026 16:00:00 GMT

真教育引导，假教育约束。 -王福强的个人博客：一个架构士的思考与沉淀

真教育引导，假教育约束。

王福强

2026-09-17

所谓的“教育”，有一个可悲的地方，就是会抹杀个人的天性和直觉。

为什么策划组织者都不是学习很好的学霸？

因为他们做事，更多在用自身直觉和天赋，而不是教化后的机械重复。

学霸或许很骄傲自己的学历和体面的工作

但很难觉察到过往的教育对自身的束缚，

而这种束缚

是从你小时候

体系化地、一点一滴地施加给你的

所以

潜移默化中

你根本就意识不到

为什么校学、家学、自学三位一体缺一不可？

因为起码你还有交叉对比的机会

假如你只接受一种

那大概率你自己的思想其实不是你的

只是你自己觉得是你的而已。

比较悲观的一点是

一旦某些草种下了

再拔就极难了

你看看“思”字

心上一块田

种啥自己要是说了不算

那就别人替你种了

至于收成是什么呢？

只能你自己想了…

刷到这个视频有感，随便唠叨一句…

https://x.com/afoo_me/status/2100538970308526225

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

about startup

精神再高贵顽强也经不起身体神殿的崩塌

如何构建OpenAI API代理？

「福强私学」来一个？

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

福强老师的 AI 通识课

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

AI 第一性原理

Tue, 15 Sep 2026 16:00:00 GMT

AI 第一性原理 -王福强的个人博客：一个架构士的思考与沉淀

AI 第一性原理

王福强

2026-09-16

IMO

1、AI是什么？

数据的统计。

2、AI如何认知世界？

模式匹配（或者说模仿）。

3、AI的价值是什么？

提高人的信息采集效率和输出效率。

4、怎么使用AI？

干中学啊！

大模型这灵丹妙药再牛逼，你也得先找准自己的病症才能用🤣

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

听故事学架构之Henry Howard Holmes

别天天羡慕西方了

LOD Explained

「福强私学」来一个？

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

福强老师的 AI 通识课

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

一人军队（OMA），如何玩转 Vibe Coding？

Sun, 06 Sep 2026 16:00:00 GMT

一人军队（OMA），如何玩转 Vibe Coding？ -王福强的个人博客：一个架构士的思考与沉淀

一人军队（OMA），如何玩转 Vibe Coding？

王福强

2026-09-07

从“让 AI 写代码”到一套可控的软件生产方式

这几年，“一人公司”越来越流行，也就是 OPC（One Person Company）。

但我其实还挺喜欢另一个更早的说法：

OMA，One Man Army。

一个人的军队或者就是一人军队。

它强调的不是“公司只有一个人”，而是一种更强烈的状态：一个人，却拥有完成一整套任务的能力。 或者更大粒度的，完成整个目标交付的能力，从产研到销售和服务。

过去想做一个稍微完整的软件产品，往往需要产品、设计、前端、后端、客户端、测试、运维等不同角色。现在，随着 Coding Agent 的能力越来越强，一个人能够覆盖的范围正在迅速扩大。

我自己已经做了不少工具软件，包括 KeeNotes、FooSnippets、FooCloud、RMBG 等，更有多款产品已经进入 Apple App Store 的发布流程。

最主要的是，Tooling 本身也是整个 KEEVOL TEC 体系的一部分：工具软件、技术教育和战略咨询，构成了一套相互支撑的事情。（我叫这个战略愿景为KEEVOL Troika）

当 KVectors 向量数据库成为个人古早手工编码时代的最后一个高质量交付的产品之后，

从 2026 年开始，我的软件开发方式发生了一个非常明显的变化，即开始了 Vibe Coding（Everything）。

从 Panic 到 Hug

很多有多年开发经验的人第一次真正面对 Vibe Coding，多少都会经历一点心理冲击，而我就经历了一个如下的过程：

Panic → Hug。

从恐慌，到拥抱。

恐慌其实很好理解。

我们几十年来形成的软件工程习惯和个人能力，本质上建立在一个前提之上：

代码很贵

代码需要人一行一行写，框架需要人学，API 要查，跨平台意味着重新学习另一套技术栈，一门新语言可能要花几个月才能熟悉。

因此，我们过去的软件工程里，有大量决策，其实是在优化“人写代码的成本”。

为什么强调跨平台？

因为 Android 写一套、iOS 再写一套太贵。

为什么希望前后端都用一种语言？

因为维护两三套语言体系太贵。

为什么如此强调代码复用？

因为重新写一遍太贵。

可是 Coding Agent 出现以后，一个极重要的变量发生了变化：

代码的生产成本突然量级般地下降了。

这时候，如果依然机械地沿用过去所有“为了减少写代码而产生的最佳实践”，未必还是最优解。

这也是我这一段时间 Vibe Coding 最大的体会，下面是个人Vibe Coding过程中总结的一部分个人认为的最佳实践，与大家分享。

第一条个人最佳实践：MonoRepo

我的第一条实践非常简单：

MonoRepo。

传统团队为什么经常把项目拆成很多 Repository？

因为不同团队负责不同部分。

前端一个 Repo，后端一个 Repo，iOS 一个 Repo，Android 一个 Repo，基础设施可能还有一个 Repo。

这是一种很典型的组织结构映射到代码组织结构的方式。

但 OMA 的情况不同。

如果一个产品本来就是一个人加若干 Agent 在维护，那么人为把它切成七八个仓库，反而会产生额外的上下文成本。（还记得微服务吗？🤪）

对于 Coding Agent 来说，这一点尤其明显。

假设一次需求同时需要修改：

Web 前端、API、数据库 Schema、macOS 客户端和部署脚本。

如果它们都在一个 MonoRepo 里，Agent 可以直接看到整个系统。

数据库字段改了，它能够顺着依赖关系找到 API；API 改了，又可以继续找到客户端。

所以，对 OMA 来说，MonoRepo 不只是代码管理风格。

它实际上在做一件更重要的事情：

把系统尽可能完整地放进 Agent 的可见范围。

换句话说，过去 Repository 经常围绕“人和团队”划边界；到了 Agent Coding 时代，Repository 还要开始考虑：

怎样划分，最有利于机器理解整个系统？

这是两个完全不同的出发点。

第二条个人最佳实践：Hierarchy Context Files

有了 MonoRepo，还只是让 Agent 看得到代码。

但看到代码，并不代表它理解你的意图。

所以第二个个人的最佳实践是：

Hierarchy Context Files。

Coding Agent 有一个非常现实的问题：

它每次进入项目，都需要重新建立上下文。

这个项目为什么这样设计？

技术栈是什么？

哪些东西绝对不能动？

命名规范是什么？

UI 应该遵循什么风格？

某个子模块为什么故意没有采用通常的实现方式？

如果这些东西只存在于你的脑子里，Agent 每一轮都得重新猜。

所以，一个适合 Agent 的代码库，不应该只有代码，还应该有一套层级化的上下文体系。

比如在最顶层描述整个项目的目标、原则和架构约束；进入具体模块以后，再补充这个模块自己的规则；再往下，还可以有更加局部的约定。

于是形成类似：

Global Context → Project Context → Module Context → Task Context

这样的层级。

这里有一个很重要的原则：

上下文应该尽可能靠近它所约束的对象。

全局规则放全局。

macOS 的规则放 macOS 目录。

某个服务的特殊约束就放在那个服务附近。

这样做的好处，不只是节约 Token。

更重要的是，它开始把过去存在于程序员脑子里的隐性知识显性化。

这其实是 Agent Native Software Engineering 很重要的一步。

第三条个人最佳实践：PairLoop

接下来是我很看重的一个词：

PairLoop

很多人理解 Vibe Coding，会想象成：

“我把需求告诉 AI，然后 AI 把程序写完。”

真正工作以后你会发现，这种模式通常并不好用。

Vibe Coding 更像以前的 Pair Programming，只不过你的 Pair 从另一个程序员变成了 Coding Agent。

而且这个过程不是一轮，是一个 Loop。

把它展开，大概就是：

意图 → 实现 → 运行 → 验证 → 反馈 → 修改 → 再运行。

然后不断循环。

这里真正重要的并不是 Prompt 有多完美。

事实上，我越来越不相信所谓 “一条神 Prompt 把事情搞定”。

复杂的软件系统不可能靠一次描述就穷尽所有细节。

真正可靠的方法是：

缩短反馈环

让 Agent 做一点。

马上运行。

看到问题。

马上修正。

然后再进入下一轮。

因此，Vibe Coding 的效率并不只取决于：

Agent 一次能生成多少代码

更取决于：

你和 Agent 一天能完成多少次有效闭环

这个区别非常重要。

当然，这里的 Pair 也可以是 Agent 和 Agent 组 Pair，不一定是你和 Agent 组 Pair，甚至组合成两个甚至更多的层次，并不冲突。

第四条个人最佳实践：Multi-Platform over Cross Platform

这是一个我觉得非常有意思的变化。

过去十几年，客户端开发有一个强烈趋势：

Cross Platform

能不能一套代码跑 iOS、Android、macOS、Windows？

它背后的逻辑非常合理：

开发两个/多个平台的版本太贵，所以最好只维护一个版本。

但 Vibe Coding 之后，我越来越倾向于：

Multi-Platform over Cross Platform

注意，这两个词看起来很像，思路却完全不同。

Cross Platform 追求：

一套实现运行在多个平台。

Multi-Platform 则接受：

每个平台都可以有最适合自己的实现。

以前后者的问题是成本。

Swift 写一套，Kotlin 写一套，Web 再写一套，维护成本太高。（甚至人你都找不到，除非你一起手就是大厂）

但当 Coding Agent 可以帮你承担大量实现工作以后，这个成本结构发生了改变。

这时候，与其为了共享代码，让所有平台迁就某一个抽象层，不如：

以 iOS 的方式和技术栈做 iOS 应用，

以 macOS 的方式和技术栈做 macOS 应用，

以 Web 的方式和技术栈做 Web 应用…

真正共享的，可以是产品定义、协议、数据模型、设计规则和业务逻辑描述，而不一定非得共享每一行实现代码。

AI 实际上让“重复实现”第一次变得没那么可怕。

第五条个人最佳实践：Multi-Lang over Single Lang Ecosystem

同样的变化，也发生在编程语言上。

所以第五条是：

Multi-Lang over Single Lang Ecosystem。

以前我们很喜欢所谓 One Language Everywhere。

比如：

前端 JavaScript，

后端也 Node.js，

工具也 JavaScript，

这样整个团队只需要掌握一种语言。

它最大的好处，还是降低人的学习和切换成本。

但 Coding Agent 并没有这么强的“语言洁癖”或者说“语言壁垒”。

今天写 Swift，下一分钟写 Rust，再下一分钟改 TypeScript，对 Agent 来说并不像人一样需要重新学习个半年。

于是技术选型可以逐渐回到一个很朴素的问题：

这件事情，用什么计算机语言做最合适？

macOS 原生 App 用 Swift。

某个高性能组件用 Rust。

Web UI 用 TypeScript。

一些自动化任务用 Python。

服务器再根据实际情况选最适合的语言。

过去 Polyglot Programming （多语言混合编程）最大的问题之一是认知成本。

而 AI 正在显著压低这个成本。

所以未来软件系统可能反而会变得更多语言，而不是更少语言。

只不过复杂性的一部分，从“人必须熟悉所有语言”，转移成了：

人必须对问题的边界和语言的匹配度作出合适的决策

第六条个人最佳实践：广域网验收，局域网交付

这背后的思路其实也是在优化反馈 Loop。

开发过程中，最重要的是让东西尽快被看到。

因此验收环境应该尽可能容易访问。

一个功能完成以后，不要让对方先装环境、VPN、依赖和各种工具才能看。

最好给一个地址，打开就能验。

这是广域网验收。

但最终真正交付的时候，尤其企业内部系统或者私有化软件，完全可以进入客户自己的局域网或者内部环境。

这是局域网交付。

把“验收”和“最终部署”拆开，解决的是两个不同的问题：

验收追求低摩擦反馈；

交付追求安全、私有和可控。

如果把二者强行绑定在一起，反馈周期往往会被部署复杂性拖慢。

而 Vibe Coding 最怕的，就是 Loop 太长。

一个更深的变化：Reuse VS. Distill

传统软件工程非常强调 Reuse。

不要重复代码。

做公共组件。

做公共库。

抽象框架。

沉淀基础设施。

这是因为：

代码贵，所以代码值得重复利用。

但 Vibe Coding 以后，我们可能需要重新思考：

真正应该重复利用的，到底是什么？

比如我刚刚完成一个非常好的 macOS 权限授权流程。

过去第一反应可能是：

把这套代码抽成 Framework。

但在 Agent 时代，另一种做法可能更有价值：

把这次实践里真正有效的东西提炼出来：

设计原则是什么？

哪些 API 容易踩坑？

正确流程是什么？

交互应该怎样设计？

哪些异常情况必须处理？

然后把这些东西沉淀成一份 Context、Spec、Skill 或 Pattern。

下一次，再让 Agent 根据新的项目重新生成最适合那个项目的实现。

这就是：

Distill，而不只是 Reuse。

Reuse 是：

复用上一次的代码。

Distill 更像是：

复用上一次获得的认知。

代码是某一次问题求解的结果。

而被提炼出来的知识，则可以继续生成许多不同的结果。

AI 让“重新生成代码”越来越便宜以后，后者的价值会越来越高。

最终原则：More Loops, More Certainty

综合整套最佳实践，我把它总结成一句话：

More Loops, More Certainty.

也就是更多轮次，更多确定性。

这其实也是我现在理解 Vibe Coding 最核心的一点。

很多人担心 AI 写代码不可靠。

这个担心没有错。

但解决方案并不是要求 AI：

一次就必须百分之百正确。

软件开发本来也不是这样工作的。

真正能够制造确定性的，从来都是反馈：

编译一次。

跑一次。

测试一次。

看一次 UI。

部署一次。

让真实用户操作一次。

发现问题。

然后再修。

AI 最大的价值，并不是消灭这些 Loop。

恰恰相反，它让每一次修改的成本急剧下降，因此我们终于可以：

跑更多 Loop(s)

如果以前修改一个方案需要两天，那么大家倾向于修改之前讨论半天。

现在修改只需要十分钟，那最经济的方式可能变成：

先做出来。

跑一下。

不对就改。

再跑。

这是一种完全不同的软件生产经济学。

Vibe Coding 并不是“不懂代码也没关系”

最后还要澄清一个容易产生的误会：

当代码越来越多由 AI 生成时，并不意味着工程能力变得不重要。

恰恰相反。

过去，你的能力决定：

你能写出什么。

现在越来越变成：

你能判断什么是对的。

架构有没有问题？

技术选型合不合理？

平台体验是不是原生？

数据模型有没有埋雷？

安全边界在哪里？

Agent 是在解决问题，还是只是绕开问题？

这些事情最终仍然需要人来判断。

所以 OMA 并不是：

一个人什么都亲自干。

更准确的定义可能是：

一个人能够对完整结果负责。

AI 可以写代码，可以跑命令，可以修改 UI，可以修 Bug。

但方向、边界、取舍和最终验收，仍然在 Builder 手里。

而这，大概也是 Vibe Coding 真正有意思的地方。

它首先改变的不是编程语言，不是 IDE，也不是某一种模型。

它改变的是：

一个人可以完成多大范围的软件工程。

以前我们靠组织扩大能力，

现在，一个 OMA 也可以靠 Agent 扩大能力和个人边界。

至于如何让这种能力变得稳定，而不是变成一场随机的“AI 抽卡游戏”，我的答案依然是：

More Loops, More Certainty.

循环得足够快、足够多，反馈足够及时，结果就会越来越确定。

最后，祝大家 Happy Vibe Coding。

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

打工人与创业者有什么区别？

并发编程：理论，框架与实践

中国咨询之父是谁？

「福强私学」来一个？

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

福强老师的 AI 通识课

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

国内的AI商战进展到哪一步了?

Mon, 31 Aug 2026 16:00:00 GMT

国内的AI商战进展到哪一步了? -王福强的个人博客：一个架构士的思考与沉淀

国内的AI商战进展到哪一步了?

王福强

2026-09-01

以下只是个人观察或者说猜测，

没啥数据支撑

各位看官姑且笑笑、姑且看看、姑且谈谈…

现在第一梯队的阵势已经差不多快形成三足鼎立的态势了

但还远没有成型

第一个就是字节主攻C端市场的战略意图很明显了

将飞书之类原来做ToB的事业部拆的拆，散的散

全都并入豆包

主打一个抢占AI时代C端市场老大的地位

第二个就是腾讯

主攻办公市场的战略意图也十分明显

今年以前（2026）

腾讯在AI层面的战略落后是很明显的

今年开始

腾讯借着WorkBuddy这个产品主打后发优势

连杭州电梯里都可以看到WorkBuddy的电梯广告投放

你说他多舍得砸钱啊

敢砸钱在广告上，就意味着他战略重心敲定了。

第三个是阿里

说实话，我觉得阿里现在不太稳当

其实前期在模型上的优势还是挺明显的

但到了现阶段

他肯定是在模型、办公agent 和 coding agent层面的投入有些举棋不定？

当然，只是个人感觉，没啥依据哈

至于其它厂商

大多都是在抢占MaaS和coding agent的市场

有谁就不说了

程序员群体都知道…

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

人口红利或者工程师红利到底在强调什么？

如何选择或者搭建合适的AI大语言模型服务？

Spring AI 1.0 发布意味着什么？

「福强私学」来一个？

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

福强老师的 AI 通识课

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

人才与企业发展阶段之间的辨证关系

Sat, 29 Aug 2026 16:00:00 GMT

人才与企业发展阶段之间的辨证关系 -王福强的个人博客：一个架构士的思考与沉淀

人才与企业发展阶段之间的辨证关系

王福强

2026-08-30

溜⁣⁣⁣‌‌⁣⁣⁣⁣‌⁣‌‌⁣⁣‌⁣‌‌‌⁣⁣⁣⁣⁣⁣⁣‌‌⁣‌⁣⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣‌⁣‌‍达的时候

想起在某司招聘的时候的一个事情

当时我面试到一个表现的比较 aggressive 的年轻人

我是比较欲しい的

但另一个 VP 交叉面的时候给否了

表现的也比较不屑

这个事情我印象比较深

现在想来

当一家公司业务前景不明朗的时候

或者创始人财务上比较“保守”的时候

确实是不太喜欢比较 aggressive 的员工

只有业务明朗而且处于高速发展期的时候

这种 aggressive 的员工才比较吃香

因为只要你能在主航道上拿到大结果

我就敢给钱

反而业务不明朗的时候

要熬

要少花钱

要减少不必要的内耗

这时候

比较 aggressive 的员工

自己耐不住

公司也不一定留得住

so 只能放弃

减少不必要的切换和摩擦成本

当然，落到人身上，能容人的人还是少，绝大多数人不喜欢 aggressive 的人，更不要说下属

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

Google Gemini CLI extensions是个什么东西？

赏金模式还是雇佣关系，这是个问题…

张小龙内部邮件中提到团队的理念[转载]

「福强私学」来一个？

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

福强老师的 AI 通识课

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

拯救行动中的AI

Sun, 23 Aug 2026 16:00:00 GMT

拯救行动中的AI -王福强的个人博客：一个架构士的思考与沉淀

拯救行动中的AI

王福强

2026-08-24

(AI in Project Hail Mary)

拯救行动里面有个场景，想来很有意思

集中式AI虽然很强大

可以守护船员、自动巡航

但遇到边缘侧实际作业环境的时候

就不行了

比如，

当主人公要跟外星人沟通的时候

当相互比划的效率不行的时候

主人公想了个edge端最简单的PoC方案

录音（语料采集）
对齐（数据标注）
翻译（双向映射/神经网络）

这个PoC方案把现在AI的能力都利用上了，尤其是livechat相关的技术：

录音（ASR，语音识别）
对齐（模型训练）
翻译（TTS，文本到语音输出）

把123压缩到一个模型服务，就成了一个多模态大模型🤣

方案很简陋，但却完整复现了一个AI语音方案的构建过程，主人公不愧是寓教于乐的中学老师🤣

另外，里面提到舰长 deceased，我差点儿看成 decreased 😂

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

后视镜中的车流

Resident Evil

N个对SEO的错误认知

「福强私学」来一个？

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

福强老师的 AI 通识课

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

TVP 走进宁德时代(CATL) 杂记

Thu, 20 Aug 2026 16:00:00 GMT

TVP 走进宁德时代(CATL) 杂记 -王福强的个人博客：一个架构士的思考与沉淀

TVP 走进宁德时代(CATL) 杂记

王福强

2026-08-21

上半年基本上埋头拉车

恰好 TVP 组织了走访宁德时代的活动

遂报名参加

也要经常抬头看路不是？😉

下面是一些杂记，没有章法和逻辑，想到哪儿说到哪儿…

产线与工序

本次带我们参观的是2016年的厂（车间），不算最新，所以，没多少惊艳

但已经是自动化程度很高了

除了工序最后几个质检环节看到几个人

整个工厂（车间）里几乎看不到人

看到的只有机器

偶尔几台轨道机器人

主要是帮助物料衔接

另外就是看到kuka机械臂堆垛，这应该是工厂里的常规场景吧？🤣

我猜测

宁德时代有三个代际的工厂

最早的工厂，更多是靠人工（因为我在宁德时代附近酒店里刷短视频的时候，刷到很多厂妹厂哥儿的视频，应该是不是研发，而是生产，但按照我们参观的工厂生产情况，明显用不了那么多人）
第二代工厂，也就是我们参观的这个工厂，自动化+少量人工
最新的工厂，自动化程度更高，但怕泄密，所以，不对外开放参观。（毕竟，我们参观工厂环节也是不让拍照的，更不要说最新的工厂细节）

当然，以上纯个人猜测😉

AB电池组

参观展厅的时候，有一个展示台挺有意思，用来展示不同材料电池的组合，比如可以用磷酸锂铁+三元锂组成一个组合电池，这个让我想起架构里的组合原则，更让我想起hybrid search或者fusion search之类的方案。

看来架构或者说产品思想很多都是相通的。

另外就是这个展示台的设计值得称赞，可以手动挑选电池块儿插入拼接，然后实时触发不同电池组合的演示视频介绍。

vent 安全阀

电芯层面的安全设计，如果有废气或者泄漏，vent安全阀破损后就意味着这个电芯废了。

formation

我不知道你看到这个词儿能不能直觉性的了解它是什么意思？

那“化成”呢？

其实说实话，我听到介绍“化成”工序的时候，我认识这俩字儿，但我不知道啥意思

然后我看到演示屏幕右上角对应的单词是“Fromation”，

然后我心里反而有底了，因为我怀疑这个地方这个单词拼错了（typo）

我就站着看了会儿视频，当看到视频里下面字幕里是formation的时候，我就确定了

其实就是“成形”🤣

整个参观过程，我自己有一个很强烈的感受

当我看不懂汉字在说啥的时候，我看英文反而一眼就看懂了

比如：

麒麟凝聚态电池，凝聚态啥意思？看英文是condensed battery，哦，原来就是更密集（浓缩的）电池🤣
无人车，其实就是自动车辆/自主运行的车辆，Autonomous Vehicle

所以，当有人告诉你说学英语没用的时候

你是不是再考虑考虑？😉

桂花云贝

今天晚宴上有道朴实无华的菜

第一眼看上去是炒饭

第二眼看上去又像是炒粉

但一吃又特别鲜美，绝对不是炒饭的口感

拍照问了豆包

菜名叫“桂花云贝”

别说，金灿灿的，是挺招人稀罕

自动驾驶

下午分享交流环节，

广汽的总师（介绍上这么写的，我不确定是不是就是这个职位称呼，还是总架构师/总工程师的缩写）给我们介绍了汽车自动驾驶的发展历史

了解到业界现在的真实水平和营销水平

最主要的是

肯定了百度在这个领域的贡献

你们不是天天骂百度吗？

其实人家也有在干实事。😉

最后

比较尴尬也比较巧合的是

在这里遇到了原来在挖财的一个同事

其实当时我们俩关系并不好

甚至是水火不容

我把他早拉黑了

今天居然在现场遇到了😂

但过去的就是过去了

Let it be.

况且，他应该是冲着腾讯云安全老大去的，碰到我真就是个巧合😂

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

Excel

为啥是“爱学不学”？

Great minds think alike

「福强私学」来一个？

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

福强老师的 AI 通识课

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

这些 AI 产品的定位其实不一样

Thu, 13 Aug 2026 16:00:00 GMT

这些 AI 产品的定位其实不一样 -王福强的个人博客：一个架构士的思考与沉淀

这些 AI 产品的定位其实不一样

王福强

2026-08-14

什么是Coding Agents？

即定位专注于写代码场景的AI Agents，比如Claude Code， Codex，Grok Build， Pi，以及最新出来的DeepSeek Harness…

小龙虾与 Coding Agents

小龙虾（OpenClaw）跟 Coding Agents 其实不完全一样。

小龙虾偏服务器端，偏Remote，用户访问它的时候，是通过其它外围channels，比如telegram，飞书之类IM产品；但Coding Agents更偏Local，通常跑在开发者使用的开发机上，虽然现在很多人喜欢结合UU/Tailscale/Paseo/Herdr等工具远程访问这些Coding Agents，但Coding Agents骨子里还是偏Local开发机上的Agents实现。
小龙虾更偏通用Agents， Coding Agents更偏Coding；
小龙虾的受众更广， Coding Agents的受众通常是研发；

WorkBuddy 与 Coding Agents

WorkBuddy的产品定位更偏办公， Coding Agents的产品定位还是Coding。

CLI，TUI 与 GUI

同为Coding Agents，

但Coding Agent跟Coding Agent其实也不一样

比如Claude Code更偏重CLI产品形式

而Codex更偏GUI产品形式（虽然也有rust版的CLI版）

而像Herdr之类agents管理类的CLI工具，其实有点儿向TUI偏移了。

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

必要回报率(Required Rate Of Return)

KVectors 向量数据库基本成型！

啥？阿里巴巴又做组织结构调整了？！

「福强私学」来一个？

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

福强老师的 AI 通识课

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

录音硬件类产品随想

Wed, 12 Aug 2026 16:00:00 GMT

录音硬件类产品随想 -王福强的个人博客：一个架构士的思考与沉淀

录音硬件类产品随想

王福强

2026-08-13

我⁣⁣⁣‌‌⁣⁣⁣⁣‌⁣‌‌⁣⁣‌⁣‌‌‌⁣⁣⁣⁣⁣⁣⁣‌‌⁣‌⁣⁣‌⁣⁣⁣⁣‌‌⁣‌⁣⁣⁣‌⁣‌‍对录音卡之类的产品需求其实挺简单的：

录音设备极简化设计，只有开关按钮和故障灯，剩下就是充电接口，绝不能有各种状态、显示屏等乱七八糟的设计。
录音设备的充电和数据传输最好一条线搞定，因为我需要根据这条线来判断充电状态和数据传输
录音设备插到专用dock上后，自动备份数据并上传到云端（产品原型是一台macbook pro + hammerspoon 自定义脚本）；

整个产品架构中，录音设备和专用dock 是关键。

如果要商业化，也是专注在专用dock层面，通过硬件加管理app形成附加价值，允许用户配置类似于是否要做ASR（自动转录）、是否上传云端后自动清理录音设备、是否要配置多个云端存储等等。

专用dock尽量轻量化设计，只负责充电和数据传输，不拥有大容量存储，否则就偏NAS了。

整个产品组合的核心理念是，每日routine + fire&forget。

具体来说就是，每天从dock上取下录音设备后即开机，全天录音，让录音设备成为自己的增强电子耳朵，到家或者休息之前，把录音设备插到dock上，dock自动上传数据并充电。

这样，对于用户来说可以很快形成习惯，又没有太多执行和认知负担，很容易持续落实。

至于像什么转录分析啥的，大部分时候不需要，但因为有dock和对应的app，也很容易扩展，但从来不是这套产品体系的关键诉求。

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

向量数据库系列第二期企业培训圆满落幕！

没想到！Java真不行了！

mysql多个slave使用同一个server id会怎样？

「福强私学」来一个？

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

福强老师的 AI 通识课

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

FSCloud 面向个人有自部署能力的用户开放试用啦～

Mon, 10 Aug 2026 16:00:00 GMT

FSCloud 面向个人有自部署能力的用户开放试用啦～ -王福强的个人博客：一个架构士的思考与沉淀

FSCloud 面向个人有自部署能力的用户开放试用啦～

王福强

2026-08-11

安装部署很简单，

首先确保本地已经安装了Docker（Docker Desktop或者OrbStack等都可以）

然后下载或者保存如下docker-compose.yaml配置内容到本地任意目录(保存到文件名依然需要是docker-compose.yaml)：

x-app-env: &app-env
  FSCLOUD_PROFILE: development
  FS_DATABASE__URL: postgres://fscloud:fscloud@postgres:5432/fscloud?sslmode=disable
  FS_REDIS__ADDR: redis:6379
  FS_REDIS__PASSWORD: fscloud
  FS_REDIS__DB: "0"
  FS_MINIO__ENDPOINT: minio:9000
  FS_MINIO__ACCESS_KEY: minioadmin
  FS_MINIO__SECRET_KEY: minioadmin
  FS_MINIO__BUCKET: fscloud
  FS_MINIO__USE_SSL: "false"
  FS_MINIO__REGION: us-east-1
  FS_JWT__ACCESS_SECRET: ${FS_JWT_SECRET:-fscloud-trial-jwt-secret}
  FS_JWT__REFRESH_SECRET: ${FS_JWT_SECRET:-fscloud-trial-jwt-secret}
  FS_NODE__REGION: local

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: fscloud
      POSTGRES_PASSWORD: fscloud
      POSTGRES_DB: fscloud
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U fscloud -d fscloud"]
      interval: 5s
      timeout: 3s
      retries: 20
    restart: unless-stopped

  migrate:
    image: ${IMAGE_REGISTRY:-fujohnwang}/fscloud-migrations:${IMAGE_TAG:-latest}
    environment:
      POSTGRES_USER: fscloud
      POSTGRES_PASSWORD: fscloud
      POSTGRES_DB: fscloud
      PGHOST: postgres
      PGPORT: "5432"
      PGPASSWORD: fscloud
    depends_on:
      postgres:
        condition: service_healthy
    restart: "no"

  redis:
    image: redis:7-alpine
    command:
      - redis-server
      - --requirepass
      - fscloud
      - --appendonly
      - "yes"
      - --appendfsync
      - everysec
      - --maxmemory-policy
      - noeviction
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "fscloud", "ping"]
      interval: 5s
      timeout: 3s
      retries: 20
    restart: unless-stopped

  minio:
    image: pgsty/minio:RELEASE.2026-04-17T00-00-00Z
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    volumes:
      - minio-data:/data
    healthcheck:
      test: ["CMD", "mc", "ready", "local"]
      interval: 5s
      timeout: 3s
      retries: 20
    restart: unless-stopped

  gateway:
    image: ${IMAGE_REGISTRY:-fujohnwang}/fscloud-gateway:${IMAGE_TAG:-latest}
    ports:
      - "${FS_HTTP_PORT:-4432}:4432"
      - "${FS_QUIC_PORT:-4433}:4433/udp"
      - "${FS_WEBDAV_PORT:-4434}:4434"
    environment:
      <<: *app-env
      FS_QUIC__LISTEN_ADDR: 0.0.0.0:4433
      FS_QUIC__ADVERTISE_ADDR: ${FS_QUIC_ADVERTISE_ADDR:-localhost:4433}
      FS_TLS__CERT_FILE: ""
      FS_TLS__KEY_FILE: ""
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
      minio:
        condition: service_healthy
    restart: unless-stopped

  admin:
    image: ${IMAGE_REGISTRY:-fujohnwang}/fscloud-admin:${IMAGE_TAG:-latest}
    ports:
      - "${FS_ADMIN_PORT:-4431}:4431"
    environment:
      FSCLOUD_PROFILE: development
      API_BASE: http://gateway:4432
      DATABASE_URL: postgres://fscloud:fscloud@postgres:5432/fscloud?sslmode=disable
      ADMIN_COOKIE_SECURE: "false"
    depends_on:
      migrate:
        condition: service_completed_successfully
      gateway:
        condition: service_started
    restart: unless-stopped

volumes:
  postgres-data:
  redis-data:
  minio-data:

然后到docker-compose.yaml所在目录下执行：docker compose up -d

即可启动FSCloud各项服务。

启动成功后：

访问 http://localhost:4432 注册新用户并登录web端
访问 http://localhost:4432/cfg 可以下载macOS版客户端，native 客户端支持实时同步等高级功能。
【可选】访问 http://localhost:4431 设置初始管理员账号，并登录和管理FSCloud

Enjoy ～

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

“换汤不换药”的技术概念或者理念

云不是万能药，治不了你的无知与懒惰

扶墙老师谈管理：到底应不应该找backup

「福强私学」来一个？

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

福强老师的 AI 通识课

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

王福强的个人博客：一个架构士的思考与沉淀

GEO 是 SEO 的替代吗？

GEO 是 SEO 的替代吗？

王福强

「福强私学」来一个？

真教育引导，假教育约束。

真教育引导，假教育约束。

王福强

「福强私学」来一个？

AI 第一性原理

AI 第一性原理

王福强

1、AI是什么？

2、AI如何认知世界？

3、AI的价值是什么？

4、怎么使用AI？

「福强私学」来一个？

一人军队（OMA），如何玩转 Vibe Coding？

一人军队（OMA），如何玩转 Vibe Coding？

王福强

从“让 AI 写代码”到一套可控的软件生产方式

从 Panic 到 Hug

第一条个人最佳实践：MonoRepo

第二条个人最佳实践：Hierarchy Context Files

第三条个人最佳实践：PairLoop

第四条个人最佳实践：Multi-Platform over Cross Platform

第五条个人最佳实践：Multi-Lang over Single Lang Ecosystem

第六条个人最佳实践：广域网验收，局域网交付

一个更深的变化：Reuse VS. Distill

最终原则：More Loops, More Certainty

Vibe Coding 并不是“不懂代码也没关系”

「福强私学」来一个？

国内的AI商战进展到哪一步了?

国内的AI商战进展到哪一步了?

王福强

「福强私学」来一个？

人才与企业发展阶段之间的辨证关系

人才与企业发展阶段之间的辨证关系

王福强

「福强私学」来一个？

拯救行动中的AI

拯救行动中的AI

王福强

「福强私学」来一个？

TVP 走进 宁德时代(CATL) 杂记

TVP 走进 宁德时代(CATL) 杂记

王福强

产线与工序

AB电池组

vent 安全阀

formation

桂花云贝

自动驾驶

最后

「福强私学」来一个？

这些 AI 产品的定位其实不一样

这些 AI 产品的定位其实不一样

王福强

小龙虾 与 Coding Agents

WorkBuddy 与 Coding Agents

CLI，TUI 与 GUI

「福强私学」来一个？

录音硬件类产品随想

录音硬件类产品随想

王福强

「福强私学」来一个？

FSCloud 面向个人有自部署能力的用户开放试用啦～

FSCloud 面向个人有自部署能力的用户开放试用啦～

王福强

「福强私学」来一个？

TVP 走进宁德时代(CATL) 杂记

TVP 走进宁德时代(CATL) 杂记

小龙虾与 Coding Agents