大部分情况下你用不到 deepagent ，一般来讲越简单越好，越薄越好，但是考虑到可维护性的问题，需要取舍一下。正好推一下自己的开源 rag ，极致简单，高效，非通用的狗粮 https://github.com/highkay/stupidsimplerag

例如 langgraph 的 react agent ，这种 case 主要是靠提示词（ ooda ）驱动 agentic 的诊断过程，workflow 其实不太好做。而且生产用的话，不要去搞什么多智能体，复杂，浪费 token ，不好调试，反正缺点远远大于优点。

多挣的那些钱对你现状帮助不大，我感觉主要还是看你对下半生的规划了，我同年，其实也是经常思考这个问题，特别是自己身体和夫人的健康出了一些问题之后。

@highkay 分治。其实总体思路就是如果一个新来的高级工程师需要开始动这个项目（或者某个模块）需要了解的所有内容，从需求分析到最后部署上线。

官方已经修好了，直接更新 gemini-cli 就好了。

@YaphetLee 爆炸盐

这个是配额用完了，触发了一个 telementry 的 bug ，github 上有 issue ，修好了还没合并，直接用 npx 安装 github 可以解决。这里正确的逻辑是切换到 2.5-flash 。

@fmumu 如果是简单的项目千把行代码，大部分模型都可以装进上下文窗口，基本上一流模型都可以干的不错，至少效率比人高。如果是复杂项目，除了需要旗舰模型（ gemini-2.5-pro ，claude-sonnet-4 等以上），就需要自己构造高质量的上下文，这个比提示词更难一些（ ide 用的提示词网上一搜一大堆，质量层次不齐，越复杂的不见得越好，很多都是编写的人自嗨，可以让大模型自己评估改写），比如项目的核心逻辑，到底是干嘛的，技术框架，数据库的表结构，开发模式（自动生成 or 模板代码），编码的约定等等，反正你们自己开发需要用到的信息/知识都要放到这个上下文中，越复杂庞大的项目，这个文件就越大，所以对上下文窗口长度是有挑战的，目前 2m 应该能满足绝大部分的项目了。这个上下文可以通过半自动的方式，用 gemini-cli 或者类似的工具去梳理出来（吃文档，自己查看代码纠错，抽取数据库 schema 然后映射到代码上），这个 CONTEXT.md 做好了，你的工作就完成了大半了，后续的也就是网上到处都是的技巧了，比如先拆分子任务，写开发计划再写代码，写测试。我个人感觉差不多可以达到一个 5 年左右的高级/资深软件工程师的水平，月薪 2-3w 的样子。

@anan1314git k2 有 groq 的版本，超级快。目前感觉相当于 ds v3.5 吧。

kontext 可以替代很多 ps 工作了，自动化的图片理解直到评估也可以做，当然产出效果不稳定。

1. 为什么要用微服务？不要拿公司的项目练手，压力会很大，也不负责任。
2. vibe coding 的话，单体仓库上下文更友好。你也说了公司没啥技术氛围，可以让你有更多的时间搞点别的。

很简单，因为这 20 块没有走公司的账，所以财务不能写在发票上，进出对不上是财务大忌。逻辑上你垫付了，司机应该把高速费的账单或者票据给你，你报销时贴上去

something like warp ？

你没有显卡肯定慢啊……，而且我觉得感觉你这个是任务的质量大于速度的，从结果讲推荐新版的 r1 蒸馏的 qwen3-8b ，同级别的模型输出的 token 越多，质量越好，一般来讲。

同样一个需求，随便做做（ 1 个小时）和精细化的去做（几个月几年）做出来的东西完全不一样的，比如你说的翻译插件和沉浸式翻译，当然如果要商业化还要看付费难度强度这些的分析。虽然这个世界上草台班子很多，但是专业团队也是很多的。

@wuligao 后排放一个安全座椅，坐两个成人不是很舒服的，要看体型的。建议你把座椅放上去试一下。

如果老板和 hr 部门没意见，那么我也没意见。实际情况比较多并不是一线业务部门卡年龄。