- 发布时间
从 IDE 到 ADE：我们现在怎样用 iKanban 与 AI 协作
- 从一个更好用的编辑器，到一个给 Agent 用的环境
- iKanban 负责什么，OpenCode 又负责什么
- 我们日常怎样走完这个循环
- 审阅的不一定是代码，也可能是一篇论文
- Agent 跑得更久之后，跨端访问就成了日常需求
- 放回四层结构里看，我们最近在优化哪里
- 从通用 ADE，到面向特定领域的 AI 工具
- 总结：我们想优化的是人与 Agent 之间的往返
过去我们分享了不少 AI 工具：某一个 CLI、某一种多 Agent 模式、一组 skills，或者一次 runtime 的迁移。这些文章各自解决了一个问题，但如果想知道“我们每天究竟怎样用 AI 工作”，只看其中任何一篇，都不太完整。
到了 2026 年 10 月，这套工作方式已经稍微稳定下来。我们想把它串起来介绍一次：以 OpenCode 为执行后端，以 iKanban 为人的交互界面，把日常工作组织成表达意图、Agent 执行、审阅结果的循环。
这篇不再逐个介绍工具，而是讲这些工具怎样组成一个工作环境，以及我们为什么还要继续维护自己的界面。
从一个更好用的编辑器，到一个给 Agent 用的环境
如果很早就关注我们，可能还记得，持续写博客和做视频的起点之一，是 2025 年 1 月的《Neovim 入门》。当时我们关心的是怎样减少鼠标操作，怎样让编辑器和日常工具遵循一套更统一的逻辑。后来的 Linux、窗口管理器和 IDE 之旅，也都沿着这条线展开。
到了 2026 年 2 月，我们在《更好的 AI IDE：软件应先服务 AI，再服务人类》里提出了另一个问题：当代码主要由 Agent 编写时，我们是不是还需要一个围绕人手动操作代码而设计的 IDE？
现在，可以用 ADE（Agent Development Environment，面向 Agent 的开发环境） 来描述我们想做的这一类应用。这里借用这个概念，是为了说明设计重心的变化，并不是要划定一个严格的产品分类。
传统 IDE 把搜索、编辑、重构、测试等操作集成到界面里，方便人直接完成它们。而在我们的工作流中，Agent 已经可以通过终端调用工具、修改文件、运行构建和测试。许多过去需要人点击界面完成的操作，不再需要经过人的手。
这不意味着所有 GUI 都应该被替代，而是说：Agent 的执行界面和人的工作界面，不必是同一个东西。 终端和结构化工具适合 Agent；清楚的任务状态、可阅读的摘要和产物预览，则更适合人。这也延续了我们在浏览器优先工作流中的变化：底层仍然是终端工具，人却不必一直待在终端里。
iKanban 负责什么，OpenCode 又负责什么
iKanban 是我们从年初开始持续迭代的项目。它中间经历过多次重构，也尝试过不同的底层方案。在 DeepSeek Harness 上重写 iKanban记录了其中一个阶段，但那篇描述的是当时的实现，不能直接当作今天的安装说明。
当前版本是一个面向 OpenCode V2 的独立静态前端，直接采用上游共享的桌面 / Web 应用。浏览器通过 API 连接运行在工作机器上的 OpenCode 后端。项目、会话、工具执行和文件访问都围绕后端所在的环境展开，前端负责把这些过程呈现给人。
这个边界很重要。我们不打算在 UI 里再实现一套 Agent runtime，而是把精力放在人的两项工作上：
- 表达意图：说明要做什么、有哪些约束、什么结果才算完成。
- 审阅结果：判断 Agent 做得是否符合目标，哪里需要补充、修改或重新执行。
当前 iKanban 已经提供项目与会话管理、worktree 工作区、文件引用、Git diff 审查、文件预览和终端等能力，也支持多服务器切换与移动端布局。可以直接打开 iKanban 在线前端，按仓库说明连接自己的后端。
这些功能并不是彼此独立的卖点。它们最终都要服务于同一个循环：把意图交给 Agent，再把可判断的结果交还给人。
我们日常怎样走完这个循环
以给项目增加一个功能为例，我们通常先进入对应项目和工作区，新建一个会话。相对独立的任务可以放进单独的 worktree，避免多个会话同时改动同一份工作目录。关于隔离和并行，我们在多 Agent 并行工作流里已经展开过。
接下来表达需求。这里最重要的不是把 prompt 写得很长，而是把目标、边界和验收条件说清楚。比如，与其只说“增加 PDF 预览”，不如说明它应该出现在什么位置、要解决什么审阅问题，以及是否允许引入新依赖。相关文件可以直接引用，不必把所有背景都重新描述一遍。
执行开始之后，Agent 负责读项目、形成方案、修改文件和运行验证。我们不需要逐条盯着它的命令，而是在它需要澄清、申请权限或者给出阶段结果时回来处理。多个会话可以各自推进，但并行的前提仍然是任务边界清楚，而不是单纯多开几个聊天窗口。
结果回来后，我们先看这次修改的整体说明，再根据需要打开 diff、测试结果或最终产物。如果方向不对，就补充意图，让 Agent 继续修改；如果方向正确，但验证不足，就要求它补齐证据。
这和过去“先打开编辑器，再自己逐步实现”的区别在于：我们首先组织的是任务和验收，而不是文件和编辑动作。
表达意图：用 audio2text 减少输入成本
在表达意图这一步，我们已经有一个配套项目：audio2text。它是面向 Wayland 环境的中文语音转文字工具，可以把识别结果直接输入当前获得焦点的应用。
很多时候，我们已经知道想做什么，只是需要把一段尚未完全整理的想法交给 Agent。对这类输入，先说出来，再整理成明确需求，可能比从空白输入框开始打字更顺畅。尤其在手机端，输入成本会更加明显。
具体使用时，我们把焦点放在 iKanban 的输入框里，通过窗口管理器配置的全局快捷键开始录音，说出需求，再检查转写文字、补充相关文件和约束，最后发送给 Agent。audio2text 负责把声音变成输入，iKanban 负责把意图交给后端，两者不需要在应用内部做专门集成。
目前 audio2text 默认使用 WeType，也支持切换到 DashScope。它是系统级输入工具，不是 iKanban 内置的语音功能，也不是手机端方案；直接输入需要 Wayland 合成器支持相应的虚拟键盘协议。音频会发送到所选的云端识别服务，因此涉及敏感内容时，也要考虑这一步的数据流向。
这套方式要解决的不是“让 prompt 更随意”，而是缩短从想法到可执行任务的距离。转写之后，目标和边界仍然需要确认；说得快，不等于表达得清楚。
审阅结果：先看摘要，再按风险下钻
另一个变化发生在 review 上。以前 AI 一次生成的代码不多，我们可以逐段阅读 diff。现在一个任务可能同时修改很多文件，如果仍然要求每一处都以同样的精度人工阅读，审阅就会成为整个流程的瓶颈。
所以，我们现在更常从针对整个 commit 或一组变更的摘要开始：实现了什么，为什么这样改，影响了哪些模块，做了哪些验证，还有哪些已知限制。我们先审阅这份说明，判断功能方向，再决定往哪些细节继续看。
这不是说摘要可以证明代码正确。摘要同样可能遗漏问题，甚至与实际修改不一致。它的作用是帮助我们分配注意力，而不是取消 diff。涉及认证、数据删除、权限或其他高风险逻辑时，仍然需要回到具体实现。
对于可以机械检查的质量要求，我们更希望提前放进项目规则和自动化检查里，例如格式、类型、测试和依赖约束。相比年初，我们在日常使用中感觉模型对明确指令的遵循更稳定了，但写进提示词的规则仍然只是软约束；能通过检查阻止错误进入下一步的规则，才是硬约束。
人的注意力因此可以更多放在“这个功能是不是我们想要的”上，但不能把“Agent 说完成了”当成验收依据。
审阅的不一定是代码，也可能是一篇论文
表达意图和审阅结果可以是通用框架，但具体怎样表达、怎样审阅，取决于领域。
在代码项目中，diff 是重要入口；而在论文写作中，即使源文件修改看起来没有问题，我们最终仍然要看编译出来的 PDF：公式有没有溢出，图表能不能读，分页是否合理，论述是否连贯。只看 LaTeX 或 Typst 的文本变化，无法完成这些判断。
所以，对我们来说，在 review 界面中预览 PDF，是一个明确的领域需求。这里也需要区分：输入框能够接收 PDF 附件，并不等于已经具备面向论文产物的完整 PDF 审阅体验。
同样，其他领域也可能需要自己的产物视图。我们希望以后能通过插件补充这些审阅能力，而不是把所有领域功能都塞进通用界面。这仍然是后续的扩展方向，不是说当前 iKanban 已经有一个完整的领域插件生态。
通用 ADE 要解决的是交互骨架；领域扩展要解决的，是让人真正看见并判断这个领域的工作成果。
Agent 跑得更久之后，跨端访问就成了日常需求
当只有一个短会话时，坐在电脑前等结果还算自然。但当多个会话同时运行，或者单个任务需要更长时间，我们就不希望一直守在工作机器前。
我们需要的往往只是：离开电脑后，在手机上看一下最新结果，回答一个澄清问题，或者判断下一步应该往哪个方向走。不是把完整开发环境搬到手机，而是把必要的决策入口带走。
OpenCode 的客户端—服务端架构为这件事提供了基础。会话和执行发生在后端，桌面浏览器和手机浏览器可以连接同一个服务，而不必各自启动一份任务。具体接口可以参考 OpenCode V2 API 文档。
我们自己的部署方式分成两部分，都可以在公开配置仓库里找到：
- 通过 systemd 用户服务托管 OpenCode 后端，让它在用户服务启动时运行，并在失败后重启。
- 通过 frpc 配置，把本地后端端口转发到公网服务器，再由服务器上的 Nginx 提供 HTTPS 入口。
访问路径可以理解为：手机或电脑上的 iKanban，经由公网 HTTPS 入口和 FRP 隧道，连接工作机器上的 OpenCode。前端换了设备，实际工作的环境并没有换。
这里不能把“端口通了”等同于“可以安全使用”。这个后端能够操作项目文件、运行命令，远程访问需要认真对待认证和传输安全。我们的要求是使用足够长、随机的服务凭据，并将后端认证与 FRP 隧道认证分开配置；公网入口使用 HTTPS，远端转发端口不直接开放给公网。
仓库中的 FRP 配置只保留结构和环境变量引用，真实密钥放在不提交到 Git 的本地配置中。systemd 服务也从本地环境加载凭据，而不是把密钥写进公开服务文件。相关配置分别归档在 linux-config 和它的 .config 子模块 arch-config 中。
这些文件是我们环境的实现记录，不是复制后就能保证安全的通用部署方案。尤其 systemd 用户服务的开机运行，还取决于具体的用户服务启动配置。
放回四层结构里看，我们最近在优化哪里
我们之前写过四层多 Agent 工作流。当时第三层主要围绕 Superpowers、worktree 和结构化执行展开。现在回看，我们更愿意把这一层理解得宽一些：它是项目或领域所需资源的组合，而不只是某一个工作流工具。
| 层次 | 解决的问题 | 当前工作流中的位置 |
|---|---|---|
| 第 1 层：模型 API | 使用什么模型，以什么成本获得能力 | 可替换的模型接入 |
| 第 2 层：Agent runtime | 怎样管理会话、调用工具并执行任务 | OpenCode |
| 第 3 层：项目与领域资源 | Agent 在这里应该遵循什么规则，具备哪些能力 | 项目指令、skills、MCP、验证工具和工作流 |
| 第 4 层：人的交互环境 | 怎样提出要求、观察状态和审阅结果 | iKanban 这样的 ADE |
这里的“稳定”，不是说第一、二层从此不会更换，而是它们的职责和接入方式已经比较明确。我们不需要每做一个上层功能，就重新探索一次模型接入和工具执行。
第三层也已经积累了不少可复用资源，例如 OpenCode 配置和自定义 skills。这些资源决定 Agent 怎样工作，第四层则决定人怎样参与这份工作。
最近我们更多的优化，恰好都落在第四层：输入怎样更顺畅，摘要怎样更容易审阅，特定产物怎样预览，以及离开电脑以后怎样继续做判断。
这也解释了为什么我们还想维护 iKanban。底层 Agent 越能独立执行，人这一侧的交互就越值得单独设计。
从通用 ADE，到面向特定领域的 AI 工具
我们的最终目标，不只是做一个更顺手的通用 coding 界面。我们希望在这套通用交互之上，组合出面向特定领域的 AI 原生工具，论文写作就是其中一个方向。
它可以被叫作第五层，也可以理解为第四层 ADE 的领域化变体。名字并不重要，关键是：把领域资源和领域审阅方式一起交给使用者，而不是让每个人从零拼装。
为此，我们维护了 AI4Paper（ai4paper） 组织。目前可以直接参考的资源包括：
- apaper-plugin：组合学术写作、论文绘图 skills 和文献研究工具，为 Agent 补充论文工作所需的能力。
- apaper-mcp：提供学术来源检索、文献元数据与 BibTeX 获取，以及受支持的论文下载能力。
- book：围绕选题、实验、写作、投稿和修改等阶段整理实践方法。
这里也做一个历史说明：旧的 iPaper 工作区曾经尝试过独立的产品封装，但按照 AI4Paper 当前的组织说明，它已经停止开发。当前路线以 OpenCode 为 runtime，围绕插件和研究工具积累能力，而不是继续维护那套旧工作区。
这些资源还不等于一个完成的论文 ADE。它们提供了领域能力和流程基础；怎样让研究者更容易表达研究意图、核实来源、审阅论文产物，仍然是我们希望继续完善的部分。
总结：我们想优化的是人与 Agent 之间的往返
从 Neovim、Linux 到现在的 iKanban，表面上我们一直在换工具，但关注的问题已经变了。早期是怎样更高效地亲手操作计算机，现在则是怎样把工作交给 Agent，同时保留清楚的判断和控制。
目前稳定下来的答案是：让模型和 runtime 负责执行，让项目资源提供规则与领域能力，再通过 ADE 把人的工作集中在表达意图和审阅结果上。语音输入、变更摘要、产物预览和跨端访问，都是在减少这两件事的阻力。
我们会继续维护和优化 iKanban，也会继续探索论文写作这样的领域工具。衡量这些工作有没有价值的标准，不是界面里多了多少功能，而是：我们能不能更清楚地提出要求，并且更快、更可靠地判断结果。