让产品自己提 PR：PostHog 工程师把“信号”变成代码的野心

如果产品问题不是写在文档里，而是直接变成一条 Pull Request 呢？PostHog 的 Joshua Snyder 在这次分享中，展示了一条极具野心的路径：让产品信号自动驱动代码改动，工程师醒来只需要看“全绿”的 PR。

最反直觉的一点：不是 AI 写代码，而是产品在“要求”改代码

很多人一听“AI + PR”，第一反应都是：模型又能多写几行代码了。但 Josh 一上来就把方向拧了个 90 度——重点根本不在写代码，而在于“产品信号”。在 PostHog，他们关心的不是模型会不会写函数，而是：用户行为、错误日志、异常指标，能不能自己站出来说——“这里该改了”。

这是一种典型的工程师反直觉时刻。过去我们是先有人发现问题、写分析、提需求，再排期、实现。Josh 讲的却是反过来：信号先出现，系统自动整理成报告，最后直接生成 PR。工程师的角色，从“找问题的人”，变成了“审核问题是否解决的人”。

从信号到 PR：一条看似简单、实际很脏的流水线

Josh 把这套系统称为一个 pipeline，但他说得很坦白：真正难的地方不在概念，而在细节。大致流程听起来很“顺”：收集产品信号 → 把信号内容嵌入（embed） → 生成报告 → 形成代码改动 → 创建 PR。

问题在于，现实世界里的信号从来都不干净。有些是零散的，有些是延迟的，有些根本不具备“可行动性”。他们踩到的第一个大坑就是：系统能生成一堆分析，但工程师看完只会问一句——“所以我要干嘛？”

直到他们开始强制把信号压缩成更具体的上下文，效果才“好得多”。Josh 特别提到，对信号内容做更精确的嵌入后，生成的结果明显更可用。这不是模型突然变聪明了，而是输入终于像工程问题了。

真正的难题：让 PR 变得“值得被看”

即便系统已经能创建 PR，新的麻烦才刚开始。Josh 直言不讳：工程师不缺 PR，缺的是“值得点开”的 PR。如果一个自动生成的 PR 需要人花大量时间理解背景、验证假设，那它本质上还是在制造负担。

他们尝试过很多方式去改进报告质量，但结论有点残酷：越是复杂的问题，越难自动变成“立刻可行动”的改动。系统很容易发现异常，却很难给出一个工程师愿意直接合并的解决方案。

所以他们给自己定了一个听起来很激进的目标：理想状态下，工程师早上醒来，看到的是一堆“全绿”的 PR，只需要做最终确认。这不是为了偷懒，而是为了把人的精力留给真正需要判断的地方。

他们学到的三件事：这条路比想象中快，但也更残酷

在分享的后半段，Josh 回顾了这段探索带来的几个关键认知。第一，构建这样的系统，比传统产品流程快得多——从信号到代码的反馈周期被极大压缩。第二，问题的瓶颈几乎从来不在模型，而在“你到底喂了它什么”。第三，也是最意外的一点：不是所有产品问题都值得自动化，有些问题一旦被强行自动化，反而更糟。

他最后展示了他们目前的进展，并留下一句意味深长的话：现在的结果，可能会“让你惊讶”。惊讶的不是系统有多聪明，而是工程流程还能被重塑到这个程度。

总结

这场分享真正击中 AI 从业者的地方，不在于某个炫技的模型，而在于它重新定义了“谁在推动代码变化”。如果你在做 AI、平台或开发者工具，可以问自己三个问题：你收集的信号，是否真的能指导行动？你的自动化，是否在减少而不是转移认知负担？以及——有没有哪一步，其实可以大胆交给系统先走一轮？未来的软件工程，可能不再是“人驱动代码”，而是“产品自己走到代码面前”。

关键词： 自动化开发， 产品信号， Pull Request， AI 工程， 开发流程

事实核查备注： 需要核查：Joshua Snyder 的姓名与职务；该分享是否明确来自 PostHog；视频发布时间 2026-06-10 是否准确；是否真的使用了“embed the contents of the signal”这一表述；PR 全绿的描述是否为原话或意译。