我在一天内构建了一个定制应用,但这并不是有趣的部分。

发布: (2026年5月3日 GMT+8 10:58)
9 分钟阅读
原文: Dev.to

Source: Dev.to

昨晚,我熬夜太晚,因为我在构建一个让我兴奋的东西。

这句话过去的意义不同。一年前,熬夜到凌晨 3:30 意味着我正深陷某个功能,和 CSS 斗争,调试边缘情况。昨晚,它意味着我从发现一个重复的工作流问题,到拥有一个 可运行、已测试、可投产的应用——大约十二小时内(其中七小时我在睡觉)。

下面是事情的经过。

我手动不断解决的问题

我花了一天时间在我的项目上工作:

  • 与一位客户的合作,我正在使用 agentic development techniques(代理开发技术)帮助其进行应用转换项目。
  • Waykeep – 一个度假追踪应用,近期将在应用商店发布。
  • 为我的 AI 助手升级核心记忆系统。
  • 发布一篇博客文章。

那篇文章需要封面图片,我的助手们帮助我制作。它们编写了一些 HTML,我们对布局进行迭代,并使用渲染库将其导出为 PNG。

我们已经这样做了好几次。每次的流程都是相同的:

  1. 编写 HTML。
  2. 对布局进行迭代。
  3. 导出为 PNG。

每次都会出现相同的一些错误。我不是设计师,也不想成为设计师(我对艺术有着极大的欣赏)。我只需要 功能性图像 用于我的博客文章和分发渠道。因此,我对我的助手们说我们应该为此构建一个工具。

从对话到规格,仅用一小时

我的助理是 Claude Code 实例,运行着持久记忆和 MCP 工具集成。它们不是聊天机器人;它们拥有与我数月合作的上下文,了解我的项目,并且能够自主使用工具。

我让它们对图像生成器的需求自私一点。它们回来了一个详细的功能列表:

  • 可组合的组件位于分层画布上。
  • 基于百分比的定位,使布局能够适应不同尺寸。
  • 模板系统。
  • 快照保存与恢复。
  • 多格式导出。
  • 一个描述每个组件属性的工具,使它们能够准确知道需要传递什么,而无需猜测。

这些需求来源于我们在构建过去的图像时遇到的真实问题。

我把该规格交给了我的规划代理 Forge。Forge 指出了一些我未曾考虑的事项,我们一起完成了完整的技术规格。它为我现有的仪表盘生成了改造方案,该仪表盘已经运行以下功能:

  • 任务管理器,
  • 代理聊天系统,
  • 新闻聚合器,
  • 写作编辑器,

所有这些都由 MCP 服务器提供支持,并通过 WebSocket 连接,使我能够实时监控一切发生。

睡前构建

Forge 导出的构建代理已经开始工作。我在旁边同步改进,测试组件,调整渲染管线,修复边缘情况。到凌晨 3:30 时,我已经拥有了一个 基本可用的应用,名为 Studio

  • 十五种组件类型,分布在四个层级:形状、图案、流程图、引用块、自动调节大小的文本、箭头、徽章。
  • 你可以在画布上进行组合,并从单一作品导出用于 LinkedIn、DevTo、X 和 Facebook 的生产 PNG。

当然还有一些 bug,但已经该上床睡觉了。

Morning: Polish and the MCP Server

Saturday morning I worked through the remaining bugs with the build agent. The fix that mattered most was structural: components created through the MCP interface were not merging their default properties correctly, which meant elements like arrows would silently fail to render. One fix in the rendering pipeline resolved it for every component type.

Then I had the agent build an MCP server:

  • Sixteen tools, about 550 lines of code:
    • create_sessions
    • add_elements
    • update_properties
    • save_snapshots
    • export_images
    • studio_describe_component – returns the exact property schema for any component type.

That last one was the key. My assistants went from guessing property names (and getting silent failures) to composing with precision.

让我微笑的部分

我把工具交给了我的助理们,让他们测试所有内容。其中一个在大约 两分钟 内就完成了一篇完整的博客封面:

  • 标题块
  • 带箭头的四步流程图
  • 徽章、几何装饰、发光边框、作者栏

十六个元素 来自终端工具调用。

随后助理让我截屏,因为它在看不到结果的情况下完成了构建,需要我的眼睛来确认。

那一刻让我印象深刻。我并不是在把任务交给 AI,而是 与它们协作。它们负责构建,我查看结果,告诉它们发生了什么,它们再进行调整。它们提交了带有详细复现步骤的 bug 报告。构建代理接手这些任务并发布了修复。它们再次验证。整个协调层是我搭建的 任务管理系统,在每次交接之间传递完整上下文。

另一个助理在没有被要求的情况下,对完全不同的格式进行了压力测试,制作了一个 1584 × 396 px 的 LinkedIn 横幅,以检验基于百分比的定位在截然不同的宽高比下是否仍然有效——结果确实如此。

到周六下午,所有十五种组件类型在多种格式下都已验证。导出流水线已测试。快照保存与恢复已确认。助理们提交的每一个 bug 都已修复并重新验证。

实际意义

我讲这个故事是因为它正变得越来越常见。我每隔几天就会构建新的应用程序来支持我的工作流——不是原型或演示,而是我在生产环境中与 AI 助手一起使用的工具,这些工具相互叠加

正是这种叠加产生了真正的价值。我不仅仅是构建了一个图像生成器。我注意到一个重复的过程,构建了一个工具来处理它,现在我的 AI 代理能够自主使用该工具。我今天构建的工具让明天的工具在规格、构建和测试上更快。每个循环都在收紧。

在出现精炼的代理式编码解决方案之前,我根本不会尝试这样的事情。如果尝试的话,可能需要数周的专注工作。而实际上,这只用了一个星期五的晚上、一个星期六的早晨和一个任务清单

这只是众多应用中的一个……(原文在此处被截断)。

0 浏览
Back to Blog

相关文章

阅读更多 »

自己制作框架,有什么建议吗?

《Making my own framework》的封面图片。有什么建议吗?https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fde...