你可能也遇到过这种场景：脑子里已经有了一个相当清晰的产品/技术想法——比如「给内部平台写一个高性能的 Userscript，全屏重做一套更好用的任务控制台，支持持久化设置、复用现有 UI 风格、还要尽量不卡顿」——但真正开始动手时，却发现一件更难的事：

不是“怎么写代码”，而是“怎么把这件事讲清楚，让另一个 GPT 或 Agent 能接得住”。

你知道自己想要什么：要挂在哪个页面、要怎么改列表、要保存哪些配置、要兼容什么性能约束……但这些信息散落在脑子里、浏览器标签页里、cURL 里、甚至你对现有系统的隐性经验里。直接对 GPT 说一句“帮我写个脚本”，要么得到一段没上下文的 demo，要么来来回回补充细节，沟通成本很高。

这篇文章就是围绕这样一个真实 case 展开的：我希望 GPT 不仅帮我写代码，而是从一个模糊的 Userscript 想法开始，和我一起梳理需求、反向提问、收集必要信息，最后产出一份可以交给其他 GPT 复用的 Context Prompt 模板。下面是这整个过程的拆解与复盘。

1. 背景：不是“写代码”，而是“帮我把项目讲清楚”

这次的需求表面上是开发一个高性能、可持久化设置、带 full-page UI 的 Userscript，但真正难点不在代码，而在于：

  • 把散落在脑子里的设想，变成结构化的需求；
  • 把“我懂的网站上下文”转成“GPT 也能懂”的上下文；
  • 最终生成一份可以交给“另一个 GPT / Agent 复用”的 Context Prompt。

因此我刻意让 GPT 不急着写代码，而是先帮我梳理需求 → 挖问题 → 讨论方案 → 抽象成 Prompt 模板。

这篇就是把这个过程抽象成一套可复用的经验。

2. 第一步：先确认“输出物”是什么——不是脚本，而是一份 Prompt 模板

一上来我就明确跟 GPT 说：我最终要的是一份可以给其他 GPT 使用的 Context Prompt，而且要：

  • 支持填充 {PLACEHOLDER} 占位符，方便后续复用；
  • 包含“角色设定 + 目标 + 约束 + 需要用户补充的信息”。

这一步很关键，因为它：

  • 把 GPT 的“目标”从“立即写代码”切换到了“设计协作协议（Prompt）”；
  • 避免陷入“先写一堆实现细节、后面发现上下文没讲清楚”的浪费。

经验总结：

  • 只要是长期/复杂协作，最好先告诉 GPT：我们现在是在“设计说明书”，不是“写最终代码”。
  • 用一句话锁定最终产物形式，比如：“最终我们要得到一份可复用的 Context Prompt 模板”。

3. 第二步：利用 GPT 做“需求梳理器”，而不是“脑补器”

在明确了“要产出 Prompt 模板”之后，我进一步让 GPT：

  1. 拆解目标系统的结构：
    比如 Userscript 这个项目，GPT 自己就拆出了三层：
    • 挂载层（Userscript 壳）
    • 应用层（UI + 交互逻辑）
    • 数据层（设置持久化 + API 封装）
  2. 结合当前页面上下文给出可能的增强点：
    例如它根据 vivo 内部 AI 计算平台的训练任务列表结构，给出：
    • 自定义工具栏（快捷筛选、视图保存）
    • 列重排、状态高亮、统计视图
    • 全屏控制台 UI 的布局可能性
  3. 明确“你需要给我什么”的信息清单：
    包括：
    • 挂载点 DOM、URL 模式；
    • 预期功能的用户故事；
    • 接口的 cURL 与响应结构；
    • 持久化需求细节；
    • 性能与技术偏好。

这一步的关键是：让 GPT 反向告诉你它需要什么上下文，而不是你一个人硬想。

经验总结：

  • 刻意把 GPT 当成“项目的 Tech Lead”，让它给出“需要什么输入”，而不是只给“输出代码”。
  • 要求它按“模块 + 信息清单”的结构说话，你会得到一份天然适合作为 Context Prompt 骨架的东西。

4. 第三步：把“性能要求”前置，写进协作协议里

因为这个 Userscript 运行在生产内部平台页面上，我提前问 GPT：如果要性能高不卡顿，有哪些策略和 trick？

GPT 给出的重点包括：

  • 事件节流与防抖（scroll / resize / 输入过滤）；
  • 列表的分页/虚拟滚动；
  • 批量 DOM 操作、避免强制 reflow；
  • IndexedDB 的异步读写与配置缓存；
  • 统一的根容器 + 命名空间 CSS，减少对原站影响。

然后，我没有停在“知道这些就好”的层面，而是进一步要求：

在后面设计 Context Prompt 模板的时候，把这些性能策略写成“要求”和“约束”，让未来接手的 GPT 默认遵守。

经验总结：

  • 对于“非功能性需求”（性能、兼容性、可维护性），不要只让 GPT 提建议，而是要写回 Prompt，变成显式约束。
  • 这样同一个 Prompt 在不同模型间复用时，大家都会按同一标准来实现。

5. 第四步：让 GPT 总结出一份通用的 Context Prompt 模板

在前面的讨论之后，我再给 GPT 一个更 meta 的任务：

请你帮我把“如何跟 GPT 沟通这个项目，并逐步补信息、沟通方案、最终输出 Context Prompt”的过程，总结成一份可以给别的 GPT 用的 Context Prompt 模板，用 {PLACEHOLDER} 标记我需要后填的部分。

GPT 最终给出的模板，大致具备这些特点：

  1. 明确角色设定
    比如“资深前端工程师 + Userscript 专家”，能帮忙做架构设计、性能优化、模块化实现。

  2. 结构化章节
    模板会按如下章节组织：
    • 目标与场景
    • 现有页面结构与 CSS 复用
    • 功能需求（用户故事）
    • 后端接口与鉴权信息
    • 配置持久化与缓存设计
    • 性能优化约束
    • 技术栈与输出形式
    • 协作方式（分步迭代）
  3. 大量 {PLACEHOLDER} 占位符
    例如：
    • {TARGET_DOMAIN}, {TARGET_URL_PATTERN}, {PAGE_BUSINESS_DESC}
    • {CURL_LIST_REQUEST}, {PERSIST_VIEWS_SCHEMA}, {DEBOUNCE_SETTINGS} 等等。
  4. 明确“需要向用户继续提问的方向”
    通过这些 placeholder，其他 GPT 在使用时会自然地追问：
    • “请补充你的接口 cURL 示例”；
    • “请描述你希望的视图配置结构”；
    • “请说明你能接受的外部依赖策略”。

经验总结：

  • 一个好的 Context Prompt 模板，既是说明书，也是提问清单。
  • 用 {PLACEHOLDER} 强制你把“还没想清楚的东西”暴露出来，未来协作时就不会遗漏。

这篇文章的目的，就是帮未来的自己记住：
不要急着让 GPT 写代码，先让它帮你把“如何跟另一个 GPT 说清楚项目”这件事做对。