最新

中国阻止外国收购人工智能初创公司Manus [了解更多信息](https://www.reuters.com/world/asia-pacific/china-blocks-foreign-acquisition-ai-startup-manus-2026-04-27) [点击这里查看相关报道](https://www.bbc.com/news/articles/cj0v0gr2yz7o)

在设计这个电子表格工具时，我意识到我从来没有考虑过键位绑定。这一切都自然而然地来自于 Vim。正常模式/插入模式/可视模式，hjkl 导航，dd/yy/p，:w，:q。习惯的肌肉记忆依然有效。 它支持 CSV/TSV 的导入和导出，以及一种原生的 .cell 格式，可以保留公式。公式引擎支持 SUM、AVERAGE、COUNT、MIN、MAX 和带范围引用的 IF。 代码库是一个 Cargo 工作区：一个纯粹的 cell-sheet-core 库（没有 TUI 依赖）和一个基于 ratatui 的 cell-sheet-tui crate。虽然还处于早期阶段，但已经可以使用。 要尝试它： cargo install cell-sheet-tui 任何反馈都非常感谢！

嗨，HN， 我已经在这个项目上工作了一段时间，决定何时停止并不容易，无论是信息的呈现方式还是何时停止添加条目。这个项目并不是一个博客，而是一个不断增长的参考资料。 链接： [https://thehardparts.dev](https://thehardparts.dev) 目前我创建了四个主要部分： - 失败模式：项目出错的方式 - 警示信号：值得认真对待的早期信号 - 技术决策：常见和不常见的艰难选择权衡 - 行动手册：针对重复出现情况的指导方法 我还专注于在它们之间建立联系，以展示许多事物之间的关联：警示信号通常会在失败模式之前出现，而失败模式可能与被迫决策相关联，等等。 以下是一些条目的示例，以便让你了解内容： - 看不见的截止日期：一个在社会上存在但不够明确以便诚实管理的日期 - 每个人都问同一个人：当一个人变成默认的真相来源时 - 建立实用的回滚策略：如何构建一个可靠的回滚策略 目前在这四个部分中共有151个条目。 我很想知道你对内容、格式和分组的看法。

在这里的一些评论线程中，有几位分享了有趣的想法和模式，足以让我相信，所有对马达工程感兴趣的人都在开发某种软件“黑工厂”。<p>我们有OpenAI的Symphony[1]、StrongDM的Factory[2]、Yegge的GasTown[3]，还有可能有我遗漏的一些其他项目。<p>所以我很好奇，你们在做什么？你们学到了什么？什么是有效的，什么又是失败的？你们认为接下来会发生什么？<p>我先来分享。让我获得有趣结果的第一件事是，在可能的情况下，为模型提供一个真实的基准或参考，以便进行迭代：例如，UI工作的截图或模型，逻辑的API合同和单元/集成测试。这就是我们都熟知并喜爱的Ralph Loop——一个反馈循环。<p>第二个（显而易见，我知道）是将规划和实施分开。<p>接下来是其他模型的评审和迭代循环，取得了可观的成果。然而，实施代理往往会通过将事情推迟到无尽的未来或声称实际上重要的反馈超出了范围而逃避责任。又一个反馈循环。我发现将这些评审转化为“硬性关卡”会带来一系列问题，因为评审代理总会找到一些细枝末节的问题，使得这种迭代实施方法变成近乎无限的循环。<p>将这些评审与代码一起提交计划，导致了一个有趣的意外：评审代理自发且意外地关注这些内容，并通过比较计划和实施大幅改善了他们的反馈（这本该是显而易见的，你可以想象当GitHub Copilot第一次提供有用反馈而不是通常的拼写错误挑剔时，我的惊讶）。<p>然后这里的一条评论让我想到了一个对抗性的绿色团队/红色团队流程。<p>第一个代理根据我的初步计划创建一个规范（基于StrongDM的NLSpec），并进行评审，包括详细的API。<p>红色团队代理根据这些规范编写单元和集成测试，并进行评审。<p>然后，一个绿色团队代理获得这些相同的规范和API，实施实际的功能或修复，并在没有任何测试访问权限的情况下进行迭代，只知道哪些测试失败以及它们测试的内容。这防止了它对测试的操控。<p>最后，一旦测试通过，评审代理会根据规范对实施进行评审。<p>这个流程很不错。它允许混合和匹配模型、思维层次和提供者。但绿色团队和红色团队有时会偏离初始规范和API，有时是有正当理由的。<p>因此，引入了另一个代理来评估这些偏差，并在它们是有效的改进时，从规范生成点重新启动流程，结合新的见解。又一个反馈循环。<p>最后，将日志、OTel跟踪和堆栈跟踪整合到流程中。这些代理似乎在筛选这些信息方面表现得非常出色，端到端的可观察性显著改善了结果。同样，又是一个反馈循环。<p>这就是我目前的分享。期待看到其他人对此的分享！

Forkle（forkle.co.uk）是一款每日文字游戏，两个主题相关的填字游戏同时占据同一个网格。每个方块包含两个字母——一个属于每个谜题——以对角线的颜色分割显示。在两个谜题交叉的地方，某些方块共享相同的字母，使你能够同时进入两个填字游戏。 这个机制有两个层面：共享的网格和相互关联的主题。每天的两个填字游戏围绕一个中心思想进行主题配对。今天的谜题是“同一个家，不同的王国”——同一个家，同样的人类，却是完全不同的世界。一个填字游戏是狗的世界，另一个是猫的世界。这些主题被选择为相关但又各自独立，这在连接的瞬间带来了额外的满足感。 将两个填字游戏强行放入一个物理空间的限制，实际上创造了非常有趣的解题决策——有时两个谜题相互帮助，有时则相互对抗。 这个游戏是我在几个月内独立开发的，使用了React、Python、Supabase、Fly.io和Resend。预加载了三个月的每日谜题。两周前正式上线。 欢迎任何愿意尝试的人提供反馈。