汽车人 AI 进化论 · 第 09 期
从 Ultrathink Goal
AI Coding 工程化的一年
缪东旭 MiaoDX
prelude · proof of work
这不是旁观者视角
公司内部 project、自己的开源项目、CI、OpenClaw，都在真实消耗这些模型；长程任务也已经开始交给 agent 跑
claude code
主力长 session
Max 20x / all models 接近打满，很多 lecture 和项目改动都从这里起步
codex
/goal、review、CI
不是只做 demo，而是在真实 repo 里让 Codex 扛住目标、检查和收尾
kimi / mimo
国产与私有模型池
内部 only 项目不一定能用 SaaS frontier model，但仍然要尽量用可 access 的最好模型
openclaw
Slack 里的 agent 工程
GSD / WLB / 状态汇报不是孤立技巧，而是协作入口的一部分
open source
开源项目持续迭代
自己的工具链、deck、实验项目都在持续被 agent 辅助 refactor
long run
/goal + hybrid-phase-pipeline
展示的是目标命令加自建 skill 可以承接真正的长程任务
这页不要讲太久。目的不是炫耀 token，而是建立资格：内部项目、开源、CI、OpenClaw、长程任务都在跑，后面的判断来自真实消耗和踩坑。
§ 0
# Karpathy 的困境开场。给观众扔一个困境：Karpathy 一边说自己每天都在 manifest，一边又说自己从没这么跟不上。今天不把它讲成情绪，而是讲成工程问题：如果一切都是 skill issue，那 skill 的边界是谁在推?
section/0 · 双证据
同一个人，两个信号
No Priors · manifest
Code's not even the right verb anymore.
I have to
express my will to my agents for 16 hours a day.
Manifest.
X post · behind
I've never felt this much behind as a programmer.
The profession is being dramatically refactored.
动词改了。Karpathy 没说"写代码"，说的是 manifest——把意图具现化给 agent。不是写代码，而是召唤/驱动一组 agent 去执行意图。另一边，他又说自己从没这么跟不上。今天就解释这个困境：工具越强，人越容易变成系统瓶颈。
section/0 · AI psychosis
AI psychosis 在工程里长什么样
this is why it gets to the psychosis is that this is like
infinite and everything is skill issue.
best practice drift
最佳实践追不上，昨天刚学会的 workflow 今天就被产品内建或废掉
infinite budget feeling
token 似乎用不完，任务总还能继续 refactor、继续 polish、继续开分支
moving tools
MCP、skills、subagents、/goal、routines 快速变化，手册永远慢半拍
endless continuation
agent 总能再跑一个验证、再补一个资料源、再生成一个候选实现
exit problem
最难的不是生成，而是决定什么时候算完成、谁有资格说完成
engineering reading
这里不做医学定义，只讲工程体感：无限 action surface 遇到模糊 exit condition
我们不必再是 binding constraint ，但必须重新设计 harness
不要把 AI psychosis 当医学词展开。这里讲的是工程体感：生成成本接近零以后，事情没有自然停止点。你可以继续让它查、继续让它改、继续让它验证。于是真正的问题变成：谁定义 action surface，谁控制 information surface，谁给 exit condition。
§ 0.5
25.7pp
一个夸张的差距 —— 同模型，只是换了个 harness
harness = 模型外面那一圈：工具、上下文、权限、流程、验证机制
实证立柱。Karpathy 的 psychosis 不是孤立感受，是有数据的。这一节就拍出三组实证：25.7pp / 6× / 81.8%。这页只放 25.7pp，留个钩子，下一页才出全图。
section/0.5 · 数据立柱
25.7pp
same model · different harness
GPT-5.5 在 Cursor 87.2% vs Codex 61.5%
6×
cited across studies
Meta-Harness 论文 cite [46] 的跨研究发现27.5% → 37.6%
81.8%
different models · same harness
GPT-5.4 + Opus 4.6 在同一 harness 下都跑到同分
为什么同一个模型差这么多？因为 agent 只能调它能调的工具、看它能看到的上下文、在它被允许的验证机制里宣布完成
把三个数据点串起来念：同一个模型不同 harness 差 25 个百分点(Endor 真实 benchmark)；同 benchmark 跨研究有 6× 差距(Meta-Harness 论文 cite，不是它自己的实验数字 — 它自己的贡献是 27.5%→37.6%)；同 harness 让不同模型收敛到同分(ForgeCode 关键发现)。第三个最有意思 — 它说的是 harness 把不同模型的失败模式都 round 掉了。停一下，引到下页：今天不讲哪个模型最强，讲那 25 个百分点的工程化在哪里。
section/1 · 三轴入口
为什么从三件事讲
同一个模型，换一个 harness，表现可以完全不同。因为 harness 改的不是智商，而是行动面、信息面和退出条件。
Skill
agent 能调什么?
对应 action surface ：工具、命令、skills、routines，决定 agent 能把意图落实到哪些动作上。
Context
agent 看到了什么?
对应 information surface ：文件、历史、memory、subagent 隔离，决定模型靠什么作判断。
Verification
谁判定完成?
对应 exit condition ：rubric、grader、测试、proof pack，决定长程任务什么时候停止。
这三件事能解释为什么同模型、不同 harness，会出现巨大的结果差异
提前给观众三轴。Skill 不是能力泛称，而是 action surface。Context 不是越多越好，而是 information surface。Verification 是 exit condition。后面的 281 个版本，都用这三件事读。
section/1 · 主线
Claude Code 281 个版本 · 截至 2026-05-06
VIBE
0.2.x · 107 versions
SDD
1.0.x · 95 versions
HARNESS
2.x · 79 versions
ultrathink
0.2.44
auto compact
0.2.47
@import
0.2.107
plan mode
1.0.33
hooks
1.0.38
subagents
1.0.41
/todos
1.0.94
skills
2.0.20
subagents v2
2.0.30
routines
2.1.72
managed agents
2026-05-06
/goal
读这条时间线的方法：每到一个节点，只问三件事
它能调什么？
它看到了什么？
谁在判定完成？
把三段念出来：0.2 时代 vibe，三个维度都靠人；1.0 时代 SDD，plan mode 第一次被做进产品内部；2.x 时代 harness，三轴同时工程化。提醒听众：后面不按 release note 讲功能，而是每到一个节点只问三件事——agent 能调什么、看到了什么、谁在判定完成。指着右下方虚线那个 /goal —— OpenAI 同期也在做同样的事，Codex 0.128.0 把 agent loop 自身 bake 进 slash command。这条线上的 281 个 tick，每个都是这一年 Anthropic 工程师在重新定义 binding constraint。
§ 2
# Vibe 段0.2.x 时代 · Skill / Context / Verification 三个责任几乎全在人手里
section/2 · vibe
三个维度都由我们自己承担
SKILL
我们写 prompt
没有 skills，没有 MCP，prompt 就是工具调用的全部门面
CONTEXT
我们管上下文
auto compact (0.2.47) 是产品第一次帮一点忙，但仍然主要靠人剪
VERIFICATION
我们自己看输出
"先跑一下""手动改改"——人盯每一步
关键里程碑：ultrathink (0.2.44) 让模型多想一会；CLAUDE.md @import (0.2.107) 让上下文可以分文件、可以复用——但还是 prompt 风格，不是 skill / harness 风格
section/2 · vibe · 收束
这一段的核心体感
所有 prompt 都是一次性的 —— 一次没沉淀下来的任务约束，下一次还得重说
于是 0.2 时代社区里大家都在 hack —— 用 prompt 把后来的 SDD / 推理深度 / Context 雏形手工凑出来：
SDD 雏形
把 plan 写到文件
先让模型出 plan，写成 docs/plan.md 再让它照着实现 —— 把 plan 模式手工模拟出来
推理深度雏形
一直加 "ultrathink"
每个 prompt 末尾加 "ultrathink" 触发深度推理 —— 后来才被产品化进 /effort 命令
CONTEXT 雏形
@import + prompt 模板
CLAUDE.md @import 拼上下文，社区分享 prompt template —— 自己当 skill / context 的存储层
这一段最深的体感是：vibe 段我们自己在补后来会被产品内建的机制。Plan 没产品支持，就把 plan 写成 markdown 文件让 Claude 照做。Ultrathink 当时是隐藏关键词，没有 /effort 命令，每次都要手动加。Skill 没有产品形态，社区就互相分享 prompt template。这几件事 1.0.x 之后被产品化 —— plan 变成 plan mode，ultrathink 变成 /effort，prompt template 变成 skills。今天回头看，我们当时干的就是后来的 SDD / reasoning effort / Skill / Context 雏形。
§ 3
# SDD 段1.0.x 时代 · Plan 先被做进产品内部，但 skill / context / verification 还主要靠人
section/3 · sdd · 关键转折
"先想再写" 从 prompt 习惯变成产品按钮
1.0.33
Plan mode
先 think 后 act 变成显式 mode
1.0.38
Hooks
在生成边界注入约束 — 机械执行胜过文档
1.0.41
Subagent 雏形
独立 context 的子任务隔离
1.0.94
/todos
长任务的执行节奏被产品化
section/3 · sdd · 副线
OpenAI 同时间在做同样的事
Plan/Spec mode discussion #7355 · GitHub Copilot Plan mode · Cursor 的 plan-and-act
1.0.x 这一段最重要的事不是某个 feature——是 "先 plan 再 do" 这个工程习惯被产品化了
player
feature
when
form
Anthropic · Claude CodePlan mode (Shift+Tab × 2)
2026-01 · v1.0.33
显式 mode toggle · 已落地
OpenAI · CodexPlan/Spec mode
2026-Q1 · discussion #7355
RFC 阶段 → 后期实现
Cursor plan-and-act
2026-Q1
两阶段流程 · 内置
GitHub · CopilotPlan mode
2026-Q2
跟进 · IDE 内
不要把这页念成产品功能比对。重点是：四家在同一时间点做同一件事——把 "先 plan 再 do" 这个工程习惯产品化。这就是 binding constraint 被产品内建的明确信号——当四家独立团队同时把同一个 prompt 习惯做成 button，说明这个 pattern 已经稳定到值得 bake-in。
section/3 · sdd · 收束
但 SDD 不是终点
SDD 把 plan 这一件事工程化了；但 skill 、context 管理 、verification 仍然由人承担
2.x 时代会同时把这三件事做进 harness：agent 调什么、看什么、凭什么宣告完成
§ 4
## Harness 段2.x 时代 · 三个责任同时工程化：agent 调什么、看什么、凭什么宣告完成
section/4.1 · 三轴框架
当生成成本归零，瓶颈在三件事
"We view harness engineering as a subset of context engineering."
但 context 不是全部；harness 工程化在过去一年沿三条线收敛——
section/4.1 · 三轴总览
三轴看的是：责任如何转移
Skill
action surface
工具、命令、skills、routines：agent 被允许把意图转成哪些可执行动作。
Context
information surface
文件、memory、subagent、compact：agent 看见哪些高信号 token，以及哪些噪音被隔离。
Verification
exit condition
rubric、tests、grader、proof pack：谁决定任务已经达到质量标准，可以停止。
共同模式：人手动承担 → harness 显式化 → 产品内建
接下来三页分别拆开看：prompt 怎么变成可调用能力、context 怎么变成高信号 token、完成判断怎么独立出来
section/4.1 · 三轴落地
三轴在 2026 的产品里长什么样
抽象的 action / information / exit 三个 surface，过去一年都被钉在了一个具体的产品形态上——下面三个就是它们今天最容易看见的样子。
Skill
action surface · 一条 /goal 命令
Codex 0.128.0 把整套 ralph loop 烤进一条 slash command。从用户视角是“说目标”，从 harness 视角是 skill / planner / loop / continuation 一起被产品化。
γ-friendly：以前要自己拼一堆 prompt，现在一个命令
Context
information surface · subagent fresh 200K
每个 subagent 起一段干净的上下文，不背主线的噪音。最戏剧的演化：从被动 transcript → 隔离 context → 5-6 Dreaming idle 时离线蒸馏 pattern。
γ-friendly：不是塞更多，而是开一个新房间专门干这件事
Verification
exit condition · Anthropic Outcomes
rubric 加独立 grader agent 取代“agent 自评”。docx +8.4% / pptx +10.1% / task +10pp 都来自这套机制——下一页的数字就是它出的。
γ-friendly：写作业的同学和改作业的老师必须是两个人
每个 anchor 都是一年前还要我们自己拼的“工程动作”，今天变成了一个产品入口——这就是“被悄悄接走”的样子。
这一页是给 γ 听众的“下脚点”。前一页三轴还停在抽象名词，这页把它们各自钉到一个看得见的产品上：/goal 是一条命令、subagent 是开新窗口、Outcomes 是“写作业 vs 改作业分两人”。α 听众也得到一组锚点，方便后面 5.x 我自己实践时回照。停一拍后再翻 Skill 轴的演进图。
section/4.2 · skill 轴
Skill 轴：prompt 变成可调用能力
这条线不是“prompt 写得更长”，而是把稳定动作包装成 agent 可以发现、加载、调用、调度的能力。
2025 · MCP
工具暴露出来
MCP 把外部能力接到 agent，但早期经常把工具说明全部塞进 system prompt。
2025-10 · Skills
能力按需加载
Claude Skills 把说明、脚本、模板和资产打包，让 agent 在需要时再读。
2026-02 · Codex Skills
跨产品跟进
同一个 pattern 进入 Codex：任务经验不再散在 prompt 里，而是进入可安装能力。
2026 · Routines
能力可被调度
routine 把固定职责和触发节奏也封装进去：不是问一次，而是长期运行。
Routines are higher-order prompts.
section/4.2 · context 轴
Context 轴：不是越多越好，是高信号 token
从被动缓冲 → 手动裁剪 → 隔离/持久化 → 离线蒸馏；目标不是塞满窗口，而是提高每个 token 的命中率。
Context is a critical but finite resource for AI agents. Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.
0.2.107
CLAUDE.md @import
人手动剪上下文
1.0.41
subagent 隔离
独立 200K context · 不污染主线
1.0.x
claude-progress.txt
长 session 自动持久化
2026-05-06 →
Dreaming (preview)
idle 时复盘 session 提取 pattern 进 memory
反直觉点：更长上下文不是自动更强；高信号 context 才能减少 agent 在噪音里自信地走偏
section/4.2 · verification 轴 · 为什么
Verification 轴：完成判断必须独立出来
不是“多看一眼”，而是把判断标准、判断角色、判断证据从生成过程里拆出来。
You will get higher success if you give that output to a fresh Claude and say, 'what bugs do you see?'
— Anthropic 工程师 Albert @ Code w/ Claude 2026 keynote ·
source
fresh grader 减少自评偏乐观
生成者最容易 rationalize 自己的输出，独立检查能把问题重新 surface 出来。
rubric 把质量标准写清楚
“看起来不错”变成可检查条目，agent 和人才能对齐完成条件。
结构化 artifact 更适合被检查
docx / pptx 这类对象有结构、约束和可见结果，适合独立 grader 逐项判断。
这一页只讲“为什么完成判断要独立出来”，三个 reason 各停一拍。下一页再讲 Outcomes 的 loop 和数字——先把“为什么不能自评”讲清楚，再讲“进入迭代后为什么会提升最终交付质量”。
section/4.2 · verification 轴 · 数据
独立 grader 提升的是最终交付质量
因为它把“生成 → 检查 → 指出 gap → 修改 → 再检查”做成 loop，而不是让 agent 自己写完自己宣布完成。
+10pp
task success vs standard prompting
+8.4%
docx generation quality
+10.1%
pptx generation quality
核心不是 grader 魔法，而是 generate-grade-revise loop：grader 在独立 context 里按 rubric 找 gap，反馈回 agent 再迭代。越是“硬题”——长程目标、结构化交付物——越不能让 first draft 直接过线。
这页要先澄清：grader 不会让 first draft 突然变聪明，它提升的是 final deliverable quality。Outcomes 把 artifact 交给独立 grader，grader 按 rubric 指出 gap，反馈给 agent 再改下一版。然后再给数字：+10pp 是 task success（最难的题抬升最大），+8.4% / +10.1% 是 docx / pptx 生成质量。最后接到 roboharness：proof pack 也是不让长程任务靠“我完成了”直接过线。
section/4.3 · 社区在做同样的事
不只是 Anthropic / OpenAI / Cursor
mattpocock/skills · GSD / gstack · Superpowers · Awesome Claude Code：社区也在把工程习惯做成 harness
The most common failure mode in software development is misalignment.
Software engineering fundamentals matter more than ever.
SKILL LIBRARY
mattpocock/skills
把 Pragmatic Programmer / DDD / TDD / APOSD 翻成可调用 skills：先对齐，再实现
SDD PIPELINE
GSD / gstack
把 spec → research → plan → execute → ship 做成 slash command；每段 fresh context / subagent 隔离
QUALITY GATE
Superpowers
把 TDD、review、plan discipline 做成默认流程；不是 advice，而是 agent 必须穿过的门
PATTERN INDEX
Awesome Claude Code
把分散的 CLAUDE.md、hooks、MCP、subagent 模式收集起来；社区在沉淀 reusable harness components
共同点：不是 prompt trick 越写越长，而是把稳定工程习惯封装成可复用入口、流程和质量门
section/4 · 收束
三轴收束
每一轴都经历同一个动作：人手动承担 → harness 显式化 → 产品内建
下一段：这套框架在我自己的项目里怎么落地
§ 5
# 我的实践不是工具推荐，而是三个真实场景里 binding constraint 被移走的方式
section/5.1 · roboharness · 叙事页
roboharness · 长 unattended run 的 review 工程化
移走的是 Verification bottleneck——agent 跑 4 小时改机器人代码，人不该一帧帧看完整过程；做的是把 review 从“盯过程”换成“审证据包”。
long unattended agent run
→
one proof pack → short human review
review path： 看 Run Decision banner → 只看 surfaced case → 用 phase_manifest 决定是否重跑
关键变化： 人不再验证完整过程，而是验证一个证据包——review bottleneck 从“盯 4 小时”变成“5 分钟做决策”。
1 · INPUT
contract.yml
声明这次 run 必须满足的不变量，避免 review 时重新猜目标
2 · DURING RUN
phase_manifest
每个 phase 的 input / output / 决策点都被保留下来
3 · AFTER RUN
approval_report
grader agent 只 surface 需要人看的 case，而不是整段执行日志
4 · HUMAN REVIEW
report.html
先看 Run Decision banner，再看 surfaced cases，最后决定 merge / rerun · 5 min
这页只讲“proof pack 的 4 步是什么 + 它换了 review 的什么”。下一页才用真实截图证明它长什么样。讲法：先指右边 4 张卡走一遍 pipeline，最后回到左边红字收束（4h→5min）。停一拍翻下一页。
section/5.1 · roboharness · 实证页
proof pack 长什么样：G1 humanoid run 的真实输出
不是手绘示意——下面这组就是从 examples/g1_cross_framework_report.py 跑出来的 proof surface，原样进 report.html。
phase: pre_grasp
phase: contact
phase: grasp
phase: lift
项目自己的轨迹
这页是 P28a 的实证。GIF 是 README 头图：G1 humanoid 同一个 run 的 Meshcat 和 MuJoCo 跨 framework 比较，phase 名留在每帧上——这就是 proof pack 让人 5 分钟就能横扫的原因。右边 4 个 mujoco 抓取阶段是 baseline phase 帧的样子，证明每个 phase 都有 visual artifact。底部那行带出下一页的"同一项目走过两段"叙事。
section/5.2 · routine 多 agent · 实证
routine 多 agent · 云端 60 分流水线
移走的是调度和上下文切换 bottleneck——四个 routine 把工程团队角色封装成云端流水线，下面三张截图就是它真在跑的痕迹。
主力
auto_pr
每小时一个 issue；三态自评 FULLY / PARTIAL / DIMINISHING
辅助 1
issue_label
每天排优先级，只读 + 打标签
辅助 3
daily_duty
CI 兜底 + 代码健康
label · issue_label routine 自动打 documentation / priority / enhancement 标签
PR · auto_pr 输出的 merged PR · 走 GitHub 标准协议，留下 Summary / Test plan
这页给 cards 加上了视觉证据。讲法：先念 4 张 cards 的角色名，停一拍，再往下指三张截图：cron 真的每小时跑、PR 真的产出、配额真的在被消耗。这页解决一个常见怀疑：“云端 agent 听起来玄，到底是不是真在干活”。
section/5.2 · routine · 三轴定位 + Brockman
routine 跨 Skill 轴 + Context 轴 + Verification 轴
同一个 routine 同时落到三条轴上——下面架构图说"它怎么连"，右侧 4 行 fact 说"它各自负责什么"。
Skill axis
auto_pr / issue_label / pr_again / daily_duty 不再是 prompt，而是工程团队角色的可调用封装
Context axis
每个 routine 以 fresh context 开始，失败也隔离在自己的分支、comment 和下一轮接手协议里
Verification axis
三态自评（FULLY / PARTIAL / DIMINISHING）把 exit 条件写清楚——PARTIAL 不是失败，是云端流水线对自己边界的诚实声明
Boundary
60 分钟不是能力上限，是任务拆分和工具匹配的边界
"[The Codex app] is really two things in one. It's a general agent harness that can use tools, and it's also an agent that knows how to write software."
— Greg Brockman · Big Technology Podcast · 2026-04-01 · bigtechnology.com —— OpenAI 总裁亲口把 harness 定义为产品一等概念
三轴定位页：架构图说 routine 怎么用 GitHub 当消息总线；右侧 4 行 fact 把 Skill / Context / Verification / Boundary 一次过完。Verification 一行的"三态自评"是关键创新，PARTIAL 不是失败而是诚实声明边界。底部 Brockman 一行作为外部背书一句念过即可。
section/5.2 → 5.3 · 交棒 · 同一项目走过的两段
cloud-first → 切回本地 ：roboharness 自己走过这条路不是两个独立工具的 routing，是同一项目在不同资源密度下被迫迁移 。一旦任务需要 GPU、真机、单次迭代 > 1h、或反复 trail-and-error——cloud routine 就该把活交出去，roboharness 这个 repo 就是这么被催生的。
维度
阶段 A · cloud routine（项目起步期）
阶段 B · 切回本地（roboharness 期）
资源
CPU、网络、API quota——配额范围内可调度
GPU、真机、本地 dataset、特殊运行时——非云端 worker 能 reach
单次迭代时长
≤ 60 min ，配 fresh 200K context 跑完一轮
> 1h 单轮，往往要连跑几轮 trail-and-error
失败模态
FULLY / PARTIAL / DIMINISHING 三态自评，PARTIAL 由人接
用 contract / phase_manifest / approval_report 把试错过程沉淀成证据包
人审 surface
PR diff + GitHub comment——日常增量
report.html · Run Decision banner——压缩成 5 min 决策
交棒触发条件（实操判断）：任务需要 GPU/真机 、单次迭代 > 1h 、或预期要反复 trail-and-error ——满足任一条，就别指望 cloud routine 在 60 分内压住，直接 wrap 进 roboharness 的 proof pack 流程。
这页解决一个常见误会：routine 和 roboharness 不是新旧两代，是分别针对不同资源密度的两套 routing。stop-the-line 信号是“资源 + 时长 + 试错次数”——一旦其中任一条触发，60 分流水线就压不住，要换 long-run + proof pack。讲法：先念表头（cloud vs local），再走完 4 行维度，最后那行红字直接出口播。
section/5.3 · local 重 harness
"60 分" 是任务-工具匹配的边界
移走的是任务匹配 bottleneck：哪些活交给 routine，哪些活留给本地重 harness
SKILL 轴 + 对齐
mattpocock/skills
grill-me / grill-with-docs：让 AI 反问需求是否清晰
SKILL 轴 + 大 scope
GSD / gstack
plan-pipeline 跨多文件大改
VERIFICATION 轴 + 长 run
roboharness
proof pack 让 unattended 长跑可 review
section/5 · 收束
哪类活配哪种 harness——这本身就是工程判断
纵轴：验证风险 · 低 → 高
横轴：任务清晰度 · 模糊 → 清晰
risk / clarity
模糊
清晰
高验证风险
先规格化，再分 phase
GSD / gstack plan pipeline
需求还不稳，但错误成本高；先把目标、约束、验证标准写出来，再进入执行。
长程执行 + 证据包
/goal + hybrid-phase-pipeline + proof pack
任务清楚但验证风险高；让 agent 扛住长程目标，同时用 proof pack / roboharness 缩短 review。
低验证风险
先问清楚
grill-me / office-hours
风险不高但意图模糊；最便宜的动作是让 agent 反问，把想法压成可执行判断。
重复调度和固定职责
routines
任务清楚、风险可控；auto_pr / daily_duty 这类固定职责适合云端周期运行。
roboharness 不是单独象限，而是高验证风险任务里的 proof-pack 机制
§ 6
# 当下与未来bake-in 的极致 · 用户表面回到 vibe，底层工程化反而更重
section/6 · /goal · bake-in
/goal：agent loop 自身被 bake 进 slash command
不是替代 AGENTS.md / skills / permissions / subagents，而是把它们 wrap 成"我说目标"的入口
Skill axis
/goal <objective> 把“设目标、拆动作、继续推进”包装成一个可调用入口
Context axis
loop 状态不再靠人手动续写 prompt，而是由 runtime continuation 接住
Verification axis
Ralph loop++ 的核心不是多跑几轮，是每轮都带着 audit pressure 逼近完成
section/6 · caveat
bake-in 也会引入新失败模态
Anthropic 2026-04-23 quality post-mortem 是产品 bake-in 引发新失败模态的活教材
cause 1
reasoning effort 改 default
触发用户不可察觉的退化
cause 2
thinking-history 清理 bug
长 session 上下文被错误压缩
lesson
产品化 ≠ 终点
harness 接走的越多，反向出错的成本也越高
section/7 · 回到困境
everything is skill issue —— 但 skill issue 的边界在移动
仍需自己解
judgment
什么活配什么 harness、何时介入、何时放手
被产品消化
机制
plan / hooks / subagents / outcomes
被 skill 走
特定能力
skill 取代 prompt 的「再说一遍」
下次 agent 失败时，先别问"模型是不是不行"
我们不必再是 binding constraint
"or it's a skill issue, and we just haven't figured out how to use it. So, it's hard to tell." — Karpathy
§ 8
# Tips三件今晚就能做的实验：整理 harness、让 agent 反问、用最好模型跑真实任务
section/8 · slide 1 · 把环境装好
实验 1 · 把 harness 环境整理到最新
↪ TIP 3
·
但 model 也不能省 —— 待会儿 Tip 3 会接这条线
每天第一件事：升级所有工具 · claude --upgrade · codex · MCP servers · skills
tool kit
github.com/MiaoDX/claude-devkit
我整理的 daily-update 工具集
权限
clean workspace first
干净分支 / git / CI / secret 边界先到位，再减少审批 prompt
版本
落后两周先升级
很多失败不是 prompt 问题，是 harness 版本还停在旧默认里
section/8 · slide 2 · 试这些方法
实验 2 · 先让 agent 问你，再让它干
01
跑一次 grill-me
让 AI 先反问需求是否清晰；被盘问过一次，就很难再回到直接写 prompt
02
试一次 office-hours
用 YC 风格 forcing questions 把“我想做个东西”压成可执行判断
03
画图给它看
架构、流程、UI 草图直接截图丢进去；多模态输入比 200 字描述稳定得多
section/8 · slide 3 · 心态
实验 3 · 用你能 access 的最好模型跑真实任务
↩ TIP 1
·
harness 比 model 重要 —— 但 model 别成为新的 binding constraint
SaaS frontier model 可以用就直接用；内部 only 项目，就用私有部署的 top-tier 开源模型
这场 lecture 听完最容易的失败模式：回去想"我下周开始整这套"什么都不试
section/8 · bonus · 长程任务组合
最近好用的一个大杂烩：hybrid-phase-pipeline
把 GSD、gstack、mattpocock/skills 组合起来，再搭配 Codex 的 /goal，我最近用两三天，体感很适合长程任务
gsd
用 discuss / plan / execute / verify 把任务拆成可恢复的 phase
gstack + mattpocock
用 grill、office-hours、autoplan、review 类 skill 把需求和设计先压实
codex /goal
用一个持续目标把长程执行、反复检查和最终收尾串起来
这页放在 Tips 后面当 bonus，不展开成教程。口播重点：它不是一个全新的框架，而是把现有几个好用的东西粘成了一个长程任务方式，再用 /goal 扛住最终目标。
section/8 · coda · 这场 lecture 的准备
这场 lecture 的准备，也是同一套 workflow
云端先把方向跑出来，本地再用完整 repo context 做细节、证据和 QA。
cloud / phone
claude.ai 手机端先出初始版本
在路上先讨论题目、听众、主线和讲稿骨架，把模糊想法压成能继续推进的 draft。
local / repo
本地再做细节调整和验证
回到 repo 里处理截图、链接、版面、source caption、主题截图和质量检查；细节靠本地 harness 收口。
这也正是整场要讲的：云端负责快速 manifest，本地 harness 负责 context、verification 和最后一公里。
section/9 · Q&A
Q & A — discussion —
