最新

TLDR: AI 智能体通过使用 grep/find/glob 等工具对代码库进行暴力搜索来理解代码。而这个 CLI 工具则查询你代码库依赖关系图的本地 SQLite 数据库，从而为智能体提供准确的上下文信息，使其在第一次尝试时就能制定出更好的方案。 过去 6 个月里，我一直在用 Claude Code 进行工作，感觉很棒。我的工作流程非常典型：启动 Claude Code > 在计划模式下开始规划我的功能 > 实现。然后，我只需要观察工作进展，偶尔在它偏离轨道时进行引导（这种情况并不常发生）。 但由于 Claude Code 存在“失忆症”，而且你只能在 CLAUDE.md 文件中放入有限的内容，它总是会先通过暴力搜索代码库来理解它。通常，它会先选择一个入口点，然后向上追溯。 因此，我最终构建了这个简单的 CLI 工具，旨在供你的 AI 智能体使用，你可以将其放入任何项目中（只要你的语言有 SCIP 索引器）。 它使用 SCIP 对你的代码库进行索引，然后 CLI 将其转换为 SQLite 数据库。所有命令都只是对查询的封装，你也可以直接查询数据库。SCIP 实际上并不适用于文档和通用文本文件，我在 CLI 中为此添加了一个索引器（这个索引器有点不稳定，是我最近添加的）。 设置方法： 1. 在你的系统中安装 CLI。 2. 为你的语言安装 SCIP 索引器。 开始在项目中使用它： 1. 在你的智能体记忆文件中添加代码片段，告诉它在进行代码探索时优先使用 dora 而不是其他工具。 2. 添加技能文件以获取更详细的用法说明。 3. 添加钩子，在会话开始和每轮结束时在后台运行索引器。 我一直在用它进行主要工作，并根据我发现的改进空间进行调整。我的想法是保持它尽可能简洁。我能够第一次就获得不错的方案。 了解更多： 网站 - [https://dora-cli.dev/](https://dora-cli.dev/) GitHub - [https://github.com/butttons/dora](https://github.com/butttons/dora)

嘿，Hacker News！我是 FlutterJS 的开发者。 问题：Flutter Web 擅长构建应用，但对于网站来说却很糟糕。它将所有内容渲染到 Canvas/WASM，这意味着： * 2-5 MB 的打包体积（在移动端很慢） * 零 SEO——谷歌无法索引 Canvas 像素 * 糟糕的无障碍性（屏幕阅读器没有语义 HTML） * 3-8 秒的初始加载时间 如果你曾经尝试用 Flutter Web 构建营销网站或博客，你肯定会遇到这个问题。 解决方案：FlutterJS 将你的 Flutter/Dart 代码编译成语义 HTML + CSS + JavaScript，而不是 Canvas。使用你已经熟悉的 Flutter 语法，但输出结果是： * ~50-100 KB 的打包体积（缩小 50 倍） * 完全的 SEO 支持（真实的 HTML 元素） * 首次渲染时间小于 1 秒 * 默认可访问 工作原理： 1. 你编写普通的 Flutter/Dart 代码 2. 我们的 Dart CLI 分析你的 AST 并生成中间表示（IR） 3. IR 被转译为 JavaScript，并附带一个轻量级的运行时 4. 输出是搜索引擎可以索引的语义 HTML 当前状态：Beta（v0.9.x）。我们支持最常见的 Material 组件（Scaffold、AppBar、Text、Button、Row、Column、StatefulWidget 等）。动画支持和完整的 Material 3 正在开发中。 已知限制： * 并非所有 Flutter 组件都已实现（请参阅 README 中的兼容性矩阵） * 方法拆分目前需要用 lambda 表达式包装 * 暂不支持复杂的动画 * 这最适合内容丰富的网站，而不是图形密集型应用 我为什么构建它：我一直遇到喜欢 Flutter 的 DX 但需要他们的网站在谷歌上排名的客户。Flutter Web 无法做到这一点。我想要两全其美。 我很乐意听取你的反馈，特别是： * 你是否在使用 Flutter Web 时遇到了 SEO 问题？ * 你的用例需要哪些组件？ * 你对这种方法有什么担忧吗？ 欢迎提问关于架构、性能主张或路线图的问题！

我是一名大二学生，正在开发 ReTraced——一个分布式作业调度器，它将重试行为视为一等数据，而不是将其隐藏在日志或配置标志中。 大多数调度器只会告诉你作业重试了 3 次。而 ReTraced 会告诉你： * 每次重试发生的时间（带时间戳） * 重试的原因（瞬时故障 vs 永久故障） * 是自动触发还是手动触发？ * 完整的 DLQ（死信队列）之前的审计追踪 我构建这个项目是因为在压力测试时，我发现了一个退避计时错误，只有当我能将重试尝试作为结构化数据“看到”时才会显现。预期的指数延迟（5 秒 → 10 秒 → 20 秒），但实际的时间戳显示了大约 6 秒的平台期。这种可见性使调试变得非常简单。 *核心理念：* * 重试尝试存储为可查询的记录（不仅仅是计数） * 每个作业的重试策略（固定、线性、指数 + 抖动） * DLQ 是一等公民，具有完整的失败上下文 * 基于 Redis，至少一次语义 *当前状态：* v1.0.0——核心模型稳定，可用于内部工具和实验。目标是在一年内实现可自托管的生产就绪。 我正在积极寻求关于以下方面的反馈： * DLQ 重放策略 * Redis 协调模式 vs Postgres * 我遗漏的重试策略边缘情况 GitHub: [https://github.com/Anshikakalpana/ReTraced](https://github.com/Anshikakalpana/ReTraced) 文档: [https://re-trace-five.vercel.app/](https://re-trace-five.vercel.app/) 欢迎您的想法，特别是来自那些在生产环境中构建或操作过调度器的人。

我一直在日常工作中尝试使用 AI 编码助手，并遇到了一个反复出现的问题：我一直在重复相同的工程原则。<p>比如验证输入、谨慎使用新依赖项，或者遵守某些产品约束。通常的解决方案是提示或规则。<p>在使用这两种方法一段时间后，我感觉都不太合适。 - 提示在每次任务后都会消失。 - 规则仅在狭窄的上下文中触发，通常与特定文件或模式相关。 - 有些原则是个人偏好，我不想在项目层面强制执行。 - 另一些根本不是“规则”，而是关于产品约束和过去权衡的知识。<p>这促使我尝试为 AI 助手创建一个单独的“记忆”层。不是聊天记录，而是小的、原子的知识片段：决策、约束和可以根据需要检索的重复出现的原则。<p>在开始认真使用它之后，一些事情变得显而易见： - 模糊的记忆会导致模糊的行为 - 冗长的记忆会污染上下文 - 重复的条目会使检索效果变差 - 许多问题只有在您每天真正依赖助手时才会出现<p>当上下文正确时，AI 在执行方面表现出色。但是，决定应该记住什么、应该拒绝什么，以及何时可预测性比聪明才智更重要，仍然需要人为判断。<p>很好奇其他人是如何处理这个问题的。您在使用 AI 编码助手时，主要依赖提示、规则，还是某种形式的持久知识？