最新

来自官方Zig源的包管理器，即“zig fetch”，让我感到非常烦恼。我讨厌必须先从一个URL获取项目，然后将代码复制到build.zig中，接着又没有智能提示，只能猜测我需要写什么，不需要写什么。这真是一团糟。 所以我解决了这个问题，构建了自己的包管理器zeP。 https://github.com/XerWoho/zeP 这是一个简单的包管理器和Zig版本管理器。 那么我学到了什么呢？首先，构建一个包管理器需要进行大量的规划。目前我仍处于预发布阶段，这里会有很多重大变化，但我已经做出的许多重大改动让我意识到，在承诺某件事情之前，我必须先停止编程，开始思考。 例如，我的可执行文件命名为zeP，这对Linux用户来说是个问题。他们总是必须输入带有大写P的zeP，这实在令人烦恼。 在此之前，我在zeP中有一个Zig版本管理器，在安装Zig版本或切换版本后，会更改可执行文件的路径。也就是说，每次安装或切换时都会添加一个新路径。 ~/.zig-0.15.1/x86-windows/:~/.zig-0.13.0/x86-windows:~/.zig-.... 可以想象，经过一段时间后，PATH变量会变得多么臃肿，而且不仅如此，这完全没有用，因为我会检查路径是否在PATH变量中，如果在，我就不会再添加它。也就是说（以上面的例子为例），zig 0.13.0将永远不会再被使用，因为它被0.15.1所覆盖。为了解决这个问题，我使用了符号链接。只在主路径~/.local/bin内，zig会在安装和切换之间进行符号链接。 符号链接对我来说非常好，因为我发现了pnpm的工作原理。pnpm使用符号链接，减少了安装、延迟和文件大小，因为有一个主文件夹包含所有文件，并且这些文件在项目之间进行链接。但是，有一个问题。如果你卸载一个包，它会删除主文件夹中的包，这意味着所有可能安装了该包的其他项目将会有一个悬空的符号链接。 再次，解决方案很简单。一个manifest.json。在这里，我们存储所有包及其链接的项目。这个文件会检查链接的项目，如果该包没有链接的项目，才会删除该包；否则，它只会解除项目的链接。 不用说，我遇到了许多需要测试的问题，并且亲自使用zeP。只有通过使用我自己的产品，我才能确定其他人可能遇到的问题。但有些人也提供了反馈，之后我修复了一些问题。 zeP有自己定制的打印结构。它接收数据，然后通过清空整个屏幕再重新打印。这是为了让我可以显示进度条等内容。然而，有用户讨厌zeP会完全占用整个屏幕。因此，现在zeP只会清除自己的行，而不会影响其他内容。 构建一个包管理器不仅需要我这边的测试，还需要社区的反馈。

我们正在构建万亿参数的模型，并通过字符串连接将上下文嵌入其中。 我一直对“上下文工程”这个词感到困惑，因为它到处都是，但没有人明确说明它到底意味着什么。框架定义了工具循环，但却没有定义注入点。 这是一个关于上下文工程基础设施应如何构建的提议： - 可渲染的上下文组件（工具在用户界面和模型中的不同服务方式） - 可查询的对话（带有物化视图的事件流） - 响应式注入（基于对话状态触发的规则） - 注入队列（优先级、批处理、去重） - 可钩挂的架构 博客文章： [https://michaellivs.com/blog/context-engineering-open-call](https://michaellivs.com/blog/context-engineering-open-call) 代码库（早期设计阶段，寻找合作者）： [https://github.com/Michaelliv/context-engine](https://github.com/Michaelliv/context-engine) 希望能对这个方向获得反馈，特别是：规则应该如何表达 - 是领域特定语言（DSL）还是代码？现有框架的正确集成面是什么？

我一直在开发一个小工具，旨在减少在氛围编码工作流程中的提示摩擦。 实际上，很多迭代源于不够明确的提示：缺少约束、不清晰的范围、隐含的假设或混合的意图。这个工具将您想要构建的内容的粗略自然语言描述，重写为更明确、结构化的提示，提供更清晰的要求和背景，然后再发送给模型。 重点在于： - 使意图、约束和假设变得明确 - 减少提示的变动和微迭代 - 提高首次输出的质量，尤其是针对非技术构建者 它主要围绕氛围编码的用例（快速原型制作、AI辅助构建）设计，最适合与Lovable/Claude风格的工作流程配合使用，尽管在概念上它是模型无关的。 非常希望能得到技术反馈： - 提示规范化/重构是您认为有价值的内容吗？ - 您是通过系统提示、微调还是运行时提示转换来解决这个问题的？ - 在更复杂或长上下文的任务中，这个工具的效果如何？ 欢迎分享批评意见。