@akshay_pachaar:Karpathy 说过一句你以后会后悔忽视的话:“我们必须给 AI 拴上狗链。我仍然是瓶颈。我有……”
摘要
Karpathy 关于给 AI 拴上狗链的观点在模型改进后仍然成立,因为权限和授权与正确性是两回事。文章展示了 AI 生成的应用程序如何缺乏身份和审计,以及 Retool 的平台如何通过提供受控运行时解决这一问题。
查看缓存全文
缓存时间: 2026/06/23 17:52
Karpathy 说过一句你可能会后悔忽视的话:
“我们必须给 AI 拴上链子。我仍然是那个瓶颈。我必须确保这东西不会引入 bug,也不会有安全问题。”
这是他在去年 YC 演讲中说的,当时大家担心的是可靠性。模型会产生幻觉、犯下人类不会犯的错误,所以“链子”意味着你要让自己始终在循环中,在信任输出之前先检查它。
现在模型好多了,但这句话依然成立,原因却是他当时没关注的方向。
即便是一个今天能写出无瑕疵代码的模型,仍然不知道谁有权限运行它。
正确性和授权是两个不同的问题,而随着模型改进,只有正确性会提升。
一个完美的智能体仍然只是把工具交到任何人手里,任何人都能用它做任何事,因为权限从来就不是任务的一部分。
我实际上用 Claude Code 测试过这一点。
我让它构建一个内部小工具,带一个按钮,点击后发放账户积分。第一次就成功了,本地运行时,我一点击,积分就立刻到账。
没有任何东西判断谁有权点击这个按钮。智能体写了正确的逻辑,并显示了成功通知。
它从未检查调用者是否有权限,是否应该暂停等待人工确认,或者是否有任何日志记录。
而且这不是一个更聪明的模型能修复的 bug,因为“链子”根本就不在代码里。
身份、权限和审计存在于运行应用的系统里,而不是智能体生成的内容中。
为了解决这个问题,我把完全相同的代码包托管到了 @retool 上。
那个在我笔记本电脑上静默触发的积分写入,现在停在了审批关口前,通过 SSO 解析到了真实的身份,并落入了审计日志。
我一行代码都没写。
应用在部署的那一刻就继承了整个边界,视频展示了前后对比。
你可以在这里亲自尝试:https://fandf.co/4ofoO72
我还写了详细的分析文章,并与团队合作整理了这些内容。
文章一步步介绍了构建过程、积分写入在我笔记本电脑上无人检查就通过的瞬间,以及同一个应用在 Retool 上运行时发生了什么变化。
它还解释了为什么这是运行时的属性,而不是更好的模型能解决的问题——这也是开发者通常忽略的地方。
文章引用如下。
将随性编码的应用部署到生产环境
来源:https://retool.com/blog/retool-launches-react-ai-app-builder?utm_source=freeman_and_forrest&utm_medium=influencer&utm_campaign=r2_launch&utm_content=akshay_pachaar_x&rcid=701Ql000011zyUSIAY
如今,公司内部构建的软件比历史上任何时候都多——但平均质量却比以往任何时候都低。LLM 让任何人都能在几分钟内在本地生成一个可运行的应用。但 localhost 不是生产环境。这些应用大多没有身份验证、数据访问控制、审计追踪,也没有经过 IT 批准的部署路径。结果是影子 IT 更快的出现,规模扩大了 100 倍。
如何让人们继续使用这些工具进行构建——同时又不会在企业规模上创建不受管控的软件?
我们有答案。今天,我们推出了全新的 Retool:一个平台,你可以在任何地方构建软件:Claude Code、Codex、Replit、Lovable 或 Retool 自己的编辑器——然后通过一个统一的、受管控的运行时进行部署,该运行时会自动强制执行身份验证、权限和数据治理。
- **运行任何内容。**在 Retool 上部署任何 React 应用——无论它最初是 Replit、Lovable 项目还是 Claude Code 会话中的原型。导入时,Retool 会将应用的数据连接映射到你团队已经配置和保护的资源。无需重写。
- **默认受管控。**Retool 上的每个应用都继承集中式身份验证、基于角色的访问控制和数据访问策略——这些都不在应用代码中。每一次与数据的交互都是可审计的。在 Retool Cloud、你的 VPC 或完全本地部署。管控层在任何地方都是相同的。
- **为运营而构建。**大多数 AI 生成的应用在被构建后就被人遗忘了。Retool 处理后续工作:版本控制、发布管理、环境升级、访问变更和监控。一个地方管理所有应用,贯穿其整个生命周期。
在 2020 年代初,低代码和无代码平台押注构建软件更快的秘诀是远离代码。我们也押注过这一点。并且在很长一段时间内,这是正确的。客户构建和交付真实内部工具的速度比从头编写所有代码更快。
但是 AI 改变了构建的经济性。生成代码——由每个月都在改进的模型编写——现在是构建定制软件最快的方式,而且对更广泛的人群来说,比低代码工具更易上手。
当我们创办 Retool 时,我们专有的抽象让构建变得快速。但它们也意味着 LLM 无法流畅地在我们的平台上工作,工程师无法带上他们自己的工具和工作流,在其他地方构建的应用也无法在 Retool 的平台上运行或继承其集中式管控。
当最佳的构建方式改变时,我们也随之改变。
Retool 的新应用构建器是构建内部软件最快、最自然的方式——同时不会放弃团队在应用连接到真实业务数据后所需的控制、可见性和信任。
新的构建器针对提示优先的工作流进行了优化,但它也建立在一个新的架构之上:Retool 中的应用现在前端使用 React,后端使用 TypeScript。
这意味着智能体使用的是现代软件团队已经在使用的相同语言和模式。结果是更高质量的应用生成,更具表现力和可定制性的 UI,真正的后端逻辑,以及你的团队可以检查、审查和改进的代码。没有任何东西被锁定在仅存在于 Retool 内部的专有格式中。
我们还开放了比以往更多的输入方式。拖入截图、PDF、设计文件或电子表格,智能体就会从你的团队已经使用的相同参考内容开始工作。构建者可以拉入每一个已经完成工作的地方,然后交给 Retool 接力,继续推进项目。
你可以针对整个应用进行提示,也可以点击预览中的任意单个部分,将提示范围限定到该组件。当你想要更接近实际构建的内容时,提示界面旁边有两种模式。
代码标签让你检查或直接编辑底层的 React 代码。点击应用预览中的任何元素,你就会被带到代码树中需要修改的确切行,而无需在数百行 AI 生成的代码中寻找。
随着 AI 生成的应用变得越来越普遍,要了解一个应用实际上在如何处理你的数据变得越来越困难——而这正是大多数构建器给你最少可见性的地方。Retool 不仅生成你的前端;我们也生成后端。因此,我们不是让你在一个大型代码库中阅读深埋的查询逻辑,而是把这个层设计得易于理解。
在新的数据标签中,每段与数据源交互的逻辑都以函数的形式创建,你可以打开并理解它。对于带有条件逻辑的更复杂函数,还有一个可视化数据图:一个映射输入和数据源之间关系的图表,展示用户操作和应用逻辑如何转化为对你的数据的操作。
应用进入 Retool 的途径已经大大扩展。
现在,团队可以直接在 Retool 的平台上部署现有的 React 应用——从在 Replit、Lovable 和 v0 中随性编码的原型,到本地仓库中的项目。
导入时,Retool 会将应用的数据连接映射回团队已经定义和保护的资源。这些资源已经携带了正确的数据访问规则。该应用还会获得 Retool 的应用级权限,因此团队可以通过与其他地方相同的基于角色的访问控制来管理谁能查看、使用和管理它。
Retool 不是要求——或期望——每个团队都从头搞定托管、身份验证、权限、密钥、可审计性和数据访问,而是成为一个卓越中心,你可以以编程方式将其应用于你部署的每个应用。
几周前,我们推出了 Retool 的 MCP 服务器,以便管理员可以从 Claude Code、Cursor 或 Codex 中以编程方式管理他们的 Retool 环境——查询资源、邀请用户、审计访问。
现在,我们将应用构建也加入了那套工具。你可以直接从你已经在使用的智能体中构建和编辑 Retool 应用,并且你在那里拥有的项目上下文会随你而来,而不是在另一端重建。并且,因为 Retool 可以托管任何现有的 React 代码,你可以继续在你最喜欢的代码生成工具中构建,并在准备交付时将它们指向 Retool。
如果你打算让人们从任何地方构建(我们认为你应该这样做!),管控就不能是每个应用自己实现的东西。它必须是位于所有应用之下的单一层。
每一次与企业数据的交互都通过 Retool 的管控层。数据访问、权限、批准的资源、环境和部署规则由客户配置,并且无论应用如何构建,都得到一致执行。安全不存在于 AI 生成的层中。它存在于其下方。
将权限和安全放在单个应用内部,在只有少数几个应用和构建者时是可行的。但当软件在跨团队、跨工具、跨技能水平的范围内被创建时,它就会崩溃。当每个团队都有自己的生产路径时,技术领导者就会失去可见性。Retool 创建了一个单一的管控检查点。
这对于软件维护的长尾也很重要。一个软件的大部分生命不是初始构建——而是更新、访问变更、调试、监控、弃用,以及保持应用与业务变化的一致性。Retool 在一个地方处理所有这些事情。
构建软件的人越多,确保每个应用在生产之前都是安全的就变得越关键。有了 Retool,你的团队在构建方式上拥有终极灵活性——但你不必独自解决部署问题。
我们已经与领先的咨询公司、系统集成商和代理商合作,他们提前访问了新的应用构建器,并完成了实践培训,以帮助你自信地交付:Artefact、BitHippie、BoldTech、GxP、Lingaro、Nymbl、Sabai System、SingleWave、Sixth Generation、StackDrop、Stradia Partners、TechRebels 和 Paramint。
今天的发布是关于构建和交付随性编码应用的最佳方式。但这只是下一步的开始。正如我们所预期的那样,AI 辅助开发已经在迅速向前发展。我们看到了能够对数据采取行动、触发工作流、并在没有人类每一步都在循环中的情况下调用系统的智能体。随着 AI 越来越自主,管控问题只会变得更加紧迫。你现在在 Retool 中定义的资源、权限和批准的路径,将成为让更自主的软件安全运行的缰绳。
我们很快会分享更多内容。
相似文章
@akshay_pachaar: https://x.com/akshay_pachaar/status/2067646389291725258
像Claude Code这样的AI编码代理可能很危险,因为它们生成的代码不考虑授权和操作安全性,可能导致未经授权的写入操作,例如删除生产数据库。真正的风险不在于代码质量,而在于缺乏运行时访问控制。
@rewind02: 安德烈·卡帕斯花了2小时解释大多数AI教育者不会告诉你的——关于当AI接管知识工作时人类会发生什么…
安德烈·卡帕斯讨论了当前AI模型的局限性,强调人类技能培养比外包思考更重要,以及他受星际迷航学院启发的新教育平台愿景。
@akshay_pachaar: https://x.com/akshay_pachaar/status/2069118430582866051
本文解释了AI代理中的循环工程概念,强调核心循环很简单,但关键工作在于模型周围的“束具”,包括知道何时停止以及防止上下文腐败。
@addyosmani: https://x.com/addyosmani/status/2056078124346228860
Addy Osmani 提醒:过度依赖 AI 编写代码可能会阻碍学习,并削弱对软件开发的思维模型。
@rohit4verse:AI 并没有让代码变得廉价,而是让劣质代码变得致命。Matt Pocock:“软件基础比以往任何时候都更重要”AI 在……
探讨了 AI 如何放大代码质量的影响,强调软件基础比以往任何时候都更重要,并推荐了构建可靠 AI agent 的五种设计模式。