crackhopper

我对 AI 整体感觉就是：大力出奇迹。并且确实很强。但我对 AI 未来的预期，还是偏保守的。

AI 虽然一直在变强。但它的缺陷，并没有真正被攻克：幻觉、不确定性。现在的技术手段更倾向于，用更多的 对齐训练、context/harness engineering ，降低出大问题的概率。但这些缺陷就会被进一步转移到其他看起来不那么是问题的地方，并逐渐累积，直到，项目整体出现结构性问题。（这些都有解决手段，但都需要外力，不能单纯靠 AI 解决；因为有了额外的人力约束，因此 AI 的需求并不是无限的）

主流观点上，AI 还在进步，还在爆发。从 AI 行业商业角度上来说，是对的。从 AI 工具的本质能力来说，我认为并不是，未来 AI 也很难在短期内有更加亮眼的表现。（吹牛会有更多，但我对 Anthopic 和 OpenAI 目前的吹牛，并没觉得会带来更大的需求提升；因为这些方面的人，已经在用 AI 了；而所谓的能力提升，也只是一个子方面的能力，比如我后续说的，容易模拟获取到结果的领域，比如黑客方面，系统会给出对应的反馈；并不是通用基础能力）

首先说一下所谓的爆发。最近几年 AI 带来的提升，本质来源于 context/harness engineering 这样的 Agent 开发手段。但利用这个技术，提升是明显有上限的。本质上是写一些 if/else 来优化 LLM 模型的用户体验。但这个方式并不能真正提升 AI 。历史上的第一次人工智能危机前，就有人认为靠写 if/else 足够多，程序就能成为真正的智能一样（当时还甚至有顶级的研究员认为一个暑假差不多就能搞定 AI ）。那么那次后来的结果，就是 AI 研究沉寂很多年。本轮会不会也是一样呢？我想我的判断是是，但也不完全是，因为还有基础模型能力提升的故事可以讲。

说到 AI 基础模型的提升。我认为，目前已经变缓了。高质量的数据燃料有限，AI 只能指望自己生成数据，用生成的数据继续提升自己，类似 AlphaGo 那样的思路。但 AlphaGo 所面临的世界是简单的，确定性的围棋规则，因此生成数据和环境交互下，是能进一步得到有效数据来提升的。因此 AlphaGo 有很多优势：围棋对局可以快速模拟，规则有明确边界。这样情况下的围棋 AI ，超越了人类。不过即使这么有利的条件下，AI 也并没有真正求解围棋（很显然，围棋的所有可行对局，在数学上是有限的，那么就有一个最优解，即必胜的下法；但围棋 AI 并没有求解到这个解）。回过头来，看现实的 LLM 对应的 AI 。如果走同样的路子，那么也需要能自己生成有效的训练数据，也需要和环境交互才能得到。这个环境是什么？是人类社会的语言交流。但人类产生数据的速度，无法追上 AI 消耗的速度；确实，人类一直在产生大量数据，但 AI 需要的是可以超越自身性能边界的，更高质量的数据。此外，同样和环境交互生成数据，LLM 对应的评估标准也不那么明确（ AlphaGo 则可以直接根据围棋规则给出结果），更关键的是，没法快速模拟（有人会说，LLM 模拟人，互相对话，这样可以快速模拟。但问题是，需要突破 AI 能力边界的数据，这种让 AI 自己生成，不借助外部帮助，还是很困难的。不过，这个思路也有价值，就是可以快速蒸馏其他更强的模型，哈哈）。（另外，某些子领域，AI 会更有作为，比如黑客，是否入侵成功，明显是系统可以快速给出回馈的；只要搭建一些蜜罐系统，用来训练模型，那么这方面能力显然会有巨大的提升。但这个并不能完全算作 AI 的基础能力，只能说某些领域就是有 AI 训练的潜力）

基于上述思考，我的判断如下：
1. context/harness engineering 还有提升用户体验的空间，进一步释放基础模型的能力。但它的边际收益会逐渐减少。目前看起来，代码开发方面提升效率约 50%-200% 。并且很可能是上限。因为一个人类，可以有效消耗 token 是有上限的：取决于人类 review 代码的速度是怎么样的。诚然比写代码快，但肯定比不过 AI 生成的速度；因此，最优解应该在，生成的数量恰好达到人类 review 数量的上限。基于这个看法，token 输出其实并不需要无限供应（目前，实际上主要的 token 消耗是在 Agent 自己内部，做 context/harness 的时候，消耗掉的，但这个也会到达 context window 、token 成本、推理速度，这些约束下的一个平衡点）。这个点来看，我认为短期，3-5 年内，AI 体验会上升，单价会更贵，需求随着更多人使用 AI 工具开发而进一步释放，但效率提升和成本的比值很可能会更早达到上限。（我这里没讨论 vibe coding 。vibe coding ，我认为更适合原型生产阶段，不适合严肃的工程开发； vibe coding 可能也许创造一些快速原型的开发工程师的岗位，但交付的产品，除非不考虑维护，否则肯定要人类 review ，这也是自然语言和代码细节本质的差异导致的：即人类掌控项目才能控制项目迭代长期稳定不崩溃）。
2. 靠 context/harness engineering 。但上限肉眼可见：token 成本，和靠 if/else 本身就是历史失败路径。对此不能抱有太高的预期。用户体会到的 Agent 能力大爆发，靠基础模型+这些 engineering 整体达到的。不要小瞧了这些 engineering 的能力。但，可惜上限的存在。
3. AI 基础模型的提升，目前已经不再是爆发期，而是一个稳态慢速提升。由于 AI 基础模型能力进步，只能靠 AI 搜集更多高质量数据（比如开发者和 Agent 交互的轨迹数据），以及协助研发更加快速逼真的仿真系统（通过仿真系统来得到更多数据，当然聚焦于更加 specific 的领域；仿真系统，并不完全是物理仿真，软件环境仿真，某些具体的 case 可以仿真，也是 ok 的）； scaling law 时代目前基本已经结束，数据和硬件都没办法指数增长。

可以预见的未来是：AI 公司最终还是要商业化的。AI 要想赚钱，得有客户，并且得有更多客户； AI 如果想要进步，需要有客户，因为要采集客户的高质量数据；最终，不可避免的，高水平 AI 还是会被后发者蒸馏，除非不发展客户了；最终，不会存在高质量的通用 AI 被垄断，除非先发者不考虑商业化赚钱。行业的终态，还是会变成成本比拼、生态工具链比拼。各个非 AI 基础服务公司，对 AI 的使用也会“去魅”，限制 token 用量，更合理的评估 token 单位成本带来的收益，并保持让 token 单位成本收益，和 人类工资单位成本收益，达成一个一致。（当然，specificialization 的 AI 有可能可以被垄断，有专门的用途）

短期来看，AI 并没有充分供应。需求缺口大。因此，AI 产业相关的上游，长期应该会不愁订单，迎来黄金发展期。但当需求增长放缓，就会迎来 AI 泡沫破裂的时期。（条件是（需要同时符合）：harness 相关技术达到效益瓶颈期，潜在的生产力用户都已经进入 AI 生态，企业学会 token 成本相处并冷静对待 AI 带来的效益提升。不过，到了这个时候，我估计更多的 AI 数据中心也建的差不多了，token 成本下降，供应也会更加充足。大概有多久？不好说，我暂时预判 3-5 年。很可能被打脸，比如 AI 再次不靠基础性能，再次扩大用户需求面，我感觉挺困难的，目前能用 AI 的都在用，已经扩大的很大了）

现在能力确实暴增，之前 方案 C 不太行。现在 方案 C 可行。尤其是如果是对于很多工作来说，并不需要多高质量的代码，AI 质量基本满足要求。claude 和 codex 我觉得都写的不错，有问题你指出来目前也能较为精准的控制具体改哪些。文档管理同步，skill 积累，反而变得更必要了。
如果代码质量要求高，方案 B 。
如果要求更高且 AI 训练库里基本见不到的模式，方案 A 。
对前端来说，大部分都是 C ，少部分 B ，很少量的 A 。我的判断是这样。
D 也可以，不过不是做产品，是快速做原型。review 也不用太 review ，让 AI review+test ，只迭代功能+人类测试一下。

除非 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 模式）。