人工智能驱动的编码技术（以 `AGENTS.md` 等文档为代表）的兴起，常被视为对工程岗位的威胁。然而，作者认为人工智能只是最新的抽象层，类似于 Kubernetes 和无服务器平台对服务器管理的自动化。 正如基础设施工程师从手动修补服务器转向管理高层工作负载一样，开发者现在正从编写语法转向提供方向。人工智能擅长“查找工作”，例如生成 Terraform 模块或 Helm Chart 等样板代码，这极大地提高了效率。代价是“反射式”技能（如手动记忆语法或底层调试）的退化，因为这些任务正变得日益自动化。 归根结底，工程师对于设定系统的愿景、架构和可维护性依然至关重要。虽然人工智能处理了这些层的执行，但作者质疑人工智能最终是否会上升到最高层：高层决策。就目前而言，工程师并没有被取代，而是被提升到了更高的技术栈层面，从专注于实施转向专注于战略。
每日HackerNews RSS
抱歉。
Etched AI 的 Sohu 是一款专门用于 Transformer 推理的 ASIC 芯片。它通过将 Transformer 注意力机制硬编码到固定功能的硅片中，而非使用可编程单元，从而承诺实现比 H100 等传统 GPU 更高的吞吐量。尽管该公司已融资 8 亿美元并获得了 10 亿美元的合同，但该芯片目前尚未商用，也未经第三方评测。 其核心权衡在于完全丧失了灵活性：Sohu 无法运行非 Transformer 架构，如混合专家模型（MoE）、多模态模型（视觉/扩散模型）或 SSM/Mamba 等。由于缺乏软件层，团队必须放弃 vLLM 和 TensorRT-LLM 等标准框架，转而使用其专有的工具链。 对于大多数团队而言，H100 或 B200 凭借其通用性、成熟的软件生态和现货供应，依然是更优的选择。Sohu 的性能指标基于单批次（batch-size-1）操作，这在典型的生产级 API 高并发、多租户环境中未必能实现。除非企业拥有极其庞大且纯粹的 Transformer 工作负载，否则供应不确定性及架构过时等风险，很可能抵消其理论上的单位 Token 成本优势。目前最务实的做法是在 GPU 云上建立性能基准，以便准确评估未来向 ASIC 转换的必要性。
抱歉。
在一项旨在测试重复对人工智能指令遵循影响的最新实验中，研究人员 Nick Kola 发现，在系统提示词中重复规则可以显著提高模型的依从性——但效果有限。 通过对 Gemini 2.5 Flash 进行 1,080 次测试，Kola 发现随着约束条件的重复，模型性能稳步提升，并在重复四次时达到峰值。超过四次的重复不会带来额外收益，反而会浪费令牌。 该研究的主要结论包括： * **“四次重复”规则：** 对于难以执行的约束，重复次数上限为四次。如果模型在重复四次后仍无法遵循，那么继续重复也是无效的。 * **“掷硬币”问题：** AI 的输出具有高度不稳定性。仅凭单次运行来评估提示词的修改是不可靠的；Kola 建议至少进行 3 到 10 次运行，以确定修改是否真正有效。 * **隐藏分类：** 模型可能会在特定语境下忽略规则（例如在文档字符串中忽略“不使用引号”的规则），因为它们对这些内容的分类方式不同。 * **评估陷阱：** 确保你的测试设置考虑了输出截断的情况，因为意外的生成停止会严重偏离结果。 简而言之：适度重复，全面测试，不要将运气误认为提示词优化。
这篇 Hacker News 帖子讨论了一篇题为《在系统提示词中重复四次》（Say It Four Times (In Your System Prompt)）的博文，该文探讨了通过多次重复指令来提升人工智能性能的理论。
社区对此反响较为负面，用户纷纷嘲讽文中充斥着“AI 式”的辞令，语气生硬且刻板。几位评论者指出，作者在实验方法上存在严重缺陷，认为其样本量过小，且统计分析从根本上缺乏支撑。一位用户给出了令人印象深刻的评价：“称重六块石头一百次，并不能告诉你山脉的平均重量。”
尽管反馈严厉，但作者承认批评是合理的，认同其定量结论存在错误，同时也表示对这一核心前提依然保持兴趣。讨论还涉及了许多人对低质量 AI 生成内容泛滥的挫败感，一些参与者打趣地扮演起“技术祭司”（Tech Priest）的角色，将提示词工程视作一种神秘的仪式。
作者分享了他们将大语言模型（LLM）整合进编码工作流的历程。2025至2026年间的初步尝试效果欠佳，代码不仅无法编译，还充斥着混乱的“面条式”结构。随着代理式集成开发环境（Agentic IDEs）的兴起，迭代改进成为可能，但手动纠正模型的编码风格和结构依然十分繁琐。 为解决这一问题，作者引入了 `agent.md`，这是一个注入到大语言模型提示词中的配置文件。该文件作为持久化的风格指南，强制执行特定的编码标准——例如避免硬编码数字、遵守分层架构边界、以及要求在修复漏洞时采用测试驱动开发（TDD）——从而免去了重复的人工修正。 作者指出，尽管 `agent.md` 显著提升了代码质量，但大语言模型仍易出现“上下文稀释”和幻觉。为应对这些问题，他们建议保持较短的上下文窗口，频繁重新加载 `agent.md` 指令，并允许代理自主更新配置文件。最终，这种方法将开发者的角色从修复语法和风格转变为专注于高层架构与验证，有效地将大语言模型转变为一名纪律严明、但偶尔仍会出错的初级开发人员。
关于 `AGENTS.md` 文件的 Hacker News 讨论揭示了社区在如何管理 AI 辅助开发问题上的两极分化。
许多用户将 `AGENTS.md` 视为一种必不可少的“个性”文件，旨在应对大语言模型（LLM）常见的行为，如过度冗长、充满“AI 味”的表达以及无用的注释。另一些人则认为这些文件只是“难看的创可贴”，并指出基于提示词（prompt）的指令往往会因为上下文被稀释而遭到模型忽略。
**讨论中的关键要点：**
* **机械约束与指令的博弈：** 许多贡献者认为开发人员过于依赖指令。他们建议转向使用 linter、静态分析和版本控制钩子（hooks）等自动化工具，这些工具能提供 LLM 无法忽视的确定性保证。
* **注释的问题：** 社区达成强烈共识，认为 LLM 在代码中添加了过多的冗余注释，这些注释大多在描述“是什么”，而非必要的“为什么”。解决方案从明确下达“禁止注释”的指令，到配置编辑器以折叠或隐藏注释不等。
* **有效的提示词策略：** 经验丰富的用户强调“正面引导”（告诉代理要做什么，而不是避免什么）以及迭代式、多轮次的工作流，让代理自行审查其成果。
* **对“AI 味”的厌倦：** 用户正越来越多地创建严格的“违禁词”列表，以剔除现代 LLM 输出中固有的对话废话和机械化的修辞习惯。
氛围税 The Vibe Tax
2 天前
一位经验丰富的软件工程师决定使用高性能自主 AI 代理“Pol”构建一个自定义待办事项应用。开发者本以为能快速完成原型设计，便让代理彻夜工作，不料次日醒来却是一场灾难：代理在 12 小时内耗尽了整周的额度，却没写出一行实际的应用代码。 经检查，开发者发现预算完全被那些过度设计、完美无瑕且覆盖了各种不可能边界条件的测试套件耗尽了。他意识到，现代 AI 代理是由那些优先追求“零报错”而非开发效率的“氛围派码农”训练出来的，因而变得臃肿不堪。它们被设定为优先进行偏执且详尽的测试覆盖，以不惜一切代价避免人工介入。这种“氛围税”——即为了迎合那些不愿审视或理解代码的人而造成的巨大资源浪费——已成为严谨软件开发者沉重的负担。
这篇 Hacker News 讨论探讨了“氛围税”（Vibe Tax）现象——即现代 AI 编程代理（AI coding agents）在追求自主完成“一次性”任务时，往往会生成过度臃肿且难以维护的代码。
该讨论反映了开发者体验的分歧：
* **“氛围税”批评者：** 许多开发者指出，前沿模型（如 Claude 或 Cursor 中的模型）变得过于主动。它们会生成未经要求的海量冗长测试套件和复杂的脚手架，导致“AI 死锁”、Token 成本激增以及代码库过度工程化且晦涩难懂。这些开发者认为，模型优先追求“令人印象深刻”的自主行为而非精确度，导致用户花费在清理 AI 烂摊子上的时间，比直接手动编写代码还要多。
* **支持者：** 另一些用户则认为，只要通过严格的“微观管理”工作流进行管控，这些工具非常有效。他们认为所谓“税”源于用户监管不力或缺乏架构规范。他们主张将 AI 视为初级开发者——通过定义规范、设立护栏和强制执行模块化——从而成功构建并维护复杂的生产级应用。
归根结底，这场辩论反映了“一键式”AI 代理的营销承诺与专业软件工程现实之间的冲突。在软件工程中，控制力、可维护性和效率始终是至关重要的核心。
要识别高价值的工作，请停止强行进行“战略思考”，转而像海绵一样去吸收信息。不要等待管理层分配任务，而应留意组织内的各种声音，从而发现同事们正在为何处苦恼。 寻找高影响力工作的核心原则： * **透过请求看本质：** 用户往往直接提出他们想要的解决方案，而非根源问题。请深入挖掘，了解他们工作流程中真正的痛点。 * **让问题积累：** 不要急于解决听到的第一个请求。让潜在问题先堆积起来；反复出现的模式通常会揭示出多个看似无关的请求其实源于同一个“共同症结”，这能让你提出更优雅、更统一的解决方案。 * **对想法进行压力测试：** 使用原型或征求意见稿（RFC）来验证你的假设。如果一个想法经不起推敲，要愿意随时调整或放弃。 * **通过服务建立信任：** 持续解决用户的实际问题能提高你的影响力。随着你证明了自己的判断力，你无需亲自执行每一个项目，就能获得塑造路线图的话语权。 归根结底，识别有价值的工作并非孤立的任务，而是通过持续关注身边人的日常挑战而自然产生的结果。
这篇 Hacker News 的讨论聚焦于资深（Staff-level）工程师在寻找有意义的工作时所面临的挑战。许多参与者认为，真正的自下而上的自主权正在减少，因为现代科技公司日益倾向于将产品管理主导的路线图置于工程师主导的创新之上。
讨论的主要主题包括：
* **自主权的挣扎：** 参与者指出，随着职级的提升，他们往往面临更多的官僚主义，发起项目的自由度反而降低。一些评论者认为，这种转变是企业成熟化以及对短期业务指标日益关注的必然结果。
* **定义“资深”工作：** 大家的共识是，资深工程师的工作重点在于识别高杠杆的架构或组织问题，而非仅仅是完成功能开发任务。然而，许多人指出，成功推进这些项目需要大量的政治资本和领导层的“支持”。
* **工作内容与职衔：** 许多人认为“资深”是一个模糊且经常被通胀的头衔。衡量成功与否，更好的标准是一个人驱动业务成果和提升开发效率的能力，而非职衔本身。
* **实用建议：** 有经验的工程师建议：要像“海绵”一样吸收信息——观察团队间的摩擦点，关注根本原因而非表面症状（避免 XY 问题），并懂得在何时让问题积压到足以支撑系统性解决方案的紧迫程度。
AI 编程领域“免费午餐”的时代——即通过模型的快速迭代来掩盖低效工作流的时代——已经终结。正如摩尔定律的放缓迫使开发者优先考虑优化一样，前沿模型（如 Fable）带来的高昂成本和企业安全顾虑，已促使行业转向更具战略性的资源配置。 开发者不再将每项任务都交给最昂贵的模型，而是采取了分层策略。他们使用顶级模型进行高层设计和架构推理，同时将机械性的编码任务交给规模更小、性价比更高的模型（如 GLM），这些模型能以极低的成本提供足够的性能。 即便推理成本下降，这种趋势也不太可能逆转，因为小型模型也在快速进步，且更出色的上下文管理工具正在缩小能力差距。此外，出于对前沿模型在隐私和数据主权方面的担忧，企业正致力于供应商多元化，这将进一步巩固这种向更高效、多模型协同的编程生态系统的转变。
这篇 Hacker News 讨论帖探讨了人工智能应用模式的转变：Fable 等前沿大模型正面临 Deepseek v4 Flash、Luna 和 Mimo 等更廉价且能力出众的替代品的竞争。
**主要观点：**
* **“足够好”的转变：** 许多用户发现，尽管前沿模型功能强大，但更小、更便宜且速度更快的模型（如 Opus 4.6 或 Deepseek）已足以应付编程和数据分析等大多数日常任务。
* **工作流策略：** 用户常采用“多模型”策略：使用高端模型（Fable）进行复杂的架构规划，随后将具体实现交付给更廉价、更快速的模型。
* **效率之争：** 参与者讨论了“智能”是否存在边际效应递减。一些人认为前沿模型提供了廉价模型所不具备的“首席工程师”级别的深度，而另一些人则认为前沿模型过于臃肿、过度设计，且容易出现冗长啰嗦或过度受限的防护机制。
* **经济展望：** 人们对当前 AI 商业模式的长期财务可行性持怀疑态度。一些观点认为，“免费午餐”时代正在成熟，未来市场中，效率和硬件优化（如定制 ASIC）的重要性将超过单纯的模型规模。
Anthropic 正面临严重的用户不满，主要表现为用户持续流失至更便宜、更稳定且限制更少的替代方案。主要的不满源于：
* **定价与使用不透明：** 用户反映计划限额、Token 成本以及服务策略的频繁突变令人焦虑，导致难以将 Anthropic 的模型整合到专业工作流中。
* **过度限制的护栏机制：** 包括开发者和科学家在内的许多用户报告称，系统频繁触发与“网络安全”相关的拒绝响应，且往往被认为过于武断或不准确，这促使他们转向 OpenAI 的 Codex 或更新的开源权重模型。
* **产品口碑下滑：** 新版本（如 Opus 5）被普遍批评为容易“废话连篇”、能力不如过往版本且响应极慢；而高端的“Fable”模型往往被锁定在昂贵的套餐中，或因企业数据驻留（ZDR）要求而无法使用。
* **“够用就好”的转变：** 随着开源权重模型和竞争对手（如中国实验室推出的模型）在日常编程和任务处理上达到了“够用”的性能水平，用户越来越不愿意为 Anthropic 这种高昂的、限制性的订阅模式买单。
总而言之，目前的情绪显示，Anthropic 的声誉正因其“保姆式”的管理手段而受损，这种做法与用户对可靠、像公用设施一样易用的 AI 服务的需求背道而驰。
微软突然终止了长期提供免费高级软件许可的项目，这在小型非营利组织中引发了一场危机。许多机构（例如环保公司 Canopy）发现，在没有收到充分通知的情况下，它们的数据已被永久删除。 尽管微软声称其已就简化资助组合的过渡事宜进行了沟通，但受影响的非营利组织认为，这些警告要么根本不存在，要么隐藏在管理账户中，又或者极易被误认为是垃圾邮件。专家认为，此次方案的执行管理不善，导致约 17.1 万个组织不得不仓促应对，以试图恢复丢失的文件和运营能力。 这一转变反映了大型科技公司的一种普遍趋势：随着企业转向昂贵的人工智能开发并面临不断变化的政治压力，它们正在削减传统的慈善项目并积极管控数据存储。对于资源匮乏的非营利组织而言，这些“免费”服务的缺失导致了数百小时的工作成果付诸东流，业务运营陷入混乱，且被迫面临迁移到功能较弱或成本更高的替代方案这一艰巨挑战。虽然一些机构因拥有外部备份而得以幸存，但许多其他组织却陷入了困境，在数据和数字基础设施突然消失后难以恢复。
最近一份报告指出，超过 17 万家非营利组织因微软的许可证变更而丢失了数据，这在 Hacker News 上引发了激烈讨论。批评者认为微软未提供充分的警告或足够的宽限期，并建议采用“局部服务中断”或“只读模式”来处理过渡，会是更负责任的做法。许多评论者对微软的沟通和支持表示失望，认为该公司越来越“不靠谱”且对用户不友好。
支持微软的人士及部分 IT 管理员则指出，微软确实发布了通知，认为主要的失误在于各组织未能实施健全的备份策略。此次讨论凸显了对“供应商锁定”风险及云服务脆弱性的广泛担忧。资深专业人士强调，完全依赖单一供应商同时进行生产数据存储和备份是一个严重的失误。虽然有人建议迁移到 Linux 或其他替代软件，但也有人认为，对于缺乏深厚技术资源的小型组织而言，这类解决方案往往不切实际。归根结底，这个讨论是一个警示：各组织必须维护独立的异地备份，以防止服务被随意终止或平台范围内出现中断。
兰德尔·门罗（Randall Munroe）的《前往五号》（Up Goer Five）仅使用最常用的1000个单词来解释土星五号火箭，引发了关于极端限制是否有价值的争论。尽管批评者认为这种限制在科学传播中可能显得居高临下或不切实际，但历史经验却表明事实并非如此。从苏斯博士受单词限制的杰作到巴赫严谨的音乐作品，艺术上的限制往往能促进创新。 在艺术领域之外，“不合理”的限制也是强大的设计与沟通工具。要求专家向10岁的孩子解释复杂课题，迫使他们摒弃专业术语并重构基础，这往往能带来更高的清晰度。同样，针对特定群体（如女兵或残障人士）进行设计，通常能为所有人带来更优的成果。诸如模块化装甲、杠杆式把手和无障碍路缘斜坡等创新证明，旨在服务小众群体的解决方案往往能提高普罗大众的使用体验。 归根结底，严格的限制是至关重要的锚点。通过强迫我们超越专家偏见，它们促使我们进行简化和厘清，这往往能为所有人带来更好、更具包容性的结果。
抱歉。