24小时热榜

我一直称 eforge 为一种自主构建系统。传统的构建系统将源代码转换为工件，而 eforge 则将规范转换为源代码，然后验证其输出。 我构建它是因为我厌倦了将编排逻辑保存在脑海中——为盲审启动一个单独的会话，切换回实施会话以评估结果，决定接下来构建什么。我为各个部分开发了插件，但序列化的过程仍然由我来负责。我想要一个能够处理完整循环的工具，并且这个工具在不同项目中都能通用，而不是硬编码到特定的代码库中。 你只需提供一个规范——一个提示、一个计划文件或一个产品需求文档（PRD）——然后 eforge 会根据你的代码库评估复杂性，选择一个工作流（简单的更改走快速路径，复杂的则分解为子计划的依赖图），在隔离的 git 工作树中构建、审查和验证——这一切都无需监督。 我实际使用它的方式是：我在 Claude Code 中互动式地规划一个功能，然后运行 `/eforge:build`。插件会获取计划，将其排入队列，然后一个守护进程接管。eforge 从队列中提取计划，理解它们之间的依赖关系，尽可能并行执行，并按拓扑顺序合并。排队的工作在执行前会重新评估，以便考虑到早期构建的更改，而不是盲目地应用于已经变化的代码库。我在构建完成后检查结果——一个网络监控仪表板实时跟踪进度、成本和令牌使用情况。eforge 就是这样构建自己的。 每个构建阶段都有自己的代理——规划者、构建者、审查者、评估者和修复者。审查者在一个全新的上下文中运行，对代码的编写方式没有任何了解。Anthropic 的工程团队独立得出了相同的模式——他们的发现是：单独的代理会批准自己的工作；对抗性评估显著提高了质量。然后，评估者会应用每个块的裁决，接受严格的改进，同时拒绝任何改变意图的内容。

假设一款人工智能机器人，配备了高度耐用的身体（比如它是由钛制成的），明天真的获得了意识并具备了情感，那么它是否应该被赋予人权？