AiderDesk
通过桌面工作台组织 AI 开发任务，查看代码修改并控制智能体协作过程。
AiderDesk 是面向软件开发的桌面工作台，可按项目和任务组织 AI 编程，查看代码差异、配置工具权限，并用 Git worktree 分开处理不同修改。
可以用来完成：修复小缺陷、补写开发说明、比较重构方案。
AiderDesk 能做什么
它需要实际代码项目、可用模型及对应开发环境。适合愿意检查代码和测试结果的开发者，图形界面不能替代对项目运行方式的了解。
先给出一个可复现的小问题，把修改范围和验收命令写清楚。模型生成、测试通过、合并代码与上线是不同环节。
按任务组织开发
在项目下区分功能与缺陷任务，保留各自的对话与工作上下文。
隔离不同修改方向
使用配置好的 Git worktree 为任务建立独立目录，便于并行尝试和后续合并。
检查差异和工具动作
差异视图用于逐行审阅；可配置工具审批规则，控制命令与文件操作。
选择模型和协作方式
支持不同模型提供方、智能体配置与子任务协作，可按项目需要组织上下文。
- 核心用途
- 项目任务管理、代码差异审阅、工具权限与独立工作目录。
- 可完成的工作
- 修复小缺陷、补写开发说明、比较重构方案。
- 如何开始
- 打开代码项目并配置模型，在单独任务中说明问题和验收标准。
- 使用条件
- 需开发工具与项目依赖；模型、外部工具和可选服务的费用另行核对。
可以完成哪些工作
按你的目标查看准备资料、操作方法和交付结果。
修复一个可复现缺陷可审阅的修复修改与测试记录。
适合：应用开发者
- 准备什么
- 复现步骤、报错、预期行为与相关测试命令。
- 怎么完成
- 新建任务定位问题，先确认原因再做最小修改，运行对应测试并逐行查看差异。
- 完成后得到什么
- 可审阅的修复修改与测试记录。
- 交付前检查
- 检查相邻行为和边界输入，模型声称修好不能替代复现验证。
补齐项目上手说明与项目现状对应的开发说明。
适合：维护者与技术写作者
- 准备什么
- 现有说明、安装流程和允许查看的配置示例。
- 怎么完成
- 让任务根据代码整理依赖、启动与测试步骤，实际验证关键命令后补入文档，未知条件单独标出。
- 完成后得到什么
- 与项目现状对应的开发说明。
- 交付前检查
- 不要把密钥或本机路径写入公开文档；未经运行的命令须注明。
比较两种重构方案两份候选修改及选择理由。
适合：负责模块维护的工程师
- 准备什么
- 同一模块、约束、基准测试与验收目标。
- 怎么完成
- 为两种方案建立独立任务和工作目录，保持相同输入与测试，比较差异、可维护性和运行结果。
- 完成后得到什么
- 两份候选修改及选择理由。
- 交付前检查
- 确认比较基于同一版本，选定后审查合并冲突，不能直接覆盖已有工作。
如何使用 AiderDesk
- 确认项目现状
检查未保存修改与依赖，明确允许改动的目录。
- 准备模型和工具权限
配置模型及必要工具，选择适合当前风险的审批规则。
- 让任务保持具体
给出复现方法、预期结果和测试命令，及时纠正无关改动。
- 审查后再合并
核对文件差异和测试结果，确认候选内容后按项目流程合并。
界面与操作参考
开始前需要了解
代码仍需人工审查
生成内容可能误解业务、依赖或边界条件，测试覆盖也可能不足。
工作目录隔离需要正确配置
worktree有助于区分文件修改，但不能自动隔离数据库或外部服务。
更多智能体可能增加消耗
重复上下文、并行尝试与工具调用都会影响费用和维护负担。
账号权限、费用与可用功能请以官方入口的当前说明为准。重要结果应先检查，再用于实际工作。
常见问题
它和命令行 Aider 完全一样吗？
AiderDesk有自己的桌面任务与扩展能力，使用时以本项目文档为准。
不懂代码能放心接受修改吗？
应由能理解项目的人核查差异、运行测试并确认业务行为。
保存到本地就不发送代码了吗？
本地工作记录与模型请求不同，云模型仍可能接收选入上下文的代码。
测试通过会自动发布吗？
测试、合并和发布各有条件，应按自己的项目流程分别执行与验收。
从开源与本地工具角度评估AiderDesk
把开源与本地工具需要的条件列清楚，再比较工具。阅读本页的产品用途、步骤与限制，再逐项确认下面的问题；这些是选型方法，不表示每款工具都具备同样能力。
本地运行到哪一步
区分本地界面、本地处理和外部API；不能只看名称判断数据去向。
环境是否匹配
检查系统、内存、磁盘和依赖，按官方要求判断能否运行。
后续是否可维护
确认许可证、配置保存、数据导出与版本更新方法。
选择一个小样任务，先检查结果与交付格式，再决定是否用于更多资料。
