在前文中，我们曾提到过， BFE 比同量级的项目要花了多得多的 token ，这固然有第一次 vibe 不太有方法论和策略，整体规划做的不太好和 token 是免费的用起来不心疼的原因，但就算将上述原因全部纳入考虑，如此庞大的 token 消耗数依旧是不太正常的。所以，我猜测， BFE 中可能有部分需求触及到了 agent 能力的边界。目前我想到最有可能的就是，对十个主题的适配。这需要 agent 从网上下载十个主题的源码，浏览并学会如何使用之后，再用正确的脚本将用户的配置填入到主题中。事实上，这是我理想中 agent 应该干的事，但是 agent 似乎在搜索这方面偷了懒，十个主题有些一次就能过，有些就不行。有些配置有的主题支持，有的不支持， agent 也未识别出来。

但，将这个可能性列出来之后，我发现这似乎并不是 agent 能力的边界，而是由于前面提过的原因，导致 agent 在我的使用下，发挥不出全部的能力。“我”降低了 agent 的能力边界。这很正常，事实上大部分人使用 agent 都会这样，只是有些明显有些不明显。不过我在这里想讨论的并不是这个问题，相关的反思在前文中也已详细的叙述过。至于反思的到不到位，有没有效，都要经过下次 vibe 的检验。

我想探讨的是，如何通过对需求的设计和转化，将其变为哪怕 agent 在被人降低能力边界的情况下，依旧能够很好的胜任。具体到这个项目，我想的是，能不能让 agent 重写这十个主题，使他们都符合某种设计好的格式，这样就不用后续做适配，相当于将适配提前。这里显然的缺点是， agent重写的主题不一定和原本的主题相一致，看上去也增加了工作量和整个项目的风险与不稳定性。

好处也是显而易见的，首先，假设使用同样多 token 的情况下，我觉得 agent 能在重写任务完成的不错的前提下，提升整个项目的可靠性（上文提到的风险是由于重写可能不成功导致项目失败，这里的可靠性是指， agent 一旦重写成功，后续功能的构建将有极大可能成功）。重写这十个主题对于 agent 完成这个项目来说，并不会比上面那样提到的去做更难，相当于将一个难完成的需求，通过增加工作量，变成一个易完成的需求，并提高成功的概率和整个项目的可靠性。还有第二个好处，是我们可以将重写主题的格式开源，从而来构建起一套新的主题生态，增加用户对项目的黏性。虽然这个在 BFE 上不太可能看到（毕竟只是一个不成熟的小玩具），但是思想非常值得学习。我们能在很多地方看到这种类似思想的使用，构建一套自己的标准，然后强兼别人的标准。

至于工作量的增加，似乎也是一个伪命题。我就是一个很好的例子，毕竟我用看似更简单的方式去构建这个项目，但 token 数花的出奇的多。或许换成上面重写的思路，还不需要花这么多 token ，这种情况下，工作量的多少还真不好说。

如果以后真的有人使用这个项目，或许我会考虑将项目迭代成重写主题的这种形式。如果没有就不折腾了。

至于如何设计和转化需求，就是各位天才程序员目前的价值所在了。对此我也还在探索之中，并没有很多想法。但是可以将我对本文中思路的重思考分享一下。在正式开始项目之前，我其实未必想不到这个思路，但是，由于它可以预见的工作量，在还没开始之前，就被我不带任何其他思考的否决掉了。这么做放在 agent 出现以前，当然是合理的，可以让项目仅用很少的工作，就达到落地的效果。这对于项目后续的开发和开发者在这个项目上的收获都是很重要的。更别提重写主题是一个带有很大不确定性的活，比起这个，人类开发者肯定更擅长也更喜欢去一个一个主题的做适配。但是，大人，时代变了。在 agent 出来之后，二者在工作量上的差异在好的使用者手中被无限缩小， agent 的能力也让了重写的成功性大大提高。我们以前可能更倾向于敏捷开发，让产品能很快有一个能给用户使用的版本，而放弃掉一些锦上添花的功能，甚至放弃一些明显有无可替代优势的方案。但在 agent 的时代，不妨给这些功能和方案一个机会。当我们迈一小步和一大步所需要的努力差不多的时候，我觉得后者会是更好的选择。

agent 的冲击不止在技术的使用上，更在想法上。