这篇就作为是 CodeFlicker 天使用户体验记录的第一期吧。#

先说背景，我不是拿它跑了一个 demo 就来写体验。这个月基本是边用边在群里提问题，很多点也不是“好不好看”“顺不顺手”这种泛体验，而是更深入一点的东西：模型列表、倍率、登录态、Duet 入口、workspace 缓存、版本号、代码索引、Wiki，还有积分消耗等。

所以这篇不会写成官网功能介绍。功能列表大家自己看官网就行，我只写我实际遇到的东西。

模型列表其实是第一印象#

我第一次打开 CodeFlicker，第一眼看的就是模型列表。

AI IDE 和普通 IDE 不一样。普通 IDE 可以先看 UI、插件、主题、快捷键；AI IDE 第一眼基本就是看模型。模型版本是不是新、倍率合不合理、延迟稳不稳、有没有 Codex 这种编程侧模型，基本决定了它能不能被我放进真实工作流。

当时我比较在意几个点。

GPT 系列没有跟到我预期中的新版本，Codex 相关模型也没看到。GLM-5 这边有卡顿感。还有就是一些低成本模型的倍率看起来不太符合直觉，比如 DeepSeek 这类模型，如果倍率和高成本模型差距不明显，用户会很难判断应该怎么选。

这个问题不是简单的“贵不贵”。

AI IDE 的核心用户大多知道模型大概成本，也知道哪些模型适合重任务，哪些模型适合快速扫代码。如果倍率和用户认知差太远，第一反应不是“你卖贵了”，而是“这个计费系统是不是不透明”。

这一点很影响信任。

模型层我觉得后面最好做得更明确一点。不要只让用户看到一个模型名字，需要能看到具体版本、倍率、effort并且能够进行选择。

这个东西看起来是 UI，其实不是。模型列表本质上就是 AI IDE 的路由配置表。它不清楚，用户就不敢放心跑长任务。

登录态链接不稳定#

前期我和群友遇到过登录态不稳定的问题。IDE、CLI在网页登录后无法回传回来状态，在多次修复后似乎还有这个非常基础的问题，个人认为这是极其影响体验的。并且在登录后也无法看见你目前的具体套餐状态，通过点击进入网页的方式虽然是通法，但在回传状态不稳定的情况下建议考虑（修好了也就无所谓了，毕竟Antigravity和cursor也是类似的）

这块我建议后面直接做显式状态：

• 当前账号+当前套餐或资格
• CodeFlicker设置
• ……
• 当前版本号+检查更新

这些东西不用做得很花，但一定要能看见。

Duet 的方向可以，但别和 editor 绑太死#

Duet 是我比较关注的功能。

我理解 CodeFlicker 想把 Duet 做成一个任务入口，而不是编辑器右侧普通 Chat。这个方向我认可。现在很多 AI IDE 其实最后都变成了“一个会改文件的聊天框”，Duet 如果能往任务工作台走，是有差异化的。（但是很显然，别人家跑的确实更快一些，curosr和trae已经可以做到独立了）

但我实际用的时候，感觉它现在和编辑器窗口绑得有点紧。

比如打开 Duet 还依赖 editor。这个交互我觉得非常奇怪，二者需要同时在一起运行才行，即使我们用户看不见，内核在后台运行也行的呀。

因为很多时候我打开 Duet 并不是马上要改代码。我可能只是想先讨论需求、整理方案、看一下项目结构，甚至只是问一下这个项目应该怎么拆。这个阶段并不一定需要 editor 立刻出现。

更合理的方式应该是：

先打开 Duet，绑定 workspace；
如果只是讨论，就停留在任务视角；
如果要读文件，再进入代码上下文；
如果要改文件，再唤起 editor。

这样 Duet 才更像任务入口，而不是 editor 的附属窗口。

这个问题不只是交互问题，背后其实是产品形态问题，这个cursor和trae布局很早且很快。

CodeFlicker 如果想做“AI IDE”，那 Duet 依赖 editor 很正常；但如果它想做“AI coding workspace”，那 Duet 应该比 editor 更靠前。editor 只是执行阶段的一个界面，不应该是所有任务的入口前提。

workspace 状态需要当成一等对象#

和 Duet 相关的另一个问题是 workspace。

我遇到过这样的情况：在 Duet 里打开了目录，editor 侧也能打开，但重启之后状态没有很好恢复。然后进代码索引页重新打开文件夹，又跳到另一个编辑器页。

这个体验很割裂。

普通 IDE 里，workspace 可能只是一个窗口状态。但 AI IDE 里不是这样。workspace 是整个系统的根。

代码索引基于它。
Wiki 基于它。
Agent 工具调用基于它。
Git 状态基于它。
文件写入也基于它。

如果 workspace 状态不稳定，上面的东西都会变得不稳定。

用户每次打开都要确认：现在 Duet 绑定的是哪个目录？索引的是不是这个目录？Agent 等会改文件会不会改到另一个窗口？Wiki 是基于当前项目，还是上一次项目？

这类问题最后都会消耗用户的注意力。

我觉得这里需要把 workspace identity 做清楚。Duet、Editor、索引页、Wiki 页都应该共享同一个项目状态，而不是各管各的。

索引是目前最卡我的点#

现在 CodeFlicker 里最影响我连续使用的，还是索引。

打开项目需要索引，这个能理解。问题是后续修改文件、生成文件之后，经常又开始索引。有时候看起来像是重新跑一遍。个人网站这种不算特别大的项目，都能让我感觉索引一直在路上。

这个很伤节奏。

索引本来应该是给模型补上下文的，不应该变成用户等它完成的东西。尤其是 AI IDE 里的对话是连续的，用户很可能一边让它改代码，一边让它解释，一边继续追加需求。如果每轮中间都被索引打断，agent loop 就不顺了。

我感觉现在的问题像是 invalidation 粒度太粗。文件一变，就容易触发比较重的索引任务。Wiki 那边也有类似感觉，像是项目理解、代码索引、文件变更监听之间没有拆得很清楚。

我觉得这里比加新功能更优先。

首次导入全量索引没问题。后面应该尽量增量（增量变化个人感觉其实挺难的，但一定是效果较好的）。依赖目录、构建产物、日志、缓存、临时文件这些默认就该排除。生成文件也不应该轻易触发整套重建。且需要想好，当任务执行过程中，代码会进行修改，那么wiki和索引的状态应该怎么变呢（前端显示）。

还有一个点，索引任务最好不要完全阻塞对话。

比如我只是问一个普通问题，或者让它解释当前打开的文件，不一定要等整个项目索引完。可以允许用户在“索引未完成”的情况下继续跑低依赖任务。否则用户会觉得 IDE 一直在准备，真正干活时间反而变少。

我现在对索引的期待不是“更炫”，而是更安静。它应该在后台把事情做好，而不是反复跳出来告诉我它又开始了。

Wiki 也依赖索引质量#

Wiki 这个功能我也看了。方向是好的，项目级知识库对 AI IDE 很有用。

但 Wiki 的效果很依赖索引质量。如果索引本身不稳定，Wiki 就会跟着不稳定。如果代码变更之后 Wiki 更新策略不清楚，用户也会不知道它现在读到的是不是最新结构。

这里我觉得可以把 Wiki 和索引拆开看。

索引是底层数据结构。 Wiki 是基于索引生成的项目摘要。

这两者不应该完全绑死。代码有小改动，不一定马上重建 Wiki；Wiki 也不应该因为几个生成文件就重新开始一套重流程。

更合理的方式可能是：索引增量更新，Wiki 按模块或目录局部刷新。用户也可以手动触发 Wiki 刷新，而不是所有事情都自动发生。

自动化太积极，有时候反而像 bug。

版本号和更新提示别藏太深#

还有一个小问题：版本号（上边也说过了，不再赘述）。

早期产品更新很快，这时候版本号其实很重要。用户反馈 bug 的时候，开发最先要知道系统、架构、版本、复现路径。如果本地版本号不好找，沟通成本就上去了。

我之前也提过，希望更新页面或者角落里能看到当前版本号。检查更新的时候，也应该显示当前版本、最新版本、更新内容。

不然用户不知道自己是不是最新版，也不知道自己遇到的问题是不是已经修过。

这个功能没什么复杂的，但很实用。尤其 CodeFlicker 现在还在快速迭代，用户反馈本身就是研发流程的一部分。反馈链路越清楚，修问题越快。

团队响应速度是我愿意继续用心测的原因#

虽然前面说了不少问题，但我对 CodeFlicker 不是负面评价。

我愿意继续测，是因为它确实在变好。

最开始我对它的感觉是“根本用不了一点”，后面已经变成“可以连续使用”。bug 少了不少，群里反馈也有人接，不是那种用户说完就没下文的状态。

这个对早期产品很关键。

AI IDE 赛道现在已经很卷了。Cursor、Claude Code、Codex 插件、Trae、opencode 这些东西都在抢开发者时间。CodeFlicker 如果只是做一个“功能很多的国产 IDE”，其实不太够。

大家最后都会有 Agent、补全、计划模式、索引、MCP、Wiki、模型列表。真正能留下用户的，还是底层体验。

模型稳不稳。 索引会不会打断工作流。 workspace 状态是不是可靠。 积分消耗是不是可解释。 长任务能不能连续跑下去。

这些才是关键。

目前的期待#

最后放一下我现在对 CodeFlicker 的期待。

第一，希望能更快响应新模型。

比如 GPT-5.5、DeepSeek V4 Pro、Flash 这些模型。AI IDE 用户对新模型非常敏感，新模型出来之后大家都会第一时间试。如果 CodeFlicker 跟进慢，用户很容易回到原来的工具链。

第二，定价需要前期就考虑好。

倍率会影响信任度。这个点我觉得挺重要的。用户不一定要求便宜，但会在意它是不是合理。低成本模型、高性能模型、推理模型、快速模型，最好一开始就有比较清楚的价格逻辑。

第三，底层基础设施还要继续补，尤其是索引。

索引不是“有这个功能就行”。它是整个上下文系统的地基。如果索引频繁重跑、阻塞对话，Agent、Wiki、Duet 都会被拖累。

第四，也是我最希望尽快加的，是模型缓存。

现在积分消耗确实偏快，而且从用户侧看不太出来缓存有没有生效。AI 编程任务里有大量重复上下文：项目结构、文件内容、Wiki、系统 prompt、历史对话、工具说明。这些内容如果每轮都按完整输入算，用户成本会很高，平台自己的推理成本也不会低。（现阶段模型缓存基本都是9成以上，但是每次任务积分消耗都是那些，这消耗太太太快了）

缓存做好，不只是给用户省钱，也是给 CodeFlicker 自己省钱。

如果后面积分明细里能体现缓存命中就更好了。比如哪些上下文复用了，哪些内容重新计费，缓存后省了多少。用户看得见，才会更敢把真实项目放进去跑。

总的来说，CodeFlicker 现在还没到我能无脑替换主力工具的程度，但已经从“尝鲜工具”往“可以继续认真测试的 AI IDE”靠近了。

后面能不能留下用户，就看这些底层工程问题能不能补上。加油吧，到时候看看第二期如何~

引自DeepSeek的一句话

「不诱于誉，不恐于诽，率道而行，端然正己。」