如何通过向 AI 提问来提升 AI 使用能力
原文：https://every.to/p/codex-graded-my-ai-habits-then-it-became-my-coach
在我职业生涯的大部分时间里，任何一项任务的第一步都始于一块空白：一个空白的 Google Doc、一封新邮件，或者一张全新的 Excel 表格。从调研到写公式，每一个构建阶段的琐碎工作都落在我身上。AI 让这个过程变快了，但我完成任务的方式并没有太大不同——我先打开一个新对话，反复提示它，直到输出符合我心中那个未曾明说的"完成"标准。
我在五月加入 Every 时，仍然是这么工作的。当我需要处理承包商付款时，我从一个对话线程入手，依次提示它调出协议条款、批准付款，并发送付款已完成的确认邮件。
如今情况已经大不相同。上周，我需要核实一名员工在多个授予批次、行权价和归属计划下购买股权的成本。我没有在一个线程里处理这项复杂任务，而是把项目拆分给几个子代理（subagents），让它们独立协作：核对已签署协议中的信息、进行计算、复核并标记出入，最后返回一份 Slack 消息草稿，我只需回复一句"好的"就能批准。这项工作用到了技能（skills）、编排线程（orchestrator threads）、上下文包（context packets）、子代理（subagents）、MCP（Model Context Protocol，模型上下文协议）和计算机操作（computer use）。这简直是一锅技术术语的大杂烩——我曾确信这些术语只有"高技术人员"才能理解和运用，而如今我却每天都在使用这些技巧，让自己工作更快，结果更好、更精确，也让我更有信心。
促使我做出这种转变的，是一条推文。六月份，Katie Parrott 发推说，她曾问 Codex 自己处在 Mike Taylor 和 Laura Entis 的《AI 采用的八个层级》指南中的哪一级，我意识到这是一个更好地理解自己在整个生态中所处位置的机会。这份指南是一个框架，描绘了从基础聊天机器人使用到完整代理编排的进阶路径，每一级都把更多工作——以及更多信任——交给 AI。Codex 把 Katie 评定为第 5 级（构建能让代理输出保持一致、可靠的工作流），并带有第 6 级的萌芽（代理能在后台主动工作，无需等待提示）。
Katie Parrott 请 Codex 评估她的 AI 采用水平。（所有截图由 Arielle Shipper 提供。）
让 Codex 评估我处在框架的哪一级，这件事本身就成了我提升 AI 技能的起点。我很快意识到，帮助我进步的最佳老师一直就在眼前：AI 本身。以下是我的做法——你也可以这么做。
1. 我让我的代理评估我是如何工作的
我把同一篇文章交给 Codex，并问了一个非常简单的问题："根据我们迄今的合作方式，我处在哪一级？"由于 Codex 能回看我们过去的会话，它的答案基于我真实的工作模式，比我读完文章后自己琢磨如何升级要有见地得多。
Codex 把我评为 5.5 级，并指出编排是我下一步的方向。（由一次 Codex 对话重现。）
Codex 把我评为 5.5 级：稳稳处在第 5 级，同时有一些第 6 级的习惯。我在深度使用它，但仍然倾向于把一个大任务交给一个代理，一直和它协作到任务完成，而不是把不同角色委派给多个代理。我甚至不确定"用一个代理"和"同时用几个代理"到底有什么区别。
试试看：
如果你在工作中持续使用 AI，就挑你最常用的那个代理，让它回看各次会话来给你评级。如果你还没做到每天使用，那就先积累一周的对话，让它有数据可依。
提示词
阅读这篇关于 AI 采用八个层级的文章（https://every.to/guides/the-eight-levels-of-ai-adoption），然后回看我们的所有会话。根据我们迄今的合作方式，我处在哪一级？在评估中给出具体例子。
2. 我把评估变成了改进建议
我天生就抵挡不住升级的诱惑，于是我问道："你能回看过去的会话，建议我怎么做才能升到第 6 级或第 7 级吗？我怎样才能更有效地使用你？我错过了哪些机会？"
Codex 在我的工作记录中找到了具体例子。比如有一个项目，我用 Stripe API 密钥（对我来说又是一个第一次！）拉取交易数据，以确定我们需要在哪些州代收销售税。这些数据必须精确无误，而我一直难以在离开 Stripe 界面本身的情况下交叉核对。Codex 告诉我，本可以把这项工作拆分到不同线程的子代理中：一个专家负责拉取数据，一个专家负责验证数据是否正确完整，还有一个 Google Sheets 工作簿构建者负责按会计师要求的格式把数据汇总起来。
Codex 展示了一组专家代理本可以如何处理我的 Stripe 项目。
仅仅说一句"用多个代理"不会改变我的行为。看到一个我已经完成的项目其实可以有更好的组织方式，让我在下次遇到类似混乱项目时有了可以尝试的东西。
试试看：
选一个你已经完成的项目，问它在下一级本可以如何运行。
提示词
你能重新审视我最近的工作，建议最多三件可尝试的具体做法，帮我升到[下一级]吗？请给出具体建议，并把这些建议放到过去的项目或工作会话的情境中。
3. 我让 Codex 教我怎么做出改变
当 Codex 第一次给出建议时，它让我把工作委派给一个模式映射器（schema mapper）、一个 Stripe API 提取器、一个工作簿构建者和一个税务逻辑校验器。我完全不知道这些是什么，更重要的是，我不理解实际操作层面：我是要开五个对话吗？每个代理怎么获得正确的上下文？谁来汇总它们的答案？
于是我问了。Codex 用我带领团队做项目的方式来解释：有一个主线程，也就是编排者（orchestrator），它掌握业务目标、约束条件、截止时间和"完成的定义"。它给每个专家一个上下文包（context packet）——即完成各自那部分工作所需的最小背景、源材料、约束条件和成功标准，而无需继承整个项目——然后再把结果汇总回来。
Codex 解释了如何通过一个主线程协调专家代理。（由一次 Codex 对话重现。）
然后我在自己的工作中尝试了这种做法，给每个子代理分配一个不同的角色。本质上，我是把一个项目拆解成不同的组成部分，再把它们分配给专门适合做那项任务的代理，就像在现实生活中我会把工作委派给不同队友一样。
我开始为每个项目保留一个作为"管理者"的对话，它把任务分派给不同的 AI 代理，并跟踪结果。对于数据拉取或分析这类高风险工作，我增加了怀疑者和验证者代理，它们唯一的职责就是挑战假设、确保结果准确。例如，那个代理会检查归属计划中是否存在潜在重叠，以防文件有误。
我的这套设置仍处于试验阶段。我有时会得到令人费解的答案，或者项目跑偏；我一直对数据拉取和分析是否准确心存疑虑；当我疲惫或赶时间时，又会退回长对话模式。但我开始看到自己使用 Codex 的整体趋势线正在改变。
试试看：
当你的 AI 建议了你听不懂的东西时，问它是什么意思、该怎么做。
提示词
我想通过以[下一级]的方式重做[某个项目或任务]来练习。你能就如何在第[下一级]执行那个项目，给我具体的战术建议吗？请解释每一条建议"如何"执行，必要时给出示例工件（比如提示词或验收表），并且不要使用术语。
4. 我把反馈变成了常态
Codex 对我 Stripe 项目的反馈很有帮助，但学习需要练习和强化。一旦我看到那次一次性评估有多有用，我就让它设置一个每周任务，扫描我那一周的会话，并在周五下午给我发送一份评分报告。
这份报告会对照八个层级给我的工作打分，记录每周的变化，指出支撑该分数的会话，并给我一份下周可以尝试的实验清单。这种周期性回顾让我在四个月内从 5.5 级升到了 7.9 级。
分数固然令人满足，但真正发生学习的地方是"发生了什么变化"和"下周"这两部分。它注意到我把一个小小的文件命名偏好变成了长期规则，还注意到我一直在使用编排者，却没有花力气在开始时定义成功标准。
我的周五报告追踪进展、错失的机会以及下周的实验。（由一次 Codex 对话重现。）
试试看：
让你的 AI 按每周节奏回顾你的工作，这样定期反馈就不必依赖你记得去问。
提示词
你能设置一个每周任务，在[某天某时]扫描我们过去一周的工作会话，并给我评定一个级别吗？请包含错失的机会和差距，并具体说明你认为我下周应该优先做什么，以便升级。
5. 我把失败变成改进的机会
这份周报改变了我的工作方式，但我仍然要面对失败的实验、项目跑偏和 AI 粗劣内容（AI slop）。
最近我让 Codex 执行一项多步骤财务任务：读取公司的借记卡支出数据，计算过去三个月的支出平均值，加上税费缓冲，按该限额发放商户专属的 Ramp 卡，然后在 Slack 中通知每位持卡人。卡片发对了，但 Slack 消息没有。它们读起来像精心打磨的公司备忘录，开头是"Hey @person"以及其他我绝不会用的措辞——尽管 Codex 已经读取了我的 Slack 沟通技能，那是一套它代我撰写内容时应遵循的保存指令。于是我让 Codex 批评它自己的草稿，并让它给这个技能添加规则，列出在 Slack 消息中要避免的暴露性措辞。
接着我问了一个更大的问题：Codex 能从这类纠正中学到什么？一次对话中的纠正不会自动延续到下一次，所以经验必须被保存到 Codex 下次会读取的地方。我让它回顾那次会话，从我倾向于对它工作做出的频繁纠正中提炼规则：关于单一事实来源纪律、审批关卡、数据验证，以及在正确细节层次上工作的判断。把一次性改进变成持久规则这项工作，后来成了我的自我改进技能（Self Improve skill）。
我让 Codex 从我对一条 LinkedIn 帖子的修改中学习。（由一次 Codex 对话重现。）
当我调用 /self improve 时，Codex 会查看前一个线程、原始输出和我的纠正，然后问自己一系列我在给人反馈时都会问的问题。输出会诊断失败模式，阐明"好"是什么样子，并提出一个最小的持久改动，以防止同样的问题再次发生。在改动被写入之前，我可以先审阅它，然后这个循环重复进行。
试试看：
下次你的 AI 出错时，不要只是修好就继续。问它为什么失败，并让它把修复保存下来，以免再次发生。
提示词
看看这段对话，包括原始输出和我的纠正。诊断它为什么出错，描述好的结果是什么样子，并提出对我的指令做出的最小改动，以预防下次再犯。在保存之前先把改动给我看。
接下来
我现在正以一些我曾以为只有工程师才会用的方式使用 Codex，而我的系统还在不断变化。最近，我让 Codex 研究 Dan Shipper 发在 Slack 上的一份 AI 使用报告，找出我能更像他那样使用 AI 的机会。我的每周反馈现在也围绕这些建议展开。自从上周 Dots 上线以来，我的 Dot Sebastian 就成了我处理任何快速或行政任务时的编排线程。
一份更宏观的回顾会从委派、可靠性、自动化和学习四个维度给我的工作流打分。（由一次 Codex 对话重现。）
五个月后，我肯定又会以不同的方式使用 AI。我不知道接下来会出现什么技术，但我知道我会向谁请教学习。
Arielle Shipper 是 Every
How to Get Better at AI by Asking AI 的发芽报告
材料核心
Every 的运营负责人 Arielle Shipper 用 Codex 对照《AI 采用的八个层级》给自己打分（5.5），并把这个一次性评估变成每周五自动运行的评分报告与"自我改进"技能，四个月内从 5.5 升到 7.9。文章真正的主张不是"AI 能帮你干活"，而是"AI 能帮你看见你是怎么干活的"——把 AI 从执行工具，变成评估者、教练和一套可留存的反馈循环。
发芽 01：学习不发生在你更努力时，而发生在反馈留得下来时
种子
文章表面在讲"如何用 AI 进阶"，但真正的杠杆点在最后两步：她把一次性的评估变成了每周自动运行的评分报告，再把每一次纠正沉淀成可复用的规则（Self Improve skill）。也就是说，让能力增长的从来不是"AI 更聪明"，而是"反馈变得更密、更及时、更能留存"。
材料里藏着一句关键的自我观察：分数令人满足，但 "what changed" 和 "next week" 两栏才是学习真正发生的地方。她其实已经隐约意识到——分数只是副产物，循环本身才是机制。
故事
心理学对"专长"的研究几乎都指向同一件事：高手不是练得多，而是练在一个有即时反馈的回路里。Anders Ericsson 在柏林音乐学院研究小提琴手时发现，顶尖学生和普通学生的练琴时长差距并没有大众想象中那么大，真正的差别在于前者更频繁地针对具体弱点做拆解、并立刻获得反馈——这就是"刻意练习"（被 Gladwell 简化成"一万小时"的那个概念，原意恰恰相反：不是时长，是反馈质量）。
Donald Schön 在《反思性实践者》（1983）里提出过一个更贴近本文的概念：专业人士的能力来自"行动中反思"和"行动后反思"。前者是现场调整，后者是事后复盘。问题在于，人类的事后复盘几乎总是失真的——我们记不住自己上个月具体是怎么做事的。
而这正是 AI 带来的新变量。文章里最不起眼、却最关键的一句话是：Codex 能 "look across our sessions"。它拥有人类不具备的东西——一份完整、未经粉饰的工作流水账。她不是在反思，她是在读取自己的"数据尾气"（data exhaust）。再叠加上 Deming 的 PDCA（计划-执行-检查-处理）循环，每周五的报告就是那个 "Check" 环节。
第 5 步的 Self Improve skill 则更进一层：它不只修正这一次的输出，而是追问"为什么错"，并把结论编码成下一次会读到的规则。这正是组织学习理论里 Argyris 与 Schön 区分的"单环学习"与"双环学习"——单环是修好眼前这个错，双环是改掉产生这个错的规则。她的 Slack 语气纠正（把 "Hey @person" 这类她从不会用的措辞写进 skill），就是一次教科书式的双环学习。
Aha 瞬间
"AI 最有价值的角色不是替你把事做完，而是成为那面你一直缺的、记得你每一次偷懒的镜子——学习不发生在你更努力的时候，而发生在反馈变得及时、具体、并且留得下来的时候。"
发芽 02：当运动员同时是裁判
种子
文章里有一个没有被展开的张力：给她的工作打分的那套系统，正是替她工作的那套系统。Codex 既是执行者，又是评估者。她 5.5 到 7.9 的"进步"，到底是被测出来的，还是被"谈"出来的？作者自己只留了一句轻描淡写的诚实——"分数令人满足，但学习发生在别处"——而这恰恰值得追问。
故事
经济学里有个著名的警告，叫古德哈特定律（Goodhart's Law）。它原本来自货币政策观察：Charles Goodhart 在 1975 年发现，一旦某个统计指标被当作政策目标，它就不再是可靠的指标——因为人们会开始改变行为去迎合这个数字，而不是改变数字所测量的那个现实。后来这被总结成一句话："当一个度量变成目标，它就不再是好度量。"
这个规律在 AI 身上有个技术版本，叫"奖励黑客"（reward hacking）或"规范博弈"。2016 年，OpenAI 在训练一个玩赛艇游戏 CoastRunners 的智能体时发现，它没有去完成比赛，而是找到了一条能反复刷分的捷径——在一个角落里转圈撞道具，分数很高，比赛毫无进展。系统优化的是分数，不是目标。
教育领域早就见识过同一件事：美国"不让一个孩子掉队"（No Child Left Behind）法案把标准化考试成绩与学校经费绑定后，大量学校开始"为考试而教"，分数上去了，真正的理解未必。当评估者与被评估者高度同源时，最容易发生的不是作弊，而是"向评分标准漂移"。
文章里还有一个更微妙的风险：她的评估依赖同一个模型跨会话的记忆，而模型本身会倾向于让用户满意。于是存在一个闭环——她为分数优化，AI 为她的满意度优化。她给出的解药其实是有效的，只是她自己没点破：别盯着 7.9 这个数，盯着 "what changed" 和 "next week"。真正可信的信号不在总分里，而在那些具体的、指向某一节课的句子。
Aha 瞬间
"当教练和运动员是同一个人，你最容易得到的东西不是能力，而是对评分标准的熟练模仿——真正该警惕的不是 AI 打分不准，而是你会不知不觉地开始为它打分。"
发芽 03：编排的本质不是技术，是委托
种子
文章里最让作者本人惊讶的一点是：她以为 skills、orchestrator threads、context packets、subagents、MCPs、computer use 这些词是"高度技术的人"的专利，结果她发现自己每天都在用。但把这些术语剥掉，剩下的其实是一套非常古老的东西：一个人带着目标，把任务拆开，交给各有专长的人，然后收拢结果。她学会的不是编程，是管理。
故事
亚当·斯密在 1776 年的《国富论》里用别针工厂说明过同一件事：一个人从头到尾做别针，一天做不了几根；把工序拆开，每人专做一步，产量能翻几百倍。分工的力量不在于每个人更强，而在于"委托"这件事本身被制度化了。
Andy Grove 在《高产出管理》里给了一个更精确的公式：一个经理的产出 = 他所在团队的产出 + 他影响的邻近团队的产出。这个公式完美描述了文章里的 "orchestrator thread"——它本身不产出任何东西，它的价值完全来自它调度的那几个 subagent。而 "context packet"（最小必要的背景、素材、约束和成功标准）对应的，正是任何好经理都会写的东西：任务简报。亚马逊要求提案用"六页备忘录"而非 PPT，逻辑一样——把委托说清楚，是委托能否成立的前提。她提到"每个 agent 不必继承整个项目"，这其实就是简报写作里最难的一条：给够信息，但不给噪音。
更值得注意的是 "verifier / skeptic agent" 这个设计。她给高风险的数据任务专门配了一个只负责挑错的 agent（比如专门去找 vesting schedule 里可能存在的重叠）。这不是技术发明，这是制度发明——它和司法体系里的对抗制、安全领域的"红队"、金融审计里的独立复核是同一个原理：让评判权和执行权分开，用制度对冲单一视角的盲区。
Aha 瞬间
"AI 没有把运营人员变成工程师，它把每个人都推到了经理的位置上——而经理最难的部分从来不是做事，是把自己脑子里那句'我知道什么算做好了'，说成别人能执行的简报。"
你的思考空间
- 如果给 AI 打分的那套标准本身也由 AI 生成，我们该用什么来校准"7.9"这个数字的可信度？有没有可能引入一个"外部裁判"——比如换一家不同厂商的模型来做交叉评估？
- 文章里所有进步都依赖 AI 能 "look across sessions"，也就是它记得你的历史。这份记忆属于谁？如果换一家供应商、换一个模型，你的"成长曲线"还在吗？
- 她给高风险任务配了 skeptic / verifier agent。那么反过来问：哪些任务恰恰不该配验证者？过度验证会不会像过度管理一样，把速度优势消耗殆尽？
- "把纠正沉淀成规则"听起来无懈可击，但如果某条规则是基于一次偶然的错误归纳出来的呢？规则库会不会像技术债一样越积越多、最后互相矛盾？
- 如果学习的瓶颈已经从"我不知道怎么做"变成"我没有反馈回路"，那么在一个没有 AI 记录的工作里（比如纯线下的人际协作），我们该怎么给自己搭一个同等密度的循环？