悲观者正确，乐观者前行。宝玉老师提出了很多条质疑的点，本着严谨交流的态度，我不介意一一回复。这篇文章内容涵盖了大量软件工程，因为我们希望把自己AI First如何实践落地的理念分享出来，而不仅仅是一些形而上concept的内容。至于其他AI First的实践，由于篇幅和文章重点无法涵盖所有。

发布时间: 2026-04-14 17:20:15

1分

数据加载中

悲观者正确，乐观者前行。
宝玉老师提出了很多条质疑的点，本着严谨交流的态度，我不介意一一回复。
这篇文章内容涵盖了大量软件工程，因为我们希望把自己AI First如何实践落地的理念分享出来，而不仅仅是一些形而上concept的内容。至于其他AI First的实践，由于篇幅和文章重点无法涵盖所有。
时政
( twitter.com )

悲观者正确，乐观者前行。
宝玉老师提出了很多条质疑的点，本着严谨交流的态度，我不介意一一回复。

这篇文章内容涵盖了大量软件工程，因为我们希望把自己AI First如何实践落地的理念分享出来，而不仅仅是一些形而上concept的内容。至于其他AI First的实践，由于篇幅和文章重点无法涵盖所有。

第一，AI提交代码是不需要全部人工回归一遍的。我们会拆细每次PR的影响范围，基本都只会涉及某个功能模块，而不是大范围的修改，这在手写代码时也是基本的软件开发协作规范。
在符合软件工程协作规范下的情况下，AI提交的代码修改完全可以被自动化测试覆盖，不需要担心它会搞崩别的功能。

第二，我们中间的测试/审查/发布确实做到了全部自动化跑通了，所以我们做到了今天这个迭代效率。

第三，我们每次A/B测试的线上监控基础设施也都是完善的，有充足的数据支撑我们做判断。我建议你学习了解下statsig。

第四，你为什么会把大而模糊的任务丢给AI？这个问题非常奇怪，我相信如果你做过管理，也不会把大而模糊，自己都没想清楚的任务丢给员工吧。

第五，系统架构的设计是任何软件工程团队的基本功了，拿出这一条来悲观质疑真的很像在抬杠。

结论是，我们全都做到了。

关于你提到的claude code和codex团队是否有这么搞的问题，事实上我们就是观察到了claude团队极其夸张的迭代效率，以及OpenAI工程团队在今年二月份的分享得到的灵感：https://t.co/ym1wzNQOX5…
你觉得他们有没有也在用这一套呢？为什么你如此笃定AI交付和功能质量必然在对立面？

我们的分享来自于团队脚踏实地实践后的经验，关于我们目前做到了怎样的迭代效率，请看产品changelog：https://t.co/JyZwCJnvLt…