这集讲什么
Cloudflare CTO Dane Knecht 认为，AI 正在同时加速漏洞发现、软件生产和智能体访问网络；应对之道不是退出互联网，而是把安全嵌入开发流程，并为智能体时代重建内容分发与付费机制。
1-3要点
- AI 改变的是攻防速度与参与门槛：更多人能发现漏洞，防守组织也必须提高发现、分派和修复速度。
- 减少攻击面优先于无止境增加扫描：复杂度本身会制造长期维护负担；AI 生成代码仍需人类工程判断。
- 安全应成为开发流程的一部分：组织规范、独立审查和修补能力要跟上代码产出。
0:00 / --:--
No Priors · 10 月 23 日
Cloudflare CTO Dane Knecht 认为，AI 同时加速了漏洞发现与代码生产，应对之道是把安全嵌入开发流程、减少攻击面，并为智能体时代重建内容分发与付费机制。
Cloudflare CTO Dane Knecht 认为，AI 正在同时加速漏洞发现、软件生产和智能体访问网络；应对之道不是退出互联网，而是把安全嵌入开发流程，并为智能体时代重建内容分发与付费机制。
这集还没有学习卡。生成后会保存在这一集，下次直接打开。
a16z Show· 2026-10-16AI 能写代码。它能运行系统吗？｜Grepr CEO Jad NaousAI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous同主题：AI 编程
No Priors· 2026-10-29挑战 ServiceNow：面向我们普通人的编程智能体，与 Serval 联合创始人兼 CEO Jake Stauch 对谈Taking on ServiceNow: Coding Agents the Rest of Us with Serval Co-Founder and CEO Jake Stauch同主题：AI 编程
Latent Space· 2026-10-28为什么 AI 智能体喜欢 SupabaseCloudflare 同时处在网站防护、网络流量和开发者平台的交汇处。智能体开始替人浏览网页、调用工具、生成代码后，这些领域的问题也连在了一起：漏洞能以多快的速度被发现？新代码能否安全上线？当机器读取内容却不观看广告时，网站靠什么维持运营？
本集围绕 Knecht 对这些变化的判断展开。他既谈互联网层面的攻防，也谈 Cloudflare 内部如何让员工安全地使用 AI、重组工作流，以及如何决定模型开支。
这场对话的核心不是“AI 会不会带来安全危机”，而是互联网能否以足够快的速度改造自己的生产与防护方式。Knecht 观察到，过去需要集中力量处理的严重漏洞，如今出现得更频繁；智能体又把发现漏洞的能力带给了更多人。他预计企业会在一段过渡期内显著增加安全投入，但不同意因此就该把关键系统一律与互联网隔离。已有的零信任实践、跨公司协作，以及 AI 辅助发现和修复漏洞，都是防守方可用的手段。
他的方案从代码本身开始：先减少复杂度和攻击面，再让安全审查贯穿开发流程，而不是指望某个模型自动写出安全软件。这一思路也延伸到 Cloudflare 内部：公司把规范整理成智能体可使用的文档，搭建受治理的员工 AI 平台，并尝试重做跨部门工作流。与此同时，智能体正大量读取为人设计的网页，令抓取成本、内容发现和创作者收入成为基础设施问题。Knecht 提出的内容微支付与新发现机制提供了方向，却仍须证明其交易成本、定价和分配方式可行。整集因此呈现出一种有条件的乐观：技术可以帮助解决它放大的问题，但组织必须先改变安全流程、激励机制和对复杂度的容忍度。
💬 他们说了什么：Knecht 说，Cloudflare「建设更好的互联网」这一使命没有变，但过去一年的关注点从帮助人们部署 AI 和智能体，转向防止数据外泄、阻止入侵。在他观察中，过去 3—6 个月漏洞报告明显增加；类似 Log4j、Shellshock 那种需要集中应对的事件，以前大约一年碰到一次，如今他认为近乎每周都会遇到严重问题。他预计未来 18 个月安全会占据团队大量时间，并援引当天主题演讲中关于工程时间可能有超过 50%投向安全的说法。
💡 为什么重要：当漏洞发现加速，安全就不只是上线前的一道检查，而可能成为决定研发资源如何分配的持续工作。Knecht 同时指出，模型能力之外，人们使用模型的工作方法也在改进。
⚡ 争议点：「每周一次」和「超过 50%」分别是嘉宾的观察与其转述的预测，不应读作已公开验证的行业统计。节目提到的密码学种子案例也缺少足够细节，不能据此推断整个 TLS 信任体系已经失效。
💬 谈到攻击者，Knecht 认为近期某些重大发现并非来自国家级组织：高中生也可能让智能体寻找漏洞，再通过漏洞赏金获益。主持人追问，关键基础设施是否应当全面物理隔离。他回答说，自己没有那么悲观；在危急时刻，原本竞争的公司会合作，而过去 5—10 年从“城堡与护城河”式防御转向零信任，也使组织能按设备和数据流细化防护。
💡 AI 降低漏洞研究门槛，既扩大了善意研究者群体，也扩大了潜在攻击者群体。零信任提供的不是“互联网绝对可信”的保证，而是在不完全信任网络的前提下控制访问。
⚡ 「攻击者中有高中生」是嘉宾基于其所见提出的例子，不能概括攻击者总体构成。零信任也不能替代关键系统所需的隔离、备份或应急演练。
💬 主持人提到另一种预测：到 2027 年，组织用于安全的 token 开支可能与工程用途相当。Knecht 的判断是，迫近的风险会推动企业把未来 18 个月的安全投入提前，既加强主动寻找漏洞的红队，也加强防守准备；但他不认为这种资源占比会永久维持。
💡 如果这是一段集中补课期，管理者需要区分临时增加的漏洞清理能力和必须长期保留的安全开发机制。前者应对积压，后者决定新漏洞是否继续累积。
⚡ 投入增加未必自动提高安全性。若漏洞发现、定级、修补与验证能力不匹配，更多扫描结果可能先形成更长的待处理队列。
💬 Knecht 形容当前工作是在为约 70 年积累的软件“补课”。但只修旧漏洞不够：软件开发生命周期和智能体开发生命周期都应改变，把安全检查、对抗测试纳入每一步。
💡 AI 一面提高漏洞发现速度，一面提高代码产出速度。若新代码仍按旧方式生产，组织可能一边修复旧系统，一边生成新的安全债务。
⚡ 「70 年」是对软件遗留问题跨度的概括，不是一次可量化的漏洞盘点。将安全“嵌入每一步”也需要明确哪些检查可自动化、哪些上线风险必须由人承担决策责任。
💬 面对形式化验证、智能体审查等众多方法，Knecht 首先建议简化软件：减少代码、依赖和可能存在漏洞的入口。他承认，更安全的语言、运行时与验证方法都有价值；但现阶段 AI 常生成冗长、复杂的实现，因此仍需要工程师判断设计是否足够简洁。
💡 安全不只取决于“找出多少漏洞”，也取决于系统留下多少需要理解和维护的部件。代码生成越便宜，拒绝不必要复杂度的能力越关键。
⚡ 更少代码不必然等于更安全代码；删除显式检查、改用不透明外部依赖，也可能只是把风险藏起来。简化需要结合权限边界、依赖质量和可测试性评估。
💬 Knecht 说，降低复杂度要在多个层面推进：产品工程师接受训练，安全团队提供第二双眼睛，流程提供制衡。Cloudflare 也把团队积累的 RFC 与建设原则整理为内部规范，再提炼成供智能体在审查过程中使用的规则；写代码、性能检查和安全检查不应全由同一个角色自说自话。
💡 组织过去依靠入职培训、同事协作传承的隐性知识，必须变得足够清晰，才能进入智能体工作流。规范文档因此不只是知识库，也是自动化审查的输入。
⚡ 让智能体“知道规则”不等于它总能正确执行规则。组织仍需检验规则是否及时更新、例外如何审批，以及对抗性审查是否真正独立。
💬 Knecht 将当下称作混乱的过渡期：智能体正在解析为人类设计的网页，却可以在人阅读一页的时间里访问约 1000 个页面。传统广告收入与这种访问方式并不匹配。他设想网站以适合机器的方式交付内容，让智能体决定是否按内容站熟悉的 CPM 等价格逻辑付费；这又要求能支撑大量小额交易的支付设施。
💡 问题不只是爬虫是否被允许进入网站。抓取的基础设施成本由谁承担、内容价值如何传递给创作者，都会影响开放网络能否继续提供丰富内容。
⚡ 「1000 个页面」是用于说明速度差异的例子，不是所有智能体的固定访问量。按 CPM 换算机器阅读价格也未必公平：广告曝光、机器读取与最终带来的购买或引用，价值并不相同。
💬 在此前的产品讨论中，Knecht 称 Cloudflare 已推出帮助站点对内容收取小额费用的入口，并谈到智能体钱包、稳定币及与 OpenAI 合作的 Signals：让智能体更容易发现新内容，而不是反复抓取整张网页。他希望创作者最终获得足以覆盖基础设施成本、支持持续创作的收入，而不是只为承接访问流量付费。
💡 内容发现和内容付费是同一个经济问题的两端。减少重复抓取能降低站点成本，但只有收入能回到内容提供者手中，这套机制才可能成为可持续的替代方案。
⚡ 节目主要给出产品方向与期望，未提供创作者实际收入、交易规模或成本数据。智能体如何证明身份、处理支付争议，以及平台怎样分配议价权，仍待观察。
💬 Knecht 介绍了 Cloudflare 内部员工使用的 AI 平台：其出发点是避免客户和内部数据失控，同时让员工能够调用新工具、理解数据如何流动。他说，这个平台在市场拓展与行政等团队的使用甚至多于工程团队；相比给员工一个空白聊天框，预先接入业务数据和引导流程更容易发挥作用。他还提到，公司开发者平台已有超过 100 种工具，希望把内部平台作为可供他人借鉴的参考架构。
💡 企业 AI 落地的障碍往往不是员工不知道有模型，而是不知道模型能安全地连接哪些数据、完成哪项具体工作。把治理和用例放在同一产品中，有助于减少“便利性与安全性二选一”。
⚡ 内部使用广泛不等于对其他组织可直接复制。数据权限、审计要求和业务流程不同，参考架构仍需按本地风险重新设计。
💬 Knecht 坦言重组及与同事告别很艰难。他举例说明，过去产品经理给客户发邮件，要依次找 BI 确定人群、市场团队撰写内容、市场运营团队发送；现在可以在一个工具中描述目标人群、生成符合公司风格的邮件，再由经理批准发送。他认为，这不是让原有 3 个团队分别提速，而是重新设计任务本身。面对约 5000 人规模的组织，他更倾向给主动承担问题的人工具，让改造从基层发生。
💡 AI 对组织的影响可能大于对单个任务的提速。真正的变化涉及谁有权限完成工作、哪些交接可以取消，以及最后由谁审核。
⚡ 流程缩短不应抹去原有团队承担的合规、品牌或数据质量职责。重组的人员代价也不能只用效率收益衡量；节目未给出这一案例的错误率或节省成本数据。
💬 Knecht 认为，不该长期要求员工自己为每项任务挑模型；更理想的是智能路由。现阶段可先用前沿模型做规划，让成本较低的模型执行部分任务，再用强模型复核与红队测试。Cloudflare 不设 token 使用排行榜，而看员工交付了什么；如果个人某天用量达到约 300 美元，系统先发提醒，约 500 美元通知经理，约 1000 美元通知副总裁。他说这些升级通知很少发生。
💡 提醒而非一开始就设硬额度，能让员工探索，同时补上常被忽视的成本反馈。分阶段选模型则把昂贵算力留给更需要判断的环节。
⚡ 上述金额是该公司的内部做法，不是通用预算标准。只看交付而不看用量，也仍需有质量、安全和长期成本指标，避免短期产出掩盖浪费。
💬 在结尾前，Knecht 说公司曾从约 200 名实习生身上看到 AI 原生工作习惯，随后计划在一年内招募约 1000 名实习生；他也预计红队可能从当前 1 支增加到未来的 4—5 支。但多数小机构没有这样的资源。针对它们，他强调 Cloudflare 希望像普及边缘缓存一样，把重大漏洞发生时的防护提供给付费与免费用户。他以 CDN 覆盖作比：从过去约 3000 个具备大规模 CDN 的站点，发展到如今有数亿站点使用边缘缓存。
💡 如果强大的攻防工具只掌握在大公司手中，缺少专职安全团队的网站与服务会更加脆弱。基础设施提供商能否把及时防护作为普遍可得的能力，是“安全民主化”的实际检验。
⚡ 接入单一供应商并不能覆盖应用内部漏洞、身份治理或数据备份，也会带来平台依赖。Knecht 关于未来红队规模及覆盖效果的说法，应与已实现的服务能力区分。
“造成这种安全危机的 AI，也可能是帮助我们更快解决它的工具。”——Knecht 的结尾判断，意译
“如果你停止交付，你就在衰退。”——Knecht 谈安全工作与新功能开发如何并行，意译
“我们不鼓励 token 排行榜；我们希望人们关注产出。”——Knecht 谈内部 AI 使用管理，意译
“与其让三个团队各自更快，不如重新想一遍这件事该怎么做。”——对其跨团队邮件流程案例的概括，意译
安全债务与代码产量之间可能出现新的剪刀差。 智能体能更快检查旧代码，也能更快生成新代码。衡量安全进展，不能只看发现了多少漏洞，还要看漏洞从发现到修复所需时间，以及新功能是否带来更多依赖和权限入口。
机器友好接口不是把网页换一种格式那么简单。 API、内容发现信号和付费入口分别解决“怎样读取”“怎样知道内容更新”“谁为读取付钱”。缺少任意一环，智能体仍可能回到高频抓取人类网页的做法。
规范文档正成为可执行的组织基础设施。 当智能体参与代码、营销或内部操作，原本由资深员工口头传递的判断原则需要被写清楚。但可读的规则只是起点，还需要权限控制、审计和效果评估。