Theo 提出的六个开发工具与平台创意

我花了很多时间思考如何构建软件，但做什么依然重要。选错项目可能让人觉得浪费时间，所以我通常建议从自己真正遇到的问题开始。解决一个问题会发现更多问题，沿着这条线探索，可能做出有用的东西。

如今创意似乎更重要了，我知道很多开发者不确定该做什么。我一直列着一份希望有人做出来的东西。智能体让其中任何一个项目对我来说都更可行，但我仍没有时间全部完成，所以我把清单分享出来。

第一个想法是更好的 npm，包括 npx。npm 是了不起的软件，但它的规模也让它成为安全攻击的目标，而新的防护措施可能让正常发布更困难。对我来说，发布包越来越成为项目中最难的环节之一。

版本号发布错误可能很难撤回；npm 担心删除依赖会让将来的构建失败。改变这种行为确实会带来生态风险，但我希望有一个有限的撤回窗口，例如安装量少于 100 次或上线不到 5 小时的版本可以撤回。

我还希望能付费审查每次发布的差异，并看到更多直观的元数据：代码是否可读或经过混淆、是否开源、最近版本由谁发布。这些信息应该同时显示在包注册表和命令行安装过程中。

一个名称相似的包可能执行可疑的文件系统或网络操作，而安装过程并不会明显提示风险。不同包的需求和风险不同，用户应该能看到这些区别。我也希望有更好的流程处理包名抢注。

npx 尤其值得重新设计，因为它可以分发小型可执行工具，包括智能体需要的工具。现在的安装提示可能只给我一个版本号和是否继续的选择，却没有足够信息让我判断代码。我希望看到作者、大小、权限和风险提示。

这对智能体也很重要：技能文件中的命令可能运行一个后来遭到接管的包。智能体可以展示警告，让用户决定怎么办。我设想独立自动审查给出粗略的风险提示，而不是保证包绝对安全。

私有注册表可以让人们共享自己的小工具，而不必把一切公开发布，并在适当情况下优先使用私有包。替代方案需要发布集成、托管、CDN、验证、注册表和命令行工具。这工作量很大，但我认为 AI 已经改变了成本，使它值得尝试。

Socket 是审查版本发布方面的一个例子；无论是在 npm 之上构建工具，还是开发替代品，都有空间。第二个想法更大胆：重新思考版本控制。Git 成为标准有充分理由，但它的假设无法满足今天的所有需求。

以环境变量文件为例。把密钥放进仓库会让有仓库访问权的人看到它们，也可能让它们留在历史记录里。独立的密钥管理服务有帮助，但我想问，为什么版本控制本身不能支持私有文件、私有分支或拉取请求，以及更细粒度的权限？

安全修复是另一个例子。我希望维护者能够先准备修复，并将其交给受影响的各方，然后再公开代码，缩短攻击者能分析补丁而用户尚未更新的窗口。这与开放性之间确实存在权衡；我认为这里应该更加重视安全。

我此前也发帖问过：能否让尚未完成的拉取请求保持私有，或者让单体仓库包含私有子包？我曾经因为只能公开部分代码而把项目拆成多个仓库。我希望工具能让我决定共享什么，而不是迫使项目结构服从这一限制。

提交和分支也是值得重新思考的模型。我喜欢 Jujutsu 的使用体验，尽管它没有解决我最关心的问题；它对快照和标签的处理让我重新思考我们花多少时间管理历史。Git worktree 也让我沮丧，比如一个工作树会阻止另一个检出同一分支。

我还在想，版本控制是否一定要依赖真实的操作系统和文件系统。像 just-bash 这样的工具可以用 JavaScript 模拟 shell，让智能体环境在内存中运行。在那里复制环境，或许能避免搬动大量文件的一部分开销。

NullVoxPopuli 分享的一项磁盘基准测试帮助解释了我的挫折感。它克隆项目并安装缓存的依赖，测量文件创建而非网络下载。在我看到的结果里，一台 Ubuntu 系统用了 6.8 秒，M4 Mac 用了 31 秒；其他 Mac 的结果慢得多。这是特定工作负载，并不能代表对文件系统的全面比较。

有人说问题出在 fsync，但我并不确定原因。这种体验让我希望有不那么依赖文件系统的工作流。内存中的表示方式可能避开某些平台特有的行为，尽管真实系统仍需要处理持久化等实际问题。

下一个想法是面向开发者的 Dropbox。我在多台机器上工作，经常遇到 worktree 基础版本过期、缺少环境变量和项目目录结构不一致的问题。Dropbox 让我的其他工作在各台机器上保持一致的文件夹结构；我希望代码也能有类似的便利。

想象一下，启动一台机器后，整个代码目录都以相同的结构出现。环境配置也可以同步，不过像 node_modules 这种因操作系统而异的依赖需要特殊处理。对我来说，用另一个仓库和子模块管理一组仓库并不是令人满意的替代方案。

我曾开始一个叫 FS2 的项目，但理想方案还要更进一步：在各处保留目录结构，并在人或云端智能体访问时按需拉取内容。它应该兼容现有工具、自动加入新项目，并有类似 .gitignore 的同步排除机制。

一位观众说自己一直梦想做这个，却缺少相关技能。我建议先验证这个假设：如果有耐心和资源解决困难部分，今天的模型和智能体也许能帮你走得比预想更远。我希望有几个人尝试。

接下来是新的移动平台。我曾是 Android 爱好者，现在依赖 iPhone，但移动应用的分发和开发体验让我沮丧。我不喜欢 iOS 应用商店的规则和支付限制，也认为 Android 的分发与审核存在不透明的问题。

我使用 CyanogenMod 的经历说明了这个问题。它是社区构建的 Android 变体，让人们移除不需要的软件并定制设备。当时对我来说，修改 Android 本身似乎比开发一个应用还容易——对于一个需要开发者的平台，这很荒谬。

我还记得 Paranoid Android 和 Paul Henschel；他在 React 生态中的作品包括 Zustand 和 React Three Fiber。我猜测，移动开发的困难促使一些有才华的开发者转向 Web。这是我对他经历的理解，并非他与我深入确认过的事实。

BlackBerry 10 提供了 Android 运行时，说明不同的操作系统也可以支持现有应用生态。它也有缺点，包括性能问题，以及用户选择它而非 Android 的理由不足。我从中得到的启发是，新平台未必需要从完全没有应用开始。

我希望有一个实验性的移动操作系统：兼容 Android 应用，同时鼓励定制、分叉和开发。想象一下，看完演示后扫描二维码就能试用应用，或者修改现有应用。我希望移动平台更容易供人实验，更接近 Web 或桌面平台。

我担心现有移动平台的利益结构会让这个未来难以实现，而利用可解锁引导加载程序的设备进行构建的机会可能越来越少。这是我的判断，而非能够证明的预测。我希望有人抓住机会，探索更开放的平台可以是什么样。

接下来是更好的 Slack。跨公司共享频道让 Slack 很难替代，但我对它的回复和线程模型感到沮丧：活跃的旧线程可能很难找到，要回复线程中的某一条消息往往还得手动引用。

智能体进一步暴露了这些限制。我希望沟通工具能帮助人们确定优先级、重新展示活跃的对话，并让智能体探索讨论中的一个分支后回来报告。嵌套回复以及人和智能体共享的上下文会让工作流更连贯。

灵感来自 Facebook Workplace 的帖子和评论模型：帖子下可以有嵌套回复，新动态也能让旧帖子重新置顶。在我看来，帖子是介于频道和线程之间很有用的基本单元。录制视频时 Workplace 已经关闭，因此我希望出现一个易于采用、方便智能体使用的开放替代品。

想象一下，智能体回复一项工作后，该帖子就重新置顶，而不是让输出埋在难以管理的聊天线程中。我甚至开始做过类似的东西，但没有时间深入推进。我希望有一个开源标准，能逐步与 Slack 竞争。

最后，我们需要更多基准测试，包括研究实验室之外的人制作的奇特测试。我的 SkateBench 要求模型根据描述说出滑板动作的名称；研究人员觉得结果有趣，因为这项任务混合了专业语言、语法和空间推理。

当智能体在你的工作中失败时，把任务保存为可复现的形式，再次测试。基准测试可以覆盖 Git 工作流、冷门编程语言、图像或其他真实任务。测量能展示弱点，并激励实验室改进；但分数本身不能证明真实环境中的可靠性。

比起自己动手，我更希望这些想法成为现实。我可能不会尝试每个项目，但如果有人使用和讨论，我会感兴趣。更广泛地说，如果你有让自己兴奋的想法，也可以做自己的项目：尝试用更大的方案解决更难的问题，动手实验，挑战过去对可行性的假设。