AI 秒出网页代码,我却卡在了想要什么和怎么指挥
- 2026-08-07 22:48:28
一开始我以为，做网页最难的地方是技术。
毕竟我不懂前端，也不懂 HTML、CSS、JS 这些东西到底怎么配合。以前用飞书文档和 Word 做作品集，虽然能放文字和图片，但内容一多，排版就开始变得笨重。我想让项目图自动切换，想让模块之间有更清楚的层级，想让页面看起来不像一份被搬进浏览器里的静态简历。于是我开始让 Claude Code 帮我搭作品集网页。
但真的做起来之后，我发现技术没有我想象中那么挡路。AI 可以帮我写代码，可以帮我改样式，可以帮我拆参考网站，甚至可以帮我部署上线。它让很多原本需要先学很久才能动手的门槛，变成了边做边学的即时反馈。
问题反而换了一个地方冒出来。当做网页这件事变得没那么难之后，我必须回答一个更直接的问题，这个网页到底想要表达什么。
技术门槛消失后，我开始追问
这是我“做网页”系列的第三篇文章，前两篇解决掉了一部分问题。
第一篇，我写的是视觉秩序。AI 可以很快做出一个看起来不错的页面，但如果所有元素都在抢注意力，页面就会失去焦点。所以我开始学着看视觉权重、信息层级、留白、色彩和组件语义。【AI 做的网页总感觉差一口气？我是如何重塑视觉秩序的】
第二篇，我写的是网页层级。AI 把学习顺序反过来了，我不是先学会前端，再开始做作品集，而是先让 AI 把页面做出来，再带着真实问题回头理解 HTML 管骨架、CSS 管外观、JS 管动作。【不懂代码，我怎么指挥 AI 做出一个像样的作品集】
这两篇是在写怎么样做网页，其实一直在逼近同一个问题：我到底想让这个页面长成什么样？
刚开始做作品集的时候，我其实没有一个完整答案。我只是觉得飞书和 Word 不够用了，想做一个更像网站的东西。探索路径其实更像是模仿、拆解、改造。
这个过程挺野生的。我一边去找一些我觉得做得还不错的参考网站，让 AI 帮我去仿照那个样式做，然后看它输出的结果，看哪里不符合我的想象，然后再让它继续改。页面确实一点点变像样了，但做着做着，我也开始意识到，如果只是不断把喜欢的零件搬进来，网页很容易变成一个精致的拼盘。它可能有漂亮的背景，有动效，有卡片，有轮播，但用户进来以后，会不知道先看什么，也不知道最后应该记住什么。
走到这里，我真正关心的已经不是怎么上线，也不是怎么复刻一个品牌站。那些当然有用，Cloudflare、Git、Plan、commit 都有用。但它们解决的是执行过程里的问题。执行再顺，最后还是会回到同一个地方。
我得先知道，我想让这个网页替我表达什么。
不同网页，回答的是不同问题
以前我只知道把内容填进去，但后来我发现，作品集、简历和个人站，虽然都在介绍“我”，底层的任务其实完全不同。
如果把作品集做成了简历，页面就会显得急切，像是在催促对方赶紧做判断；如果把个人站做成了作品集，页面又会显得过于功能，少了“我是谁”的温度。我意识到，我之前之所以做出“精致的拼盘”，就是因为我在用做简历的思路塞满作品集，又想用个人站的风格去装点门面。
网页的内容架构，取决于它到底要回答什么问题，我想让别人先看见哪一个“我”。
作品集更像证据，它不需要把我做过的事都列出来，而是要挑出最能证明能力的部分，回答“我做过什么，做到了什么程度”。简历则更像筛选工具，每一行字都要帮对方快速判断“我适不适合这个岗位”。而个人站面对的往往是完全陌生的人，对方不一定有耐心读完所有经历，它更需要一条主线，让人知道“这个人是谁，她在关心什么”。
目的落点不同，表达架构就不一样。这决定了哪些内容应该被保留，哪些内容应该退后，哪些内容应该删掉。
如果是作品集，项目就应该站到前面，因为作品本身是最有力的证据。如果是简历，信息就要更快、更准、更方便判断，教育背景、实习经历、技能和项目之间的顺序，都要服务于匹配。如果是个人站，经历不一定越全越好，它更需要一条主线，让别人形成一个稳定印象。要是换成产品介绍页，架构又会变成另一套逻辑，读者最关心的可能是它解决什么问题，和现有方案有什么不同，为什么现在值得试。
所以我想讨论的是，我们在用 AI 做表达型网页时，应该先想清楚什么。
这里的表达型网页，包括作品集、简历、个人站、项目展示页，也包括一些轻量的产品介绍页，但复杂业务系统、后台工具、电商交易页就不在这次的讨论范围。它们不一定需要复杂功能，也不一定需要数据库和后台。它们共同要解决的是一件事：用网页完成表达、展示、介绍、说服，让别人理解一个人、一件事、一个项目或者一个产品。
5 个问题，搭出第一版架构
既然架构是为了回答问题，那到底该怎么落地？我觉得可以问自己 5 个问题：
1. 这个网页给谁看？ 2. 我希望他最先知道什么？ 3. 我希望他最后记住什么？ 4. 哪些内容能证明这个判断？ 5. 他看完之后下一步应该做什么？
通过这 5 个问题，可以搭建起网页的第一版架构。网页里的每一块内容，都是从这 5 个问题的答案里长出来的。答案没想清楚就开工，AI 做得再快，也只是一堆不知所云的页面。
比如说，我的作品集如果按这 5 个问题来填：给招聘方和潜在合作对象看，我希望他最先知道的是我在做 AI 实践和内容表达，最后希望他记住我能把 AI 工具、真实问题和内容叙事连起来，证明材料就是项目、文章和网页本身，下一步则是看作品或联系我。这样一来，首屏、项目区、文章入口和联系方式的顺序自然就出来了。
同样 5 个问题，换成简历和个人站，答案不同，页面架构也会不一样。
这一步其实挺难的。因为经历越多，越容易什么都想放。AI 也很容易顺着我给的素材，把所有内容都排进去。它不会天然知道哪个经历更能代表我，哪个项目只是阶段性尝试，哪个按钮应该引导用户去看作品，哪个链接应该引导用户去读文章。这些判断都得我来做。
我现在越来越觉得，搭表达型网页之前，最该先写下来的不是视觉风格，也不是技术方案，而是这几个问题的答案。哪怕答案还很粗糙，也比直接让 AI “帮我做一个高级一点的网页”要好得多。因为前者是在给它方向，后者只是在让它猜。
把感觉翻译成 AI 能执行的指令
有了表达架构，只是第一步。真正动手时，我发现最大的障碍是，我的想法是模糊的，但 AI 需要具体的规则。
一开始我跟 Claude Code 说“把模块往左移一点”，它经常会改过头，或者移动得不够。后来我学会了不说形容词，而是给参照物。文字说不清楚的，就用图片标注给它看。我说“和导航栏左对齐”，“整个页面宽度以导航栏宽度为主”，并且把截图标注给它看。这时候，它才真正知道我说的“对齐”是指什么。
不是它突然变聪明了，而是我学会了把模糊的感觉，翻译成它能听得懂的指令。
还有要给它验收的标准。以前我说“首屏要清楚一点”，这句话其实不好执行。后来我会更具体地说，首屏 3 秒钟内要看懂我是谁。仿照 Qoder 那个图片轮播样式时，我也不能只丢一张截图给 Claude Code，因为我喜欢的不是某一帧，而是图片进入、停留、退出的整个过程。于是我把过程拆成多张截图，告诉它图片从下方进入相框，停留一会儿，再从上方退出。这一步看起来有些笨，却能省去许多次改-看的来回拉扯。结构可以用截图说清楚，动效就要用多张截图、录屏或者文字拆过程。
AI 不会读心术，它需要参照物，需要边界，也需要验收标准。
有时候 AI 可能会过于陷入局部，而忽略全局的统一性。比如说页面层级。Claude Code 帮我审视页面之后，给我很多具体建议，比如哪个区块应该用什么字号，标题和正文分别多大，行高多少，卡片间距怎么调整。如果我只是逐条照着改，页面可能局部变好了，但下一次改另一个地方，又会出现新的数字、新的颜色、新的间距。
所以我让它把字体、字号、颜色这些样式定义为变量，所有样式直接调用这些变量，之后只需要改一个变量，就能全站生效，避免手写样式的混乱和难以维护。这个动作看起来像前端实现，其实是在建立设计秩序。今天一个标题用 32px，明天另一个标题用 36px，单看都说得过去，但整个页面会越来越松。变量的作用就是把这些局部决定收束到同一套规则里。
那它难道不知道要去设置变量吗？AI 当然也知道，只是有时候就没有想到这一点，所以也不是 AI 给出的所有建议都可以直接采纳。我觉得人的作用也就在这个地方。我会从我的视角对它给出来的方案提出质疑、疑惑和补充，然后它会对我提出来的问题给出回应，我们再不断讨论，最后决定采纳什么方案。所以，我觉得人和 AI 要一起协作，不能偏听一方，而是要一起去想办法解决问题，共同参与这个过程。这样才有可能拿到更好的结果。
用 Plan、变量和 Git 留住判断
光会翻译还不够，AI 的执行力太强，如果不加约束，它很容易把页面改得支离破碎。所以我慢慢建立了三条规则，来管理我们的协作过程：大改动先 Plan，先局部验证再推广全局，改好就 commit。它们看起来分别在管需求、设计和版本，其实是在管“失控”。只有建立了这些边界，我才能放心地把执行交给它，自己专注于判断。
我最开始提需求时，Claude Code 经常会直接开始改代码。它一顿操作之后，有时候确实改好了，有时候却不是我想要的。更麻烦的是，它可能顺手动了我没让它动的地方。反复几次之后，我给它定了一个规则，大改动先别急着写代码，先说 Plan。
这个计划不需要多复杂，但要讲清楚准备改哪些文件，调整哪些结构，布局是怎样，预期效果是什么。我看完以后，如果方向对，再让它执行。如果方向不对，我就能在它动手前直接调整。这一步一开始会让人觉得慢。但我后来发现，真正浪费时间的不是写 Plan，而是 AI 已经改了一大堆，我才发现它根本没理解我的需求。
另一个很有用的做法是，先改一个地方验证效果，再推广到全局。前两天 Claude Code 帮我定义变量并应用到全局的时候，就是帮我这样做的。
它先在文件的开头声明变量，再改一个部分作为试点，让我确认效果。它还贴心地给我看新旧对比，等我看完确认无误后，它再一次性做全站的修改。先用一个局部验证判断，如果错了，损失也小；如果对了，再扩大范围。
我对 Git 的理解，是被一次惨痛的教训给倒逼出来的。我曾同时开了三四个窗口，分别改作品集的不同部分。其中一部分改得不好，我就回退到之前的状态。结果一回退，其他窗口里已经改好的部分也跟着回去了。我一开始还以为是 Claude Code 又乱动了文件，后来才明白，几个窗口操作的是同一个文件，那些我以为已经完成的改动，因为没有及时 commit，就没有形成一个清晰的存档点，实际上并没有保存。因为 AI 并不知道，这处修改对我来说只是过程，还是已经可以存档的结果。
从那之后，我对 Git 的理解变得很具体。git 不是一个抽象的程序员工具，而是我和 AI 协作时的安全网。每改完一页，或者每完成一个明确阶段，我觉得 OK，就 commit 一次。这样后面哪怕 AI 改坏了，也能回到一个确定版本。这就像在 Word 文档里面写内容，写完一部分就要及时保存。不然的话，内容写得再好，没有保存，也是白费工夫。
所以，Plan、局部验证、commit，其实是在解决同一个问题。AI 执行得太快了，人如果不给它设置边界、验收点和记录节点，项目就会很快变成一团乱麻。做网页不是把需求丢给 AI，然后等它变魔术般交付一个成品。这感觉更像是我和一个执行力很强但需要明确指令的同事一起工作，我要告诉它目标，给它参照物，定义规则，确认每一步有没有跑偏，也要在必要时保留回退的路。
技术门槛消失后，思考门槛显现。做网页不难，自己想清楚才难。
这次做完作品集和简历之后，我更清楚地意识到，难的不只是“想清楚”，还有把这个想清楚的东西，变成 AI 能理解、能执行、能一步步验证的规则，最后做出我想要的东西。
因为最后决定网页有没有意义的，不是它好不好看、用了多少动效，也不是它上线到了哪里，而是它有没有替我准确地回答：我到底想让别人怎样理解我，理解这件事，理解这个作品。
Plan、变量、Git，这些看似枯燥的执行规则，其实都是在捍卫那个最初的想法。如果我不先想清楚我想要什么，AI 就只能给我一个漂亮的空壳。如果我光想清楚了，却不能用 AI 实现，再好的想法也会在一次次混乱的修改中消磨殆尽。
往期推荐：
从 MSA 到「默契」：我的人机协作系统是怎么一步步长出来的？
Your feed is your fate.
谢谢你阅读我的内容，希望你能有所收获。
