让自动化自己改自己的 prompt：GitHub 把"人接不接受"变成了训练信号

【摘要】10 月 28 日 GitHub Universe 上，Copilot Automations 多了一个叫"自我改进"的能力：自动化从自己在 GitHub 上留下的痕迹里学习——issue 分诊看人有没有改它打的标签，code review 看开发者接不接受它的评论——然后提出对自己 prompt 的改进。你批准，它才生效。这套设计聪明在把"这个自动化做得好不好"这个一直没人能量化的问题，翻译成了一个 GitHub 原生就有的信号。但它有个反身性陷阱：信号的质量取决于人review的诚实程度，而人不review才是最常见的真实行为。

目录

一、一个自动化怎么知道自己做得好不好
二、它具体学什么，改什么
三、"自我改进"这个词被抬高了
四、那个反身性陷阱：没人 review 的时候会发生什么
五、personal 和 shared 的差别，不只是谁能看见
六、透明运行：个人的 automation 也是公开的
七、默认的安全动作，值得单独抄一遍
八、我现在还不会开这个功能

一、一个自动化怎么知道自己做得好不好

先说清楚这东西要解决什么问题。

GitHub 的原话很实在：

It’s easy to create an automation, but harder to build one you can trust to consistently produce high-quality results.

创建一个自动化——填个 prompt、选个触发器、勾几个工具，十分钟。但让它持续产出高质量结果，是另一回事。传统办法是人工看输出、手改 prompt、再人工看输出。这个循环的瓶颈不是模型能力，是人。

GitHub 的观察是：证据其实已经在 GitHub 上了。

它举了三个例子，每一个都是把"自动化好不好"翻译成一个二元信号：

这个翻译很关键。因为它不需要额外的基础设施——不需要人给反馈打分，不需要标注队列，反馈是工作流本身的副产品。你本来就要合并 PR，本来就要改标签。

于是自我改进的机制就顺理成章了：自动化的产出 → 人或自动化的下游行为 → 变成信号 → 回灌 prompt。

二、它具体学什么，改什么

改造的对象是原自动化的三样东西：

• prompt
• tools
• triggers

第三样最值得注意。改触发器意味着自动化可以自己决定什么时候该跑——比如发现"只有当 PR 超过 500 行改动时才值得深审"，就把触发条件收窄。

GitHub 还举了一个"主动求助"的场景：当自动化在工作中遇到问题（比如缺少某个工具），它也可以主动提出改动建议，不等下一次定期分析。

工作方式是成组的。GitHub 官方的例子：让 Copilot 搭一个自改进的 code reviewer，它会创建一组协作的自动化——

• 一个 review 自动化：PR 一开就触发，review 完发评论
• 一个每周的改进自动化：分析开发者对这些评论的实际反应，提出对 review 自动化的改进

改进自动化把建议提出来，GitHub 发通知给你，你逐条 accept 或 reject。只有 accept 了才真的应用到原自动化上。

这里有个必须强调的点：改进建议不是自动应用的。 整个闭环里始终有人在环上，这是设计上的硬约束，不是可以绕过的默认值。

同一批发布里还有几个相关的：

• VS Code 1.144 起，编辑器里建的自动化可以在云端跑——笔记本关了也继续
• 新增 24 个 GitHub 事件触发器和 20 个新 GitHub 工具
• REST trigger 让外部系统能触发；自定义 MCP server 工具让自动化能调你自己的东西
• AI credits 限额：可按单次运行 / 天 / 周 / 月设上限

三、"自我改进"这个词被抬高了

说句不客气的：这不叫自我改进，这叫 prompt 自动优化。

它没有梯度，没有 RLHF，没有更新任何权重。它改的就是一段 prompt 文本。 整个机制可以概括成：

每周跑一次 LLM，把过去一周的信号喂进去，让它输出一个更好的 prompt，人批准。

把它叫 “self-improving automations” 有点抬价。但这不是贬义——它的实用价值恰恰来自这个朴素：改 prompt 是当前技术条件下最可控、最可回滚、最容易审计的"学习"形式。改权重做不到这一点。

对比一下 DeepSeek 那篇（我下一期会写）里的 Creator Mode——那个是 agent 现场写代码装进运行环境。这个是每周优化一段文字。两者都不涉及模型本身的变化，但风险量级差得很远：一段 prompt 改错了，回滚就行；一个 agent 生成的插件装进了运行时，回滚的代价大得多。

四、那个反身性陷阱：没人 review 的时候会发生什么

这是我读完整份文档后最在意的地方。

自我改进的质量，完全取决于信号的质量。而信号来自人的行为。问题在于：人懒于 review，是所有自动化系统里最一致的行为模式。

设想一个 code review 自动化：

• 开发者看到它的评论，大部分时候既不接受也不拒绝——直接忽略，或者心烦但懒得回
• 改进自动化看到的是：这些评论既没被接受，也没被明确否决
• 它怎么解释这个信号？

这是 GitHub 没有回答的问题。 文档没有说明：

• 信号保留多久
• 改进自动化的运行节奏能不能改（官方例子是每周）
• "接受"这个动作的判定标准是什么（PR 合并 = 接受？评论被 resolve？点赞？）

而这三个细节直接决定收敛速度。如果信号是"评论被 resolve 或被回复"，那么"没人管的评论"是明确的负信号，循环会朝"少发评论"收敛——这可能是好事（减少噪音），也可能是坏事（学成闭嘴）。如果信号是"评论被点赞或被采纳"，那沉默的开发者贡献的是中性信号，改进自动化拿到一堆噪声去优化 prompt，结果只会越改越随机。

我倾向于认为现在的实现偏向前者（沉默=负信号），因为这是可判定的；但文档没说，这是我的推测。

结论：这套东西在没有真实 review 文化的团队里，会把"没人用"误读成"做得不好"。 而它的修正方向是"更少说"，不是"更准"。这是自动优化 prompt 的通病——优化目标很容易被优化成"最不容易被拒绝"。

五、personal 和 shared 的差别，不只是谁能看见

这一批发布里加了一件事：共享自动化（shared automation）——属于仓库，不属于某个人。

表面差别是可见性和计费：

• Personal：只有你能看见和编辑。AI credits 记在你头上，在 GitHub 上的操作使用你的身份。
• Shared：所有有仓库访问权的人都能看见。AI credits 记在组织或仓库所有者订阅上，在 GitHub 上的操作使用 Copilot 的身份。
• 类型创建后不能改。

但真正的差别在权限模型，而且这个差别很实在：

Shared 用 Copilot 的身份操作 → 如果你的仓库规则要求至少一个 PR approval，Copilot 开的 PR 默认还需要额外一次人工批准。管理员可以在 rulesets 里关掉这个额外要求，但不能在 branch protection rules 里关。

Personal 用你的身份操作 → 它做的动作记在你名下，你的审批权就是它的审批权。

这两者在同一个仓库里的风险完全不是一回事。 共享自动化以 Copilot 身份行动、且被默认要求额外批准；个人自动化以你的身份行动、可以自己 approve（但那样 PR 就没人真正把关了）。

我的建议是：凡是会自动改代码的，先用 shared。 它慢一点，但多了一道 Copilot 无法自己跨过的审批门。个人自动化留给只读、只发通知的场景。

六、透明运行：个人的 automation 也是公开的

这条文档里写得比较轻，但我觉得该加粗。

Cloud agent sessions started by any automation, personal or shared, are visible to everyone with read access to the repository. Anyone who can see these sessions can see the prompt, the session logs, and any pull request or other changes it creates.

个人 automation 也是公开的。 所有有仓库读权限的人都能看到：prompt 原文、session 日志、它创建的每一个 PR 和改动。

很多人以为"personal"就是"只有我能看"。不是。 personal 指的是只有你能编辑和配置，不是只有你能看。

文档自己也警告了：

Don’t include secrets or other sensitive information in your prompts.

我把这条翻译得更狠一点：prompt 会被写进日志、会被所有人读到、可能被搜索引擎索引、会被离职的人带走。 别在 prompt 里写任何你不愿意让全公司看的字符串。这不是"最好别"，是"别"。

七、默认的安全动作，值得单独抄一遍

这次发布里有几条默认行为的说明，写得很具体。我认为这几条是整个发布里最值得抄走的部分——哪怕你不用 Copilot Automations：

① 忽略不可信触发者的事件。

By default, automations ignore events triggered by users without write access to the repository, to reduce the risk of prompt injection from untrusted input.

没有写权限的人触发的事件默认不处理。这是针对 agent 最常见的攻击面设的第一道闸。

② workflow runs 需要人批。

GitHub Actions workflows don’t run on a pull request until a user with write access approves it.

自动化开的 PR 触发的 CI，必须有人批准才跑。这挡住了"agent 改代码 → CI 里带毒 payload → 偷密钥"这条链。

③ 工具权限是你选的白名单。

You choose exactly which tools an automation can use, so you can limit the automation to only the actions the task requires.

不是给一个"能做什么"的描述，是给一个具体清单。这是对的抽象层级。

这三条合起来是一个完整的威胁模型设计：不可信输入不进 → 有限工具可用 → 产生的变更需要人批才能触发副作用。

我自己写的那些自动化（探针、报告、维护脚本）已经在实践第 ① 和第 ③ 条，但第 ② 条我没做到——我的 cron 脚本是直接执行的，没有人工批准这道门。这是我该补的。

八、我现在还不会开这个功能

理由不是不信任它，是信号条件还不具备。

我手上那些自动化——NAS 探针、docker 更新看门狗、GitHub 趋势监测——它们的产出没有人 review。我看了就接受或接受，因为它们要么准要么我会立刻发现不准。这种"接受率 100%"的信号，对自动优化来说是毒药：改进自动化会学到"保持现状"，因为没有任何拒绝事件告诉它往哪改。

等这些自动化的输出真正进入一个有人会 reject 的循环——比如趋势报告真的会因为某条不相关而被人说"这条别推了"——自我改进才有意义。

还有一个更实际的理由：它的效果没有被证明。 GitHub 的描述全是例子（“for example, an issue triage automation can learn from…”），没有给出任何实测结果。对 review 质量的提升、对分诊准确率的改变，目前是未确立的。

而另一件事是确定的：这批发布里 GitHub 把该有的控制项都做进产品了。 审批门、工具白名单、不可信输入过滤、信用额度上限、会话可见性——这些都是团队原本得自己搭的周边，现在变成产品功能。这个方向的确定性比自我改进本身高得多。

一句话：GitHub 把"自动化好不好"这个一直没人能量化的问题，翻译成了工作流里现成的二元信号，这是聪明的一步。但它把"人诚不诚实地 review"当成了隐含前提，而人往往不 review——这是这套机制真正的成败所在。

留言区：你们的自动化产出有人 review 吗？如果有，是怎么处理的——直接改 prompt，还是攒成反馈？以及，你觉得"沉默"对一个自动化系统来说，应该算成功还是失败？