项目简单介绍

BFE 全称 BlogForEveryone ，是一个专为小白设计的面向 GitHub 部署的一站式博客搭建创作发布软件。这是项目的仓库，想要体验的可以直接点进这个链接，软件内有详细的教程。欢迎大家前来体验，有 bug 或者有什么想和我交流的都欢迎直接联系我。

项目开始之前

如果我们想要通过 vibe 出来的项目来学东西，无论是学语言，还是学类似的项目应该怎么构建，还是学项目的管理和最佳实现等诸如此类的内容，那我建议在项目正式开始之前，先跟 agent chat 。我们可以先从最简单的问题开始，比如这个项目最好用什么语言实现，逐步通过 chat 的方式让我们了解整个项目怎么写，应该怎么构建。这个过程中，我们提出的问题很重要，要有意识的提那些让项目能够逼近最佳实现的问题。如果毫无头绪，也可以问 agent 有没有什么类似的成功的项目，问 agent 他们好在哪里，问题又在哪里。我们可以不关心最底层怎么实现，但是再往上的所有内容我们都需要在这个环节进行一些了解，这才能有助于我们在 vibe 的过程中学习到东西，对项目也有着更好的掌控。

这里有个小小的 tips :对于小白来说，在向 agent 提问的时候，要注意不要代替 agent 去判断，而是要尽量客观详细的描述问题和提出需求，这个时候不妨给 agent 最大的自由。举个例子，当我们编写一段程序报错的时候，应该要做的是将程序和报错发给 agent ，而不是根据报错自行做出判断，再把判断发给 agent 让他修复。在我们的经验和能力没有 agent 强的时候，前者通常都是更优解。

然后，无论我们是通过上面的方法，还是本来就已经想好了项目该如何实现，都要进行接下来这一步——还是 chat 。这一步的目的，是要看看 agent 对我们的实现想法理解的到不到位，以及约束 agent 接下来的行为。我们要让他生成项目计划书，然后让他检查一遍（这一步我们可以再开一个窗口来做，避免上下文污染，也减少 agent 对自己的信心的影响），我们再 review 一遍，将意见反馈给他，重新生成，重复这个循环直至项目计划书我们确定没问题。接着以同样的步骤生成 spec 文档。在生成这两个文档的过程中，我们要告诉 agent ，让他保持诚实，有模糊和需要进一步确认的地方要向我们提问解决，确保这两个文档足够详细清楚且正确。

最后，我们要明确 agent 能做什么，不能做什么，要怎么做。最好还能告诉 agent 一些过去项目会出现的问题，或者我们遇到过的问题（这是人有价值且无法被替代的部分），将这些作为 rules 和某种意义上的 skills 让 agent 写进项目的 instructions 里，确保 agent 后续的每次行为都不越界且更高效。至此，项目开始前的准备工作才算大功告成。

我十分不建议跳过上述的步骤，这会让后续项目的推进很不顺利，越大的项目越是如此，小项目就算看上去是那么回事，但其实内部早已是屎山堆积，甚至潜藏没那么容易被发现的 bug 和功能异常，最终导致重构。有关这部分的内容在后续 agent的特点 处会有更详细的阐释，现在我们只需要知道，在这里跳过的工作量，后面会成倍的反噬回来。

这次我在项目开始之前就只让 agent 生成了一个项目计划书，也没有过多的去了解整个项目有关的内容。造成了一些严重的后果，首先是 agent 自行决定了很多局部的东西，但整体规划没做好，导致后面项目第一版基本完全不能用。其次一开始没有给 agent 很具体的rules约束，导致他会写出一下超大的代码文件，无论是可读性、正确性和可维护性都奇差，导致后面需要重构这些代码。

如何提需求

在正式开始 vibe 的阶段，我们首先要做的还是 chat ，循环上面的步骤，然后生成一个新的 spec 文档。上面的 spec 文档有关项目有哪些功能，要按什么顺序做，验收的标准是什么，这里的 spec 则是逐功能的，要明确每个功能要以什么顺序完成什么步骤来实现。逐功能这一点很重要，原则上不建议一次会话让 agent 完成一个以上的功能，除非我们的每个功能实现起来都不复杂，就算在这种情况下也不建议一次会话超过三个功能。

需要注意的是，上一步的工作量，这一步就有了回报。当我们足够了解整个项目，知道大概怎么实现的时候，只要将我们的理解写在 prompt 中，就能让 agent 更加高效准确的理解和正确实现我们需要的功能，相应的，我们需要花在改 spec 文档上的循环和时间也会更加少。

这里和上面提问环节相比，给 agent 的自由度要大大降低。前提是，我们在一开始提问时，已经收集到了足够多的信息。

在项目一开始的时候，我用的是 copilot + superpowers （通过米奇妙妙神奇方法做的适配）。copilot 有一个最大的特点，他是按请求数计费，所以在一个请求中塞尽量多的需求看上去是一个划算的做法。但我们不难发现，这和我们上文提到的逐功能提需求原则严重冲突。这样的后果是，一开始整个项目推进的很快，但每个功能都没有做到可以验收的地步，甚至有些功能还被遗漏了。我后来付出了成倍的请求数来修复这些问题，贪小便宜的代价说是。

前端设计

我相信主要 vibe 过有前端界面项目的人都清楚， agent 在这方面的表现是灾难级的。御三家在这方面的表现也有明显的分化（ Claude > Gemini > ChatGPT ），比在其他方面的差异更直观，也更令人印象深刻。我的建议是任何有前端的项目，都要将前端的实现放在第一步。在这个过程中，我们要让 agent 逐步（和上文的逐功能有点类似）的完成前端，且不附加任何后端逻辑。这有利于我们因为前端问题重构的成本最小（前端据我现在看来，最有可能成为重构的原因）。

尽管我们做好了重构前端的准备，也并不希望需要大量的重构和花费太多时间。所以下面我会给出我的一些实践经验，和在各种渠道上看到的一些解决方案:

  1. 配合一些专门用来设计前端的项目，比如 agent Studio 和 Figma。
  2. 找一些专门用来设计前端的 skills ，需要注意的是，大部分 skills 对于设计前端的支持要远比重构前端更好。
  3. 找一些你喜欢的前端页面，将截图和网址发给 agent ，明确让他模仿样式布局和配色方案。这样的做法提高了 agent 的下限，但是会丧失前端界面的设计感，有可能做出雷同的网站。
  4. 目前我看到过最有趣的一个做法，运行两个 agent ，一个专门生成，一个专门评估。不断循环生成-评估的流程，直至评估 agent 认为可以验收。这个方案上限最高，但也最考验人的能力。我们不仅需要写好两个 agent 的设定，还要写好两个 agent 的行为。对于生成器，我们不仅要告诉他怎么设计，还要让他有推翻前面方案重来的能力，也即给予他跳出局部最优解的能力。对于评估器，则是更考验开发者的审美和品味。我们需要告诉他，什么样的方案是好的，并给他一个细化的指标和打分标准，每个指标之间的权重可能还要差异化，因为 agent 在不同指标上的表现也有不同。对于小白来说，这个方案是有点难以实现的，但是也可以试试让另一个 agent 来帮我们完成上面这些步骤，我们需要做的是将这个体系当成一个新的项目，重复一次项目的 vibe 流程（套娃）。
  5. 在开始做前端之前，先让 agent 生成一个 playground ，让 agent 炫耀一下自己的军火库，把他所有能实现的效果都在这个界面展示出来，我们再在这个界面中挑选。
  6. 色彩搭配方案可以上一些专门的网站进行选择，比如 huemint 等。

值得一提的是，这几种方案是可以组合使用的，甚至有几种方案还有明显的使用逻辑链。为了我们的前端能够顺利 vibe 出来的同时，还保持高水平的审美设计感，我强烈建议尽可能多的使用上面的方案。最后，如果十分不幸，我们在进行到后面的步骤中时，突然发现了某个前端小问题（大问题不应该出现在后面的步骤中），我建议不要用 ChatGPT 来修复。

这次 vibe 过程中我对前端 vibe 的过程印象深刻。由于我一开始就是前后端让 copilot 一起写，这上面的几种方法我也没有用，所以做出来前端很不好看。而当我发现这点的时候，重构的风险和已经写好的后端逻辑，让我想着让 agent 自己一点点修改。然后就陷入了 token 和请求的无底洞中。最终我用 skills 彻底重新设计了一次，才让现在的前端勉强变得能看（后续如果有人用且对前端有意见，我会考虑再重构一次）。要是我早点知道这几个方案就好了，悲!还有一件印象很深的事是，后期我发现了一个前端的小毛病，以为 agent 肯定能手到擒来，结果 GPT 5.4 修了一天都没修好。后面用 Gemini 3.1 pro 十分钟不到就解决了。

过程中

在项目构建的过程中，最好不要像流水线一样，一个功能实现，继续到下一个功能，这样直线式的前进和迭代，而是迭代完两三个功能之后，就让 agent 自己反思一下构建过程中有哪些值得记下来的问题。可以是某个库与另一个库不兼容，需要进行什么额外的操作，也可以是某个功能这样实现会覆盖掉其他正常的功能。这些问题和解决方法让 agent 生成一份 skills 来专门记录，这个 skills 在我们后续如果要新开一个对话，或者在不同的工作区开发的时候，就可以帮助没有以前上下文的 agent 少走很多弯路。用来生成 skills 的 token 在这一步也会省下来。

就算这是个简单的项目，我们后续不需要再换上下文开发，这一步依然是有意义的。我们可以将这个 skills 中能适用到其他项目的部分保留下来，让他从项目 skills 变成个人 skills ，用在我们以后所有能用到的项目中。定期整理个人 skills 是很有价值且有必要的一件事，我们不可能每次开始 vibe 一个新项目的时候，都能知道自己哪些经验要告诉 agent ，也不一定还能记得这些经验。但有了定期整理的个人 skills ，agent就能继承我们以往开发的经验，并在新项目中表现得像个老资历（这也是“同事. skills ”这种东西为什么会产生，和互联网大厂冰冷的同事变成温暖的 skills 这些梗产生的本质原因）。

对于经常 vibe 的人来说，我认为定期更新 skills 也是很重要的。随着模型能力的变化， skills 里的一些内容可能会从帮助变成一种束缚，成熟的工程师会定期对自己的 skills 进行消融实验（这点对 tools 和其他所有 agent 能力的辅助工具都有效）。

项目完善

在所有功能都 vibe 出来之后，项目已经初具雏形，但这时我们并不能保证项目能够正常运行，我们要对项目进行测试。对于小白来说，这些测试肯定也是由 agent 来写， agent 来完成。但是怎么让 agent 的测试全面有效，也需要不断摸索。一般来说，这种问题对小白来说的最佳解法有且仅有我们前面反复提到过的——和 agent chat ，我们可以问问 agent 测试分为哪些类型，我们的项目需要什么样的测试，也要告诉 agent ，我们需要测试达到什么效果，测试的最终目的是什么，测试要测试哪些内容和功能。一般来说，我建议每当我们逐功能的完成一个功能之后，都要让 agent 生成配套的测试，并保证测试通过，最终到验收整个项目的时候再来一个整个项目的测试。这样能最大限度的确保所有功能能够正常使用。

一个容易被忽略的点事，测试代码也是 agent 生成的，所以他们本身也需要某种程度上的测试和 review 。我个人感觉，应该还不至于为所有的测试代码，再写出测试的测试代码这种东西（而且这样会套娃无限循环），但这一步不能忽略。我们可以让 agent 使用瞪眼法来检查，要检查的内容要跟他提前说清楚，比如测试是否逻辑正确、测试有没有没覆盖或者覆盖弱的地方和测试会不会被阻塞卡死之类的（这些内容也可以通过万能方法——和 agent chat 来获得）。

还有一个很有意思的想法，是受到上面前端设计里很有趣的那个做法启发。我们可以让一个 agent 改进，一个 agent 专门测试（这两个 agent 的设计和上面也高度相似）。注意这个测试的 agent 应尽量不用我们已经写好的测试，而是通过我们给他的设定和 prompt ，来自行完成决定方向、编写测试和反馈测试问题整个流程。且每一轮循环应该都是“崭新”的， agent 不应该被之前的循环影响当前循环（最简单的做法是不共享上下文？）。也即 agent 每次都要像第一次看到这个项目一样进行评估和测试，防止前面循环测试过的内容在后面的循环中被 agent 排除。

抛开项目测试这方面的完善以外，还有项目的审计。我个人认为项目的审计关注重点和测试不同，测试更多是保证功能正常运行，审计则要更多的去审查项目潜在的风险，项目有没有遵守 rules ，还有安全性隐私性和性能的问题。很多测试其实也在覆盖这部分的内容，但终究不如跟 agent 说让他审计一次来的全面，这一步也完全可以等到所有其他功能正常后，项目正式发布前再来做。

最后我想说的一点是，当我们在任何阶段发现项目令我们不满意或 agent 走向了错误的方向时，要敢于重构。 agent 重构的效率比我们想象的高，至少在大部分时候，比一点一点纠正方向和改各种问题要容易。

在这次项目的完善中，由于我对整个项目并没有掌控感，对项目的正常运行也没有信心，所以我非常看重整个项目的测试。有代码逻辑测试这样的白盒测试，也有模拟使用环境这样端到端的黑盒测试，还强制要求了代码测试覆盖率不低于某个阈值，后期每次改动都会重跑这三个测试。这也间接的反映出，前面的步骤做好有多么重要，无论哪里欠下的债，最终都是要还的。

我用的 harness

我先说一下我这次 vibe 使用的 harness 和用到的扩展。一开始是用的 copilot + superpowers ，这个组合的特性以及由此带来的影响在上文已经有所提及。但最终促使我换 harness 的事是， agent 一开始生成的端到端测试有问题，导致卡在某个地方卡了整整一天半（我一开始以外单纯是测试内容多和复杂，就没中断他）。 copilot 貌似没有熔断机制，导致会一直卡在那，哪怕我后面手动中断了会话，告诉他测试有问题，他也不能成功的找到问题。这让我不得不换到其他的 harness ，现在来看这个决策是明确的，换 harness 并没有出现想象中的那些问题，反而给了我一个弥补前面步骤的契机，但我当时看不到这一点，我以为整个项目只差临门一脚了，就没有这么做，因此我后面的体验也没有很美妙。

后续的组合是 opencode + oh my opencode + superpowers ，这个组合相关人员肯定不陌生，他成功解决了我前面端到端测试的问题，前端的重构也是在这个组合中的 skills 帮助下完成的（虽然我个人觉得没有很强，大家可以找找其他的更强的 skills ）。但这个组合本身也有自己的问题。首先是 opencode 老生常谈的内存泄漏问题，我同时打开两个 opencode 过一次，那次电脑内存占用率来到了 99% ，吓得我赶紧关掉了其他的一些软件。还有就是 opencode 有时候会把一些任务丢到后台运行，但我完全看不到相关的状态，只有在任务完成之后会话里才会弹出一个框，导致有时中途连接断了，任务没在正常运行了我也发现不了，交互体验非常差。

花销

这部分是我认为本博客美中不足的地方，因为我用的全是免费的 api ，所以使用时没有很好的考虑怎样高性价比的花掉 token 。包括上面提到的所有内容，我虽然有自信说，大部分经验和原则是可以帮你节省 token 的，但是我并没有试过怎样才是最佳实践。这些经验和原则落实到行动上，依然有宽松和模糊的地方，我并不知道在这其中哪一点才是合适的，我只知道大方向应该是要这样。所以如果有读者读了本篇博客，并借鉴着去实践的话，可以多在这方面思考一下，并根据自己的需求和情况来化用我的经验。但是，我的免费 api 并不廉价， copilot 是学生认证之后的 GPT 5.3 codex ， opencode 时期是群友中转的免费 GPT 5.4 ，都是目前最好的一批模型，否则也不至于在我这样乱来下最终还能完成这个项目（越弱的模型越应该有一套优秀的使用准则，跟弱模型配 Claude code 能力大幅增强一个道理）。

虽然我没有实际的花费，但是有其他数据来间接反应总共的 token 花销。整个项目最终花了大约 35% 的 copilot 月请求额度和等价 1000 多刀的 token 。这是一个很恐怖的数，不亚于大炮打蚊子。资深的开发者用完这些额度和 token ，足以再产出 3 ~ 5 个跟我这个项目规模差不多但更精美的项目。所以虽然我不知道省 token 的最佳实践，但我知道走我的老路肯定很花 token 。

后记和一些感想

多即是少，少即是多

在一开始 vibe 的时候，由于不用花钱，所以我将 GPT 的思考拉到了 xhigh ，但之后我看到一篇文章，里面提到并不是所有的问题都适合 high 和 xhigh 。对于一部分问题， medium 加合适的 skills 的效果要远远好于 xhigh + skills 和 high + skills，哪怕是不加 skills 的情况下， medium 的表现也不比这两者差。作者猜测，可能是因为过度的思考反而会让 agent 回到原来平庸的道路和设计上。颇有一种多即是少，少即是多的哲学意味。因此根据功能复杂程度和请求的难度，来动态调整每次的思考强度是一个行之有效的策略。不过，作者还说，无论在哪种情况下 Claude 的表现都是完胜，用 Claude 就没这么多事了，又体现着一种一力降十会的暴力美学。

agent brain fry

agent brain fry 指因过度使用或监管 agents 而导致的精神疲劳，超出个人认知能力极限的状态。专业的部分到此结束，接下来是我自由发挥加输出一些在别的地方看到的内容的时间。

首先就是严重影响了我的注意力。 copilot 时期有问题会弹出通知，我只需要在有弹窗的时候去看一看就行。到了 opencode 时期，由于一开始没配置 opencode notifier 等类似的东西（一开始也不知道有），所以有问题不会有通知，我的精力始终有部分在那边，时不时不放心就得切过去，看看还有没有正常工作。频繁的切换注意力和持续的精力牵扯，让我干其他事的效率大幅下降，大脑也总是处于一种很疲惫的状态。哪怕在 copilot 时期，在有通知的帮助下，注意力的频繁切换也还是不能避免。

没有 agent 在跑的时候，感到焦虑。感觉自己在浪费时间。这是微软的一位工程师说的，也反映了大部分人的状态。在这个项目开始之后，我也算是体验到了资本家是什么心态。我之所以时不时切到 opencode 界面，也有因为想看看 agent 跑完没有，跑完赶紧布置下一个任务的心态影响。甚至有时候会没事找事让 agent 做。到了晚上睡觉前，我也一定要布置一个任务，让 agent 跑在那里（我的电脑因此好几天没关机）。这是相当病态的一种状态，加剧了我注意力的消耗和认知能力的下降。这种状态还有另一种表现形式， token 焦虑。我身边有朋友会因为 copilot 学生认证每月的额度用不完和订阅 plan 的 token 没用完而感到焦虑，在他们心里多多少少会有一点没用完就是浪费了，以及 token 剩下了是不是代表自己不行的想法在。最近还有部分企业以花费 token 数作为 kpi 的风声，仿佛谁用的 token 多谁就勤奋努力，谁就能快人一步。我对这种 token 大比拼祛魅的很早，因为我曾经大炮打过蚊子（因祸得福说是）。我觉得调整这种状态的办法，是要意识到 vibe coding 并不是 agent 的独角戏，人在其中也扮演着重要的角色，我们在其中的价值并不能被 token 评估。要知道自己想要做什么，不要为了做而做，也要明白 agent 只有和人一起工作才能发挥出最大的效果。

哪怕我们全心全意 vibe coding ，中途不干其他的事，到最后也还是会 agent brain fry 。以前编程像填字游戏，有节奏，可以放松。现在更像辩论。脑力已到吸收复杂信息、做出真实决策的极限。古法编程时期，负荷大多来自执行负荷，比如写代码、查文档和调试代码等。这些其实并没有完全调用我们的脑力。现在这部分负荷转移到了 agent 上，但复杂度是守恒的，他给我们留下了更加需要深度参与的评估负荷，比如验证输出、确定下一步和判断方向是否需要调整等。评估负荷在认知上比执行负荷更需要深度参与，每一次都是在直接消耗大脑的精力。执行可以是机械的重复，但是评估却没给开发者一点偷懒的余地。哪怕我们中途跑去刷手机，疲惫也不会减缓，反而因为切换注意力会导致适得其反。

对于我个人来说，第一次 vibe 还有一点体验很不好——我不知道这个过程究竟要花多少时间。我一开始预判是三天，因为这真的只是个小项目。事实证明，我还是太乐观了，这个项目最后花了我差不多两周时间，而且在正式结束前的每一天，我都不能确定是否明天就能结束。这是一种很消耗心力的状态，更别提因此被打乱的计划。

因为 agent brain fry 的存在，我下次 vibe 项目开始前，会先问自己准备好没有，并确保后续能有相当一段时间允许我保持 agent brain fry 状态。任何强大的武器都有他的约束。

agent 的特点

抽象泄漏定律:所有非平凡的抽象都会在某种程度上泄漏。放在 agent 上来说，就是把设计转化成代码的过程被抽象出来了，但是我们并不能百分百确定代码是对的，很可能某些 bug 绕过了测试，就这么潜藏在了项目中，这就是某种泄漏。网上很多一句话生成产品的营销，但其实对于大部分规模稍微大一点点的项目而言，一句话可能生成一个能看的 demo ，但是离真正完成整个项目还差得远。甚至我们后续还要花比正常一步一步 vibe 更多的时间在补充和修改上。因为一句话过于抽象了，泄漏是必然的。一个项目有很多的细节，哪怕我们觉得，我们已经将脑子里想的项目的功能描述的很具体详细了。但是大脑里这些想法本身就经过一定的抽象，以前开发者在将设计转成代码的过程中，把这些想法还原到具象层面了，我们没有意识到这一点，现在我们把还原具象这一步交给了 agent 。agent 本身很强，也因为如此，对他来说，这个抽象可以对应着很多的具象。更何况自然语言本身并不如代码那样严格，是有歧义的，可能一句话可以代表两三种抽象，让对应的具象数目更多。它从中随机挑了一个较为“简单”给我们（大模型带来了随机的特点， agent 的设计让他偏向“简单”的），当然在大部分时候不可能和我们抽象对应的具象相符。这也是上文逐功能提需求原则的由来。

agent 并不是公平的脚手架，让每个人提升相同的水平，而是公平的放大镜，他让强者更强，弱者更弱。不可否认， agent 让很多人有了想法变成现实的途径。但举例来说，假如有 agent 前， A 的水平是 1 ，B 的水平是 10 ， agent 出来之后，全部放大十倍。放大的倍数是相同的，但二者的水平差距由 9 变到了 90 ，差距放大的倍数也是公平的。我相信不少人能看到这一点，所以大家都在研究怎么提高自己使用 agent 的水平，争取让自己的放大倍数变大。但我觉得，更为重要的是提升自己的初始值。我们想让 agent 干什么就提升什么方面的初始值，对大部分人来说，这样带来的收益远比提升放大倍数要高，并且哪怕提升初始值时接触到的知识和技能都和 agent 无关，但是放大倍数也会有所提升。agent 终究还是工具，在学习如何更好的使用工具之前，先要让自己变得强大。工具并不能改变我们在所有同样使用这个工具的人中的定位，学会怎样更好的使用工具也不能构成竞争力壁垒。

由于 agent 的特点，提升初始值时学习 how 的效益没有学习 why 的效益高，但是我认为两者都有学的必要，需要根据具体情况来斟酌。

完结撒花!大家都来试试 BFE 呀!

本篇文章部分观点参考了 Whisper 大佬的博客AI Coding is a framework, and…，但没有全部涉及，我十分建议大家都去看看这篇博客，佬的视角能让大家看透一些东西。如果是集体一起 vibe 一个项目的开发者，还可以去看看佬的这篇博客：当规则堆积成为智能的坟墓