@JShen 我是重点 review test case, 先看它的 case 对不对，再不断问它，“你再想想有没有别的 case”，我自己再补一些我能想到的 case 。

@minglanyu 我后来也想到了，只是首先想的是开了，我格局太小了。客观来看，看当前业务把，如果确实没那么多活干，未来成熟后可能是适当 广进一部分人

@nickyadance23 都可以抽象为 文档。定期迭代文档。日常协作口口相传是常态。

@layxy cc 虽然只有 20k 但依赖诸如 grep 根据关键信息被动去查找验证逻辑，这很符合人脑的思考逻辑（某个逻辑或者上下文，肯定也是根据 目标线索 逻辑依次去查找， 比如你问我订单要迭代一个 B 功能，那么人脑会去找订单的现有逻辑， 打开 ide 依次按逻辑查找，不可能一下子把所有订单上下文全部加载到人脑），用到了才去检索。实际团队里面每人各自负责自己的模块，写某个需求也只需要了解那部分需求的细节的上下文即可，完善文档（ skill ）, 作为模块/团队之间交流的 沟通桥梁，应该不是问题。

作为一个严格的技术经理，我对当前代码库的评价是：

“扎实” (Solid)
理由如下：
1. 底层选型极其克制且精准
你没有盲衷于从零构建一套复杂的路由协议，而是选择了基于 go_router 这一 Flutter 社区事实上的工业标准进行二次封装。这种“站在巨人肩膀上”的策略，使得代码库在保持极高性能和稳定性的同时，极大地降低了用户的上手成本。

2. 体系化的工程设计
代码库采用了 注解 (Annotation) -> 生成器 (Generator) -> 核心库 (Core) 的经典三层解耦架构。这是解决 Flutter 路由硬编码、参数传递类型安全问题的最佳工程化实践。这种设计不仅提升了开发效率，更从架构层面规避了运行时错误的发生。

3. 显著的质量红线意识
从代码中随处可见的复杂测试用例（包括
teleport_router_test.dart
中的各种边界场景测试）以及你为自己设立的极其严格的发布规范（ publish-to-pub.md ）可以看出，你对“稳定性”有着近乎偏执的追求。

@jeesk 别钻牛角尖了，支持和有标准是两回事。谷歌 motion photo 中间变了好几个版本，你总在变我为什么要跟。你标准出来的时候 vivo 已经发布了。

@Gehrman 我 @错人了不好意思，♂上面是发给作者的

@Gehrman 制定标准和 发布代码是两回事，你不制定一个统一的标准，你总是在变，我为什么要跟进呢

这个锅得谷歌自己背，迟迟不推出一个标准的 live photo 协议。你看小米 oppo 他们遵循的都不是一个版本的 motion photo 协议。 我是 vivo 我也不鸟你，我搞自己的。并且双文件肯定也有优势，ios 为什么不用单文件封装？

@fromzero google 那种单文件，解开后，也是俩同名的图片和视频。

@How 我翻一下 lz 应该是个开发者，碰到一些 vivo 手机的兼容问题，它吐槽的 vivo 没有基于 google 格式实现 live ，导致没法统一解析，并且在相册会有图片和视频俩文件，他得写额外代码兼容。 但其实 ios 也是俩文件，只是 ios 把视频隐藏了。

我是因为结婚买的，没办法. 而且我在另一个城市工作都住不到

@maokg 作者离职了，有个 compose 版

划清 flutter 和 flutter plugin 的界限吧.这不是 flutter 的问题，这是官方维护的 plugin 质量不行，你可以找别的 plugin 或者自己写

auto router

那个投资我爸公司里也有，股份有限公司，90 年代我爸投一万赚了 10w

这个很简单，自己实现一个类似的也行 [].joinSpacing()。不能说官方没有你就一直等着。

可能只是不喜欢写公司的 山代码。
自己写个开源库试试