原生人工智能代码审查集成开发环境 | AI生成和翻译
问：类似Claude Code或OpenCode这样的工具是否应当支持直接的“/read @文件”式命令，让用户无需切换到VSCode就能查看文件内容？
答：
是的——这类/read @文件或“内联文件查看”体验正是提升你所指工作流程的关键。
你所察觉到的其实是一种上下文切换摩擦问题：
- 你要求AI处理代码库
- 但之后仍需打开VSCode（或其他编辑器）来核对文件内容
- 这破坏了在单一系统内工作的“闭环感”
更理想的集成设计应当如下：
1. AI界面中实现原生文件读取功能
无需使用：
展示marp_watch.py文件
而应支持：
/read @ww/marp/marp_watch.py
甚至：
@ww/marp/marp_watch.py
这使得文件本身成为可引用的对象，而不仅仅是字符串参数。
2. 此举为何重要
这不仅是便利性问题——它将改变工作流：
- 减少上下文切换 → 降低认知负荷
- 强化AI信息基础 → 模型始终能查看文件的确切状态
- 加速迭代循环 → 读取→修改→验证可在同一环境中完成
- 提升可复现性 → 消除“文件版本差异”的模糊性
3. 当前系统仍依赖编辑器的原因
Claude Code等工具往往依赖VSCode，主要因为：
- 编辑器本身已针对文件导航进行深度优化
- AI工具初期更关注生成能力，而非导航用户体验
- 文件浏览界面设计复杂度高（树状视图、差异对比、搜索功能等）
但这种状况正在改变——新型智能体工作流已明显朝着这个方向演进：
“让AI成为核心IDE界面，编辑器转为可选项”
4. 流畅系统应具备的体验
真正集成的系统应当包含：
/read @文件/search "匹配模式"/diff @文件/edit @文件- 内联预览（无需外部编辑器）
至此，VSCode将仅作为一种可选的渲染器，而非工作流的核心。
核心结论
是的——你的直觉完全正确。
/read @文件式命令（或等效的基于实体的文件引用）是实现更无缝“AI原生IDE”的关键步骤，届时你将无需跳转至VSCode仅为了查看文件状态。
真正的演进方向是：文件应当成为对话中可寻址的对象，而非需要额外获取的外部产物。