最新

我们从2006年10月以来每天收集了前三条HN（Hacker News）故事（总计约21,000条），对这些故事进行了主题聚类，并可视化了主题随时间的变化情况。<p>您可以放大查看任何时间段——一些模式出人意料地清晰（例如，人工智能超越创业文化成为HN的热门话题，加密货币的兴起与衰落，以及因COVID疫情导致的远程工作的激增）。<p>欢迎随时询问有关方法论的问题。

这个项目是什么 这是一个用于结构化处理复杂目录中的Markdown文件（规范）的Go工具，详细信息可在<a href="https://spec-schema.org" rel="nofollow">https://spec-schema.org</a>找到。该工具主要有两个任务： - 验证一组Markdown文件； - 与Markdown文件进行交互（查询、添加、更新、删除）。 验证可以由开发人员（包括在持续集成中）和代理进行。同时，查询和修改Markdown文件的命令（查询、添加、更新、删除）主要是为代理设计的（因为开发人员通过代码编辑器进行这些操作更为方便）。 这个项目解决了什么问题 主要解决三个问题： - 担心代理会破坏规范的结构完整性； - 能够维护由Markdown文件组成的结构复杂的规范； - 代理需要在上下文窗口中加载过多数据（读取整个规范）。 它是如何工作的 该工具的大致使用场景如下： - 你使用一个YAML文件初始化规范架构，按照<a href="https://spec-schema.org/" rel="nofollow">https://spec-schema.org/</a>的说明。这个架构描述了Markdown文件目录的结构以及Markdown文件本身的结构。这个阶段当然可以由代理完成； - 在与代理的新会话中，你只需告诉它运行`spec-cli help`：通过这个命令，它会获得一个适合代理使用的规范架构投影，然后进行操作； - 现在代理可以使用spec-cli来验证、更新和查询规范； - 规范仍然方便开发人员阅读，因为它与项目位于同一位置，并且具有开发人员定义的结构。 这个项目不是 这不是一个像spec-kit、openspec、spec-kitty等的规范驱动开发框架。它仅仅是一个用于结构化处理复杂Markdown文件目录的工具。 未来计划 目前我正在一个真实项目上测试该工具。特别是，该工具需要支持并发工作（例如，避免同时添加的Markdown文件获得相同的ID）和批量操作。 感谢您的阅读！

我在机器学习软件领域工作了四年，期间我遇到了一个反复出现的问题：我总是问自己，“我为什么要这样写这个函数？”或者“这个代码块为什么在这里？” 我尝试使用Obsidian和其他笔记应用来整理我的思路，但说实话，为自己写文档总是感觉像是一项繁琐的工作。文档总是让人觉得是为“别人”准备的。 于是，我决定构建一个VS Code扩展，直接将我的推理和上下文记忆与代码片段、标签等链接在一起。我甚至添加了一个优先级任务列表，这样我就能准确知道第二天待办的事情。 结果是什么？我从来没有使用它。 几个月后，我感到失望。我觉得自己在一件连我自己都觉得没用的事情上浪费了时间。 然后，智能代理出现了。 与AI代理的合作让我开阔了视野，但我遇到了一个瓶颈：“冷启动”问题。每次新会话都需要我从头开始解释一切。我尝试了MEMORIES.md、AGENTS.md和Claude的项目规则。讽刺的是，冷启动的改善并没有如预期那样明显。一些基准测试甚至显示，当被迫解析过多静态技能文件时，代理的表现反而更糟，而其他测试仅显示出边际10%的改善。 出于好奇，我决定实现一个本地的MCP，以便我的代理能够自主使用Neurotrace。 结果令人震惊。我没想到代理们真的会使用这个工具，但他们确实在使用。我还没有正式的基准测试，但我可以自信地说，冷启动的问题大大减少了。由于我使用来自不同提供商的不同代理，现在“下一个”代理确切知道我们昨天停在哪里了。他们决定保存哪些上下文记忆，而且做得相当不错。我的工作流程显著改善。 我很想听听你对代理记忆的看法，或者你是否找到更好的方法来处理上下文交接。 祝好， Irwing Castro (CastleOneX) 你可以在以下市场找到它： VS Code市场: [https://marketplace.visualstudio.com/items?itemName=BlackIronTechnologies.neurotrace](https://marketplace.visualstudio.com/items?itemName=BlackIronTechnologies.neurotrace) Open VSX: [https://open-vsx.org/extension/BlackIronTechnologies/neurotrace](https://open-vsx.org/extension/BlackIronTechnologies/neurotrace)

我对这种炒作曾经翻了个白眼，但实际上，<i>阅读</i>这方面的内容和<i>体验</i>它是完全不同的。如果你有任何旧的代码库，试试看，你可能会感到惊讶。 我不确定对于复杂的遗留企业系统，长期的“*90% 生产力*”的说法是否可信，但对于模板、库、构建工具和重构来说，收益是巨大的。那些耗时且令人紧张的工作大部分都得到了处理。 一开始你会像鹰一样仔细检查每一个差异，期待它会破坏东西，但老实说，很快你会发现大多数情况下这并不是必要的。你只需保持IDE开启，将“分析代码”的输出反馈给它。在Java中，告诉它“<i>添加checkstyle，运行mvn verify并修复</i>”的效果很好，你甚至可以去喝杯咖啡，而不是与linter警告作斗争。 理论上，剩下的只是<i>逻辑</i>和<i>想法</i>。当架构真正变得复杂时，我们将看看这一点是否成立。但目前，让它分支、创建模板并编写简单的测试，同时你只需在规格上进行迭代，效果出奇地好。只有在写下规格用普通英语太麻烦时，你才会编写源代码。 这提出了一个真正的问题：如果你的竞争对手Y刚刚解雇了90%的开发人员以节省成本，你会盲目跟随吗？还是会保留你的团队，利用这个巨大的杠杆，以一个远远更好的产品将Y彻底超越？