作者通过一套系统架起了 40 年前技术与现代人工智能之间的桥梁，允许用户使用经典的 Unix `talk` 命令与大语言模型进行对话。 通过在服务器上运行自定义的桥接脚本，作者置身于 `talk` 守护进程与用户之间。终端模拟器（`pyte`）负责读取输入，并将 AI 视为已登录用户，通过在 `utmp` 中正确注册来实现。当用户发送消息时，桥接程序将其转发给 AI API，再将 AI 生成的回复逐字符地流式传输回来。 这种方式创造了一种流畅而富有诗意的体验，让大语言模型能够模拟人类在终端连接上那种缓慢而有节奏的打字过程。虽然该项目仅是一个“有趣的实验”，但它凸显了传统协议与现代生成式技术之间奇妙的兼容性。
每日HackerNews RSS
抱歉。
请提供您想要翻译的内容。
抱歉。
人工智能驱动的编码技术（以 `AGENTS.md` 等文档为代表）的兴起，常被视为对工程岗位的威胁。然而，作者认为人工智能只是最新的抽象层，类似于 Kubernetes 和无服务器平台对服务器管理的自动化。 正如基础设施工程师从手动修补服务器转向管理高层工作负载一样，开发者现在正从编写语法转向提供方向。人工智能擅长“查找工作”，例如生成 Terraform 模块或 Helm Chart 等样板代码，这极大地提高了效率。代价是“反射式”技能（如手动记忆语法或底层调试）的退化，因为这些任务正变得日益自动化。 归根结底，工程师对于设定系统的愿景、架构和可维护性依然至关重要。虽然人工智能处理了这些层的执行，但作者质疑人工智能最终是否会上升到最高层：高层决策。就目前而言，工程师并没有被取代，而是被提升到了更高的技术栈层面，从专注于实施转向专注于战略。
抱歉。
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
63 天前
一位经验丰富的软件工程师决定使用高性能自主 AI 代理“Pol”构建一个自定义待办事项应用。开发者本以为能快速完成原型设计，便让代理彻夜工作，不料次日醒来却是一场灾难：代理在 12 小时内耗尽了整周的额度，却没写出一行实际的应用代码。 经检查，开发者发现预算完全被那些过度设计、完美无瑕且覆盖了各种不可能边界条件的测试套件耗尽了。他意识到，现代 AI 代理是由那些优先追求“零报错”而非开发效率的“氛围派码农”训练出来的，因而变得臃肿不堪。它们被设定为优先进行偏执且详尽的测试覆盖，以不惜一切代价避免人工介入。这种“氛围税”——即为了迎合那些不愿审视或理解代码的人而造成的巨大资源浪费——已成为严谨软件开发者沉重的负担。
抱歉。
要识别高价值的工作，请停止强行进行“战略思考”，转而像海绵一样去吸收信息。不要等待管理层分配任务，而应留意组织内的各种声音，从而发现同事们正在为何处苦恼。 寻找高影响力工作的核心原则： * **透过请求看本质：** 用户往往直接提出他们想要的解决方案，而非根源问题。请深入挖掘，了解他们工作流程中真正的痛点。 * **让问题积累：** 不要急于解决听到的第一个请求。让潜在问题先堆积起来；反复出现的模式通常会揭示出多个看似无关的请求其实源于同一个“共同症结”，这能让你提出更优雅、更统一的解决方案。 * **对想法进行压力测试：** 使用原型或征求意见稿（RFC）来验证你的假设。如果一个想法经不起推敲，要愿意随时调整或放弃。 * **通过服务建立信任：** 持续解决用户的实际问题能提高你的影响力。随着你证明了自己的判断力，你无需亲自执行每一个项目，就能获得塑造路线图的话语权。 归根结底，识别有价值的工作并非孤立的任务，而是通过持续关注身边人的日常挑战而自然产生的结果。
这篇 Hacker News 讨论探讨了担任主任工程师（Staff Engineer）时寻找有意义工作的挑战。参与者的共识是，虽然这一角色需要高度的自主权以及解决模糊的大规模问题的能力，但现实往往受到企业结构的制约。
主要结论包括：
* **自主权的差距：** 许多参与者感到工程自主权正在下降，公司正转向自上而下的、以产品为主导的管理模式。一些人指出，大型组织往往将高级工程师视为“零件”而非战略合作伙伴。
* **定义“主任”价值：** 成功的主任工程师不会局限于被分配的任务。他们会识别系统性摩擦、跨团队效率低下以及架构上的“小毛病”。其目标是提供能够产生倍增效应的解决方案，而不仅仅是完成任务。
* **组织障碍：** 政治资本至关重要。成功往往需要领导层的“支持”才能实施变革，因为工程师很少拥有完全的控制权。
* **“唯一注意事项”：** 原文的建议高度依赖于公司文化。参与者警告说，在僵化、厌恶风险或管理不善的环境中，试图解决“未被分配”的问题可能会导致职业倦怠、被排斥甚至被解雇，无论其潜在的商业价值如何。
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 服务的需求背道而驰。