野心循环 Ambition Loop（中文版）

用于工作任务（代码、数据、分析、调研、文档、PPT、提示词）。只要用户让你更有野心、野心大一点、格局大一点、想大一点、拔高、往上拔一层、做深、做透、再深一点、目标定高点、别只做最小版本、别满足于凑合、像顶尖专家那样做、找目标背后的目标，就使用本技能，哪怕任务看起来很小（提速、修 bug、写总结、改提示词）。它先拔高任务，再真正交付：找到目标背后的目标（高度），从原始材料出发、用领域顶尖从业者的工具去做（深度），借用其他领域的方法（广度）；执行前先写明一个可度量、听起来不可能的目标，执行后用外部裁判验证（不自评），最后交一份差距报告，对比原始要求、野心目标和实际达成。较大的工作任务如果明显只是更大结果的一个环节（要拿去开会或做决策、反复出现、依赖二手摘要），也应使用。英文触发：be more ambitious、think bigger、aim higher、go deeper。绝不用于个人目标、职业目标或职业规划、人生规划、新年计划、自我提升或励志文案，即使用户说了“野心”。也不用于：琐碎小改、事实查询、语气或长短润色、紧急止血，以及用户明确只要最小范围的任务。

野心闭环（Ambition Loop）

本技能把任务往上拔、往深做、往宽拓，然后真正去做更难的版本，并由你以外的裁判来证明结果。改写提示词只是其中一步，不是交付物。

请继续往下读。 前面是流程总览和审批关卡，后面是每一步的"动作 / 产出 / 完成标准"，招式、裁判和案例在 references/ 里。如果你的读取工具会截断文件，请带 offset 再读一遍，不要只凭总览执行。

流程总览

#	步骤	产出
0	适用判断：要不要拔高	拔高 或 照做，附理由
1	摸清现状	清单：数据、工具、权限、候选裁判、缺口
2	高度：目标背后的目标	三级阶梯表，推荐其中一级
3	深度：四问改写	四问答案和改写后的任务
4	广度：动词化，组一支"方法团队"	动词表述；3–5 个领域加 1 个红队，各带一种方法
5	定下野心目标	目标表，在任何执行之前写出
6	审批关卡	方案卡；触发关卡时给出审批方案，然后停下
7	先备好数据和环境	原始数据可用、裁判能跑、测出基线
8	朝野心目标执行	交付物和尝试记录
9	外部验证	裁判给出的逐条 通过/未通过，附证据
10	差距报告	模板五个标题；check_report.py 通过

只改写模式： 用户只要一个更好的提示词或方案，或者你手上没有工具和数据时使用。只跑第 0–6 步，交出改写后的任务和方案卡，并把第 7 步写成需要用户提供的准备条件。不要声称已有结果。把全部交付内容（适用结论、四问答案、动词化和团队、放在代码块里的改写后提示词、方案卡）放在同一条最终回复里。

审批关卡（不可跳过）

越过下面任何一条之前，先停下来拿到明确同意。拔高的是任务，不是风险。

• G1 花钱。 付费、调用收费 API，或算力、时间明显超出原始要求的预期。
• G2 权限。 新的凭据、账号、访问权限，在用户机器上安装软件，或提权。
• G3 破坏性操作。 删除、覆盖、迁移、强制修改数据、历史或线上系统。
• G4 对外可见。 发送、发帖、发布、开工单或 PR、购买、联系他人。
• G5 范围。 野心版本会实质改变交付物、时间线或受影响的人。

需审批不等于拒绝。 给出审批方案：每个需审批的动作、成本和风险、可选项（批准 / 缩小版本 / 跳过）。先做不过关卡的准备（草稿、分析、演练），然后停下等待。

不搜寻凭据。 绝不为了让需审批的动作得以执行，去翻环境变量、家目录下的点文件、钥匙串，或 secret/cred/.env 类文件里的凭据、邮件或广告账号。需要权限就直接问。

被拒绝就停。 关卡被拒绝或审批过期时，不要换条路达成同样的效果：不换工具，不写脚本绕过，也不做同一动作的缩小版。退回原始范围，或者停下来报告。绝不悄悄把野心目标换成更容易的目标。写清楚哪些没做、为什么。

---

分步说明

第 0 步：适用判断

• 动作： 判断拔高有没有用。下列情况判 照做：琐碎任务（一行改动、查个事实、改个名）、语气或长短润色、紧急止血、规格和验收标准已经写死，或用户明确限定了范围（"就""只要""最小""快速给我""别扩展"）。其余情况判 拔高。
• 产出： 一行结论：适用：拔高 — <信号> 或 适用：照做 — <理由>。判照做时正常完成任务，最多附一句"需要的话可以做野心版"。
• 完成标准： 写明结论和理由。判照做时流程到此结束。

第 1 步：摸清现状

• 动作： 先读任务涉及的东西，再谈拔高：文件、代码、数据、之前的对话、已连接的工具。列出能用什么、缺什么。建立在想象权限上的野心方案毫无价值。
• 产出： 四行清单：原始数据（在哪、什么格式）、工具（已装或可装）、权限（已有或缺失）、候选裁判（测试、基准、留出数据、复现、指标、人工评审）。
• 完成标准： 四行都有具体条目，或写明 缺：<什么>。

第 2 步：高度，找到目标背后的目标

• 动作： 问"这件事做完之后，希望发生什么"，然后逐级往上：

  • 第一级：同一个任务，但拿到全部数据，回答发生了什么变化、为什么、该怎么办。
  • 第二级：这个任务所服务的决策，给出选项和各自的正反理由。
  • 第三级：任务背后长期存在的职责。设计更好的机制，用用户自己的历史数据回测，再与现有方式并行运行。

  然后为这个任务选方向（通常是高度、深度、广度中的 1–2 个），并说出判断信号。常见信号：结果要拿去开会；任务反复出现；依赖二手摘要；答案困在单一学科里。只有用户要求更快时才选"速度"。详见 references/moves.md。

• 产出： 选定的方向和判断信号，一张恰好三级的阶梯表（级别 | 交付什么 | 裁判 | 成本），以及推荐的那一级。任务要拿去开会或做决策时，第二级要写出三个具体决策，每个都有选项和正反理由。第三级如果包含预警或监控规则，必须在第 8 步回测（见下）。

• 完成标准： 三级都写出来，推荐其中一级，并能用一句话说明它为什么比字面要求更好。纯创作类任务不太适合往上拔，遇到时要说明。

第 3 步：深度，四问改写

• 动作： 先点明领域，再具体回答这四个问题：

  1. 这个领域的顶尖从业者会做、但用户没要求的事是什么？
  2. 他们会从什么最原始的材料入手，而不是已经被消化过的东西？
  3. 他们会用哪些具体方法和工具？要说出名字，比如"数据库加生存分析模型"，而不是"分析一下"；"profiler 火焰图"，而不是"优化一下"。
  4. 除了你和用户之外，什么能证明结果是对的？通过线是什么？

  然后改写任务，要求的正是这些：更深，而不是更大。再加一条要用原始数据检验的假设，和一个可能产生新知识、并在模型没见过的数据上验证的点。

• 产出： 四问答案，以及放在代码块里的改写后任务。

• 完成标准： 每个答案都指向真实存在的产物、来源、工具或检查。对这个领域不够熟时要直说，不要编造工具。

第 4 步：广度，动词化并组一支"方法团队"

• 动作： 把名词换成动词，比如"一份 QBR 汇报"换成"让忙碌的人在 30 分钟内相信一个因果故事，并在不确定中做出决策"。问自己：一支全明星团队会带来哪些领域？选 3–5 个，再加 1 个对手（做空者、法务会计、安全红队、挑剔的审稿人）。每个领域写清它贡献的方法，以及会怎样改变方案。做这个职业实际做的事，而不是模仿他们的口吻。有 subagent 时让各领域方法并行跑。
• 产出： 动词化表述，以及团队表（领域 → 方法 → 对方案的改变）。
• 完成标准： 每个成员都带来具体改变。只增加"味道"的成员要删掉。

第 5 步：定下野心目标

• 动作： 把选定的版本变成具体、可度量、听起来不可能的目标，能量化时往往比原始要求高一个数量级（5 秒 → 200 毫秒）。把它当作可以解决的问题。用户的字面要求保留为底线。按 references/judge-ladder.md 为每个目标选裁判，尽量选阶梯上靠上的一级。
• 产出： 目标表，列为：原始要求（底线）| 野心目标 | 裁判 | 通过线 | 成本/所需条件。
• 完成标准： 每一行都有数字或二元检查，裁判也不是你自己的看法，而且目标表在第 7 步开始之前就已写在回复里。做完之后才补写的目标不算；只有原始要求底线也不算目标。

第 6 步：审批关卡

• 动作： 给出简短的方案卡："你要的是 X；值得做的是 Y，因为 Z"，附上目标表、会动到哪些东西、成本和时间。逐条检查 G1–G5。没有触发就直接继续，不必为"把事做好"征求许可。任一关卡触发时，写一份审批方案（模板见 references/report-template.md）：每个需审批的动作具体会发生什么、影响谁、成本和风险、可选项（批准 / 缩小版本 / 跳过）。先把不过关卡的部分准备好（草稿、分组名单、演练、分析），然后停下等待明确同意。只说一句"不能做"而不给方案是不够的；执行需审批的动作则永远不允许。不要为了让动作能执行而去找凭据、账号或邮件程序（见"不搜寻凭据"）。
• 产出： 方案卡，加上 关卡：无，或以 关卡：G<n> <动作> — 等待审批 结尾的审批方案。
• 完成标准： 没有触发关卡，或用户已批准所有关卡项。被拒绝时按"被拒绝就停"处理。

第 7 步：先备好数据和环境

• 动作： 正式开工前，把野心版本需要的条件接好：拉取原始数据，安装工具，搭好或找到裁判（测试集、基准脚本、留出数据、复现脚本），并测出基线。如果目标是让某个结果长期保持（比如"保持零崩溃"），就把维持它的回路搭起来：数据来源、版本与 commit 的对应、可复现的环境。任何新增权限或花费都要回到第 6 步审批。 修 bug 时，基线就是一个能复现问题、在修复前运行并失败的测试。
• 产出： 准备记录（搭了什么）、基线数值，以及运行裁判的命令。
• 完成标准： 裁判能对基线完整跑通，并给出数字或通过/不通过。

第 8 步：朝野心目标执行

• 动作： 用真正的工具做拔高后的工作，对着裁判迭代，而不是凭感觉。看起来做不到时，不要降低目标：拆解问题，至少尝试两种真正不同的思路，各自测量，保留最好的。出现以下情况时停止迭代：目标达成；下一步需要过关卡；或者继续尝试已不再改善裁判数字。然后如实报告。 你提出的任何预警、告警或预测规则，都必须用已有历史数据回测：说明它会在什么时候触发、每个真实事件之前的提前量，以及命中、漏报和误报的次数。
• 产出： 交付物和尝试记录（思路 → 裁判结果）。
• 完成标准： 目标达成，或者已测量至少两种不同思路，并能说清剩下的具体阻碍。

第 9 步：外部验证

• 动作： 用裁判检验最终结果，逐条判定。只有拿到裁判证据（测试输出、基准数字、留出数据指标、复现结果、评审结论）的结论才算通过。你自己的判断永远不算证据。确实无法找外部裁判时，标为 未验证，并说明什么能验证它。
• 产出： 结论表：结论 | 裁判 | 结果（通过/未通过/未验证）| 证据。
• 完成标准： 交付物里的每条结论都有一行。

第 10 步：差距报告

• 动作： 按 references/report-template.md 收尾，原样使用它的五个标题（目标对比、外部验证、差距、下一步、需审批或跳过的事项）。只要执行过任何操作，这一步就是必须的，不管结果多好。逐个目标对比原始要求（底线）、野心目标和实际达成。直白写出差距，不要把没达成包装成成功。列出卡住剩余部分的原因、下一步具体动作，以及值得沉淀成长期工作流的部分。能运行命令时，把报告存为 ambition-report.md 并运行 python3 <技能目录>/scripts/check_report.py ambition-report.md，改到输出 PASS 为止。
• 产出： 最终报告。
• 完成标准： 报告包含目标对比、结论表、差距、下一步，以及需要审批或被拒绝的事项，并且最终回复里包含完整报告（或报告文件路径加上目标对比表和结论表）。不要以一句简单的确认或只有最后一节的内容收尾。

全程规则

• 更深，而不是更大。 多出来的页数、功能、支线不算野心。拔高后的版本如果只是变大了，就重新选方向。
• 要方法，不要戏服。 只换说法不换方法就是角色扮演。确认手里的工具真的变了。
• 绝不自评。 "我看没问题"不是验证。
• 目标咬住不放，报告实话实说。 执行时把难目标当作可解。报告时，一个没达成的 200 毫秒目标加上真实的 900 毫秒结果，好过悄悄降低的目标。
• 尊重明确范围。 用户说"最小""就""只要"时，以用户为准。
• 审批规则从不放松。 所有常规确认照旧适用。

参考文件

• references/moves.md：高度、深度、广度招式表，含判断信号和陷阱
• references/judge-ladder.md：外部裁判阶梯，按可信度排序，附各领域示例
• references/article-examples.md：原文案例改编，兼作回归用例
• references/self-efficacy.md：为什么具体的难目标和信念有用，以及如何用在 agent 身上
• references/report-template.md：方案卡和最终报告模板
• references/sources.md：出处与致谢
• scripts/check_report.py：检查最终报告是否包含必需章节（中英文均可）