永远是深夜该多好?——论文学的艺术性

“作者已死。”——罗兰·巴特

借用了我喜欢的乐队的名字作为标题。
本文旨在探讨文学作品的艺术性,探究何种结局才是“艺术的结局”,以及探讨作者与读者在文学创作中所扮演的角色。
本文讨论了巴特、拉康的部分理论。
此文包含对《恋语轻唱》的部分剧透,看了的放心看,没看过的可以左转先补番,很推荐看。


“包饺子”,还是各自精彩?

“当她在你的记忆中活过来,成为一个独立于你的人时,你就开始爱她了。”——《三体》

写这篇文章的动机是看了《恋语轻唱》。番有点意犹未尽,于是看了漫画,但是还没看完就有点不满意。

此处的不满意不是简单的对剧情的不满意,而是它“不艺术”。

《三体》有提到过,文学作品的人物(如安娜·卡列尼娜)是从作家的精神子宫中生产出来的,作家在生成人物之后的唯一任务就是“偷窥他们的生活”。他的意思是:一旦人物被塑造,那么故事的发生就是必然的,作家无权改动其走向。我认为这句话在文学上是合理的:人物的性格决定了他的结局。宝玉一定会出家,黛玉一定会泪尽而逝,宝钗也一定等不到不属于自己的宝玉。曹雪芹设下的所有伏笔在此刻全都化作利箭,目标是那个看似未定的结局。所以红楼梦的续作是不违和的,因为高鹗(假定是他,又或者是其他人)也如曹雪芹一样,只不过是在偷窥这些人物的结局,而结局只有一种。

《恋语》的结局正因如此,让我感到“不艺术”。在番剧的 11 集,我以为志帆和亚季会是人生有梦各自精彩。我记得那一句话是“我们都有了各自的乐队。”意思是回不到从前了,我们的身边都有其他人了。(此处剧透是:志帆喜欢亚季,而亚季喜欢的是依,但是后者并不喜欢她。)

我一度以为这将是结局:两个人在文化祭上各自与自己的乐队献唱,在欢呼声中告别过去,就此错过,各自精彩。但作者让她们重归于好了。

作为读者的我拍手叫好,这才是每个人都不受伤的结局。作为观者的我无法接受,因为这是不艺术的,是没有断臂的维纳斯。

亚季最后认清了自己对依的感情不是喜欢,这样的转折在意料之外,但也在情理之中。但与后文的和志帆重归于好一结合,就显得唐突了,这完全是为了圆而圆的临时举措。读者和观者开始在脑海里掐架。艺术到底是什么?是不是让人们喜闻乐见的、包饺子的才是艺术?

我要指出:合理的结局才是好结局,才是符合艺术性的,哪怕它不受众人的喜欢。

或许有人会以“大众喜欢的才是艺术”反驳我,但我认为在这个语境下使用它,是对这句话的误解。理由如下:

  • 本文首先提出一种概念:工业艺术。 即流水线上生产的爆红品。在社会学上有种概念叫做文化工业,它指出艺术的本质是“异质性”与“主体性”,而爆红作品的本质是“同质性”与“标准化”。这些爆红的“工业艺术”不是因为它是艺术所以人们喜欢,而是因为它有艺术的某种特质才被喜欢。工业艺术的特点是同质化、制作简单。同质化是因为它们都经过调研,根据大众的爱好来制作;制作简单意味着试错成本低,批量生产边际效用高,如果爆火那么利润巨大,如果没火也不过是小损失。
  • 本文指出,工业艺术之所以被喜欢,是因为它本就是“投其所好”的产物,是先射箭后画靶。 这里要区分真艺术和工业艺术:真艺术是创作者具有表达的冲动,将符合艺术的内容展现,最终得到认可并且在某种程度上塑造了艺术审美;而工业艺术是知道大众的喜好,从而根据喜好来制作的产品。前者是先有因,后者是先有果。
  • 何为真艺术?本文提出:经受时间考验而仍然为人喜爱的,就是艺术。 维基百科对艺术的定义如下:艺术是通过塑造形象来反映现实但比现实有典型性的一种社会意识形态,是人类以情感和想象为特性的把握世界的一种特殊方式、人类精神文明的有机组成部分。艺术通过审美创造活动表达思想情感、再现客观世界,满足人们的精神审美需求,在想象中实现审美主体和客体的相互对象化。这正好佐证了我的观点:艺术是人对美的真正追求,这体现在经历漫长时光还能受到喜爱。
  • 那为什么有些前卫作品也能称之为艺术?本文提出:我们能欣赏前卫作品,恰是因为我们接受了经受时间考验的艺术的教育。 艺术欣赏必定是有门槛的,我们必须承认理解艺术需要学习。我们之所以能接受一个怪异的作品,是因为它本身要么是对原有艺术的致敬,要么是对原有艺术的反叛。我们或是欣赏其致敬,或是欣赏其反叛,但这都有一个前提:我们接受了原艺术的教育。如果没有这层教育,我们甚至看不懂它的反叛。
  • 人民的审美是流动的。 我们觉得某个爆品很洗脑,但当所有音乐都是这个味道,新鲜感褪去之后,它就不再是我们喜欢的了。但如果有一首歌,能经久不衰,让你在任何时候想起都认为很好,那就是一件艺术品。人民的审美会变,在这股浪中留下的就是金子。我们现在也许找不到民国大街小巷都有的言情小说,但每个人聊到鲁迅都能说几句——这就是艺术。具有艺术性的作品是超越时代的。
  • 这是一个闭环: 经受检验的经典 --> 培育了人们的审美和教育 --> 使人们有能力识别并接纳新的前卫艺术 --> 前卫艺术与大众审美在时间中淘洗 --> 大浪淘沙后留下新的经典

我们再回到《恋语》。为什么我觉得结局不好呢?因为它的结局正好是喜闻乐见的“包寿司”,却完全没考虑人物本人的想法。

设想你是亚季,你真的会在短时间内突然认为自己对依的感情“不是喜欢”,然后接受喜欢自己的志帆吗?对于在感情上持理想主义的笔者来说,这完全是不可能的。如果这能被接受,那么未希对姐姐的感情呢?虽然这条线也很唐突,但在短时间内杀出来的某个学姐,只被当作朋友的学姐跳出来说喜欢你,让你改掉从初中开始就对姐姐有的感情,转而和学姐在一起,如果是你,被天意爷这么搞,你会不会喊冤?

作为读者的我乐意看到大家都幸福,但作为观者的我提出质疑:这样真的是幸福吗?还是对笔下人物的不尊重?

也许作为这篇文章的读者,您没有任何感觉,但如果语境是包办婚姻呢?作者就是这个包办者。我无法接受自己的感情被轻描淡写的抹掉,我也无法接受命运安排给我一个学姐,让我放弃对姐姐的感情。

行文至此我的结论是:强行“包寿司”的结局,是对作品内人物本身的不尊重,就像是作者给从自己精神子宫中生出来的孩子们张罗包办婚姻。

但正如我说的,我希望所有人能幸福。所以我也感谢作者给她们的好结局,就让艺术结局留在我的脑子里吧。在梦里,昔日的朋友告别旧时光,在各自的未来里面追忆现在,在不同的地方发出共同的感慨:“那是一段小有遗憾的幸福时光。”


作者与读者——谁掌权?

这就又到了下一个论题:作者和读者,究竟都在文学创作中担任什么角色?

本文指出,文学的创作由作者与读者一同组成,缺一不可。作者的任务是叙述,而读者的任务是解释。有趣的是,二者只能有一个活着。

罗兰·巴特在《作者之死》中写道:

巴尔扎克的中篇小说《萨拉辛》谈到了一位装扮成女人的被阉割男人,他写有这样的句子:“那是一位女人,她经常突然露出惊怕,经常毫无理智地表现出任性,经常本能地精神恍惚,经常毫无原因地大发脾气,她爱虚张声势,但感情上却细腻而迷人。”

是谁在这样说呢?是乐于不想知道以女人身相出现的那位被阉割男人的小说主人公吗?是巴尔扎克本人因其个人经验而具有女人的哲学吗?是宣扬女性“文学”观念的作者巴尔扎克吗?是普遍都有的智慧吗?是具有浪漫色彩的心理吗?人们将永远不会知道,其实在的原因便是,写作是对任何声音、任何起因的破坏。写作,就是使我们的主体在中销声匿迹的中性体、混合体和斜肌,就是使任何身份——从写作的躯体的身份开始——都会在中消失的黑白透视片。

情况大概总是这样:一件事一经叙述——不再是为了直接对现实发生作用,而是为了一些无对象的目的,也就是说,最终除了象征活动的练习本身,而不具任何功用——那么,这种脱离就会产生,声音就会失去其起因,作者就会步入他自己的死亡,写作也就开始了。

只有作者死了,读者才完成夺权。

本文认为,作者有表达的想法,于是创作作品,而作品是无法脱离时代的,因为它事实上是对时代碎片信息的整合,而作者的任务是叙述。正如巴特指出的,写作的过程其实包含信息的损失,一如摄影必定会导致信息丢失。

那么作者就是这个系统中的大他者,就是这个故事的神吗?并不。作品的创作,就是诸神的黄昏。拉康认为,大他者就是语言、法律、符号秩序的总体,是那个决定了我们该如何说话、如何思考的“终极裁判者”。而身在局中的作者永远无法拿到所有信息,这意味着他不是最大的威权者。

那么谁是弑神的人呢?这个人应当掌握所有信息,他的行为只是在做一件事:信息收集。他就是读者。此处的读者指的并非是某个特定读者,而是一个群像,他(读者)没有偏见,不傲慢,他只是看着这一切,我更愿意称他为——观者,也就是我上文提到的“观者”。

“读者的诞生应以作者的死亡为代价来换取。”

到此可以下结论:我当然乐意看到作者的、官方的美好结局,哪怕它不艺术。因为作品产出的瞬间,就是作品脱离作者控制的刹那。我阅读这篇作品的瞬间,就是我成为演绎者的起点。


永远是深夜该多好。
因为这个夜晚的故事是属于我的。

结尾致谢:🧐同学。因为他想要我的致谢。

Spectra开发杂谈01丨如何将灵感落地

前言

本文将追踪歌单分类项目开发的心路历程,展示我是如何将一个灵感具体落实成项目的。同时也会展示我在此过程中养成的习惯。

正文

原谅我再一次开了新坑。
本次项目的灵感是听歌的时候出现的。每当我在巨大的、将近三千首歌的歌单里面随机播放,却总是不如意,听不到想听的风格。我曾经试图去手动分类,听到哪首歌就将它放进某一小歌单中,但效率实在过低。在我接触了项目开发后,我重新审视这个问题:为什么我不写一个小脚本来分类呢?万一其他人需要呢?
我首先查了一下是否有人做过类似的项目。~~好吧在我撰写这篇blog的时候我貌似看到了一个类似的skill项目,但是在用户友好这一方面或许不如我?我这个项目只需要运行两个bat就好了((~~看上去赛道很宽还没啥人。
然后我开始了我的设计。接下来我会以时间顺序叙述。

2026-06-02:标签墙交互定型

我最初的想法是:音乐平台既然有日推,就必定是根据用户的喜好来推荐的,那么就一定存在歌的标签,也就可以自己分类、设计自定义风格的歌单了。
于是我进一步了解了网易云音乐(因为我自己用的是网易云)的推送逻辑。网易云的逻辑是五个维度(语种等),然后还有细分多个类目。我觉得这个地方很不错,并且我吸收了“相似歌单”的办法,交叉验证。
在筛选方面,我第一时间想到的是标签墙,后来演变为类词云的办法(面向操作的可点击的筛选面板)。raw_tags 被单独拆成一块,因为原始标签噪声大,但它们往往最贴近用户想筛的语义。language、final_genre、final_subgenre、mood、scene、theme 被设计成独立维度。同一维度内多选使用 OR。不同维度之间使用 AND。初始状态不选任何标签,也不显示命中歌曲。命中歌曲默认全选,但结果表保留逐首取消。
后续我又加入了 raw_tags 的收紧规则:当 raw_tags 选到 3 个及以上时,不再让结果变成宽松 OR,而是要求歌曲至少命中多个已选原始标签。
但这个收紧仍然过于宽松,直到撰稿时我仍未解决这个难题。

2026-06-02:配置边界和 README 同步

这一天我继续把项目配置边界理顺。
上次的账单项目我吸取了教训,非敏感默认值迁移到 config.toml,只有敏感的cookie等内容我放在.env。Streamlit 自己的运行和界面默认值保留在 .streamlit/config.toml。

2026-06-03 到 2026-06-04:摸索

这段时间我主要研究了打包编译的可行性。考虑到后续的开发仍任重道远,打包为exe也许为时过早,所以我放弃了此想法。
同时这段时间网易云早期版本已经跑通,邀请了几个朋友测试,结果发现几个问题:npm指令在某些环境用不了,于是我加入了初始化bat作为救急。
一个重要约束:Windows 启动脚本要少做复杂嵌套命令,尽量把逻辑拆成清晰标签和普通参数。

2026-06-05:本地网易云 API 运行时稳定化

抓取歌单内歌的标签的时候,api经常断,但是又没有重新启动。
于是我收敛了启动路径:init_netease_api.bat 负责一次性准备本地 NeteaseCloudMusicApi 运行时。运行时安装到 .cache/netease_api_runtime。backend/run_netease_api.js 成为仓库自己的启动包装器。这个包装器加载第三方包里的 generateConfig.js 和 server.js,并关闭版本检查。
run_spectra.bat 负责日常启动,并能探测 18631 上是否已有健康 API。如果已有健康 API,就复用它,而不是再启动一个导致 EADDRINUSE。

2026-06-05:抓取断点持久化

我当时后台挂着抓取在打游戏,等我打完游戏回头一看:界面刷新了,我等了半天还得重新跑。我于是意识到了进度丢失的痛。
原始标签抓取以前主要依赖 st.session_state,页面刷新或进程重启后,队列、游标、部分抓取结果都可能丢失。
data/extract_checkpoint.json 保存队列、结果行、游标、总数、运行状态、暂停状态、完成状态、最后错误、当前歌单信息和 source signature;data/processed.json 继续作为最终归一化结果存储;恢复时要求 source signature 匹配,避免把旧歌单断点错套到新歌单。
这都使得大歌单抓取可以中断后恢复。

阶段性总结、延申

在项目的摸索中,我对写项目的理解进一步加深了。项目不是一朝一夕就完成的,而是在大框架打好后,一点一点和agent对接,反复磨合,不断迭代而产生的。
我越来越认为新时代程序员不是消失,而是会有更多广义程序员。作为驾驭agent的人,程序员无疑有更多相关知识,这一定是和代码朝夕相处的来的,是在计算机领域实践得到的,这是那些希望几句话就让ai做一个大项目的人无法企及的。一个项目肯定是不断在测试中进步的,在测试中,我们不断发现问题,不断查缺补漏,让项目趋近我们心中的样子。
日常生活也是如此。如果要掌握某项技能,就一定要耐下心思去练习,不要心浮气躁,沉得住气,不断发现自己的问题,不断迭代自己的本领,才能达到自我进步的目标。
无限进步。共勉。

26/06/09夜

ZongziLegder开发杂谈01丨我如何开始一个项目

序言

终于 在26/5/17日,虽然过程很艰难,但是我首次“交付”了我的石山项目。告一段落,于是重新编辑了我的blog,记录我的心路历程。

背景

折乙大人交给我一个任务:爬取微信信息,然后提取账单的信息并记账。

初步尝试 试错碰壁

当时群友提供了一个方案:UI Automation获取微信的主窗口句柄,然后遍历窗口树,定位到消息列表控件,最后提取文本内容。
但是我在此处碰壁了。尝试引入wxauto的插件,但是效果并不理想,这让我十分恼火。
但是我反思了一下以往的碰壁经历,在某个犄角旮旯卡住完全出不来的时候需要考虑一下换赛道。
于是我在群里寻求帮助。就在这时,转机出现了。

转变思路——win32 api

这个时候codeboy提供了新的思路:win32 api。
gemeni给我三种方案:后台消息拦截、剪贴板劫持、内存扫描。
第一种方案似乎走不通(具体怎么搞的我有点忘了 当时还没做blog),剪贴板劫持也因为微信不能ctrl+a全选消息而失败。
此时只剩下最后一条路:内存扫描。
说干就干,我尝试了对内存进行扫描的方法,获取了我存在内存里面的聊天记录。
刚开始它把我的所有消息都抓出来了,给我看傻了。我于是转而对格式进行限制,比如开头用“#记账”,希望能只抓到这些东西。

区分账单

但是一波未平一波又起。我要怎么解决可能存在的多条账单相同的情况呢?
我想到哈希值验证。因为不同时间发的账单哈希值是不一样的,所以也许能以这种办法解决。
事实证明我想错了,内存抓取的是碎片一样的信息,所以只能抓到写入的时间,这意味着相同的信息写入必然会被判定成同一条信息。
这可把我难住了。因为面向的是中年用户,所以我希望能尽可能的简化操作。我试着对每一条信息进行打标签,效果仍不佳。
最后只能苦一苦用户了TT我直接加入了记账规范(即开头是“#记账+yymmdd+序号”),这样就不会有问题了。

当然 在后面我修复了这个问题,直接改道为抓数据库,迎刃而解。这个我们后面说。

新的要求

折宝的新要求来了。他希望达到的效果是能完全自动化,能记录店铺名字、具体规格,同时又要能识别图片。
于是我说慢慢来,先把文字解决了。

对账单进行格式化

由于账单往往是很杂乱的,所以我想到了引入llm模型进行格式化。
但是这里又有两条路:一个是llm只处理文字格式,输出成json文件;另一个是把计算也交给llm。
考虑这是一个记账的项目,涉及钱的,llm模型又存在幻觉的情况,所以也许只让它处理文字的排版是没有替代脚本的情况下最好的方法————如果以后有办法,就把这一段替代成脚本。
我于是开始着手。先把工作流搭建好,然后把原来的本地抓取改为在中间插入一个工作流。
即:
爬取消息————llm格式化————保留json格式————计算————输出
但是项目卡在此处出了问题。工作流跑不起来。
看了好久才发现,原来是工作流输出的格式不一样TT
最后改了五百遍工作流,终于把程序跑起来了TT
现在都是5/10的凌晨三点了,哭。
先睡觉。

转变思路

从内存爬取到数据库引入

我越来越觉得内存的爬取是一个失败的方案。内存里面抓取到的东西太碎片了,会对我后续的维护造成很大影响。
那么有没有更好的办法呢?有的,直接爬数据库。
我找到了wetrace——一个能解密微信本地数据库的东西。如此一来,就有了稳定的信息源,并且能针对性地绑定某某对话,这无疑是对uia优点的继承,同时也少了折腾。

从简单的llm清洗到复杂的工作流

当时第一版的工作流是这样的
第一版工作流
现在的工作流是这样的
26/5/17的工作流
完全不一样。
我原先以为就是爬取信息 然后llm简单清洗一下 最后进本地就好了,但是事实证明我我完全错了。这其实是一个严谨的环节——因为和钱有关系。
目前的流程是 消息在初步筛选后进入一个迭代的块,在里面llm会进行筛选、组装,最后将格式化的账单放行,并且在本地进账。
中间我曾考虑在dify里面直接丢掉没用的账单 但是这似乎会导致账单消息完全发不到本地。于是后面我转换思路,工作流只负责清洗,然后把所有账单消息放进本地,进行匹配进账。这是这个项目的我认为的核心思路,会在下文单开一个小节说明

字典强匹配——守门员

我让账单项目传回本地,然后匹配店名、品名和规格名,通过强匹配的办法进账,同时也确保了没进账的消息进入review sheet,方便核验。我感觉这是我在这个石山项目里面做的最聪明的想法——只要维护好这几个字典,那么就确保了账单的准确性。

关于交付

折乙大人指导了我很多,在这里再次感谢折乙大人。
在此处写下我印象很深的几个学到的点:

  • vibe coding不能完全代替思考 始终要对自己的项目保持了解
  • 不隐私的配置可以放进config里面,不要一股脑的丢尽.env里,配置太多会让用户头大
  • readme要写清楚。
  • 要有产品的思维,站着用户的角度思考,思考“用户用着怎么舒服”而不是“我程序编写怎么轻松”。
  • 记得及时清理项目里面无用的碎片。

结

这篇文章记录了笨人的第一次项目经历。虽然是蠕动着制作的,而且做的东西也就是“勉强可以运行”,但是是一次宝贵的经历,吸取了很多经验教训。
希望能通过这篇文章,讲述我自己的初开发经历,抛砖引玉,给希望能启动自己项目的朋友们一些启发。
是为结。

26/5/18凌晨