ynsstudy

关于人生第一次写小说

Tue, 2 Jun 2026 18:15:52 +0800

前言

最近闲来无事，一直在折腾一些和 AI 有关的东西。折腾着折腾着，就想着能不能让 AI 帮忙写点小说，然后我再发到小说网站上，说不定还能挣点零花钱。

正文

一开始我以为，用 AI 写小说应该挺简单的。后来才发现，如果只是要求“能看”，也不是完全丢给 AI 就行。

剧情大纲、世界观设定、人物关系、故事走向，这些东西还是得人来整理。

于是我大概花了半天时间，把这些内容一点点梳理出来，再交给 AI 去写。

然后 AI 就开始哗哗地写。

说真的，最开始我对这本小说的质量并没有多大期待。

我的想法很简单：写完之后投到某某小说网站，能不能挣到钱另说，至少先试试水，赚点零花钱也行。

但是后来写着写着，我发现事情好像变得不一样了。

我开始把文章里的主角想成我自己。那些我在现实生活中没有完成的事，那些我曾经幻想过却没有做到的选择，好像都能在小说里慢慢实现。于是我对剧情走向、人物之间的关系、每一个角色的命运，都开始变得越来越苛刻。

最开始的时候，我一天能写好几万字，简直像是在批量生产。

可到后来，我开始一字一句地读。遇到语境不对的地方，我会自己手敲修改；遇到人物情绪不够准确的地方，我也会停下来重新调整。

原本只是抱着玩一玩的心态，想试试 AI 写小说到底能做到什么程度。可写到后面，这本小说对我来说似乎也越来越重要了。

有时候我吃饭睡觉前都会想这剧情的走向该如何选择，可能这就是处女作的含金量吧。

用 Codex 做项目之后的一些感受

Tue, 26 May 2026 15:37:15 +0800

最近这段时间，我在自己的博客项目里接入和使用了 Codex，也就是现在这类可以直接参与代码修改、检查项目结构、生成素材、辅助调试的 AI 工具。没有使用CC(claude code)的原因还是因为太容易封号了

一开始使用它，只是觉得有些功能自己写起来比较琐碎，比如前端页面调整、素材处理、移动端适配，还有后端接口的一些配合逻辑。如果全部自己一点点写、查、改、测，时间会被很多细节消耗掉。

因为一个博客系统写代码最多还是增删改查

但真正用下来之后，我能明显感觉到工作方式(或者说思想，也有可能是动机)发生了一些变化。

以前做一个功能，很多时间是花在“想这个功能要不要做”上。比如某个页面布局不太舒服，需要不断调 CSS；某个交互需要补充状态；某个按钮点下去之后，前端要有反馈，后端还要记录日志；再比如图片素材不合适，还要考虑透明背景、尺寸、风格统一。

这些事情都不难，但很消耗精力。

有了 Codex 之后，它更像是一个可以一起做项目的秘书。我把需求描述出来，它能先看项目结构，再根据已有代码风格去修改，而不是完全从零开始乱写。

和网页端最大的不同是它可以直接操作电脑文件，虽然对于安全层面确实可能不太友好，但是对我来说，电脑上的文件也没什么有价值的东西...

让我印象比较深的是，它不只是写代码，还能处理一些比较细的体验问题。比如手机端按钮太靠下，或者素材背景不透明，再比如功能区太臃肿，需要重新调整布局。这些如果靠自己一个人慢慢调，也不是不行，但会花不少时间。

Codex甚至可以自己打开浏览器来验证它写的东西是否符合预期

有时看他的思考，真的让我惊讶哭笑不得,你既然不想糊弄过去,那么从一开始就给我生成好了呀

我现在对 AI 的感觉是，它不是简单替代程序员，而是把很多重复、琐碎、耗时间的部分提前处理掉。这样我可以把更多精力放在“这个功能到底有没有意思”“用起来顺不顺”“项目后面要怎么优化”这些事情上。

对于我自己的博客项目来说，Codex 带来的便利很明显。以前可能一个小功能拖很久，现在可以更快地尝试。想到一个点子，可以先让它帮我做出第一版，然后我再根据实际效果调整。这个过程让项目迭代变得轻松了一些，也让我更愿意去加一些以前觉得麻烦的小功能。

我觉得注意的是，要保留自己的判断。AI 很强，但它并不了解项目背后的所有取舍。有些功能看起来很酷很强，但不一定适合当前项目。有些代码能跑，但不一定是最好的实现方式。

总的来说，Codex 确实让我感受到了 AI 的强大。它让开发变得更顺手，也让我更愿意去完善自己的项目。以前很多想法可能只是想想，现在可以更快地试出来。

让我有更多精力去真正写博客，而不是一直在完善网站功能。

以后我应该会继续把 AI 用在项目开发里，但不会完全依赖它，不至于失去自己的想法。

RSS 折腾后续：慢慢修补

Fri, 22 May 2026 10:11:10 +0800

昨天刚把 RSS 的后端接口折腾完，把那些严苛的 XML 格式修补好，本以为这事就算告一段落了。没想到今天看博客的时候，收到了一位博友的留言。

他给了个很实在的小建议，推荐我把 RSS 的链接配置在网页的头部里。说是加上这个标签后，各种阅读工具和插件就能识别到订阅地址。

看完这句提醒，心里觉得挺感慨的。其实写代码或者自己搭网站，很多时候容易陷入“自我良好”的状态。。如果不是这位博友点醒，我估计很久都不会留意到还有这种规范。

于是趁着代码没忘，顺手去前端的项目文件里，把那行的代码补了上去，重新打包发布了一下。整个过程并不复杂，但敲完最后一行代码重新上线后，总觉得这个网站又变得完整了一点点。

在此也简单写下这篇随记，算是对这位博友善意提醒的感谢。

至于加上这个功能后，会不会真的带来多少新的订阅，或者对后续的各个平台收录有多大帮助，我倒也没有去强求。在这个节奏越来越快的互联网里，能有这么一块属于自己的角落，偶尔收到一两句路过行人的指点，然后一点点完善，这本身就是一件挺让人开心的事情。

关于 RSS 订阅的一点小折腾

Thu, 21 May 2026 11:34:39 +0800

起因:

最近闲来无事，寻思着给网站加个 RSS 订阅，顺便去几个导航站(博客聚合)提交一下收录。其实在这之前，我对 RSS 到底是个什么东西并没有太多概念，只知道它是某些网站角落里那个不太起眼的橙色小图标。既然网站从最初的个人笔记慢慢变成了支持多人的合集，总觉得该完善一下这些基础功能。

准备动手:

刚开始觉得这东西不难，无非就是用 Java 查一下数据库，拼接一段包含和的 XML 代码。看着浏览器里打印出来的树状图，觉得大功告成了，就顺手把地址填到了提交页面上。

磕磕绊绊:

结果很快就被打回了原形，系统冷冷地提示：“RSS 地址不正确，抓取不到正确内容”。

我盯着屏幕发呆了挺久，把别人的 RSS 源和我的放在一起比对，看着似乎没什么区别，标签结构都是一样。后来耐着性子查了查资料，才发现这个有些年头的协议，对格式有着一种固执的严苛。

比如时间格式，我们平时写接口习惯直接输出 2026-05-20T10:28:28 这样的标准时间，但 RSS 的规范里只认 RFC 822 标准，非得是带有 +0800 时区标识的英文格式。

没办法，只能老老实实去改代码。为了兼容数据库里查出来的各种时间类型，特意抽离了一个方法把时间全部转成它认识的样子。顺便也在 XML 顶部补上了 W3C 规范要求的自身链接；考虑到以后社区文章变多，把用来做唯一标识的从单纯的数字 ID 换成了完整的文章链接，免得产生冲突；最后，还加上了一个，告诉外界网站最后一次更新是什么时候。

把这些细枝末节的东西都修补完，重新部署上线，又重新提交了一次申请。现在能做的，也就是等一个不知道会不会顺利通过的回复了。

结语:

写代码有时候也是这样，看着简单的东西，里面往往藏着很多不经意的细节。暂时不去想收录的结果如何，慢慢打磨、慢慢完善就好。就像写博客一样，不用急于求成，哪怕走得慢一点，只要这个站点还在一点点变好，回头看看，为了几行代码折腾的这半天时间，想必也是值得的吧。

终于支持匿名评论了

Wed, 20 May 2026 10:28:28 +0800

新功能上线：博客终于支持匿名评论啦！

是的，以后看到喜欢的文章，不再需要繁琐的注册和登录，直接就可以留下你的脚印了！

回想最开始做这个网站的时候，完全是脑子一热的产物。当时全凭自己的直觉“闭门造车”，压根没去翻找、借鉴其他优秀博客的样式和功能设计。

直到最近闲逛其他大佬的博客时，我发现大家普遍都支持匿名评论。虽然我的网站定位和纯个人博客有些区别（大部分个人博客压根不提供登录入口，而我做了完整的用户系统），但不得不承认：“必须登录才能评论”这个设定的确太反人类了。

繁琐的步骤不仅劝退了原本想要交流的朋友，也让互动变得极其不人性化。所以，痛定思痛，我把“匿名评论”安排上了。

（当然，我也很清醒：有了这个功能，也不会有很多人来评论就是了）

闲聊几句：我为什么讨厌“无意义的更新”

对于我个人而言，我一直非常讨厌那种“为了更新而更新”的无意义折腾。

比如什么呢？今天花一两个小时把前端某个按钮往左边挪了两个像素；明天又给页面加个花里胡哨但毫无卵用的小动效；又或者是陷入“强迫症”，为了所谓的“完美对齐”把 CSS 翻来覆去重构好几遍……

这种折腾，说白了就是程序员的“自我感动”。 它对实际的使用体验没有任何增量价值，只会无端消耗开发者的热情，甚至有时候改着改着还顺手引入了几个新 Bug。相比之下，我更倾向于去做一些切实提升体验、或者解决真正痛点的功能迭代。每一次代码的提交，都应该是为了让这个网站变得“更好用”，而不是仅仅“看起来不一样”。

这也是为什么我渐渐觉得，经常去串门、阅读别人的博客，好处是大大的有。闭门造车容易陷入死胡同，而出去转转，每次看到别人网站上那些让人直呼“卧槽，好方便”的设计时，我脑子里冒出的第一个念头就是：

“这玩意儿真香，我要怎么把它搬到我的网站里？”匿名评论就是这么来的。