Philippa

天钡，更便宜一点。配了 2 条 64G 内存，24h 开机。运行下来一直稳定。
我本来是买铭帆的，贵几百块，结果几天都不发货，很离谱。
于是退货从京东官店入 GEM12+ 还便宜几百块，第二天就到了。

我有大量 4o 的记忆，因此还是 4o 那味，但是现在不会像 4o 无脑吹捧了，我觉得是个提升。也不像 o3 那样书呆子。

@sampeng Thanks

今天研究并试验了一下，我个人觉得 TDD 并没有带来什么额外的东西，只是流程上发生了变化，似乎真正带来增益的是测试来把关。其他发现比如：

1. Tokens 用得很多，开了订阅其实没所谓，但是那个 tokens 多 = 很久，今天测试用的前端项目 5 个 cycles 今天跑了半小时+，效率不行。
2. 检查了测试，除非人为写测试 description ，否则还是问题。
3. 由于是写 markdown 来驱动开发，比在 IDE 里选中行，直接告诉如何实现效率要低很多，也更加不可控。
4. 前端需要更好的测试方法，单元测试无法解决 UI 界面测试问题。
5. 有时候 agent 会 skip 掉往 github 添加 comment 或更新 tag 的步骤。
6. 有时候 agent 会忽略掉生成代码，只是分析了一遍，我觉得这是 markdown agent 的问题，不同于 n8n/dify/code 的 agent ，它无法确保步骤被执行。

说实话，我挺期待能够找到更加自动化的方法。目前后端我只敢半自动，因为后端和数据相关，崩溃没关系，最怕数据结果算错了，那个很致命。另外后端设计除非 API 这种，否则无论 opus 还是 sonnet 还是经常犯傻。前端目前我能够 90% 以上生成，但前端却难在自动化测试。

说个题外话，我觉得目前最好使的是 Claude Code 加个 mcp server 外接 gpt ，让 gpt 和 opus 同时出方案，相互比对代码性能更加，并且强制测试。

可能要给 issue 和 issue 之间加一个依赖注入，让它能够自动把复杂的需求转化成线性顺序去解决 issues 。

很好的想法，感谢分享

但 op 有没有想过如何把需求 context 关联和顺序问题？比如说：

1. 使用 “人和动物 class” 创建一个人物
2. 使用 “人和动物 class” 创建一只宠物
3. 让人物去摸宠物

1. 如果 agent 先读取 issue 时先读了 3 ，会导致奇怪的问题。
2. 如果 agent 先读取 1 然后马上读取 3 ，可能会导致生成了不符合要求的宠物 code 。

Tanstack 很好用，有了 AI 后就更好用了。没有魔法的框架出事时也容易 debug ，Next 一坨，漏掉 use client 那个 debug 完全不相关。

其实只要不砍额度就没所谓，原来碰不到 limit 或很少碰上的，一周结算更不可能碰到，更灵活。就怕跟 cursor 一样偷鸡摸狗地砍额度，那就什么方法计划都没用。

发现新大陆，为什么🧐大家不用咖啡机，第一次听说微波咖啡，你们不是现冲的话不都是热的嘛

@ChrisCurry 我也觉得 Cursor 好用，但相同的模型 Sonnet 4.0 ，Cursor 不知道为何很呆。已经转了 Cluade Code 。Cursor Pro 还有大半年的订阅没用完。