实时协作与自动化
- 一三行大白话，换回一整份作业手册。 Idan Gazit（GitHub Next 负责人，GitHub 的实验室团队）像给团队里一个初级开发发 Slack 消息一样写了三行字——"每天看看有没有新版本、读 changelog（更新日志）和文档、想个升级方案出来、开个 PR"——Copilot 就把它展开成一份完整的 playbook（作业手册，即一步步该怎么干的流程稿），真的把他的个人网站从 Astro 5 跨两个大版本升到了 Astro 7：改好被升级弄坏的代码、跑构建验证、还把他自己必须动手的手工步骤单独标了出来。→ 详细
- 二这个自动化本体就是一份 Markdown 文档。 用他的话说，"就像 GitHub Actions 和 Copilot 生了个孩子，而这孩子跑在 Markdown 上"——Markdown 才是源代码，编译出来的 YAML 只是产物、你根本不用看；不满意它的行为，改英文就行。而文档顶部那段 YAML front matter 是放护栏的地方：护栏必须写成确定性规则，靠给 agent 写提示词求它守规矩，"基本上等于把狐狸放进鸡窝"。→ 详细
- 三AI 到目前为止只帮我们干了 5% 的活。 收尾金句：过去几年 AI 帮的是"打字"，但一项跟踪了约 100 名开发者、上千小时的纵向研究显示，手放在键盘上敲代码只占这份工作的 5%；剩下的 95%——"我想动的那个系统在哪儿？它今天是怎么跑起来的？别人怎么看它该不该改？"——才是接下来 AI 该管的地方。→ 详细
GitHub Next 是干什么的：探"明年的 GitHub"
最难的问题不是"怎么做"，是"什么值得做"
当下的持久主题：从"更多个我"到"一群人做更多事"
*▲ 图注：他这一季的主题就印在这一页上：multiply us, not me（放大「我们」，不是复制「我」）——agent 该做的不是给你造一堆分身，而是让一群人一起做成更多事。*软件业其实还处在"前工业时代"
"理解是瓶颈"的团队版：跑得越快，小错位越贵
切入点：他想要一个"会自己改代码的超级 Dependabot"
- 演示从他的个人网站开始（他自己说这是"契诃夫的枪"，后面还会用到）。网站用 Astro 这个 Web 框架搭的，而 Astro"最棒的一点是每个月能发布大概 50 个东西，这意味着我永远在升级的跑步机上跑"。→ 详细
- GitHub 有个产品叫 Dependabot（依赖机器人，专门盯着你项目引用的第三方库有没有出新版本、有没有安全漏洞，然后给你提个 PR 提醒）。问题在于它只管通知，升级时往往还得改代码，尤其遇到破坏性变更（新版本故意改掉了旧写法，不改代码就跑不起来）。→ 详细
- 所以他要的是"一个一直待在后台的超级 Dependabot，自动盯着我的依赖，自己琢磨怎么帮我升上去，包括那些代码改动、破坏性变更"。动机他说得很直白："因为我懒，我喜欢不干活。"→ 详细
【本期最值钱】三行 Slack 大白话，模型自己展开成完整 playbook
- 他怎么写的：最上面一行是"神奇的一行"——塞给 Copilot 一个 skill（一份告诉模型"这类东西该长什么样"的说明文档），内容大意是"帮我创建一个 agentic workflow，这份文档里写了你需要知道的一切"。注意这一层是元规格，讲的是格式和规矩，不是这次的具体任务。→ 详细
- 再往下的正文，用他自己的话说，"就很像我发给团队里某个初级开发的一条 Slack 消息：每天帮我看看有没有新版本发布，去读 changelog，去看文档，想一个升级方案出来，然后开一个 PR 把东西提上来，这儿是文档的链接。"——就这么长，没有参数、没有步骤编号、没有伪代码。→ 详细
- 展开结果：Copilot 生成的 playbook 里写着「升级检查器」和一串任务——第一步检查有没有新版本发布，因为它能看到代码库，自己推断出该去查哪些依赖，而且真的找到了那几个具体的依赖；然后是查 changelog 和升级指南、执行升级、最后创建 pull request。他强调："这些我一条都没有明说，但事实证明，Copilot 挺擅长把我那三行小消息挖出意思、扩写成一整份 playbook。"→ 详细
- 这里有个值得单独记住的分工："该干什么"用大白话说，"该查哪些具体东西"让模型自己从环境里读出来，只有"这类文档该长什么样"是他事先写死的。→ 详细
agentic workflow 的本体，就是一份 Markdown 文档
- 他给的定义比任何架构图都好记："agentic workflow 大致就长这样：它们看起来就是 Markdown 文档。就像 GitHub Actions 和 Copilot 生了个孩子，而这孩子跑在 Markdown 上。"（GitHub Actions 是 GitHub 自带的自动化流水线，平时用 YAML 配置文件描述"什么时候跑什么命令"。）→ 详细
- 由此带来的迭代方式非常轻："你不喜欢这个自动化的行为方式，改英文就行。" 它会被重新编译成一个 Actions workflow。他把关系挑明了——"Markdown 才是源代码，YAML 只是编译产物，你根本不用去看它。"→ 详细
- 这条的分量在于它改的是"谁是权威文本"：过去人写的说明是给机器配置作注解，现在人读的那份自然语言文档才是真源码，机器格式退化成中间产物。→ 详细
护栏必须写死：给 agent 写提示词等于把狐狸放进鸡窝
▲ 图注：护栏那页只有四行，但每行都是硬规则：纵深防御 / 别把密钥交给 agent / 所有写操作都要先暂存再审 / 记录一切。他的原话是：靠提示词约束 agent 等于把狐狸放进鸡窝。
- 文档顶部的 YAML front matter（Markdown 文件开头用
---围起来的一小段配置区，写元信息用的）是放护栏的地方。理由是：如果你不打算全程盯着 agent 干活，就必须给"能做什么、能读什么、能写什么"加上强得多的限制。→ 详细 - 为什么不能靠提示词：他举的例子是你对 agent 说"兄弟听着，你永远不许拿我的钱去买比特币"——这不够，因为别人可以通过 prompt injection（提示词注入：把恶意指令藏在 agent 会读到的网页、issue、邮件里，骗它当成你的命令执行）把 agent 带到你意想不到的方向去。 结论一句话："如果你的护栏是靠提示词喂给 agent 的，那基本上等于把狐狸放进鸡窝，它根本算不上护栏。"→ 详细
- 他实际写死的东西：权限只读；允许用哪些工具；允许发哪些网络请求——不是想去哪就去哪，而是一组指定的白名单：NPM 生态（查有什么新版本用）、GitHub，以及他在原始提示里点名的 Astro 文档。→ 详细
- 还有一块叫 safe outputs（安全输出）的配置：这是 agent 唯一被允许写入的东西。这个例子里只允许"创建 pull request"，而且是单数——"因为我不希望 agent 被 prompt injection 之后一口气开 500 个 PR，那就成拒绝服务攻击了"。→ 详细
- 最容易被忽略的一条：他明确写了"你也可以什么都不做"。他自己都说这听着有点傻，但很重要——"在一个我有一大堆自动化的世界里，我最不想要的就是噪音。我可不想被这些 agent 反过来拒绝服务了。"→ 详细
真实战果：从 Astro 5 跨两个大版本升到 Astro 7
- 先看小版本：自动化产出的 PR 里写着"从你现在这个版本升到目标版本，你能拿到的亮点是这些"——它把中间所有的 release notes 都读了一遍，他补了一句"正常情况下这活儿得我这个人类来干"；写了份量身定制的说明，判断出没有破坏性变更，而且真的跑了一遍构建来验证。→ 详细
- 验证闭环也很实在：网站部署在 Cloudflare（他强调任何支持预览部署的平台都行——就是每个 PR 自动生成一个临时可访问的站点副本），点开链接看到页面没有任何变化，"升级做完了，站还跟原来一模一样"。→ 详细
- 真正的硬活是大版本：他运气好，Astro 刚发布了 Astro 7，所以这次是从 5 一口气跳两个大版本到 7。PR 里列出 Astro 7 带来了什么、Astro 6 本来会带来什么——他坦白："我一直没升级，就是为了给大家留一个够酷的 demo。"→ 详细
- 结果三件套：把所有被改坏的代码找出来并更新掉、验证构建能跑通、把那些需要他事后自己动手的手工步骤单独标出来。最后一条尤其关键——它没有假装全能，而是划清了机器与人的边界。→ 详细
现成的 workflow 库：不只给工程师，PM 也该用
- 他们提供了一整个 agentic workflows 的库当起点，可以拿来自己改。issue 分诊器——GitHub 内部就是拿它当基础，快速搭出了自己的 issue 分诊器，还有去他们那个大单体代码库里揪 N+1 查询（一种常见性能问题：本该一次查完的数据被拆成上百次数据库查询）。→ 详细
- repo assist 是"一群 agentic workflow 协同工作"帮你维护项目：找出容易摘的低垂果实并修掉、找出哪些工单需要推一把、哪些提了 issue 的人那边还需要拿到反馈。→ 详细
- CI doctor 配了全场最有共鸣的一句："有多少次，你面对一个跑挂的 CI，处理方式就是再跑一遍？我们所有人都这样。没举手的都在撒谎。"另外还有目标追踪、每日团队状态、仓库状态，也能让它上网做功课。→ 详细
- 他专门点了非工程角色："这不只是给工程师用的，也是给产品经理用的——他们的工作就是看这边的信息、把那边的工单总结出来。我们可以开始让所有人都参与到自动化里来，这才是真正做到工业级规模的方式。"→ 详细
四条安全原则 + Home Assistant 的第一个 workflow
- 他说这四条"所有人都该刻进脑子里"：① 纵深防御，一层永远不够；② 永远别让 agent 碰密钥；③ 所有写操作先暂存、再审核，为了可审计；④ 把所有事情都记录下来，同样为了可审计。→ 详细
- 第二条他展开得最狠："如果一个 agent 能知道某个密钥，你就得当这个密钥已经泄露了来处理"——因为你不知道有没有人注入了它、让它把密钥透露到别处。他们的做法是把密钥全放在 agent 的"牢房"外面，agent 想用密钥调服务时得先问看守："报告，我能去跟那个服务说句话吗？"→ 详细
- 外部案例：他们把这套东西给了 Home Assistant（一个巨大的开源智能家居项目），对方做的第一个 agentic workflow 是——看每个提交上来的 issue，顺着 Python 的调用栈判断这个 bug 到底出在第一方代码还是第三方代码里，不是他们的问题就直接关掉。 他的评语："这件事在 AI 出现之前是做不到的，用死规则也做不到，但现在可以了。"→ 详细
- 状态与赌注：Agentic Workflows 当天已开放 public preview（公开预览，谁都能试）。他给了一个明确的品类判断："我们其实相信，这会是一个比交互式 AI 更大的品类——因为真正决定胜负的，是那些趁你睡觉时在后台自己跑的自动化。"→ 详细
协作篇的前提：规划不再在前，review 不再在后
▲ 图注：全场的转场页：Automation → Collaboration。前半场讲自动化（一个人怎么把活交出去），后半场讲协作（一群人和一群 agent 怎么在同一份东西上干活）。界面为什么长得像 Slack：把"不在代码里的事实"浮出来
*▲ 图注：他为界面选型给的理由只有一句：realtime multiplayer wins every time（实时多人协作，每次都赢）——所以 Ace 长得像聊天，不是偷懒，是因为要把「不在代码里的那些事实」浮到台面上。*
- 他先自嘲这话"只是稍微有点找茬"：Slack 当年的设计目标是"对普通办公室白领来说比邮件更好用"，它从来就不是为做软件设计的。→ 详细
- 但聊天这种形态有个不可替代的长处：代码里有的事实，agent 自己读代码就能搞明白；剩下的就是代码里没有的东西。 他给的例子全是"政治与偏好"类：那边那位 VP 会认这个方向、应该做成紫色因为那是人家最喜欢的颜色、从 Azure 拿到的基础设施价格特别香所以该建在 Azure 而不是 GCP 或 AWS。→ 详细
- 更大的那层收益他用一个类比说完："我现在不会再把 Word 文档用邮件来回传了，我在同一个界面里创作，也在同一个地方协作。这件事一定会发生在代码上，一万个百分点地确定。"→ 详细
Ace 是什么：全在云端，一个 session 就是一个分支
- Ace 的界面"长得特别像 Slack"，左边是 sessions（会话）列表，可以随手新建。他承认到这儿为止跟市面上 Conductor 之类的产品差不多。→ 详细
- 区别在于没有任何东西跑在他本机上，全是云上的 micro VM（微型虚拟机，一个轻量、启动极快的独立小机器）——每个 session 就是这个 repo 的一个分支，被 check out 到云端某个地方，可以在里面装依赖、跑 dev server、开浏览器预览，同时跟队友聊天。→ 详细
- （现场小插曲：他把一句聊天当成终端命令发了出去，自嘲"干得漂亮啊我"；Wi-Fi 也不给力，他只能说"这块你们得信我一次"。演示真实度还行。）→ 详细
"Ace，照做"：聊天记录本身就是上下文
计划是一份大家一起改的 Markdown：「把这份文档变成真的」
*▲ 图注：他用一条进度条表示工作状态：plan（规划）→ build（构建）→ review（评审）——计划不是一次性动作，而是这条带子上可以来回滑的位置。*
- 复杂需求走另一条路：他想给应用加"可切换的时间范围"，于是先让 Ace 出一份计划，计划以一个 Markdown 文档的形式给出。→ 详细
- 关键差别在所有权："这个 Markdown 文档不只是给我一个人看、一个人改的，它是给我们一起看、一起改的。" 演示里 Russ 就在文档里加了"全部时间"选项，他自己顺手删掉"今天"，然后一句"计划我们已经更新过了，照做"——Ace 就照着两人共同改出来的这份计划执行。→ 详细
- 他从中推出一个更大的判断："我们跟 AI 一起干的活儿，越来越多地会沉淀成文档，比如 docs 目录里的 Markdown 文档，那里承载的才是'事实'。也许再往后，我们做开发的方式就是去编辑这些文档：要改我这个应用里的某个东西，我就去改一份文档，然后跟 AI 说'把这份文档变成真的'。"→ 详细
- 落点一句："所以这种共享文档编辑不只是'有了更好'的锦上添花，它可能真的就是我们愿意待着干活的那个界面。"→ 详细
环境感知：不用问，也知道队友在忙什么
- 他重提 GitHub logo 底下当年那句 slogan（"social coding"，社交化编程），说光有实时多人协作不够——"我还想在不经意间就知道大家都在忙活什么。"→ 详细
- 演示里有个团队 dashboard，显示队友各自在做什么（其中一位在做工具链方向的活儿——这块的具体词转写不清晰，别当准确专名；另一位写了这个 dashboard 还把自己的名字写死在里面，所以看板上只有她的名字）。这些都是他们开发 Ace 时的真实工作，目的是帮他跟团队保持在一条线上。→ 详细
- 他留了个开放问题：自动化要怎么在这种界面里"露面"？ 比如当一个 agent 想拍拍你肩膀、问你一个问题的时候。→ 详细
关系反转：越会把目标讲清楚，agent 越不需要你
*▲ 图注：全场最扎人的一页：humans are the tool calls now（现在人类才是那个被调用的工具）——关系反转了，你越会把目标讲清楚，agent 需要打断你的次数越少。*
收尾：打字只占 5%，AI 该来管剩下的 95%
▲ 图注：收尾那张条形图：开发者的时间绝大部分花在理解代码、在代码里导航和其他杂事上，真正「编辑」（打字）只占很小一条。他的结论是：工具一直在优化那 5%，而 AI 该去管剩下的 95%。
- 全场最硬的一个数："过去这几年，AI 帮我的是'打字'。但你要是看研究数据，打字只占这份工作的大概 5%。有一项纵向研究，跟踪了大约 100 名开发者、上千小时，结果发现真正手放在键盘上敲代码的时间只占 5%。"（纵向研究＝长时间持续跟踪同一批人，而不是问一次卷。）→ 详细
- 那剩下的 95% 是什么？他直接把问题列了出来：我想动的那个系统在哪儿？它今天是怎么跑起来的？别人怎么看这个系统能怎么改、该不该改？ 当 AI 能把代码库里的任何东西都翻出来时，"我们该怎么把这些'其他的事'一起放大？而不是只盯着那 5%——到目前为止，所有工具帮我们做的都只是这 5%。"→ 详细
（本期无闪电问答）——这是 AI Engineer 大会上的单人演讲，没有问答环节。演讲的收尾观点已并入上面第十九、二十节。
产品状态（演讲当天口径，会过期）：
Agentic Workflows：已开放 public preview，"大家可以去随便折腾，尽管撒欢"。→ 详细
Ace：争取"这个月晚些时候"进 technical preview（技术预览，比公开预览更早、更小范围的试用阶段）。→ 详细
讲者：Idan Gazit，GitHub Next 负责人（GitHub 的实验室团队，Copilot 的出处）。
团队网站：githubnext.com（团队工作大部分公开，社交账号"我们偶尔会想起来在上面发点东西"）。→ 详细
现场：会场里在微软展台设有位置（GitHub 是微软旗下公司）。他明确邀请反馈："我们非常想听到你们的反馈，以及你们打算拿它来干什么。"→ 详细
这期是罕见的高相关：讲者做的事情和你日常做的事情几乎是同一件——用自然语言文档去驱动一群 agent 干活。他管这叫 agentic workflow，你管它叫 skill。差别只在于他在 GitHub 的实验室里做，你在自己电脑上一个人做。所以下面每一条都能直接对到你手上的东西，尤其是最后那条「和你现在做法冲突」——这期最值钱的地方恰恰是它和你现在的习惯是拧着的。
一、Personal Thinking（第二大脑 + 你写的那一堆 skill）
1. 「元规格写死，任务描述写薄」这个分层
- 怎么做的：他的自动化文件其实是两层。最上面"神奇的一行"塞给 Copilot 一份 skill 文档，说的是"agentic workflow 该长什么样、有哪些格式规矩"——这一层是元规格，写得很实。下面才是任务本身，只有三行 Slack 大白话："每天看看有没有新版本、读 changelog 和文档、想个升级方案、开个 PR，这是文档链接。" 结果模型自己补出了完整步骤，甚至自己去代码库里翻出了该盯哪几个依赖。他强调："这些我一条都没有明说。"
- 你可以怎么做：把你的 skill 文档拆成这两层来看。像视频转文字那份里的"存哪个目录、文件名怎么起、锚点写成什么格式、密度梯度怎么分"，属于环境里读不出来的约定，该继续写死；而像"通读全字幕、聚类主题、每个要点带跳转"这类任何合格模型自己就会推出来的操作步骤，可以试着砍成一两句。做法：挑一份你最熟的 skill，把每一条规则标上"约定"还是"常识"，先删掉三条"常识"跑一次，看产出掉不掉链子。
2. 护栏必须写死，不能写在提示词里
- 怎么做的：他把权限放在文档顶部的配置区（YAML front matter），用确定性的方式规定：权限只读、允许用哪些工具、只准访问哪几个域名（NPM 生态、GitHub、他点名的那份框架文档）。还有一块叫 safe outputs，规定 agent 唯一能写出来的东西——这个例子里只允许"开一个 PR"，单数，防止被注入后一口气开 500 个。他的判词："如果你的护栏是靠提示词喂给 agent 的，那基本上等于把狐狸放进鸡窝。"
- 你可以怎么做：你的 skill 里现在有不少护栏是写在正文里的"请你不要……"式叮嘱——比如播客那三条红线（字数基准必须用脚本给的、日期必须用视频发布日、音频目录不能进 iCloud）。这三条里至少前两条是可以做成脚本检查、不过就中止的，而且你已经有
lint_script.py这个位置了。这周就把"日期不等于视频发布日直接报错"这类判断，从文档正文搬进代码检查——能被脚本挡住的规则，就别继续靠模型自觉。
3. 「允许什么都不做」是防噪音的正经配置项
- 怎么做的：他专门写了一条"你也可以什么都不做"，自己都承认听起来傻，但理由是："在一个我有一大堆自动化的世界里，我最不想要的就是噪音。我可不想被这些 agent 反过来拒绝服务了。"
- 你可以怎么做：你的内容雷达技能、以及未来任何定时跑的巡检，最大的失败模式不是漏，而是每次都硬凑出三条推荐——这恰恰是你自己在「不硬掰」红线里立过的规矩，但那条规矩现在只活在写作规范里，没活在自动化里。给每个定时任务显式加一句"这轮没有值得报的就回一行'本轮无'"，并且允许它输出空结果不算失败。
二、Holdwell ERP 的多-Agent PRD 工厂
1. 你怕碰撞协议的纪律守不住，他的答案叫 safe outputs
- 怎么做的：他没有靠"要求 agent 在某个阶段停下来等审批"，而是从写入口子上限死——agent 能往外写的东西只有白名单里那几种，其他一律做不到。配套的是他四条安全原则里的第三条：所有写操作先暂存、再审核，为的是可审计。
- 你可以怎么做：你那条流水线里"碰撞纪律靠自觉"的悬念，本质和他一样——规矩写在协议文档里，靠角色自觉遵守，就等于没有规矩。 可借鉴的形状是：把每个环节"允许产出哪几类文件、写到工单目录的哪一格"列成白名单，评审没过就物理上写不进下一环节的目录。先拿一个环节试，别一次全改。
2. "所有事情都记录下来"是拿来当证据用的
- 怎么做的：他的第四条原则是把一切都记日志，理由和第三条一样一个词：可审计。他也顺带说了成本账——流程跑得快之后，"一个小小的错位可能滚雪球滚成一大堆白费的工作，而这些工作要烧 token，token 现在是真金白银。"
- 你可以怎么做：你现在的痛点是"agent 产出缺可观测/可验证"，而验证证据的原材料就是这种日志。别再事后补故事——让每次跑流水线自动落一份最小记录（哪个阶段、几轮返工、改了什么、花了多少），攒三次就是你要的那份证据，比再写一版方法论有用。
三、app_incubator（7-Agent 造 App）
- 怎么做的：他给出的品类判断是 "这会是一个比交互式 AI 更大的品类——因为真正决定胜负的，是那些趁你睡觉时在后台自己跑的自动化。" 配套演示的 repo assist 就是一群 agentic workflow 协同，自己去找容易摘的低垂果实并修掉、找出哪些工单需要推一把。
- 你可以怎么做：你想把"该做什么"前移到 agent，这就是现成的形状——不是让 7 个 agent 等你派活，而是留一两个常驻的后台 workflow，在你不在的时候自己找活干（比如扫一遍上次造的 App，把首屏体验里明显掉链子的地方列出来、能改的直接开一版）。第一步只做"它自己找出来并列清单"，先不给它改的权限。
四、Chief of Staff apps（决策外脑）
- 怎么做的：他描述的关系反转是 "我们越是能把自己的目标讲清楚，它们就越不需要我们"；模型变强之后越来越擅长发现哪里没说明白、回头找人澄清，需要一双手的时候再把人叫过来。他还留了个开放问题：agent 想拍拍你肩膀问一句时，界面上该怎么露面？
- 你可以怎么做：这正好是你"软教练质量"那件事的另一种解法——好的外脑不是每次都给建议，而是准确地知道什么时候该打断你。 具体动作：给你的决策外脑定一条"什么时候才开口"的规则（比如只在你要做的事和你自己写过的原则冲突时才拍肩膀），其余时候闭嘴。这条规则本身值得写进宪法。
五、StockHelp（投资看板）
- 怎么做的：他整个演讲最实的一个价值主张就是"后台自动化"——收盘那种固定节奏的活儿，交给一个有明确权限边界的自动化去跑；并且他真的验证到底了：读完中间所有的更新说明、跑一遍构建、点开预览部署确认页面没变，而不是只报告"我干完了"。
- 你可以怎么做：你的看板本来就是"收盘后拉 12 只票的数据"这种典型的睡觉时该跑完的活。可以直接抄两件事：① 权限白名单——这类脚本只该访问那几个数据源域名，写进配置而不是靠自觉；② 拿结果验证自己——每次拉完自动做一次合理性检查（比如某只票的估值分位跳变超过阈值就标记待人工看），检查不过就在看板上说"本次数据存疑"，而不是安静地展示一个错数。跑通了不等于跑对了，这是他那个"真的跑一遍构建"给的提醒。
六、一人公司 build-in-public（onehuman_company）
1. 一条现成的「大佬说 X 我试了」验证体选题
- 怎么做的：GitHub 实验室负责人当着大会说：三行大白话 + 一份元规格，模型能自己展开成完整作业手册，并且真的把网站跨两个大版本升上去了。这是个观点明确、可证伪、有具体数字的主张。
- 你可以怎么做：这就是你那个支柱要的弹药——"GitHub 的人说三行就够了，我把自己写了半年的详细流程稿砍成三行试了试"。可抄物是现成的：你砍前砍后的两份文档 + 产出对比。过弹药库闸门吗？过——删掉你的实测和判断这篇就不成立了，因为核心不是转述他的观点，而是"在我这台机器、我这套 skill 上到底掉不掉链子"。
2. 一条成本账选题
- 怎么做的：他把机会成本讲得很直白——"就算你是个 token 亿万富翁，开着 10 个终端日夜跑，机会成本依然在那儿，而且它就是一切"；又说小错位滚雪球会烧掉大把 token，"token 现在是真金白银"。
- 你可以怎么做：对应你那个"AI 员工管理成本账"的支柱。你手上已经有真实数字（比如做一集播客大约多花的那十几二十万 token），可以写一篇"我的 AI 员工返工一次要多少钱"——把一次因为规格没写清导致重跑的账算出来。这类文章的可抄物就是那张账单表。
更深三角度
该反着用
他有一条你没有的退路："要么你多招人，要么你把手下人现在正在做的一部分事情自动化掉。" 他两条都能选，你只有第二条——所以对你来说自动化不是效率优化，是唯一的产能来源，投入判断标准应该更激进。反过来，他做的是"给全世界一个可改的起点"，所以要出通用的 workflow 库；你是单人，通用化对你是纯成本。别学他把自己的 skill 往通用模板方向打磨——你的 skill 只需要在你这一台机器、你这一套目录结构上跑对。他还有"我故意不升级，就为了留个够酷的 demo"的余裕，你没有 demo 预算，别为了演示效果留技术债。
和你现在做法冲突（这条最该慢慢读）
他的核心示范是"任务描述写到三行就停"，而你现在的做法是把流程写成几百行的详细规格。 你手上那份视频转文字的 skill 有五百多行，连"每片切多少轮"都用一段脚本反推、连翻车史都写进了坑表。这两种做法的价值观是相反的：他相信模型能从环境里读出大部分上下文，你相信不写清楚就会翻车。
值得注意的是，你们俩谁都不算错，而且他的做法里藏着你那套的一半——他那"三行"之所以能展开，前提是他另外给了一份写得很实的元规格（agentic workflow 该长什么样），以及模型能直接看到代码库、自己推断出该查哪些依赖。也就是说详细规格并没有消失，只是从"这次要干什么"挪到了"这类东西该长什么样"。而你写那五百行的很多细节，恰恰是模型从环境里读不出来的：产物存哪个目录、锚点写成什么格式、密度梯度怎么分档、哪一版口径是第三次校准后的。
所以真正的张力不是"详细 vs 简洁"，而是——你那些行里，有多少是"环境里读不出来的约定"（该留），有多少是"任何模型自己就会想到的步骤"（该删）？ 你的坑表明显属于前者，是你踩出来的、外面读不到；而"通读全文、聚类主题、写 bullet"这类明显属于后者。这个问题这期没替你回答，你自己那五百行里的答案也没盘过。
对你的镜子
"打字只占这份工作的 5%。" 这句话对你的版本不是"敲代码"，是"写规格文档本身也只是那 5%"。你这半年在 skill 上花的力气，大部分在把流程写得更全、更细——但真正决定产出质量的那 95%，是"这件事值不值得自动化""这份产出的口径该定在哪档""哪些护栏必须写死"。你的三条播客红线是那 95%，切片轮数的计算公式是那 5%。另一面镜子来自他的动机自白——"因为我懒，我喜欢不干活"——他把"懒"当成正当的设计起点；你的元约束是精力稀缺，本质是同一件事，但你更容易把它说成"要更高效"，然后又给自己加一份文档。
所以呢
可迁移思维模型
- 【耐用】护栏不能靠请求，只能靠限死。凡是"请你不要 X"的规则，都要问一句"能不能变成一条它物理上做不到 X 的限制"。这条不随模型变强而失效——恰恰相反，模型越强、越自动，它越重要。
- 【耐用】人读的那份自然语言文档才是源代码，机器格式是编译产物。 判断一个流程健不健康的检验是：不满意的时候你改的是英文（中文），还是去改配置文件？改配置文件就说明你的源代码放错地方了。
- 【耐用】"允许什么都不做"是一等公民。 自动化多了以后，噪音是比漏报更贵的失败。
- 【耐用】机会成本是一切——即使算力和 token 不再是约束，它也还在。这条和你自己写过的"判断力 > 努力""99% 的努力终将白费"是同一条。
- 【会过期】"三行就够"这个边界值。 它取决于当下模型能从环境里推断出多少，模型一换、上下文一变就会移动。所以别把"砍到三行"当成目标，把它当成每隔一段时间要重测一次的刻度。
- 【会过期】产品状态：公开预览 / 技术预览的时间点、具体产品能力边界。
判断更新
把默认动作从"写清楚点，免得翻车"改成"先给三行 + 一份元规格，看它自己能展开到哪儿；展不开的地方才补细节，而且补的时候标明白这是约定还是常识"。这不是要你删掉现有的 skill，而是把"删"变成一个会定期做的动作——现在你的 skill 只增不减，每次踩坑就加一行，从来没有人回头问"这行还需要吗"。
这周一个赌注
挑一份你已经跑熟、失败了也不心疼的 skill（内容雷达巡检是最好的候选，产出是一份清单、错了就重跑），做一次对照实验：复制一份，把任务描述砍到三到五行大白话，只保留"环境里读不出来的约定"（存哪儿、什么格式、什么口径），其余全删；同一个输入各跑一次，比对产出。赌注的赔率在于：如果砍完还行，你就拿到了一条能横扫所有 skill 的减法规则，顺带得到一篇现成的验证体选题；如果砍完就崩，你就第一次有了"我这些行为什么必须存在"的实证，而不是靠印象。两种结果都比现在这样一直加行强。