北京
先把当前代码的结果写成详细的功能文档，然后让最新的模型基于功能文档去重写——这是宝玉分享的一种代码重写思路。它绕开的不是重写本身，而是重写时最容易踩的坑：旧代码的结构会一路牵着新代码走。
他的判断很直接：单纯重构，往往还是在原来的框子里打转。把源代码蒸馏成功能文档之后，AI 面对的是逻辑描述，不是旧实现的写法，反而更容易跳出原有结构。
单元测试为什么不好用了
代码实现完全改变之后，原来那批单元测试的处境有点尴尬。它们绑的是实现细节，实现一换，测试跟着失效。宝玉的说法是，以前的单元测试代码不一定能用，也不建议用，因为代码不一样了，单元测试的价值不大。
重心因此转向 E2E（端到端）测试。它看的是最终结果，是黑盒验证，不关心内部怎么写的。重写后的功能对不对，靠它来兜。
顺序上他给了一个明确建议：重写之前，先让 AI 补一些 E2E 测试，覆盖主要流程，重写的时候可以拿来验证。测试先行，重写在后。
E2E 也别贪多
E2E 测试有它自己的代价。运行慢，还容易受环境影响，这两点决定了它不适合全覆盖，也不适合高频跑。
所以策略是收窄：只聚焦核心主流程的验证，保证关键链路能跑通就够了。框架层面，他推荐用 Playwright 这类成熟工具。
还有一句提醒值得记下：重写后的代码需要时间验证才能稳定。这不是一次提交就能收工的事。
整套流程拆开看其实就三步——把现有代码转成功能文档，让 AI 基于文档重写，用提前补好的 E2E 测试守住主流程。比起直接对着旧代码动手，多出来的这一步文档，换的是重写时不被旧结构绑住。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
