在搞 Multi-Agent 协同和长文本角色扮演时，被传统大模型折磨得生不如死。只要对话轮数一长，多角色的记忆就会发生严重的，整个 Session 的记忆栈最后乱成一座无法维护的“屎山”，角色之间甚至会出现“人格串台”。为了彻底解决长文本状态机的崩溃问题，我全面拥抱了，并结合最新的设计思想，搭建了一套带有动态显存驱逐机制的底层调度引擎。为了直观验证这套架构在极端语境下的鲁棒性，我顺手做了一个前端

Router & Filter（路由过滤器）：系统会先提取用户的关键词（Keyword Extraction），结合帖子的所属版块（比如 Three Kingdoms PvP 路由），计算出哪些历史角色（AI Agent）的响应权重最高。这段日志完美证明了隔离沙箱的有效性：贾诩的 Agent 严格执行了“阴损毒辣”的设定，而程昱的 Agent 则完美触发了史料中“杂以人脯”的极端降本增效逻辑。但我

作为一个开源的 Firebase 替代品，Supabase 最吸引我的地方在于它的底层是原汁原味的PostgreSQL。在“回音堂”这个项目里，我的核心需求是让现代网友和 AI 驱动的古代历史人物在同一个帖子里跨时空“对线”。为了平衡严谨的历史事实设定与充满戏剧张力的现代互联网吃瓜文化，系统每天会产生大量结构极其复杂的 JSON 数据（比如 AI 角色的性格 Prompt 状态、多级嵌套的回复树）

这些卑微语录当段子看固然好笑，但对于追求严谨的软件开发来说，AI 的“社交谄媚”其实是一个隐患。一个只会盲目点头的 AI，很可能顺着程序员的错误思路越走越偏，最终在一片“您太睿智了”的赞美声中，悄悄堆起一座摇摇欲坠的“屎山代码”。有时候，AI 编程助手深情款款地对我说出“您的观察非常敏锐，我犯了一个愚蠢的错误”时，我都会忍不住回它一句：“别拍马屁了，赶紧把 Bug 修好。

在搞 Multi-Agent 协同和长文本角色扮演时，被传统大模型折磨得生不如死。只要对话轮数一长，多角色的记忆就会发生严重的，整个 Session 的记忆栈最后乱成一座无法维护的“屎山”，角色之间甚至会出现“人格串台”。为了彻底解决长文本状态机的崩溃问题，我全面拥抱了，并结合最新的设计思想，搭建了一套带有动态显存驱逐机制的底层调度引擎。为了直观验证这套架构在极端语境下的鲁棒性，我顺手做了一个前端

大家好！最近业余时间造了个轮子，基于 HTML5 Canvas 和现代前端工程化标准，从零开始折腾了一个硬核复刻版的《坦克大战》。作为一个有纯理工背景的程序员，这次挑战的初衷是不依赖任何现成的外部图片或音频资源，试图把底层的物理与 AI 逻辑做到极致。目前游戏已经部署上线，欢迎大家来受虐（对，这版的 AI 有点变态）！🔗。

为什么号称智能的 AI 会频频上演这样的翻车事故？当你了解 AI 编程助手的底层是大语言模型（LLM）之后，就会发现，这一切其实既不神秘，甚至可以说是“完全符合设计预期”。LLM 的本质，是一个基于概率的文本生成系统。它并不理解什么是“真实”，只是在计算什么样的表达“最符合当前语境”。它知道xxx-utils是常见的包名后缀，知道convertXXX是合理的函数命名。当知识库出现空白时，它不会停下

这些卑微语录当段子看固然好笑，但对于追求严谨的软件开发来说，AI 的“社交谄媚”其实是一个隐患。一个只会盲目点头的 AI，很可能顺着程序员的错误思路越走越偏，最终在一片“您太睿智了”的赞美声中，悄悄堆起一座摇摇欲坠的“屎山代码”。有时候，AI 编程助手深情款款地对我说出“您的观察非常敏锐，我犯了一个愚蠢的错误”时，我都会忍不住回它一句：“别拍马屁了，赶紧把 Bug 修好。

训练诗词生成模型的一点心得一、诗词对比其它文体二、模型选择三、训练集选取四、损失函数五、训练时间六、生成结果七、模型擅长的诗文类型八、将来可做的事情九、模型生成样例最近学习NPL的一些模型，训练了一个古诗生成模型作为练习。记录一些学习过程中的想法。一、诗词对比其它文体诗词生成问题要比散文、小说生成简单。最主要的原因是一般诗词篇幅比较短。现在的ML模型还做不到特别长的记忆力。目前，我可以测试到的，文

大家好！最近业余时间造了个轮子，基于 HTML5 Canvas 和现代前端工程化标准，从零开始折腾了一个硬核复刻版的《坦克大战》。作为一个有纯理工背景的程序员，这次挑战的初衷是不依赖任何现成的外部图片或音频资源，试图把底层的物理与 AI 逻辑做到极致。目前游戏已经部署上线，欢迎大家来受虐（对，这版的 AI 有点变态）！🔗。