最新

我想分享一个我最初为 OpenClaw 制作的解决方案，它有助于控制你的 AI 代理在无需影响其能力的情况下可以访问的内容。我希望它对你有所帮助。 基本上，该解决方案让你可以在安全边界内自由地试验你的代理。 它是有意设计的确定性系统（不包含任何 AI 层），这意味着该解决方案遵循清晰且已定义的规则，以最大限度地提高安全性/可靠性和可预测性。 这些规则经过了大量测试，用于检测提示注入尝试和其他安全案例（在文档中详细说明）。 所有内容都位于本地，并存储在你的计算机上，包括文档站点。 它为你提供了一个控制面板，用于监控和控制边界。当边界即将被突破时，你会收到一个批准请求，让你看到你的 openclaw 试图做什么。 它还（目前）支持 Tailscale，因此你可以连接你的 Tailscale IP 地址并在手机上接收所有内容，并且你可以正常聊天、批准或拒绝请求。它允许你通过你的 tailscale IP 地址（建议使用私有 IP 地址）从任何地方访问控制面板。目前仅支持 Telegram 频道。 目前仅支持 Linux 操作系统以及 Opencode Claude Code & OpenClaw 运行器。 开始所需的步骤在自述文件中进行了说明，其中还包括快速演示/展示图片，以便你可以了解它的外观。 我很乐意听取大家的反馈，特别是针对提示注入的测试，以了解它如何处理。如有任何问题，请随时在 GitHub 上开一个工单，我会尽力修复它们。 链接在这里：[https://github.com/steadeepanda/agent-ruler/](https://github.com/steadeepanda/agent-ruler/) 感谢你的阅读。我很乐意与你讨论。

我将我的军官分为四类：聪明的、懒惰的、勤奋的、愚蠢的。每个军官至少具备这四种特质中的两种。 那些既聪明又勤奋的人适合担任最高的参谋职位。愚蠢又懒惰的人也能被利用。 然而，那些聪明又懒惰的人适合担任最高的指挥官；他们有处理各种情况的性格和神经。 但那些愚蠢又勤奋的人是个威胁，必须立即清除！ ——库尔特·冯·哈默斯坦-埃奎德 起初，我对我的新编码伙伴的惊人速度感到兴奋。和这个智能体聊天感觉就像和真人交谈一样，这让我有点迷失了方向，忘记了许多软件开发的理性规则。经过几次重构和许多经验教训后，我在Hacker News上找到了共鸣，那里的人们批评着我最初如此热衷的东西。 我有一个非常勤奋的伙伴，速度极快，但却毫无头脑，也毫无知觉。 我是哈默斯坦告诉我们要避免的那种人吗，还是我的智能体（或者更糟的是，是我们两者的结合）？ 想象一下，一个勤奋又愚蠢的人和一个人工智能智能体的组合。

以色列8200部队是一个APT组织。 伊朗的军队旗下大约有4个APT组织。 为什么美国国家安全局（NSA）没有被归类为APT组织？ APT定义：APT是指由国家支持、有组织且隐蔽的攻击组织。 美国国家安全局符合这个定义。 有人能解释一下吗？ 仅仅是政治原因吗？

我构建了一个开源代码库模板，为 AI 辅助软件开发带来结构，从编码前的阶段开始：目标、用户故事、需求、架构决策。 它围绕 Claude Code 设计，但其理念与工具无关。我从事计算机科学研究和全栈软件工程师 25 年，主要在初创公司工作。我一直在个人项目中使用这种方法，后来，当我决定将其打包成一个脚手架以便更容易复用时，我认为它可能对其他人也有用。我将其发布在 Apache 2.0 协议下，欢迎 fork 并将其变成你自己的。 你可以轻松试用它：按照 README 中的说明开始使用。 它解决的问题： AI 编码助手非常擅长编写代码，但当它们对要构建什么以及为什么有清晰的上下文时，它们的工作效果会更好。大多数项目直接跳到实现阶段。这个脚手架为编码前的阶段提供了一个结构化的工作流程，并组织了输出，以便助手可以在不同会话中高效地浏览它。 它是如何工作的： 所有内容都与源代码一起存在于代码库中。AI 指导分为三层，每一层都针对上下文窗口的使用进行了优化： 1. 指令文件 (CLAUDE.md, CLAUDE.<phase>.md)：始终加载，保持较小。它们按层次结构组织，描述代码库结构，维护工件索引，并定义跨阶段规则，如可追溯性不变式。 2. 技能 (.claude/skills/SDLC-*)：按需加载。每个 SDLC 活动的逐步过程：获取需求、差距分析、起草架构、分解为组件、规划任务、实现。 3. 项目工件：结构化的 markdown 文件，随着工作的进展而积累：利益相关者、目标、用户故事、需求、假设、约束、决策、架构、数据模型、API 设计、任务跟踪。通过索引选择性地访问。 这种分离很重要，因为指令文件永久保留在上下文窗口中，并且必须保持精简，技能可以详细说明，因为它们仅在被调用时加载，而工件会随着项目的扩大而扩展，但通过索引表而不是全文阅读来导航。 关键设计选择： * 上下文窗口效率：工件集合使用 markdown 索引表（单行描述和触发条件），以便助手可以找到它需要的内容，而无需阅读所有内容。 * 决策捕获：在 AI 推理和人工反馈期间做出的决策被保存为结构化工件，以便它们可以被审查、追溯并在不同会话中一致地应用。 * 瀑布式流程：具有定义输出的顺序阶段。对于人类团队来说很乏味，但 AI 助手并不介意这种开销，并且显式结构可以防止不受约束的“直接开始编码”的失败模式。 我如何使用它： 简短、专注的会话。每个会话调用一个技能，产生其输出，然后结束。知识组织意味着下一个会话在不丢失上下文的情况下继续进行。我发现技能之间的自由形式提示通常表明工作流程缺少一部分。 当前的局限性： 我还没有找到一种好的方法来集成 Figma MCP，以便将现有的 UI/UX 设计导入工作流程。欢迎提出建议。 非常欢迎反馈、批评和贡献！