AI 服务于自己,好用就行,别搞技术歧视

一、小客户要的是解决，不是完美

服务大企业时，稳定性、性能、架构是硬指标。系统宕机一分钟可能损失百万，并发量上来必须水平扩展，数据安全必须符合合规要求。这些场景下，技术架构确实重要。

但当你服务的是小企业、个体户、或者你自己的小需求时，游戏规则完全不同。一家小店用你的工具管理库存，它一天就几百条数据，偶尔卡一下不影响生意。一个自由职业者用你的 AI 助手整理文档，它偶尔出个 bug，刷新一下就好。他们不会写工单投诉你，不会要求 SLA 99.99%。

小客户要的是：今天有个想法，明天就能用上。他们愿意容忍不完美，只要核心功能跑得通。你花两周优化架构让它支持十万并发，他们永远用不到那个量级。你花的时间，他们感知不到。

二、服务于自己，是最高效的需求来源

这位开发者说"AI 时代服务于自己"。这六个字藏着独立开发最朴素的真理：你自己遇到的麻烦，别人大概率也遇到。你自己做的工具，你最清楚哪里不好用。你自己用的频率最高，迭代动力最足。

大厂做产品要调研、要画原型、要开评审会。独立开发者不需要。你自己就是用户。你发现一个重复劳动烦死了，花一晚上让 AI 写个脚本自动化。你发现信息太散乱，花两天搭个聚合页面。这些东西一开始只是给自己用，用着用着发现同事也想用，朋友也想用，干脆开放出来收个费。

服务于自己的好处是：你不需要猜用户要什么。你知道。你不需要验证需求是否存在。它已经在折磨你了。你不需要强迫自己迭代。你自己用得不爽就会改。

三、技术歧视：把大厂标准强加给小场景

"不需要搞什么技术歧视"——这句话值得展开。技术圈有一种隐性的等级观念：用微服务的比用单体的高级，写 Go 的比写 Python 的高级，搞分布式系统的看不起做脚本的。这种歧视的本质，是把特定场景下的技术要求泛化为普遍标准。

微服务架构解决的是大团队、大流量、复杂业务的问题。当你一个人维护一个服务三五家企业的小工具时，微服务只会给你增加部署和调试的复杂度。你不需要消息队列，不需要服务发现，不需要分布式事务。一个单体应用、一个数据库、一个定时备份，够用了。

算法也是。小数据量下，O(n²) 和 O(n log n) 的差距是毫秒级的，用户感知不到。你花时间优化算法，不如花时间加一个用户真正需要的功能。

四、UX 偏好：极简才是永恒的

这位开发者还提了一个细节："建议你换个 UX，这套我个人不喜欢这种暗色（还是喜欢极简）。"

暗色主题在开发者圈子里流行，因为它看起来酷，长时间看代码不刺眼。但它不是唯一选择，更不是最好的选择。很多用户觉得暗色压抑、看久了累、打印出来一片黑。极简的亮色设计，留白多、信息密度适中、层级清晰，反而更适合工具类应用。

UX 没有标准答案。有人喜欢暗色，有人喜欢极简，有人喜欢拟物。关键是你的工具服务于谁。如果你做给自己用，那就按自己的偏好来。如果你做给客户用，观察他们怎么用、在哪里卡住、什么界面让他们舒服。别用你作为开发者的审美去绑架用户的体验。

极简主义的核心不是"少"，是"不多余"。每个元素都有存在的理由，没有装饰性噪音。这种理念不仅适用于视觉设计，也适用于代码架构、功能规划、甚至商业模式。不多余的东西，才能长久。

五、怎么做一个让自己舒服的小工具

如果你也想走这条路，几个实操建议：

第一，从自己的痛点出发。别想"什么能赚钱"，想"什么让我烦"。烦的事往往别人也烦。

第二，用 AI 加速实现，但别让 AI 决定边界。你定功能范围，AI 写代码。功能做到刚好够用就停，别无限扩展。

第三，接受不完美。第一个版本丑一点、慢一点、少几个功能，没关系。先让它跑起来，用起来，再慢慢改。

第四，小客户的需求简单直接。他们不会要求你做灰度发布、蓝绿部署、全链路压测。这些事等你真的需要了再加。不要提前透支精力。

第五，UX 跟着感觉走。你喜欢极简就做极简，别被流行趋势带偏。工具是你自己的延伸，它应该像你。