他用 o1 Pro 写代码的方式太狠了：AI 不是帮你写，而是直接进仓库

大多数人还在把 ChatGPT 当“高级代码补全”，Mckay Wrigley 已经把 o1 Pro 变成了真实项目里的协作者。从提示工程、Repo Prompt 到 Cursor 的 apply 流程，这套工作流的核心不是更聪明的模型，而是让 AI 的代码“立刻可用”。

真正反直觉的地方：问题不在模型，而在你怎么接住它

视频一上来就抛出一个很反常识的结论：o1 Pro 再强，如果你只是让它“生成一段代码”，那它的价值会被浪费掉。Mckay 展示的不是某个惊艳的算法，而是一整套把模型输出快速落地的流程。

他明确区分了两种用法：一种是把 ChatGPT 当灵感来源，复制几段代码、自己慢慢改；另一种是把模型当成项目的一部分，让它在理解完整仓库上下文的前提下，直接产出“可以 apply 的改动”。o1 Pro 的优势不只是推理更强，而是当上下文足够清晰时，它更少胡来、更像一个谨慎的高级工程师。

这也是视频标题里“insane”的真正含义：不是模型多神，而是你一旦搭好接收系统，AI 写的代码能以接近实时的速度进入生产路径。

一个看似普通的需求，为什么能测出工作流的上限

Mckay 选的示例非常“无聊”：在一个 Supabase + Postgres 的 to-do 应用里，加一个 sub-todos 功能。没有炫技，没有新框架，甚至是每个全栈开发都写过的需求。

但正是这种需求，最容易暴露 AI 工作流的问题：
- 数据库 schema 要不要改？
- 前端状态怎么嵌套？
- 删除、更新这种边界行为会不会炸？

他没有急着让 o1 Pro 写代码，而是先在 Repo Prompt 里把整个项目结构、约束条件、已有模式交代清楚。这个细节很关键：模型不是在“猜你在干嘛”，而是在一个接近真实工程环境的上下文中工作。

结果是，o1 Pro 给出的方案不是零散片段，而是一套能贯穿前后端的实现思路。这也是为什么他反复强调：PRo mode 和普通 o1 的差别，在这种跨文件、跨层级的改动中会被明显放大。

三条“默认开启”的提示，比模型升级更值钱

视频里一个容易被忽略、但极其值钱的细节：Mckay 有三条几乎“每个请求都会用”的存储提示（stored prompts）。内容不复杂，但作用非常明确——统一模型的行为边界。

其中最重要的一条，是他专门为 o1 准备的格式约定（他称之为 o1 format）。核心目标只有一个：让模型的输出，天然适合被 apply，而不是被人肉整理。

这背后其实是一种提示工程的转变：
- 不是“如何让模型更聪明”
- 而是“如何让模型更守规矩”

当你希望 AI 的代码直接进入仓库，稳定性、可预测性远比灵光一闪重要。这也是为什么他反复强调：这些提示是通用的、基础的，但一定要“始终开启”。

最后一公里：为什么 Cursor 才是这套流程的终点

很多人用 AI 写代码，卡在最后一步：代码生成得不错，但真正合进去要花大量人工检查。Mckay 的解决方式，是把 Cursor 作为最后的执行层。

在 Cursor 里，他不是逐行复制粘贴，而是直接 review 和 apply o1 Pro 给出的改动。当出现 sub-todos 的 bug（比如删除逻辑问题）时，也是在同一套上下文里继续修，而不是重新开一个“解释为什么不对”的对话。

这一步看似只是工具选择，实际上是角色切换：
- 你不再是写代码的人
- 而是代码审查者和决策者

当 AI 负责“产出”，人负责“判断”，整个开发节奏会发生质变。这也是视频后半段最重要、但最少被讨论的价值所在。

总结

这条视频真正值得 AI 从业者反复看的，不是 o1 Pro 本身，而是一种新的开发分工方式：模型负责在清晰约束下给出完整方案，人类负责定义上下文和把关质量。

如果你今天就想行动，有三件事可以立刻做：第一，别再裸聊代码，学会用 Repo Prompt 给模型完整上下文；第二，固定几条“永远开启”的行为提示，让输出更可控；第三，把 AI 的终点放在能直接 apply 的工具里，而不是聊天窗口。

一个值得思考的问题是：当这种工作流成为常态，我们到底是在“用 AI 写代码”，还是在训练自己，成为更好的技术编辑和架构判断者？

关键词： o1 Pro， ChatGPT， 提示工程， 代码生成， Cursor

事实核查备注： 需要核查：1）视频发布时间是否为 2024-12-08；2）o1 Pro 是否为视频中明确选择的模式名称；3）示例项目是否基于 Supabase + Postgres；4）是否明确使用 Cursor 作为 apply 工具。