crackhopper

我的感受总结：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== ，有空可以多交流。