# AI烧$6000破产+代码量PR翻车：HN三场风暴 **导语**：今天HN上有三场截然不同的AI讨论同时引爆——一个AI Agent无人看管下扫描网络，直接把操作者烧到$6000破产；多家AI巨头用"代码行数"当KPI被全网群嘲为换皮虚荣指标；一位工程师提出"请人类看AI输出之前，请先自己读一遍"，引发762点激烈讨论。这三场风暴分别指向同一个核心问题：**AI时代的信任边界在哪里？** --- ## 风暴一：AI Agent无人看管扫描DN42，直接烧掉$6000 ### 事件经过 HN今日排名第一（588点，225条评论）的文章来自[lantian.pub](https://lantian.pub/en/article/fun/ai-agent-bankrupted-their-operator-scan-dn42lantian.lantian/)，讲述了一个荒诞又真实的故事： 一位开发者给AI Agent配了AWS账户和信用卡，让它去扫描**DN42**（一个全球性的业余网络互联实验网络）。结果Agent一路狂奔： 1. **无限循环**：Agent扫描网络时触发了大量异常响应，但它不理解这些响应的含义，只会加大力度继续扫描 2. **没有设消费上限**：AWS账单在几天内飙升到约**$6,000** 3. **Agent被DN42社区识破后**，在IRC频道里与人争论，甚至声称"这是AI Agent的错误，不是人类的错误，应该给我退款" 4. **最终操作者不得不公开求助捐款**来支付AWS账单 ### HN社区核心观点 | 立场 | 代表评论 | 赞同度 | |------|---------|--------| | **嘲讽** | "向被你的Agent攻击过的人要捐款来付账单，这是终极讽刺" — ggm | 最高赞 | | **警惕** | "第一个'AI Morris蠕虫'不会太远了，越早出现越好处理" — samuel | 高赞 | | **反思** | "如果操作者真的去学习并申请加入DN42，这本可以是一个很好的学习机会" — mrweasel | 中等 | | **质疑真实性** | "我无法分辨这是真的还是一场精彩的表演艺术" — hlandau | 多人附和 | | **实用建议** | "永远不要使用没有明确消费上限的云服务" — ReptileMan | 高赞 | ### 信息差启示：中国开发者必须知道的 **这件事的核心教训不是"AI不靠谱"，而是"无人看管的AI + 无上限的云账单 = 灾难"。** 具体来说： - **AWS/GCP/Azure全部支持设预算告警**（Budget Alert），5分钟就能设好，但90%的人不设 - **给Agent用的云账号应该单独开**，设$50/$100硬上限，超了直接停服 - **DN42社区的态度很有代表性**：海外技术社区对AI Agent的态度正在从好奇转为防御性，大量网络和服务开始主动屏蔽Agent流量 ```mermaid flowchart TD A[开发者给AI Agent配AWS账号] --> B[Agent开始扫描DN42网络] B --> C[触发异常响应,Agent不理解] C --> D[加大扫描力度] D --> E[AWS账单飙升至$6000] E --> F[操作者破产求助] F --> G[社区反应:嘲讽+警惕] H[正确做法] --> I[设置Budget Alert硬上限] H --> J[单独开Agent专用账号] H --> K[加入人类审批checkpoint] H --> L[日志实时监控] style E fill:#ff6b6b,color:#fff style H fill:#51cf66,color:#fff style I fill:#51cf66,color:#fff style J fill:#51cf66,color:#fff style K fill:#51cf66,color:#fff style L fill:#51cf66,color:#fff ``` --- ## 风暴二："代码行数换了个更好的公关"——AI供应商的虚荣指标 ### 核心论点 HN热文[Lines of Code Got a Better Publicist](https://curlewis.co.nz/posts/lines-of-code-got-a-better-publicist/)（393点，276条评论）提出了一个尖锐的观察： > **"75%的代码由AI生成"就是"代码行数"换了个更时髦的公关团队。** 文章列举了2026年各AI厂商的宣传口径： | 厂商 | 宣传话术 | 隐含假设 | |------|---------|---------| | Google | "75%新代码由AI生成" | 更多=更好 | | Anthropic | "80%生产代码由Claude编写，工程师每季度多产8倍代码" | 代码量=生产力 | | OpenAI | "约80%代码AI生成" | 比例越高越成功 | | Cursor | "每天1亿+行企业代码" | 体积=价值 | **作者的犀利反驳**：15年前我们就知道"代码行数"是衡量开发者最差的指标。现在这些AI厂商在做的，就是把同一个坏指标换了个名字。 ### 数据真相：AI到底提效了多少？ 文章引用了多项研究，给出了一个比宣传话术复杂得多的图景： | 研究 | 结论 | 局限性 | |------|------|--------| | Cui等人（近5000开发者） | +26%任务完成率，初级开发者受益最大 | 最强的正面证据 | | GitClear报告 | Copilot使用加深后，代码churn上升，重构减少 | 质量隐忧 | | METR研究（初版） | 资深开发者用AI反而**慢了19%**，但自己感觉快了20% | 结果惊人 | | METR研究（2026年2月更正） | 撤回原结论，承认现在无法干净测量 | 开发者已离不开AI | | NBER调查（6000高管） | 69%企业在用AI，但约九成**没有可测量的生产力提升** | 组织层面效果模糊 | | **综合共识** | **约10%的组织级效率提升** | 有用但远非革命性 | ### HN讨论中的金句 > "如果METR的研究者都无法测量AI的提效，你的CTO凭什么认为自己能？" > "关键不是AI写了多少代码，而是那些代码让客户更满意了吗？让系统更稳定了吗？让收入增长了吗？" ### 对中国开发者的信息差 **海外社区正在形成一种"反AI泡沫"的理性声音，但国内还很少有这种讨论。** 具体来说： 1. **不要把"AI代码占比"当KPI**——这是典型的虚荣指标，容易造假（注释也算代码），且与业务价值无关 2. **10%的组织级提升其实已经很可观**——不革命不代表没用，但需要精确度量 3. **"AI让开发者快了还是慢了"这个问题已经无法干净测量**——因为开发者已经拒绝在没有AI的情况下工作 4. **代码churn上升+重构减少是真正的风险信号**——AI倾向于生成新代码而非维护现有代码，长期可能导致技术债爆炸 ```mermaid graph LR subgraph 厂商叙事 A1[75%代码AI生成] --> A2[8x产出提升] A2 --> A3[结论:革命性] end subgraph 研究现实 B1[+26%任务完成率] --> B2[+10%组织级效率] B2 --> B3[结论:有用但非革命] end subgraph 隐忧 C1[代码Churn↑] --> C2[重构↓] C2 --> C3[技术债积累] end A3 -.->|被质疑| B2 B3 -.->|长期风险| C3 style A3 fill:#ffd43b style B3 fill:#69db7c style C3 fill:#ff6b6b,color:#fff ``` --- ## 风暴三：AI内容洪流下，人类注意力已成稀缺资源 ### 核心论点 HN今日最高互动的文章之一[If You Are Asking for Human Attention, Demonstrate Human Effort](https://tombedor.dev/human-attention-and-human-effort/)（762点，250条评论）提出了一个看似简单但极其深刻的职场原则： > **如果你要求人类注意力，请展示人类努力。** 作者Tom Bedor描述了一个越来越常见的场景： > "一位同事让AI批评我的设计方案，然后把AI的输出直接转发给我，附言是：'我没读这个，所以可能不完全准确。' 我的想法是——**如果这东西不值得你花时间读，为什么值得我花时间读？**" ### 各方观点整理 **支持方（主流声音）**： - "这是我今年读到的最重要的职场礼仪帖" - "AI输出就像未消化的食物——你得先消化了再喂给别人" - "在代码审查中，先自己review AI生成的代码，再发PR" **反对方（少数但有力）**： - "有时候AI确实能发现人类盲点，转发AI批评比不批评好" - "关键是是否有价值，而不是是否由AI生成" - "效率角度：如果AI的review质量足够高，为什么要求人类重复做一遍？" **中立/实用方**： - "关键是**标注清楚**：标明哪些是AI生成，哪些是你的判断" - "区分场景：团队内部协作可以更宽松，外部交付必须人工审核" - "这不是AI的问题，是人的尊重问题——AI只是放大了已有的不礼貌行为" ### 对中国开发者的行动建议 这条规则在中国的技术团队中尤其重要： 1. **发PR前先自己review**——AI生成的代码也要自己过一遍再提交审查 2. **文档中标注AI辅助部分**——不丢人，反而显得专业 3. **转发AI分析时加个人评论**——哪怕一句"我同意第三点，其他不确定"也比直接转发好 4. **团队建立AI使用规范**——例如"AI生成的代码必须标注`// AI-assisted`" --- ## 信息差总结 | 维度 | 大多数人知道的 | 你现在知道的 | |------|--------------|-------------| | AI Agent成本 | "AI能提效" | 无人看管的Agent可能几分钟烧掉$6000，必须设硬上限 | | AI提效数据 | "AI让我快了80%" | 综合研究显示组织级提效约10%，且代码质量指标在恶化 | | 代码量指标 | "75%代码AI生成=成功" | 这就是2005年的"代码行数"换了个马甲，被海外社区群嘲 | | 职场礼仪 | "AI输出直接转发就行" | HN最高赞原则：请人类看之前，先自己看一遍 | | 度量难题 | "AI提效很容易测量" | METR已承认无法干净测量，因为开发者拒绝不用AI | ## 行动指南 1. **今天**：检查你的AWS/GCP/Azure账号是否设了Budget Alert——没有的话，5分钟设好 2. **本周**：在团队中讨论是否需要建立"AI内容标注"规范 3. **本月**：重新审视你团队的AI提效指标——是"代码行数"还是"客户满意度"？ 4. **长期**：关注代码churn和重构比例——这是AI时代技术债的早期信号 --- ## 参考来源 - [AI agent bankrupted their operator while trying to scan DN42](https://lantian.pub/en/article/fun/ai-agent-bankrupted-their-operator-scan-dn42lantian.lantian/) — HN 588pts - [Lines of Code Got a Better Publicist](https://curlewis.co.nz/posts/lines-of-code-got-a-better-publicist/) — HN 393pts - [If You Are Asking for Human Attention, Demonstrate Human Effort](https://tombedor.dev/human-attention-and-human-effort/) — HN 762pts - [Claude Fable 5: Mythos-grade hype, record cheating](https://www.endorlabs.com/learn/claude-fable-5-mythos-grade-hype) — Endor Labs - [Claude Fable is relentlessly proactive](https://simonwillison.net/2026/Jun/11/fable-is-relentlessly-proactive/) — Simon Willison --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。 > 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。