不是作弊，是协作 —— Copilot 如何帮我还原 UI 页面结构

在实际开发中，我开始探索一种以语义注释为驱动、Copilot 协作构建 UI 的工作流。它不像在写代码，更像是在沟通页面结构。

我曾以为这是“作弊”

最近项目用的是 React + Next.js，由于我主力技术是 Vue，写起 React 来并不算完全顺手。

尤其是在拿到 UI 设计稿的时候，心里总会想：“这结构我大概知道怎么写，但懒得一个一个敲出来。”

于是我开始尝试一种写法：

1
2
3
4
5
{/* title center h1 */}
<h1>title here</h1>

{/* content card round bg-white shadow */}
<div>card title...</div>

写完这些注释之后，交给 Copilot edit 自动续写结构。

有时候 Copilot 会猜得很准，有时候它写出来的东西完全跑偏。但不管怎样，主导权始终在我手里。

一开始我也会觉得这样“很像作弊”。明明不是自己一行一行手写 JSX，而是靠着注释 + 自动补全写出来的结构，甚至会因为这点而感到内疚。

后来我和 ChatGPT 聊天时，它一句话点醒了我：

“你不是靠 Copilot，是你让它帮你实现得更快。”

那一刻我突然意识到，这根本不是“作弊”，这是协作。

我的开发流程是怎样的？

我最常做的，其实是边看设计稿边想清楚结构层级：

  • 哪些是区块？
  • 哪些是重复组件？
  • 哪些需要布局语义？

接着我会用注释写下来这些语义，然后再用最简结构写一遍草稿。

1
2
3
{/* 表单：左右结构，左侧文字，右侧输入框 */}
<label>用户名：</label>
<input type="text" />

在注释非常清晰的前提下，Copilot 就能理解我要的布局模式，然后自动补全 Tailwind 类名、基本结构，甚至嵌套关系。

当然，它不会百分百准确，所以我会手动改。但正因为有这一步结构预写，我的开发效率整体提高了不少。

👇 简化展示一下我常用的结构规划逻辑：

1
2
{/* Card-left flex-column border:purple-100 */}
<div className="flex flex-col border border-purple-100 rounded-lg p-4">...</div>

注释提示了结构+样式意图，Copilot 会补出完整 JSX，再微调即可。

在实际项目中，我是怎么做的？

我曾参与一个 AI 音频相关项目，负责前端页面的构建，使用 React + Next.js 技术栈，任务包括登录组件、后台部分页面、首页内容完善等。

项目采用 GitHub Issues + PR 的协作方式，我会按任务切分分支进行开发，每个页面都先由我注释规划结构，再交给 Copilot 续写，并根据实际效果再调整。

注释驱动 + JSX 构建的开发流程，在这个项目中极大提高了我搭建组件的速度。

但不是每个人都这样用 AI

说实话，我也遇到过一些人，张嘴闭嘴就是“这个 AI 一下就行了”，但他们写出来的东西不是 bug 连连，就是逻辑混乱。

我自己的习惯是：先梳理项目结构，拆分大纲，再从最小模块逐步构建。

而有些人却会张口来一句“你帮我做个什么什么系统”，问题模糊得没法下手——这种时候，AI 再强也搞不出来。

我曾经合作过某些队友，他们不仅没主导任务，还指望 Copilot 全自动写完需求，最后项目烂尾。

AI 是工具，但不是借口。它可以补代码，但不能代替思考；它能节省时间，但不能节省责任。

我对“面向 AI 开发”的态度

AI 工具像是一双帮我提速的跑鞋，但路线和目标还是我自己定的。

我愿意用 Copilot 甚至 ChatGPT 来加快开发流程，但我从不相信“完全 AI 即可交付”。

我希望自己成为的是：

“能清晰表达结构 + 驾驭工具协作 + 亲手完成交付”的开发者

我会让 AI 为我加速，但不会让它替我交差。

写给像我一样有点怀疑自己的开发者

你不是因为用 Copilot 就变弱了。

你是因为足够有责任感，才会想知道：我这样写是不是不算“正经的工程能力”？

但只要你能清楚知道自己在做什么、理解背后逻辑、能够落地项目，那你就不只是“会用 Copilot”，你是“知道如何把 Copilot 用得好”。

不要被那些“什么都 AI 搞一下”的人代表。

AI 是辅助，你才是核心。

这是我和 AI 的协作方式，也是在前端项目中，我给自己的一种温柔提效路径。