## 验证规格驱动开发 (VSDD) – 摘要 VSDD 是一种新颖的软件工程方法，将规格驱动开发 (SDD)、测试驱动开发 (TDD) 和验证驱动开发 (VDD) 结合到一个 AI 编排的流程中。它优先考虑一个严格、可追溯的过程，其中规格定义了软件 *做什么*，测试强制执行 *如何构建*，而对抗性验证确保 *不会遗漏任何内容*。 该过程涉及一名人类架构师监督 AI “构建者”和“对抗者”代理，并通过 Chainlink 进行跟踪以确保完全的责任追溯。第一阶段侧重于“规格提炼”，在编码 *之前* 创建严密无缝的规格，包括可证明的属性和将可验证的核心逻辑与外部效应分隔开的“纯度边界”。第二阶段实施严格的 TDD 循环 (红→绿→重构)，由 AI 构建者引导。第三阶段将代码置于 AI 对抗者的严格审查之下，识别规格、测试和实现中的缺陷。第四和第五阶段整合反馈并执行形式化验证，而第六阶段确认“收敛”——当规格、测试、实现和证明都能经受住对抗性审查时。 VSDD 强调“规格至上”，验证优先的架构和无情的否定态度以消除“漏洞”。它专为需要高正确性、长期可维护性和强大安全性的项目而设计，利用 AI 来增强而非取代人类的战略决策。最终，VSDD 旨在创建具有可证明存在理由和可靠保证的代码。
每日HackerNews RSS
## AI 驱动的规范驱动开发：摘要
这次 Hacker News 的讨论围绕“验证的规范驱动开发”（VSDD），这是一种随着 AI 辅助编码兴起而逐渐流行的流程。其核心思想是优先*明确*系统应该做什么，*然后再*编写代码，利用 AI 根据这些规范生成和测试代码。
一些评论者质疑其可行性——认为它假定先验知识，不适用于需要快速迭代的探索性 AI 开发。但也有人支持它。一个关键点是，由于代码生成成本降低，专注于完善的规范变得更有价值。
这场辩论凸显了“感觉编码”（快速原型设计）和正式规范之间的紧张关系，许多人建议采取混合方法。几位参与者强调了人工监督的重要性，指出 AI 生成的代码可能混乱，需要仔细审查。一些人提倡使用 AI *生成*现有代码的规范，从而辅助迭代改进。
最终，讨论表明 VSDD 并非关于严格的前期规划，而是关于将规范用作动态演化的工件，以指导 AI 开发并控制复杂系统。
格奥尔格·康托尔通常被认为是集合论的创始人，并在1874年证明了存在不同大小的无穷。然而，最近的研究揭示了一个更复杂的故事。播客制作者Goos最初认为康托尔是一位孤独的天才，但后来发现康托尔严重依赖数学家理查德·戴德金。 在1872年的一次关键会议之后，康托尔不断寻求戴德金的建议，最终提出了一个引发突破性进展的问题：实数和整数是否可以“一一对应”？戴德金提供了关键的见解，甚至简化了康托尔最初的证明。康托尔怀着强烈的使命感和对无穷肯定上帝存在的信念，旨在彻底改变数学。 然而，由于担心受到有影响力的数学家利奥波德·克罗内克尔的拒绝——一位坚决反对无穷的学者——康托尔有策略地发表了他的发现。他向《克雷莱杂志》提交了一篇关于代数数（克罗内克尔喜欢的课题）的论文，巧妙地包含了关于实数的革命性证明，并淡化了其重要性。至关重要的是，康托尔声称是唯一的作者，抹去了戴德金的贡献。几十年后被艾米·诺特发现的信件揭示了戴德金曾向康托尔发送了核心证明，这些证明几乎原封不动地以康托尔的名义出现。虽然戴德金私下注意到这个问题，但他和诺特都选择让通信本身说话，维护了专业的沉默准则。
## 康托尔与戴德金：关于署名权的问题
一篇近期文章探讨了格奥尔格·康托尔在其关于无穷和实数线完备性的研究中可能存在的剽窃问题。虽然康托尔被认为是第一个证明实数不可数的人，但该文章认为，他证明代数数的可数性很大程度上依赖于理查德·戴德金的工作，可能缺乏充分的署名。
讨论的中心在于，鉴于戴德金为康托尔最初的证明提供了一个关键的简化，他的贡献是否应该得到联合署名，或者至少得到承认。一些人认为，学术政治的背景——特别是避免与数学家克罗内克发生冲突——可能阻止了适当的署名。
然而，另一些人强调康托尔的整体遗产仍然稳固，因为他是第一个证明存在不同*大小*的无穷。这场争论也涉及报道的准确性，人们对原始文章中的事实错误以及更广泛的浮于表面的科学新闻趋势表示担忧。最终，核心问题是康托尔是否恰当地承认了戴德金对一项基础数学突破的重大贡献。
## Obsidian 获得无头客户端和 CLI 关注 - 摘要
Obsidian 这款流行的笔记应用发布了无头客户端，并强调其命令行界面 (CLI)。这使得在无需运行完整 Obsidian 应用的情况下，即可实现自动同步、远程备份以及与 AI 工具集成。用户对脚本编写、服务器端自动化和代理工作流的可能性感到兴奋。
讨论的重点是同步解决方案的争论。虽然 Obsidian Sync 提供便利性、加密和版本历史记录，但许多用户正在探索替代方案，如 Git、Syncthing 和云存储 (Dropbox、iCloud、Nextcloud)，以避免订阅费用或获得更多控制权。移动同步仍然是 Obsidian 之外解决方案面临的关键挑战。
一个反复出现的主题是对更大灵活性的渴望，包括选择性同步、更轻松地与其他工具集成以及更强大的免费版本。尽管有这些愿望，许多人仍然承认 Obsidian Sync 的价值，并愿意为其易用性和持续的开发支持付费。新的 CLI 被视为对高级用户和自动化爱好者的重要一步。
## Claude 上下文模式：延长 AI 会话时长 Claude 代码使用 MCP 工具时，常常会迅速填满其 200K 上下文窗口，例如，Playwright 快照会占用 56KB，20 个 GitHub issue 占用 59KB。这限制了会话时长，仅 30 分钟后便会损失 40% 的上下文。**上下文模式** 通过充当 Claude 与工具输出之间的服务器，大幅减少数据大小——从 315KB 减少到仅 5.4KB（减少 98%）来解决这个问题。 它通过一个安全的 **沙箱** 实现这一点，在隔离的进程中执行工具调用。只有 *输出* (stdout) 会传递给 Claude，从而防止大型原始数据（如日志或 API 响应）膨胀上下文。支持十种语言运行时，包括通过 Bun 优化的 JavaScript/TypeScript。 内置的 **知识库** 使用 BM25 搜索索引 markdown 和网页内容，返回精确的代码块——而不是摘要——而无需将原始页面内容发送到上下文。 在实际场景中的测试表明，输出大小显著减少（例如，56KB 快照减少到 299B）。这使可用会话时间从约 30 分钟延长到约 3 小时，45 分钟后保留 99% 的上下文。上下文模式易于安装为插件或直接通过 MCP，并且不需要更改现有工作流程。
## Claude 上下文模式：摘要
mksglu 的“Claude 上下文模式”（CCM）是一种旨在大幅减少 Claude 上下文窗口消耗的系统——最高可减少 98%——通过智能处理工具输出实现。CCM 不会将原始数据（如日志、快照或 git 历史记录）直接转储到上下文窗口中，而是将工具调用在隔离的子进程中运行。然后，它仅将简洁的摘要返回给 LLM，同时将完整输出存储在可搜索的本地 FTS5 数据库中。
这种方法避免了上下文膨胀，并允许 LLM 在需要时从数据库请求特定细节。主要功能包括用于提高效率的增量索引，以及使用 BM25 和向量搜索（通过 Model2Vec 和 sqlite-vec）来实现强大的检索。
讨论强调了这种“预压缩”策略的优势，并将其与在上下文已被消耗*之后*尝试修剪上下文的方法进行对比。虽然有人争论其对所有工具类型（特别是 MCP 工具）的适用性，但总结和索引输出的核心原则被视为 LLM 工作流程中的一项有价值的优化，可能提高性能并降低成本。该项目在 GitHub 上可用：[https://github.com/mksglu/claude-context-mode](https://github.com/mksglu/claude-context-mode)。
## 从噪声到图像：AI如何创造视觉内容 AI图像生成，例如扩散模型，在难以置信的巨大图像可能性空间中运作——估计为10<sup>400,000</sup>。这些模型并非从零开始*创造*；它们从随机噪声开始，并根据你的提示逐步将其提炼成连贯的图像。 这个过程发生在更易于管理的“潜在空间”中，这是所有可能图像的压缩表示。文本提示也被转换成高维的“嵌入空间”，作为引导模型旅程的指南针。 关键因素会影响结果：**随机种子**决定起点，**步数**控制提炼频率，而**引导比例**则决定模型遵循提示的程度。更详细的提示提供更清晰的方向。 有趣的是，模型甚至可以在提示*之间*生成图像，探索嵌入空间中不对应特定词语的区域。最终，AI图像生成是对巨大可能性的复杂导航，将混沌转化为视觉上有意义的结果。
一个名为“[从噪声到图像](https://lighthousesoftware.co.uk)”的新互动指南，旨在以易于理解、非技术性的方式解释扩散模型——许多AI图像生成技术的核心。创建者专注于这些模型*如何*根据提示词运作，而非复杂的训练细节。
该指南反响良好，评论者称赞其直观的解释和视觉化方法，特别是能够可视化逐步去噪的过程。许多人表达了希望有更深入、技术性的配套指南。
讨论集中在提示词工程的细微之处、词语顺序的影响，以及文本提示与模型“潜在空间”内生成图像之间的关系。用户还探讨了随机种子在生成变体中的作用，以及模型如何在这个空间中导航，根据提示词创建图像，本质上遵循从噪声到连贯图像的“速度场”。有人指出在移动设备上滚动时存在一个小小的可用性问题。
与一位747飞行员的对话引发了对职业发展本质的思考。这位飞行员精通他的技艺，但感叹经过数十年后，“没有进步”——他已经掌握了关于驾驶747的一切知识。这引起了作者（一位软件工程师）的共鸣，因为人工智能编码代理正在迅速改变他们的工作环境。
这些代理最初被用作高级搜索工具，现在通常在极少的人工干预下完成整个功能。虽然提高了生产力，但这种转变带来了一个挑战：与传统编码不同，依赖人工智能并不能培养对系统和问题解决的相同深度理解。作者发现，随着每个任务的完成，他们学到的东西越来越少，可能面临着与飞行员停滞不前的相似的未来。
尽管承认人工智能辅助的好处和必然性，作者强调了继续重视基础知识的重要性。提示代理很容易，但真正的成功依赖于*理解*问题领域——随着人工智能处理更多实现工作，这项技能正变得可选。他们建议有意识地练习手工编码，以保持和建立这种关键的专业知识。
## 编程与人工智能的变迁
这次Hacker News的讨论集中在人工智能，特别是大型语言模型（LLM）对编程的影响。许多评论员担心依赖Copilot等AI工具会削弱基础学习和技能发展。一些人回忆起编程需要通过艰苦学习和解决问题来获得深刻理解的时代——他们认为这个过程培养了真正的专业知识。
争论的焦点在于人工智能是更有用的助手，还是会侵蚀核心能力的捷径。一些人认为人工智能就像一个强大的搜索引擎，可以加速任务，但不一定能建立知识。另一些人则认为使用人工智能来处理繁琐的任务很有价值，从而让他们能够专注于更高层次的解决问题。
一个关键点是*生成*代码和*审查*AI生成的代码之间的区别；后者被认为教育意义较小。人们担心，如果未来一代人持续依赖人工智能为他们编写代码，他们可能会缺乏基础技能。最终，这场讨论凸显了效率与精通之间的紧张关系，以及软件开发者角色可能发生的变化——可能更多地转向监督和验证，而不是直接编码。
## AI辅助开发中认知债务的兴起
AI辅助编码极大地提高了开发速度，但也引入了一种隐藏的成本：**认知债务**。虽然交付的功能和DORA分数看起来很亮眼，但代码生成的速度超过了我们*理解*代码的能力。这种生产与理解的脱钩造成了一个危险的差距。
传统上，编写代码需要理解——摩擦会产生知识。现在，工程师生成代码的速度比他们批判性地审查或真正理解其影响的速度更快。这会导致不确定性，甚至对自己的工作也会产生不确定性，并最终表现为更长的恢复时间和更改失败——这些是掩盖日益严重问题的滞后指标。
当前的性能指标是为输出意味着理解的时代设计的，无法捕捉这种差距。代码审查成为瓶颈，经常为了速度而被牺牲，从而加剧了问题。这并非因为*做*得太多而导致的倦怠，而是因为一种脱节——生产却没有真正理解结果。
最终，组织面临失去关键的内隐知识的风险，创建出没有人完全理解系统如何运作的系统。这会导致脆弱的系统、昂贵的调试以及经验丰富的架构师人才管道的减少。核心问题在于？我们正在优化可衡量的速度，而忽略了不可衡量——并且日益关键的——对理解的需求。
这个Hacker News讨论围绕一个新发布的库，可能用于检索增强生成（RAG）系统。初步反应不一。一些人承认该项目存在（17个版本，315+次安装），而另一些人则强烈批评其“生产就绪”的说法，理由是提交历史混乱，并且在处理简单的PDF文件时性能不佳。
一个关键的争论点是分块算法——该库如何将文档分解为LLM处理的块。用户要求详细说明“结构化”、“固定”和“混合”方法。一位评论员对*任何*分块表示怀疑，提倡使用整个文档，并依赖LLM来总结检索相关性。人们担心仅仅依赖孤立的块会丢失关键上下文。最终，用户质疑该项目声明的能力的有效性，并要求验证。
## Woxi：一个快速的 Wolfram 语言解释器
Woxi 是一个使用 Rust 构建的新的 Wolfram 语言解释器，专为 CLI 脚本和 Jupyter Notebook 设计。它的目标是实现 Wolfram 语言的一个重要子集，通过消除内核启动和许可开销，提供比 WolframScript 更快的替代方案。
目前，Woxi 拥有完整的 Jupyter Notebook 支持，包括图形，以及不断增长的已实现函数库（跟踪在 `functions.csv` 中）。安装过程简单，克隆 GitHub 仓库后使用 Rust 的 `cargo` 即可。
用户可以通过命令行直接执行代码 (`woxi eval '...'`) 或运行脚本 (`woxi run script.wls`)。还提供了一个 Jupyter 内核，用于无缝的笔记本集成，以及一个独立的基于浏览器的 JupyterLite 实例。
Woxi 优先考虑与 WolframScript 的兼容性，要求两个解释器都通过所有测试。鼓励通过 Pull Request 贡献代码——提供了一个全面的测试套件用于开发和验证。
## Woxi：Mathematica 的 Rust 重实现 - 摘要
Woxi 是一个新项目，旨在用 Rust 重现 Wolfram Mathematica 的功能。开发者在 AI 的协助下取得了显著进展，已经实现了超过 5000 个测试，并支持许多核心 Mathematica 函数。
一个关键的架构讨论围绕着最佳实现方法。评论者建议采用一个小型核心解释器，并通过 Woxi 语言本身（woxilang）中的术语改写规则来构建功能，而不是直接在 Rust 中实现。 这种方法被认为可以提供更大的灵活性、可维护性，并允许更广泛的贡献，因为只需要 woxilang 知识。
人们对该项目的长期可行性和潜在版权问题表示担忧，考虑到 Mathematica 的专有性质。 然而，法律先例表明，干净房间实现不一定构成侵权。 该项目采用 AGPL-3.0 许可，可能旨在阻止 Wolfram 直接重用。 Woxi 具有潜在优势，例如更快的启动速度、通过 WASM 进行嵌入，以及为无法访问 Mathematica 的用户提供非专有替代方案。
无书签
No Bookmarks
20 小时前
无书签 | nik.art 跳至主要内容 本网站使用cookies来改善您的体验。我们将假定您对此表示同意，但您可以选择退出。接受 拒绝 了解更多 隐私与Cookie政策
这个Hacker News讨论围绕着书签的习惯——无论是数字链接还是实体页面——以及人们如何（或未能）重新访问它们。 许多评论者承认他们保存了很少返回的链接，其中一人认为用户界面本身会助长囤积行为。 其他人发现质疑保存的必要性更有效，而是依赖谷歌或记忆。
对话扩展到更广泛的记忆习惯。 一些人回忆起在没有GPS的情况下记住路线，而另一些人则讨论了记住书中的页码或使用独特的书签。 一个共同的主题是在现代、信息饱和的世界中难以保留细节，一位评论员将其归因于“注意力缺陷多动症的金鱼记忆”。
最终，这场讨论突出了不同的信息保留方法——从主动记忆和依赖物理线索，到接受数字工具的便利性，并放弃记住一切的需要。