是的，这就是我说的增加用户学习成本，很多人根本不会点开官方配置网页，开箱即用得顺利不顺利就直接导致他弃坑
我觉得这个避免不了，做这些包装我怀疑既增加代码复杂度和维护成本，也没有降低用户使用成本，毕竟配置api key 不也得看文档去么。
嗯，我同意现在的architect mode方式真的增加了不少维护成本和代码复杂度，主要aider上游是这个功能支持得还非常烂。
其他对于model的常规设置，应该还行吧？没几行字一个run函数解决的问题
你要担心这个，不如学学 gptel 多一些配置文档
我觉得没必要把这些都包装了，做了这些封装，其实对于我来说还得先检查一下命令行里多了啥 
gptel的readme真的是极端丰富了哈哈哈
我挺喜欢你这个方案，你有空写PR吗？不然我明天来搞
这个也好，就是不适配目前dynamic model selection的函数，需要改一下
哈哈哈，所以对于intuitiveness和usability的理解真的太主观了，你对aider doc很了解，所以会好奇心驱使你去研究一下有了什么改动；我从完全不了解aider的新用户角度去推测，我想他们应该更关心能不能开箱即用，用熟悉的emacs setq配置好就能直接跑了，所以我才觉得更省事
你们的feedback都很好，我目前的方案确实有over engineer或over abstraction的风险，我把我的观点想法已经说完了，得睡了，你们继续讨论，直接上PR就更好了 
这还有个问题得考虑清楚，我现在的实现是可以toggle的，因为reason+edit双模型会比较贵，会有时候用一半想换。
还有就是，Aider目前好像不支持这种程度的runtime切换（或者我漏掉了什么doc）目前切换必须重启整个aider进程…
现在好像不行，只能切换单个
嗯，我关注一下这个issue，暂时只能这样dirty workaround了
我刚刚对 Architect/Editor 模式进行了优化，现在 aidermacs-editor-model 默认会使用 aidermacs-default-model 的值，而不是单独设置。这样配置更简洁直观：
(setq aidermacs-use-architect-mode t)
(setq aidermacs-architect-model "o1-mini") ; 只需要设置 Architect 模型
;; aidermacs-editor-model 默认使用 aidermacs-default-model
这个改动的好处是：
- 减少了需要配置的变量，更符合直觉
- 用户只需要关心要额外引入的 Architect 模型
- 保持与默认模型的兼容性
- 当用户切换回 solo 模式时，配置可以无缝衔接
Aidermacs 最新版本 已经支持自动检测 .aider.conf.yml 配置文件 ，搜索顺序如下：
~/.aider.conf.yml(aidermacs-project-root)default-directory
当 .aider.conf.yml 存在时，Aidermacs 会忽略所有其他配置变量 （不仅仅是 --model）。所有配置都由 .aider.conf.yml 直接接管，这意味着不需要再手动设置 aidermacs-default-model、aidermacs-architect-model，--model、--architect 之类的参数
可以通过配置文件注明config-file位置：
(setq aidermacs-config-file "/path/to/your/project/.aider.conf.yml")
或者：
(setq aidermacs-extra-args '("--config" "/path/to/your/project/.aider.conf.yml"))
@vinurs 建议更新后试试！
1 个赞
更新后试了一下，可以了，谢谢^_^
1 个赞