TL;DR
全栈开发，一定一定不要先写前端再写后端，先写后端逻辑将要渲染什么数据确定，前端编写就顺理成章的完成了
开发遇到的问题
Vibe Coding 时候，很多时间花费在了调整前端样式上面，当然我不回避品味问题，品味就是要一点一点调整的，重大流程问题出在了前后端衔接数据渲染上面，AI 出的前端原型总是会出现过度设计，我的工作流程往往是先写 HTML 然后才会设计后端接口，很多开发的新功能时候先写前端会浪费大量时间，应该先设计后端 API 接口数据，要先想好，渲染什么数据，才决定前端如何显示
关于前端开发
前端编写的前提是先确定好后端要渲染什么数据这也是上一章节问题中一再强调的事情，只有设计好的后端渲染的数据才能保证前端不过度设计，添加一些本不需要的逻辑和数据
自己的最佳实践一些拙见，选好框架，可以是 ai-elements 也可以是 assistant-ui，也可以是 shadcn/ui，作为最基础的 AI 前端框架骨架层代码，Vibe Coding 最累人的地方是品味，因为大家用的都是同一个框架渲染出来的内容在很多程度上同样的丑陋，同样的没品，当然我也不是说我多有品味，因为我也抽卡，安装了这些组件，不要直接用组件来直接编写生产代码，先在项目的 design/ 文件夹下编写某个功能的 HTML 版本来创建三个不同的设计方向，可以去选哪些设计方向是想要的，只有两种结果，某个方向是想要的/三个方向都差强人意，可以继续抽卡或者粘贴某个 SaaS 平台或者产品的截图继续生成想要的设计方案，设计方向觉得 OK 想继续看一些不同细节的不同设计，根据设计方向写几种 HTML 变体，一切准备就绪即可应用于生产代码组件中
随着项目的迭代代码规模逐渐变大，新的功能会越来越多，遵循上述设计开发流程 design 文件夹下会有很多内容，如何沿用之前的设计偏好和风格来开发新的 feature？让 AI 阅读 design 文件夹下的内容整理总结设计风格和原语，后续可以复用已有的通用型资产，下一阶段新设计参考这些原语（Design Primitive），产品整体基调基本定型同时也会减少样式设计中抽卡失败的概率
还有另一种路径，项目创建之前提前设计好原语，而不是从项目开发过程中派生。提前定制化项目设计前端原语，确定好以下几点，项目主要功能，面向受众群体，简约风格 or 流媒体风格 etc.，预设的功能，交互的方式，AI 会参考功能和预期方向设计原语和风格定下基调，这需要对项目规划有一个整体的预先评估和规划，这个方法才会发挥更好的作用，如果自己都没想清楚要做什么那么我认为这不是一个很好的起点
Flue 框架引发的 agent harness 是否已经是过去式的思考
Flue 这个框架是基于 Pi Coding Agent 这个框架之上写的一个可以自由定义并且集群化 agent 的开源框架，Vercel 也推出了相关的产品，是 Eve，但是 Eve 强绑定 Vercel 平台化能力，依赖 Vercel 的 sandbox，意味着你必须强行绑定 Vercel 生态，很多强绑定的其实风险很大，例如最近的 Fable 5 禁令包括 GPT-5.6 的延期推迟，很多都意味着自研能力包括开源的重要性，研究了一个多月的 Agent Sandbox，本来以为 Daytona Sandbox 是很好的开源解决方案，但是这周也走向了闭源，GitHub 最新提交全删了不再维护，我感觉又要转向 E2B sandbox 了，无论是软件还是 model 虽然我认为优秀的开源项目不少，但是还是要读一些底层实现原理，因为很多开着开着就会闭源，逐渐走向商业化，这是趋势也是必然，也能理解
当然为了说 Flue 这个框架，谈起开源并不是重点，而是想说，根据现在 model 的能力我认为 harness 并不是重点了，因为给一个 Bash 工具，还有一些根据项目需要的特定工具在一个给定的环境下，AI 基本上能够完成 80% 的任务，之前 Claude Code 源码泄露，暴露了很多 harness 工程的一些细节，但是 Pi Coding Agent 中学到的内容是，简单的工具，也能实现几乎与闭源框架同样的性能，也许下一阶段的走向，不是 harness engineer，现在软件越来越像一个黑盒，之前我们说 model 参数量太大，可解释性低，现在软件似乎也朝着这个方向发展，很多都是一句话生成，自然语言编程，很多人不知道底层逻辑，只知道这个 feature works 了，nobody cares about the detail，AI generation 速度越来越快，代码量越来越多，是个人都审不过来，这很正常，我也承认这是趋势，未来我不知道软件会怎么发展，总是有一种感觉软件也逐渐像一个可优化可梯度下降的趋势在发展，就像是在训练 model
又扯远了，Flue 使用下来给我的体感就是给一个 goal 优化方向然后 run run run wait output，没人关心怎么执行的中间过程，这是我最初使用 Flue 的体验，也许最佳使用场景是 PR 审核，issue 回复，长时任务执行
Flue 定义 agent 更像是雇了一个人专门干一件事的感觉，只不过 Flue 提供的能力就是，只需提供 skills 只需提供工具，然后其他交给 agent 这个发动机执行
写在最后，感觉自己写作能力下降了不少，后面还需要多写一些手敲的东西，渐渐恢复表达能力，即使是 AI 润色过的内容我也会标记出来，给出原始手敲的原始稿
TL;DR：做全栈开发，不要先写前端再补后端。先把后端逻辑、以及「要渲染什么数据」定下来，前端自然水到渠成。
这是我第一次正经写 Tech Blog，标题叫「梦到什么写什么」，本就是随手记录的一篇思考。下面是把原始草稿重新梳理后的版本。
一个反复踩到的坑：不要从前端开始
Vibe Coding 时，我大量的时间其实花在了反复调前端样式上。品味问题我不回避——审美本来就需要一点一点磨。但真正拖慢节奏的，是前后端衔接、数据渲染这一层。
AI 生成的前端原型几乎总会过度设计。而我过去的习惯偏偏是先写 HTML，再回头补后端接口。结果就是：开发一个新功能时，先动前端往往会浪费大量时间。
正确的顺序应该反过来——先设计后端的 API 与数据结构：想清楚到底要渲染哪些数据，再决定前端怎么呈现。
关于前端：让后端数据先行
承接上一节，前端编写的前提，是先确定后端要渲染什么数据。只有后端数据设计清楚了，前端才不会过度设计，也不会塞进一堆本不需要的逻辑和字段。
先选一个骨架框架
选好一个基础框架作为 AI 前端的骨架层，比如 ai-elements、assistant-ui，或者 shadcn/ui。
Vibe Coding 最累人的地方还是品味。因为大家用的都是同一套框架，渲染出来的东西在很大程度上「同样地普通、同样地没特点」。我也不敢说自己多有品味——毕竟我也在抽卡。
不要直接拿组件写生产代码
装好组件之后，别急着用它们直接写生产代码。我的做法是：
- 先在项目的
design/文件夹里，为某个功能写出 HTML 版本的三个不同设计方向； - 从中挑选想要的方向。结果通常只有两种：某个方向对了，或者三个都差强人意；
- 如果都不满意，就继续抽卡，或者贴一张某个 SaaS 平台 / 产品的截图，让 AI 接着生成；
- 方向定了、还想看细节上的差异，就在这个方向下写几个 HTML 变体；
- 一切就绪，再把它落到生产代码的组件里。
沉淀设计原语（Design Primitive）
随着项目迭代、代码规模变大，新功能越来越多，按上面的流程走，design/ 文件夹里会堆积大量内容。
那么，如何在新功能里沿用之前的设计偏好和风格？我的做法是：让 AI 阅读 design/ 下的内容，整理、总结出设计风格与原语。之后就能复用这些已有的通用资产，新设计直接参考这些原语（Design Primitive）。产品的整体基调一旦基本定型，样式设计「抽卡失败」的概率也会随之下降。
还有另一条路径：在项目开始之前就预先设计好原语，而不是从开发过程中慢慢派生。提前定制时，需要先想清楚几件事：
- 项目的主要功能
- 面向的受众群体
- 走简约风格还是流媒体风格，等等
- 预设的功能与交互方式
AI 会参考这些功能和预期方向去设计原语、定下风格基调。但这条路要求你对项目有一个整体的、预先的评估和规划——如果连自己要做什么都没想清楚，我认为这并不是一个好的起点。
由 Flue 引发的思考：agent harness 已经是过去式了吗？
Flue 是基于 Pi Coding Agent 写的一个开源框架，可以自由定义、并且把 agent 集群化。Vercel 也推出了类似的产品 Eve，但 Eve 强绑定 Vercel 的平台能力，依赖它的 sandbox——这意味着你必须绑死在 Vercel 生态里。
这种强绑定其实风险很大。最近的 Fable 5 禁令、GPT-5.6 的延期，都在提醒我们自研能力和开源的重要性。我研究了一个多月的 Agent Sandbox，本以为 Daytona Sandbox 是个不错的开源方案，结果这周它也走向闭源，GitHub 上最新的提交全删了、不再维护，我感觉又得转向 E2B sandbox 了。
无论是软件还是 model，优秀的开源项目确实不少，但还是要读一点底层实现原理——因为很多项目开着开着就闭源了，逐渐走向商业化。这是趋势，也是必然，可以理解。
真正想说的：harness 也许没那么重要了
聊开源其实不是重点。我想说的是：以现在 model 的能力，我认为 harness 已经不是重点了。
给它一个 Bash 工具，再配上几个项目所需的特定工具，在一个给定的环境里，AI 基本上能完成 80% 的任务。之前 Claude Code 源码泄露，暴露了不少 harness 工程的细节；但我从 Pi Coding Agent 里学到的是：简单的工具，也能实现几乎和闭源框架同等的性能。
也许下一阶段的方向，不再是「harness engineer」。
软件正越来越像一个黑盒。过去我们说 model 参数量太大、可解释性低；现在软件似乎也朝着同一个方向发展——很多东西一句话就生成出来，自然语言编程，很多人并不清楚底层逻辑，只知道「这个 feature works 了」，nobody cares about the detail。AI 生成的速度越来越快、代码量越来越大，根本不是一个人审得过来的。这很正常，我也承认这是趋势。未来软件会怎么发展我说不准，但总有一种感觉：软件本身也在变得像一个可优化、可梯度下降的东西，就像在训练一个 model。
Flue 用下来的体感
又扯远了。Flue 用下来给我的体感是：给一个 goal、一个优化方向，然后 run、run、run，等 output——没人关心中间是怎么执行的。这是我最初使用它的感受。它最适合的场景，大概是 PR 审核、issue 回复，以及长时任务的执行。
用 Flue 定义一个 agent，更像是「雇了一个人专门干一件事」：你只需要提供 skills、提供工具，剩下的交给 agent 这台发动机去跑。
写在最后：感觉自己的写作能力下降了不少，后面得多写一些手敲的东西，慢慢把表达能力找回来。即使是经过 AI 润色的内容，我也会标注出来，并给出最初手敲的原始稿。