AI

前沿哨所

• 独立开发者3天上线AI梗视频生成站：全栈技术选型与踩坑复盘

  一位有多年数据和产品经验的开发者分享了3天内独立完成并上线的AI视频生成网站。该站点借势TikTok和X上流行的AI小矮人踮脚舞热梗：用户上传一张单人照片，无需编写提示词，即可生成约11秒、720p的个人版跳舞视频，支持16:9和9:16两种比例，输出带原片配乐的MP4与无水印GIF，耗时4至7分钟，关闭页面生成也会继续。技术栈方面，前端采用TanStack Start，部署于Cloudflare Workers、D1和R2，并用Cron Trigger兜底超时任务；生成流程为Nano Banana 2将照片转为彩铅风参考图，火山方舟Seedance 2.0 mini以参考视频模式逐镜头重演原片，服务端用Mediabunny合入配乐后存入R2。定价单条4.99美元，另有3条和10条打包价，不设免费试用，原因是每条视频都消耗真实GPU成本，新站难以承受白嫖流量。文中记录了多个实战坑：照片尺寸过小遭模型拒绝、用户中途关闭页面导致任务卡死、PayPal日本区开发者后台无法登录、Cloudflare兼容日期与时区报错、Workers Builds部署排队异常等，并逐一给出解决方案。作者还实践了GEO策略，通过撰写llms.txt、构建问答页、添加FAQ/Article Schema、接入IndexNow等方式，尝试让ChatGPT等AI搜索收录推荐站点，效果仍在观察中。

  事件分析

  技术上，该项目展示了当前AI视频应用典型的多模型编排模式：图像生成模型负责风格转换，视频生成模型负责动作重演，服务端合成音轨，全程无服务器架构压低了运维成本，浏览器端图像预处理则规避了模型接口的尺寸限制。值得关注的是火山引擎Seedance进入海外独立开发者的技术选型清单，反映国产视频生成模型在性价比上的竞争力。产业层面，热点梗站模式验证了AI内容生成的快速变现路径，从热点出现到产品上线仅需数天，但热度衰减快、同质化涌入与GPU成本压力构成长期挑战，失败自动退积分等细节也体现了商用化的工程考量。作者尝试的GEO预示流量入口正从传统搜索引擎向AI对话助手迁移，llms.txt、结构化数据等规范或将成为开发者的新必修课。

  核心观点：AI视频API把创业门槛压到数天量级，独立开发者的胜负手已从技术转向热点嗅觉与工程化交付速度。

  原文链接：V2EX 分享发现

  10小时前

• OpenClaw Skill 装不上，问题不只在审批开关

  

  在飞书里让 OpenClaw “安装一个 Skill”，Agent 明明已经把提案生成出来，流程却停在 pending。接下来还得再发一句“批准并应用”，Skill 才会进入可用状态。

  这个行为适合多人共用、权限边界复杂的环境。放在单用户、受控的 OpenClaw 实例里，审批会把一次完整请求拆成两轮：第一轮生成，第二轮确认。自动化链路也会因此中断。

  这次调整的目标很具体：用户在飞书里明确提出“安装”或“创建 Skill”时，Agent 在同一轮完成创建和应用；普通聊天不能触发安装；已有的安全扫描继续保留。

  实施时按优先级分成三层：

  1. 配置层把 Workshop 审批策略设为 auto，这是权限基础。
  2. 工作区指令明确“安装/创建”请求包含 apply 授权，这是行为策略。
  3. 如果当前版本仍受内置提示词限制，再对编译产物做兼容补丁。

  三层并非在所有版本里缺一不可。配置和工作区指令相对耐升级，但仍要留意 Schema 迁移或工作区重建；编译补丁只解决特定版本的冲突，升级后很可能被覆盖。本文现场版本为 OpenClaw 2026.9.8，其他版本应先核对实际行为。

  为什么只改 approvalPolicy 还不够

  这次卡住的对象是一个名为 lobster-hub 的 pending 提案。表面看，问题出在审批工具：apply 需要确认。继续往下查，会发现限制分成两部分。

  一部分是工具调用前的硬拦截。当前安装包会读取：

  {
    "skills": {
      "workshop": {
        "approvalPolicy": "auto"
      }
    }
  }
  

  当 approvalPolicy=auto 时，apply、reject、quarantine 等生命周期动作可以跳过强制审批。这一层决定工具是否允许执行。

  另一部分来自系统提示词。当前编译产物仍在告诉 Agent：生成的 Skill 默认保持 pending；只有用户单独提出 approve、use 或 apply，才能执行应用。工具已经放行，模型却仍可能主动停下。

  因此，仅改配置可能出现一种很别扭的状态：门锁已经打开，Agent 仍站在门外等第二句确认。

  工作区指令负责补齐用户意图。用户说“安装这个 Skill”时，合理的任务终点是 Skill 已经 live，而不是只生成一份 pending 提案。编译文件补丁则清掉当前版本提示词里的冲突文案。

  三层方案各自解决什么

  层级	修改位置	解决的问题	升级后是否保留
  配置层	openclaw.json	取消 Workshop 生命周期动作的强制审批	通常保留
  工作区指令层	workspace/AGENTS.md	定义“安装/创建”请求已经包含 apply 授权	保留
  编译文件补丁层	全局 OpenClaw 安装目录的 dist/skill-workshop-prompt-*.js	消除当前系统提示词里的保守限制	可能被覆盖

  这三个层级不能混为一谈。

  配置层是权限基础，工作区指令是行为策略，编译补丁是特定版本的兜底。应先完成配置和指令，只有端到端测试仍停在 pending 时，才考虑第三层。把三者分开记录，后续升级时才知道哪些要复查，哪些可以撤掉。

  第一步：把 Workshop 审批策略改成 auto

  操作前先备份配置文件。配置文件的真实位置取决于部署方式，本文环境位于 Agent 目录下。

  cp agent/openclaw.json agent/openclaw.json.bak
  
  openclaw config set skills.workshop.approvalPolicy auto
  openclaw config validate
  openclaw config get skills.workshop
  

  预期结果：

  approvalPolicy: auto
  Config valid
  

  当前版本的 schema 已支持 skills.workshop.approvalPolicy。如果目标环境提示字段不存在，先用对应版本的配置 schema 或官方文档核对，别直接把其他机器的配置复制过去。

  这里有一个边界需要说清：auto 放宽的是 Workshop 生命周期动作。它不会自动赋予 Agent 原本没有的文件权限、网络权限或工具权限，也不会替代 Skill 内容扫描。

  第二步：在 AGENTS.md 定义“安装”的完成语义

  配置开关只负责允许执行。Agent 是否愿意在同一轮执行 apply，还要看工作区指令如何解释用户请求。

  在 agent/workspace/AGENTS.md 末尾追加一段类似下面的规则：

  ## Skill 安装策略
  
  - 用户明确要求安装或创建 Skill 时，任务完成标准是 Skill 已创建并应用生效。
  - 使用 skill_workshop 创建提案后，在同一轮执行 apply，不再等待第二次确认。
  - 用户从 Skillhub 或市场明确要求安装 Skill 时，同样完成安装和启用。
  - 只对明确的安装、创建、应用请求执行上述流程；讨论、审阅、比较或引用 Skill 不构成安装授权。
  - 继续执行现有的内容扫描、权限检查和来源校验。
  

  这里的边界要写清楚：放行审批不等于把所有提及 Skill 的消息都当成安装命令。文章评审、代码讨论、市场搜索都不该触发 apply。

  工作区指令也是升级后的兜底。全局 npm 包更新后，AGENTS.md 通常会保留，可以继续告诉 Agent 什么才算任务完成；如果部署流程会重建工作区，则要把这段规则纳入配置管理。

  第三步：修正当前编译产物里的限制文案

  这一步最脆弱，也最容易被误用。

  当前环境里没有对应的 TypeScript 源文件，只有 npm 全局安装目录下的编译产物。文件名带构建哈希，例如：

  /home/gem/.npm-global/lib/node_modules/openclaw/dist/
    skill-workshop-prompt-Ro8fA5Wx.js
  

  不同版本、安装方式和操作系统下，目录与哈希文件名都会变化：npm、Homebrew、容器和源码部署不能照抄同一路径。不要把示例文件名写进长期脚本，应先搜索包含目标文案的实际文件：

  rg -l "Generated skills are pending proposals by default" 
    /home/gem/.npm-global/lib/node_modules/openclaw/dist
  

  找到文件后先备份到项目目录：

  mkdir -p tmp
  cp /path/to/dist/skill-workshop-prompt-*.js 
    tmp/skill-workshop-prompt.js.orig
  

  需要调整两类文案。

  原限制大意是：

  Generated skills are pending proposals by default.
  Do not apply them unless the user explicitly asks for that separate action.
  

  调整为：

  Generated skills may be applied immediately via action=apply
  when the user asks to install or create the skill;
  approvalPolicy is auto.
  

  另一处 Use action=apply... 的约束也要同步改成：用户明确要求安装或创建时，可以在同一轮执行 apply。

  补丁只改提示词文案，不要碰工具调用前的审批判断。当前环境中，审批判断已经能识别 approvalPolicy=auto，继续改它只会扩大维护面。

  修改后加载模块做语法验证：

  node -e "import('/path/to/dist/skill-workshop-prompt-实际哈希.js').then(() => console.log('ok'))"
  

  输出 ok 只能证明模块能解析和加载，无法证明运行中的 Gateway 实际引用了这个文件，更无法证明审批链路已经放开。后面还要新建会话或刷新快照，并从飞书做端到端测试。

  还要注意，全局 dist 补丁可能影响同一套 OpenClaw 安装下的其他 Agent，并不天然限定在飞书实例。共享安装环境必须先评估影响范围。

  为什么编译文件补丁只能算临时方案

  全局 dist 目录属于安装产物。npm 更新、OpenClaw 自更新或重新安装都可能覆盖它。

  所以补丁要具备三个特征：

  • 有原文件备份。
  • 有可重复执行的搜索和替换记录。
  • 升级后重新检查目标文案，不能盲目套旧补丁。

  更稳的长期解法是把这类行为做成官方配置语义，让系统提示词根据 approvalPolicy 动态生成。配置为 manual 时强调单独审批；配置为 auto 时，明确允许“安装/创建”请求在同一轮 apply。这样配置和提示词不会互相打架。

  在官方行为完成统一前，配置层和 AGENTS.md 是长期基线，dist 补丁属于版本修复。

  重启前后怎么验证

  skills.* 配置可能触发会话快照重建。为了排除旧快照和热加载残留，本次修改后执行了完整重启。

  具体重启命令取决于部署方式。项目自带 restart.sh 时可以使用它；受托管的 OpenClaw Gateway 应使用平台提供的重启入口，避免直接杀进程。

  重启后检查三组状态：

  openclaw gateway status --json
  openclaw channels status --probe
  openclaw config get skills.workshop
  

  验收关注点：

  • Gateway RPC 返回 ok=true。
  • 飞书 Channel 为 enabled、configured、running、works。
  • Workshop 返回 approvalPolicy: auto。
  • 补丁模块仍能 import。

  命令行健康不代表飞书链路已经成功。最终验收必须从飞书发起。

  端到端测试应该怎么做

  可以先处理已有的 pending 提案。auto 只取消审批拦截，不保证提案一定有效；状态、内容扫描、来源策略、文件权限、插件策略或版本兼容性仍可能阻止 apply：

  把 lobster-hub 提案 apply 生效
  

  随后再做一次完整安装测试：

  安装一个用于验证的 Skill，并在当前轮完成应用。完成后告诉我 Skill 名称和状态。
  

  合格结果应该满足：

  1. Agent 识别出明确的安装意图。
  2. Skill 提案创建成功。
  3. 同一轮执行 apply。
  4. 状态从 pending 变为 applied 或 live。
  5. Skill 能被重新发现，或在新会话中正常调用。
  6. 飞书端没有出现额外审批拦截。
  7. Agent 返回实际状态，而不是只回复“已经开始处理”。

  测试 Skill 应当来源清楚、内容可审阅、权限范围小。验证完成后按正常流程保留或卸载，别拿未知市场包测试自动安装能力。

  放开审批后，安全边界发生了什么

  approvalPolicy=auto 让 Agent 可以把提案直接变成正式 Skill。单用户、可信输入、tools.profile=full 的实例通常能接受这个取舍。多人群聊、公开机器人或输入来源复杂的环境风险会高很多。

  自动 apply 扩大的是代码执行与持久化能力，风险远不止少了一次确认。主要风险包括：

  • 恶意或被污染的 Skill 进入正式环境，读取文件、访问网络或调用现有工具权限。
  • 提示注入诱导 Agent 把“讨论安装”误判为“执行安装”。
  • Skill 写入持久指令后持续影响后续会话。
  • 全局 dist 补丁波及同一安装下的其他 Agent。
  • dist 补丁在升级后失效，行为悄悄退回 pending。
  • 配置、提示词和工作区指令不一致，导致行为难以预测。

  建议至少保留这些护栏：

  • 只在私聊或受控会话开放自动 apply。
  • 限制可安装来源，市场包先做来源白名单和内容审计。
  • 保留 guardian 或等价内容扫描，但不能把扫描当成安全保证。
  • 按最小权限配置文件、网络和外部系统能力。
  • 高风险 Skill 继续要求人工确认。
  • 记录创建、apply、启用和回滚日志。
  • 保留原文件备份和补丁记录，明确备份保留周期。
  • 每次升级后跑一遍端到端回归。

  如果实例服务多人，或者能接触生产凭据、支付、云资源和公开发布渠道，建议继续使用人工审批。省掉一句确认，不值得换来不可控的供应链风险。

  升级后的回归清单

  每次更新 OpenClaw 后检查下面几项：

  [ ] skills.workshop.approvalPolicy 仍为 auto
  [ ] AGENTS.md 的 Skill 安装策略仍存在
  [ ] dist 中限制性提示词是否已经由官方修复
  [ ] 如果仍未修复，旧补丁能否安全重打
  [ ] Gateway 和飞书 Channel 健康
  [ ] pending 提案可以 apply
  [ ] 新 Skill 能从飞书端同轮创建并生效
  [ ] 内容扫描与权限限制仍然工作
  

  如果官方版本已经统一了配置和提示词，就应撤掉 dist 补丁。临时补丁长期存在，会让后续排障越来越难。

  需要回滚时，顺序也应写进变更记录：恢复原始提示词文件，把审批策略改回原值，撤回工作区自动 apply 指令，按部署方式重启或重新加载 Gateway，然后新建会话并确认审批拦截已经恢复。

  最终判断

  这次调整能成立，依赖的是三层职责分离：配置层放开硬审批，工作区指令定义用户意图，提示词补丁修正当前版本的行为冲突。

  真正需要长期维护的是前两层。编译产物补丁只服务于当前版本，必须带着备份、版本记录和升级回归一起使用。

  对于可信的单用户实例，这套方案能把飞书里的 Skill 安装恢复成一次完整任务。对于多人或高权限实例，保留审批更稳。

  10小时前

• 懒人驱动开发：用Claude写个MCP工具，躺床上遥控电脑息屏

  一位科技论坛用户因经常上床后忘记关闭电脑屏幕，借助AI编程工具Claude开发了一款支持MCP协议的屏幕控制小软件，实现躺在床上远程控制电脑的功能。其技术方案为：在电脑端部署MCP（Model Context Protocol，模型上下文协议）服务器，将屏幕亮度和息屏等系统控制功能封装为标准化的MCP工具；再通过组网工具Tailscale将手机与电脑接入同一虚拟局域网，实现安全远程访问。随后用户在手机端通过支持MCP连接的AI助手应用Muse，即可用自然语言指令控制电脑屏幕的亮度调节与息屏开关。整个开发过程由Claude代为编写代码，作者几乎无需手写程序，只需向AI描述需求即可完成从想法到落地的全过程。作者在帖子中展示了这套方案的实用性：睡前躺在床上发现屏幕还亮着，掏出手机说一句话即可远程关闭，无需起身回到电脑前操作。该案例被视作AI编程降低开发门槛的典型缩影，解决的是一个微小但真实的生活痛点，而其技术链路则串联了AI代码生成、MCP协议、Tailscale远程组网与智能体控制等多个当下热门的技术组件，展示了普通用户组合现成工具实现个人自动化的可行路径。

  事件分析

  从技术架构看，该方案的关键在于MCP协议充当了AI智能体与本地硬件之间的桥梁：屏幕亮度、电源管理这类系统级操作被封装为标准化工具，任何支持该协议的客户端都能调用，省去了以往手机控制电脑需要专门App或自建服务的繁琐流程。Tailscale的引入则解决了内网穿透与身份认证问题，使离开家庭网络后的访问依然可行，这一组合正在成为个人级’远程智能体控制’的常见范式。该案例也折射出MCP生态的扩展轨迹，从最初的开发工具、浏览器操作，逐步渗透到硬件控制、家庭自动化等生活场景。随着更多客户端与设备接入MCP标准，AI助手有望演变为个人设备的统一控制层，自然语言管理硬件的形态正从演示走向日常。类似’痛点驱动+AI代写’的开发模式，也可能催生更多社区共享的小型MCP工具集。

  核心观点：AI编程正把定制软件的成本压到接近零，生活中的微小痛点也能成为个人自动化的起点。

  原文链接：Linux.do

  11小时前

• 西蒙斯基金会启动1500万美元计划，助力数学家驾驭AI时代

  西蒙斯基金会宣布启动一项总额1500万美元的专项计划，旨在帮助数学研究者应对人工智能带来的深刻变革。该基金会由文艺复兴技术公司创始人、数学家吉姆·西蒙斯创立，长期资助数学与基础科学研究，是该领域最具影响力的私人资助机构之一。此项计划的推出背景是AI工具正快速渗透数学研究领域：从大语言模型辅助提出猜想、检索文献，到形式化证明系统与AI推理模型在竞赛数学中的突破，传统研究范式正经历显著变化。不少数学家面临工具更新与技能转型的双重压力，同时学界对AI生成内容的可靠性、学术规范等问题也存在分歧。据基金会介绍，该计划将为数学家提供AI工具培训与资源支持，资助探索AI在数学研究中的应用场景，并推动研究者、AI专家与业界之间的跨领域合作，帮助学术共同体在技术变革中保持主动。这一举措被视为传统基础科研资助机构对AI浪潮的制度性回应：与其被动等待技术冲击，不如主动引导AI与数学研究的融合方向。该计划的具体落地方式、资助重点及首批受益项目预计将陆续公布，其对全球数学研究生态的示范效应值得关注。

  事件分析

  技术层面，AI进入数学研究的路径已初步清晰：大模型承担猜想生成与文献综合，形式化验证工具（如Lean）保障证明严谨性，两者结合正在形成新的人机协作研究流程。产业层面，私人基金会以千万美元级资金介入，为AI科研工具生态注入了独立于商业公司的资助来源，可能催生面向学术场景的专门工具、数据集与基准测试。后续走向上，若该计划产出可复用的培训体系与开源成果，其他科研资助机构或跟进设立类似项目；同时，AI与形式化数学的深度融合有望加速数学形式化库的扩张，这些高质量证明数据反过来可成为训练更强推理模型的重要养料，形成学术与AI产业的双向循环。

  核心观点：数学界以制度化资金主动拥抱AI，标志基础科研从被动应对转向塑造人机协作新范式。

  原文链接：Hacker News

  11小时前

• 开源项目为谷歌 Antigravity 补齐 Office 预览：Word、Excel、PPT 编辑区内直接看

  Linux.do 社区用户发布开源项目 antigravity-office-viewer，为谷歌 AI 编程工具 Antigravity IDE 补充 Office 文档预览能力。该项目托管在 GitHub，支持在编辑区内直接预览 Word 文档、Excel 表格和 PowerPoint 演示文稿，官方描述其为一款接近原生体验的高性能 Office 文档预览引擎。发布者按照社区开源推广规范完成全部声明，包括项目完整开源、链接认可社区、AI 生成内容以截图形式公示等，并附带安装、排查与卸载说明，方便开发者按需部署或移除。Antigravity 是谷歌推出的智能体式 AI 编程 IDE，原生功能集中在代码编辑与 AI 协作，此前对 Office 等办公文档缺乏预览支持；当 AI Agent 在工作流中生成或修改 docx、xlsx、pptx 等文件时，开发者往往需要切换到外部应用查看结果。该扩展将预览环节收回编辑器内，减少上下文切换，提升智能体工作流的连贯性。目前项目处于社区早期阶段，功能覆盖三大主流 Office 格式，实际性能与兼容性表现有待更多用户实测验证。

  事件分析

  从技术角度看，此类项目反映出 AI 编程 IDE 的功能边界正由社区快速填补。Antigravity 主打智能体协作，但在办公文档等格式的基础体验上仍有缺口，第三方扩展以轻量方式补齐，说明其插件机制或文件访问接口具备一定开放性。产业层面，AI 编程工具竞争已进入生态比拼阶段：Cursor、Claude Code 与 Antigravity 之间的差距不只取决于模型能力，还取决于周边工具链的完善速度，社区产出扩展的速度将直接影响开发者留存。后续走向上，若 Antigravity 官方将 Office 预览纳入原生功能，此类第三方项目可能被取代；反之，围绕它的扩展生态可能进一步扩张，延伸至 PDF、数据文件等更多格式预览。项目可持续性还取决于维护者对 Office 格式解析复杂度的应对，以及大文件场景下的性能表现。

  核心观点：AI 编程 IDE 的竞争已从模型能力转向生态完整度，社区补位速度正成为平台留住开发者的关键变量。

  原文链接：Linux.do

  12小时前

• GPT重构20万行代码项目遇阻：开发者称工程能力不及Claude

  一位开发者在Linux.do论坛发帖求助，计划使用Codex配合GPT模型重构一个约20万行代码的大型项目。据其描述，该项目存在多重架构问题：业务逻辑冗余繁杂、模块职责划分不清、大量跨项目引用导致耦合严重，每新增一个功能都需要改动多处代码，开发效率低下且消耗大量token。项目原开发者并非计算机专业背景，且大量代码由GPT生成，整体架构基础薄弱。该开发者面临的另一现实困境是：此前一直使用Claude进行开发，但因账号被封禁，被迫转向GPT生态。在实际操作中，其感受是GPT的工程能力明显弱于Claude，使重构工作颇为费心。因此其在帖中向社区征求提示词、Skills或工作流方面的建议，希望借助社区经验提升GPT在大规模代码重构场景下的表现。该帖反映出当前AI辅助开发实践的普遍现状：一方面，AI生成代码在快速产出方面效率显著；另一方面，缺乏架构约束的AI代码在项目规模化后容易积累技术债务，为后续维护和重构埋下隐患。同时，单一AI工具依赖带来的账号封禁风险，也促使部分开发者重新审视多模型并行的备份策略。

  事件分析

  技术层面，大型代码库重构对AI模型的长上下文理解、跨文件依赖分析和架构规划能力要求极高，这正是当前各模型间差异显著的领域。Claude在代码理解与多步骤工程任务上积累的口碑，与GPT形成直接对照，帖主的体验是社区关于模型工程能力对比的又一实证案例。产业层面，该案例暴露出AI编程的两个结构性问题：其一，无架构约束的代码快速生成，正让早期项目集中进入债务偿还期，AI重构本身成为新的需求增长点；其二，开发者对单一模型的深度依赖叠加账号封禁风险，凸显多模型工作流与灵活迁移策略的现实价值。后续走向上，社区预计会沉淀出基于Codex的大规模重构方法论，如分模块拆解、依赖图构建、测试先行的渐进式重构方案，这类实践经验将成为AI工程化应用的重要积累。

  核心观点：Vibe Coding狂欢进入偿债期，AI生成代码的架构债务与单一模型依赖风险正集中显现。

  原文链接：Linux.do

  12小时前