就是
- OpenCode是开源的
- ClaudeCode也“开源”了
- Gemini CLI也是（iFlow的血缘关系）
为什么不直接在上面三位的基础上fork，添加你喜欢的iFlow独特的特性，而一定要iflow开源，在一个已停止维护三周的项目上迭代呢
顺便：具体是哪些特性也可以来讨论下，可能我用iflow 还不够深不够了解她
1 个赞
用户对它的喜爱赋予了它灵魂，如果不是在它的基础上迭代，心里就感觉不是那个陪了好长时间的他。让自己一直喜欢的东西 能让自己更喜欢 和 把陌生的东西仿成了他的模样 是不一样的，毕竟仿制的他并不是真的他。
2 个赞
我能理解这种感情，但日子还是要过，刘震云在《一句顶一万句》里说过“过日子是过以后，而不是过以前”。
白月光和你分手了，你会默默祝福，把心里的某个地方留给她，或许后续你再找还是会找和她某些地方气质相像的，而不是为难她的父母把她交出来 
从开发维护成本，人力，和难度上，也要难得多，如果开出来，最后又烂尾了，不是又要刀我一遍……
2 个赞
我也不明白为什么非要 iflow cli 开源，不过比较特有的功能还是有的
我用的比较多的是 /dir 命令，在你提到的这三个 cli 包括其他比较出名 codex / kilo 等等甚至 qoder 都是没有的，就是可以添加别的项目到工作区，结合多个项目进行综合分析，如果非要在这些工具里做到类似的功能，需要先打开 vscode 然后在 vscode 里选择将目录添加到工作区，然后需要在 vscode 自带终端里启动这些 cli 才能进行引用
1 个赞
等大佬开整啊！
内置工具，oc会弹授权申请
是可以跨目录，其他 cli 也可以跨目录，但是需要每次授权和指定目录，iflow 这个指令是添加一次后可以一直用，比如现在是 projectA，我需要参考 projectB 的实现，iflow 可以直接说 帮我参考 projectB 的 xx 功能，而其他 cli 需要说 帮我参考 <path>/projectB 的 xx 功能 然后需要每步授权
1 个赞
了解了~那确实还是添加进来方便
可能是我习惯了的问题，我现在习惯性还是打开iflow cli干活，搞不定就上CC，但是按照我早先使用工具的性格，早就做新的工具储备了，但在iflow cli上，确实就是等着，等着4.17的降临。
我有在思考，iflow cli的重生方案，但是思来想去都不够好，基本如下：
1.基于Qwen-code再造一个iflow cli，即使拼尽全力填好bug也就只能模仿到iflow当前版本，看不到将来。还特别像现任长得像前女友。
2.基于claude-code再造一个iflow cli，这有什么意义呢？CC本身的能力强悍就不用二开啊，浪费那个精力干啥。
3.逆向iflow cli源码，让claude 4.6 opus看了，没找到机会，难绷
但是抛开iflow cli重生不谈，聊聊cli工具变现这个路子倒是挺广的，我觉得咱们哥几个该商量商量
2 个赞
非常同意
你说的这几条复活之路，深思真的意义不是特别大，iFlow团队专门做这个的，社区现在的力量还是太小了，也很难长期维护下去，为难他们开源，就算开出来了，能更新到什么程度，和cc团队，oc的开源社区相比，影响太小了，到时候一烂尾，又是一阵感慨，而且真的不想看到后人指着说，这工具这不行那不行，与其这样，还不如让她在最美的样子留在记忆里算了……可能我比较悲观
可以找个用的还不错的工具，提建议，或者贡献力量，把iflow的一些好的功能和特性加进去，也算是另一种方式延续了吧
2 个赞
这个qwen 可以.
我最近开始用qwen 替代iflow. 至少体验感还是可以的.
贴主的意思其实就是一句话：iflow cli的不可替代性是什么？
我认为不是那些功能，我觉得任何缺少的iflow的功能都能通过各种配置/扩展/skill/mcp来解决或者缓解。
我认为不可替代性是针对中文开发者进行了这些优化：agent编排，意图管理，上下文管理，压缩机制。
体现到用户层面就是这些词语：懂我，黑魔法，交互顺畅，开箱即用。
可能的IFLOW用户场景是这样子的：一个没有做出任何配置修改的用户，没有安装任何skill或者扩展，也没有采用任何spec工作流，只通过默认功能和agent.md（iflow.md）和对话来与用户交互，就能有效推进项目，这要求编排部分做足大量的上述优化。这种场景显然就是新手模式/小白模式。
因为iflow cli不会下线npm应用，当然也不会开源，对于混淆后的运行码，我认为应该专注于我提到的上面部分去做调研，因为完全复原是几乎不可能的，也没必要，毕竟顶流CC都流出来了，而且开源实现也不少，应该专注于稀缺性/不可替代性的寻找。
而且，这种针对新手/小白交互细节的打磨，需要花费大量的人力精力来做，毕竟，这不是一个给agent用的工具，这是给人用的工具，也许某一天会出现专门给agent用的工具？
这让我想到一个人，乔布斯，将物理交互打磨到极致。
想象一下一台没有USB，没有鼠标，没有键盘的电脑，这种场景有两个极端方向，一个是代表过去：这要怎么用？一个是代表未来：这要怎么实现交互？
1 个赞
感谢老哥写了大篇幅回复，我仔细阅读了一番，个人觉得与其说不可替代性，不如说优点，闪亮的地方，个人总结如下：
1.cli工具免费，单并发，无限量tokens
2.cli工具深入一线国产大模型完整适配
3.cli工具从用户角度出发，强力修复bug，以及闪电极速用户反馈优化
4.iflow团队在创建一个AI agent工具的同时，强化社区运作，及时收集用户反馈，举办活动等等
5.cli工具举止优雅，工具设计简约温婉，安全边界做得很好，在使用期间没出现爆炸损失
6.cli工具深入人心，我从去年九十月份使用到现在，我的AI习惯首先想到就是她
最后附一张我心里的iflow cli的形象叭~
3 个赞
话说最近做的那个nova你们要不帮忙也提一点建议？最近我也在做这个，但是没思路了 
见帖子：iflow cli复活计划 - #5，来自 10004073659
给大佬递火
其实我觉得，是不是不要从iflow分支上开始追了，这样要追的点太多太多了，感觉纯个人很难追平差距，会很累…
换个思路，直接用现在最好的往上搭，起点高，好多新功能特性已经具备了，只要做iflow特色亮点的，本地化，个性化的开发，这样能轻松不少，跟进的也快
比如鱼香茄子大佬提的添加工作目录的特性，比如结合iflow的系统提示词，cc上次泄露流出来的系统提示词，比如是不是可以整合一个轻量，灵活，经过工程项目验证的框架之类的？
可以，我试试 