CEO的评论会在Slack中流传，所以我用AI制作了一个评审Web应用，结果遇到了另一堵墙

～设计师与 AI 一起在 Cloudflare 上创建了带身份验证的 Web 应用～

你好。我是 UI 设计师 Hasshi。

最近，我们不再采用绘制线框图后让客户确认的流程，而是越来越多地使用 AI 来创建 LP 和网站的原型，然后请客户进行确认。

以前，当需要客户确认设计时，我们会在 Slack 上

「请扩大这里的空白！」 「请替换这张图片！」 「请修改这里的文案！」

这样的评论。

乍一看，这是一种很常见的做法。

实际上，到目前为止这种方式没有造成任何重大问题。

但是，自从开始用 AI 快速创建原型后，一个问题就变得尤为突出。

评论流动不断。

Slack很方便。

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

日常工作沟通、闲聊、其他项目的咨询，全部都流入同一个地方。

结果是，

• 修改意见流向了其他对话
• 讨论线程杂乱无序
• 「那个修改在哪里来着？」
• 不知不觉中话题就转向了别的内容

这些情况就会发生。

Slack 也有列表功能。

之前，我还写过一篇关于使用 Slack 模板改进业务的文章。

使用 Slack 模板开启轻松 DX | 话题 | Liberogic 株式会社

不过，线程的通知容易让人困惑，如果连接通知的话，消息栏又会变得混乱……

最后，

聊天栏变得越来越热闹。

用 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这样的启动文件。

双击后，

启动终端、进行必要的准备、启动应用程序、再打开浏览器。

完美。

……但我后来想到。

冷静地想想，

「请双击这个陌生的.command文件」

这样的说明，其实也挺吓人的。

给社长发"先试试双击这个吧！"...真是可疑。 自己做的东西却感觉可疑。

虽然功能基本可用，但并未成为公司内部推荐的首选方案。

与AI一起开发应用时，

"在我的环境中可以运行，但其他人无法使用"

这样，我们也会普遍碰到开发中常见的这道难题。

工程师前辈的一句话

在这种情况下，一位工程师前辈说了一句话。

创建一个 README，然后 "将文件夹加载到 CloudCode 中，并按照 README 的说明进行设置" 不就可以了吗？

……

我们之前做了很多功能试图提高便利性，但如果针对能使用AI的人，这样的方式反而简洁得多。

与其一味地想在应用端解决所有问题，

从用户和AI的角度考虑，寻找最简便的方法。

这也是一次很好的学习。

但老板就是不写评论

也写了README。

启动方法也简化了。

这样应该没问题。

……我当时是这么想的。

结果呢。

一点消息都没有。

老板太忙了，没空理我……。

在这里，我意识到了一个更重要的事情。

比起开发审查应用，

让人们真正使用它

要困难得多。

即便在本地做得再便利，

"启动应用"

这第一步是必要的。

对于忙碌的人来说，连这一步都可能成为障碍。

那么……。

那就改成网页吧

只要点击 URL 就能使用，这样的话用户应该会接受吧？

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

先从创建登录前页面开始来提升积极性。

虽然想加入很多功能，但需要考虑的事情太多，所以暂时先用 AI 生成的 LP。

关于后端如何构建，我进行了思考。最后选择了 Cloudflare。

但说实话，我是设计师。

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

虽然听过名字，但自己从零开始考虑架构并将其构建成网络应用还是第一次。

从这里开始就该让 AI 老师登场了。

我想创建内部管理界面和用于与客户共享的审查界面。

管理界面可以使用 Cloudflare Access。

评论和项目信息呢？

可以保存到 D1

ZIP 文件呢？

有使用 R2 的方法

我明白了。感觉全部都理解了！

……只是感觉这样而已。

AI 确实很出色。

一旦提问，它就会告诉你相当具体的结构。

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

AI 能告诉你方法，和能构建安全的系统，这两者是有区别的

就是这样。

从"请教我"转变为"我的理解是否正确？"

特别是涉及安全的部分，仅凭 AI 的回答来决定还是很让人担心的。

因此，我决定让工程师前辈对不清楚的部分和重要的部分进行审查。

如果是以前的我的话，

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

我认为这是从那个角度听说的。

但是，这样的话前辈也必须从头开始全部解释。

在百忙之中，

前辈！请从头开始教我！

就像是在进行突击。

这次，我先通过与 AI 多次交流，用自己的方式整理了想法。

而且，

管理后台通过 Cloudflare Access 限制为仅公司内部成员访问。 共享界面按项目使用 URL、ID 和密码进行登录。 项目信息和评论保存在 D1 中，LP 完整包的 ZIP 文件保存在 R2 中。 我的理解正确吗？

在推进到那个阶段之后，我们才进行了咨询。

也就是说，

请告诉我

而不是

"我的理解对吗？"

发生了改变。

这是我内心的一个相当大的转变。

与前辈的沟通互动大大减少，能把时间花在真正需要确认的地方。

我自己也不再只是复制粘贴 AI 的答案，

「为什么要这样做」

能够在逐步理解的过程中推进工作。

转向 Web 版后，又遇到了新的问题

就这样，Web 版逐步变得可以运行了。

只需发送 URL 就能打开。

比本地应用易用得多。

「这样就能解决了吗？」

……但我后来想到。

转向 Web 版的那一刻，本地版中不太关注的问题一下子都浮现出来了。

比如说，

• 能否将客户的上线前LP安全地存储在云端
• 谁可以查看哪个项目
• 如何保护密码
• 如何防止非法登录尝试
• 能否安全地显示上传的HTML
• 项目结束后何时删除数据

等。

仅仅添加一个认证界面并不意味着「安全对策已完成！」

理所当然，但直到自己动手实现才深切体会到这项工作的分量。

目前我们已实现了Cloudflare Access、按项目的登录认证、存储到D1和R2等基本机制。

另一方面，

密码保护加强、登录尝试次数限制、HTML预览隔离、数据保存和删除规则等方面仍有改进空间，这些是我们在正式公开前想要完善的部分。

Design Marker 中有一个模式，不将 ZIP 保存到云端，只在浏览器内进行审查。

在云端共享项目时，我们采用了只保存必要项目信息和 ZIP 文件的机制。

Design Marker 目前还不是正式服务。

我们正在以内部使用为中心进行验证阶段。

换句话说，这次创建的是

「已完成一个完全安全的服务！」

这样的说法。

相反，

是一个正在逐步理解应该保护什么、并一个接一个实施必要防护措施的应用

。

将业务转移到网络上不仅仅是为了提高便利性。

同时也产生了保护用户数据的责任。

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

这是完成后的设计工具管理后台界面。

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

进入详细页面后，可以通过这种方式打开结构方案的快速链接，直接查看落地页或添加评论。

同样也可以用这种方式确认落地页和标注的评论。此外还可以查阅以往的评论，使得结构调整变得更加顺畅。

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

通过这次开发，我强烈感受到了另一件事。

得益于AI，即使是设计师也比以前更容易尝试开发了。

就我自己而言，

「想要制作这个」

到实际能运行的东西，范围显然扩大了。

但是，那是

「再也不用学习了」

的意思。

反而恰恰相反。

推荐这样的构成

明白了！

仅凭这一点是不够安全的。

真正需要的是，

「为什么？」 「这次这样可以吗？」 「有什么遗漏吗？」 「这部分应该向专家确认一下吗？」

被认为是这样的。

判断AI的提案是否符合本次要求、存在哪些不足之处，需要具备相应的知识。

AI真的是一个可靠的好帮手。

但是，最后做出判断和承担责任的还是人类。

这次Design Marker的网页化让我们重新思考了如何与AI相处。

在AI时代，审查流程可能会迎来最大的变革

AI可以在几分钟内生成着陆页。

以前需要花费好几个小时的初稿版本，现在以惊人的速度就能生成出来。

但之后进行的是，

「这里要这样改」 「这个空白稍微宽一点」 「只改这张图片」

这样的沟通，意外地从很久以前就没有改变。

只是制作的速度变快了，

人类进行确认，传达修正内容，然后再重新制作。

这部分仍然相当人性化。

所以最近，

不仅是AI本身，

AI与人类如何进行沟通交互

这样的机制也变得越来越重要。

Design Marker 是我们为此进行的实验之一。

目前，

我们正在尝试向 HTML 添加评论、附加图像、集成多个审查、按项目进行版本管理等功能。

我们还有很多想要实现的功能。

直接在截图上进行标记。

通过评论向 AI 请求修正。

改进版本之间的比较。

提升多人审查的易用性。

当然，还有身份验证、HTML 预览、数据管理等功能的安全性提升。

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

一开始，

""Slack 中的评论容易消失，我需要想想办法""

这只是一个抱着"大概就这样"的心态开发出来的小工具。

这样的话，不知不觉间，

开发本地应用，

没有被总裁使用，

Web化，

学习 Cloudflare，

为安全而烦恼，

向资深工程师咨询，

这让我们也开始思考如何与 AI 相处。

……我只是想做一个代码审查应用。没想到需要考虑的东西这么多。

但是，能够和AI一起把工作中的这些小不便变成现实，我觉得这是一个有趣的变化。

等安心地公开发布了，我想再次正式介绍Design Marker。

不过在那之前。

首先要努力让老板好好写评论（笑）。 不过话说回来，今天应该能喝到好酒了