用自己的 api 就几种方法
1. 楼上说的，国产模型 (glm4.5 或者 k2, qwen3 coder 贵一些)
2. 用(买)key 池白嫖 gemini 2.5 pro (效果不一定好于国产模型)
3. 各种便宜 api 商，还是用回 claude 自家模型（有黑卡/偷改模型/llm 注入之类的风险）
效果最好的还是官方自己的包月（ opus 4.1 + 未来应该会上的加长上下文版 sonnet ），因为他的 prompt 都是根据 claude 自己模型调整的

大佬牛逼，呆呆兽是我今年玩到魂味(探索感)最足的游戏，游玩过程非常愉快，现在非常期待你们的 dlc

这插件不是一开始就有黑历史么，作者还在本站上 battle 了几次，反正我一开始就因为他那些黑历史没用他

这种肯定不止一个 agent 的，你就算套出来了也只是套了其中一个的 prompt

我个人体验的话，都是旗舰模型（ claude 4, gemini 2.5 pro..之类的）那么 coding agent 设计的好坏大于模型选择，而 coding 流程设计又大于 coding agent 的选择
就 agent 本体设计好坏来说，我目前没见过任何一家能超越 claude code 的设计（哪怕 claude 4 在处理复杂问题的实际能力上不如比如 2.5 pro 这样的模型）
而流程好坏上来说，我觉得 kiro 是这么多家里最好的（基于 spec 流程），当然他那套东西也不是专属的，你可以任意复刻到自己用的顺手的那个 agent 上去，我自己就搞了个 cc 版本的

已举报

@dongcxcx #12 kimi k2 试下？
我的意思不是用前置 node 判断用户意图（意图识别在模型性能不够强的情况下非常容易出错），而是简单判断信息是否完整，相当于做一次前置过滤，将用户问题按标准化格式转写也是一种方法

@dongcxcx prompt 看着没啥问题，那一般这种问题解决方法就是
1. langgraph 做一个前置检查 node （在这个 node 里判断用户信息是否完整，不完整就直接去 respond node 向用户要信息）
2. 如果保险起见就再做一个后置检查，去读你的 messages 记录里的 function call 是否有成功调用 sku 查询
3. prompt 里加入详细的流程例子做引导
4. 如果效果还是不好，在前置 node 里做用户 query 标准化转写
5. 最后不要用 4o-mini ，性能太弱，不要用 dsv3 ，指令遵循不行，虽然以我的经验来看 4o 实际不适合 react 的场景，如果可能可以酌情使用更好的模型（带 thinking/混合 thinking 模式），不行就算了

你这最关键的用了哪个模型驱动都不说
每个 agent 对各种 prompt 的效果也不一致，
你怎么设计的 prompt 也要描述清楚，
最后才是这些框架 workflow 的问题

那我也有一个问题：入门一定要报班吗？不能够通过自己的兴趣学会么？
前端入门是很艰深难懂的东西靠网上这些资料自己学不会？还是报了班自己就不用花时间去研究了？还是现在的 ai 一对一问答不好使了？
我这里也放个暴论，一个网上成熟的入门学习路线 + ai 辅助教学，未来会比任何培训班都好使

大词汇发明家 Karpathy 的发明词汇（最新的是 context engineering ）， 结果大家都跟风用，
然后如果完全按着字面意思来理解真的去 vibe 就会大呼上当，一个误导性极强的词汇

@Grin1024 我在想能不能把 roo 的那几个专家移植几个过去

@Abmcar 怎么说呢，当年有些程序员是可以在记事本上面写码，肉眼排语法错误，你说这算不算内功？
但是后来大家都用 ide 了，不管你语法记得牢不牢，api 记得好不好，内功强不强，一开语法高亮和补全，新手老手根本拉不开差距。
现在也是一样，在 ai 辅助下，对于开发来说，内功强不强根本拉不开差距

@Chuckle 我觉得现在还在早期阶段，至少市面上还没有一套完整的，业内公认的 agent 工作流出现（就是怎么理解任务背景，怎么拆解任务内容，怎么执行，和怎么用测试验证防止出现你提到的这种经典错误），不过前两天刚出的 aws 的 kiro 有点那么个意思了，搞不好今年底或者明年初这套流程就能定下来，定下来之后大家统一按照流程走和优化流程，估计复杂度高的业务也能拿下了

我觉得本来就不应该把大部分精力放在怎么写上面，
而且下一代开发可能一入行就是 ai 辅助代码的环境了，会不会写对他们来说可能真没这么重要

你不试一试 gemini 2.5 pro 和 o3/o4 mini high 还有 grok4?
你选的那几个做题都一般

ai 应用发展的最快的是程序员应用的原因只是因为程序不是一个 open ended question ，有明确的结果可以预期和判断，所以 1. 这个方便了基模训练和对齐的过程 2. 也方便基于基模的应用引入自己的工具进行增强，所以程序员应用的体验是最好的，发展也是最成熟的，而不是交互模式这种理由