我不会写代码,怎么把一个网站一步步做出来的?

我不会写代码，但过去这段时间，我用AI上线了一个公众号排版网站。这篇文章也是使用这个工具完成排版的。

它不是一句话生成的的玩具demo页面。

它有编辑器，有主题系统，有用户登录体系，有积分机制，有后台管理，还有后来我花了很多时间才补上的  AI 一键排版 。

现在这个网站已经真实在线上跑了，也已经有用户在用了。

体验地址是https://flowcast.aurova.top

你可能以为我要说一个“一句话AI全自动生成”的故事，但其实完全不是。

我想说的是，  不会写代码，不代表做不出产品。可想把产品做出来，依然要花很多时间，很多耐心，还要踩很多坑。

我今天想把这个过程完整复盘一遍，一方面自己做一些总结。

另一方面，也想给大家一些经验参考，如果你也是非技术背景，想借助 AI 做点自己的东西，这篇文章应该会比那种纯工具安利更有用。

01	我为什么要做这个网站

这个项目不是我拍脑袋想出来的。

它来自我自己一个特别高频、特别真实的痛点。

我平时会发公众号。

每次发文，排版都会浪费我的时间精力，而且都是一些体力活儿。

两边边距要调，行间距要调，不能太挤，标题要醒目。

更麻烦的是，公众号原生编辑器并不好用，也没有帮你记住上次排版效果的功能，每次都要重新调整，真的很麻烦。

我也试过一些市面上的排版工具。

有的功能很多，但功能一多，使用负担也跟着上来了。

我真正想要的，其实很简单。

还有一点，我发现，现在 AI 其实很擅长理解 Markdown 这种结构化文本。

也就是说，如果我能把AI擅长的Markdown格式和排版这两个环节接起来，这个过程可以被大幅简化。

所以我最后想做的东西就很很明确了：

就是一个  面向非技术创作者的、极简的、审美在线的、支持 Markdown 和 AI 排版的公众号编辑器 。

就算最后没人用，只解决我自己的问题，我也觉得值。

这是也是我觉得新手用AI做产品的一个技巧，很多产品，往往是从你自己那个高频、重复、又很烦的痛点里长出来的。

02	真正难的地方，很多时候不在代码

过去一年我做过一些小项目。

折腾得越多，我越发现，一个人做产品时，最难的地方并不是写代码。

最难的是，你到底想做什么。

你想保留什么。你不要什么。

AI 能帮你写实现，能补代码，能查资料，能改 bug。

但如果产品定义本身是模糊的，AI就会给你乱加功能，最后成为四不像的一个臃肿的产品。

所以这次我没有一上来就让 AI 开始写代码，而是先跟AI协作，先把问题问题想清楚。

我现在基本固定成了一套工作流程，这个在我之前的文章中也提到过。

第一步，先让 AI 做调研。

我会把需求描述清楚，让它去看市面上有哪些同类产品、有哪些开源项目、哪些能力值得借鉴

第二步，让 AI 根据调研结果写 PRD。到这一步，我关心的重点落在产品逻辑，不会落在技术细节，一些小的交互细节也不会特别关心，只管大逻辑是否正确。我要先判断这个产品到底该长成什么样，哪些功能应该先做，哪些先别碰。

第三步，让 AI 输出技术架构文档。

这一部分说实话，我很多细节看不懂，所以我基本上不看，但是这个步骤是需要的，因为可以告诉后面的AI一个基础框架，不至于大方向上跑偏。

第四步，再让 AI 把任务拆成实施计划。这是 superpowers 自带的技能，会自动把任务拆解出来一个md文档，后面AI就知道先做什么，后做什么，有条不紊的写代码。

第五步，才是真正开始写代码。

整套工作流程我主要是靠  superpowers  这个 skills 体系去跑的。

Skills地址在这里，对于开发产品来说，我还是非常推荐的https://github.com/obra/superpowers

它最有价值的地方，是把整个过程拉回一个，像正规大长工作流一样的，有秩序的工作状态，让你像是在带着一个 AI 团队做项目，会让整个项目的可控性强很多。

03	第一个版本，其实挺丑的

第一版做出来的时候，我自己都觉得挺粗糙。

看这个图就知道，第一班其实完全是一个只能自己测试的版本，不是能够直接对客的状态，自己用用嘛无所谓，对外就过于粗糙了。

不过我知道，这一版最重要的任务，是先跑通产品逻辑，先把逻辑跑通最重要，至于交互和视觉好不好用，那是后面的事情。

第一个版本，左边输入内容，右边实时预览。支持几个基本主题。能一键复制到公众号。

到这里，它就已经是一个 MVP 了（ Minimum Viable Product ，即“最小化可行产品”）。

如果你对这个词不熟，可以把它理解成一句很朴素的话。

先做出一个最小的、能真正解决问题的版本。

不是最完整的版本。也不是最漂亮的版本。更不是一步到位的完美版本。

先跑起来，再一点点变好。这件事非常重要。

因为 AI 编程太容易了之后，很容易让人偷懒，想要一句话就得到一个非常完美的版本。但往往越这么想，越偷懒，越容易返工。

04	从能用，到稍微像个产品

MVP 跑通之后，我开始往前补真正影响体验的部分。

现在网站里做到了三十多种主题，这都是让 AI 自由发挥，再由我自己一轮轮筛、一轮轮调出来的。

这段时间也是 bug 最多的时候，需要很多的耐心调整细节。

颜色不对，背景和文字撞在一起，看不清。有些主题比较丑。有些交互细节很难用。

这种时刻特别考验人的，是你能不能明确说出自己到底不满意在哪里，你有没有自己的感觉，到底哪里不好用，该怎么去改。

AI 很擅长执行。但“什么叫更好”，最后还是要你来判断。这也是AI圈现在经常讲的品味，品味不只是视觉审美，是一个很宽泛的，很抽象的概念，每个人的品味不同，做出的产品都会不一样。

05	最折磨我的，是编辑器细节

如果你没做过编辑器，可能会低估这件事，编辑器真的是个很折磨人的模块。

因为它会牵扯到大量格式状态切换。

你从普通段落切到标题，从加粗切到引用，从无序列表切到有序列表，每一个格式调整都可能会遇到坑。

我当时遇到过很多很具体、很崩溃的问题。

这里最让我头大的，就是有序列表和无序列表的切换。

网页里看着像对了，复制到公众号后台就开始格式错乱。

我真的是来回调了很多轮都搞不定，然后我开始换一种做法：

我回去翻调研时看过的那些开源项目，一个个去体验它们的真实效果，再把我觉得处理得比较好的项目扔给 AI，让它研究别人是怎么写的。

这招特别有用。

因为复杂问题，光靠空口描述，AI很难理解，即使理解了，AI自己想办法解决，很多时候也是无效努力，AI总是告诉你改好了，但是你去测试的时候，会发现一点都没变，来回个几次，你就会非常崩溃了！

但你一旦给它参考代码、参考产品，它就更容易一次性做好。

这也是我现在很常用的一个习惯。

遇到复杂问题，不要只会追加提示词。去找参考。去找同类项目。去找已经被别人验证过的实现。  给AI参考文档、参考代码，这个招数，我屡试不爽，推荐你遇到疑难杂症时，也去试一下。

06	有些问题，真的要靠换模型

还有一次我印象特别深。我在处理列表复制到公众号后台之后的乱码问题。

表面看只是个格式错乱的小问题，列表前面的小图标和后面的文本会异常换行。我前面已经试了很多轮，用Gimini怎么都搞不定。

后来我索性换了模型。我切到Claude 4.6 opus去处理这个问题，结果两轮就把根因找出来了修复了。

所以说，不同模型的表现差异真的非常大。不同的模型擅长的能力也不同。

比如说，Gemini的前端审美很好。

而Claude 4.6及以上，GPT5.4在后端代码逻辑上明显强于Gemini（目前）。

所以我现在会根据处理的任务不同，选择不同的模型。

07

前端好看的秘诀

很多人用 AI 做网站，都会遇到一个相似问题，就是AI做的网站，就像AI写的文字一样，也有AI味儿，审美不够高级，动不动就上蓝紫色渐变。

我自己常用两个办法。

一个办法是，直接换更擅长前端审美的模型（我自己喜欢用Gemini做前端），让它专门做视觉优化。

比如网站导航栏里有一些磨砂玻璃效果，都是直接让Gemini自己做的，我也没提示他做什么风格，他就是直接给我这么做了。

而我给他的提示词非常简单，而且我屡试不爽，用这个提示词的方法做过好多个网站，效果都不错。

请你按照一线互联网大厂的审美标准，优化我们的前端视觉交互，让其用户体验顺畅，视觉高级

另一个办法，是使用Fronted Design这个前端设计Skills，让 AI 按设skill 去同时出几套方案，然后把方案真实做出来，再在页面里横向比较，我再选择一个更好的方案。

Fronted Design地址：https://github.com/anthropics/skills/tree/main/skills/frontend-design

这个方法我很喜欢。因为用文字描述常常不如直接成品。

尤其你自己不是设计师的时候，更应该让不同方案先落地，再做判断。比如下图就是我之前做职业风险评测这个网站时，让AI给我出的一个对比网站。放在一起对比，很明显就能选出来哪个更好了，最终我使用的是A极简主题，这个网站也可以看这篇文章，小程序中也可以体验。

我做AI一键排版效果时，还折腾过一个环绕光效。有点像 Apple Intelligence 那种感觉。

这个效果我折腾了一整天。我知道自己想要什么，但 AI 最开始给出来的都不对。

后来我也是一路找参考。找了好多个开源项目，找相似效果，再把源码喂给 AI。

最后终于调到我满意的效果。

08	真正把产品对外，难度才刚开始

前端页面做出来，只能算过了一半。

真正麻烦的，是你准备把它放出去给别人用的时候。

网站我最后是部署在 Vercel 上的，域名和访问层面又结合了 Cloudflare 去处理。

这部分我也不懂。本就是一步一步问 AI，它再一步一步带着我操作。

为什么要这么做。因为如果直接按国内正式网站那套流程走，备案、部署、配置，整体会复杂很多。

我更在意的是，先把东西跑起来。先能访问，先能验证，先有真实用户反馈。

但更大的挑战，其实还在后面。

因为当我准备把  AI 一键排版  这个功能真正开放给用户时，我突然发现，问题根本不只是一个按钮调用AI模型的问题。

我得考虑很多现实问题。

于是我又补了一整套配套系统。

用户登录体系，积分体系，签到机制，邀请逻辑，后台管理。

到这一步，这个项目才开始从一个前端小工具，慢慢变成一个真正有业务闭环的产品。

我去看仓库历史的时候，已经能看到  139 次提交  了。

这个数字其实特别能说明问题。

它说明做产品这件事，哪怕有 AI，依然是反复试、反复修、反复判断的过程。

没有那种一句话直接到终点的神话。

09

最后一些感想

第一，AI 能把很多以前做不到的事，变成普通人也有机会做到。

第二，产品依然是一门取舍的学问。

你做得出来，不等于你什么都该做。

你最需要判断的，常常是哪些功能该砍掉，哪些别再加了。

第三，开源项目真的很重要。

我现在越来越常做的一件事，就是先去 GitHub 看。

看别人已经解决了什么问题。看别人踩过什么坑。

看哪些模块可以借鉴，哪些产品心智不该照搬。

很多时候，AI 给你的不是完美答案。开源项目也不是完美答案。

但它们会让你从完全空手变成手里已经有一堆可拼接的积木。

对不会写代码的人来说，这个差别太大了，把做产品的难度降低了N个数量级。

第四，MVP 这个概念真的很重要。

不要一开始就幻想做出一个完美产品。

先做一个能跑的版本。先解决一个真实问题。

后面有没有人用，要不要继续打磨，边走边看。

这才是普通人更有机会走通的路径。

如果你看完这篇，最大的感受是原来做一个网站还是这么麻烦。

那你理解对了。

它确实没有看起来那么轻松。AI 帮我跨过了很多技术门槛。但它没有帮我跳过思考，也没有帮我跳过调试。

可即便这样，我还是觉得这是一件特别值得的事。因为以前，这件事我连想都不敢想。现在，我至少能真的把它做出来。

如果你也是非技术背景，也有一些一直想解决的小问题，我很建议你去试试。

未必要一上来就做一个对外开放的大产品。

你甚至可以先给自己做一个很简陋的小工具。

能帮你省十分钟，能帮你少做一次重复劳动，很多时候就已经足够有价值了。

产品这件事，未必要从宏大叙事开始。

很多时候，它就是从你自己那一点点“不想再忍了”的痛点开始的。

感谢你看到这里，如果觉得对你有帮助，欢迎点赞、在看、分享给朋友，这对我真的很重要。

10	附录 这篇文章里提到的开源项目

下面这些项目，是我这次做 FlowCast 过程中参考过，或者确实在工程链路里发挥了作用的，感谢这些开源贡献者们。