Viking

最近把技术开发基本都挪到 Grok Bot 上了，分享一下现在的工作流： 1 一个产品一个 bot 每个项目各有专属 bot，记自己的 repo 测试规则和上下文，不搞写作 设计 review 测试拆一堆 2 写代码不用 Cursor cloud agent，慢没必要，直接在 bot 电脑上跑 Cursor CLI，我是老的 plan，bot 和 grok model 和 other models 是分开算的，还有 Codex CLI 作为辅助。 3 按任务换模型，安装到了全局 skill 当中 代码： 规划大任务用 Opus 5.5 写具体实现用 Grok 4.7 review…

最近开发项目的经验发现，PR 完全没用了，原来是人类 review 的关卡，现在开之前 AI 都 review 完了，变成了一种仪式感的东西，就是看看 CI 变绿就无脑点通过了。 现在我的开发方式变成了，同一项目多个 feature，采用基于 worktree 的多 branch 并行开发，开发完了，大 feature，双甚至三 Agent 用不同模型从头开始交叉 review ，改 P0 - P1 的共性问题，别的不管了，小修改，直接一个模型 review 一次。 Review 通过以后，跑一次全量 E2E，跑 pre-commit 检查，没问题就直接 merge main 提交了，整个…

昨天还在说 Code Review 的实践，今天Anthropic就写了一篇文章详细描述它们 Code Review 的工程实践： https://t.co/ApdUTxp8pv 非常受用，可以好好读一下，核心观点是：代码多到人读不过来之后，人已经不 review 代码了，而是追求花最少的时间 并且回滚和事故又不增加 一个改动要过七层检查，几点也很有趣： 1 让 Agent 提 PR 之前先自证 证明做完了 测试 截图 等等 2 每个 PR 都有 AI review diff，对照整个仓库和 PR 的意图来审 多个 agent 同时找 bug 再由另一组投票，多数认定是真问题才发出来…

太艺术了 试了一下确实是艺术品 真的漂亮 看着这种机械结构忍不住把玩一下 而且惊叹于 Claude 的创造力 很强 https://t.co/NHly6T3O90 https://t.co/eKx3qarVKR

现在失业怎么都搞 OPC 去了，我的一点小建议： 1 认真找工作 虽然已经很难找了 但是还是有可能找到的 2 少看成功故事 别光看月入万刀 多看失败故事 看月入零刀的 精心开发一个月的产品 没有一个用户的 这样不会一腔热血就开始干 3 从月入十刀开始努力 月入十刀应该能战胜 90% 的OPC 或者独立开发者 4 验证了的产品要坚持不懈 别倒腾一个产品一个月发现不赚钱就开始搞另外一个了 5 搞这个东西 和工作多少年也没有关系 都是新人