测试

https://i.imgur.com/xbYEfLl.jpeg

不要有大厂滤镜

在任何 人构成的 组织里, 最多就是一两个大佬 带飞一群人, 构成一个能跑的草台班子; 一个组织里大佬多了分歧就多, 谁都不服谁, 最终也会分家, 变成上面的稳定草台班子结构

datagrip 不是非商业免费了吗


如果您将 DataGrip 用于非商业用途，例如学习、个人爱好或开源项目开发或者内容创作，现在可以免费使用该工具。

此次调整后，DataGrip 正式加入 JetBrains 旗下对非商业用途免费的产品行列，此前 RustRover 、CLion 、Rider 、WebStorm 和 RubyMine 已开放这项权益。

如果您将 DataGrip 用于商业项目，相关政策保持不变 – 我们将继续实施现有的许可模式。 其他 JetBrains IDE 也不受此更新的影响。 我们将评估这项免费非商业许可举措的效果，以判断是否可以推广。


https://blog.jetbrains.com/zh-hans/datagrip/2025/10/04/datagrip-is-now-free-for-non-commercial-use/

@passive 啊, 你怎么知道, 简单的就直接出, 复杂的就真的在列竖式, 但是太复杂的计算图像会不稳定或者丢失细节, 就没法继续算了

2 个实践

1. 哥就是这么直接, 不服就干
2. 先发给 GPT, 要求润色, 然后再发出去, 一段时间后你就学会沟通套路了

0 总之不爽辞
1 Code Review 的人是谁, 为什么有权让你改?
1.1 组长? Leader? 不爽辞
1.2 组员? 完全可以拒绝或向上申请复议或者全组公开讨论


2 Code Review 应该在测试前之前就做完改完


3 整体重写的情况非常非常少, 是否是开发前的方案设计讨论就不充分


4 针对编码风格, 应该全组讨论制定统一的规范; 如果自己维护的业务在全周期由自己负责, 那你可以随便操, 反正也是鹅心下一个接盘侠; 如果是多人共同维护或者定期轮换, 你也不想维护被别人私自随意操烂的代码吧

因为在当前时间节点, 整个生态内还没有沉淀足够的 "发觉其他 AI 的能力，然后调用他们的能力" 的规范, 共识, 知识

等生态繁荣了, 数据量足够了, 会有的

别钻牛角尖了


"怎么, 不会打铁就不配用菜刀了是吧? 学独孤九剑之前必须先学抡大锤?"

"都是供应商装什么 b 呢, 这模型你不炼有的是人炼"

"读论文, 复现, 调参, 然后呢? 祈祷下一个神迹涌现?"

你是甲方, 掌握客户资源, 炼模型的才是乙方, 流量为王

各领域只有最顶尖的模型会胜出, 绝大部分炼模型的人炼出的模型都没用, 消失在历史的试错的长河中

对模型有滤镜, 建议祛祛魅

与其说模型, 不如说各领域的有效训练数据才是最重要的

都在社会上混口饭吃, 总是想踩别人一头, 或者被人踩头干啥, 鉴定为工作量不饱和

自选自用

把日志记好，出问题好追溯

https://docs.docker.com/engine/storage/volumes/
查到官方文档有相关特性介绍

Populate a volume using a container
If you start a container which creates a new volume, and the container has files or directories in the directory to be mounted such as /app/, Docker copies the directory's contents into the volume. The container then mounts and uses the volume, and other containers which use the volume also have access to the pre-populated content.

看来是个刻意设计的特性...


GPT 问了一圈又一圈没回答到要点, 还是得翻文档才行

啥时候标准库广泛使用泛型改写了，啥时候考虑用，当然也只是考虑考虑

除了上面提到的方式，还可以指定 pod 的 nodeName
https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodename

链接中整篇官方文档正好对应你的问题

无限流量什么意思，你的服务器要抵御阴离子炮轰击? 建议上 AT 立场

先谈剂量，再谈毒性
先谈规模，再谈设计

@lizon 比同事先跑路?那没事了

等你同事的代码上生产了，过了半年他跑路了，你接手了，然后半夜出问题了，领导要你起床马上修复并且上线，还要顺带热修数据，你就会后悔，这么 sb 的写法一眼就能看出问题，当初为什么没有 review 代码提前发现

review 能提前发现处理一些 sb 问题 sb 写法

寻找最佳实践很正常

最佳实践是从过往的工程实践中获得的。最佳实践不一定是当前场景事实上的最优解，但一定是当前有限成本（经济成本，时间成本，智力成本，试错成本，后期维护成本等等）的情况下最值得优先尝试的方案，这个"值得"是从节省成本的角度来说的

如果判断有改进的必要，那可以投入成本改进现有方案，适应当前细分场景就行了

当然理想情况下你可以投入无限的时间成本，经济成本，了解所有细节，设计出一套适应当前情况的最优方案，但是情况又是不断变化的，现在的最优不代表永远的最优，这样做真的值得吗

trade off

插件 Auto-Open Markdown Preview
https://marketplace.visualstudio.com/items?itemName=hnw.vscode-auto-open-markdown-preview