矛盾 核心矛盾: 工资待遇很不错 写代码前要求我先把文档写出来,详实程度要求每个 service 中将会有哪些方法,共有私有 开会的时间占到了工作时间的 50%左右 领导是写代码出身,但每次开会和其他交流中都透露出对"写代码为低级工作,确定业务为高级工作"的看法 我不否认他的某些想法,目前也会尽力完成他想要的东西,只是怕很多矛盾后面会越来越尖锐 最近和其他同事一起下班才知道部门其他同事也对他颇有微词,我进来时替换的这个岗位原来的开发就是被骂跑的
他的看法在大部分公司都是对的，毕竟造火箭的公司不多，CURD 能不能卖钱还是要靠业务。 要是我的话，就想想怎么从代码提取出文档。 要么自己改个 parser ，扫一遍代码列出所有 service 和方法，按照固定格式输出，然后自己添点东西改成文档。 要么找个开源的 LLM ，看看能不能改造集成让它给我生成文档。一般来说这种固定格式的文档，你自己写个服务调个开源的 LLM ，调一下模型或者搞提示词应该能很好的解决。 甚至你也可以反过来用文档生成代码。 都搞定了就可以准备跳槽了。这次再跳至少不会说什么 “公司技术栈陈旧，没有学习机会” 了。
有一说一，没太大问题...写业务代码就是低级工作，根据业务进行设计才是高级工作，只会写业务代码屁用没有。 先写文档还是先写代码就是个风格、习惯的问题，各有优劣。但是在当下，先写一份设计清晰、描述详细的文档，是可以让 AI 快速解决代码的问题的，只要你的文档足够明确，AI 生成的代码跟你直接写的没区别，甚至可能更好，而且在整理思路上还会更优于边写代码边改。
简明版：按照你的领导说的做 --------------------- 本来就是要做设计的，你如果设计的比较清晰，甚至到处文档这部分工作你甚至可以直接让 AI 辅助。 如果“确定业务”意思是“搞清楚需求”，那我觉得优先级要比单纯“写代码”是应该排前面一些。 至于开会 50% 也很正常，如果系统牵扯的人和部门比较多，就是要开会确认的，这些都是得开会确认的。你设计提交上去，估计也是要开会说明，pass 了才可能让你正式写，等到结束了还有回顾时间，50% 很夸张吗，其实还好。 整体来说，按照你这个描述，我觉得你如果想吐槽，可能只是不适应。建议好好适应。
和你有类似经历，之前老板也是对文档要求很高，语句通不通顺都有要求，画图要求都很高，一个文档能改十几遍，确实难受，但确实也有提升，这种情况确实会导致下面员工离职率不低，只能说好好沟通面向老板输出吧，保证写文档时间够和薪资不错就行了
