AI Agent 的道与术：工程师如何重构工作方式

预计阅读时间：35分钟 | 难度：⭐⭐⭐

目标读者：想系统理解 AI Agent 时代工程实践如何落地的开发者、技术负责人、内容创作者
核心问题：onevcat/2026-let-s-vision 这场演讲，到底提供了哪些可复用的方法，而不只是一次漂亮的分享？
事实口径：本文基于仓库公开材料撰写，重点参考 README.md、slides.md、resources/、design-fix/critique-report.md、scripts/ 与 package.json

很多人看到这个仓库，第一反应是“onevcat 把演讲稿开源了”。但如果你认真翻一遍目录，会发现它真正有价值的并不是那份 PDF，而是一整套可复用的工程化工作流：观点池、结构规划、引用清单、完整讲稿笔记、设计批评记录、提取 speaker notes 的脚本，以及面向 Agent 的技能目录。

换句话说，这不是“把幻灯片放上 GitHub”那么简单，而是把一次分享拆成了一套能复盘、能迁移、能复用的生产过程。

§0 先看结论

如果你时间有限，先记住下面 7 点：

• 这场分享真正讨论的不是“AI 工具哪个好”，而是工程范式正在往 Agentic Engineering 迁移。
• onevcat/2026-let-s-vision 值得研究，不是因为作者用了 AI，而是因为它把资料、结构、设计、脚本和技能都留下来了。
• “道”谈的是约束与判断：上下文有限、经验要沉淀、协作范式在变。
• “术”谈的是具体做法：任务如何切分、验收如何前置、上下文如何组织、经验如何 skill 化。
• 这套仓库最稀缺的部分，不是 slides.md，而是 resources/ 与 design-fix/：前者告诉你内容怎么长出来，后者告诉你页面怎么被批评和修正。
• 当前文章原稿里最容易误导读者的地方，是把一些事实说得过满；更准确的说法应该是：这是一个公开、可复现的演讲工程样本，不是普适模板。
• 如果你想把这些方法迁移到团队里，最先该做的不是“上更多 Agent”，而是把任务边界、验收标准、知识入口整理清楚。

§1 为什么这个仓库值得研究

1.1 它不是单一产物，而是一套生产档案

仓库根目录里最值得注意的，不只是 slides.md，还有这些配套材料：

这意味着你研究的不是“一个结果”，而是“结果背后的生产链条”。

1.2 这场演讲的主题，比“AI 很强”具体得多

README.md 开宗明义写得很清楚：主题是**“AI Agent 时代下，工程师如何重构工作方式”**。这里的重点不在“AI”，而在三个词：

• 时代：这是对阶段变化的判断，不是工具使用教程
• 工程师：讨论对象是做软件的人，不是泛泛的知识工作者
• 重构工作方式：核心是流程、职责、边界和协作方式的改变

所以这不是一场“如何写 prompt”的分享，也不是一份“2026 年 AI 工具清单”。它真正想回答的是：

当 Agent 不再只是回答问题，而能接手更长链路的任务时，工程师应该把时间和判断力放到哪里？

1.3 仓库名和 PDF 链接为什么看起来不一致

这里顺手纠正一个容易让读者困惑的点。

• GitHub 仓库名是：onevcat/2026-let-s-vision
• README 里的发布版 PDF 链接是：https://github.com/onevcat/2026-vision/releases/download/release/2026-vision.pdf

这不是本文原稿里的笔误，而是上游仓库 README 本身就是这样给出的：仓库使用 2026-let-s-vision，发布资产沿用了 2026-vision 这个 release 路径。写文章时最好把这层关系讲清楚，免得读者误以为引用错仓库。

§2 这场演讲到底在讲什么

2.1 从 resources/slide-overview.md 看，它本来就是按“方法论”来设计的

resources/slide-overview.md 不只是一个提纲，而是一份相当明确的演讲设计说明。里面给出了：

• 全场时长：40 分钟正文 + 5 分钟 Q&A
• 页面规模：34 页左右
• 结构分段：开场、时代判断、现实证据、“道”、“术”、双案例、收束
• 每一页的用途、重点和可降级内容

这说明作者一开始就不是按“把想到的内容堆上去”来做，而是先把叙事节奏和信息密度设计出来。

一个很重要的细节是：文档明确写着“主观点上主页，重复或次要观点放讲者备注”。这已经体现出很强的工程思维：公开展示层和内部支撑层要分开。

2.2 “道”不是空话，而是 3 类约束

从 resources/points.md 和 slide-overview.md 可以把“道”层内容整理成三组更具体的约束：

如果把它说得再直白一点：

• 以前软件工程怕“代码不同步”
• 现在还要怕“上下文不连续”
• 以前知识沉淀主要为了给人看
• 现在知识沉淀还要为了给 Agent 消费

这就是演讲里“道”的部分真正要解决的问题。

2.3 “术”不是工具列表，而是 4 个执行抓手

原稿把“术”写得比较散。结合 resources/points.md，更清晰的归纳方式应该是下面这四类：

1. 任务切分：任务不再只是“写一段代码”，而要切成可验收交付单元，例如 PR、patch、demo、回复草稿。
2. 验收前置：测试、日志、回滚方式、风险列表要在动手前讲清楚，让 Agent 能“自证完成”。
3. 上下文工程：给 Agent 喂的是 README、架构图、关键文件、约束清单，而不是一整段混乱聊天历史。
4. 技能沉淀：把成功流程变成 skill、模板、runbook、FAQ，而不是每次从零开始重复试错。

注意，这里有个非常关键的态度变化：

工程师的稀缺价值，正在从“亲手写出实现”转向“定义问题、设置边界、设计验收、沉淀流程”。

这句话如果单独拿出来听，容易显得像口号；但放回仓库里看，你会发现作者确实在用仓库本身演示这件事。

§3 仓库里最值得看的，不是最终 slides，而是中间层

3.1 resources/：把观点从“想法”变成“结构”

如果你只读最终 PDF，你看到的是成品；如果你去看 resources/，看到的就是方法。

这里最关键的几个文件分别承担了不同职责：

这组文件提供的启发很直接：复杂内容先做素材库，再做结构，不要一上来就写最终稿。

3.2 design-fix/critique-report.md：把“设计感觉”变成可讨论对象

这是整个仓库里我最推荐细读的文件之一。

它有价值，不是因为它在夸页面，而是因为它把很多“PPT 看着不对劲”的问题拆解成了可操作判断，例如：

• 哪些页面有典型的 AI 生成感残留
• 哪些组件结构重复过多，导致视觉疲劳
• 哪些颜色使用稀释了语义
• 哪些 slide 应该“安静下来”，让关键页真正“响”起来

比如文档里明确批评了几种常见问题：

• 左侧粗色边框滥用，变成廉价装饰
• hero metric 大数字卡片过度模板化
• 连续多页使用同一种卡片网格，造成“企业模板感”

这部分最有意思的地方在于：它不是空泛地说“再高级一点”，而是明确写出为什么有问题、怎么修、修到了哪里。

对工程师来说，这种文档非常有借鉴意义，因为它和代码评审的优秀做法很像：

• 先指出反模式
• 再解释影响
• 最后给出具体修正策略

换句话说，design-fix/ 的价值不只在幻灯片设计，它也是一份如何做高质量批评的示范。

3.3 scripts/：把演讲内容变成可审校对象

仓库里两个脚本都很实用，而且本文原稿在这里有一处事实需要修正。

scripts/extract-notes.py

这个脚本会解析 slides.md，输出每页的：

• 页码
• 行号范围
• layout
• 标题
• clicks 信息
• speaker notes
• notes 所在行号

更准确的说法是：它把 JSON 打到标准输出，而不是自动生成一个 JSON 文件。

也就是说，真正可复现的命令更应该写成：

python3 scripts/extract-notes.py slides.md > notes.json

scripts/slide-index.sh

这个脚本会输出一个页级索引表，包含：

• Page
• Lines
• Layout
• Title

适合做两件事：

1. 快速定位某一页对应的源码位置
2. 给审校、批评、重写建立统一坐标系

更实用的调用方式是：

bash scripts/slide-index.sh slides.md

这两段脚本背后有一个很重要的思路：把原本只能“看”的演讲稿，变成可以被程序检索、被 Agent 消费、被团队协作引用的结构化资产。

§4 这套分享是怎么被做出来的

4.1 从仓库材料看，流程不是“让 AI 帮我写”，而是“让 AI 加速迭代”

如果把 README、resources/ 和 design-fix/ 放在一起看，整个流程大致可以还原成下面这样：

观点发散 → 证据补充 → 结构编排 → 页面制作 → 设计批评 → 多轮修正 → 发布与复盘

这里最重要的一点是：AI 并没有替代作者做判断，它更像被放进了几个关键环节里：

• 在内容阶段，帮助扩展观点和补足表达
• 在结构阶段，帮助比较组织方式
• 在制作阶段，辅助出图、排版、生成页面
• 在迭代阶段，参与批评、修正、再生成

真正决定成败的，仍然是人的判断：什么该讲、什么不该讲、什么该留在 notes、什么该放到页上、什么该删掉。

4.2 package.json 也透露了一个实用态度：先把产物跑起来

上游仓库 package.json 很简单：

{
  "scripts": {
    "dev": "slidev --open",
    "build": "slidev build",
    "export": "slidev export --per-slide",
    "export:png": "slidev export --format png --output slides"
  }
}

对研究者来说，这意味着两件事：

1. 这不是“只适合看、很难跑”的展示仓库，而是可以直接本地复现的项目。
2. 重点不是炫复杂工程，而是把复杂方法论装进一个足够轻的交付形式里。

本地最常用的命令也应该写得更准确一些：

git clone https://github.com/onevcat/2026-let-s-vision.git
cd 2026-let-s-vision
pnpm install
pnpm dev

如果你只是研究内容，不一定需要导出所有图片或 PDF；但如果你想完整理解节奏、动画与 notes 的配合关系，本地跑起来会比只看静态 PDF 清楚得多。

§5 从这个仓库里，工程师能学到什么

5.1 第一课：上下文不是背景信息，而是生产资料

resources/points.md 里有一句很重要的话：context = 内存。

这句话的价值在于，它把很多人对 AI 协作的误解掰正了。问题不只是“模型够不够聪明”，而是：

• 它现在拿到的信息是否正确
• 这些信息是否处于合适粒度
• 上下文是否被无关历史污染
• 关键决策是否会在下一轮会话中丢失

这对工程团队的启发非常直接：如果你们的文档、约束、架构边界本来就混乱，再强的 Agent 也只是在更快地继承混乱。

5.2 第二课：memory 和 skill 才是团队复利的起点

仓库里存在 .agents/、.claude/、skills/ 这些目录，不是装饰。它们反映的是一种明确态度：

成功经验不该只留在个人脑中，而应该变成可以共享、可以复用、可以持续调用的资产。

个人视角下，这意味着减少重复解释和重复踩坑。团队视角下，这意味着把少数高手的经验，变成更多人和更多 Agent 都能继承的基础设施。

很多团队引入 AI 后效果不稳定，往往不是模型不行，而是：

• 经验没有被结构化
• 任务没有标准化
• 约束没有显式化

一旦这三件事没有做好，AI 协作就很难稳定复现。

5.3 第三课：任务必须长成“可验收交付单元”

这是这场分享最像工程方法论的地方。

从 points.md 的表述看，任务切分的目标不是让 Agent “看起来很忙”，而是让它产出可以验收的结果，例如：

• 一个 PR
• 一个 patch
• 一个最小复现 demo
• 一份结构化回复草稿

这背后的思想很朴素：任务的边界越清楚，验收越容易；验收越前置，自动化越可靠。

很多团队一上来就让 Agent 接大任务，最后得到的是大量“看似完成、实际上无法落地”的结果，问题往往就出在这里。

5.4 第四课：工程师不会消失，但职责会明显上移

从演讲材料反复出现的一条主线是：

• 亲自实现的成本在下降
• 定义问题的价值在上升
• 设边界、做取舍、做验收变得更稀缺

因此更现实的判断不是“AI 取代工程师”，而是：

工程师的工作重心会从“直接生产代码”逐步上移到“组织任务、治理质量、设计系统、沉淀知识”。

如果你已经是技术负责人，这种变化会更明显；如果你还是一线开发者，越早把自己训练成能写清楚任务、说清楚验收、维护知识入口的人，越能吃到这一轮变化的红利。

5.5 第五课：未来很多东西都要开始“为 Agent 而写”

这大概是整场分享里最值得多想一步的判断。

以前我们写文档、做工具、设计接口，默认服务对象主要是人。现在情况在变：

• 文档不只是给人看，还要让 Agent 稳定消费
• 工具不只是让人点，还要能被 CLI / API 调用
• 代码边界不只是为了人理解，也直接影响多个 Agent 能不能并行协作

这也是为什么仓库里“知识结构化”“CLI/API 化”“Agent-friendly 基础设施”这些话反复出现。它们不是新口号，而是软件工程用户模型正在变化后的自然结果。

§6 如果你想照着做，可以怎么复用这套方法

不一定非要做演讲，写技术文章、做方案评审、做内部分享，都能套用这条路线。

6.1 最小可复用流程

1. 先建观点池：把所有判断、案例、反例、问题先收集到一个地方。
2. 再做结构提纲：规定篇幅、节奏、分段与每段目标，不要直接写最终稿。
3. 补齐引用依据：把数据、出处、截图来源单独整理，避免写作时反复回查。
4. 把批评显式化：不满意不要只说“感觉不对”，要写清楚哪里不对、为什么不对、改法是什么。
5. 给内容加索引：能提取 notes、建立页码索引、建立文件映射的，尽量脚本化。
6. 沉淀复用资产：把有效流程写成模板、skill、FAQ、runbook。

6.2 适合团队落地的 3 个起点

如果你想在团队内部试，不必一上来就做很大：

6.3 不要照抄的部分

这套方法很好，但也不适合机械复制。

至少有三件事要保留判断：

• 别把个人经验写成普适真理：onevcat 的工作方式有很强的个人风格，迁移时要看团队规模和协作方式。
• 别为了 AI 而制造复杂度：能用简单模板解决的问题，不必强行上多 Agent 编排。
• 别忽略验证成本：任务切分和自动化做得越激进，验收和回滚设计就越重要。

§7 按时间预算，怎么读这个仓库最划算

7.1 30 分钟

适合只想抓住核心的人：

1. 读 README.md
2. 读 resources/slide-overview.md
3. 快速翻 slides.md 中“道”和“术”相关页面
4. 看 design-fix/critique-report.md 的开头和优先问题

这条路径的目标不是读全，而是先理解：主题、结构、方法、迭代分别放在哪里。

7.2 2 小时

适合想把方法搬到自己工作流里的人：

1. 完整阅读 resources/points.md
2. 对照 slide-overview.md 与 slides.md
3. 阅读 design-fix/critique-report.md
4. 跑一遍 scripts/slide-index.sh
5. 用 extract-notes.py 把 notes 导出来看

走完这条路径，你基本就能看懂这场分享是如何从“观点”变成“成品”的。

7.3 半天

适合想把这套思路做成自己团队方法的人：

1. 完成上面 2 小时路径的全部内容
2. 细读 resources/2026-03-shanghai-ai-agent-talk-notes.md
3. 查看 .agents/、.claude/、skills/ 的组织方式
4. 尝试为自己的项目做一份 points.md 和 slide-overview.md
5. 仿照仓库做一轮“批评 -> 修正 -> 再审视”的闭环

如果你真打算复用，最值得抄的不是某一页 slide，而是资料分层、批评机制和知识沉淀方式。

§8 常见误读

Q1：这篇仓库的重点是“AI 帮 onevcat 做了一套 PPT”吗？

不是。更准确地说，这是一个公开展示如何把 AI 纳入完整生产流程的样本。重点不在“用了 AI”，而在“怎么组织资料、怎么收敛结构、怎么做批评、怎么沉淀经验”。

Q2：如果我不用 Slidev，这篇文章还有价值吗？

有。Slidev 只是载体。真正可迁移的是：

• 观点池
• 结构提纲
• 引用清单
• 设计批评
• 脚本化索引
• skill 化沉淀

这些方法和你用 Keynote、Figma、Notion，甚至只写技术文档都不冲突。

Q3：这套方法是不是只适合内容创作，不适合软件团队？

恰好相反。它最值得软件团队学的地方，就是把“内容生产”做成了“工程生产”：

• 有输入材料
• 有结构设计
• 有中间产物
• 有批评环节
• 有自动化脚本
• 有可复用资产

这和优秀的软件交付过程，本质上是相通的。

Q4：我最应该先学哪一部分？

如果只能选一件事，先学如何把任务写成可验收交付单元。因为这是把“聊天式 AI 使用”升级成“工程化 AI 协作”的分水岭。

§9 总结

onevcat/2026-let-s-vision 最值得研究的地方，不是某个页面做得多漂亮，也不是某条 prompt 写得多聪明，而是它把一次技术分享拆成了可以反复复用的工程资产：

• 观点如何收集
• 结构如何规划
• 证据如何归档
• 设计如何批评
• 内容如何索引
• 经验如何沉淀

如果你把它只当成一份演讲仓库，收获会有限；如果你把它当成一个Agent 时代知识生产与工程协作的样板间，很多做法都能迁移到自己的文章、项目和团队工作流里。

最后把整场分享浓缩成一句话：

AI Agent 时代，工程师的核心竞争力不再只是“写出实现”，而是“定义任务、组织上下文、设计验收，并把有效经验沉淀成系统”。

§10 资源链接