给安卓开源商店提补丁，AI怎么负责用

AI 可以帮你写代码、写说明、整理测试步骤，但如果给 F-Droid 这类开源安卓应用商店做贡献，最终能签名的还是你。根据 Debian 投票结果和 F-Droid 管理员仓库里的讨论，F-Droid 考虑跟进，允许负责任使用生成式 AI，不强制标注，但责任由贡献者承担。这个赛道的关键问题是责任边界，不是工具效率。

第一次做合规贡献，可以先找低风险任务。别一上来改应用代码，去项目仓库找 `README`、`CONTRIBUTING` 或构建说明。新手可以补一段「AI 使用责任说明」。之后在 GitLab 点 `Fork`，把别人项目复制到你自己的空间，不影响原项目，预期地址里多了你的用户名。新建分支，如 `ai-responsibility-note`。分支像临时小路，确认没问题再合回去。用 AI 起草时，提示词可以要求用中文写一段开源项目贡献说明，让贡献者对 AI 生成内容进行理解、审查和测试。别让它写具体版本号，也别让它承诺通过审核。拿到草稿后逐句改成你能解释的版本，问自己这句话我能做到吗，我测试过吗，答不上来就删。本地验证时，只改文档就用 `git diff` 看改动，预期只看到自己改的那几行。若涉及构建说明，按项目文档跑一遍，常见命令是 `./gradlew assembleDebug`，预期出现 `BUILD SUCCESSFUL`。提交 `Commit changes` 时，信息写补充 AI 使用责任说明。最后创建 `Merge Request`，请求维护者把你的分支合并进主项目。描述里列三件事，哪些由 AI 辅助起草，哪些由你确认，你跑过什么命令，不要只写「已测试」。

这样做门槛低，维护者容易审，也能走一遍开源协作流程。风险是 AI 容易把话说满，比如写「已通过全部测试」，你没跑过就是埋雷。它还可能混入不合适的许可证片段，本地能编译不代表能提交。

Debian 这次通过的立场是不背书、不禁止，但贡献者必须能理解、审查、测试，必要时自己修改。

我这边用 WorkBuddy 三周多，最近两周也拿 Claude、Gemini 做过文档辅助，这几天在试云厂商的合规检查能力。经验是 AI 最容易制造虚假自信，它适合整理模板，不适合替你判断。安卓开源应用商店里，应用是否自由开源、有没有广告追踪、依赖是否合规，这些判断不能外包给模型。

最容易踩的坑是许可证混入，要逐段搜索来源，不确定的删除。另一个坑是只测成功路径，最好故意删掉一个环境变量，看构建是否按预期报错。还有提交描述太短，维护者没时间猜你测了什么，把命令和结果写进去。

如果想更轻，可以打开 F-Droid 客户端，找一个常装应用，去源码仓库提一个 issue，也就是项目里的公开提问，问是否计划采用 AI 政策。下一步可以试给常用开源应用补一段「AI 辅助贡献说明」，然后提一个小 MR。