#ai #dev 这位作者的效率观和我类似 https://t.me/hacker_news_zh/18607
但他觉得chatUI是最差的媒介，我是觉得只有聊天框适合("Zen Mode")。

如果我要维护代码基，“选取&重录”是好模式，但我习惯于连根拔起，忘掉还有旧代码，整个数据流拆的独立可用、解耦正交。
就像今天的消息里把 ascii art 写15遍的故事，我同样也把递归下降parserc在8种语言里写过>12遍，所以我并不抵制算法或API移植--我知道如何“控制变量”

而在ai建议上，我很少同步等待chat的回复，而是保持方向相同，始终领先1~3条消息， Fire-and-Forget（射后不管）的策略 🤪

领先于LLM的建议是我眼里的轻松工作节奏，等待LLM帮忙续写，意味着我没用fast模型做好知识预备。

我一般会隔离工作流，而不是通过工具模糊顺序和边界
另一方面，我有 bookmarklet/F12 帮忙把chat REPL化，而他可能不 习惯模糊“开发app与开发devtools”的边界，哪怕熟悉 #Haskell
主流觉得 Copilot 是正义，是因为主流开发者的日常工作是“隐式修补”（Patching）；而我讨厌它，是因为我的核心工作是“净室推演”（Reasoning）。

另一方面，不打开心智开销重的IDE，我可以有“超线程workspaces”，正如 https://t.me/dsuse/21861 所言😒
这就是我的护城河（差异化）： 无论小白vibe还是大神Claude，他们都是在臃肿的栈上，被隔离在“反射弧”之外，而我把实现和对 话串放在一个Loop&Notebook里-真正有思维的HITL😒

只有“聊天框”才允许“遗忘”。如果堆砌（Stacking）代码，Copilot 当然才思敏捷，可我是在雕刻（Sculpting）逻辑，我不能看见自己不想看见的功能点。
我希望随时能忽略之前的所有实现，立刻切到另外的语言或 API set ，直接操纵数据流

换句话说，我是计算密集型，虽然prompt很简单，却只有IO包给最先进的AI大哥😃
绝大部分dev是IO密集型，“回忆 API”、“查文档”或者“看懂之前的代码”已经突破舒适区了

如果是我，会直接假定API里会有我猜到的货，只需确定函数颜色（def/async/鉴权/class boilerplates ），然后“原谅比请求好”，就像 可空?.链() 一样简单
代码逻辑链已经在我脑子里跑通过了 (简单是可靠的先验, Top-down mood)。我不需要 Copilot 在旁边关于“能不能”猜测和二开 (那些复杂到不可靠都难读懂的实现) 😒

不是“我去查查框架有什么”，而是“它应该有这个，如果没有，我就写个 Wrapper 让它变成这样”
如果一个库的用法复杂到让你记不住——那不是你的问题，是那个库设计太烂——这其实是DSL（领域特定语言）设计者的思维，再加上我要的可复用可插拔

所以，我的apksigner实现比“最佳实践”小200倍 ——它的存在是先于js代码的
https://github.com/patrickfav/uber-apk-signer/

当我看到"apksigner.jar"这个动词，我想到的其实只是一个被插入的bytes()或.RSA文件
当我看到apk这个名词，我想到的又是它里面每个文件的compile与安装流程、函数节点/XML，以及这些节点的极简调用demo。 从具体到抽象，从骨架到皮毛，就像庖丁解牛，我已经看不见代码基，看见的是它贫瘠到<200行的意图😅

我知道很多IT人以自己学到的术语和API为荣，90%的小白或大佬认为code是骨架，可在今天的我眼里，“用户的既视感”是架构，代码是皮毛。

其实这很“容易”： 我猜不出demo用法的就是烂代码。今天无论是前后端/算法/游戏，我写一个app往往就会自带一段框架，因为现在的框架太拉了。
#ai锐评 https://gemini.google.com/share/72fa6f07f978