感谢分享，我也写了一个，我的痛点是跨平台同步。

自用+维护的一套 Flutter libs：
---

- view_model： https://pub.dev/packages/view_model 状态/数据管理/共享/依赖注入
- teleport_router： https://pub.dev/packages/teleport_router 基于 go_router 的注解化路由
- state_lifecycle_observer： https://pub.dev/packages/state_lifecycle_observer 复用 State 逻辑，对标 flutter_hooks
- dataforge： https://pub.dev/packages/dataforge bean 类自动生成

人文相机

codex 需要编写详细的 plan 。特别是复杂逻辑，靠聊天聊不清楚，因为 codex 一旦进入思考非常缓慢。根据 plan 生成的效果非常好，基本上是一击即中。

是我的话就不管了，就是这么自私冷漠。斩断和这个家庭的联系，对自己的成长没啥卵用。

挺棒的，不占状态栏的位置

一股浓浓的民科风。像没上过什么学的人学了点知识捣鼓出来的

@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 把视频隐藏了。