前情提要: https://www.v2ex.com/t/1211896#reply101
其实已经过了一段时间了. 但是一直太忙所以现在才写出来。
省流太长不看版本: 没做完
虽然老板给了一个月时间,但并没有暂停其他产品需求, 估计没想到。产品经理也不知道这件事,所以产品需求还是照常排期、照常交付。导致重构前几周基本没有实质进展,大家还是在做原本的业务需求。
到了 ddl 前一周的周五周会,老板发飙,要求必须在期限内完成,做不完就走人。而且他的要求变了, 不是小范围整理代码或抽离部分模块,而是要把一个大单体服务拆成多个微服务。至于服务之间的历史依赖、数据依赖、业务边界、灰度方案、回滚方案、测试覆盖这些问题,因为当时气氛的原因没有讨论, 后面也没空讨论了。
其中一个组把任务交给了一个刚入职不久的新人。DDL 前几天,组长不知道为啥在老板也在的大群里 at 新人的导师,问当前进度如何。导师回复说进度不理想,时间紧、任务重,需要更多支持。被老板看到了, 出来发话说:你这就是不会用 Agent 。你可以让 Agent 去做嘛, 读代码、生成测试用例,然后你人看下方案有无问题,把边界和方向定好,一个晚上就能写完了。
到了 DDL 当天上午,项目经理在 TL 群(无老板的)里要求大家汇报进度。一个 TL 向项目经理质疑,说这本身就是一个不合理的需求,目前大家做的东西根本不能称为重构,甚至方向都是偏的。项目经理很礼貌地请他把这个观点发到老板在的大群里。这个 TL 回复说可以。之后这个群没有下文,老板在的大群也没有新的信息。
到了下午,项目经理在老板在的大群里 at 全员要求汇报进度。大家纷纷表示自己模块已经完成了重构,对应的微服务也已经实现完成。我不知道是不是真的, 反正我没做完, 但我随大流。
实在好奇就去看了一下:
新人负责的服务,建了一个仓库,里面有个 HTTP client 接收。没了。
上午说“这不是重构”的 TL ,我没找到对应模块的仓库。
但这并不妨碍大家说自己已经做完了, 反正也没人细究。而老板表示很满意,随后约了第二天的会议,要求大家分享这次使用 AI 重构的经验。
在第二天会议上,几个人分享了一些 Agent 使用经验, 就是一些让 Agent 自己记录错误、形成 loop 、不断修正之类的常规方法。
最后老板做总结,说这次实践是公司通往 AI 原生的一大步。大家鼓掌撒花....




