学完电机公式，我以为能读懂机器人代码了，结果卡在更底层的地方...
Gyroflow 是一款备受关注的开源应用程序，旨在通过利用...
针对ROS 2生态中标准工具robot_localizati...
FusionCore 是一个基于 ROS 2 框架的开源传感...
针对传统饮食记录 App 滞后的痛点，独立开发者推出了名为 ...
一位有多年数据和产品经验的开发者分享了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视频API把创业门槛压到数天量级，独立开发者的胜负手已从技术转向热点嗅觉与工程化交付速度。
原文链接：V2EX 分享发现
在飞书里让 OpenClaw “安装一个 Skill”，Agent 明明已经把提案生成出来，流程却停在 pending。接下来还得再发一句“批准并应用”，Skill 才会进入可用状态。
这个行为适合多人共用、权限边界复杂的环境。放在单用户、受控的 OpenClaw 实例里，审批会把一次完整请求拆成两轮：第一轮生成，第二轮确认。自动化链路也会因此中断。
这次调整的目标很具体：用户在飞书里明确提出“安装”或“创建 Skill”时，Agent 在同一轮完成创建和应用；普通聊天不能触发安装；已有的安全扫描继续保留。
实施时按优先级分成三层：
auto，这是权限基础。三层并非在所有版本里缺一不可。配置和工作区指令相对耐升级，但仍要留意 Schema 迁移或工作区重建；编译补丁只解决特定版本的冲突，升级后很可能被覆盖。本文现场版本为 OpenClaw 2026.9.8，其他版本应先核对实际行为。
这次卡住的对象是一个名为 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 时，才考虑第三层。把三者分开记录，后续升级时才知道哪些要复查，哪些可以撤掉。
操作前先备份配置文件。配置文件的真实位置取决于部署方式，本文环境位于 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 内容扫描。
配置开关只负责允许执行。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
验收关注点：
ok=true。enabled、configured、running、works。approvalPolicy: auto。命令行健康不代表飞书链路已经成功。最终验收必须从飞书发起。
可以先处理已有的 pending 提案。auto 只取消审批拦截，不保证提案一定有效；状态、内容扫描、来源策略、文件权限、插件策略或版本兼容性仍可能阻止 apply：
把 lobster-hub 提案 apply 生效
随后再做一次完整安装测试：
安装一个用于验证的 Skill，并在当前轮完成应用。完成后告诉我 Skill 名称和状态。
合格结果应该满足：
测试 Skill 应当来源清楚、内容可审阅、权限范围小。验证完成后按正常流程保留或卸载，别拿未知市场包测试自动安装能力。
approvalPolicy=auto 让 Agent 可以把提案直接变成正式 Skill。单用户、可信输入、tools.profile=full 的实例通常能接受这个取舍。多人群聊、公开机器人或输入来源复杂的环境风险会高很多。
自动 apply 扩大的是代码执行与持久化能力，风险远不止少了一次确认。主要风险包括：
建议至少保留这些护栏：
如果实例服务多人，或者能接触生产凭据、支付、云资源和公开发布渠道，建议继续使用人工审批。省掉一句确认，不值得换来不可控的供应链风险。
每次更新 OpenClaw 后检查下面几项：
[ ] skills.workshop.approvalPolicy 仍为 auto
[ ] AGENTS.md 的 Skill 安装策略仍存在
[ ] dist 中限制性提示词是否已经由官方修复
[ ] 如果仍未修复，旧补丁能否安全重打
[ ] Gateway 和飞书 Channel 健康
[ ] pending 提案可以 apply
[ ] 新 Skill 能从飞书端同轮创建并生效
[ ] 内容扫描与权限限制仍然工作
如果官方版本已经统一了配置和提示词，就应撤掉 dist 补丁。临时补丁长期存在，会让后续排障越来越难。
需要回滚时，顺序也应写进变更记录：恢复原始提示词文件，把审批策略改回原值，撤回工作区自动 apply 指令，按部署方式重启或重新加载 Gateway，然后新建会话并确认审批拦截已经恢复。
这次调整能成立，依赖的是三层职责分离：配置层放开硬审批，工作区指令定义用户意图，提示词补丁修正当前版本的行为冲突。
真正需要长期维护的是前两层。编译产物补丁只服务于当前版本，必须带着备份、版本记录和升级回归一起使用。
对于可信的单用户实例，这套方案能把飞书里的 Skill 安装恢复成一次完整任务。对于多人或高权限实例，保留审批更稳。
一位科技论坛用户因经常上床后忘记关闭电脑屏幕，借助AI编程工具Claude开发了一款支持MCP协议的屏幕控制小软件，实现躺在床上远程控制电脑的功能。其技术方案为：在电脑端部署MCP（Model Context Protocol，模型上下文协议）服务器，将屏幕亮度和息屏等系统控制功能封装为标准化的MCP工具；再通过组网工具Tailscale将手机与电脑接入同一虚拟局域网，实现安全远程访问。随后用户在手机端通过支持MCP连接的AI助手应用Muse，即可用自然语言指令控制电脑屏幕的亮度调节与息屏开关。整个开发过程由Claude代为编写代码，作者几乎无需手写程序，只需向AI描述需求即可完成从想法到落地的全过程。作者在帖子中展示了这套方案的实用性：睡前躺在床上发现屏幕还亮着，掏出手机说一句话即可远程关闭，无需起身回到电脑前操作。该案例被视作AI编程降低开发门槛的典型缩影，解决的是一个微小但真实的生活痛点，而其技术链路则串联了AI代码生成、MCP协议、Tailscale远程组网与智能体控制等多个当下热门的技术组件，展示了普通用户组合现成工具实现个人自动化的可行路径。
核心观点：AI编程正把定制软件的成本压到接近零，生活中的微小痛点也能成为个人自动化的起点。
原文链接：Linux.do
西蒙斯基金会宣布启动一项总额1500万美元的专项计划，旨在帮助数学研究者应对人工智能带来的深刻变革。该基金会由文艺复兴技术公司创始人、数学家吉姆·西蒙斯创立，长期资助数学与基础科学研究，是该领域最具影响力的私人资助机构之一。此项计划的推出背景是AI工具正快速渗透数学研究领域：从大语言模型辅助提出猜想、检索文献，到形式化证明系统与AI推理模型在竞赛数学中的突破，传统研究范式正经历显著变化。不少数学家面临工具更新与技能转型的双重压力，同时学界对AI生成内容的可靠性、学术规范等问题也存在分歧。据基金会介绍，该计划将为数学家提供AI工具培训与资源支持，资助探索AI在数学研究中的应用场景，并推动研究者、AI专家与业界之间的跨领域合作，帮助学术共同体在技术变革中保持主动。这一举措被视为传统基础科研资助机构对AI浪潮的制度性回应：与其被动等待技术冲击，不如主动引导AI与数学研究的融合方向。该计划的具体落地方式、资助重点及首批受益项目预计将陆续公布，其对全球数学研究生态的示范效应值得关注。
核心观点：数学界以制度化资金主动拥抱AI，标志基础科研从被动应对转向塑造人机协作新范式。
原文链接：Hacker News
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 的竞争已从模型能力转向生态完整度，社区补位速度正成为平台留住开发者的关键变量。
原文链接：Linux.do
一位开发者在Linux.do论坛发帖求助，计划使用Codex配合GPT模型重构一个约20万行代码的大型项目。据其描述，该项目存在多重架构问题：业务逻辑冗余繁杂、模块职责划分不清、大量跨项目引用导致耦合严重，每新增一个功能都需要改动多处代码，开发效率低下且消耗大量token。项目原开发者并非计算机专业背景，且大量代码由GPT生成，整体架构基础薄弱。该开发者面临的另一现实困境是：此前一直使用Claude进行开发，但因账号被封禁，被迫转向GPT生态。在实际操作中，其感受是GPT的工程能力明显弱于Claude，使重构工作颇为费心。因此其在帖中向社区征求提示词、Skills或工作流方面的建议，希望借助社区经验提升GPT在大规模代码重构场景下的表现。该帖反映出当前AI辅助开发实践的普遍现状：一方面，AI生成代码在快速产出方面效率显著；另一方面，缺乏架构约束的AI代码在项目规模化后容易积累技术债务，为后续维护和重构埋下隐患。同时，单一AI工具依赖带来的账号封禁风险，也促使部分开发者重新审视多模型并行的备份策略。
核心观点：Vibe Coding狂欢进入偿债期，AI生成代码的架构债务与单一模型依赖风险正集中显现。
原文链接：Linux.do