Pi 仓库出现 Harness-v2 草案

意义不大,

1. 
   

   一来生态小(目前来看将会长期生态小, 没有太多资源投入, 也没有稳定的盈利模式. 反例: 比如巨硬支持的VS Code; 与 *nix 系统捆绑有大量的开源开发者投入精力的 Vim), 插件质量普遍不高, 而且插件系统大而全(大忌: 无法组合)

   
   


2. 
   

   二来在AI时代, 软件的分发和扩展不仅仅可以通过插件系统, 还可以通过直接二开源码, 让模型来处理上下游合并冲突, 重复功能删减, 冗余文件移除, 功能新增等, 远远比基于扩展系统灵活的多(扩展系统对外暴漏的接口, 怎么可能有直接改源码舒爽呢), 配合如下 git 配置, 简直不要太好用…最符合自己的 cli agent 很快就可以随着使用不断完善…

   
   

   git config rerere.enabled true                                                                                                           
   
   git config rerere.autoupdate true                                                                                                        
   
   git config merge.conflictStyle zdiff3                                                                                                    
   
   git config fetch.prune true                                                                                                              
   
   git config remote.pushDefault origin                                                                                                     
   
   git config branch.main.remote origin                                                                                                     
   
   git config branch.main.merge refs/heads/main 
   
   

   
   

注意:

1. 插件系统有用, 且可以和上述二开流程配套使用(但插件系统是可选的, 因为 cli agent 组合能力的功能模块是 Skills 和 MCP Tools 等, 已经暴漏给用户 → 这才是 AI 时代真正的解耦方式)

2. AI 时代软件的分发, 我坚信一定会在黑盒三方依赖(比如 npm 包)之外, 再开出另外一朵类似 Tailwind CSS 的 shadcn/ui Copy 模式的分发扩展方式. 毕竟模型已经解决了这种软件分发方式最大的难点: 功能冲突, 功能重复等

之前参考过佬的 pi-rewind，Shadow Git 仓库的想法很优雅

我现在就是直接二开 Pi 然后把自己写的扩展放在 src/extensions/ 下（）

（某些我需要的效果 Pi Extension API 不能很好的做到，只能二开自己改源码

这样就完全不安装外部扩展了，只用把需要的功能自己实现一次然后发布新版本 Pi Fork（

是这样, pi 的扩展系统暴漏的接口不够灵活, 很多操作必须修改源码…

所以想通以后, 我目前是在 kimi code 上二开扩展最适合自己 cli agent 了

pi-rewind 一开始的想法是好的, 但是只适合中小项目, 且不适合在多 git 项目的大目录中使用…只能说是一种取舍吧…所以我已经将这个项目归档了, 没什么好改的了…