软件开发序列设立发文安排
1. 关于发文修改建议：
由“促进多元人才成长”调整为“促进人才多元成长”
FAQ部分，Q4的措辞需要调整。序列合并导向下的多元发展并不是一个0或1的问题，鼓励同学们比原来会得更多，但不是要求同学们所有都会，大家更多是外在-一个更中间的状态.
大模型技术在发文中需要提及，让大家理解公司注意到了并且鼓励这个事情
2．关于大模型技术的理解、应用和推广
a. 这个阶段利用大模型能力把Code Review工具做强
本身它是很有意义的。现在我们如果把这个能力做
的比较好，我们其实是可以极大地加强工程师在
Code Review这件事的效率，以及我们可能可以建
立一个最低标准，让工程师不至于做子这个动作但
其实就是应付一下。
b. 技术委员会的成员要对大模型技术足够拥抱，足够
了解前沿变化。如何帮助工程师团队更快地转型是
一个大而重要的课题。自上而下，我们要在导向、
工具、基础建设等方面开展工作；自下而上，我们
要发掘一线的创造力，将好的尝试找出来推而广
之、发扬光大。
c.在大模型技术的理解与应用上，TC是公司内一个很
重要的驱动力。希望TC带领着公司技术骨干团队先
行动起来，同时鼓励业务线的技术管理者与业务团
队多多“安利”，促进整个组织在大模型技术浪潮下
在开头那句话，就可能还是把促进.星然
后面讲的是帮助大家成长，我觉得这个确实也是
我们培养的方向目标吧，不是局限于非常窄的这
些领域。而且据说现在大模型写码效率提升这个
初步的看法是，未来这种纯写码层面的专业壁垒
应该是更加的被打破，可能未夹更需要这种解决
问题和全栈类的工程师，是否是这样，是吧？这
个也是可以略微有些涉及的。所以Q4我觉得可能
也不是简单的否，或者是就是，在我看来全栈工
程师和这个专业软件开发工程师，大家可能更多
的是处在一个更中间的状态，而不是说…大家也
许容易理解成0或1的问题。
这个我们建议根据业务实际需要来看吧，
确实可能有部分业务，或者说根据如果大模型的
发展，未来有一些情况，其实工程师就是可以全
栈把这活儿千了，我觉得确实是这样-
一个情況。
所以我觉得我们确实没有必要现在在这个上回答
说不是，可能更多是说根据业务实际的情况来
看.有-
一些可能随着人才的融合，他可能就是在
这个业务下，你可以认为他就是全栈，那可能有
- 些可能还是..
或者这样理解，原来4个通道对吧，那相当
于是你要干一个事儿，如果都涉及，可能要四个
人或四个团队，那末来可能三个人或三个团队
他不是说一个全栈工程师解决所有，而是说两个
0.6或者三个0.7这样。全搞其实对我们工程师挑
战是挺高的，但是你比原来搞得更多，你也并不
是所有都全部能搞，我觉得未来可能是这种情
況。你们感觉呢？
