近一年来，自己都在用Cursor和Claude Code写代码，最近又在用Superpowers尝试一把梭哈。最近读了一篇关于AI编程的文章Jsse: A JavaScript Engine Built by an Agent的时候，突然发现里面的Lesson learned和自己平时的碎片化的思考不谋而合。

计划比代码重要

不是说代码不重要，而是说在AI编程的时代，计划比代码更重要。因为AI可以很快地写出代码，但是做出来的东西却不一定符合预期。所以需要有清晰的计划，才能写出符合预期的代码。我之前用Superpowers的时候，就发现如果我直接无脑批准它出的计划，那么多半会翻车。所以，对于Spec和Plan，一定要自己过一遍，确保没有问题。想要放手一博，可能是自己没脑子了。

此外，好的架构师在一开始的时候就开始技术选型了，比如是否需要微服务，是否需要数据库，是否需要缓存等等。这些都是需要在一开始就想清楚的。一般情况下，AI喜欢Flask一把梭，但我个人更喜欢Fastapi，就需要在早期就明确下来，否则后期改起来就麻烦了。

Feedback很重要

学习自动化的时候，教过一个词，叫做”闭环“。就是说，一定要让AI自己自己写的代码有没有问题，要不停给它反馈，直到它自己写出符合预期的代码。我之前用Cursor的时候，基本是守着它写代码，而且从plan和代码，我都全程守着，命令也是简单的指令式，它基本就是一个初级的刚毕业的大学生，效果很不错。但在用Claude Code的时候，因为没有了IDE，我要Review Plan和代码都非常不方便，这个时候，就需要老老实实地Review Spec和Plan，然后搭建反馈（比如TDD），这样才能闭环。这种情况下，才可以不需要IDE，也可以放手一博。

然而，我们常常遇到的问题是，需求是模糊的，而且很多东西不是QA和开发Review就能发现问题的，而是等东西做出来之后，用着用着才会发现，这个东西并不能解决我的问题，或者这样做会引来其他的问题。在开发团队里面，这个东西会通过团队之间的沟通来解决的，但是这些东西是没有记录下来的，AI也没有办法从这个过程中得到反馈。

上下文爆炸

当上下文超过模型上限的时候，AI就开始快快收尾，很多东西其实都没有做完。一旦CC开始压缩上下文，就会导致细节丢失，忘记自己要干什么了。所以，最好的方案还是，计划好，拆分好，然后丢给多个Agent自己去处理。

静态语言可能是一个好的选择

虽然我很讨厌Java，因为修改一次，他都要编译很久才可以看到效果。但一旦哪里写得有问题，IDE就会语法高亮，提示错误。这个就契合上面的Feedback，AI知道自己写错了，会去修改。所以，Golang和Rust可能会是更好的选择，这也是为啥Python和Typescript都引入了类型，减少思维负担。

另外一篇文章Harness Design Essay，则从历史演进的角度，介绍了近几年AI发展的历程。

2023 年，提示词工程师

B站上还有很多提示词工程的视频，比如教深度学习的吴恩达都跑出来教大家怎么写提示词。但那会儿自己非常抵触这个东西，觉得这个就像玄学，一点都不科学。为什么这个提示词会生效，没有一个科学的解释。此外，因为后来发现出来了cached token，导致调试提示词非常麻烦。

直到这篇文章给的解释，我才豁然开朗。 ”在训练数据中，高质量的输出几乎总是与结构化的上下文共现。“ 也就是说，如果你的提示词告诉他是一个”专家“，这就把AI预测的下一个词往”专家“的概率区间驱赶，进而提高了输出质量。

2024 年，Reasoning 思考模型

但是随着Reasoning模式的出现，模型自己会给自己结构化的提示词，使得提示词工程变得不那么重要了，甚至让模型没法找到最优解。曾经有用的”专家“提示词，现在反而会限制模型的思考。曾经要求的few shot的提示词，也变得不那么重要了。

模型还更加倾向于肯定之前的输出，表示目前挺好的，除非你明确地告诉他哪里有问题，否则他很难自己发现问题。这个就是顺从引力井，这个Anthropic也发现了这个现象，见 Harness Design for Long-Running Apps。

2025年，Agent 编程

随着Claude Code等Agent 编程的出现，AI编程进入了一个新阶段。比如许多公司都开始使用Cursor，Claude Code等等。

2026年，Harness 编程

随着Anthropic 提出的Harness 编程，2026年又开始了构建完整闭环的编程，从需求，计划，编码，测试，反馈。从上面的分析，我们知道这个闭环不是完整的，但是在有限的范围内，我们可以实现从需求需要人Review，剩下的都交给AI来做。当然，最后还是需要人去用，再来反馈哪里还有问题，如此迭代。