泛架构 | 使用AI-CLI工具后的思考 : 这是操作系统级别的工具更新,大多数工作将迁移至新的基座,工程化仍然是解决问题的核心能力

0> 随手记

近期，使用几个AI工具，实际为个人做了小场景的开发和实践。

每天，脑子都有适应不过来的感觉，太多概念/流程/操作，都需要理解和实践。

慢慢有点想法，关于架构、工程、工具本质，关于未来的软件形态等，只是粗浅的一些联想。

多数应该都经不起推敲，只是杂乱记下。

1> 架构的对比和认知迁移

从架构上看，包括底层设施、中间框架、功能插件，也包括应用分层、应用部署等，软件类应用和AI类应用，还是有不少的类比可能性，这种可能性能够提升一些认识。

毕竟，从学习角度，学习=我知道的+我不知道的，用“知道的”去学习“不知道的”，是一种手段。

整体上，AI化应用的主环境、运行主逻辑、Agent、Skill、Content 等概念，和软件化应用的操作系统、运行时环境Runtime、软件、配置、进程/线程/堆栈等，可以认为有一定关系，可以类比。

对原操作系统及软件的理解，从底层到应用层，从开发部署和实际运行，可以进行类比迁移。

这种迁移的根本，是认知逻辑、软件工程架构本质的呼应。

操作系统，同，AI-CLI本身。

软件Runtime，同，AI-CLI Agent Runtime。

软件加载，同，Agent/SubAgent。

配置/功能，同，Skill。

进程/堆栈，同，Content。

这意味着曾经的知识会被提炼和重构，而且更加清晰。

在实践过程中，曾经专业课上理解过的操作系统体系、程序如何被加载/如何在内存总分布、进程间如何通讯，这些知识在新的工具下，都有一定指导意义。

认知的底层结构，是可以复用的。

2> 新的工具仍然需要工程化方法

实际体验看，新工具的能力极大提升了，是数量级的能力提升。

然而，要用好新的工具，仍然要回到工程化路径上来，至少发出命令就可以得到结果的期望，我认为当下还无法实现。

从实际体验看，对新工具的使用，更要强调专业性。

随着项目的深入和推进，对更全面/更系统的工程化方法的要求更高。

即，对新工具的掌握，其专业的深度和广度，都走向更高级别。

一样要细致地进行模块划分、层级规划、功能分工、通讯规范。

一样需要安全、策略、隐私、鉴权等更细致的规划和落地。

一样需要测试、监控更闭环的流程执行。

有了 AI工具，很多脏活/累活是不太占用时间了。

复杂性、价值性，仍然是核心的问题。

提出问题、理解问题，给出最本质的方向和路径，并确保其得到解决，并且在安全规范的情况下得以解决，仍然是解决问题的关键。

复杂性不会消失。

描述需求、制定解决方案、执行解决方案，其总是偏差累积的过程。

无论是用代码来实现，还是用AI工具来实现，这种复杂度的累积，是无法通过工具根本解决的，也许，熵增是其本质。

从这一段的实践看，要真正解决一个问题，得到不错的执行效果和体验，仍然需要：

模块划分，把大任务拆成小模块，逐个定义清晰。

层级规划，理清依赖关系，确定执行顺序。

功能分工，哪些用Agent、哪些用 Skill，哪些写脚本，哪些手动干预。

通讯规范，模块之间如何传递信息，格式是什么。

工程化素养，工程的设计能力，在 AI 时代不仅不过时，反而更重要了。

AI看起来什么都可以，至少目前来看，其对架构的深入思考，还不足。

3> 新工具推动人的进化

直观体验看，AI-CLI类工具赋予我们通过语言来实现软件/系统的能力。

那么，如何能通过语言将软件/系统其本质描述清晰，就成为关键。

软件/系统本身的复杂性，也不会消失。

在传统软件开发里，架构、框架、库、编译器、编程语言等，其实质就是在降低复杂性，面对一个复杂问题，分而治之/分而精之。

有了更强大工具，这些能力会被用的更好更顺利，这是必然。

必然的另一面，就是原来一个专业工程师只需要面对一个环节专业，现在要对更多环节担负起专业性，如果达不到，则整个流程就无法推进。

面对新的工具。

– 它的能力边界在哪里？

– 它擅长什么，不擅长什么？

– 什么情况下该信任它的输出，什么情况下需要人工校验？

– 如何设计提示词才能让它按预期工作？

这些问题，没有标准答案，只能在实践中摸索。

工具降低了专业的下限，也极大提升了专业的上限。

想用好工具，需要更深更广的专业能力。

4> Token和流量

新的工具消耗的是 Token 和大模型算力。

传统软件消耗的是流量和网络带宽（本地运行算力也算）。

这是一个有趣的对比。

当下Token消耗巨大，基于AI基座部署和运行应用，以及生成传统联网软件的方式运行应用，AI化应用对比软件化应用，会呈现怎样的形态。

当下，一条可能的路径是：先通过大模型和 Token 形成可用的有效工具应用，然后将工具应用”软件化”在本地，在本地运行/脱离Token约束。

粗浅看，这个路径含有以下思考。

成本层面，Token 是消耗品，用完要花钱，如果能将高频使用的功能固化成本地软件，就能把”边际成本”降下来。

安全层面，敏感数据不必每次都发给云端，工具本地化运行，数据留在本地。

可控层面，云端模型和工具可能变化、下线，本地工具在你自己的机器上，稳定可控。

即，这是“用 AI 执行应用”和“执行AI 写的应用”的区别。

前者消耗 Token（贵的），后者消耗本地算力（廉价的）。

当下，把 AI 当作”代码生成器”，而不是”在线运行时”，是否是可以考虑的方案之一。

5> 当LLM部署在本地

更进一步，如果大模型可以部署在本地了，那么这种能力本身就成为本地无穷机器能力的一部分——当然还需要电。

这时，Token 和流量就等同了，也许不需要”软件化”和”本地化”。

但这里有一个微妙的差异。

具体固化的本地化软件，和随时变动的大模型化应用，存在一定差异。

软件化应用的特点：

– 版本固定，行为可预测。

– 边界清晰，知道它能做什么。

– 出问题可以定位、修复。

– 对外部服务依赖性低。

大模型化应用的特点：

– 能力在持续迭代，今天能做的明天可能更好（也可能变差）。

– 边界模糊，总能试试看。

– 出问题难以定位根源。

– 依赖服务可用性。

或许，这是两种不同的工程哲学。

前者追求稳定可控，后者追求灵活进化。

也许未来会出现两者的融合形态——既保留确定性，又能持续学习进化。

但在此之前，我们需要在两者之间做出取舍。

6> 结语

新的生产力工具，如AI，提供了更快更低成本解决问题的方案。

但是，新的工具无法降低问题本身的本质，也无法降低解决方案的复杂性。

新的工具，也会暴露更高层级/更大范围的/更本质的问题，其复杂性更严重。

深刻理解这一点，或许能让我们更清醒地使用这些工具。

我们既不能神话它，也不能低估它。

======

<本文如对您有些许启发，请帮忙点击“❤”，谢谢~~>

======