茨木シンフォニーさん

AIまるだしイラスト使ってるゲームは、例えおもしろくてもやる価値無しと見做します！ イラストを描く、もしくは外注する情熱が無いってことやろ？ 他も手ぇ抜いてると考えるのが妥当よな？

关于日企的Excel有多么恶心，简单拿考勤系统来举个例。按我的理解，正常情况下，完全可以建立一套员工考勤的数据模型。 每个员工有自己的ID，每天对应一条或者多条考勤记录，记录日期、工作状态、起止时间等属性。 出差可以有目的地，在家办公可以有工作计划和实际工作内容，请假可以有假期类型。 在中美任意一家大厂工作过的员工应该都知道，这些都是可以结构化定义的数据。用Python定义业务对象，配合关系型数据库保存数据。 虽然每个企业具体做法可能不同，但大部分日企通常会先建一个属于2026年的Excel文件，里面12个Sheet，每个Sheet对应一个月。每个月再按照人数建立不同的行，列则对应日期。 然后由每个课特定的办事员手动维护每年默认的休假出勤状态，再由每个员工每天手动填写当天是上班、休假、出差还是在家办公等信息。 整个系统的数据结构实际上就是由这个Excel 模板决定的。月份、日期、人员、状态都被固定在工作表的行列位置上。到了2027年，再由办事员重新建一个文件。 如果需要新增员工、修改考勤类型、增加某个状态的属性，就要修改模板。如果不同年份的文件结构还不一样，后续的数据汇总和维护就更加麻烦。 更操蛋的是，这只是总表。 如果我今天要在家办公，还需要另外打开一个Excel文件，填写今天的工作时间、预定工作内容和实际完成的内容。 明明前面已经在考勤总表里填过自己的姓名、日期和工作状态，到这里还得重新填一次。 填完以后，还要到Teams里面给领导发消息，告诉他今天在家办公。 同一件事情，员工需要在几个完全不同的地方重复操作。但这些文件和消息之间并没有可靠的数据关联。 而且最操蛋的是，随着领导的更换，这些流程还会变。 如果有一个正常的后端系统，这些问题根本不需要这么处理。 员工在前端提交在家办公申请，后端保存一条记录，关联员工ID、日期、时间和工作计划。系统根据业务规则执行审批，再调用接口向领导发送Teams通知，必要时同步Outlook Calendar。 至于管理人员需要什么格式的考勤总表、工作计划表、月度报表，完全可以根据数据库中的记录自动生成Excel。 这样即便领导变了，就按领导要求输出领导想要的数据即可。而员工只需要录入一次相同的信息。这就是数据复用。 在日企里，Excel文件既是数据存储，又是数据结构，又是输入界面，还在单元格里塞进各种业务计算逻辑。数据、业务逻辑和用户界面全部耦合在一起。 肯定会有精日抬杠说可以通过锁定单元格、添加校验规则、编写VBA来实现。但系统越来越复杂以后，公式如何维护？权限如何管理？不同文件之间的数据如何保证一致？修改历史如何追溯？多个员工同时修改时如何处理冲突？ 本来在数据库和后端可以集中实现的功能，却需要在不同的Excel文件里分别维护。而且Excel文件通常只能反映某个时间点的表格状态。 领导如果需要查询某个员工过去三年的在家办公记录，或者统计所有部门某种考勤状态的变化，就需要重新读取和解析大量文件。 一个合理的系统根本不需要把年份和月份设计成不同的文件和Sheet。日期就是数据字段，查询哪个时间段，就从数据库里读取哪个时间段的记录。需要按月显示，再由前端或者报表程序按月组织即可。 数据应该独立于展示形式存在，而不是由展示形式决定数据结构。 这也是SSOT的问题。同一个员工、同一个日期、同一种考勤状态，本来应该在系统里有唯一可信的记录，而不是在考勤总表、在家办公申请表、工作报告和Teams消息中分别存在几份互不关联的数据。 这些数据一旦出现矛盾，到底哪一份才是正确的？ 日本企业缺乏数据库、后端服务和统一的数据管理机制，才被迫让员工使用无数个难以忍受的Excel承担整个系统的数据管理工作。 日本企业所谓的系统集成，很多时候实际上就是员工本人在充当不同系统之间的API。 一个系统的数据不能自动传递到另一个系统，就让员工打开文件，复制、粘贴、填写，再发邮件通知下一个人。 一个但凡稍微懂点技术的人在日企工作，都需要无时无刻提醒自己，公司是否盈利、效率高低都与自己无关，工作只是为了一份工资而已，不然的话真的会被无数个Excel逼疯。

なんでAI絵師がリポストされたりいいねされるか自分にはわからないんだ。 独自のプロンプトを打ち込んでいるというのはすごいと思うのだけど、その絵柄はAIを教育するために読み込まれた様々なイラストレーターの過去の作品があるからこそで、プロンプトを打ち込んでいるその人自体の絵柄ではないよね

両方話せばわかるタイプなことあるんだ