fqyd

@poxiaohy 听起来 Zed 不错，我试试

@poxiaohy 我也不喜欢 Superpowers ，太死板了。/pan 之前用过，但是体验不是很好，如果问题比较复杂，在 cli 窗口讨论不是一个好的位置，我更喜欢在专门的 markdown 阅读器和 txt 编辑器里面（我用的是 idea ，刚好 md 和 txt 的阅读和编辑体验都挺好的）去阅读和编辑问题，然后把回复的文件路径发给 AiAgent 。更主要的原因是，把需求和沟通过程存到本地，可以脱离单次会话容量、AiAgent 、LLM 模型的限制，而且后续如果要做定期的回顾的时候，可以利用留下的文件做分析总结。
[Kimi-2.7 我觉得最大改善就是思考循环问题，之前 2.6 经常出现各种等等...，啊！什么的，然后自己陷进去半天最后还吐出来一个错误的结论] 这个是的，对我的流程来说，这是最大的改善，LLM 可以不那么聪明，我可以引导它，但是不能不听指挥，之前 k2.6 的思考循环问题导致它很难遵循指令，所以 k2.7 改了这个之后，对我的流程提升很大。

@poxiaohy Kimi-2.6/2.7 肯定是不如 GPT 5.5 的。我上面说的只是陈述一下之前使用 k2.6 的情况。因为我的习惯是在开始执行前先让模型把讨论过程都写在本地文件中，所以没开/plan ，gpt 和 deepseekv4 pro 都能按照这套流程走，但是 k2.6 不行，它的思考过程很奇怪，经常会忽视我的约束指令直接去改代码，k2.7-code 算是把这个问题给改了，指令服从度相比 2.6 高了不少。

@poxiaohy k2.6 非常不可控，经常在讨论阶段去做执行，几乎没法用。kimi2.7-code 起码能听指挥了，比 DeepSeek-v4-pro 强个多模态能力，就是上下文短了

@NeoWalnut 我就是这么干的，好处很明显啊，所有计划都确定了，基本不用返工，而且开新会话，切新模型或者换 Agent ，都可以随便换，完全不会被某个模型或 Agent 绑定。至于中间过程中存在的固定行为，直接让 AI 做个工作流工具把这些动作做成快捷键固化掉就行了。

你可以将这个 plan 内容存到本地文档啊，这样新开会话需要之前的 plan ，把文档甩进去就行了

@widowcat 那我觉得你应该先用 AI 帮你把业务梳理清楚，否则容易改崩。然后，你的 sql 要做个版本管理，方便回退。

你试试呗，我之前用 codex gpt5.4 改过一个上千行的 mysql 的存储过程，效果不错。

基本野榜了，kimi2.6 我的使用体验除了有个多模态外，全方位不如 deepseekv4 pro 。不可能有榜单里面差距的那么大