@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 部门没意见，那么我也没意见。实际情况比较多并不是一线业务部门卡年龄。

缺乏确定性，安全感。并且你本身不 enjoy 这种感觉。大部分人在当今的社会环境下都是如此。

胜利，阳坊涮肉，可以自己开车去吃。
炒菜的话，四季民福还可以的，有些店比较有特色。

个人使用经验，jenkins4-5 年>gitlab 不到 1 年>gitea 2 年。jenkins 运维成本比较高，适合大一点的团队。gitlab 主要是刀法太精准，免费版本功能卡的你很难受。gitea 当然不完美，不过适合中小规模的团队，简单够用。前面的人单个产品的优劣说的比较多了，我提一个点，就是你选型要看你的约束，比如团队规模，资源（比如单独的运维），团队成熟度（开发的平均水平）这些，脱离这些约束谈好或者不好意义不大，就跟哪个语言更好一样。