摘要：我没有直接让 Gemini "帮我写个 Chrome 插件"，而是在开始之前，先在对话里初始化了几个虚拟团队角色：
PM（产品经理）：梳理功能边界和验收标准 UX：从交互体验角度提出设计建议 我从这次实验里得到的几个判断 1. AI 重塑的是工作流，不是替代判断力 Gemini 帮我收敛了需求，Replit 帮我生成了代码，但每一个"要不要做这个功能"的决定，都是我自己做的。
最近我完成了一件之前从没做过的事：从零开发一个 Chrome 插件，并提交到 Chrome Web Store。全程用了不到一天，没有查任何 Chrome 插件开发文档，没有写过一行 manifest.json。
manifest.json
但我想聊的不是"1天能做什么"，而是这个过程里我真正在做的那件事——用 AI 重新定义自己的工作方式。
起因很简单。长时间盯着屏幕，我需要一个提醒自己定时休息的工具。市面上有类似插件，但要么功能太多太重，要么 UI 丑得让我不想打开。
更重要的是，我想试试一件事：独立走完从想法到上架的完整闭环，看看 AI 工具能把这条路缩短到什么程度。
这两件事叠在一起，就有了这次实验。
这次我用了三个工具：Gemini、Replit、Cursor。它们不是随机组合，而是在开发过程中自然分工形成的角色。
Gemini → 需求收敛 + 方案设计 + 功能迭代 Replit → 在线开发 + 代码生成 + 运行调试 Cursor → 本地微调 UI 细节
这条链路的逻辑是：先把"做什么"想清楚，再让 AI 帮我实现，最后自己动手打磨感受。
说实话，这是整个过程里我花心思最多、也觉得最有价值的环节。
我没有直接让 Gemini "帮我写个 Chrome 插件"，而是在开始之前，先在对话里初始化了几个虚拟团队角色：
每当我提出一个新功能想法，这些"角色"会从各自的视角输出意见，帮我做出判断——这个功能该不该做，MVP 阶段应该砍掉什么。
举个例子，我最初想加"声音提醒 + 自定义铃声 + 多套提醒计划"。PM 角色立刻提问： "护眼插件的核心价值是提醒，还是声音体验？" QA 角色补充： "多计划的状态管理会引入不少复杂度，是否 MVP 阶段必要？"
最后我砍掉了这些，只保留：倒计时 + 视觉提醒 + 简单配置。
这个过程让我意识到，AI 不只是写代码的工具，它可以成为一个思维碰撞的空间。多角色的设定，实际上是在模拟真实团队里那种互相 push 的动态——只不过我一个人扮演了 PM 的决策角色，AI 提供了不同维度的输入。
确定好 MVP 范围之后，我把需求整理成一段清晰的 prompt，扔给 Replit 的 AI。
Replit 的优势在于环境即开发：代码写完直接在浏览器里跑，不需要配本地环境、不需要折腾 Node 版本。对于 Chrome 插件这种"结构相对固定、逻辑不太复杂"的项目，它的效率很高。
6 次对话调整之后，核心功能基本跑通了：
chrome.storage
整体来说，AI 生成的代码质量还可以接受，逻辑清晰，没有出现明显的运行时 bug。我做的更多是验证行为是否符合预期，以及提出"这里的交互不对，调整一下"之类的修正。
功能跑通之后，我把代码拉到本地，用 Cursor 做 UI 微调。
这部分是我自己主导的，AI 更多是辅助执行——比如"帮我把这个按钮的间距调整一下"、"这个颜色换成更柔和的护眼色调"。
有建筑学背景的我，对空间感和视觉比例还是有些执念的。这个阶段花的时间不长，但对我来说很重要——工具做出来的东西，最后需要人的审美去收口。
提交 Chrome Web Store 是整个流程里最出乎意料的环节。
原以为"提交个插件"很简单，实际上需要准备的东西比想象中多：
其中最费时间的是截图和 icon 的规格要求。Chrome Store 对图片的尺寸、格式有严格规定，我来来回回导出了好几次才搞定。
这些东西和代码质量没有关系，但它们是上架的必经之路。某种程度上，这也是"独立开发"真正的成本——不只是写代码的时间，还有那些"最后一公里"的琐碎工作。
目前插件已提交，等待审核中。
1. AI 重塑的是工作流，不是替代判断力
Gemini 帮我收敛了需求，Replit 帮我生成了代码，但每一个"要不要做这个功能"的决定，都是我自己做的。AI 提供了更多的输入维度，但我是那个拍板的人。
这个分工如果搞反了——让 AI 决策，自己只是执行——大概率会迷失在一堆不必要的功能里。
2. MVP 思维比技术深度更值钱
我完全没有 Chrome 插件开发经验，但这不重要。重要的是我想清楚了"这个插件最小可用版本是什么"，然后坚持只做那一部分。
技术可以通过工具弥补，但产品判断力需要自己建立。
3. 1 天上架不是终点，是验证闭环的开始
完成这件事给我的最大感受不是"我做了个插件"，而是"我验证了这条路是通的"。
从想法到上架，这个闭环我走通了一次。下一次可以更快，可以做更复杂的东西，可以在每个环节做得更好。第一次的价值不在于产品本身，在于建立了对整个流程的直觉。
4. 工具组合比单一工具更重要
Gemini、Replit、Cursor 单独拿出来都不稀奇，但把它们组合成一条有意识的流水线，效率是叠加的。选工具的能力，本身就是一种需要刻意培养的判断力。
诚实地说，这次实验也有一些让我不太满意的地方：
这些问题留着下一次迭代的时候再想。
这篇文章与其说是教程，不如说是一次工作方式实验的记录。
我没法保证这套流程适合所有人，也没法保证这个插件会有多少用户。但我确实在这一天里，把"想做一个东西"变成了"上架了一个东西"——这件事本身，比插件本身更值得记录。
如果你也有一个一直搁置的小工具想法，或许现在是一个很好的时机去跑通一次。工具的门槛已经低到不需要理由了。
暂无回复，快来抢沙发吧！
本次需消耗银元：
100
当前账户余额: 0 银元
PM（产品经理）：梳理功能边界和验收标准 UX：从交互体验角度提出设计建议 我从这次实验里得到的几个判断 1. AI 重塑的是工作流，不是替代判断力 Gemini 帮我收敛了需求，Replit 帮我生成了代码，但每一个"要不要做这个功能"的决定，都是我自己做的。
最近我完成了一件之前从没做过的事：从零开发一个 Chrome 插件，并提交到 Chrome Web Store。全程用了不到一天，没有查任何 Chrome 插件开发文档，没有写过一行
manifest.json。但我想聊的不是"1天能做什么"，而是这个过程里我真正在做的那件事——用 AI 重新定义自己的工作方式。
起点：一个很小的自用需求
起因很简单。长时间盯着屏幕，我需要一个提醒自己定时休息的工具。市面上有类似插件，但要么功能太多太重，要么 UI 丑得让我不想打开。
更重要的是，我想试试一件事：独立走完从想法到上架的完整闭环，看看 AI 工具能把这条路缩短到什么程度。
这两件事叠在一起，就有了这次实验。
工具链：三个工具，各司其职
这次我用了三个工具：Gemini、Replit、Cursor。它们不是随机组合，而是在开发过程中自然分工形成的角色。
Gemini → 需求收敛 + 方案设计 + 功能迭代 Replit → 在线开发 + 代码生成 + 运行调试 Cursor → 本地微调 UI 细节这条链路的逻辑是：先把"做什么"想清楚，再让 AI 帮我实现，最后自己动手打磨感受。
最有意思的部分：让 Gemini 扮演开发团队
说实话，这是整个过程里我花心思最多、也觉得最有价值的环节。
我没有直接让 Gemini "帮我写个 Chrome 插件"，而是在开始之前，先在对话里初始化了几个虚拟团队角色：
每当我提出一个新功能想法，这些"角色"会从各自的视角输出意见，帮我做出判断——这个功能该不该做，MVP 阶段应该砍掉什么。
举个例子，我最初想加"声音提醒 + 自定义铃声 + 多套提醒计划"。PM 角色立刻提问： "护眼插件的核心价值是提醒，还是声音体验？" QA 角色补充： "多计划的状态管理会引入不少复杂度，是否 MVP 阶段必要？"
最后我砍掉了这些，只保留：倒计时 + 视觉提醒 + 简单配置。
这个过程让我意识到，AI 不只是写代码的工具，它可以成为一个思维碰撞的空间。多角色的设定，实际上是在模拟真实团队里那种互相 push 的动态——只不过我一个人扮演了 PM 的决策角色，AI 提供了不同维度的输入。
Replit：让"在线写代码"成为可能
确定好 MVP 范围之后，我把需求整理成一段清晰的 prompt，扔给 Replit 的 AI。
Replit 的优势在于环境即开发：代码写完直接在浏览器里跑，不需要配本地环境、不需要折腾 Node 版本。对于 Chrome 插件这种"结构相对固定、逻辑不太复杂"的项目，它的效率很高。
6 次对话调整之后，核心功能基本跑通了：
manifest.json权限配置chrome.storage）整体来说，AI 生成的代码质量还可以接受，逻辑清晰，没有出现明显的运行时 bug。我做的更多是验证行为是否符合预期，以及提出"这里的交互不对，调整一下"之类的修正。
Cursor：把"能用"变成"好用"
功能跑通之后，我把代码拉到本地，用 Cursor 做 UI 微调。
这部分是我自己主导的，AI 更多是辅助执行——比如"帮我把这个按钮的间距调整一下"、"这个颜色换成更柔和的护眼色调"。
有建筑学背景的我，对空间感和视觉比例还是有些执念的。这个阶段花的时间不长，但对我来说很重要——工具做出来的东西，最后需要人的审美去收口。
上架：真正的障碍不是代码
提交 Chrome Web Store 是整个流程里最出乎意料的环节。
原以为"提交个插件"很简单，实际上需要准备的东西比想象中多：
其中最费时间的是截图和 icon 的规格要求。Chrome Store 对图片的尺寸、格式有严格规定，我来来回回导出了好几次才搞定。
这些东西和代码质量没有关系，但它们是上架的必经之路。某种程度上，这也是"独立开发"真正的成本——不只是写代码的时间，还有那些"最后一公里"的琐碎工作。
目前插件已提交，等待审核中。
我从这次实验里得到的几个判断
1. AI 重塑的是工作流，不是替代判断力
Gemini 帮我收敛了需求，Replit 帮我生成了代码，但每一个"要不要做这个功能"的决定，都是我自己做的。AI 提供了更多的输入维度，但我是那个拍板的人。
这个分工如果搞反了——让 AI 决策，自己只是执行——大概率会迷失在一堆不必要的功能里。
2. MVP 思维比技术深度更值钱
我完全没有 Chrome 插件开发经验，但这不重要。重要的是我想清楚了"这个插件最小可用版本是什么"，然后坚持只做那一部分。
技术可以通过工具弥补，但产品判断力需要自己建立。
3. 1 天上架不是终点，是验证闭环的开始
完成这件事给我的最大感受不是"我做了个插件"，而是"我验证了这条路是通的"。
从想法到上架，这个闭环我走通了一次。下一次可以更快，可以做更复杂的东西，可以在每个环节做得更好。第一次的价值不在于产品本身，在于建立了对整个流程的直觉。
4. 工具组合比单一工具更重要
Gemini、Replit、Cursor 单独拿出来都不稀奇，但把它们组合成一条有意识的流水线，效率是叠加的。选工具的能力，本身就是一种需要刻意培养的判断力。
还没解决的问题
诚实地说，这次实验也有一些让我不太满意的地方：
这些问题留着下一次迭代的时候再想。
小结
这篇文章与其说是教程，不如说是一次工作方式实验的记录。
我没法保证这套流程适合所有人，也没法保证这个插件会有多少用户。但我确实在这一天里，把"想做一个东西"变成了"上架了一个东西"——这件事本身，比插件本身更值得记录。
如果你也有一个一直搁置的小工具想法，或许现在是一个很好的时机去跑通一次。工具的门槛已经低到不需要理由了。
参考资料