2 个小工具
第 1 个小工具，是防止自己沉迷 v 站的浏览器插件。 以前都是比较频繁刷 v 站，浪费很多时间。现在，这个插件可以帮我抓取最新的帖子，以及最新的回复。原理很简单，每隔 10 分钟左右打开首页的 10 个 tab ，看看是否有新帖，以及老帖是否有新增的回复数。如果有新回复数，那就每隔 1 分钟左右抓一个新回复。（所以对服务器的压力不大）。这个插件大大减小了刷 v 站的时间。
第 2 个小工具，是自媒体话题的管理工具。 想了不少待创作的自媒体话题，考虑到每个话题的创作，都需要经历构思、搜集资料、学习知识、制作脚本、制作素材、集成等等固定的几个步骤。所以，想着把它们以类似 CPU 流水管线的形式，管理起来。A 话题在搜集资料时，B 话题在制作脚本，C 话题在构思阶段。这样让同一个话题的创作，分散在很多天，防止某个过程卡住。所以做了一个统一管理的页面，可以设置阶段、状态等等。
感想
这些工具，完全是以 vibe coding 的形式完成的，没有任何手动介入编码。
所以现在的感想是，任何普通人，都可以着手编写自己的工具了，未来的比较简单（什么叫简单，视 AI 的能力而定）的软件工具，根本无需再由开发商开发、发布这样的过程了。用户可以自己制作，自己发布，自己修改，自我满足。
这到底意味着什么呢？当用户可以自己用 AI 完成自己的软件，那就相当于提供 AI 的公司就是一众软件的提供商了。用户向 AI 公司付费，而不是向软件开发者付费。如果说简单的软件是这样，那么复杂的软件呢？会变成什么形态？
未来真是难以想象。
 |
1
purringpal 4 天前  8
这种 AI 做了个小工具的感想在 v 站看了 2 年了，很疲劳了。
|
 |
2
baiyuxiong126 4 天前
现在 ai 在处理非文字信息，如图片视频等差一些。等什么时候可以直接读自己输出的 ui 界面了。程序员就完全不需要了。丢一个需求文档进去，ai 直接给你出个产品，还能给你部署好，直接用就行。
|
 |
3
darksword21 PRO 这种 AI 做了个小工具的感想在 v 站看了 2 年了，很疲劳了。
|
 |
4
catch 4 天前
其实我一直想，为啥你们 刷点网页 总想搞个工具呢，不是 找乐子吗
|
 |
5
sillydaddy OP @purringpal
@darksword21 想来点劲爆的？可以考虑成本的边际效应，如何影响软件行业的生态。 比较下面 2 种方式： 1 种是用户将自己的需求表达出来，然后由 AI 直接处理（或者生成对应的软件来处理）。 2 是用户在市面上搜索对应的软件，或者找到对应的供应商然后将软件需求表达出来，由供应商制作。 上述的哪个成本更低？用户会如何选择？如果说 |
 |
6
QS0x01 4 天前
|
 |
7
adgfr32 4 天前 via Android
v 站有 API ，不用浏览器插件的形式吧，这个 cron 运行在电脑后台即可。
|
 |
8
LaurelHarmon 4 天前
二八定律依然有效，20%时间做出 80%效果，剩下 80%时间在跟他交流让他 de 那 20%的 bug ，翻来覆去改不明白，稍微搞点正经项目就知道它短板了
|
 |
9
VinsonGuo 4 天前 via Android
那也仅限于小工具，高强度使用各种 ai 工具之后，反倒是对自己更加自信了
|
 |
10
hewitt29 3 天前 1
5 年过去后，你可能还是一样的想法，在通用型 AI 出世前。。也就这样了，天天，哇，这个模型牛，哇，新出的模型牛。。实际没鸟用，程序员除外
|
 |
11
Skifary 3 天前
@sillydaddy
1 种是用户将自己的需求表达出来，然后由 AI 直接处理（或者生成对应的软件来处理）。 ------------------------------------------------------------------------ 乔布斯有个理论：用户根本不知道自己要什么。用户一般是市面上有什么就用什么，能把需求描述清楚并且逻辑自洽不是普通用户能做到的。 |
 |
12
Tose 3 天前 via Android
我觉得很好啊，都是分享。有了 AI 每人都能够 DIY 自己的小需求，楼主的审美还不错
|
|
13
sillydaddy OP @adgfr32 #7 浏览器插件方便些。第一时间没想到 API 。
@Skifary #11 我仔细想了下，你提到“把需求描述清楚并逻辑自洽”，其实是在 AI 出现之前的时代，前 AI 时代，用户没办法看到效果，没法操作的，所以，它不能像瀑布流开发中的需求分析一样，一下子把所有的需求系统地描述出来。所以，前 AI 时代，会有敏捷开发，讲究快速接触客户获取反馈，快速调整。也有借助原型的概念。 到 AI 时代，一个软件可以从用户的一个非常模糊的需求开始，然后用户看到反馈，才给出进一步调整的指示。这也符合软件迭代的模式。需求是逐渐细化的，需求与开发与测试，是纠缠在一起的。这是一个逐渐将限制精确化的过程，也是补足信息的过程。这个过程如果在前 AI 时代，需要很多次的沟通，成本很高。特别是用户突然改变想法的情况下。 @Tose 感谢夸奖。其实设计方面，我只介入了很少的一点，就是让它尽量紧凑排布，然后让它用 solarized light 主题配色。 |
 |
14
udisyue 3 天前
@sillydaddy 你要知道，瀑布流也是避免不了需求不完整要修改的。而 ai coding 麻烦就麻烦在这个修改上，如果一次完整描述做出来恰好符合需求倒还好说，如果不符合需求，这里要改一点，那边要改一点，你懂开发出来的内容还好说，不然就像二把刀产品经理跟二把刀程序员交流一样，改着改着整个工程就一塌糊涂了
|
|
15
sillydaddy OP @udisyue 不需要懂开发啊。我在主题里发的那两个工具，都是以用户的角度要求修改的，完全没有看过代码。
看着哪里不合适就告诉 AI 自己的想法。比如 v2tracker 里面，关注的帖子要展示最新的回复，如果新回复超过了 3 条就折叠起来。比如标题比较长的，之前是自动换行，让 AI 换成了单行并用省略号折叠。还有很多类似的，用户看到了实际产品的样子，甚至实际用起来，才能给出反馈。 |
 |
16
maplezzz 2 天前
做 demo 和小工具确实很快，但是也仅限小规模应用的阶段。最主要的问题就像 14 楼说的，你作为一个开发和作为一个普通用户对生成出来的代码工程的理解能力是完全不一样的，所有的新增需求和问题完全让 AI 来改，普通用户对于这个理解就是黑盒，切不中出问题的地方，只能通过语言描述来调整，很容易越改越乱。
我昨天看到了一篇文章，lovable 和 Blot.new 在最近几个月的用户量都下降了非常多，对于普通用户来说，完全的氛围编程还是有点太超前了 |
Select Language