今天发现 cursor 已经降智到不可理喻的程度了？ 会忘记 4 条前的消息？为了将成本疯狂削上下文？ 订阅制的 ai 辅助编程工具已经没钱路了吗？

大家有遇到相同的情况吗？

blog.langchain.dev

从 langsmith 的数据中看，python sdk 、openai 一骑绝尘，ollama 和 anthropic 用量相当，ollama 是真没想到，这么能打？大家的使用场景是什么呢？

把自己在做的事做好，切菜扫地，立业齐家，都应以平常心认真对待。
日常即道场，平凡即修行。

从明天起，我可再不想做机器迁移了……

为了省钱，买腾讯云的学生机 1 年期的，然后因为要迁移的东西太杂，花了 1.5 天时间……

1. 以后机器的初始化，全部通过 dotfile 去做: github.com
2. 配置文件之后若有需要，则迁移到 chezmoi 当中去 (上面的这些 dotfiles 也可以迁过去)
3. 以后所有的网站，全部通过 bt 去管理，看看迁移方案
4. 所有应用都通过 docker 去管理，数据挂在统一的 /data 目录下

服务器有多贵？人有多贵服务器就有多贵……

我需要两类编辑器:
- 基于文本文件
- 文件系统管理能力
- 基于行的文本编辑能力
- 恢复到任意操作的能力

- 基于语法树的编辑器
- 要有检索能力
- 要有位置定位能力

不论哪种都要有 status 和 summary 的能力，要有模糊输入的能力。

有 AI 辅助编程的情况下，尤其要关注项目结构设计，应当要把大量的时间花到设计上，不然后期就有的辛苦了。

使用 AI 编程工具的一些要点:
1. 结构清晰，表述明确的需求描述
2. 测试驱动的开发流程
3. 强调结构设计的重要性
4. 避免上下文过长，模拟不同角色，对同一个设计和实现的看法

大团队做产品有一个问题，当一个产品的初始形态还不够清晰的时候，定了一版，然后做后续的设计、开发、推广等等。

但这个领域发展很快，当初做产品时的一些假设变得有些落后了，此时产品就陷入了泥潭当中，不敢随便尝试，尤其是涉及到基本流程的一些特性。

即使大家可能都知道在这条路上走下去可能就回不了头了，但由于牵涉面有点广，加上又不是自己需要对产品负责，往往都藏着掖着，把真正的问题暴露出来。

或者即使暴露出来了，也不会受到重视，因为跟大多数人的利益不相符，搞工作嘛，有事情做就可以了，麻烦的事情就算了。

这也就是个人开发者和小团队的一些优势吧，所以在 AI 的加持下，以超高速的优化和迭代速度，去打爆一些大公司生产的臃肿的产品，这条道路应该是通的。

现在的 prompt 没有进化能力，只有特定模式下的引导和优化，优化受上下文上限的约束，本质都是建立在 “已有理论和认知” 的基础上做 “推理” 和 “尝试”。

进化的关键，在于上下文扩充和定向优化，优化的来源是什么？是基于理论推导(作出假设)、实验验证、形成结论的这套循环。

所以，prompt 的管理体系本身要拥有这套机制。

AI 应用开发的过程当中，有很多的问题需要解决，其中就有： AI 应用如何开发？

现在 AI 应用的主要开发语言是 python，另外 js/ts 的支持也逐渐丰富。究其原因有两个：
① 机器学习领域生态最完善的就是 python，最早能发现这个需求和机会的人，也是这个领域的人，因此有先入优势。
② 应用开发，这个领域人数最多的就是 js/ts 的人，他们是第 2 波大量进入 AI 应用开发的人。

开发语言的门槛本身不是什么大门槛，但大多开发者们都已习惯性固守在自己的开发体系下，向外探索的动力不足。比如一个熟练使用 go 的开发者，则不太愿意去理解 python、js 这类语言，有思维惯性的问题，也有职场环境的问题，也有业务系统现状的问题。

在后端应用开发这个领域当中，使用 python、js 语言的开发者规模较小，而使用 java 最多、golang 次之，传统的其他类型开发，则使用 C/C++ 居多，部分使用 php，其他语言则均是小范围使用。

一个 AI 应用由两部分构成： AI 能力的部分 + 非 AI 能力的部分。在已有的应用系统中，非 AI 能力的部分大都有较完善的解决方案，大都是基于原生态系统构建的能力。而当这些应用，希望加入 AI 能力的部分时，只会面临一个抉择： AI 能力的系统如何提供？

摆在他们面前的有两个选择：
① 使用和非 AI 能力部分不同的技术栈，比如 python、js 等等，但能获得比较完善的功能特性支持
② 使用现有的技术栈，比如 java、golang 等等，但不一定能获得完善的功能特性支持

在大多数企业和项目当中，这个抉择是发生在半年甚至一年之前，彼时选择方案 ① 居多，当时其他语言可选择的方案不多，相比于语言的熟练度，功能特性的比重会高于其他，主要也是由于能做决策拍板的人，往往不认为语言熟练度是什么问题，没有开发者自身的思维和情感束缚。

但如果这个抉择发生在当下或未来，当其他技术栈下的功能特性支持逐渐完善，在没有功能性上较大优势之时，则应用系统常用的 java、golang 的优势则会越来越明显，主要是： 资源消耗小、类型安全、应用生态完善。

所以，可以预见，在服务端的 AI 应用系统当中，java、golang 等的应用框架将会有越来越多的市场。

那么如何加速这个过程呢？分为两个方向：
① 结合语言和生态优势，集成丰富的功能特性，先追平功能，再形成优势特性
② 构建迁移的方案和指引，逐渐让已有系统迁移

AI 应用系统除了语言相关的业务逻辑开发外，还有辅助 AI 应用开发、运维、优化的支持系统，比如 组件能力提供方、应用运维系统、反馈及优化系统 等等。这些支持系统是语言无关的，因此要吸纳和拥抱他们，把它们融入到自己的生态当中来，以帮助自身形成强大的生态护城河。

AI 应用系统和传统应用系统有不一样的地方，同时也有很多相同的地方。对于不同的地方则要提出对应的解决方案，对于相同的地方则要考虑是否融入生态。

传统应用系统所需要的开发、部署、调试、观测等方案，在 AI 应用系统当中依旧需要，但也有一些独有的特性，比如观测的数据的形态和内容就和传统观测有所不同；比如在编排系统中的开发调试方式有所不同；

不同的地方核心在于 “数据”，传统应用在数据回流和使用上重要性不强，而 AI 系统则非常看重数据的利用，比如用于优化 prompt、优化模型等等，这将会是一项重点。