除非 AI 技巧就是主线……哈哈。比如，我看现在搞 AI 生成数字资产类的公司挺多。而且也有变现不错的。确实大家都可以尝试，大概有个几万块钱就可以起步了。

@bigxixi 确实，毕竟老板不干细节工作。不过，老手的话，AI 替代不了，老板开了其实也容易找到下家。

我觉得其实当前社会主要对新手越来越不友好，行业准入门槛会变高。哪怕新手学会怎么玩转 AI 也没啥用，因为本身不是太难替代的技能。要想难替代，就得更深入更专业，这样才能发挥更大的 AI 效率。但新手被铺天盖地的 AI 新闻淹没，如何找到正确前进的路呢？如何能切实有效提高自己能力，也让 AI 效率能更大发挥？其实行业更需要这类资深的工程师（也即专家）。这类人，基础扎实，适配 AI 也容易。而想成为这样的专家，需要投入精力学习的并不是 AI 技巧，而是戒骄戒躁，深度积累。毕竟和 AI 配合相对来说是更简单的事情，等需要的时候再学也来得及；一直焦虑不停的研究 AI 用法技巧反而耽误主线。

对了，游戏地图场景里的那个。还有个要求，是要有足够的多样性。这块其实还挺难评估的，所以，如果只能产生 trival 解也是没用的。而什么是多样性，我把生成地图搞成可视化的工具，然后肉眼看是不是足够“多样”。。。也许可以抽象出多样性的指标，但我觉得这个也是不必要的麻烦。因为地图生成主要作为工具使用，而算法随机性，保证了足够次数的扰动后，地图就是“多样”的。

@happynewday123 感谢推荐。我去试试。

@WithoutSugarMiao
也许是我技术姿势和水平的问题。在我看来用 Agent 实在太累，这两个 case 手写+AI 辅助反而挺轻松的。

@WithoutSugarMiao
我的两个场景：
1. 期货系统仓位管理。哪怕是逐仓模型。我不能按照常见教学里的方式来强制平仓。需要计算保证金率，考虑手续费（双边手续费，有时候还是仅单边货币支付的），考虑资金量的滑点不同，流动性差异也会导致滑点不同，等等的。因此公式需要手动推导，还要设计一些预设的参数，最终达成一个可控的强制平仓。（由于这些过于细节，AI 来写总是错误很多；无奈手写。当然，里面还有跟各个模块的复杂交互，比如结算系统，这块 ai 写得也不容易维护，理解起来很难）我觉得你可以尝试以下纯 AI 做一个真正可实用的交易所，兼顾各种细节问题。
2. 游戏里地图生成的图论算法。类似杀戮尖塔那样的地图。但我有更多要求：同类节点在图中的距离约束、起点到终点 path 上必经类型节点数量的约束。然后进一步考虑，要有足够的多样性。算法上基本需要启发式+局部随机变异+回溯，存在无解和无穷解情况。工程上要求，我可以随时添加更多约束条件。AI 写出来的主要问题是算法是错误的；需要人类不停的补充各种 case 测试（但这个比较复杂，太费时间。随便搞个地图都大几十个节点）。最后，我切换成我手动写，AI 来 review 的模式，进展稳定了很多。简单测试 case 下，我还是能保证实现正确的。复杂的测试 case 本身就构造起来很费劲，干脆没弄。

下面是我用 Agent 模式得到的一些经验：

1. 不再 DRY ，不再遵循很多设计模式。对 AI 来说，相似功能重写一套代码，灵巧复用很难。而即使代码量大，AI 也能快速阅读理解，因此修改上的难度也降低了。（但我认为，引导的人，也需要更加专业了；需要知道一个地方的修改，会引起多个位置的 bug ，需要有这种敏锐的判断）
2. 用静态语言，用工具链更完善的语言，以及公开代码更多的语言。这种语言，对 AI 更友好。（这意味着很多语言的使用度，会被 AI 偏好所影响；对 AI 来说语言学习的难度没有意义；但对很多技术人员来说，放弃自己的语言偏好，并不容易接受。）
3. 更多的测试和 review：单元测试、集成测试、e2e 测试，以及 AI 在各种位置加入 review 。（以我用 Agent 的经验来说，可以更好的驱动 Agent 收敛到自己想要的实现效果上；至于实现方式，可能非常 dirty ，大量临时的 trick 。需要通过架构能力来隔离这些污染，以及降低作为技术人员的品味。和 AI 配合不能那么“洁癖”；）
4. 更多的文档化。这点没什么好说的。我在用 Agent 模式，会专门维护 AI 的计划文件夹和常用 prompt 模板。以及写好的代码让它多 review 产生模板。
5. 比起使用 mcp ，更多可以考虑使用 cli 工具。（后者可用范围更广，前者还需要支持 mcp server ；并且对 AI 来说，好的 cli 输出更多，不太影响它的理解和执行；并且 CLI 其实人类也方便用）
6. 更多的管理工作。把 Agent 当成多个初级技术人员，每个有自己的偏好。因此，管理上，多强调规范，但也要能容忍代码上的各种微妙细节的问题。对文档也要及时更新。其实管理工作本身，似乎也可以用 Agent 来解决。（这块我没太尝试）

上面这些是我用 Agent 模式自己的+看到别人的，得到的总结。最后就是期待 AI 进一步降本增效，以及我能更加精进我协调 AI 的能力，比如在项目上做更好的抽象分离，让更多模块可以被 AI 做而不会影响人工的模块（目前对我来说还是挺难的，可能我技术能力不够；我目前整体还是用 AI 辅助，少量模块才会 Agent 模式）。

我应该属于 20%支持者+80%反对者。

你说的各种方式和主流工具，我几乎都用过。技巧上问题也不大，prompt 方面我最早相关论文都看过。我自认为至少在编程方面，我的使用程度算是比较深的。

支持和反对，主要取决于自身专注的项目上。

支持者：代码和技术框架常见（开源代码多）、需求常见（同样也是开源实现多）、对产品质量要求不高（能跑起来，能验证功能和想法）、维护场景少（很多项目甚至是一次性的，比如：数据爬取、清洗、分析；一部分外包项目；个人自娱自乐项目；或者干脆是作业）。这条路上的基本都是支持者。（当然这条路也能赚到钱，需要快试+投流；显然的一点是：机会窗口有限，门槛低会非常卷，市场环境会逐渐在这些大量较低质量的产品/内容中口味变得越来越挑剔）

反对者：项目逻辑和细节复杂、技术需求不常见、对产品质量要求高、维护场景多。这条路上反对者多。主要原因是 AI 的辅助功能确实提效很高，大家也会深度使用。但是 Agent 方面能力，导致可控性变差，项目理解成本骤升，Debug 成本骤升；往往用 AI 可以快速完成项目 90%，然后剩余 10%花费超过原本时间 10 倍的时间才能解决好。综合使用下来，用辅助的效率反而更高，用 Agent 却解决不了很多细节方面的问题（注意：因为质量要求高，所以很多细节问题看起来是不能容忍的）。我个人偏这条路，曾经用 Agent 协助完成的，和项目耦合度较低但内容和设计上相对不那么常见（开源解决方案极少），最后都返工了。现在仅保留那种，确保不会污染到主逻辑的模块、或者独立的工具类项目，会采用 Agent 来推进，剩余时候主要靠 AI 的辅助和人工来推进。（当然这条路肯定也是能赚钱的，相对上面的轻快尝试的方案，更加难+重，且市场理解上的错误可能带来很大的失败；好处也是有的，沉淀和积累上会更有收获。）

我现在整体想法是，保持我的态度上相对应比例的时间投入，1：4 。用 1 的时间，快速尝试 Agent 方案，解决一些不重要问题，以及后期尝试在市场里试试。用 4 的时间，关注到主力方向和项目上，不被贩卖 AI 焦虑的人影响。

@firefox12 这几天没空登录。抱歉才回复。我想强调的是，首先你说的这些 AI 确实能做，但不会像你说的那么容易，你可以试试；以及不用 AI 以前也能做，AI 本质只是降低了你起步的成本，而后续迭代的成本主要看你项目推进的程度了，到了一定程度后，AI 能辅助的成本下降也是有限的。其次，法律合规问题，你可以不管，我也没啥好说的。最后，我说想要靠这种盈利和赚钱，需要的不是技术，而是其他的东西，是 AI 搞不定的，需要你搞定的，这也是主要的矛盾。。。不知道你咋理解的。
一句话总结：纯靠 AI 不行，还得靠人。至于人的方面，你到底行不行，那主要看你，我说了也没用啊。

1. 数据获取问题。太多人说了，不再提。
2. 数据质量问题。很多数据本身是假的，有误导或者欺诈的嫌疑；对人类来说也并不那么容易过滤，所以大厂才会有专门针对这方面的算法和策略组，还要配套产品和运营的抓手，你确定只用 AI 能搞定？
3. 你说的这些功能，也有类似的 app 。什么值得买，之类的，建议你仔细研究一下。以及为什么它们做这些能赚钱。如果你去做，但做出来不赚钱，为什么要去做。

只能说你想得太简单了。开发软件本身也不是多难的事情，你说的这些这么没有现在的生成式 AI 的时候难道就做不了么？

我觉得软件社区需要讨论出一套和 AI 高效配合的范式。即：类似之前的各种，面向对象、领域驱动等等设计方式，需要整体革新一下，推出一个 AI 驱动编程之类的书。

现在用 Agent 通过自然语言搞个什么 App 出来，那怕看起来还有点复杂的（但网上开源方案很多的），这种，我一点都不意外。问题在于下一步，在于更加细节和繁琐的逻辑细节，算法 trick ，更加整洁的代码结构和约束，这些 AI 要不然就搞错，要不然就不经意引入破坏约束的写法，让整个项目从 1 到 100 的理解、调试、改善这些工作，时不时会变得比没有 AI 的时候还复杂。所以，我们缺少一个，成熟的，best practise, 如何更好的和 AI 配合并约束 AI ；即，我们缺少一套 《 AI 驱动的软件设计开发》 且能讲解非常深入的一本实践类的书。

至于这种 AI 可以做出来比较千篇一律需求的 app 什么的，我觉得没啥值得讨论的。实际价值，也不过是一个本科生毕业设计的水平。还是原来的老话，detail is devil 。AI 的 detail 太 dirty 了，总是 out of control ，越大型，越长期维护的代码，越不敢用 AI 的 Agent 模式。但自动补全和一些强化了约束场景下的使用还是可取的。

评论区太有意思了。哈哈。对楼主建议就是，别想太多，多执行吧。你这明显是“好谋无断”。扔个骰子决定做啥，都比想这么多有用。由于看你高考没考上 985/C9/Top2 ，说实话很多方向对你来说难度还是很高的，但如果能保持自信坚持下去可能也还好。从你罗列的方向里，给你拍一下难度顺序：

二级市场交易 > AI 原理方向研发 > 名校 phd 申请 > 产品级代码开发(算法 >= 后端 >= 前端，go > python = ts/js > html+css ；由于代码开发涵盖内容很广，这里平均了一下难度) > 大厂实习 > 雅思 6.5 >= 海外水硕(大概估算，还得看具体学校了) > 有实习 > 期末考试 top 成绩 > 学校里转系 > 英语 4 级 > 能初步玩明白 windows 系统(仅用户层面相对于普通人玩的六一些，能简单使用一些命令和进程管理器，了解一些高级配置；不涉及 api ，二进制，驱动，注册表……) > 普通人期末考试成绩 >= 普通人常规理财 > AI Prompt 使用 = 会打开 Vscode = vibe coding 入门

我更具体的建议：
1. 英语好好准备，雅思 4 个 7 会好一点。如果 6.5 都勉强，比较精英级别的机会和工作恐怕对你比较困难。
2. 海外水硕混一下。既然家里有些钱，可以走个捷径。毕竟国内更卷，以你高考实力够呛卷得过。
3. 如果未来可继承支配非固定资产>1000w ，没方向就跟着家里长辈做一做比较稳妥，有方向就以自己兴趣为导向； 如果家庭实力有限，考虑转计算机方向，多夯实自己的原理课+尝试参与开源项目/成为较为主力的开发；如果计算机学不明白，我也没啥好建议，看看家里人哪些方面强，找个长辈引路吧。

最后，建立好自我认知。你的起点并不高，你自己未来慢慢感受吧。

之前有一个月，大量使用 cursor agent 模式开发代码。（我应该算深入调研了 vibe coding ，自己还出了大概 2-3 节课的教程； AI 方面的论文和进展基本都追得动、以前也是做 AI 算法的）

而最近一两周，我的开发模式改为主要和 chatgpt 对话+自己手写，基本不怎么用除了补全、重构和 review 以外的功能。

我直接放出暴论：Agent 自动写代码的功能，在产品级开发上基本都是负收益。项目以前所未有的速度快速“屎山化”，如果要保证更好的代码质量，AI 还是用来辅助更好用。AI 发生问题的地方都在细微的细节上，积少成多；产生这种问题的根本原因和 自然语言的模糊性（交互层面）、软件设计方案上不可避免的迭代变化（需求层面）、AI 模型缺乏稳定的长期记忆、AI 模型细节输出多样化不可控 等等 有本质关系。后两个问题是当代 AI 模型内生的问题，也是 AI 和人脑主要差异所在，没什么短期内能解决的希望。而前两个问题，本质上就是多人协同开发时的管理成本，和 AI 协同自然也需要管理成本（但还要额外叠加由于 AI 内生性问题导致的管理成本）。

Agent 技术的真正作用：给真正的 Agent 开发高手扩展软件/框架/工作流等能力的手段（但需求定义本身也是更大的难度，且这种项目中 Agent 不是辅助生成该项目代码的，而是给用户生成输出的）。这种能力主要给工具链开发人员准备的。大部分人都是工具链的使用者，也用不到这些能力。

编程工具(cursor)里的 Agent 的作用：个人觉得这个功能的真实作用面非常有限。我大概可以确定的： 写 demo ，开发不怎么维护的工具（功能相对单一的），应付工作上需要写屎山的需求（给架构师增加项目维护难度；但那是他的事儿，初级程序员领自己工资就行了），给老板叠焦虑 buff （老板也不懂这么多细节，就问怕不怕被其他公司淘汰），推动公司制定更激进开发计划（不见得是坏事，尤其有的公司主要靠融资发展，拿得出 ppt 唬得住投资人，显然比做得出稳定产品更重要）。。。。总之一个原则：用的越多，debug 越难，代码维护越难。最终大概率是用 5000 行代码写出来正常人类可以 1000 行搞定的东西。

对个人发展来说：有限度使用 AI 解决工作和项目推进+无限度使用 AI 来学习，是最优发展路径。邪路（不看好）：研究各种 prompt ，Agent 用法，企图建立在工具使用上的微弱优势（迭代很快，随时被打脸，所建立的优势都微不足道，Agent 开发高手做的新工具可以直接粉碎普通用户熟悉 prompt 所建立的微弱优势）

未来 AI 编码工具的预判：Cursor 等编辑器的 Agent 功能被终端用户使用的场景慢慢变少、Cursor 等编辑器会针对边界定义良好的流程直接推出工具(Agent 技术本身成为更加底层工具的开发手段)；开发人员主要和稳定的生产流程工具交互，而不是直接使用自然语言驱动代码生成。自然语言交互界面更加聚焦在 辅助、教学问答、review 等等能力上。

装个 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 丢给我来解决。

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