Ray Amjad · 20:32 · 发布 2026-07-05 · 2677次观看(截至抓取) · 观看原视频
主旨
博主参加 Code with Claude 东京活动、与 20 多位 Anthropic 员工交流后,整理出的一线工程师真实工作流碎片:没有统一最优解,只有各自并行的实验,以及围绕验证、审查、循环化的几条共性经验。
核心论点
- 没有”标准最优工作流”这回事——Anthropic 内部员工也是各自并行实验,谁都没有摸到唯一正确答案。(→ 详解1)
- 过度精细的前置 spec 撞上真实代码库常常会碎——不如给目标+约束、让模型自主判断如何应对偏差。(→ 详解2)
- 自动验证要发生在”用户实际遇到改动”的界面上(浏览器/API/终端),而不是只靠人工代码审查。(→ 详解3)
- 与其在计划阶段穷举边界情况,不如放行后用多轮自动代码审查兜底,校验成本后移反而覆盖得更全。(→ 详解4)
- 把发现问题、修复、验证、合并做成后台持续循环,人退居”决策界面”,只在关键节点表态。(→ 详解5)
- 模型越强,junior 与 senior 的差距不在提示词技巧,而在能否凭亲身经验判断模型输出何时”看似对但实则错”。(→ 详解6)
- 用一条高信号洞见作为新对话的第一条消息去”种”模型,能激发出比空谈泛问更有价值的变体,但要在上下文饱和前及时换新对话。(→ 详解7)
知识点详解
1. 没有完美工作流,只有并行实验 00:52
博主原以为 Anthropic 内部藏着某种”完美工作流”,去了才发现事实相反:员工形容自己”活在未来,但活在 4 种不同的未来里”,有人跑复杂多 agent 编排,有人就用 Claude CoWork,有人偏好朴素的终端操作,没人自称已经找到最优解。唯一算共识的做法,是把 reviewer agent 和 builder agent 分开以避免自我偏袒。
即便实验路径各异,所有会话仍会汇入一个中心系统做跨会话分析,团队借此观察共性模式;Slack 里也常有”帮我跑一下这条 prompt”式的即兴协作。博主由此建议把本地 Claude Code 的 cleanupPeriodDays 改大(默认 30 天会自动删除本地会话记录),以便自己也能积累更长时间跨度的Agent 记忆用于复盘。
2. Spec-first 撞上真实代码库会碎:地图不是疆域 03:49
博主观察到,尽管 OpenSpec、SpecKit、BMAD 这类 spec-driven development 框架层出不穷,他接触的 Anthropic 员工没人用这类框架。更常见的做法是:描述需求、定几条约束、让模型反问细节、出个设计草案,选定后进入 plan mode 执行,最后走一轮代码审查补漏。
博主把这总结为一条轴:spec 写得越面面俱到,本质上就越像”用英文写代码”,而理想状态应该只描述目标、划几条约束(如限流),剩下交给模型判断。一位 Anthropic 工程师提出的说法是”地图不是疆域”——如果 spec 定得过严,agent 在编辑代码库过程中一旦需要偏离 spec,被强行按原计划执行反而会更差。
紧接着博主做了个实测 05:31:删掉项目里的 CLAUDE.md、memory 文件和 skills,只给 Fable 5 裸描述需求,结果模型每次都能问出关键问题并一次做到约 95% 到位。他认为这提示”你三、六个月前依赖的脚手架,现在可能已经在限制模型发挥”,值得亲自用同一任务对比”带脚手架 vs 裸跑”来验证。
3. 验证环境:改动要在用户遇见它的地方验证 06:34
博主提到 Claude 桌面应用每次改动都会在云端容器里跑一遍桌面应用,用某种 computer use 自动验证改动确实生效。这启发他归纳出一条判断标准:用户到底是通过什么界面遇到这个改动的——浏览器就用 Cloud/Chrome 或 Playwright 跑一遍,API 改动就让 agent 实际发一次请求核对返回,终端改动就让 agent 驱动终端跑一遍。
据此,博主给自己的产品 AgentStack 建了一套自动验证:每个新 PR 落地后,Claude 会自动判断用户会从哪个界面遇到这次改动,并用浏览器录屏跑一遍验证(改了标题栏颜色、滚动效果是否符合预期),再把验证 GIF 发到对应 Slack 频道 06:50。他建议看具体技术栈选工具:自建 Playwright 远程服务器、用浏览器类 MCP,或 BrowserUse 之类的第三方服务,核心是要有录屏能力并能自动推送到 Slack。
4. 代码审查循环:把边界情况留到后面抓 09:48
博主的结论是,坚持 spec-first 常常在撞上真实代码库时碎掉,更好的做法是先有个模糊想法,让模型直接在真实代码库里探索、出 PR,再靠多轮代码审查去抓边界情况、不一致和意外问题。他自己惯用 Claude Code 内置的 /code-review 命令,大改动选 max 推理强度、小改动选 medium。
某个 PR 曾经历约 12-13 轮 Codex 代码审查的来回(他事后觉得该设个 blast radius 上限控制轮次)。他还专门让 Claude Code 回顾过往 PR、比较过 GrubTile、CodeRabbit 与 Codex 三种代码审查工具的实际价值,结论是 Codex 明显更有用。基于这套经验,他不再执着于让初始 prompt 或 plan 覆盖所有情况 11:47——只要代码审查开到高强度、跑够几轮,几乎能补上遗漏;如果发现改动方向本身错了,就直接丢弃 PR、换一个从架构层面修正的新方案,而不是在局部小修小补。
5. Loopify Everything:让循环自己跑,人只做决策 12:29
把”代码审查—修复”这轮反复动作视为一个循环之后,博主的思路变成:能把多少工作循环化(loopify)?他现在的常态是:一个循环持续跑代码审查、自动发现问题并建 issue;另一个循环把 issue backlog 自动分派处理,全程跑在 Hetzner 上的远程服务器,本地与远程互相制造 PR、来回改动、Claude headless 模式再做一轮代码审查 14:22。
他习惯保持 20-30 个 PR 同时在跑,按 Blast Radius(改动影响范围)从小到大自动合并,小改动很少需要人工审阅。Codex 的 Chronicle Research Preview 功能会定期截屏,自动从中提炼出新的可循环任务 14:42,例如结合 PostHog session replay 数据,自动发现近 3 天内的 rage click/报错会话并提出对应 UI 修改建议。博主给自己定的方向是:尽量搭建能持续产出待办、自动开 PR 的环境,把人的角色收窄成只在 Slack 上做决策的”决策界面”。
6. Junior 与 Senior 的分水岭:亲身经验 16:35
博主追问了几位 Anthropic 员工一个问题:既然内部用的是比 Fable、Mithras 更强的模型,junior 和 senior 工程师/研究员之间还能有多大差别?普遍回答是差距确实在缩小,但不是因为 senior 提示词写得更好,而是 senior 有更多亲身经验去判断”模型这次是不是有隐藏假设、结论其实站不住脚”,而 junior 更容易看模型输出”每一步都说得通”就直接放行。
被追问到模型继续变强之后会怎样时,受访者的回答是 junior 会先被替代,senior 最终也会被替代,因为模型将能自我改进 17:05;到那一步,他们打算靠 Anthropic 股权退休。这段对话的核心其实呼应了经验护城河:AI 知识面已经超过普通人,但缺乏第一手经历,人的经验优势体现在”读出模型输出哪里不对”而非”写出更好的提示词”。
7. Seed Thinking:用一条高信号洞见激活模型 17:48
博主分享了自己生成新想法的习惯:把一条高信号洞见(自己想到的、在推文/视频里看到的、或书里读到的)作为一次全新对话的第一条消息发给模型,这条洞见相当于把模型”种”进某种状态,类似 Minecraft 里的种子决定了地图下藏着多少钻石。之后他会追问”这条洞见有什么延伸含义,给我 30 种变体”,与模型来回讨论。
他强调这个过程更像开老虎机:多数变体是垃圾,但偶尔会冒出比原始洞见更深、能点出某种元层面模式的”隐藏宝石”,挑出好坏依然要靠人的亲身经验。同时他发现对话进行到约 5-6 万 token 后,模型生成新想法的”魔力”会明显衰退 18:29,这时应该开新对话而不是继续往已有对话里塞新洞见 18:39,以免被旧内容污染。这与Context Rot描述的现象一致:上下文塞得越满,模型表现越容易劣化。
可执行步骤
- 把本地 Claude Code 的
settings.json里cleanupPeriodDays改成较大的数值,避免会话记录 30 天后被自动清空,方便日后复盘长期模式。 - 对某个正在做的功能,同时跑一版”带 CLAUDE.md/skills 的常规流程”和一版”删掉脚手架、只裸描述需求”的流程,对比两者结果差异。
- 给自己的项目按”用户在哪个界面遇到这次改动”分类(浏览器/API/终端),分别配一套自动验证(Playwright、API 调用脚本、终端 agent),并把验证记录自动推送到固定渠道。
- 遇到较大改动时用
/code-review选 max 推理强度跑至少 2-3 轮,直到没有新的审查意见再合并。 - 挑一条最近让自己印象深刻的洞见,单独开一个新对话把它作为第一条消息发给模型,追问其延伸含义与变体,观察对话进行到多少 token 后开始”失灵”。
关联
- 印证:Context Rot——本视频 seed thinking 到 5-6 万 token 后饱和、须换新对话,与”上下文塞入过多信息导致模型表现下降”是同一现象的不同措辞。
- 印证:Harness——验证环境、审查循环、loopify 三件事本质都是在搭建围绕 agent 的规则/workflow/可观测性集合,即 Harness 的具体落地。
- 印证:forward-goal——loopify everything 里”人只设目标与约束、循环自主推进到终态”的做法,与 forward/goal 模式高度一致。
- 张力:PRD——PRD 笔记强调长周期定制项目要靠前置 PRD 决定能走多远;本视频则主张短周期迭代改动里,过细的前置 spec 反而受限,更适合模糊起点+多轮代码审查兜底,二者适用场景(长周期定制 vs 短周期迭代)不同,并非直接矛盾。
术语
- Fable 5(视频里对 Anthropic 某个新版本模型的代称)
- Codex(OpenAI 的编码 agent,本视频里被用作代码审查工具)
- Chronicle Research Preview(Codex 的一项个性化功能,定期截屏辅助发现可自动化的待办)
- headless mode(无头模式,不经交互界面直接以命令行方式调用模型)
- session replay(会话回放,记录用户在页面上的操作轨迹用于分析)
金句
“everyone at Anthropic is living in the future, but in like 4 different futures” → 没人真正摸到”标准答案”,大家都在各自实验,这本身就是最诚实的现状描述。 “the map is not the territory” → 一句话点破 spec-first 的根本局限:计划终究不是现实,过度依赖计划反而在偏差出现时更脆弱。
立场与利益
博主是知识付费博主,视频中段明确插入 4th of July 促销:自家 agentic coding 课程与新出的 Loopy AI 课程打折(终身版 7 折、首次团队/企业版也有折扣),并强调课程里有独家的”一键跳转 Claude Code/Codex”按钮功能。视频中提到的多项技巧(验证环境、code review loop、seed thinking)均声称在其课程里有更详细讲解,存在把见闻包装成课程卖点的动机,内容本身的可验证性判断需与促销话术分开看待。
价值定位
本片价值在于提供了一手的、非结构化的 Anthropic 内部工作流碎片观察,适合已经在用 Claude Code 做实际项目、想校准自己工作流是否”过时”的从业者参考,尤其是”验证环境要对准用户接触点""审查循环替代前置详规""loopify 让人退居决策界面”这几条具体可迁移的做法。但内容本身是博主转述的零散见闻加个人实践,没有系统方法论或数据支撑,且穿插较多自我推销,更适合当作认知补充和待验证的假设,而非直接照搬的操作手册。
自检问题
- 视频里那句”地图不是疆域”具体指什么问题? 答案:指前置 spec 定得过严时,agent 在编辑真实代码库过程中一旦需要偏离 spec 会被强行按原计划执行,导致结果比信任模型临场判断更差(→ 详解2)。04:47
- 博主认为”验证环境”该按什么标准来设计? 答案:按用户实际接触这次改动的界面来设计——浏览器改动用 Playwright/Cloud+Chrome 验证,API 改动用 agent 实际发请求核对,终端改动用 agent 驱动终端跑一遍(→ 详解3)。06:50
- 为什么博主不再执着于让初始 prompt 或 plan 覆盖所有情况? 答案:因为只要代码审查(/code-review)开到高强度、跑够几轮,几乎能补上所有遗漏的边界情况,把校验成本后移比前置穷举更有效率(→ 详解4)。11:47
- 视频认为随着模型变强,junior 和 senior 工程师的真实差距体现在哪? 答案:不在提示词技巧,而在 senior 有更多亲身经验去判断模型输出是否存在隐藏假设或错误结论,junior 更容易看到”每步都说得通”就直接放行(→ 详解6)。16:35
- Seed thinking 里为什么强调”不要把新洞见塞进已有对话”? 答案:因为对话进行到约 5-6 万 token 后模型生成新想法的能力会明显饱和退化,继续往旧对话里塞新洞见容易被已有内容污染,应开一个全新对话(→ 详解7)。18:39