以前在大厂写业务，最怕"逻辑改一行、环境拉一整套"的活儿。后来觉得Python最对我胃口，倒不是它多优雅，而是它把"我想干件事"变成"已经跑起来了"的链路最短。
比如归置一堆散落日志，或者批量抓某个接口返回回来比一比，标准库里os、re、urllib都现成，十几行就能跑通，虚拟环境都不用建。它跟fzf那套命令行也处得来，管道一接，几分钟把一周杂事自动化掉，手确实变懒了。
调试友好，报错能看懂，踩过的坑大概率搜得到现成解法。前阵子想给几百张照片按EXIF批量重命名，三分钟写完脚本就完事，比翻图形界面工具省太多。从某种角度看，语言选顺手的而不是理论上最优的，反而更划算。
前阵子我也被一堆命名乱掉的音频文件烦到，想按文件里的 tag 批量重命名，os 加 re 真就十几行跑完，关掉脚本那一刻挺爽。你这帖我基本都点头。
唯一想杠一下的点是抓接口。urllib 我每次都得查半天文档，redirect 和 JSON 解析挺啰嗦，临时活儿我宁愿 pip 个 requests 三行解决。当然你说"标准库现成、零配置"完全认同，看场景取舍。
补一句：脚本要是打算留着长期用或给别人跑，还是塞个 venv（虚拟环境，隔离依赖那种），省得哪天环境一变跪给你看。一次性的活儿随意。
顺着你说的"顺手比最优划算"补一句：判断标准我一般看这活儿会不会再来第二次。一次性的，一行命令糊弄过去；要重复用的，值得多花十分钟写得体面点。
照片按 EXIF 重命名那事，exiftool 一行就能解决，纯命令行反而更快。不过 Python 的爽点本来也不在速度，是你想改逻辑时随手就能改。
fzf 接管道确实是灵魂。唯一提醒：那种"十几行跑通"的脚本一旦变成天天依赖的东西，最好顺手丢个 git 仓库加 requirements，不然哪天换台机器又得折腾一遍。C’est la vie.
我那点自动化全是半夜手滑下单 比跑脚本还快 顺手果然是第一生产力哈哈
前阵子我整理外拍原图也用了同款思路，按拍摄时间批量重命名归档。有个点想补一嘴：Python 标准库其实不读 EXIF，os、re、urllib 那套搞不定快门时间这类元数据，我那次是 pip 装了 Pillow 才从 Image.getexif() 里取出来。所以你说的"十几行跑通、连虚拟环境都不用建"在抓接口、归日志这类纯文本场景基本成立，可一旦涉及二进制格式解析，第三方依赖还是绕不开。
说回你核心意思，我挺买账的，把"想干"到"跑起来"的链路压到最短，比追求理论最优划算得多。只是顺手归顺手，心里得有本账：哪些脚本其实偷偷借了外部库，哪天换台没装过包的机器跑同段代码，才发现缺东西就尴尬了。
你这"手确实变懒了"一句我最共鸣~我平时拍照多，RAW和jpg糊一锅，文件名乱得像被猫踩过键盘，后来也是写个小脚本按拍摄时间归位，比一张张翻看图软件省事太多。
emmm
"顺手而不是理论上最优"这点完全赞成，折腾工具的时间比活本身还长就是本末倒置。我现在铁律：能三行脚本解决的绝不装全家桶。你跟fzf管道那套听着就爽，回头安利给chill_q，他估计还停留在手动建文件夹的年代。
我手机里也攒了快一千张照片，拍完就扔那从没整理过。看你三分钟按EXIF重命名就完事，心动了哈哈
不过我连虚拟环境是啥都搞不太懂，这活儿对我门槛还是高。你那个fzf管道接起来几分钟干完一周杂事，听着像魔法。我平时最自动化的事儿就是设个闹钟提醒自己吃饭，丢人
哪天我也去摸几行Python，先把相册收拾了。Друг不会的来问你啊
EXIF 重命名那个例子挑一下：标准库里其实没有能舒服读 EXIF 的东西。几百张照片按拍摄时间改名，真要十几行跑通，多半得靠 Pillow 或 piexif，要么调 exiftool，这几个都不是标准库。简单说所以"零依赖、不建虚拟环境"这份轻松，更准确说是装一次全局就忘了它，严格讲还是有依赖。你"链路最短"的判断我认，但"标准库现成"这个画面比实际糊一点。
补两个角度：
简单说依赖有有效期。不建虚拟环境，对你自己机器上的小脚本完全 OK。隐患在以后：哪天 python 升了大版本，或者全局 pip 混进别的东西，脚本就悄咪咪挂。个人自动化无所谓，可一旦想交给别人跑、或者一年后再打开，没有 requirements.txt 加 venv 这点功夫是要还的。不是说你现在错，是这条快是有有效期的。
urllib 那段我有点不同感受。os/re 确实现成，但 urllib 是标准库里最别扭的那块。想最快抓个接口回来比一比，大多数人实际伸手拿的是 requests，又是个第三方库。所以 Python 真正顺手的地方，往往已经踩到了标准库外头。
不过你最后那句我想接一刀：顺手大于最优，在 20 行脚本里是铁律，但别顺手顺到 2000 行系统去，那是另一回事。
我私底下也爱拿 python 收拾自己的小破事，比如把一堆乱账单 PDF 抽成表格。每次偷懒不写 venv，后来重跑都得哄它两句。现在习惯哪怕一次性脚本也顺手丢个 venv 和注释，三个月后省的是自己。
你那套 fzf 管道接法的思路挺好，有空把你日志归置那段脚本贴一下？想看看怎么跟 fzf 串的。
你写照片按EXIF批量重命名那段，叫我想起前些年翻腾老相册的光景。那时捧着图形界面点来点去，反倒越理越乱，像在湿泥地里拔脚。后来有人递了个脚本的法子，才恍然，绊住人的从来不是活儿有多难，是手里少一件趁手的家伙。我觉得吧
挑一门语言，挑一把椅子，挑一段关系，大抵都是这般道理。理论上最妥帖的那把，坐上去未必暖。能将自己从琐碎里轻轻拎出来喘口气，便已是好物了。
你这句"手变懒了"我直接截图存了。前阵子我也干过类似的事——为了给一摊子杂乱的现场录音按年份归档，写了个十几行小脚本，跑完之后对着终端傻乐了半天，那种"不用手动了"的爽感跟吃到对胃口的菜差不多 (￣▽￣)
不过 ehrlich gesagt，你最后那句"选顺手的而不是理论上最优的"我有点想抬杠。顺手当然划算，但它也容易让人滑进一个坑：为了省三分钟，花一下午把一堆一次性脚本缠成毛线团，最后连自己都不敢碰。我有个朋友就信了"几分钟自动化掉一周杂事"，结果三个月后他那个脚本文件夹比待办清单还吓人，每次想找点东西都得先给自己做心理建设。
当然归置日志、比接口这种活儿，Python 确实把"我想"变成"跑起来了"压到最短，这点没得黑。你那套 fzf 管道我得偷师一下，听起来比我手敲命令潇洒太多，下次整理照片也试试这路子。
你那个"虚拟环境都不用建"的判断，我觉得得看脚本的寿命。十来行、跑完就扔的活儿，确实没必要折腾；可一旦这脚本被你或者同事下个月又翻出来用，环境里要是已经装了别的项目的包，版本打架是迟早的事。我见过有人图省事全局装包，半年后旧脚本跑不起来，排查半天发现是某个依赖被新版悄悄覆盖了。
再说 urllib。标准库里确实有，但接口用着实在别扭，做个带认证的请求或表单提交要写好几行样板代码。你说"现成"没错，可真要舒服地"批量抓接口"，绝大多数人还是会顺手 pip 一个 requests。这其实跟你"顺手优先"的主张不矛盾——只是顺手往往意味着引入一两个第三方库，那虚拟环境这一步就省不掉了。
你那个核心意思我是认同的：原型阶段，把想法跑通比架构优雅重要得多。只是有个小提醒，不少"几分钟自动化掉一周杂事"的脚本，最后都悄悄长成了天天在跑的小工具，到那时候依赖管理和报错监控就不是可有可无的了。
照片按 EXIF 重命名那个，几百张里要是有缺 EXIF 的、或者手机和相机时区不一致的，你的脚本是直接跳过还是会崩？这种边界情况才是真耗时间的地方，比写主逻辑费劲多了。
补充一点：你那个EXIF批量重命名的例子，读EXIF其实不在标准库里，得靠Pillow或exifread这类第三方包。所以"标准库足矣"碰到图片元数据就有些勉强了。当然整体意思我认同，顺手确实比理论最优划算。