因为社长的评论会在Slack上流动，我用AI做了一个评审Web应用，结果又遇到了另一堵墙的故事

〜设计师与AI一起在Cloudflare上制作带认证功能的Web应用的尝试〜

您好，我是UI设计师Hashi。

最近，比起先绘制线框图再请客户确认的流程，利用AI制作着陆页或网站的效果图并请客户确认的情况明显增多了。

以前，请客户确认设计时，通常是通过Slack，

“这里请加大留白！” “这张图片换一下！” “这里的文字需要修改！”

等方式收集反馈意见。

乍一看，这是很普通的做法。

实际上，到目前为止这样做并没有出现什么大问题。

不过，自从开始用AI快速制作原型之后，一个问题开始变得明显起来。

评论不断刷屏。

Slack 很方便。

虽然很方便，但它当然不是专门用于设计评审的工具。

日常工作联络、闲聊、其他项目的讨论，全都会汇集到同一个地方。

结果就是，

• 修改意见被混入其他对话中
• 话题线程越来越多
• “那个修改到底在哪儿来着？”
• 回过神来，话题已经转到别处

这类情况时有发生。

Slack还有列表功能。

我之前也写过一篇关于利用Slack模板改进工作流程的文章。

用Slack模板轻松开启DX | 专题 | Liberogic Inc.

不过，话题串的通知不太容易看清；而如果把通知接入其他工具，消息栏又会变得混乱……。

结果，

聊天栏只会越来越热闹。

用AI制作LP的速度已经提升了好几倍，但评审的方式却还停留在过去。

即使生成环节变快了，如果后面的评审环节卡住，那就太可惜了。

于是我想到了一个办法。

那么直接在HTML中写注释不就好了吗？

制作一个着陆页时，我突然想到。

如果能直接在AI生成的原型HTML上添加评论就好了。 而且，如果能把评论和附加的图片打包成ZIP，直接交给Claude Code或Codex等AI，那不是很方便吗？

虽然在截图上直接标红也很直观，但如果能直接审查HTML本身，

• 点击的位置
• 目标元素的CSS选择器
• 附近的文字
• 页面名称
• 附加的参考图片

等信息也可以一并保留。

也就是说，

不必说“这里改一下”，而是可以说“把这个HTML元素改成这样”。

这种方式在请 AI 修改时似乎也很好用。

“这个是不是挺方便的？”

就这样开始制作的，是

Design Marker（LP 红笔检查工具）

是。

先试着做了一下

最初的版本是在自己电脑上运行的本地应用。

使用方法很简单。

1. 将 HTML 文件整体打包为 ZIP
2. 拖放到 Design Marker 中
3. 在浏览器中显示 ZIP 内的 HTML
4. 点击想要标注的位置
5. 撰写评论
6. 导出包含评论信息的审阅 ZIP
7. 交给 Claude Code、Codex 等 AI 进行修改

就像在截图上画红线一样，可以直接在 HTML 上添加评论。

如果在以前要做这样的东西，不知道得花上多少天。

在开发过程中，

评论列表、负责人姓名、跳转到评论位置、图片附件、合并多份审阅……

“这个也想要”“那个也想要”，功能就这样一点点地增加了。

从这时开始，

这不是挺方便当内部工具用的吗？

于是，我渐渐开始得意起来。

与AI的配合比想象中更好

在制作 Design Marker 的过程中，最有手感的部分是与AI的协作。

如果在普通聊天中请求修改，

"请把左上角的图片稍微放大一点"

这类指示往往就是这样。

如果是人与人之间，看着画面大致就能明白，但对AI来说，"左上"具体指哪里、"图片"指的是哪个元素，都是模糊的。

在 Design Marker 中，可以从点击的 HTML 元素中获取例如下面这样的 CSS 选择器。

article.strength-item:nth-of-type(1)
 > div.strength-visual-wrap
 > div.illustration-slot

这样一来，就会向AI发送：

请将article.strength-item:nth-of-type(1)中的插图放大到当前尺寸的115%左右。

可以这样下达指令。

只要DOM结构没有发生重大变化，就能非常具体地定位需要修改的对象。

还可以一并提供页面名称、附近的文字、注释以及参考图片。

以前，

不对不对，不是那里！

以前需要反复向AI更正说明的修改，现在也越来越多地能一次就准确落在目标位置上。

“用HTML进行评审”，是不是和AI时代非常契合？

在这一点上，我们确实感受到了明显的手感与成效。

我们觉得“这个很方便！”，并将其分享给公司内部，结果

好，那就这样。

这个挺方便的。

也让大家用用看吧。

我兴冲冲地在公司内部分享了。

结果……

不能用？怎么回事，难道是我的设置有问题？

啊……

是的。

在我的电脑上明明可以运行。

但是，

在普通人的电脑上，它无法直接运行。

就像常见的本地应用一样，它被干净利落地打包成了成品。

我能用。但是，别人用不了。

我本人就是开发者，所以当然能正常运行。

但如果其他人要使用，就需要安装 Node.js 并准备依赖包。

对于熟悉开发的人来说，这并不是什么难事。

但是，要交给设计师和项目经理使用时，

首先请安装 Node.js

这款从说明开始的评审应用。

……这已经不再是一款轻松的评审应用了。

于是，

“那就做成一键就能启动的就好了！”

我这样想，于是还制作了start-mac.command这个启动文件。

双击后，

会启动终端、完成必要的准备、运行应用，并打开浏览器。

好，完美。

……我original以为是这样的，但是。

冷静想想，

“请双击这个陌生的.command文件”

这样的提示，也还是挺吓人的。

给社长发一句“先双击这个试试！”……这合适吗？ 很可疑。 明明是自己做的，却觉得很可疑。

虽然做出了能运行的东西，但并没有成为公司内部共享的主力方案。

和AI一起开发应用的时候，

“在我的环境里明明能运行，别人却用不了”

这种开发中常见的瓶颈，也会很自然地遇到。

工程师前辈的一句话

就在这时，工程师前辈给了一句建议。

写一份README， “把文件夹交给Claude Code，让它按照README里的步骤完成设置就行” 这样不就可以了吗？

……

我原本想把很多东西都做进应用里，让它更方便，但如果面向会使用AI的人，这样做反而简单得多。

与其什么都想在应用端解决，不如

连同使用的人和AI一起，考虑最省事的方法。

这也让我学到了一点东西。

可是社长一直没有给我写评论。

还写了README。

启动方法也简化了。

这样应该可以了。

……我当时这样想。

然而。

毫无音讯。

社长很忙，所以没空理我……。

这时，我还注意到一件更重要的事。

与其开发评测应用，

让人真正用起来

要难上好几倍。

无论在本地做得多便利，

“启动应用”

这第一步始终是必需的。

对于忙碌的人来说，连这一步都会成为门槛。

那样的话……

那就做成 Web 版吧。

只要点击URL就能使用，应该没问题吧？

基于这个想法，我决定开发 Design Marker 的网页版。

先做一个登录前的页面，给自己提提干劲。

虽然还想深入打磨很多细节，但需要考虑的事情太多，目前先用AI生成的落地页。

关于后端该如何搭建，我思考了一番，最终选择了 Cloudflare。

不过，我是一名设计师。

Cloudflare Pages、Pages Functions、Cloudflare Access、D1、R2……。

虽然听说过这些名字，但这是我第一次亲自规划架构，并将其搭建为 Web 应用。

接下来就轮到 AI 老师出场了。

我想制作一个面向公司内部的管理后台，以及一个与客户共享的评审页面。

管理后台可以使用 Cloudflare Access 来实现访问控制。

评论和项目信息呢？

可以保存到 D1 中

ZIP 呢？

也有利用 R2 的方法。

原来如此。感觉全都明白了！

……只是感觉而已。

AI 确实非常出色。

只要询问，它甚至会告诉你相当具体的架构。

不过，在这次的开发中我深切感受到的是，

AI 能告诉你方法，与能够构建安全的系统，是两回事

就是这样的结论。

从“请教教我”变成“我这样理解对吗？”

尤其是涉及安全的部分，只靠AI的回答来决定，让人很不放心。

因此，我决定对于不懂的部分和重要的部分，请工程师前辈帮忙审核。

如果是以前的我，

我想在Cloudflare上实现这样的功能，请问应该怎么做？

大概会从这样的问题开始请教吧。

但这样一来，前辈就得从头到尾全部解释一遍。

在前辈忙碌的时候，

“前辈！请从头开始教我！”

就像是在硬闯一样。

这次我先和AI反复沟通，自己整理了思路。

然后，

管理后台通过Cloudflare Access限制为仅内部成员可访问。 共享页面通过按项目分配的URL以及ID和密码登录。 项目信息和评论保存在D1中，LP整套ZIP文件保存在R2中。 这样的理解是否正确？

梳理到这一步之后，我才去咨询的。

也就是说，

“请告诉我”

而不是，

“这样的理解是否正确？”

变成了这样。

对我个人来说，这是一个相当大的转变。

与前辈的沟通也减少了，您可以把时间用在真正需要确认的地方。

我自己也不再只是复制AI的回答就结束，

「为什么要这样做」

也能一点点边理解边推进了。

做成 Web 之后，又遇到了另一道难关

就这样，Web 版本开始逐步运转起来了。

只要发送 URL 就能打开。

比本地应用压倒性地更易用。

“这样不就解决了吗？”

……我original以为是这样的，但是。

一旦做成 Web，本地版本中没怎么留意的问题便一下子全都冒了出来。

例如，

• 客户的未公开落地页可以交给云端吗？
• 谁可以查看哪个项目？
• 如何保护密码？
• 如何防范异常的登录尝试？
• 能否安全地显示已上传的 HTML？
• 项目结束后，何时删除数据？

等。

仅增加一个认证页面，并不等于“安全措施已完成！”。

这话虽然理所当然，但亲自动手制作之后，才真正体会到它的分量。

目前已实现 Cloudflare Access、按项目登录、保存至 D1 和 R2 等基础机制。

另一方面，

仍有一些方面需要改进，以便正式公开发布，包括加强密码保护、限制登录尝试次数、分离HTML预览，以及完善数据的保存与删除规则。

Design Marker还提供一种模式，无需将ZIP保存到云端，即可仅在浏览器中进行审阅。

仅在需要在云端与他人共享项目时，才会保存必要的项目信息和ZIP文件。

目前的Design Marker尚未作为正式服务推出。

目前仍处于以内部使用为主的验证阶段。

也就是说，这次我们做出的是

“已经打造出一个完全安全的服务！”

这样的说法。

恰恰相反，

我们正在了解需要保护什么，并逐一实施必要的安全措施，这是一款仍在开发中的应用

是。

转向Web并不只是带来便利。

同时也会产生保管用户数据的责任。

这次的项目让我学到了很多。

这是已完成的设计制作商管理界面。

员工可以从仪表板确认所有的修改标注检查。

进入详情页后，可以通过这样的方式打开构成方案的快速链接，直接查看LP或添加评论。

此外，还可以像这样查看针对LP留下的评论。同时也能参考以前的评论，因此构成的修改变得更加顺畅了。

即使有AI，学习仍然是必要的

通过这次开发，我还有一点深切的感受。

借助AI，即使是设计师，也比以前更容易挑战开发。

我自己也是，

“我想做这个”

从想法到真正能运行的东西，可以实现的范围显然已经扩大了。

但是，这并不是说，

“再也不用学习了”

的意思。

恰恰相反。

推荐这种结构

明白了！

仅靠这些是有风险的。

真正需要的是，

“为什么？” “这次也用那个方案可以吧？” “有没有漏掉什么？” “这部分找专家确认一下会不会更好？”

这是我们思考得出的结论。

要判断AI的建议是否符合本次的条件、还缺少什么，需要相应的知识。

AI确实是值得信赖的搭档。

但最终做出判断并承担责任的，仍然是人。

这次将Design Marker迁移到Web端，也让我们重新思考了与AI相处的方式。

在AI时代，变化最大的可能是审核工作。

AI只需几分钟就能做出一个LP。

以前需要花上好几个小时的初稿，现在出来的速度快得惊人。

然后再进行的，

“把这里改成这样” “把这块留白稍微加大” “只换这张图片”

这种来回沟通的方式，其实从很早以前就没有太大变化。

只是制作速度提高了，

由人确认、告知修改内容、再重新制作。

这一部分仍然相当依赖人工。

所以最近，

不仅是AI本身，

AI与人如何交互

这一机制也变得越来越重要，我认为。

Design Marker就是其中一项实验。

目前，

我们正在尝试HTML评论、图片附件、多人审阅意见整合以及按项目进行版本管理等功能。

今后想做的事情还有很多。

直接在截图上进行标注修改。

通过评论向AI提出修改请求。

改进版本之间的对比功能。

提升多人协作审阅的易用性。

当然，还将加强身份验证、HTML预览和数据管理等方面的安全性。

我们计划先在公司内部实际使用，并逐一进行改进。

起初是：

“Slack 上的评论一直刷屏，想想办法解决”

本来只是抱着这种想法开始做的一个小工具。

没想到不知不觉间，

做出了本地应用，

却没能让社长用起来，

于是改成了 Web 版，

开始学习 Cloudflare，

又为安全问题烦恼，

向工程师前辈请教，

最后连 AI 的使用方式也开始考虑了。

……本来只是想做一个审阅应用，没想到需要考虑的事情还挺多的。

不过，能够借助AI把日常工作中遇到的小麻烦变成实际的成果，我觉得这是一个很有意思的变化。

等它成熟到可以放心地对外公开时，我想再正式向大家介绍Design Marker。

在那之前。

首先，我会努力让社长认真地写一条评论（笑）。 不过今天先痛快地喝一杯好酒吧。