[鸭哥 AI 手记] 2026-04-11

> 代码写完了，瓶颈才刚到。当执行成本归零，约束会往上游迁移，落在你最不习惯投入时间的地方。

懒人包：鸭哥做了一整天 PPT，80% 时间在想逻辑流和认知负担，20% 时间在操作，顺手开源了一个 pptx skill。群里胥克谦展示了一套 143 万字符的文档驱动开发体系，代码本身的问题不到 10%。群里同时在吵 MCP 是否已死，实战中 CLI 和 skill 方案正在绕过协议层。三件事指向同一个判断：AI 把执行成本压平之后，瓶颈正在向"想清楚"这件事迁移。

143 万字符的文档，换来不到 10% 的代码问题

群里胥克谦说了一句让人停下来想的话：大部分代码的问题，根源最大的在于 PRD 严重不合格，其次是架构文档严重不合格，然后是任务拆分与持久化不够，只有不到 10% 是代码本身的问题。

他紧接着亮了数字。PRD 生成环节的 skill 文件是 381K 英文字符，架构文档生成 skill 是 348K，文档质量门禁是 70 万字符。三个环节加起来超过 143 万字符，全部自动化，99% 以上的 API 调用缓存命中率，每次运行的 token 成本几乎为零。这不是一个写代码的系统，是一个写"怎么写代码"的系统。

这种做法正在行业层面获得正式名字。Google Cloud 的 Mofi Rahman 在 3 月把它叫做 Spec-Driven Development，称之为"编程的第五代"（Medium）。DEV Community 上有人给了另一个名字 Intent-Driven Development，并给出了时间分配比例：60% 产品判断，30% 工程架构，10% 设计精度（DEV Community）。

反面数据更能说明问题。OpenReview 上一篇论文测量了没有 spec 约束时 AI 编码的后果：代码复杂度增加 41%，超过 90% 的输出中引入安全漏洞（OpenReview）。不写 spec 直接让 AI 编码，你拿到的代码大概率比不用 AI 还糟。

崔富泽在群里拿 Factory AI 的 DROID Mission 模式（$200/月）做对比，认为 DROID 的内置提示词"按企业级规范去靠拢"，在纯编程领域比 Claude Code 的自由度路线更可控。他写了一篇完整指南给群友入门，还提到 Mission 模式有个已知 bug：主动上下文压缩无法触发，官方一直在修。

胥克谦看完后评价罕见地正面："有些东西一看就是大量想象和人类开发经验的移植，但这个是真正系统化解决问题。"他估计 DROID 公开的 skill 只是全部体量的十分之一，大量逻辑在程序级别控制。

两个人在做同一件事的不同版本：把开发的质量控制点从代码层推到文档层。胥克谦是自建的，DROID 是产品化的。共同点是代码生成已经退居到管线末端。对 builder 来说，投入时间的优先级需要翻转：你花在描述"要做什么"和"什么算好"上的每一小时，回报率可能高于花在调试 AI 输出上的十小时。

---

80% 的时间在想，20% 的时间在做

上面是编程领域的瓶颈迁移。同一天鸭哥在非编程领域撞上了同样的现象。

鸭哥从早上 6 点到晚上 10 点做 PPT，在群里写了一段感慨："以前可能 80% 的时间在拖框框，打字。现在 80% 的时间在想真正用的事情。比如为什么这件事我觉得很难讲清楚，怎么降低听众的认知负担，整个逻辑流对不对，起承转合顺不顺，哪里听众会走神。只有 20% 的时间在做 tactical 的东西。"为了编辑 pptx，他现场搓了个工具并开源了（github.com/grapeot/pptx.skill）。

群里有人问 PPT 生成工具好不好用，回答是"布局不太满意"。问题的根源相同：生成 PPT 容易，想清楚要讲什么很难。

80/20 的翻转看似个人体验，外部数据在验证一个更广泛的模式。Fortune 3 月引用数据称，AI 工具普及后员工花在邮件上的时间翻倍，深度专注工作的时间反而下降（Fortune）。BCG 2026 年的职场研究更精确：同时使用 4 个以上 AI 工具的员工，精神疲劳增加 12%，信息过载增加 19%（Business Insider）。BCG 的研究者用了"AI brain fry"来形容这种状态。

为什么会这样？BCG 的解释是：AI 替代了重复性操作后，剩下的工作全部集中在问题解决、决策和复杂输入整合上，认知强度反而上升（BCG）。AI 消灭了"简单的忙"，把你暴露在"困难的忙"面前。

鸭哥的 16 小时 PPT 日就是这个现象的微缩版。以前拖框框和打字是累的，但那种累有下限，总能机械地完成。现在操作被压缩到 20%，剩下 80% 全是"想清楚"，而想清楚没有机械化的路径。pptx skill 帮他解决了操作层的问题，但没有工具能帮他决定"哪里听众会走神"。

群里关于 MCP 的争论也在映射同一个位移。马工直言"mcp快死了"，胥克谦说"身边从来没有见谁在开发 mcp 应用"，崔富泽总结"开发 MCP 的人比用 MCP 的人还要多"。lencx.me 发了一篇从 Prompt Engineering 到 Context Engineering 的文章辩护 MCP 作为接口统一层的价值。

但 Firecrawl 的实测结论是 CLI 处理 80% 的任务，MCP 只在需要 auth 和有状态连接的 20% 场景里才有优势（Firecrawl）。UTCP 作为 MCP 的替代者已经在基准测试中展示了 60% 的执行提速和 68% 的 token 节省（andrewbaker.ninja）。协议层的连接问题曾经是瓶颈，但当 CLI 和 skill 方案足够好用时，这个瓶颈被绕过了。真正的卡点又往上移了一层：你让 agent 调的工具对不对，取决于你对任务的描述够不够清楚。

编程、演示文稿、工具协议，三个看似无关的领域，瓶颈迁移的方向完全一致：从"怎么做"到"做什么"再到"为什么做"。执行层的问题正在被工具快速消化，留下来的全是判断层的问题。

---

也值得知道

Altman 住宅遭燃烧瓶袭击：4 月 10 日凌晨 4:12，一名 20 岁男子向 Sam Altman 位于旧金山 Russian Hill 价值 2700 万美元的住宅投掷燃烧瓶，随后前往 OpenAI 总部威胁要烧大楼，当场被捕。无人受伤，火势仅损坏外部大门。（WSJ，CNN）

MiniMax 开源 M2.7：自演化 agent 模型，SWE-Pro 得分 56.22%，Terminal Bench 2 得分 57.0%，可在本地部署。（MarkTechPost）

Google AI 订阅分三档：Plus（$8/月）、Pro、Ultra。NotebookLM 全面接入 Gemini，Ultra 用户每日 200 次 Deep Research、600 笔记本上限。Jules 异步编程 agent 给 Pro 用户 5 倍于免费版的额度。（9to5Google）

---

本期素材来自 AI Builder Space 社群讨论与公开 AI 行业信息的交叉验证。

本文由AI综合领域调研和微信群聊自动生成。请注意甄别幻觉。

订阅本 newsletter：yage-ai.kit.com