昨晚我试了一次很实用的远程协作。

躺在床上，我突然想到 ems4j 的 README.md 和 README_EN.md 里，应该补一个知乎专栏链接。这个改动不复杂，但如果按平时的
方式，我还是得打开电脑、进项目、改文件、提交代码、推送远程。

这次我没这么做，而是直接通过 OpenClaw + 飞书 和它对话，让它把这件事做完。

结果很直接：它真的把仓库克fork下来，改了两个 README，最后还创建了一个 Pull Request。

我是怎么做的

整个过程其实很简单。

第一步，我先确认它能不能直接操作 GitHub 仓库，比如fork项目、修改代码、再发起 PR。

第二步，我把项目告诉它，也就是 jerryxiaosa/ems4j，并说明这是我自己的仓库。

第三步，仓库克隆完成后，我让它准备 gh pr create 所需环境。它安装了 GitHub CLI，并提示我完成 GitHub 登录授权。

第四步，授权完成后，我把具体需求发给它：

• 调整 README.md
• 在最下面联系方式里加上知乎专栏链接
• 同步修改 README_EN.md

最后，它直接把改动做好，并创建了 PR。

这件事为什么有意思

这次改动本身不大，只是 README 补一个链接。

但它真正有价值的地方在于：

我不在电脑前，也能把一个真实的代码改动推进到 Pull Request。

这说明 AI 编程助手的价值，已经不只是“帮你写一段代码”，而是开始具备了“替你执行明确开发动作”的能力。

哪些前提很关键

我觉得这类协作要顺，至少要满足 3 个前提：

1. 仓库明确
   要告诉它是哪个项目，最好就是你自己的仓库。

2. 任务明确
   不要只说“帮我改一下”，而要说清楚改哪个文件、改什么内容。

3. 权限打通
   如果你希望它直接提 PR，就得提前把 GitHub 登录和权限链路打通。

我的结论

这次体验让我更确定一件事：

AI 编程正在从“回答问题”，走向“执行任务”。

如果你也在折腾这类远程协作，我建议先从这种小而明确的任务开始试。

如果你也想找一个真实项目试试这种 AI 协作方式，也可以看看我的开源项目 ems4j。

• GitHub：https://github.com/jerryxiaosa/ems4j
• Gitee：https://gitee.com/jerryxiaosa/ems4j

它覆盖后台管理、计费结算、IoT 接入和远程控表，比较适合用来练习真实项目里的 AI 编程协作。欢迎 Star 和交流。