crackhopper

现在能力确实暴增，之前 方案 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 模式）。

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

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

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

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

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

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