OldCarMan

ID:327 谢谢

@zhdzb 哈哈，你写的我没用过，得写一个我用过能无缝过渡的😂
@abox 没用过 ai 做过这个，不过我感觉跟写代码一样，都是慢慢进化的，会越来愈好的；建议多关注，相信以后 ai 会大幅各种职位的效率的，特别是做新产品/新功能时，没有历史包袱。从我个人角度来看，我主要是反感用 ai 输出的产品内容不落实细节，乱搭线，不关注产品的功能连接，又或不简洁等等，我建议用 ai 写之前得深刻理解业务，历史关联等，另外加强 ai 写产品的技能。
@USNaWen 真棒👍

@Solix 2 已经很不错了，另外团队应该配合越来越默契了。
@runtime0 ai 本该成为提供工作效率的工具，这样变成一些人偷懒的工具了，个人觉得长期以往，团队的问题早晚会爆发。除非 ai 能成为一个比较完美的超级个体工具，上下游岗位，啥都能用 ai 做的不错。
@runtime0 话说你们一个常规的需求（定义：一个产品花多少天做出来的需求）的完整开发周期是多久
@xyzlucky 很强，很羡慕团队里面有这样的产品。真心话，如果需求周期要求温和，产品都能像你这样，应该能够降低大量下游岗位的沟通成本。
@LoongCLL 所以产品在这个过程扮演了什么角色😅，看起快速迭代，实际上开发周期估计也少不了多少，后期埋坑估计也不少。据我观察，一般团队里，都会有一个只管向上汇报的传话筒，上面说什么就迎合，不消化需求，形成产品，最终问题都流传到下游岗位。
@shawn4me 加油，多沟通吧，实在无法继续沟通，只能多提升自己，早日换个正常点的团队了。

@adimn 啊？深表同情，听你这么说，对面感觉不像一个产品。说到开会，不得不吐槽另外一点，在我们产品的认知里：开一个 1-3 小时的会，会上所有谈过的内容表示你都掌握了，ta 花一周做的需求，会后敢问某些原型上没量化的细节，跟仇人一样。😂

@cairnechen 谢谢回复，理解，快速迭代时是这样的，文字表达问题不大，主要是逻辑清晰，结构化表达，语言精炼，纲要叙事线路明朗。是的，磨合和沟通是必要的。

🤔个人觉得可以这样，4 步走：

1.解决业务可扩展性问题：可以让前端使用图片编辑器生成图片信息，如果业务需求是后续不可编辑可以生成截图保存，如果是可编辑的可以把整个编辑后的图片 html 保存，建议把其上传到对象存储；

2.前端将图片编辑结果提交给后端服务，后端将 html 信息+业务参数封装，丢到消息队列里面。

3.html->图片，这一步可以考虑各种各样的处理方式，根据自己的要求(比如性能要求)去搜索相关的库，比如 html to image java/nodejs/c++/rust 等等，生产完将结果上传并丢回消息队列里面，这个胶水层服务提供：消息队列消费，生产；图片处理；图片上传的服务。

4.后端服务消费胶水层服务产生的图片 url

目的：1.解决扩展性； 2.吞吐量； 3.图片业务与主业务的解耦，数据量大时，图片业务硬件资源吃的较多，可以单独升级图片处理服务。

之前我提过类似的问题，可以参考下：
https://www.v2ex.com/t/920810

不过个人觉得，可能对于大部分人，只是看看相关的库在开源社区的数据表现，以此作为使用的判断条件，有时间和能力当然在使用前 review 一下最好，反之，如果有这个担心，可以先在隔离环境先跑一下，观察存不存在使用异常，或者做好环境监测，尽量做到快速反馈和现场保护。

@letsky 谢谢回复
@luckykev1n 谢谢回复，你 2 楼回复的：
ParameterizedType paraType = (ParameterizedType) listenerType;
类型无法转换（ java.lang.ClassCastException: class java.lang.Class cannot be cast to class java.lang.reflect.ParameterizedType ）。

1.

2.

3.


可能我没描述好，我说的是，我在另外一个类 Cache.java 里面接收 UserListener 时，无法获取到泛型接口 UserListener<T extends User>相应的泛型 T 类型:
public class Cache{
-----

public static void addUserListener(UserListener<T extends User> userListener){

在这里无法直接获取得到 userListener 的相应的泛型 T 类型

}

-----

}

谢谢回复。不过这样会不会不大规范，毕竟代码扩散到各种地方，维护管理起来比较麻烦。😂