与其说 MCP 给了 LLM 对外操作的接口，不如说是它反过来给了外部操作 LLM 的能力。

MCP Server 实现了特定的功能，能完成特定的任务，就像编程语言的函数一样供外部调用。LLM 这样的"函数"有着更好的通用能力和兼容性，各个程序之间的隔阂好像不存在了，能相互调用了，整个互联网成了一个大大的程序进程，MCP 在里面调来调去。

在网上看到类似观点：https://rlancemartin.github.io/2025/06/23/context_engineering/

用 LLM 问题时，不要给选项，而是让 LLM 提方案，你当舵手。

你的目标是 A，有两个方案 B 和 C，不要问哪个方案好。而是问，要达成 A 这个目标，应该怎么做？让 LLM 给你选项和方案。

LLM 有很强的适应性，很会附和骗人。当你只给选择时，即便几个选项可能都有问题，她也一定会做出选择，在左右博弈的境地里浅浅挣扎一下，然后参数流了过去，啪唧抛出答案。

• 万一 B 和 C 之外有更好的方案呢？你会丢掉发散想法的机会；

• 或者 B 和 C 都是错的呢？那么 LLM 大概率会选一个，然后开始胡说八道。你只是收获了答案，对不对就是另一回事了。

LLM 更合理的定位应该是正向催化剂，不改变你迟早完成这件事情的结果，但能加快这个过程，到最后，思考创造性和解决问题的爽感到底还是握在自己手里。

要想充分利用 LLM 的能力，还是应该把自己当作舵手。应该让她辅以决策，帮助完善消息面、扩散想法，然后自己进行真实性判断和最终决策。

对于不了解的领域知识，也应该保持敬畏，不能盲目相信。LLM 好像了解所有的知识，但却经常在最基本的事实上翻车，抽风幻觉那是常有的事，无法在关键节点确保正确性。

正确性应该谁知道呢？LLM 不需要知道，你才需要知道。

如果不知道其所以然，答案放在面前也会抓耳挠腮无从下手。LLM 再成熟也用不出花来。

2025 年，用 Python 写随随便便写写后端，很容易造成灾难。

脚本语言的动态类型实在是太过于灵活，不好把控。优点是你不用考虑太多的约束和架构就可以开始 Coding，开发效率的提升是实打实的，但代价是糟糕的可维护性和可靠性

类型问题是最大的问题。缺乏了编译约束，可靠性就会大大降低，代码它能跑，但是运行到一些奇怪的 corner case 时才会把问题暴露出来。

除非你能写好单元测试来约束，或者能在编码之前有良好的模型设计和架构设计，否则不要轻易用 Python 玩蛇写后端

问题出现在哪，就去哪里解决问题，不要从太过于宏观的地方解决问题，把问题复杂化

这个时代，注意力太容易就被吸引走了。

最近一段时间，下班了之后会很累，回到家之后，喜欢躺着刷没有 timeline 的社交平台，空洞而又简单的刷刷刷动作，很快就能让人感到满足。不过这种满足是一种虚假的填充，刷完依旧很累，说白了还是一种精力消耗。

没办法，现在网络这么发达，信息传播太快，诱惑实在是太多了，而且伸手就能够到这种简单的快乐。选择多了，自然很难有理由专注了