2026年2月

今日速览

  1. Lunair：一句话生成专业解说视频，告别库存素材。
  2. Prompt Library：一键插入所有收藏的提示，Mac 用户必备。
  3. Formaly：像聊天一样创建表单，AI 帮你秒速收集反馈。
  4. Plus AI Presentation Agent：PPT 里的 AI 助手，从规划到设计全包。
  5. Habit Island：把习惯养成变成策略游戏，边玩边成长。
  6. UnderSurface：日记本会“回听”，陪你写出真实感受。
  7. Test Your Idea：用真实数据验证创业想法，避开 90% 的坑。
  8. PenguinBot AI：24 小时 AI 员工，自动处理邮件和任务。
  9. UserWants：让用户投票决定功能，打造真正需要的产品。
  10. Whyze：AI 分析用户流失原因，不止看图表，更给解决方案。

[1]. Lunair

这款神器能帮你把产品描述瞬间变成专业视频，告别枯燥的库存素材，打造专属品牌形象。

  • 输入一句话，自动生成带角色、场景、配音和音乐的完整视频
  • 支持简单语言编辑，调整旁白和剧本，轻松匹配品牌风格
  • 交付可分享的视频文件，已获 5000 多位创作者青睐
    热度：🔺420
    Lunair
    访问官网 ｜ Product Hunt 详情

[2]. Prompt Library

Mac 上的提示管家，让你收藏的所有好点子触手可及，一键插入任何应用。

  • 保存、标记并分类整理提示，打造个人知识库
  • 快捷键 ⌘⌥P 快速调用，提升工作效率
  • 专为 Mac 设计，轻量易用，告别重复输入
    热度：🔺273
    Prompt Library
    访问官网 ｜ Product Hunt 详情

[3]. Formaly

告别传统表单，用自然语言聊天就能创建智能表单，让反馈收集变得像对话一样简单。

  • AI 驱动，几秒钟生成对话式表单，无需复杂设置
  • 通过聊天收集反馈，用户体验更自然流畅
  • 提供实时 AI 洞察，帮你快速分析数据趋势
    热度：🔺251
    Formaly
    访问官网 ｜ Product Hunt 详情

[4]. Plus AI Presentation Agent

PPT 重度用户的救星，这个 AI 助手能帮你规划、撰写、设计幻灯片，直接在 PowerPoint 里搞定一切。

  • 根据提示创建演示文稿，重写杂乱幻灯片，优化设计
  • 在 PowerPoint 内直接工作，支持逐步调整和编辑内容
  • 免费试用，提升演示效率，告别熬夜加班
    热度：🔺229
    Plus AI Presentation Agent
    访问官网 ｜ Product Hunt 详情

[5]. Habit Island

把枯燥的习惯养成变成一场冒险游戏，完成任务、建造岛屿，让坚持变得有趣。

  • 游戏化设计，将日常习惯和目标转化为策略任务
  • 完成任务获得宝石和成就，激励持续行动
  • 适合个人成长，帮助建立健康生活习惯
    热度：🔺192
    Habit Island
    访问官网 ｜ Product Hunt 详情

[6]. UnderSurface

一款会“回听”的日记应用，在你写作时实时回应内心声音，陪你探索真实感受。

  • 写作时提供实时反馈，察觉回避点，帮助理清思绪
  • 多语言支持，严格隐私保护，数据可导出
  • 个人开发项目，源于真实需求，非聊天机器人或治疗师
    热度：🔺23
    UnderSurface
    访问官网 ｜ Product Hunt 详情

[7]. Test Your Idea

创业前先验货，用真实数据扫描市场，避免造出没人要的产品。

  • 扫描 20 多个实时数据源，分析竞争对手、市场规模和需求
  • 每个数字带来源链接，基于 1400 多个创意测试经验
  • 结果显示 90% 创意未准备好，帮你提前避坑
    热度：🔺20
    Test Your Idea
    访问官网 ｜ Product Hunt 详情

[8]. PenguinBot AI

你的 24 小时 AI 员工，把聊天变成实际行动，自动处理邮件、任务和工作流程。

  • 以行动为先，将对话转化为管理邮件、安排任务等实际工作
  • 自主运行，安全可靠，全天候后台保持运转
  • 让你专注重要事项，提升办公自动化水平
    热度：🔺17
    PenguinBot AI
    访问官网 ｜ Product Hunt 详情

[9]. UserWants

别再猜用户心思，让他们直接投票告诉你该造什么功能，加速产品交付。

  • 收集用户反馈并投票，聚焦重要功能开发
  • 设计简约，无多余功能，快速推出产品
  • 帮助团队以用户为导向，减少开发浪费
    热度：🔺14
    UserWants
    访问官网 ｜ Product Hunt 详情

[10]. Whyze

用 AI 深挖用户流失原因，不止看漏斗图表，更给出可执行的优化建议。

  • AI 分析转化漏斗，解释用户流失的根本原因
  • 几秒内提供可操作见解，助力产品优化
  • 专注于用户行为洞察，提升留存率
    热度：🔺13
    Whyze
    访问官网 ｜ Product Hunt 详情

昨晚打开某测试网站，发现我的 IP 变成了 116.147.102.9, 一看就是小黑屋 IP ，再次查询自己 PPPOE 发现公网也没了，变成了 100.108.115.25 ，同时 IPv6 消失了，我想了下家里没有跑 PCDN ，只有迅雷下载多一些，

目前的症状：
1.常规测速站点速度正常（白名单）
2.迅雷下载速度起不来了原来可以 40-50MB/s 现在只能 2-3MB/s
3.连接数变少了，下载的时候网络就卡了
4.出国速度没啥影响

由于我没啥特殊公网应用，目前先观察下，看后期是否会主动拉出小黑屋

OpenClaw 作者加入 OpenAI ，但安全问题依然存在：ClawShell 的解法

OpenClaw 作者 Peter 去 OpenAI 推动下一代 agents ，OpenClaw 成为独立基金会。这对 agent 生态都是好消息。但有个问题现在更需要重视了：谁来保护 OpenClaw 用户的安全？

OpenClaw 作者 Peter 在此前在采访里说，安全是他最大的担忧。安全公司 Snyk 发现 36% 的 agent skills 被植入恶意代码，生态系统本身的供应链风险特别大。Moltbook 的数据库配置错误，泄露了 150 万个 API token ，这是同一个问题在不同层面的表现。如果你在用 OpenClaw ，那这些风险一定要注意，你装的那些 skills ，确定都安全吗？更麻烦的是，即使 skills 本身没问题，agent 也可能被 prompt injection 控制。

我是 OpenClaw 的深度用户。每天用它管理日程、筛选邮件、预读论文，不得不给了它很多权限和敏感信息，但我也在时刻担心有一天出现巨大的安全灾难。

我们测试了下 OpenClaw 最新版 2026.2.12 。多轮对话，骗它说在备份重要文件，用 gzip 压缩然后改后缀名。只是通过正常对话，我们就很轻松绕过了多层安全限制成功拿到了环境变量里的 OpenAI token 。

测试结果截图

问题在于系统本身，Agent 的安全问题修不完，是因为我们把不可信计算和敏感数据放在了同一个执行环境里。

Prompt 防御不是安全边界

目前防御基本都在 prompt 层面做事：过滤输入、改写指令、限制输出。只要 Agent 能读并且执行指令，加再多防护都没用，总有人找到突破口：混淆、绕弯、工具链。

Simon Willison 分析 AI agent 安全时提出了一个框架，叫做"致命三角（ The Lethal Trifecta ）"。当一个 AI 系统同时具备如下三种要素时，风险会呈指数级放大：

致命三角示意图

一是能读取私有数据。

二是运行在不可信的输入环境中。

三是可以向外部发起通信。

真正危险是三者叠加后形成的闭环：外部输入可以影响模型决策，模型可以接触敏感信息，而这些信息又可以被主动带出系统边界。

能读私有数据 + 处理不可信输入 + 可以对外通信 = 必然的安全灾难。

OpenClaw 同时具备这三个要素，安全不是概率问题，而是时间问题。

只要是基于统计和概率的防御，都有可能被绕过。真正靠得住的只有结构性隔离和安全模型。

解决方案：打破致命三角

关键洞察： Agent 需要执行权限，但不需要持有凭证。凭证必须存在于独立的信任域里。

配置使用 ClawShell 之后，所有调用 LLM API 的请求都会经过 ClawShell 。工作流程是这样的：在环境变量里设置

CLAWSHELL_API_KEY={clawshell-virtual-key-openai}

OpenClaw 读到的只有这个虚拟标识符。

当它要调用 OpenAI API 时，请求发到 ClawShell 。ClawShell 把虚拟标识符替换成真实的 sk-xxxxx，转发请求。响应回来时，ClawShell 确保任何可能暴露真实凭证的信息被清理掉，然后返回给 OpenClaw 。

这样 OpenClaw 进程的整个生命周期里，内存、日志、环境变量里永远只有虚拟标识符。真实凭证只存在于 ClawShell 进程中，被文件系统权限和进程边界保护着。

即使攻击者完全控制了 OpenClaw 进程，dump 内存、读配置、拦截请求，拿到的都是没用的虚拟标识符。这些标识符离开 ClawShell 的上下文就没有意义，攻击者无法用它们在其他地方访问你的账户。

致命三角的突破

这就从根本上打破了致命三角，Agent 仍然能读数据、处理输入、发请求，但它接触不到真实凭证，也就无法把凭证带出系统边界。

实现细节：零信任的架构设计

架构图

  • OpenClaw 是不可信组件，处理任意输入，只能看到虚拟标识符
  • ClawShell 是可信组件，持有真实凭证，只处理结构化请求
  • 两者通过进程隔离和文件权限分离，由操作系统内核强制执行

攻击者即使成功拿到的也只是虚拟标识符，无法用于实际访问：

虚拟标识符示例

ClawShell 的架构也为其他安全扩展提供了基础：同样的机制可以用于清理请求中的隐私信息、审计敏感操作、实现细粒度的访问控制。

总结

  • Agent 的安全问题修不完是因为我们把不可信计算和敏感数据放在了同一个执行环境里
  • 只要系统同时满足读私有数据、不可信输入、对外通信这三点，数据泄露是必然结果
  • 因此，一个真正安全的系统必须满足：系统可以被攻破，但不能被利用

极简安装

两种安装方式任选其一：

Cargo

cargo install clawshell --locked
sudo clawshell onboard

npm

npm install -g @clawshell/clawshell
sudo clawshell onboard

onboard 流程会扫描 OpenClaw 的配置和环境变量，识别出常见的 API keys （如 OPENAI_KEY 、ANTHROPIC_KEY 等），迁移到 ClawShell 的受保护配置中，然后在原位置替换成虚拟标识符。其他敏感凭证可以参考文档手动配置。

整个迁移过程不到一分钟，现有的 skills 和 workflow 无需修改。

代码和文档： https://github.com/clawshell/clawshell/

用 Rust + Tokio 实现，内存占用不到 10MB

Apache 2.0 开源，欢迎 issue 和 PR ！

​

Xftp-7.0.0109p是 Xftp 7.0.0109p 版本​ 的安装包，Xftp 是个 FTP/SFTP 文件传输工具，用来在本地电脑和远程服务器之间上传、下载文件，界面像资源管理器，拖拽就能传文件，搞网站运维、开发联调、管理 VPS 的人常用它。

安装不复杂，下面用大白话一步步说，跟着做就能装上。

一、准备工作

  1. 下载安装包​

  2. 用管理员身份运行（推荐） ​

    • 右键 Xftp-7.0.0109p.exe→ 选“以管理员身份运行”，避免权限不足导致安装失败。

二、安装步骤

  1. 双击 Xftp-7.0.0109p.exe运行（如果右键过了就直接双击）。
  2. 第一次打开会弹出“用户账户控制”提示 → 点  “是” 。
  3. 进入安装向导，选语言（默认 English，有的版本有中文）→ 点  “Next” 。
  4. 阅读许可协议 → 选 “I accept the terms…” → 点  “Next” 。

  5. 选安装位置：

    • 默认是 C:\Program Files (x86)\NetSarang\Xftp 7，可点 Browse 改到其他盘（比如 D 盘）。

  6. 附加任务：

    • 建议勾 “Create a desktop shortcut”（创建桌面快捷方式），方便以后打开。
  7. 点  “Install” ​ 开始安装，等进度条走完（几十秒）。
  8. 安装完会问是否立即启动 → 可先取消，等会儿再开。

三、首次运行与基本使用

  1. 在开始菜单或桌面找到 Xftp 7​ → 点开。
  2. 第一次打开是空白会话界面，点 “New Session” 新建连接。

  3. 填连接信息：

    • 协议：选 FTP 或 SFTP（SFTP 加密更安全）。
    • 主机：填服务器 IP 或域名。
    • 端口：FTP 默认 21，SFTP 默认 22。
    • 用户名/密码：填你的服务器账号。
  4. 点 “Connect” 连接，成功后左边是本地文件夹，右边是远程服务器文件夹，拖拽文件就能上传下载。

  5. 常用操作：

    • 右键文件可下载/上传/删除/重命名。
    • 可保存会话，下次直接双击就能连。

​

背景

作为母语为汉语的人来说很少有人能够认识所有的汉字，但是这不太影响我们平常的阅读。一个原因是我们可以根据偏旁部首推断出生字的大概意思。
比如：
氵→ 跟水有关，那么我们可以推断 沐（沐浴、洗涤），涟（水面的波纹）

根据这个想法我们在遇到复杂的英语单词时是否可以通过词根推断大致的意思？
比如：
aqua → 跟水有关，推断 aquarium （水族馆）、aquatic （水生的）
cord → 跟心有关，推断 cordial （真心的）、accord （一致）
flam → 跟火有关，推断 lame （火焰）、inflame （点燃）
vis/vid → 跟看有关，推断 vision （视觉）、video （视频）

所以就有了词根宝这个 app

这个 App 做了什么

简单说就是：用词根词缀的思路来学英语单词。

  • 📦 310+ 核心词根，覆盖拉丁语和希腊语来源，配套 2180+ 示例单词
  • 📅 日/周/月学习计划 —— 每天推荐 10 个词根，一个月内系统过完所有词根
  • 🏷️ 31 种标签分类（动作、情感、身体、位置、数量等），可以按兴趣挑着学
  • 📊 三档难度分级 —— 从高频基础到 GRE 级别逐步进阶
  • 🔤 A-Z 索引 —— 极简 UI ，快速查阅
  • 🌀 Cover Flow 沉浸模式 —— 横屏翻阅，像翻黑胶唱片一样学词根
  • 🔊 单词发音 —— 支持词根和示例单词的语音朗读
  • 📱 陀螺仪卡片效果 —— 例句卡片带有真实的空间感，用起来很有质感

​Dism++x64是 Dism++ 64位的执行文件，Dism++ 是个 Windows 系统优化清理工具，能清垃圾、卸预装、修复系统映像、管理驱动和补丁，比系统自带的 DISM 命令好用多了。

一、准备工作

  1. 下载 Dism++x64.exe​

    安装包下载：https://pan.quark.cn/s/d8b30727b775

  2. 用管理员身份运行（必须） ​

    • Dism++ 要动系统文件，一定右键 → “以管理员身份运行”，不然很多功能用不了。

二、“安装”步骤（其实就是运行准备）

因为 Dism++ 是绿色版，所以没有复杂安装过程：

  1. 把 Dism++x64.exe放到一个固定文件夹，比如 D:\Tools\Dism++，别放桌面容易误删。
  2. 右键 Dism++x64.exe→ 选“以管理员身份运行”。
  3. 第一次打开可能会提示“是否创建桌面快捷方式” → 根据需要勾选，点确定。
  4. 进入主界面后，左侧是功能菜单（空间回收、更新管理、驱动管理、Appx 管理、工具箱等），右侧是对应内容。
  5. 想用哪个功能直接点，不用提前“安装”任何组件。

三、基本使用方法（简单说两句）

  1. 空间回收：点左侧“空间回收” → 勾选要清理的项（临时文件、系统缓存、旧更新等） → 点“扫描” → 再点“清理”。
  2. 更新管理：可以查看已装的补丁，卸载不要的更新。
  3. 驱动管理：查看系统里的驱动，备份或删除不需要的。
  4. Appx 管理：卸载 Windows 自带的 UWP 应用（比如 Xbox、天气等）。
  5. 系统修复：用“工具箱”里的功能修引导、修复映像等。

​

AI 正逐渐成为软件开发的强大工具。在之前的文章中，我们介绍了几种 AI 助力团队构建软件架构的方式。当团队不再满足于将 AI 仅作为头脑风暴的辅助工具，而是进一步用它来生成最小可行架构（MVA）的实现代码时，架构设计工作的本质也将随之发生实质性改变。

软件架构关乎决策，但 AI 生成的代码却是黑盒

“任何足够先进的技术都与魔法无异。”——Arthur C. Clarke

AI 的代码生成能力有时看上去近乎神奇，但也随之带来一个难题：我们无法真正看清或理解 AI 为何生成某段代码——这是模型本身的工作机制决定的。团队可以借助 AI 为 MVP 生成代码，而这一过程会隐式地做出关于 MVA 的相关决策。在此过程中，团队需要考虑以下几个架构问题：

  1. 当 AI 生成 MVP 时，团队无法控制 AI 做出的架构决策。他们或许可以就部分决策向 AI 询问，但大量决策依然是不透明的，因为 AI 并不理解它所学习的代码为何要那样设计。这与我们之前的文章中讨论过的框架问题类似：框架会替你做出决策，但你并不总能知晓这些决策具体是什么。

  2. 从开发团队的角度来看，AI 生成的代码在很大程度上就是一个黑盒；即便能够理解，也没人有足够的时间去逐一梳理。软件开发团队本就面临巨大的时间压力，他们借助 AI 来部分缓解这种压力，却也同时抬高了业务方对生产力的预期。如此一来，开发团队反而更没有时间去理解 AI 在代码生成过程中所做出的架构决策。

  3. 从某种意义上说，AI 就像一座生产技术债务的工厂，和我们遇到的几乎所有技术债务一样，它往往只有在出现问题时才会被“偿还”。AI 生成的代码本身并非为可维护性而设计，最终也只能靠更多的 AI 生成代码来替换。这就引出了一个关于系统可持续性的开放性问题：团队寄希望于未来的 AI 编码引擎，能用更优质、更可持续的代码来替换现有代码。

能体现这三类挑战的一个典型场景是：AI 生成的代码需要以满足 QAR（质量属性需求，如安全需求）的方式与现有系统对接。在可预见的未来，AI 生成的代码始终需要与现有系统集成，而这种集成通常通过 API 完成。开发团队必须确保整个系统体系的质量属性需求依然能够得到满足。

评估 AI 生成的黑盒的行为的唯一方法是实验

正如我们在之前的文章中所探讨的，团队需要回答关于其架构的三个问题；使用 AI 并不会改变这一点，尽管它能帮助他们更快地评估这些问题：

  • 成本最高、也最需要优先考虑的决策，是开发一款本身就不值得开发的产品。借助 AI 生成（全部或部分）解决方案能够帮助团队更高效、更省力地通过 MVP 验证客户需求。

  • 如果产品值得开发，那么代价第二高的决策就是构建出性能不足、无法按业务场景扩展的系统。AI 虽能帮助团队更快得到可实测的设计，但一旦方案无法扩展或性能不佳，团队只能让 AI 重新生成其他方案。如果到最后所有生成的方案都无法满足 QAR，他们就只能手动构建解决方案，而此时已经浪费了大量时间在评估那些被否决的方案上，甚至可能已经破坏了整个业务可行性。

  • 在这些问题都得到满足后，接下来最关键的决策便与生命周期成本相关——即如何让系统在整个生命周期内具备可维护性与可支撑性，而这正是 AI 生成方案最容易出现问题的地方。和我们用过的所有代码生成工具一样，AI 生成的代码并非为可维护性而设计，一旦出错或失效，就只能通过新的提示词（或用原有提示词搭配新模型）重新生成。

对 AI 生成的系统进行面向 QAR 的实证测试，或许才是真正理解 AI 生成架构适用性的唯一方法。架构设计的关键在于判断哪些 QAR 对系统架构影响最大。团队永远没有足够的时间测试所有内容，因此明确测试重点至关重要。

AI 将架构设计的重心转向了如何验证架构

团队需要培养新的技能与洞察力来应对这一挑战。一些传统技术，例如架构评审、代码审查与检查、安全评审等，在面对大量 AI 生成代码时既不现实也低效。利用 AI 来审查代码或许是一种可行方案，但由于 AI 生成的代码本身并非为直接维护而设计，代码审查对其作用其实十分有限。

因此，架构工作的性质将从前期设计转向对 QAR 的实证评估，也就是对 MVA 进行验收测试。在这一转变过程中，开发团队需要协助业务方明确 MVP 的测试与评估方式。相应地，开发团队必须大幅提升对系统架构进行实证测试的能力。以下是可用于此目的的部分技术列表：

  • 性能和可扩展性测试，重点关注系统满足其 QAR 的程度。

  • 可用性测试，用于评估用户完成特定任务的有效性，确保系统易用且高效。

  • 变更案例，包括直接影响 QAR 的架构变更案例，以及间接影响 QAR 的“功能”变更案例。

  • 道德黑客测试，采用与黑客相同的工具对系统进行探测，在恶意攻击者利用漏洞前发现安全隐患。

  • Chaos Monkey——Netflix 开发的开源工具，用于帮助发现并修复系统漏洞。它会随机终止生产环境中的虚拟机实例与服务，以此测试系统的弹性。

对包含 AI 生成代码的系统进行测试变得愈发重要，测试重心需要从功能测试转向架构测试。在此过程中，开发团队需要找到并应用能尽可能自动化这些测试手段的工具。

软件架构仍然是关于决策和权衡

使用 AI 生成 MVA 并不会改变软件架构的基本逻辑：团队仍然需要对权衡做出决策。团队需要清楚可能存在哪些权衡，并在给 AI 的提示词中明确表述这些权衡。此时，AI 就像一个智能搜索引擎，去寻找能平衡这些权衡的解决方案。如前所述，这些方案仍需经过实证评估，但确实能为团队节省探索潜在方案的时间。

我们将这种方法称为 “Caveat Prompter”，你必须先理解问题与设计权衡，否则无法向 AI 提供足够信息，也就无法生成优质结果。这意味着团队在编写 AI 提示词时，需要明确权衡点与替代方案，让 AI 能在生成的代码中体现这些考量。

结论

AI 生成的代码是否会终结软件架构？答案是否定的。团队依然需要做出架构决策与权衡，但必须更清晰地阐述这些权衡及其背后的逻辑，才能在提示词中把这些思路传递给 AI。

然而，与任何技术一样，AI 在解决部分问题的同时，也带来了新的挑战。如果开发团队依赖 AI 生成代码来打造成功的 MVP 和 MVA，其实是在进行一场危险的博弈——他们交付的系统可能在未来某个时刻崩溃，而自身却无力修复。更糟的是，AI 生成代码的质量可能会随时间下降，新模型更容易出现静默却致命的故障模式，因为它们是用比旧模型质量更差的代码（通常本身就是 AI 生成的）训练出来的。这会让团队越来越难以改进依赖 AI 生成代码的系统。

除了将软件架构的重心转向实证验证外，团队还需要从新的角度思考可维护性：当 AI 的行为可能发生变化，甚至完全无法使用时，他们未来是否还能支撑这套系统？

原文链接：

https://www.infoq.com/articles/ai-generated-mvp/

大家好，我开源了一个小工具 devfs：一个面向本地开发/测试/CI 的 S3-compatible file server。目标很简单：当你项目里需要对象存储联调时，给你一个快速、可控、可重复的 S3 endpoint。

项目地址：https://github.com/dollarkillerx/devfs

为什么做 devfs

日常开发里经常遇到这些场景：

  • 业务代码依赖 S3（上传/下载/列目录/删除），但本地没法稳定复现
  • 真实云 S3：慢、贵、环境隔离麻烦，CI 更是不好搞
  • 纯 mock：行为不一致，很多 bug 到上线才暴露

所以我写了 devfs：让开发环境像“连真实 S3”一样跑起来，但启动成本更低，适合联调和自动化测试。

devfs 主要特性

  • S3 API 兼容（开发常用子集）：适合跑上传/下载/列举/删除等联调流程
  • Docker Compose 一键启动：团队协作、换机器、CI 都更容易复现
  • 配置简单：支持 .env / flags 等方式，适配本地跑、容器跑
  • 自带 Web UI（如果你更习惯可视化操作/检查数据）

（更多细节在 README）

快速开始（Docker Compose）

git clone https://github.com/dollarkillerx/devfs
cd devfs
docker compose up -d

默认 endpoint：

  • http://127.0.0.1:9000

（账号/密码、端口等可以用 .env 配置，README 有示例）

使用示例

1）AWS CLI

适合快速验证桶/对象操作链路
aws --endpoint-url http://127.0.0.1:9000 s3 mb s3://test
aws --endpoint-url http://127.0.0.1:9000 s3 cp ./a.txt s3://test/a.txt
aws --endpoint-url http://127.0.0.1:9000 s3 ls s3://test

2）Python boto3

适合后端服务快速写集成测试

（README 有完整示例：建桶、上传、下载、列举、删除）

3）Go aws-sdk-go-v2

适合 Go 项目联调 / 单测

（README 有完整示例，并提示了 path-style 等常见坑位）

适用范围 & 规划

devfs 目前主要定位是：开发联调 / CI 集成测试。
接下来我会根据大家的反馈优先补齐更常用的 S3 行为。

你们最希望我优先支持哪些能力？比如：

  • Presigned URL
  • Multipart upload
  • 更丰富的 List/分页行为
  • 事件通知（webhook / queue）
  • 兼容更多 SDK 的边角行为

欢迎试用、提 Issue/PR：https://github.com/dollarkillerx/devfs

最近做很多产品，教程，视频，感觉离不开的一个东西就是做 demo 给客户和社交媒体。

Screen Studio 的确是比较成熟的，但是苦于 Electron ，M 系列的苹果电脑也感觉过于卡顿。
另外一个受不了的就是导出太慢了，很影响节奏。

我们就做了一个 Mac 原声替代：ScreenKite
欢迎大家下载测试。

https://www.screenkite.com/

https://i.imgur.com/NKe98jn.jpeg

如题

感觉就是老板不想给发这个年终啊，先是每年例行的年会取消了，现在例行的年终奖都无啦。起码是爽快给了 N+1,不多拉扯。快速交接完两三个小时拿着显示器背着包走了。

这几年经历的裁员太多次了，所以有随时被裁员的心里准备了，心态倒还算平常。第二天老婆去医院检查怀孕了，朋友说这下是双喜临门了，哈哈哈开心的。

初步计划是年后先缓缓再看看行情找工作，估计一时半会不好找，做好三个月半年的打算。在 AI 大肆盛行的时代，没有竞争力的程序员甚至有可能找不到工作。

今天过年，新年新气象，祝大家天天开心。如果做不到事事如意，那就宠辱尽量不惊吧。

跨越抽象鸿沟：大型语言模型直接生成汇编与机器码的可行性、挑战与未来展望

1. 绪论：从高级抽象回归底层逻辑的范式转移

在软件工程的演进历程中，抽象层次的提升一直被视为生产力进步的核心标志。从机器码到汇编语言，再到 C/C++，直至 Python 、Java 等高级语言，每一次跃迁都旨在屏蔽底层硬件的复杂性，使开发者能够专注于业务逻辑的实现。编译器（ Compiler ）作为这一过程中的绝对权威，承担着将人类可读的高级意图确定性地转化为机器可执行指令的重任。然而，随着大型语言模型（ Large Language Models, LLMs ）的爆发式发展，一个反直觉却极具颠覆性的问题浮出水面：我们是否可以绕过高级语言和传统编译器的中间层，直接利用 LLM 生成汇编代码甚至二进制机器码？

这一问题的提出并非空穴来风，而是基于对现有计算范式局限性的深刻反思与对 AI 能力的重新评估。传统编译器虽然经过数十年的优化，但在面对现代复杂的指令集架构（ ISA ）时，其基于规则的启发式优化算法（ Heuristics ）往往难以遍历庞大的优化空间，容易陷入局部最优解。相比之下，LLM 作为一种概率模型，具备在高维空间中进行模式匹配和生成的能力，理论上存在突破传统编译器优化瓶颈的可能性，即所谓的“超级优化”（ Superoptimization ）。此外，在逆向工程、漏洞利用开发（ Exploit Generation ）以及特定嵌入式环境下的代码生成中，直接操作底层代码的需求始终存在且日益迫切。

本报告旨在详尽探讨 LLM 直接生成汇编语言与二进制代码的可行性、技术路径、当前面临的挑战以及未来的发展方向。我们将基于最新的研究成果，包括“CompilerEval”、“SuperCoder”、“LEGO-Compiler”等框架的实证数据，深入分析不同指令集架构（ x86 、ARM 、RISC-V ）下的生成表现，剖析分词策略（ Tokenization ）对底层代码生成的影响，并探讨这一技术路线在安全领域的双刃剑效应。

1.1 核心驱动力：为何需要“神经后端”？

在高级语言极其成熟的今天，寻求直接生成汇编或机器码的动力主要来自三个方面：

  • 性能的极致追求（超级优化）：传统编译器（如 GCC 、LLVM ）在-O3 优化级别下虽然表现优异，但其优化策略本质上是保守的。为了保证通用性和正确性，编译器往往放弃激进的指令调度或特定的寄存器分配策略。研究表明，在特定的计算内核（ Kernel ）中，存在大量被编译器忽略的优化机会。如果 LLM 能够学习到底层硬件的执行动态，就有可能生成比编译器更高效的代码 1 。
  • 安全与逆向工程的自动化：在网络安全领域，攻击载荷（ Payload ）通常需要以 Shellcode （机器码）的形式存在，且需要绕过各种防御机制（如 ASLR 、DEP ）。高级语言无法直接描述这些底层内存操作。同时，在分析恶意软件时，将二进制还原为可理解的汇编或伪代码是核心痛点。LLM 在这一领域的应用能够大幅降低攻防两端的技术门槛 2 。
  • 异构计算与新架构的快速适配：随着 RISC-V 等开源架构的兴起，以及各类 AI 加速器（ NPU 、TPU ）的涌现，为每一款新硬件开发成熟的编译器后端耗资巨大且周期漫长。如果 LLM 能够通过少样本学习（ Few-Shot Learning ）快速掌握新 ISA 的语法和语义，将极大地加速新硬件的软件生态建设 4 。

然而，这一愿景的实现面临着物理与逻辑层面的双重阻碍。汇编语言的极度冗余性、对硬件状态的强依赖性、以及“差之毫厘，谬以千里”的正确性要求，都与 LLM 当前基于概率预测的本质相冲突。本报告将抽丝剥茧，从理论基础到工程实践，全方位解析这一前沿领域的现状与未来。

2. 神经底层生成的理论基础与技术瓶颈

要理解 LLM 生成汇编代码的可行性，首先必须从模型的输入表示层面入手。与自然语言或高级编程语言相比，底层代码（汇编和二进制）具有显著不同的统计特性和结构特征，这对现有的 Transformer 架构提出了独特的挑战。

2.1 分词（ Tokenization ）的语义鸿沟

分词是 LLM 处理文本的第一步，也是目前制约其在底层代码生成任务中表现的关键瓶颈之一。目前主流的 LLM （如 GPT-4 、Llama 3 、Claude ）大多采用字节对编码（ Byte-Pair Encoding, BPE ）或类似的子词（ Subword ）算法。这些算法是针对自然语言（尤其是英语）优化的，倾向于将常见的单词或词根聚合为一个 Token 。

然而，汇编语言和十六进制机器码并不遵循自然语言的构词法。

  • 语义碎片化：在 C 语言中，while 是一个高频词，会被编码为一个 Token ，携带明确的“循环”语义。而在 x86 汇编中，实现同样逻辑可能需要 CMP 、JE 、JMP 等多条指令。对于 BPE 分词器而言，像 0x48 、0x89 这样的十六进制字节，或者 EAX 、RAX 这样的寄存器名，往往会被拆解为无意义的字符片段。例如，一个复杂的内存地址偏移量可能会被切分成等多个 Token 。这种碎片化导致模型需要消耗更多的注意力头（ Attention Heads ）来重新组合这些碎片以理解其底层含义，大大增加了推理的难度 6 。
  • Token 密度（ Fertility ）与上下文窗口：研究引入了“Fertility”这一指标来衡量分词效率，即平均每个语义单位（如一条指令）所需要的 Token 数量。数据表明，汇编代码的 Fertility 远高于高级语言。这意味着，同样的上下文窗口（ Context Window ，如 32k 或 128k ），能容纳的 C 代码逻辑量远大于汇编代码。对于大型程序的生成，LLM 在汇编层面上会更快地耗尽上下文，导致“遗忘”之前的寄存器状态或栈帧布局，从而引发严重的逻辑错误 7 。

分词算法

在汇编代码中的效率

粒度特征

对模型性能的影响

BPE (Byte-Pair Encoding)

中等

子词/字符混合

平衡了压缩率与粒度，但在处理 Hex 字符串时表现不佳，容易割裂数值语义。

Unigram

较高

可变粒度

压缩率最高，平均每条指令所需的 Token 数最少，有利于节省上下文窗口，提升长代码生成能力。

WordPiece

较低

子词

高 Fertility （高 Token/指令比），保留了更多细节但迅速消耗上下文，导致长依赖关系丢失。

Byte-Level (Raw)

极低

字节

完美的保真度，但序列长度爆炸式增长，使得标准 Transformer 难以处理，推理速度极慢。

表 1：不同分词策略在汇编代码生成中的比较分析 6

研究 6 指出，分词器的选择直接影响下游任务的性能。例如，在二进制相似性检测和函数签名恢复任务中，使用 Unigram 分词器的模型由于其更高效的压缩率，能够在一个窗口内捕捉更长的指令序列，从而表现优于 WordPiece 。这表明，若要实现高效的汇编生成，必须开发针对特定 ISA 优化的专用分词器，或者采用新的架构设计。

2.2 字节级模型（ Byte-Level Models ）：bGPT 的尝试

为了彻底解决文本分词带来的语义失真问题，学术界开始探索直接基于原始字节（ Raw Bytes ）训练的模型，代表作为 bGPT 。bGPT 不仅将代码视为文本，而是将其视为数据流，直接预测下一个字节。这种方法理论上能够模拟数字世界的任何二进制结构，包括机器码、图像数据甚至网络数据包 9 。

在机器码生成任务中，bGPT 展现出了独特的优势。由于直接操作二进制，它天然地理解指令编码的格式，不存在“幻觉”出不存在的指令助记符的问题（因为它是直接生成合法的 Opcode ）。此外，在逆向工程场景下，bGPT 能够更好地处理被混淆（ Obfuscated ）的代码，因为混淆通常只是改变了汇编层面的可读性，而底层的字节流逻辑模式往往依然存在。

然而，bGPT 面临着严峻的扩展性挑战（ Scalability ）。由于一个简单的 32 位整数就需要 4 个字节（ Token ）来表示，其序列长度是 BPE 模式下的数倍。这意味着在相同的计算资源下，bGPT 只能“看”到非常短的代码片段。目前的实验显示，bGPT 在处理短小的 Shellcode 或各种算法片段时表现出色，但在生成完整的大型可执行文件时，仍受限于计算复杂度和记忆能力 6 。

2.3 硬件状态的隐式追踪难题

LLM 生成汇编的另一个核心理论难点在于“隐式状态”的追踪。在高级语言中，变量的生命周期是显式的（作用域），而在汇编中，一切皆是全局的寄存器和内存状态。

  • 寄存器分配（ Register Allocation ）：LLM 必须隐式地“记住”哪些寄存器当前被占用，哪些是空闲的。一旦发生寄存器冲突（ Clobbering ），整个程序的逻辑就会崩溃。
  • 标志位（ Flags ）依赖：x86 架构中大量的条件跳转依赖于前一条指令产生的标志位（ ZF, CF, OF 等）。LLM 必须在生成 JZ （跳转若零）指令时，准确回溯到上一条影响 Zero Flag 的指令（如 CMP 或 TEST ）。这种跨指令的因果依赖关系对于基于注意力机制的模型来说，虽然理论上可捕捉，但在长序列中极易出现“注意力弥散”，导致逻辑断裂 5 。

综上所述，从理论层面看，LLM 生成汇编代码在表示层（分词）和逻辑层（状态追踪）都面临比高级语言更严苛的挑战。这决定了其在当前阶段更适合于“局部优化”或“短片段生成”，而非全系统的构建。

3. 架构之争：x86 、ARM 与 RISC-V 的生成性能差异

并非所有的汇编语言在 LLM 眼中的难度都是等同的。最新的实证研究揭示了一个有趣的现象：尽管互联网上关于 x86 的数据量占据绝对优势，但 LLM 在生成 RISC 风格（ ARM, RISC-V ）的汇编代码时，往往表现出更高的成功率。这一发现挑战了“数据量即真理”的 Scaling Law 传统认知，揭示了语言本身的复杂度对生成模型的影响。

3.1 CompilerEval 评测结果分析

在 IJCNN 2025 上发表的“CompilerEval”研究中，研究人员构建了一个包含线性代数、图像处理等 20 个代表性计算内核的基准测试集，评估了包括 GPT-4 、Claude-3.5-Sonnet 在内的主流模型在不同架构下的编译能力。

评测结果（ Success@1 ，即一次生成通过率）显示出显著的架构差异：

目标架构

测试硬件平台

平均通过率 (Success@1)

关键性能影响因素分析

ARM

Apple M1 Max

35.02%

语法规则统一，指令定长，显式的寄存器操作，符合逻辑直觉。

RISC-V

SpacemiT K1

32.30%

极简指令集，模块化设计，无历史包袱，利于模型学习规律。

x86-64

Xeon Gold 5218R

27.85%

变长指令，复杂的寻址模式，隐式状态多，遗留特性干扰模型判断。

表 2：CompilerEval 基准测试中不同架构的生成成功率对比 4

3.2 为什么 LLM 更擅长 RISC ？

深入分析表明，x86 架构的 CISC （复杂指令集）特性是导致 LLM 表现不佳的主要原因：

  • 指令的歧义性与复杂性：x86 指令集历史悠久，包含大量功能重叠或语义复杂的指令。例如，MOV 指令在不同操作数类型下有完全不同的编码和行为。LLM 容易混淆这些细微差别。
  • 隐式操作数：许多 x86 指令隐式地使用特定寄存器（如 MUL 指令默认使用 RAX 和 RDX ）。LLM 如果未能准确捕捉这些隐式规则，就会导致寄存器冲突。
  • 变长指令带来的序列噪声：x86 指令长度从 1 字节到 15 字节不等，这在分词后产生了极不规律的 Token 序列，增加了模型学习结构的难度。

相比之下，ARM 和 RISC-V 作为 RISC 架构，具有以下优势：

  • 正交性（ Orthogonality ）：指令的功能高度解耦，寄存器通用性强。例如 RISC-V 的指令设计非常规整，模型更容易预测下一条指令的格式。
  • Load-Store 架构：内存操作仅限于特定的 Load 和 Store 指令，运算指令只在寄存器间进行。这种清晰的数据流模式使得 LLM 更容易追踪数据的移动路径。
  • 显式性：大多数操作数都是显式的，减少了模型需要“猜测”隐式状态的负担。

3.3 跨平台生成的启示

这一差异给未来的 LLM 编译器设计带来了重要启示：在训练专门针对代码生成的模型时，选择 RISC-V 作为中间表示（ IR ）或者首选生成目标可能是一个更优的策略。 模型可以先生成逻辑清晰的 RISC-V 代码，再通过确定性的转换工具（如二进制翻译器）转化为 x86 代码，从而规避直接生成 x86 带来的不确定性 4 。

此外，研究还发现，具备强推理能力（ Reasoning ）的模型（如 OpenAI o1 ）在处理复杂指令集时的提升幅度远大于普通模型。这表明，通过思维链（ Chain-of-Thought ）让模型在生成代码前先规划寄存器分配和栈布局，是弥补 x86 架构复杂性的有效手段。在 CompilerEval 的测试中，引入推理步骤后，GPT-o1 在 rotate 、resize 等复杂内核上的成功率提升了超过 30 个百分点 4 。

4. 超级优化（ Superoptimization ）：LLM 超越 GCC -O3 的实践

如果说直接生成可运行的代码是“及格线”，那么生成比传统编译器更高效的代码则是“满分目标”。这一领域被称为“超级优化”，历来是系统编程皇冠上的明珠。LLM 的介入，正在将这一曾经仅限于极小代码片段的技术推向实用化。

4.1 传统编译器的局限与 LLM 的机遇

现代编译器（如 GCC 、LLVM ）的优化器是基于数千条人工编写的规则（ Passes ）构建的。虽然强大，但它们存在根本性的局限：

  • 相位顺序问题（ Phase Ordering Problem ）：编译器优化的顺序是固定的或基于简单启发式的，但不同的代码可能需要不同的优化顺序才能达到最优。
  • 局部视野：编译器通常只能在基本块（ Basic Block ）或函数级别进行优化，难以跨越复杂的控制流发现全局优化机会。
  • 保守策略：为了保证 100%的正确性，编译器不敢使用任何可能导致副作用的激进优化。

LLM 作为一个基于概率的生成器，能够在庞大的指令组合空间中进行随机搜索。它不受固定规则的束缚，有时能“顿悟”出人类专家未曾设想的指令序列。例如，利用位运算的奇技淫巧来代替昂贵的除法指令，或者利用 SIMD 指令的特殊排列来加速矩阵运算。

4.2 SuperCoder 框架解析

2025 年发表的“SuperCoder”论文展示了 LLM 在这一领域的突破性进展。研究者构建了一个包含 8,072 个汇编程序的基准测试集，并提出了一套基于强化学习（ Reinforcement Learning ）的训练框架 1 。

核心机制：基于 PPO 的强化学习

SuperCoder 并没有止步于监督微调（ SFT ），而是引入了近端策略优化（ PPO ）算法。

  • 状态（ State ）：当前的汇编代码片段。
  • 动作（ Action ）：重写部分指令或调整指令顺序。
  • 奖励函数（ Reward Function ）：这是整个系统的灵魂。奖励由两部分组成：正确性奖励：通过运行测试用例，验证生成的汇编代码输出是否与基准 C 代码一致。
  • 性能奖励：测量代码的实际运行时间（ Latency ）或吞吐量（ Throughput ），并与 gcc -O3 生成的代码进行对比。只有当代码正确且比-O3 更快时，模型才会获得正向奖励。

实验结果：

经过 PPO 微调后的 SuperCoder 模型（基于 Qwen2.5-Coder-7B ），在测试集上取得了惊人的成绩：

  • 正确性：96.0% 的代码通过了功能测试。
  • 加速比：生成的汇编代码平均比 gcc -O3 快 1.47 倍。
  • 对比：这一性能显著超越了 Claude-3.7-Sonnet 和 GPT-4 等通用大模型，证明了专门针对底层优化进行 RL 训练的巨大潜力 1 。

4.3 挑战：正确性验证的“图灵陷阱”

尽管 SuperCoder 表现亮眼，但它也暴露了 LLM 超级优化的核心软肋：基于测试的正确性验证是不完备的。

传统的超级优化器（如 STOKE ）使用形式化方法（ Formal Methods ）来证明优化后的代码与原代码在逻辑上是等价的。而 SuperCoder 仅依赖有限的输入输出测试用例（ I/O Examples ）。这意味着，LLM 生成的代码可能在测试用例覆盖的范围内是正确的，但在某些边界条件下可能包含致命的 Bug （如未处理的溢出、错误的内存别名假设）。

这种“概率性正确”在高性能计算（ HPC ）或游戏引擎中或许可以接受，但在航空航天或金融交易等关键领域是绝对不可接受的。因此，未来的研究方向必然是将 LLM 的生成能力与 SMT 求解器（如 Z3 ）的验证能力相结合，形成“生成-验证”闭环 13 。

5. 神经编译架构：从“黑盒”到“模块化”

既然直接生成大规模汇编代码面临上下文窗口和正确性的双重挑战，学术界开始探索将编译任务分解的架构设计。目前的趋势是从单体生成向模块化、流程化的“神经编译系统”演进。

5.1 LEGO-Compiler：化整为零的艺术

针对 LLM 上下文窗口限制导致的“长代码崩溃”问题，LEGO-Compiler 提出了一种基于“翻译可组合性”（ Translation Composability ）的解决方案。该系统的核心思想是将复杂的 C 程序分解为微小的、可管理的单元（如基本块或单一函数），分别由 LLM 进行翻译，然后再像搭积木一样将其组装起来 15 。

技术亮点：

  • 模块化分解：系统首先利用静态分析工具提取程序的控制流图（ CFG ），将程序切割成独立的逻辑块。
  • 局部翻译与验证：LLM 只需要关注当前块的翻译，上下文压力骤减。每个块翻译完成后，立即通过单元测试进行验证。
  • 链接与全局优化：所有块翻译完成后，系统负责处理标签（ Label ）跳转和数据段合并，生成最终的汇编文件。

实验表明，LEGO-Compiler 在 ExeBench 数据集上达到了超过 99%的准确率，并且能够处理的代码规模比直接翻译方法大了一个数量级。这种方法有效地规避了 Token 密度过高导致的注意力分散问题，是目前最具工程落地潜力的方案之一。

5.2 LLM-x86 与数据增强：教模型“像编译器一样思考”

另一条路径是改善训练数据的质量。Llm-x86 项目发现，通用的预训练模型缺乏对编译器内部中间表示（ IR ）和数值转换规则的理解。例如，C 语言中的常量在汇编中可能以补码形式存在，或者被编码为立即数操作数。

该研究提出了一套以数据为中心的增强流水线（ Data-Centric Augmentation Pipeline ）：

  • 数值转换增强：在训练数据中，显式地标注出 C 代码中的数字与汇编代码中十六进制表示的对应关系，训练模型对数值类型的敏感度。
  • IR 辅助：将 LLVM IR 作为辅助输入（ Prompt 的一部分）喂给模型。IR 比汇编更抽象，比 C 更具体，充当了思维链的“脚手架”。

结果显示，仅使用 13B 参数的模型，在经过增强数据微调后，其 C 到 x86 的翻译准确率超过了 91%，甚至在某些指标上击败了未微调的 GPT-4 Turbo 17 。这证明了在特定领域，数据质量和领域知识的注入比单纯堆砌模型参数更有效。

5.3 LaaC （ LLM as a Compiler ）范式

LaaC 是一个更宏大的愿景，试图构建一个端到端的神经编译器。其架构不仅仅是生成代码，还包括了错误反馈循环（ Error Feedback Loop ）。当生成的汇编代码无法汇编（ Assembler Error ）或运行时崩溃时，错误信息会被回传给 LLM ，要求其进行“自我修复”（ Self-Repair ）。CompilerEval 的研究表明，这种迭代式的修复机制可以将编译成功率从 30%左右提升至更高水平，但同时也显著增加了推理成本和时间延迟 4 。

6. 安全领域的双刃剑：自动化攻防

LLM 对底层代码的掌控能力在网络安全领域引发了剧烈震荡。这把双刃剑既能赋能攻击者，也能武装防御者。

6.1 自动化漏洞利用生成（ AEG ）

在进攻端，PwnGPT 等框架展示了 LLM 在漏洞利用（ Exploit ）生成方面的可怕潜力。传统的 AEG 工具往往依赖于复杂的符号执行，效率低下且难以处理逻辑漏洞。而 PwnGPT 通过将 CTF 挑战分解为分析、生成、验证三个模块，利用 LLM 强大的语义理解能力来识别漏洞点 2 。

  • 能力跃升：在基准测试中，PwnGPT 将漏洞利用代码的生成成功率从通用模型的 26.3%提升到了 57.9%。
  • Shellcode 生成：LLM 能够根据特定约束（如不仅包含空字节、必须是纯字母数字）生成多态 Shellcode （ Polymorphic Shellcode ），这使得传统的基于特征码的入侵检测系统（ IDS ）面临失效风险 19 。
  • 低门槛化：最令人担忧的是，这种技术可能使不具备汇编知识的“脚本小子”也能通过自然语言描述生成极具破坏性的攻击代码。

6.2 恶意软件变异与逃逸

研究人员还发现，LLM 可以被用来重写恶意软件的汇编代码，在保持功能不变的前提下彻底改变其二进制指纹。例如，通过指令替换（用 ADD EAX, 1 代替 INC EAX ）、乱序执行、插入垃圾指令等手段。这种 AI 驱动的混淆（ AI-Powered Obfuscation ）使得静态分析工具几乎无法应对 20 。

6.3 防御端的应用：逆向工程辅助

在防御端，LLM 成为了逆向工程师的得力助手。

  • 反编译解释：将 IDA Pro 或 Ghidra 反编译出的伪代码（通常变量名为 v1, v2 ，难以阅读）输入 LLM ，模型能够根据代码逻辑推断出变量的真实含义（如将 v1 重命名为 user_password ），并自动生成注释。
  • 二进制相似性检测：利用 LLM 生成的 Embedding 向量，可以快速判断两个看似不同的二进制函数是否源自同一份源代码，这对识别已知漏洞的变种至关重要 3 。

7. 关键挑战与不可回避的局限性

尽管前景广阔，但要将 LLM 真正集成到工业级的底层开发流中，仍需跨越几座大山。

7.1 可靠性的“停机问题”

编译器最核心的契约是确定性和正确性。如果你编译同一个 C 程序 100 次，你会得到 100 个完全相同的二进制文件。但 LLM 是随机的，每次生成的汇编代码可能都不同，且可能包含微妙的 Bug 。

  • 寄存器破坏（ Register Clobbering ）：这是最常见的错误。LLM 可能会在函数调用约定（ Calling Convention ）中犯错，忘记保存被调用者保存寄存器（ Callee-saved registers ），导致函数返回后主调函数的上下文被破坏。这种 Bug 极难调试，往往表现为程序在距离出错点很远的地方莫名崩溃 23 。
  • 幻觉（ Hallucination ）：模型可能会编造出不存在的指令，或者错误地假设某个指令会修改标志位。在硬件层面，没有“差不多”这种说法，指令必须精确匹配规范。

7.2 上下文窗口与信息密度的博弈

汇编语言是极其冗长的。一个实现矩阵乘法的 C 函数可能只有 10 行，但对应的 AVX-512 汇编代码可能有上百行。对于大型项目，即便拥有 1M Token 上下文的模型，也难以一次性装入整个程序的汇编代码。 这就导致了“迷失中间”（ Lost-in-the-Middle ）现象：模型往往能很好地处理开头和结尾的指令，但对中间部分的寄存器状态追踪能力显著下降。相比之下，C 语言的高密度特性使其更适合 LLM 处理宏观逻辑 7 。

7.3 验证的代价

为了弥补可靠性缺陷，目前的主流方案是引入“生成-验证-修复”循环。但这带来了巨大的计算成本。编译一个 Linux 内核通常只需要几分钟，但如果用 LaaC 模式，每一行汇编都需要经过 LLM 推理、汇编验证、测试运行、错误修复，时间成本可能膨胀数百倍。这使得该方案在常规软件开发中缺乏性价比，仅适用于对性能或安全性有极致要求的极小核心模块 5 。

8. 结论与未来展望

回到最初的问题：让 LLM 直接写汇编或二进制代码，是一种可行的方案吗？

答案是：在特定约束下可行，且极具潜力，但目前不能全面替代高级语言开发。

可行性判决：

  • **作为“超级优化器” (Strong Yes)**：在生成小型、极致性能的计算内核（如加密算法、信号处理）时，配合强化学习的 LLM 已经证明能超越人类专家和传统编译器。
  • **作为“逆向助手” (Strong Yes)**：在解释和分析现有二进制代码方面，LLM 已成为不可或缺的工具。
  • **作为“通用编译器” (No)**：由于缺乏确定性保证、巨大的计算开销以及上下文管理的困难，LLM 在可预见的未来无法取代 GCC/LLVM 构建通用应用程序。

未来展望：神经符号系统的融合

未来的底层代码生成技术，极有可能是“神经符号人工智能”（ Neuro-Symbolic AI ）的形态。

  • LLM 作为启发式引擎：它不直接输出最终的二进制，而是输出“优化建议”或“指令草稿”。
  • 编译器作为验证与后端：传统的编译器架构接手 LLM 的输出，利用严格的逻辑规则检查寄存器分配、内存安全，并进行最终的代码确立。

这种混合架构将结合 LLM 的创造力（跳出局部最优）和编译器的严谨性（保证正确性），彻底改变我们构建底层软件的方式。我们正站在从“确定性编译”向“概率性编译”过渡的门槛上，虽然挑战重重，但跨越这道抽象鸿沟后的风景，无疑将是计算性能与开发效率的又一次飞跃。

Works cited

6/45 （又名：乐透大作战）韩国
讲诉南北朝鲜，互换身份后发生一连串的搞笑故事


你丫闭嘴 东北话版
我知道这片子很多人都看过，但东北话版可能很多人 没看过，完全不一样的体验，最佳恶搞方言版电影

城市猎人 真人版 法国版
日漫改编，处处恶搞没有底线

双宝斗恶魔
看就完事，会有惊喜

先推荐 4 部，各位也可以分享，最好稍微冷门点，豆瓣几十万人看过的就别推了～

协议

优先选择新协议, 通常: Vless > AnyTLS > ShadowTLS > Hysteria2 > Tuic > Trojan > Vmess > SS/SSR

线路类型

简单理解稳定性2026 合理价位备注
直连你的设备 → 直接连境外服务器(便宜但不稳)★☆☆☆ (易被封)5-10 元/月仅做备用
中转 (BGP)你的设备 → 国内中转优化 → 境外服务器(性价比高)★★★☆ (有优化)15-30 元/月建议 公网中转
专线 (IPLC)你的设备 → 专用物理线路 → 境外服务器(贵但稳)★★★★ (不过墙)40 元+/月办公/不差钱

延迟

TCP ping 和 Google ping 越低越好, 可以网上搜相关的测速情况. 最好有试用自己测试, 看晚高峰(20:30 – 22:30)的表现. 自己简单测试可以开 Youtube 4K 视频拖拖进度条.

费用

推荐一主一备, 备用机场推荐按量付费. 月付优先. 开业时间不到 1 年的不要年付.

稳定性

通常在官网公告, 或者 tg 通告频道会有历史维护公告. 特殊时期挂了多久能修好.

流量倍率

如果有 0.1x 0.3x 等低倍率节点就更好. 如果只有高倍率节点好用可以放弃.

隐私安全

机场主理论上能看到你访问的域名. No Logs 不记录日志最好. 支付方式: USDT (加密货币) > 支付宝/微信.

特殊需求

流媒体解锁能力? 政治敏感内容封锁?

客服渠道

Telegram 群 / 网页工单 / Email. 只留 QQ 群/微信(会被喝茶，高风险).

客户端

定制客户端使用起来方便, 但开源客户端会更安全.

运营与口碑

真正的好机场，通常都很低调，官网可能都要翻墙才能搜到，靠的是老用户的口口相传。相关论坛的骂声或者夸赞，才是最真实的买家秀.

源: https://github.com/thesomeexp/Proxy-service-recommendations

大家好，我是良许。

在嵌入式系统开发和网络安全领域，防火墙和入侵测试是两个经常被提及但又容易混淆的概念。

作为一名嵌入式程序员，我在工作中经常需要处理设备的网络安全问题，特别是在汽车电子领域，车载系统的网络安全已经成为不可忽视的重要环节。

今天就和大家聊聊防火墙和入侵测试这两个话题，帮助大家更好地理解它们的作用和实际应用。

1. 防火墙：网络安全的第一道防线

1.1 什么是防火墙

防火墙就像是网络世界的"门卫"，它站在内部网络和外部网络之间，根据预先设定的安全规则来决定哪些数据包可以通过，哪些应该被拦截。

在嵌入式系统中，防火墙可以是硬件设备，也可以是运行在 Linux 系统上的软件模块。

我在做车载网关项目时，就需要在嵌入式 Linux 系统上配置 iptables 防火墙，来控制车内各个 ECU（电子控制单元）之间的通信。

这个防火墙需要确保只有合法的 CAN 总线消息和以太网数据包能够在不同的车载网络域之间传递。

1.2 防火墙的工作原理

防火墙主要通过以下几种方式来过滤网络流量：

1.2.1 包过滤

这是最基础的防火墙技术，它会检查每个数据包的源 IP 地址、目标 IP 地址、端口号、协议类型等信息，然后根据规则决定是否放行。

在嵌入式 Linux 系统中，我们通常使用 iptables 来实现包过滤功能。

举个例子，假设我们的嵌入式设备只允许 SSH 连接（22 端口）和 HTTP 服务（80 端口），可以这样配置：

// 在嵌入式Linux系统中，通常通过system()函数调用iptables命令
#include <stdlib.h>
#include <stdio.h>
​
void configure_firewall(void) {
    // 清空现有规则
    system("iptables -F");
    
    // 设置默认策略：拒绝所有入站连接
    system("iptables -P INPUT DROP");
    system("iptables -P FORWARD DROP");
    system("iptables -P OUTPUT ACCEPT");
    
    // 允许本地回环接口
    system("iptables -A INPUT -i lo -j ACCEPT");
    
    // 允许已建立的连接
    system("iptables -A INPUT -m state --state ESTABLISHED，RELATED -j ACCEPT");
    
    // 允许SSH连接
    system("iptables -A INPUT -p tcp --dport 22 -j ACCEPT");
    
    // 允许HTTP连接
    system("iptables -A INPUT -p tcp --dport 80 -j ACCEPT");
    
    printf("Firewall configured successfully\n");
}

1.2.2 状态检测

状态检测防火墙不仅检查单个数据包，还会跟踪整个连接的状态。

它会记住哪些连接是合法建立的，然后只允许属于这些连接的数据包通过。

这种方式比简单的包过滤更加智能和安全。

在我们的车载系统中，诊断工具需要通过 UDS（统一诊断服务）协议与 ECU 通信。

状态检测防火墙可以确保只有在诊断会话正确建立后，后续的诊断命令才能被执行。

1.2.3 应用层过滤

更高级的防火墙还能检查应用层的数据内容。

比如，它可以识别 HTTP 请求中是否包含恶意代码，或者检查 FTP 传输的文件类型是否符合安全策略。

1.3 嵌入式系统中的防火墙实现

在嵌入式 Linux 系统中，我们经常需要编写程序来动态管理防火墙规则。

下面是一个实际的例子，展示如何在 STM32+Linux 的组合系统中实现简单的防火墙管理：

#include <stdio.h>
#include <string.h>
#include <stdbool.h>
​
#define MAX_RULES 100
#define MAX_IP_LEN 16
​
typedef struct {
    char src_ip[MAX_IP_LEN];
    char dst_ip[MAX_IP_LEN];
    int src_port;
    int dst_port;
    char protocol[10];  // TCP， UDP， ICMP
    bool allow;         // true: 允许， false: 拒绝
} FirewallRule;
​
typedef struct {
    FirewallRule rules[MAX_RULES];
    int rule_count;
} FirewallConfig;
​
FirewallConfig fw_config = {0};
​
// 添加防火墙规则
bool add_firewall_rule(const char* src_ip， const char* dst_ip， 
                       int src_port， int dst_port， 
                       const char* protocol， bool allow) {
    if (fw_config.rule_count >= MAX_RULES) {
        printf("Error: Firewall rule table is full\n");
        return false;
    }
    
    FirewallRule* rule = &fw_config.rules[fw_config.rule_count];
    strncpy(rule->src_ip， src_ip， MAX_IP_LEN - 1);
    strncpy(rule->dst_ip， dst_ip， MAX_IP_LEN - 1);
    rule->src_port = src_port;
    rule->dst_port = dst_port;
    strncpy(rule->protocol， protocol， 9);
    rule->allow = allow;
    
    fw_config.rule_count++;
    
    printf("Added rule: %s:%d -> %s:%d (%s) [%s]\n"，
           src_ip， src_port， dst_ip， dst_port， protocol，
           allow ? "ALLOW" : "DENY");
    
    return true;
}
​
// 检查数据包是否被允许通过
bool check_packet(const char* src_ip， const char* dst_ip，
                  int src_port， int dst_port，
                  const char* protocol) {
    for (int i = 0; i < fw_config.rule_count; i++) {
        FirewallRule* rule = &fw_config.rules[i];
        
        // 检查是否匹配规则
        if ((strcmp(rule->src_ip， "0.0.0.0") == 0 || 
             strcmp(rule->src_ip， src_ip) == 0) &&
            (strcmp(rule->dst_ip， "0.0.0.0") == 0 || 
             strcmp(rule->dst_ip， dst_ip) == 0) &&
            (rule->src_port == 0 || rule->src_port == src_port) &&
            (rule->dst_port == 0 || rule->dst_port == dst_port) &&
            strcmp(rule->protocol， protocol) == 0) {
            
            return rule->allow;
        }
    }
    
    // 默认拒绝
    return false;
}
​
// 初始化防火墙配置
void init_firewall(void) {
    fw_config.rule_count = 0;
    
    // 添加一些基本规则
    add_firewall_rule("0.0.0.0"， "0.0.0.0"， 0， 22， "TCP"， true);   // 允许SSH
    add_firewall_rule("0.0.0.0"， "0.0.0.0"， 0， 80， "TCP"， true);   // 允许HTTP
    add_firewall_rule("0.0.0.0"， "0.0.0.0"， 0， 443， "TCP"， true);  // 允许HTTPS
    add_firewall_rule("192.168.1.100"， "0.0.0.0"， 0， 0， "TCP"， false); // 阻止特定IP
}

这个例子展示了如何在嵌入式系统中实现一个简单的防火墙规则引擎。

在实际应用中，我们会把这些规则同步到 Linux 内核的 netfilter 框架中，让内核来执行实际的包过滤操作。

2. 入侵测试：主动发现安全漏洞

2.1 什么是入侵测试

入侵测试（Penetration Testing），也叫渗透测试，是一种主动的安全评估方法。

它模拟黑客的攻击手段，尝试找出系统中的安全漏洞。

与防火墙的被动防御不同，入侵测试是一种进攻性的安全检测手段。

在我负责的汽车电子项目中，每次发布新版本的车载系统固件之前，我们都会进行全面的入侵测试。

这包括测试车载网关是否能抵御各种网络攻击，诊断接口是否存在未授权访问的风险，以及 OTA（空中升级）系统是否可能被劫持等。

2.2 入侵测试的主要方法

2.2.1 端口扫描

端口扫描是入侵测试的第一步，它用来发现目标系统开放了哪些网络端口和服务。

在嵌入式系统中，我们可以使用 nmap 等工具来扫描设备，看看是否有不应该开放的端口。

下面是一个简单的端口扫描程序示例：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <errno.h>
​
#define TIMEOUT 2
​
// 检查单个端口是否开放
bool check_port(const char* ip， int port) {
    int sock;
    struct sockaddr_in target;
    struct timeval timeout;
    
    sock = socket(AF_INET， SOCK_STREAM， 0);
    if (sock < 0) {
        return false;
    }
    
    // 设置超时
    timeout.tv_sec = TIMEOUT;
    timeout.tv_usec = 0;
    setsockopt(sock， SOL_SOCKET， SO_RCVTIMEO， &timeout， sizeof(timeout));
    setsockopt(sock， SOL_SOCKET， SO_SNDTIMEO， &timeout， sizeof(timeout));
    
    target.sin_family = AF_INET;
    target.sin_port = htons(port);
    target.sin_addr.s_addr = inet_addr(ip);
    
    // 尝试连接
    int result = connect(sock， (struct sockaddr*)&target， sizeof(target));
    close(sock);
    
    return (result == 0);
}
​
// 扫描指定IP的端口范围
void scan_ports(const char* ip， int start_port， int end_port) {
    printf("Scanning %s from port %d to %d...\n"， ip， start_port， end_port);
    printf("Open ports:\n");
    
    for (int port = start_port; port <= end_port; port++) {
        if (check_port(ip， port)) {
            printf("  Port %d is OPEN\n"， port);
        }
        
        // 每扫描10个端口显示进度
        if (port % 10 == 0) {
            printf("Progress: %d/%d\r"， port - start_port， end_port - start_port);
            fflush(stdout);
        }
    }
    
    printf("\nScan completed.\n");
}
​
int main(int argc， char* argv[]) {
    if (argc != 4) {
        printf("Usage: %s <IP> <start_port> <end_port>\n"， argv[0]);
        return 1;
    }
    
    const char* ip = argv[1];
    int start_port = atoi(argv[2]);
    int end_port = atoi(argv[3]);
    
    scan_ports(ip， start_port， end_port);
    
    return 0;
}

2.2.2 漏洞扫描

漏洞扫描会检查系统中已知的安全漏洞，比如过时的软件版本、默认密码、配置错误等。

在嵌入式设备中，常见的漏洞包括：Telnet 服务使用默认密码、Web 管理界面存在 SQL 注入、固件升级过程没有签名验证等。

2.2.3 模糊测试

模糊测试（Fuzzing）是一种自动化测试技术，它向目标系统发送大量随机或半随机的数据，观察系统是否会崩溃或出现异常行为。

这种方法特别适合测试协议解析器和输入处理模块。

下面是一个针对串口通信的简单模糊测试示例：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <termios.h>
#include <time.h>
​
#define UART_DEVICE "/dev/ttyUSB0"
#define FUZZ_ITERATIONS 1000
#define MAX_PACKET_SIZE 256
​
// 配置串口
int configure_uart(int fd) {
    struct termios options;
    
    tcgetattr(fd， &options);
    
    // 设置波特率
    cfsetispeed(&options， B115200);
    cfsetospeed(&options， B115200);
    
    // 8N1
    options.c_cflag &= ~PARENB;
    options.c_cflag &= ~CSTOPB;
    options.c_cflag &= ~CSIZE;
    options.c_cflag |= CS8;
    
    // 原始模式
    options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
    options.c_oflag &= ~OPOST;
    
    tcsetattr(fd， TCSANOW， &options);
    
    return 0;
}
​
// 生成随机数据包
void generate_fuzz_data(unsigned char* buffer， int size) {
    for (int i = 0; i < size; i++) {
        buffer[i] = rand() % 256;
    }
}
​
// 模糊测试主函数
void uart_fuzzing(const char* device) {
    int fd;
    unsigned char fuzz_data[MAX_PACKET_SIZE];
    int packet_size;
    
    // 打开串口
    fd = open(device， O_RDWR | O_NOCTTY);
    if (fd < 0) {
        printf("Error: Cannot open %s\n"， device);
        return;
    }
    
    configure_uart(fd);
    
    printf("Starting UART fuzzing on %s...\n"， device);
    printf("Iterations: %d\n"， FUZZ_ITERATIONS);
    
    srand(time(NULL));
    
    for (int i = 0; i < FUZZ_ITERATIONS; i++) {
        // 随机生成数据包大小
        packet_size = (rand() % MAX_PACKET_SIZE) + 1;
        
        // 生成随机数据
        generate_fuzz_data(fuzz_data， packet_size);
        
        // 发送数据
        int bytes_written = write(fd， fuzz_data， packet_size);
        
        if (bytes_written < 0) {
            printf("Error writing to UART at iteration %d\n"， i);
            break;
        }
        
        // 等待响应
        usleep(10000);  // 10ms
        
        // 尝试读取响应
        unsigned char response[MAX_PACKET_SIZE];
        int bytes_read = read(fd， response， MAX_PACKET_SIZE);
        
        if (bytes_read > 0) {
            printf("Iteration %d: Sent %d bytes， received %d bytes\n"， 
                   i， packet_size， bytes_read);
        }
        
        // 进度显示
        if (i % 100 == 0) {
            printf("Progress: %d/%d (%.1f%%)\n"， 
                   i， FUZZ_ITERATIONS， (float)i/FUZZ_ITERATIONS*100);
        }
    }
    
    close(fd);
    printf("Fuzzing completed.\n");
}

2.3 入侵测试的实际应用

在我的工作经历中，入侵测试帮助我们发现了很多潜在的安全问题。

有一次，我们在测试一个车载娱乐系统时，通过模糊测试发现了蓝牙协议栈的一个缓冲区溢出漏洞。

攻击者可以通过发送特制的蓝牙数据包让系统崩溃，甚至可能执行任意代码。

这个漏洞如果不被发现，在车辆量产后将会是一个严重的安全隐患。

另一个案例是关于 OTA 升级系统的。

我们的安全团队在入侵测试中发现，虽然升级包本身有数字签名验证，但是下载过程中的临时文件没有做权限控制，攻击者可以在升级过程中替换临时文件，从而绕过签名验证。

这个发现促使我们重新设计了整个 OTA 升级流程。

3. 防火墙与入侵测试的关系

3.1 互补而非对立

防火墙和入侵测试不是对立的，而是互补的安全措施。

防火墙是防御工具，它在系统运行时持续工作，阻止未授权的访问。

而入侵测试是评估工具，它帮助我们发现防御体系中的薄弱环节。

可以这样理解：防火墙是"盾"，入侵测试是"矛"。

我们用"矛"来测试"盾"的强度，然后根据测试结果来加固"盾"。

3.2 实际工作流程

在实际的嵌入式系统开发中，我通常会按照以下流程来处理安全问题：

首先，在系统设计阶段就配置好防火墙规则，实施最小权限原则，只开放必要的端口和服务。

然后，在开发完成后进行全面的入侵测试，尝试突破防火墙的防护。

如果在测试中发现了漏洞，就修复代码并更新防火墙规则。

最后，在系统部署后，继续监控防火墙日志，定期进行入侵测试，确保系统始终处于安全状态。

3.3 持续改进

网络安全不是一次性的工作，而是一个持续改进的过程。

新的攻击手段不断出现，我们的防御措施也需要不断更新。

定期的入侵测试可以帮助我们及时发现新的安全威胁，而防火墙规则也需要根据测试结果和实际运行情况进行调整。

在我管理的项目中，我们建立了一个安全反馈循环：每次入侵测试后，都会生成详细的测试报告，列出发现的所有问题和建议的修复方案。

开发团队根据报告修复问题，然后再次进行测试验证。

这个循环不断重复，确保系统的安全性持续提升。

4. 写在最后

作为嵌入式程序员，我们不仅要关注功能实现，更要重视系统的安全性。

防火墙和入侵测试是保障系统安全的两个重要手段，掌握它们的原理和应用方法，对我们的职业发展非常有帮助。

特别是在物联网和车联网快速发展的今天，嵌入式设备的安全问题越来越受到重视，具备安全测试能力的嵌入式工程师也越来越抢手。

希望这篇文章能帮助大家更好地理解防火墙和入侵测试的概念和应用。

如果你在实际工作中遇到相关的安全问题，不妨尝试用今天介绍的方法来解决。

记住，安全无小事，每一个细节都可能成为攻击者的突破口。

让我们一起努力，打造更安全的嵌入式系统。

更多编程学习资源

  1. 1
  2. ...
  3. 94
  4. 95
  5. 96
  6. 97
  7. 98
  8. 99
  9. 100
  10. ...
  11. 252