简体中文 / English
一个以 IDE 为载体的 AI 工作流产品。
Turing Runner 的重点不是单纯堆 AI 功能，而是把成熟、可复用的开发工作流直接交付给用户。
一句话结论：当前仓库仍处于初始化阶段，这份 README 先明确 Turing Runner 的定位、价值与针对 Android Studio 的优化方向。
| 项目 | 状态 |
|---|---|
| 仓库状态 | 已初始化 |
| 当前代码 | 暂未提交核心实现 |
| 当前 README 目标 | 先讲清产品定位与工作流价值 |
| 产品方向 | 以 IDE 为载体交付 AI 工作流 |
| 当前强调 | 对 Android Studio / JetBrains 使用场景做特别优化 |
Turing Runner 不是单纯的模型调用工具，也不只是另一个“带 AI 的 IDE”。
它更像一个通过 IDE 直接交付工作流的 AI 产品：
- 用户得到的不只是对话、补全或 Agent 能力
- 用户得到的是一整套更成熟的开发方式
- 重点不是多几个按钮，而是让 AI 真正进入日常开发流程
Turing Runner 的核心目标不是卖能力点，而是送工作流。
现在很多 AI IDE 或 AI 编程工具都已经证明了一些方向是成立的：
- 项目上下文驱动的开发方式是有效的
- 高频、低打断的辅助方式是有价值的
- 多模型、任务流、Agent 化协作会越来越重要
但用户真正缺的，往往不是“再多一个模型入口”或“再多一个命令面板”，而是：
- 一套顺手的工作流
- 一套稳定的协作方式
- 一套能长期复用的开发节奏
- 一套不用自己从零拼装的 AI 开发体验
所以 Turing Runner 要解决的问题是：
如何通过 IDE，把已经被验证有效的 AI 开发工作流，直接交付给用户。
很多产品提供的是功能列表，Turing Runner 想提供的是：
- 任务拆解方式
- 上下文组织方式
- 与代码库协作的方式
- 与模型交互的方式
- 日常开发中可复用的操作路径
用户不需要先研究一堆 prompt、规则和工具组合，才能开始受益。
Turing Runner 的理想状态是：
- 打开 IDE
- 进入项目
- 直接使用已经设计好的 AI 工作流
很多高效率 AI 开发方式，本质上是高手手里的隐性经验。
Turing Runner 希望把这些经验沉淀为：
- 可复用的流程
- 可维护的配置
- 可共享的项目约定
- 可持续演进的 IDE 使用方式
重点不是展示 AI 很聪明，而是帮助用户更稳定地完成真实开发任务。
Turing Runner 更适合被理解为：
- 一个 AI IDE 工作流产品
- 一个把成熟开发流程直接交付给用户的 IDE 形态
- 一个强调日常可用性而不是单次惊艳感的开发工具
而不是：
- 仅仅一个模型调用器
- 仅仅一个 prompt 管理器
- 仅仅一个聊天面板封装
Turing Runner 的一个明确方向，是针对 Android Studio / JetBrains 系 IDE 的开发场景做特别优化。
这不是泛泛地说“也支持 JetBrains”，而是产品设计上会优先考虑这类用户的实际工作流。
这不是一个随意选择的切入点。
Turing Runner 会优先优化 Android Studio / JetBrains 场景，一个很直接的原因是：这个项目本身就来自长期的 Android 开发经验。
作者在 10 年前就是 Android 开发者，对 Android 工程的复杂度、IDE 使用习惯、多模块协作方式、构建与调试链路都有长期的一线体感。
所以 Turing Runner 的很多工作流设计，不是从抽象的“AI IDE 概念”出发，而是从真实开发者每天怎么工作出发。
这也意味着，Turing Runner 会优先关注这些更具体的问题：
- 如何更快理解一个 Android 工程
- 如何处理 Kotlin / Java / XML / Gradle 的联动修改
- 如何减少构建、配置、依赖问题带来的打断
- 如何让 AI 真正贴着 IDE 和项目工作流，而不是悬浮在外面
因为 Android 开发通常同时具备这些特点：
- 工程结构复杂
- 模块多、目录深、上下文体积大
- Kotlin / Java / Gradle / XML / Manifest /资源文件并存
- UI、状态、网络、构建、签名、渠道等问题经常交织
- 开发者很依赖 IDE 本身的索引、导航、重构和调试能力
所以 Android Studio 用户真正需要的，不是一个悬浮聊天框，而是一个能贴着 IDE 工作流走的 AI 助手体系。
以下是当前明确的优化方向，不是已经全部完成的现状承诺：
- 更贴合 Android 项目结构的上下文组织
- 更适合 Kotlin / Gradle / Android 资源体系的工作流设计
- 更重视多文件联动修改场景
- 更重视构建失败、依赖冲突、资源引用、Manifest 配置等高频问题
- 更贴合 JetBrains / Android Studio 用户的交互习惯
- 更强调“在 IDE 中顺手用起来”，而不是把流程切碎到外部工具里
这意味着 Turing Runner 不会只追求“通用 AI 工具”的抽象正确， 而会认真考虑 Android Studio 用户最常见的几个问题：
- 如何更快理解一个 Android 工程
- 如何围绕模块和文件关系组织上下文
- 如何辅助排查构建与配置问题
- 如何支持更自然的改代码、看报错、回到 IDE 继续改的闭环
Turing Runner 主要适合这些用户：
- 希望在 IDE 内直接获得成熟 AI 工作流的开发者
- 不想自己拼装 prompt、脚本、模型入口的人
- 希望 AI 真正融入日常编码过程，而不是只做偶尔问答的人
- Android Studio / JetBrains 用户
- 希望团队逐步沉淀统一 AI 工作方式的团队
| 类型 | 常见特点 | Turing Runner 更关注的点 |
|---|---|---|
| 聊天型 AI 工具 | 回答问题快 | 能否进入日常开发流程 |
| 代码补全型工具 | 高频、轻量 | 是否能承载更完整工作流 |
| 通用 AI IDE | 功能多 | 是否把工作流真正交付给用户 |
| Turing Runner | 以 IDE 为载体 | 把成熟开发方式直接产品化 |
以下是当前规划中的方向，不是已经全部完成的现状承诺：
- IDE 内的 AI 工作流组织
- 项目级上下文管理
- 多模型 / 多 provider 接入能力
- 面向真实开发任务的流程编排
- 针对 Android Studio / JetBrains 的深度适配
- 可沉淀、可复用、可演进的 workflow 机制
- 初始化基础项目结构
- 明确 Android Studio / JetBrains 集成方向
- 设计最小可用工作流 MVP
- 提供基础上下文组织能力
- 提供至少一种 AI 能力接入
- 围绕真实 Android 开发任务做首批 workflow 验证
- 补充文档、示例与扩展机制
- 工作流优先：先回答“怎么用起来顺手”，再考虑功能堆叠
- IDE 原生感优先：尽量贴近开发者已经习惯的工作方式
- 真实任务优先：围绕真实开发任务设计，而不是演示型场景
- Android Studio 友好优先：明确照顾 JetBrains / Android 用户体验
- 长期可演进优先：让流程能持续打磨，而不是一次性拼装
欢迎通过 issue 或 PR 参与这个项目。
当前阶段最重要的贡献方向，不是先堆很多功能，而是一起把这些问题定义清楚：
- 哪些工作流最值得先做成产品能力
- Android Studio 用户最痛的环节是什么
- 哪些能力应该放在 IDE 内，哪些不应该
- 如何让工作流既足够强，又足够顺手
MIT