个人觉得大屏这种烂大街的东西真的没必要搞，这种东西就是面子工程，我 19 年毕业的时候和低代码一起吹出来东西，看似页面酷炫，实际 low 的不行... 各种国产化和信息化衍生出来的东西，当然，可能我没见过真的厉害的这种项目吧，我见到的，听说的基本都是 echarts 加上一堆贴图，能会用 Three.js 和 D3 的都少的很，说个暴论：能熟练掌握 Three.js ，D3 ，Canvas 常见场景的脏区域渲染，4 叉树之类的人不会去承接这种业务的公司... 后端也是一堆超长 SQL 聚合查数据，虽然技术再差也不影响挣钱，但是这种活干多了人真的恶心，而且各个行业削减开支，慢慢也不流行搞这种面子工程了，长久不了。

```
// Reader is the interface that wraps the basic Read method.
//
// Read reads up to len(p) bytes into p. It returns the number of bytes
// read (0 <= n <= len(p)) and any error encountered. Even if Read
// returns n < len(p), it may use all of p as scratch space during the call.
// If some data is available but not len(p) bytes, Read conventionally
// returns what is available instead of waiting for more.
//
// When Read encounters an error or end-of-file condition after
// successfully reading n > 0 bytes, it returns the number of
// bytes read. It may return the (non-nil) error from the same call
// or return the error (and n == 0) from a subsequent call.
// An instance of this general case is that a Reader returning
// a non-zero number of bytes at the end of the input stream may
// return either err == EOF or err == nil. The next Read should
// return 0, EOF.
//
// Callers should always process the n > 0 bytes returned before
// considering the error err. Doing so correctly handles I/O errors
// that happen after reading some bytes and also both of the
// allowed EOF behaviors.
//
// If len(p) == 0, Read should always return n == 0. It may return a
// non-nil error if some error condition is known, such as EOF.
//
// Implementations of Read are discouraged from returning a
// zero byte count with a nil error, except when len(p) == 0.
// Callers should treat a return of 0 and nil as indicating that
// nothing happened; in particular it does not indicate EOF.
//
// Implementations must not retain p.
type Reader interface {
Read(p []byte) (n int, err error)
}
```
每一个开发者的设计不同，上面的代码是 Reader 的注释，说了应该总是先处理 p ，再处理错误。

我遇到的基本都是有错误只有错误会有意义，其余均是 0 值。

这个事情得看你对象决定，她才是最终下决定的人，你需要和他谈清楚你的规划和目前的实际困难，她如果选择继续下去要面临家人的反对和未来一段时间拮据的生活，她选择分手你也要理解接受。

如果你有勇气的话你可以找你对象爸妈谈一次，你起码要能证明自己是一个靠谱的人，也要说清楚你自己有哪些困难，有没有计划改善目前的境遇，谁也不希望自己的闺女找了个鬼火黄毛男孩，这一点你要理解。

一分钱难倒英雄汉，楼主需要准备提升自己的收入（虽然这很难），为未来你自己或是家庭有更好的生活质量想办法，毕竟有句老话：贫贱夫妻百事哀。

结婚只是一个为期一天的仪式，此后还要开始长久的家庭生活。

不要自卑家庭糟糕的经济状况，这并不是你造成的，相反你需要努力摆脱这种现状。

祝好～

cursor 读取 commit 总结我干了啥，生成 markdown 丢给夸克生成 ppt ，再用 excalidraw 生成一些图片补充下。

@HotieCutie 最残酷的是，上了一辈子班也没挣到啥钱😭。

哎，配上今天上海灰蒙蒙的天，难受...

13pm 两周前换了电池，还能战下去。

大佬太牛了

外包真的不如狗，hr 都经常会问外包的 hc 要不要压缩掉...

家里有孩子，之前媳妇买了博朗耳温枪，还算准确

@vislins 我当然知道，部署一个大模型，挂 RAG 知识库之类的，然后 AI 还是没决策权，很多人找客服基本都是需要人工决策处理的问题，甚至人工客服自己都决定不了，都要联系售后或者联系老板的问题，AI 再牛也不能帮商家退款，也不能代替人在这种场景下决策。

我也 98 的，我儿子都两岁半了，我和我媳妇养活一大家人，我最近也是非常焦虑，但是 10 月我想明白了，凑合过呗，这年头能苟住就好，有机会就在自己向往的地方，没机会回老家也未必会差，可能换个工作或者换个行业，怎么都能活。

AI 客服我觉得是伪需求，甚至是让客户流失的一个需求，你自己愿意找客服的时候是一个 AI 和你车轱辘话吗，我只会要求人工。

别把自己想的太优秀...

挺好看

cf 用 rust 不还是崩了吗，代码质量是看人的，不是看语言的，比如我，不关啥语言，我都能造屎山出来🐶

难啊，现在就业本身就难，java 更是一片腥风血雨，希望 op 能找到合适的新工作。

如果一点点复制或者硬编码就能解决问题，不要引入大量的抽象和封装。