1.渐进加载的思路下，啥也不用删除。基于现有的cc 扩展数据检索分析相关的技能和tool，比如Pattern搜索。 2.这就跟响亮的图一样，香很香，但维护很麻烦。 可以挂hook，在代码合并前自动检查更新。但这样又会快速膨胀。不更新，项目迭代这么快，可能很快就落后了。就得靠人盯着维护，但人已经放手许愿了，根本看不住。 长期来看就有点坑。 path 匹配rule 也可，这个路径匹配并非最好的加载时机判断。 使用技能来动态加载倒是能做，但会被压缩，变得不可控，依旧不是一个好的解法。 目前这块的设计其实是代升级的。 3.令人生厌，却又合情合理。 既不想放过别人来给他做扩展，做应用的规模化，又担心别人抄它老底，脱离他。 其实agent sdk是可以围绕cc来构建agent的。虽然cc闭源，但为了它的生态和优秀的产品力，又不得不低头。但这等于给自己的agent 埋下了未知的隐患。 作为编程agent 实至名归的 no.1，无可厚非。 对抗方式只能开源了，但开源只是手段，让更多人参与进来，快速去追赶cc的手段。 结果还是得看能不能追的上。 事实上，现在开发的能力绝对得结合ai一起算。 有没有无限opus 额度？ 能不能用cc，差距可真是大了天。 即便开源的项目能追赶上，那也是有无限opus额度加精通cc的人来贡献力量快一点。 但问题是，这些人又为何要来贡献力量呢。创造力点满，好多事可以去尝试，为何要去贡献开源代码（更别说还得花时间了解新工具做啥样）。这个时代，开发一个啥出来不难，验证有效才是最花时间和金钱的。这里面利害关系有微妙的变化。 今天刚在跟同事说，要从原本写代码的确定性思维跳出来。 围绕模型的设计就是一个概率性的设计，不是你写好1 2 3它就一定这么做，特别是长上下文的时候。 老板们总要确定性的方案。 但这是一个大量实践，下功夫观察理解，持续学习，频道变化的时代。都是摸石头过河，就算头部这几家，也没人能完全了解自己的模型，知道这个马鞍该往什么方向发展。 无非是想到啥，实现下，测测效果，敏捷迭代罢了。 Ds 和 gemini 可能上不了桌。 就编程领域，现在就 gpt claude 做对桌。 Opencode cursor 这些，没得自己的模型。等于脑子是别人的，各种协议字段，模型能力都没得控制力。很难深入玩出花来。得等着上游支持，这已经差去老远了。 除非有一套标准体系出来。