算是比较典型的依赖冲突，解决方案也就是提前拦截require了（比较本的方法，实际上如果作为插件的实现不应该这么做，不过这里是要打个猴子补丁）

大概就是这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

local data = vim.fn.stdpath('data')
local paths = {
  async_nvim = data .. '/lazy/async.nvim/lua/async.lua',
  promise = data .. '/lazy/promise-async/lua/async.lua',
}
local loaded = {}
local function load(kind)
  if not loaded[kind] then loaded[kind] = dofile(paths[kind]) end
  return loaded[kind]
end

local orig_require = _G.require
_G.require = function(modname, ...)
  if modname ~= 'async' then return orig_require(modname, ...) end

  for lvl = 2, 16 do
    local info = debug.getinfo(lvl, 'S')
    if not info then break end
    local src = info.source or ''
    if src:find('refactoring', 1, true) then return load('async_nvim') end
    if src:find('nvim-ufo', 1, true) then return load('promise') end

    if src:find('fundo', 1, true) then return load('promise') end
    if src:find('promise-async', 1, true) then return load('promise') end
  end
  return load('async_nvim')
end

保存后确保在lazy或者其他插件管理器加载之前加载这个

这些东西有时候堪称魔法一般的东，虽说在当时行编辑器的时候这些命令更像是活命的神技

通常情况下来说，ex命令大概由以下组成

1

:[range] <command> [args]

表示在range上执行具有args的命令command

关于vim中的神秘符文

vim/nvim 中很容易出现一些令人看不懂的符号，在这里的话列出一部分（混个眼熟）

关于一些范围的表示

比较常见的就是在visual模式下的两个：'‘<和'>分别代表区间的开始和结束大部分情况下，这个东西都是在visual模式下触发才注意到的

实际上，这个ex命令的范围可以是：

• 某一行：1（指定行号）,0(文件开头)，$末行，’a（某个标记，大写的话是跨文件）
• 一个范围，通常是由逗号分割开的两个指定的行号，也可以是%代指从头到尾
• 搜索的结果：由\\（向下搜索）或者??（向上搜索）指定，遵循vim拓展的正则语法（大概还是正则），具体的放到了底下说除此之外也可以使用+和-指定偏移的范围

其他的一些符号

这里列举一些可能会有用的符号（说不定哪里用上了）

• !：放开头是执行命令，如果和命令结合通常代表强制写入，作为子参数也可以说把内容传入给它然后执行，也可以对选中范围进行过滤（奇怪的知识点）
• >：重定向输入
• >>：追加重定向
• <：重定向输出后三个其实比较好理解，和bash里面用的其实差不多，很多时候是为了筛选和分离什么的（什么vim神技巧）

关于常见的ex命令

关于这些ex命令，很多都是从ed，ex这一路子传下来的，很多命令一个命令就有很多作用,通常来说这些命令的help文档相当。。。。。

Eg. Writing

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

==============================================================================
4. Writing*writing* *save-file*

Note: When the 'write' option is off, you are not able to write any file.

*:w* *:write*
*E502* *E503* *E504* *E505*
*E512* *E514* *E667* *E949*
:w[rite] [++opt]Write the whole buffer to the current file.  This is
the normal way to save changes to a file.  Fails when
'readonly' is set or when there is another reason why
the file can't be written, such as when the parent
directory doesn't exist (use |++p| to avoid that).
For ++opt see |++opt|, but only ++p, ++bin, ++nobin,
++ff and ++enc are effective.


:w[rite]! [++opt]Like ":write", but forcefully write when 'readonly' is
set or there is another reason why writing was
refused.
Note: This may change the permission and ownership of
the file and break (symbolic) links.  Add the 'W' flag
to 'cpoptions' to avoid this.

:[range]w[rite][!] [++opt]
Write the specified lines to the current file.  This
is unusual, because the file will not contain all
lines in the buffer.

*:w_f* *:write_f*
......<<省略大概100多行

基本上是一个命令有很多用法，而帮助文档需要尽可能详尽地讲清楚（但是越看越糊涂）导致的

对于这个blog的话更多是面向已经很熟悉nvim/vim的,不太可能r,w,d,i这些基础的命令也不知道，这个blog的话只讲一些奇怪神技（

执行，过滤以及外部命令（!符号）

没错，第一个讲的符号就是!符号

是一个很典型的在vim中出现二义性的符号，很多时候能写出容易让人看不懂的东西

OK，先说一下它的正常的用法：

1
2

:w!  -> 强制
:!bash ->执行命令

这两个是比较基本的，然后就是很少会有初学教程会提到的用法：

1
2
3
4
5

:[range]!<command>
eg.
:%xxd ->变为16进制视图
:%xxd -r ->变回来
:‘<,'>!xargs bash -c ->将选中的命令当作bash命令执行并且替换成指定的结果

可能不是很能被理解，实际上是运行指定的命令然后将范围内的的内容以stdin的形式发送给这个程序并且使用这个程序的stdout替换给定的范围内的命令

可能说的比较绕其实也就是：「范围内的内容」-> 「这个命令」->「粘贴回来」

再配合xargs等命令总会有点奇怪的用法（

对于w，e这些命令的参数

其实这个文档讲的比较详细不过用的比较少一点，这里直接贴出来不作过多的解释

经常用来临时覆盖一些文件的设置比如临时保存为其他的编码什么的其实这方面是很有用的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

The [++opt] argument can be used to set some options for one command, and to
specify the behavior for bad characters.  The form is: >
++{optname}
Or: >
++{optname}={value}

Where {optname} is one of:    *++ff* *++enc* *++bin* *++nobin* *++edit*
    ff     or  fileformat   overrides 'fileformat'
    enc    or  encoding    overrides 'fileencoding'
    bin    or  binary    sets 'binary'
    nobin  or  nobinary    resets 'binary'
    bad    specifies behavior for bad characters
    edit    for |:read|: keeps options as if editing a file
    p    for |:write|: creates the file's parent directory

{value} cannot contain whitespace.  It can be any valid value for the options.
Examples: >
:e ++ff=unix
This edits the same file again with 'fileformat' set to "unix". >

:w ++enc=latin1 newfile
This writes the current buffer to "newfile" in latin1 format.

The message given when writing a file will show "[converted]" when
'fileencoding' or the value specified with ++enc differs from 'encoding'.

There may be several ++opt arguments, separated by whitespace.  They must all
appear before any |+cmd| argument.

匹配

这一部分应该放到开头说的，不过这样子的开头可能有点啰嗦

这就另一个vim很有趣的东西基本上符合正则表达式的比如说常见的通配什么的

不过的话一些特殊的符号比如说是括号方括号什么的需要换成\(这样子的（否则vim默认是认为你想要搜索的是普通字符）或者直接使用very magic模式（开头加入\v）

实际上的话vim的这个虽然大体上遵循正则的模式但是其实这个东西是它自己实现的一套引擎，而不是PCRE标准（挖坑）

剪切板

这个东西的话wayland下的话提供者还是桌面环境实现的协议以及wl-clipboard提供工具来操作，其实很多时候用的剪切命令什么的（C-c；C-v） 这些都是它

这个cli东西其实同时提供了两个命令：wl-copy和wl-paste来在命令行实现剪切和粘贴（一个接受管道输入到剪切板，另一个在调用的时候输出内容），其实这个东西没有什么特别好说的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$wl-paste -h
Usage:
wl-paste [options]
Paste content from the Wayland clipboard.

Options:
-n, --no-newlineDo not append a newline character.
-l, --list-typesInstead of pasting, list the offered types.
-p, --primaryUse the "primary" clipboard.
-w, --watch commandRun a command each time the selection changes.
-t, --type mime/typeOverride the inferred MIME type for the content.
-s, --seat seat-namePick the seat to work with.
-v, --versionDisplay version info.
-h, --helpDisplay this message.
Mandatory arguments to long options are mandatory for short options too.

See wl-clipboard(1) for more details.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$wl-copy -h

Usage:
wl-copy [options] text to copy
wl-copy [options] < file-to-copy

Copy content to the Wayland clipboard.

Options:
-o, --paste-onceOnly serve one paste request and then exit.
-f, --foregroundStay in the foreground instead of forking.
-c, --clearInstead of copying, clear the clipboard.
-p, --primaryUse the "primary" clipboard.
-n, --trim-newlineDo not copy the trailing newline character.
-t, --type mime/typeOverride the inferred MIME type for the content.
    --sensitiveHint that the content is sensitive.
-s, --seat seat-namePick the seat to work with.
-v, --versionDisplay version info.
-h, --helpDisplay this message.
Mandatory arguments to long options are mandatory for short options too.

See wl-clipboard(1) for more details.

更多的自己看manpage（

PRIMARY缓冲区

这个东西的话比较冷门一些，大部分人从Windows转到Linux都不太会知道的东西（甚至我也是看了wiki才知道的）当你选中文字的时候，就会将这一段内容自动地放入这个缓冲区里，并且当你按下中键的时候就会将选中的东西粘贴进去，属于是和剪切板并行的另外一套机制，很久了，但是现在的桌面环境仍然保留它

对于操作这东西的命令其实上面的有提到（没错，还是wl-copy/paste）

剪切板管理器

看完上面的到这里可能问题其实更多了，毕竟Winsows下可能是真实感觉到剪切板这么个东西，尤其是比较新生代的可能入手win10以上都是有剪切板历史的显示的，这就会有一种『能看到剪切板』的错觉

但是实际上再往上的是没有这个东西的，很多时候是靠像是CopyQ来实现这个剪切板历史的

没错，这里提到的CopyQ，其实在Linux下也可以作为代替的剪切板历史的方案之一，除此之外还有很多其他的提供者（甚至你自己使用rofi和一个常驻的脚本也能实现），这种把剪切板里的内容显示出来的才是剪切板管理器，实际上无论是剪切板还是PRIMARY选区，这些机制其实还是桌面环境实现的（

嗯，感觉差不多说的很详细了（）也就到这里了

概述AI编码工具^[1]的使用

文化工作者一定要有文化^[2]

这方面比较值得注意到是自己也需要对做的东西有基本的认知的（如果没有你也可以让AI帮你有），经典的谬误是小白也能使用这种工具完成这方面的项目

这方面固然是现在更多工具努力的方向，但是这件事情本身存在一个盲点就是小白不可能会知道AI写出来的是什么东西，AI提出的方案也大概率不会懂，AI写出什么就是什么了而不会对AI工具产生的一些隐患产生一丝一毫的察觉

换句话说，现在的AI工具并不对它写出来的东西的质量和安全性进行担保，而生产级项目忽略这两个将会是一个巨大的灾难

其实即使AI工具担保了这些，对于小白来说很大概率因为规范和安全意识的缺失也会酿成大错，经典的死法就是密码上传github,对于这种完全阻止不了，对于教育铺开这些东西想都不用想，一眼假的诈骗网站和流氓软件还有那么多人中招甚至解压缩都不会的让它们有这种意识还不如直接教毛驴用ai工具

除此之外，AI工具也有以下几点痛点，这些东西其他大佬也都在反复提及：

• AI没有从工作中学习
• 过度编码
• 喜欢把一个文件堆成屎
• 经常把好的功能改坏
• 审美太差
• 不喜欢遵守一些项目里面已有的规范

如果你是比较喜欢抄作业的你可以先参考我的AGENTS.md(也借鉴了很多其他的项目)https://northgreen.github.io/ictye-public-note/一个自用的AGENTS.md

对于更好的编码

对于解决AI不遵守规范的事情，我个人建议是直接对AI立下规矩 这里是直接告诉AI如何提问，遇到违背事实的时候应该怎么做 最重要的是，当AI发现有不对的地方的时候，应该让它坦诚地说出来而不是隐瞒

其实相反的，对于操作者来说，如果AI有什么偏离你预定的东西或者有你不喜欢的行为也应该及时地归纳并且写入到AGENTS.md (虽说如果不勤快地整理的话就可能让整个文档看起来一团糟)

然后是对于如何约束AI写代码的事情：虽说如果不约束ai也有可能写好的代码但是ai写好的代码又不太可能

首先代码规范固然重要，这方面写一个skill然后强制AI每次编码的时候读取它就可以（这方面对于人来说，其实叫做最佳实践同样的，AI也是需要最佳时间才能写好项目的）个人的方向是

• 通用的编码规范比如oop规范和函数式规范
• 另外再加上前端规范等等总的来说就能够有很好的效果了

然后就是一些其他大佬提过的：

• 红绿测试
• 编码之前思考
• 简单至上
• 精准修改

对于更好的工作流

首先要明确的是人要把控开发方向而不是让工具去把控开发方向，即使让AI自己头脑风暴，也有很打概率并不会把一件事情做的很好（上面说的审美太差也是这个原因）

首先一定要先让AI制定计划然后经过审阅再去做（这方面借鉴了其他人的插件完成的） 或者说是一定要先对齐需求再执行

然后AI写出来的东西也应该看个大概，至少是要知道做了什么的程度

不过尽管如此，是无法阻止AI犯错的，AI犯错这件事并不是AI能力的事情而是一个工作流程的事情，要做的事情也很简单，就是让AI也使用VCS，管理自己的版本

除此之外，就是多AGENT分工，让主agent负责调度，而其他agent负责各个任务，值得注意的是，一定要用负责review的agent，就像是裁判不能是运动员一样，自己制定规则自己实施100%会导致AI自我信心爆棚而不去发现真正的问题

让AI学习

不过光有这些其实并不充足，如果AI不能够从中学习的话该有的问题永远会有

好在这方面已经有openclaw和hermes的实践，这些经验可以直接归纳到ai coding工具里

这里通过一些图记忆插件以及自己制作的一些拓展，也大概实现了这两个：

• 让AI记住发生过什么
• 让AI总结经验

大概就是提醒AI在任务完成之后，进行复盘，遇到什么坑有什么新的发现都写到记忆里，有什么更好的工作方式就归纳成skill

不过其实比较想要尽力地去做的点是如何让AI也能归纳用户画像，虽说这个还是没有做到