tninja
2025 年2 月 13 日 02:16
128
据我所知, aider CLI本身并不直接带有这样的考虑, 得自己拷贝粘贴过去, 像去问chatgpt问题一样.
aider.el的一个基本考虑是希望结合emacs lisp的编程能力把buffer里用户关心的context作为prompt的一部分发给aider, 减轻用户操作的负担. 有好几个命令都是考虑 当前函数, 或者选中代码的, 比如
询问问题:
aider-ask-question: 在当前上下文中向Aider询问有关代码的问题。如果选择了一个区域，使用区域作为上下文。如果没有选定区域, 光标在某个函数里, 那么它会问关于那个函数的问题
修改代码
aider-function-or-region-refactor：如果选择了一个区域，辅助重构或者修改所选区域。否则，重构或者修改光标下所在函数
多行注释的in-place新代码生成
aider-implement-todo: 如果有多行注释的选择区域，要求在那个位置实现这些注释中描述需求的代码
单元测试相关功能
这些功能我自己都在用, 好使的. 它们也都在菜单里
这只是我有限的经验总结的想法 请大家多多提意见 谢谢
为了实现发送多行代码块到aider session的效果, 我的选择是在代码块前后加上{aider … aider} tag. 不然的话aider会把它们当成多行命令, 一行一行逐一执行. 这个实现比较安全, 目前还没翻车. 不过, 可能和有些同学交流的时候, 没太说清楚, 让他误会了.
你描述的很清楚，我没有误会。我理解你的想法，但不理解你的实现具体“安全”在哪里，更不理解我们之前的PR具体“不安全”在哪里。
但没关系，我们想法不同，你继续你的Aider.el，我继续我的Aidermacs。Aidermacs 在昨天和今天两天时间已经加入了非常多的新功能：
vterm和comint双选择
aidermacs--current-output 彻底打通Emacs与aider输入输出通道M-x aidermacs-list-added-files 添加文件 和 M-x aidermacs-drop-file 移除文件
重新整理 transient 菜单，引入了二级菜单，强烈提升用户体验
详情可以看：GitHub - MatthewZMD/aidermacs: AI Pair Programming in Emacs
tninja
2025 年2 月 13 日 02:45
130
同学, 我好心劝一句, 如果是上班拿工资的人, 白天该上班好好上班. 现在这个经济形势下, 大家好好把饭碗捧牢是正事. 当然这不是我该管的事情. 之前沟通上有些摩擦, 你现在也还生气, 我也有一定责任. 那个时候我这也该睡觉啦. 第二天还要上班呢.
感谢提醒，最近在休假，不用担心我的工作，况且这几个功能虽然花些时间，又没有什么难的，写写还挺有意思。
tninja
2025 年2 月 13 日 03:07
132
我就是不想直接拒绝而已 公开吵架 太难看 有些code我不想merge 同意了以后 不管我自己熟悉不熟悉 将来就要维护它 我只是量力而行
当然 只是我个人的判断 对于这样古老的编辑器 如果有 品行好 有才华的年轻人 愿意贡献自己的时间帮助做emacs 相关的事情 对于这个community 而言 也是好事情 因为之前很多人都担心现在年轻人不再使用emacs
1 个赞
这又回到这一整个月包括昨天和今天都重复不下几十遍的事了，你觉得不够stable却又拿不出合理理由，什么都是你觉得，都是你的判断……这当然可以，毕竟是你的项目。但开源软件的协作和你公司里的传统工作模式可能会有些区别，你可能不够了解社区模式，也不够了解elisp。
总之我们的分歧在我Fork之后就没有任何意义了，这个话题到此为止，之后我不会再回复关于之前PR/我们分歧方面的任何内容。一切交给用户自己去判断吧。
当然，关于Aider和Aider.el或Aidermacs的功能，欢迎一起聊，毕竟Emacs社区没几个人集成Aider了。
另外，如果你的Aider.el要是实现了什么新功能，欢迎来我的帖子 宣传，好的功能大家一起用才是好事。
3 个赞
那基本就是我想的功能。
比如我针对一个函数问了一个问题或让aider重构修改。它会不会自己去找函数相关的函数？这个需要aider.el来告诉它，还是它自己作？
tninja
2025 年2 月 14 日 02:22
135
希望这些功能对你有用。就是因为有和你类似的需求，意外的发现aider可以识别代码文件里的语法单元比如函数，正好elisp可以识别光标下的语法单元，才这么做的。
如果是想解释代码，并且依赖的函数也在这个文件里，或者在已经加的其他文件里，我几个月前试过，可以用ask让它recursive的解释函数，比如，please recursively explain xx function。甚至还可以让它画dependency ascii chart. 具体效果好坏好像也看用哪个模型。现在想来模型已经更聪明了吧。
aider.el没有针对递归解释代码的要求做一个函数。虽然尝试这件事的时候很兴奋，实际上我并没有用很多次，因此也不值得占一个宝贵的菜单项。不过，如果你愿意用helm的话，可以尝试也加载aider-helm.el。它的作用是把以前用过的prompt存下来，按照使用频率排序。所以如果第一次你输入这样的要求prompt, 下次helm的模糊匹配就会起作用，敲很少的字就能找到以前用过的这个prompt。这也有点接近菜单项了
复杂的重构修改，我觉得要小心, 不要高估AI的智商。prompt越具体越好。尽量多提供有用的信息给aider，和非常具体要做什么事情的指示。即便如此，也要小心检查产生的结果，所以这个功能我用的/architect. 它会提供change供用户审核，同意了再make change，代价是多花一点token也就是钱。recursive修改的话，最好说清楚目的，和具体要改哪些函数，怎么改。当然，更安全一点的是，逐步让它做小的修改，并且经常运行单元测试。
# Aider Prompt File - Command Reference:
# C-c C-n: Send current line or selected region line by line
# C-c C-r: Send current block or selected region as a whole
# C-c C-z: Switch to aider buffer
可以分享一些用例，解释怎么用 Aider Prompt File 吗？
C-c C-n 是发送当前行，或者把 region 的内容发送过去。
C-c C-r 是发送 block，在 org mode 里，一个 block 对应的似乎就是一个段落。
它也可以发送 region，和 line by line 不同的是它会把内容包裹在 {aider} 中。
感觉两个功能很相近，想知道，一般什么时候会用 line-by-line 什么时候会用 block ?
如果都差不多是不是可以合并？感觉绑定在 C-c C-c 更好理解，因为 org mode 中执行 src block ，magit 中提交 commit 都是这个绑定键，比较容易按也容易记忆。
另外，选择 region 再发送感觉有点麻烦，如果可以直接把 heading 下的内容直接发送感觉更方便，这样我就可以用 heading 来描述我的动作，在它下面写相关指令和上下文。
感觉会更容易组织 prompt 记录。
不过自己选择 region 就相对更灵活和精确一些吧，需要什么自己选就是了。
tninja
2025 年2 月 17 日 05:28
138
完全同意 能完成工作 需要记忆的命令函数越少越好
C-c C-n是发送单行 在没有选中区域的时候 按这个按键有点像单步调试 这样也比较小心
这个功能可以选择区域执行 有时候某个具体task里涉及到多个文件需要add或者readonly 在prompt文件里就形成了好几行 对应好几个prompt 第二天过来继续工作的时候 选中这几条prompt C-c C-n 会一条条line by line发过去 这个不是multi-line prompt 发过去的时候 也不会在头尾加tag
C-c C-r是发送multi-line single prompt 没有选区域的时候 它会根据光标位置寻找周围的连续code block发过去 block就是连续的行 之间没有空行 用这个命令是认为光标下的多行只是一个prompt 因此前后会加tag 这个功能我在用rss写R的时候 或者scala-mode写spark的时候很省事 不需要选择区域的
在选择了区域以后 它就发选择区域过去 前后也会加tag
我本来希望第二个功能bind to C-c C-c 和ess一样 但是or mode已经占用了 所以就改用了C-c C-r 如果有办法改 我也想改成C-c C-c
如果不需要line by line 多prompt发送 这两个确实可以合成一个的
这个讨论也说明上面截图里面注释里的描述没有讲清楚
你说的有道理 我再想想怎么样再简单一点
是不是可以借鉴一下 embark 的思路，它会识别当前指针下面是什么，执行对应的操作。
获许可以在 aider-minor-mode 下稍微调整一下 C-c C-c 的逻辑，基于 pointer 的位置：
如果是单行或者段落，执行 block 的逻辑，发送一个 block 过去，只有一行的 block 就和 line by line 没区别。
如果是在 heading 上，则可以发送 heading 里的内容，整体发送过去
如果是 region，则发送 region
他们都可以用 {aider} 包裹，反正包了也不影响。
这样一个按键就能实现很多事情了，容易操作，也容易记忆。
tninja
2025 年2 月 17 日 05:47
141
考虑光标下是不是个aider prompt block再决定是否call 这个函数 还是org mode 已经有的功能 可能可行 这样就还能继续用C-c C-c了 我可以去看看怎么弄
多行prompt 包在aider tag里好像不按多个prompt处理 回头我可以再核实一下
现在单行的用第二个函数 和第一个 效果应该一样的 就是多了个tag block
我没明白你说的heading是什么意思 是org的标题么？ 能麻烦举个例子吗
对，就是 heading 就是说的标题。
例如你的多行场景，可以放在 heading 下，直接执行 heading 完成，类似 line-by-line，省去了选择 region 的动作。
我觉得也不用强求都在一个命令里，对于 line by line 多行这种场景，可以保留一个快捷键去完成？
然后剩下的大部分都能用 C-c C-c 完成，这样就挺方便的。
tninja
2025 年2 月 17 日 07:44
143
确实不是两个都经常用 不过 我自己用的感觉是 大部分情况下单行prompt 够用了 很少需要用到复杂的多行prompt
不过有时候copy paste例子什么的进prompt 作为context帮助大模型理解 需要multiline prompt
Aider prompt org file现在仅仅是加了上面两个eval函数 具体怎么用好 可能还得再想想 虽然是prompt文件 但是里面也可能有prompt以外的内容 比如说描述如何解决某个task或者子task的思考 或者描述prompt做得怎么样 下一步怎么改进 这样回头看的时候 有具体的文字描述 这些内容不属于prompt 也不需要发给aider
另外单独给add文件开个标题 觉得标题有点太细了 我现在还是更习惯用标题描述具体任务
tninja
2025 年3 月 3 日 05:30
144
最近aider.el 的一些改动
aider.el的基本假设之一就是aider的力量来自于用什么prompt. 而prompt是有可重复性的. 可以应用相同或者稍作修改的prompt来应用到不同的项目,类似的任务. 好的prompt可以反复使用,不需要每次手工输入,CLI在这点上做得不够.这里有优化的空间.
优化的方式基于
基于helm输入prompt (建议使用aider-helm.el) 这在诸多code change / discussion菜单项当中使用. helm的输入支持模糊匹配,所以可以比较容易的从以前自己输入的prompt里找到可以重复使用或者稍微改改就能用的prompt
最近的修改提高了prompt可重用性: 仅仅保存修改指令进history, 不保存context部分比如改哪个函数.
aider prompt file ~C-c a p~. 这个方式把prompt输入从aider session挪到的单独的aider prompt (org) file. 通过类似发送代码块的方式来和aider session交互. 这样容易管理项目, 以前同一repo的prompt也在同一文件里, 容易重用和修改. 另外发现copilot.el在aider prompt file里也很有帮助,因为copilot.el不但补全代码很好,补全prompt英文也很有用.
最近的修改引入了yasnippets 支持 (感谢之前一位网友提到yasnippets,才想到可以这么用), 这样用户可以容易重用网络上认为比较好的coding prompt库,来应用到自己的项目上. 目前加了reddit上两个比较高分的prompt list. 欢迎大家根据自己的经验加其他的,或者改进现有的prompt snippet.
其他的用户端改动:
- 菜单: 简化菜单以适应屏幕并减少记忆: 感谢 Spike-Leung的建议和review
将操作分组到同一菜单项中。不常用的操作绑定到 C-u
开发者端改动:
弃用 aider-minor-mode，改用 aider-prompt-mode (major-mode)
aider-prompt-mode 继承自 org-mode. 这样定义键位比minor-mode更容易控制
对 aider.el 进行重构，原先有接近1000行. 将其分解为几个小文件，以帮助未来的开发和维护
aider-core.el: 核心 comint aider 会话交互功能
aider-file.el: 文件操作相关的功能
aider-code-change.el: 代码更改相关的功能
依赖于 aider-core.el 和 aider-file.el
aider-discussion.el: 讨论相关的功能
依赖于 aider-core.el 和 aider-file.el
aider-prompt-mode.el: aider 提示文件的主模式
aider.el: aider 会话管理和菜单
有用户提出希望有类似cursor的code review / accept功能, 回复了aider中对应怎么review / accept code change, 也许这里也有网友会有相同的问题. 详细回答在Feature Request or Doubt: accept code changes · Issue #98 · tninja/aider.el · GitHub
PS: 做这个插件的过程中,体会到虽然AI编码很快,但是想法和思路是根据使用经验和大家的反馈慢慢发展的. 这些都需要程序员的参与. 所以对于网络上或者某些名人宣称AI将来取代程序员, 我不信.
5 个赞
通过 melpa 安装 aider 会自动安装 helm 依赖。（因为 aider.el 里的 package-requires 注释声明了需要 helm，所以 helm 会被自动安装）。
这个是否不太合理呢？大部分的用户应该使用的是 ivy+counsel 或者 vertico+consult，仅仅是为了使用 aider 就要安装 helm 似乎不太合理。
两个思路：
aider-helm 作为一个 单独的 package 发布，不再随 aider.el 一起发布
aider.el 里不再将 helm 作为 package-require。当然因为 helm 不再是 dependency，因此 byte-compile 可能会出现问题，因此需要把所有调用的 helm 变量和函数都用 defvar 和 decalre-function 声明。
1 个赞
tninja
2025 年3 月 17 日 00:23
147
非常感谢反馈和建议 应该不需要安装helm比较合理 第二条建议很好用 已经改了 谢谢
2 个赞