返回首页
最新
大家好，
关于生产力的传统观点认为，离目标越近，我们的动力就越强。逻辑上，距离终点的缩短应该是我们最强大的动力来源。
然而，我最近分析了一个深具反直觉的模式——我开始称之为“90%引力”。
这个模式是这样的：
在项目的最后阶段，约在80%到95%完成之间，存在一个统计上显著的“危险区”。在这个区域内，拖延、自我破坏和几乎放弃的比例异常上升。就像有一种明显的、无形的力量在积极地将我们从即将获得的成功中推开。这不仅仅是疲惫；即使是个人最渴望、充满激情的项目，这种模式依然存在。事实上，目标越有意义，这种负引力的吸引力似乎越强。
如果这个模式成立，那么它暗示我们的最大对手不是启动时的惯性，而是一种奇怪的“成功厌恶”，在胜利即将到来时对我们发起突袭。
我想在这里向大家开放讨论：
1. 你个人是否经历过这种“90%引力”？一个你充满热情的项目，在快完成时却 inexplicably 停滞不前？
2. 从理论上讲，你认为这里面涉及了哪些心理因素？是对成功本身的恐惧？还是对实现长期目标后所带来的空虚的恐惧？或者是其他完全不同的原因？
我很想听听你们的看法。
附言：我们已经将对这一现象的初步思考和更详细的数据整理成了一份简短的研究笔记，你可以在这里阅读：https://peach-jannelle-97.tiiny.site
请注意，Chrome 仍然需要 HTML 中的 <style> 标签。要获得真正的无 HTML 体验，请在 Firefox 中尝试该页面 :）。
大家好，
关于生产力的传统观点认为，离目标越近，我们的动力就越强。逻辑上，接近终点的距离应该是我们最强大的动力来源。
然而，我最近分析了一个深具反直觉的模式——我开始称之为“90%引力”。
这个模式是这样的：
在项目的最后阶段，约在完成80%到95%之间，存在一个统计上显著的“危险区”。在这个区域，拖延、自我破坏和几乎放弃的比例异常上升。就好像有一种可感知的、无形的力量在积极地将我们推离即将获得的成功。这不仅仅是疲惫；即使是个人最渴望、充满激情的项目，这一模式依然存在。事实上，目标越有意义，这种负引力的吸引力似乎就越强。
如果这个模式是正确的，那么它暗示着我们最大的对手并不是启动时的惰性，而是一种奇怪的“成功厌恶”，它在胜利即将到来时对我们发起突袭。
我想在这里与大家分享这个话题：
1. 你是否亲身经历过这种“90%引力”？一个你充满热情的项目，结果在快完成时却 inexplicably 停滞不前？
2. 理论上，你认为这里面涉及哪些心理力量？是对成功本身的恐惧吗？还是对实现长期目标后所带来的空虚感的恐惧？或者是完全其他的原因？
我很想听听你们的看法。
在过去几个月里，我和一位学生一起探索了氛围编码对网页开发的影响。在这个过程中，我们最终构建了Daf·thunk，一个可视化工作流编辑器。它利用了Cloudflare出色的基础设施（Workers、D1、KV、Workflows、AI等），创建了意想不到的强大工作流，这些工作流可以通过手动触发、HTTP请求、电子邮件或定时任务来启动。
在开发过程中，我们主要使用了Cursor的代理和标签模式，以及Claude Sonnet 3.5、3.7、4和Gemini 2.5 Pro。偶尔在处理或审查更复杂的更改时，我们会切换到MAX模式。我们努力定期优化Cursor规则，并开始将特定规则应用于代码库的不同部分（后端、前端、数据库等）。我们还对文档进行了索引，并在提示中广泛使用。对于大型重构，我们经常参考之前的提交，以便在代码的其他地方重新应用模式。
总体而言，我们认为在使用大型语言模型（LLMs）编码时，针对小的、渐进的、易于审查的更改进行提示效果很好，结果也非常令人印象深刻。在这方面，Andrej Karpathy的演讲《软件正在再次改变》引起了我们的深刻共鸣。John Ousterhout的深模块概念也成为了一个有用的思维模型。我们的Cursor规则要求简单的API，以隐藏丰富的内部逻辑，并避免与实现细节相对应的宽接口。
除了频繁的提交外，我们并没有详细记录我们的过程，因为我们主要是在探索和建立对有效与无效的直觉。由于我们选择比以往更信任LLM，我们将所有内容以开源许可证发布，并且不提供任何担保。随着模型的改进，我们对单元测试的依赖减少，这可能会很快给我们带来麻烦……欢迎贡献 ;)
GitHub 仓库：
<a href="https://github.com/dafthunk-com/dafthunk">https://github.com/dafthunk-com/dafthunk</a>
Product Hunt 页面：
<a href="https://www.producthunt.com/products/dafthunk?launch=dafthunk" rel="nofollow">https://www.producthunt.com/products/dafthunk?launch=dafthun...</a>
人类的思维方式结合了快速思考和慢速思考，而人工智能默认并不具备这一点。这为异步代理提供了巨大的机会。
当代理处理实时任务时，比如电话通话，它需要快速响应，同时保持准确性。这是一个经典场景，要求同时具备快速和慢速思考的能力。
我的方法是让一个“战略家”在“执行者”之后。执行者负责“快速思考”——即时的、当下的反应，而战略家则负责“慢速思考”——更深层次的分析和规划。
这就是我正在构建的人工智能代理的核心设计。你觉得这样理解可以吗？
大家好——我开发了这个工具，想和大家分享，因为它是免费的，可能对你们中的一些人有所帮助：<p><a href="https://mem-x.vercel.app" rel="nofollow">https://mem-x.vercel.app</a><p>GitHub: <a href="https://github.com/MehulG/memX">https://github.com/MehulG/memX</a><p>memX 是一个为大型语言模型（LLM）代理提供的共享内存层——有点像 Redis，但具备实时同步、发布/订阅、模式验证和访问控制等功能。<p>代理不再需要传递消息或遵循固定的流程，而是直接读取和写入共享内存键。这就像一个协作白板，代理们可以共同演变上下文。<p>主要特点：<p>实时发布/订阅<p>按键的 JSON 模式验证<p>基于 API 密钥的访问控制列表（ACL）<p>Python SDK<p>我很想听听大家是如何在自主代理之间管理共享状态或上下文的。