装个 linux 系统。ubuntu 。学习一些命令行、makefile 。手动组织一个 c 语言项目，编译运行。从这个作为入口点开始学习。不会的问 AI ，AI 说了不懂的，继续问 AI 。接着用 C 语言实现一个复杂点的项目，（我当时是 OpenGL ，但有可能过于复杂了；可以做个简单的命令行工具，比如文件夹下的查找，于是会涉及到非常多的概念，文件系统，编码、二进制/文本，正则表达式）。这个过程中，不断深入学习一下系统的用法，鸟哥那本书不错。这样感觉有了之后，开始补全各个环节的基础课内容（其他人都提过那些基础课了，我基本全部补了一遍；其实也还好，现在有 AI ，更方便跳着看书了）。

如果是针对多个语言之间，联系之类的。学习一些编译原理和汇编语言。然后，我个人觉得可能深入 C++会比较方便理解多个语言（深坑），C++中有各种指针，GC ，多态，模板等等技术，回过头来，其他语言的很多特性也就能有所理解。然后还需要看一些操作系统的具体实现原理，页管理、线程调度之类的。基本上组合这些底层技术，大概就能明白高级语言的一些特性是怎么实现出来的。每当看到一个语言特性的时候，脑子里大概能猜得出来底层怎么实现的，算是打通任督二脉了（然并卵）。

最后，你还是应该通过长期推进一个自己的项目，选择聚焦 1-3 门语言，来不断的深入技术，累积更多技术声望。

要的少，对方更觉得你不行。想办法多包装自己，多要一些。对方如果讲价，就还是有希望的嘛。

我举的例子都是技术细节上比较深的例子。不过架构问题也是类似的。但架构本身是艺术，不好评价什么是好，什么是不好，是综合多个方面，所有技术细节的，更加权衡和综合性的考虑。AI 同样可以加速 [本来就能成为架构师] 的那部分人快速成长，对 [本来就成为不了架构师] 的那部分人来说还是成为不了。结论和我上一个帖子一致。

@zhenghuiy 很赞同。

之前用 AI ，控制力很差。最近使用起来，有很大提升。

先说我对 AI 目前 coding 能力的见解： 很多较为简单的逻辑，加上合适的 prompt 技巧，基本 AI 能解决很好。复杂一些的需求，往往需要开发人员对代码深入理解，以及更灵活使用 AI 的姿势（比如，及时在 AI 跑偏的时候打断，等等）。更进一步的，长期做项目，应该还要在项目中维护一系列 prompt 模板，方便定点解决一些重复性需求（ CR 、重构、文档化）。再专业一些，如果要最大化 AI 的效率提升，大部分人搞不了（比如，维护 prompt 模板库，和一套校验测试 prompt 有效性的数据和实验），大概率是等待 AI IDE 厂商来迭代了。

对新人程序员来说：首先对 AI 使用的程度本身，就说明一定的问题。如果用法不够深入的话，大概率是 1 类人（需要环境逼迫）。

其次，对于某个领域深入学习，利用各种 chat ，通过问和自己实验的方式来推进。这里也并不如想象中那么新手友好。浅层的知识很容易获取正确答案，也许对新人到中级有帮助。但更加复杂的知识，我经历过两个 case：一次是关于有限域椭圆曲线加密快速算法上的细节问题，AI 基本一直误导我，最后还是靠我自己手动推导搞定的；另一次是，vulkan 程序上出现的异常情况（没有明显报错信息），AI 基本乱猜，最后靠我自己用 windbg+有意识引导 AI 按照我的思路排查，最终从二进制上定位到原因。我的这两个 case 之所以我能搞定，是因为我有比较扎实的理论功底和思路，如果同样的问题给到新人，真的能排查搞定么？我对此很怀疑。（当然，肯定有人可以搞定，但绝对不是大多数人）

AI 对于“好读书，不求甚解”、“叶公好龙”，这种类型的技术人员来说，只会让他们更懒了，以及让他们更加容易被替代了。（不幸的是，这样的人大概率是大多数）。而对于“打破砂锅问到底”，这种类型的技术人员来说，是效率的极速提升，而这部分人，没有 AI 也会成为技术专家和架构师。

综上，AI 加速了高级人才的成长速度。但遗憾的是没有扩大人数，稀缺性还是有，也许会稍微多一些（多出来的人 = 压缩的成长时间 x 原本每年市场上高端人才的增加量）。这个是更加冷静客观的看法。因此，楼主的左右截图，都很片面，左边说不稀缺和右侧的更加稀缺，都只是站在对自己观点有利的角度考虑。

总结：市场上高端人才适度增加，但仍然稀缺。中低端人才更加卷（因为不需要那么多了）。

我的感受总结：AI 成了我的领导，我成了 AI 的组员（兼任多个方向的组员）

我个人感受，但有可能是我使用姿势不对，欢迎斧正：

1. 搭建脚手架。文档工作做好的情况下，非常 ok 。
2. 重构项目。很困难。
- 如果重构涉及的模块比较多：目前我的做法只能是针对重构部分的业务，详细化写出重构的代码设计（很费时间），然后以类似脚手架的方式让 AI 来生成重构后的模块代码。随后，手动修复细节。并在系统其他位置上调用新代码，并修复各种调用依赖，最后再手动删掉旧代码。（目前，我正在评估这个方式会不会好）
- 如果重构比较小，基本手写更快。感觉和 AI 描述清楚太费劲了。它不太能理解我想重构的方式方法。
3. 代码内自动补全，非常 ok 。
4. 单个文件内（不考虑多模块间）的简单重构或者增加新方法，用 chat 的方式。比较 ok 。但我很少需要这种重构，写的时候我基本就写好了……程序员的自我素养
5. 配置文件修改，不需要打开额外的编辑器(csv,yaml,json 等编辑器)，用 chat 的方式让 AI 修改。非常 ok ，我不喜欢切换软件（除了浏览器）

以上就是我使用的姿势。说实话，不觉得 AI 能成为组员，除非比较常见的任务，或者从零到一，它完成的还好。稍微复杂深入点，很容易卡主。确实如同楼上所说，需要 support 它。

我觉得他缺失人类的一种能力，就是人类如果自己不明确的话，会和你进行沟通确认细节，来保证更好的对接。但 AI 不知道自己不懂，它会尝试猜。于是就有对有错，于是就也要求你 prompt 更细一些。prompt 很细本身就是成本，prompt 失败也会产生成本，需要重新 prompt 。我很难相信有人能做到 100%prompt 成功。对于粒度细到一定程度的问题，prompt 失败率高，而手写更加确定和稳定（配合 completion ）反而成本更低。

从细节和全局角度来看，我觉得 AI 对我来说，更像是领导，我特么才是组员。它可以做好架构，做好大的设计，然后细节搞不定，我扮演一堆组员，解决各种细节问题……；包括怎么业务逻辑思考后更细节的 prompt ，也不过是我身为组员给领导汇报一下思路，领导哐哐给我写出来个大体的意思，然后把细节和 bug 丢给我来解决。

难道我姿势有问题？？唉……

不如就基于 java 后端，做一些项目，并且开源。定好方向，比如自己熟悉的业务方向。做得足够久，业务足够细、功能足够细（必然要求不仅仅会后端），还是会有竞争力的。其实最好还是做项目能解决自己的兴趣需求的，以及想办法能一直坚持做，这两点看起来容易，做起来比较难。你那些方向全都不靠谱，水深着呢，并且前提还是得有点钱才行。

要是换做让我做，我就换工作。
要我是公司管理层，想法就是：总之只要钱给到位，还是有人会硬着头皮干的；而且总是有人不怎么在乎职业发展，或者没办法在乎职业发展的，人肯定是能找到。

推荐看李宏毅老师的视频课。

我其实刚想说，看已经撕起来了，哈哈。

还真没看到过啥优雅的依赖管理方式。说优雅只能说，用得还不够深度。而且，我比较喜欢都复制在本地文件夹。放在全局，项目一多了，真的头疼。每个项目都能隔离好，才是真正的优雅。而且放在本地还能一起复制走，多好。浪费点存储算什么。我有时候还会 hack 到依赖包里改源码（当然也不提交版本库，要提交也有专门的方法打 patch 吧，通过 build script 什么的），这种改依赖包源码的情况，放全局岂不是灾难？

读了一下 2 楼的内容，精神压力直接飙升。虽然我不用 java……

看开头，我以为是要做独立游戏咧。不过我预判你早晚要搞游戏的，哈哈。很欣赏你，可以做个朋友？ UTogNzEwNTkgMTIwOQ== ，有空可以多交流。

可以，看到算法题的时候，我赶紧查了一下。哈哈。习惯性查答案。

至于学历，随便搞搞就能拿个非全日制本科学历吧。大专不够用。

用不到，然后忘了，那就搞个开源项目直接用新技术去做。连项目没有的情况下，当然学了就忘。效率为零。

公司项目如果让你练手，那你就在公司里用新技术。不让练手，搞开源项目呗，有啥的。

另外，做得深入一些了，自然就会涉及到各种原理性质的、算法性质，乃至数学相关的东西。自然就提升了。至于方向，要么做感兴趣的，要么做擅长的。如果没有感兴趣，也没有擅长的，只能说，不适合吃技术这口饭。

看完，个人觉得你不应该找 AI 技术合伙人。除非你很有钱，或者已经有融资了（那样也不会在这里找人了）。

应该找尽可能全栈的工程师。AI 方面可以调用别人的模型或者 API ，以出效果为主，不以调优为主。

行业方向上，先从工程和需求开始做，而不是从算法。主要是算法 ROI 比较低（主要还是投入大，产出小），调算法包则 ROI 比较高（调包当然容易了，同时出效果也快）。

不建议做自己想出来的新需求，除非你是多次创业者；建议从一些已经有的需求上做，然后用 AI 做微创新。

直接考虑用 AI 技术作为卖点下场，会有很多问题。在大部分实际需求中，AI 都是锦上添花，并非雪中送炭。没有基础功能需求支撑，基本做了也是徒然，竞争力弱，效果大概率跟做个好的 ppt 差不多。此外，要搞清楚你的产品是 2c 还是 2b ，2c 重点是怎么搞流量，2b 重点是怎么搞客户。不管是哪个，自己去研发行业模型都不是最重要的事儿。

AI 技术方面：搞 AI 需要数据，需要算力。人的方面主要是需要有经验的，或者足够聪明的。然后基本就是调参，根据结果来测试参数，不断调优，时不时看论文，用点新技术调优。问题是，数据算力其实都不便宜，做完之后的产出也仅仅是模型，离产品还有很大差距，大概是 1 分到 100 分的差距。并且，产出模型所需的时间并不稳定，取决于数据质量，算力多少，问题难度。而且每次调整，都不是那么可控的，玄学。所以你找了个 AI 工程师，大概率就是做了个模型，给你演示一下自己研发是啥效果，然后发现很难往下做了并且钱也没了。

我个人预判还能凑合跑一些图（仅仅做一些推断），但应该比较慢。

4070 ti super 我用着的话还可以，不过那个机器只用来跑图，不做别的。4090 ，我也入手了，4090 可以勉强做一些 LoRA 微调。主要点：机箱弄大点，方便后续添东西。电源功率高点，免得负载上不去。散热看情况弄，差了自然也是有问题的，不过那个主要看 CPU 负载。另外，GPU 卡都这么贵了，主板 CPU 内存也得上来吧，要不然 IO 方面的瓶颈或者 CPU 不够导致性能发挥不足，岂不是浪费。总之，照着 2 万以上来配电脑可能更加好一些，别想着太便宜了。（如果 4090 ，照着 2.5 万以上配吧）

至于全量训练啥的，就别想了，不是个人玩得起的，至少 8 卡吧。

我印象里，没有 main(当然动态库也有自己的 main)，加上编译上带有--shared ，输出是 so ，就会形成动态库。其他主要就是写 makefile, cmake 之类的。好久没写了，我当年一般用 cmake 多一些，这样编译器标签什么的，基本都构建系统给你处理好了。就只需要项目编译组织对了就行，正确的添加好依赖，然后构建；一般项目应该都做好这些依赖的 link 配置了，当然 linking 出问题会比较麻烦，又很多细节，我也不展开说了，你可以先试试。
此外，.so 里面函数签名也有可能是麻烦的点，如果为了更好被别的语言调用，C 的封装接口更加易用一些（ C++的 mangling 可能会导致查找符号上还挺困难的，但是如果项目本身是 C++的你会发现封装一层 C 接口也有不少工作量）。另一个常见做法是，在项目中添加比如 java 语言的头文件，然后对相关调用当前 java 提供的 native 函数进行封装，这样会直接导出 java 可有识别的函数。（我推测大概率可以，其他语言都有类似做法） java 的调用技术，应该叫 jni ？你可以自己多研究研究。我对 java 不太熟，只停留在表面使用。