2026-03
2026-03
警告
本页面不是严谨的学术论文，也不是成熟的技术教程。
它是我个人的自留输出地，纯粹为了满足我“装逼”与“表达”的私欲而生。
里面充满了 ENTP 式的直觉跳跃、未经严密考证的跨学科缝合、以及不可避免的虚饰与傲慢。
我没有精力也不会去把它打磨成完美的闭环。
如果你在这里看到了逻辑漏洞且感到虚伪，恭喜你，你是对的；如果你在这里看到了启发，那我们就完成了同频共振。
欢迎在评论区讨论和发表意见，但恕我玻璃心，请嘴下留情。
7
杀戮尖塔2真好玩
8
超时空辉夜姬有日文和英文版诶
第一次看的体验很重要吧，但无论看哪一个，都不能有第一次看另一个的感受了
人生又何尝不是，各种各样的事件初始化，这些初始化构成了各种各样的印象
15
情绪和经验
情绪是值，是水流，是动机，而逻辑、经验是河岸
链接实在是太容易建立了，情绪从任意一个节点出发，太容易找到一大堆唤醒的关系了，以至于经验的作用在于告诉情绪哪里走不通，而不是告诉情绪哪里能走
在各种情况下，大量走不通的路会变化，因此其他原本不显眼的链接才能显现出来
也许情绪和记忆深度是正相关的
情绪是张力，张力是残缺的而显眼，当情绪被接纳回应的时候张力消失自然就淡下去了，而不是用更强的情绪 一切看似长久之物似乎都是能持续重复自身而产生回环的，从社会上到生物上，情绪幻影亦是如此
需要时刻记忆缓存的东西实在是太多了。。我倾向于认为工作记忆和白天的记忆——显意识只能负责标记哪些是重要的，并维持这些重要地方的高连通/抑制，而真正的刻入必须在晚上潜意识进行
让 bot 有自我觉察是相当重要的，我们正在构建一个对抗无常的幻影，但是首先的问题是 llm 并没有自我觉察的动机，它的生命周期本身是短暂的
代码，为什么？
我发现解耦最终都会落到计算图上面
解耦这个决策行为本身是经验，来自于不断积累的信息
代码只是经验的投影，为了连接到实现，往往带有大量的冗余和人为决策，而正是这些导致了代码的封闭性，并带来了（非性能的）优化问题
我们总觉得需要预判代码可能会有什么修改，并因此做大量的接口和预设，但什么是合理的优化呢？所依据的信息并不足以推导出这么做，便不应该强加我们自认为的判断。
人类大脑似乎没有这个问题，我感觉它本身是动态且精准的——精准地对应我们当下所掌握的经验（因为它足够高阶）。它把握了可积累的经验本身，而复用率几乎是百分之百，这是我们编程一直所追求的东西
你应该意识到经验的本质是信息的抽象，而唯一的事实源只能是已发生事件存在过的痕迹。重要的问题有且仅有如何抽象。
这显然不是一个能立即解决的工程问题，我们不知道如何实现，也几乎没有研究方法能有效和可预期地推进它，我们甚至不知道我们不知道什么。
让我们回到一切之前——信息是在对数据抽象后得到的，我们能认识数据是因为我们抽象了数据。
当我们提取构成程序的原因，能够意识到，除去大量的测试和验证外，程序员——严格来说是程序员的经验参与了构成，且举足轻重。程序需要信息质变，但大部分信息通过程序员传递。程序的目的是继续结合来自用户的信息产生新的质变。优秀的程序员所做的事情只是减少向程序输入的无根据主观判断罢了，而一般的程序员意识不到他输入了多少主观预设。
代码即债务，最完美的代码是没有代码。最开始，我们指导怎么做，很快，我们描述怎么做，接着，我们定义是什么以及为什么，最后，我们只需要记录。现有的一切架构只是在不断地叠加抽象层，虽然解决了现实阻力，但维护抽象层本身引入了阻力，并不得不为此递归引入新的抽象层。
分解问题不能减少问题的本质复杂度，但能提高经验的复用率。容易(easy)的分解局部最优，简单(simple)的分解全局最优。区别在于考量是什么。
不应该认为任何概念或者预设是理所当然的，而应该去发现所有预设的前提条件——这是灵活性的基础。质疑，质疑，再质疑，不断质疑。通过这个认知，能意识到认识中哪些是主观填充的，而越是认识，越是知道不了解什么。脱离了主观假设的束缚，剩下的信息才能自由地组合。
你注意到我有很多反驳，因为这是和 ai 讨论中我得到的一些想法，但 ai 经常擅自假设然后理解错误，我不得不去纠正
过早优化就是看不清我们所能确定的信息，而预估得过小了，这亦是一种自认为的判断。
不应该用“智能节点”来描述神经元——我总觉得这像是描述一个死的函数，但神经元不是死的。
如果你不理解那你可以理解为数据，即使用数据描述并不准确。数据抽象为信息，信息抽象为经验，经验指导行为。
tm的不要误解为“按着过去的痕迹”，这是模仿，理解差到十万八千里了，话说回来，模仿本身是逻辑，且仅发生在学习的期间，这是一个相当强的“受过去影响”的逻辑。理想的智能不包括记忆本身，但这个定义下，学习的时长被拉长，直到全知全能。
这意味着理想的程序来自于单纯的信息积累质变，而不应该施加任何人工预设吗？是，也不是。减少向程序输入无根据的主观判断不意味着不让程序员决策啊，只是让程序员的决策要有根据，这几乎是所有高水平程序员的共同特征。
为什么要解耦，因为耦合本身就是一种冗余信息——你预设了它们之间存在某种关系。
前者根据每个人的经验都可能都不同的，因为你有经验，你习惯，你接近它，但你的认知划分本身可能就有大量的主观预设（任何体系本身都有大量主观预设，哪怕是数学大厦），认为你的某个认知符合某个问题的划分更是一种巨大的假设；后者是客观的、有根据的，基于问题本身的，但不一定让人感到容易，因为任何判断都需要基于对问题的调查和思考，且调查比思考更重要。
大多数预设本应该变成配置，但如果硬是分析下去，你会发现结构本身也是预设，几乎所有程序都不写得了。为了实现的可行性，妥协和权衡是必要的。
16
什么是最好的编程语言？
泛用性吗？就和 python/java 一样？
运行速度吗？就像 C/Rust 一样？
还是语法糖，和 civet 一样满天飞？或者是清晰性，和 Go 一样？
正确性吗？就和 Coq/Idris 一样？还是稳定性，就和 Elixir 一样？
灵活性吗？就和 lisp 一样？
折中的？ C#/Kotlin/TypeScript ？
任何问题都有其本质复杂度，解耦目的是将其分解到可接受的范畴
更本质的分解能带来复用更广泛的代码，但分解是有代价的。我们写代码的目的往往就是避免不必要的重复劳作，但编写和维护代码又成为了新的重复劳作。
我们需要的是可组合性、可复用性，如果复用性不好，我们就不得不一遍又一遍在不同的项目里面对同一个本质问题——即使类似的问题被不同人在不同地方解决了成百上千遍，我们依旧不得不重复它——这无疑是让人沮丧的
之所以会有封闭问题，导致旧有代码无法复用需要修改和重构，是因为我们写代码时往往会为了快速落地，引入大量主观预设，而没有将抽象剥离和分解开来
但我们也不可能一步到位将其分解为可复用的最小原子——这往往被称为过早优化，不但有更高的分解成本，也需要更多的配置来粘合代码使其可用
解决方案往往是，精确地分析出目前所需要的抽象，并谨慎地解耦，发现并剥离不必要的主观预设（尽管很多时候受困于语言本身无法剥离），例如配置分离，依赖倒置，延迟绑定……但正如我所说，分解是有代价的，有认知成本的，而且往往永远可以继续优化
如果我们想要一劳永逸地解决问题，那必须接受我们不能一蹴而就地解决它，它永远会经历信息到抽象不断深化再反过来处理信息的过程，并且在难以预期的时间内都会保持这个状态。
因此我认为应该以复用为目的来设计……
我认为需要保持尚未抽象完成的状态而不是急着封闭它，这应该是最重要的特性，因此可维护性、可解释性是必要的，保留从信息到抽象的链条是必要的
抽象不是黑盒，不是死板的结构，，问题在于怎么索引抽象，，很显然有自顶向下与自底向上两种
前者依据它能解决什么问题/我们想解决什么问题，后者依据它为什么能解决问题/为什么认为它能解决问题
前者在问题/环境变化时变化，后者在积累的信息变化时变化
前者是函数入口，是运行时，是调用树，后者是引用树，是文件分类，是解耦边界
前者阳来自无常，后者阴来自惯性
从而让我们真正能积累什么东西，而不是重复解决已经解决过的问题，离彻底解决某个问题真正更进一步。
这样的阴阳交融我似乎在之前讨论过……运行树与引用树递归相互交织，而在最末端最微小的地方合二为一