00 AI编程风起

ChatGPT刚出来的时候，大家都被震惊了，感觉自己要被AI替代了，大家都疯狂地研究怎么写提示词，怎么用AI来提高效率。我也不例外，开始和ChatGPT聊天，贪婪地学着新的知识。和ChatGPT聊代码，然后把代码复制到自己的项目里面去改改再用，乐此不疲。与此同时，我对于那会儿的提示词工程嗤之以鼻，觉得那简直是玄学，一点都不科学。为什么这个提示词会生效，没有一个科学的解释。此外，因为后来发现出来了cached token，导致调试提示词非常麻烦。所以，我一直没有深入研究提示词工程。

后来的时候，Claude Code 和Cursor出来了。公司政策还很紧，不允许用Cursor，直到去年合同谈下来，放开了，我才开始用Cursor。我尝试了一下，发现真香！当然，那个时候的模型也不够强大，基本上就是非常强大的自动补全工具。从VS Code迁移到Cursor，自己同时还可以一边Vibe Coding，一边Review代码，做一个合格的数据“打标员”。

01 Claude Code

等到公司可以用Claude Code的时候，已经是2026年了。习惯了Cursor的我，慢慢也习惯了Claude Code的命令行模式，以至于自己连代码都懒得Review了。模式编程了在命令行里面，先执行/plan，然后再看看Plan，就放手让它自己写了。最后看看PR，同时触发Claude Code Review，自己测一把，完事了。我不再执着于手把手告诉它给我用什么方法实现某个函数，而是把一小块功能给它，让它直接完成。当然，这个时候模型能力大幅提升是主要原因。

02 困顿

但是，我还觉得不够，我又看了Everything Claude Code 和 Superpowers。 ECC应该还是Claude Code Agent时代的产物，Superpowers也有很强烈的Agent的痕迹，但Skill出来之后，大家纷纷开始转向Skill一把梭。我尝试了Superpowers之后，嗯，不错，就是，太慢太费token了。它是一个完整的软件开发流程，从需求分析、开发方案、编码、测试、提交，基本都涵盖了。但是，问题也来了，一个200K的session，它活生生地吃完。上下文就是生命，上下文撑爆的结果就是虎头蛇尾，AI草草收场，写得乱七八糟的。

03 1M上下文

Claude Code 1M上下文的发布，让大家看到了希望。但是，作为业界的标杆，Claude Code这个概念还没有活太长就自己胎死腹中了。原因在于，当上下文很大的时候，错误也会累加。问题不是上下文越大越好，而在于在有限的上下文里面，确保AI在正确地干活。

04 SubAgent

Claude Code有SubAgent，Skill也支持context: fork就以SubAgent的方式启动子任务。但这些都只是杯水车薪，上下文在Superpowers的加持下依旧捉襟见肘。

05 Harness

为什么我执着于Harness，一是上面的软件开发流程基本是固定的，而且有了PlayWright这样的工具之后，AI直到自己的测试结果，形成一个闭环，确保开发的东西是符合需求没有bug的。二是流程上的闭环，比如测试发现问题是会去找BA确认是否是bug，还是说需求分析的时候漏掉了东西。

基于上面两个场景，上下文都非常珍贵，无论SubAgent，还是Skill，都最好各自上下文不要超。所以，我理想中的开发流程是，主session只管协调，然后调起SubAgent干活（保证主session上下文不超），然后把结果返回给主session，主session再调起SubAgent干活，如此循环，直到完成所有任务。此外，由于SubAgent还可以互相调用（QA找BA确认需求环节），所以SubAgent还需要记住自己之前做了什么，而不是每次都是新的上下文。

06 Agent Teams

Claude Code有时候就是研究一出，就赶紧发布了。AI大环境下，大家都急着出东西，但很多东西其实并没有研究透彻。Agent Teams可以解决上面的问题，而且还增加了Agent与Agent间的调用，但token剧烈燃烧。Claude Code也说了，这个东西主要是用来并行任务推进，或者脑暴上。理论上，可以解决我需要的Session Stick SubAgent。但还需要测试测试。

07 Coordinate Mode

Claude Code这部分还在开发，据上次泄露的代码来看，这部分还没有完善。基本思路就是一个协调者，然后派发和协调多个SubAgent。和Agent Teams很相似，但多了一个协调者。我觉得等这个出来，协调者可以作为一个Skill，其余的都是SubAgent干活，也可以解决我上面的两个场景。