AI HERO · SITE HANDBOOK · 全站学习手册

aihero.dev 全站学习手册

Matt Pocock(Total TypeScript 作者)的 AI 工程站。99 篇可学内容的中文摘要已全部编进本页,加上 69 条词典全量释义与三门系列课逐课展开——不跳外部页面即可读完整学习路径;售卖页已排除,每篇末尾留「原文」脚注备查。

原站 · aihero.dev(Matt Pocock) 整理 · 2026-08-28 姊妹篇 · /grill-with-docs 单篇精读 访问原站 ↗

99篇文章站内精读
69词典条全释义
25skills 全收录
29课课时全展开
8营销页已排除
目录 · 8 节 + 说明
  1. §0 全景与路线
  2. §1 Skills 技能系统
  3. §2 AI 编码词典
  4. §3 课程与系列
  5. §4 Claude Code 实战
  6. §5 评测与改进
  7. §6 论文与资源导读
  8. §7 观点与思维
  9. §+ 排除清单与说明

§0 · OVERVIEW

站点全景与三条学习路线

全站内容围绕一件事:专业开发者如何把 AI 用出工程水准。它分两条主线——用 agent 写代码(skills、词典、Claude Code 实战)和写 AI 驱动的应用(LLM 基础、AI SDK、MCP、评测)。按你的目的选一条路线:

路线 A用好编码 agent —— 大多数人的第一优先级

路线 B做 AI 应用(TypeScript)—— AI Engineer 方向

路线 C手册式随查 —— 学过后当工具书

一句话总评:这个站最独特的资产是 skills 体系(把工程纪律写成 agent 可执行的工作流)和 AI 编码词典(给 agentic coding 一套精确词汇);课程系列(AI SDK / MCP)是免费视频课,适合 TypeScript 开发者系统入门。

§1 · SKILLS SYSTEM

Skills 技能系统(25 个全收录)

站长的核心开源资产:github.com/mattpocock/skills。一个 skill = 把「我遇到某类问题时会走的固定打法」写成小 markdown 文件,agent 按同样方式执行——不是给 agent 套脚手架,而是把你的品味和标准写下来让它复现。整包安装:

npx skills add mattpocock/skills -y -g装到全局 ~/.claude/skills;去掉 -g 则只装当前项目。也可单装某个 skill。

Main Flow · 主流程

5 篇

从模糊想法到合并代码的主干:面试落盘 → spec → 工单 → 实现 → 审查。/grill-with-docs 的单篇精读见姊妹篇。

带落盘的拷问式规划The /grill-with-docs Skill

  • 主链第一环:在 repo 里对模糊计划做访谈直至共识,且是有状态版——术语一敲定立即写入 CONTEXT.md 词表,决策过三道门槛(难逆转、缺上下文会令人意外、真实权衡)才落 ADR 到 docs/adr/;两者惰性创建。
  • 定位是单会话规划;规模超出一个 session 用 /wayfinder。无文档的老仓库可直接说 "help me document my repo" 补词汇表。
  • 本体只是一行委托,依赖 grilling 与 domain-modeling 两个 skill:装一半会出现"一次抛全部问题、无推荐、不写文件"或"访谈好但没有纸面产出",这是该 skill 被报告最多的问题。
  • 坑:被外层编排框架当步骤调用时,写文件会静默失败(已报未修);多数决定只留在对话里,词表不是 spec,收尾应把同一会话直接交给 /to-spec 而不是 clear。

原文 ↗ /skills-grill-with-docs

对话合成规格The /to-spec Skill

  • 把刚谈定的会话合成为 spec 并以单条 issue 发布到 tracker;不访谈——断言了你没说过的内容即为缺陷。v1.1 由 to-prd 改名。
  • 触发条件唯一:构建跨多个 session 才值得;单 session 直接 /implement。写正文前先把测试 seam 提给你确认,优先复用已有 seam、越少越好(理想 1 个),seam 之后约束 tdd 与 code-review。
  • 前置:setup-matt-pocock-skills 已配好 tracker(GitHub 或 .scratch/ 本地 markdown 均可)。
  • 坑:spec 带 ready-for-agent 标签会诱使 AFK agent 一口气实现整个 spec(最高频投诉),要么在 prompt 里排除父 issue,要么拆票后摘标签;spec 是快照不会随实现更新,过期即弃;user-story 模板不适合纯重构;超大 spec 经 tracker 回读会截断,故 /to-spec 与 /to-tickets 务必同一窗口连跑。

原文 ↗ /skills-to-spec

spec 拆分为工单The /to-tickets Skill

  • 把 spec 或当前对话拆成带 blocking edges 的 tickets 发布到 tracker;每张票是 tracer bullet 纵切(schema/API/UI/tests 一路打穿、可独立演示),大小以一个全新 context window 为限;发布的票已 agent-ready,不要再跑 /triage。
  • 发布前两步:识别 prefactoring 排在最前;以编号清单向你提问(粒度、依赖、合并拆分),批准才发布——quiz 是你唯一该推回的关口。宽泛机械重构走 expand–contract 序列,分批迁移共享集成分支保证绿。
  • 产出物即终点,不负责派发:自己数无阻塞的票开等量 session,一票一窗。
  • 已知坑:默认切太碎(三行改动出十二票),quiz 时令其合并;仍会切出按层分的票(每张问"完成时能演示什么");GitHub 上 sub-issue 与原生 blocked-by 常没建对(#554/#513),用 gh issue create --parent/--blocked-by 补;验收标准可能 base commit 就为真,需人工核"什么观察证明它为假";implement 完成后不关票,frontier 永不前进,票状态自己维护。

原文 ↗ /skills-to-tickets

按票构建The /implement Skill

  • 主链构建步:指向 ticket、spec 或刚谈定的计划,五拍完成——读票定 seam、驱动 /tdd 红绿循环、频繁 typecheck 与单测、末尾跑全量、运行 code-review 后 commit 到当前分支;绝不重开计划、不再采访。
  • disable-model-invocation,必须手敲 /implement;一次调用一张票,票间 clear context;计划只在对话里时调用时要说明,否则它会去找不存在的文件。
  • 坑:收尾不关票、不勾验收标准(链式依赖会卡死 frontier),也无 PR 模式,直接 commit 当前分支;code-review 看的是 <fixed-point>...HEAD,commit 前跑看不到改动,先提交再评审;同一 checkout 并行多个 session 会互踩(amend 错位、丢 stash、上错分支),要并行用 git worktree(stash 仍共享);#42 这类短引用可能解析到错误列表,传完整 URL 并让它先复述标题;非平凡票超 100k tokens 属正常,票太大回 to-tickets 拆。

原文 ↗ /skills-implement

双轴代码评审The /code-review Skill

  • 对 HEAD 与你指定的 fixed point 之间 diff 做两轴评审:Standards(是否符合仓库文档化规范 + 12 条 Fowler smell 基线)与 Spec(是否兑现 issue/spec 要求),各跑独立 sub-agent;结论不合并、只报每轴最差问题,避免一轴及格掩盖另一轴失败。
  • 必须提供 fixed point,ref 打错或空 diff 会当场拒绝;Spec 轴按 commit 引用→传入路径→docs/specs/.scratch 同名文件→问你 的顺序找 spec,找不到就明说而非编造需求;两个轴都跳过 linter 已管的事。
  • 最常见问题:与 Claude Code 内置 /code-review 同名冲突(删内置 skill 或 fork 改名);sub-agent 会再次调用 /code-review 无限繁殖(有 50+ agent 的报告),fork 修法是在两个 sub-agent 提示里加"不要再调用"。
  • 只评审已提交改动(三点 diff 不含 staged/工作区);findings 是假设不是证据,逐条核对引用;每次重跑都会找到新问题,把通过当线索清单,别循环跑到干净。

原文 ↗ /skills-code-review

Getting Started · 起步

2 篇

新仓库先跑 setup 登记,迷路时问路由器。

一次性初始化配置The /setup-matt-pocock-skills Skill

  • 每仓库跑一次的 setup:回答三个问题(issue tracker 在哪、triage 标签叫什么、领域文档放哪),写入 docs/agents/ 下的 issue-tracker.md、domain.md、triage-labels.md,并在 CLAUDE.md/AGENTS.md 追加 "## Agent skills" 段;其余 skill 运行时读这些文件,故换 tracker 不用改任何 skill。
  • 不绑 GitHub:GitHub/GitLab/本地 .scratch/<feature>/ markdown 是内置模板,"other" 路径用一段文字描述工作流即可接 Jira、Linear、Azure DevOps;GitHub 与本地 markdown 是二选一,不要叠加。
  • prompt 驱动而非脚本:读 git remote 与现有文件后先提议再写,大多数运行只需确认两次。
  • 已知坑:不会替你创建 tracker 里的标签(gh label create 要自己来);仓库残留 CLAUDE.md 时会写进 Codex 读不到的文件(未修);无用户级全局模式,每仓库各留一份;升级后行为漂移就重跑一次。

原文 ↗ /skills-setup-matt-pocock-skills

技能路由器The /ask-matt Skill

  • 手工维护的路由器:描述你的处境(有想法没起点、外部 bug 涌入、session 过长、两个 skill 分不清),它给出该用的 skill 或流程序列,只推荐不动手;必须手敲 /ask-matt,且只认识 mattpocock/skills 这一套。
  • 核心是 flow 而非清单:主流水线 grill→spec→tickets→implement→review,加 on-ramp(triage 等)、standalone、底层词汇层三类路径;另一个概念是 phase boundary——continue//clear/handoff/subagent//compact 五选项的决策树,/compact 排最后而非首选。
  • 已知 bug:多数 skill 设了 disable-model-invocation,导致它误报"未安装"(13/22 个中招),照常输入斜杠命令即可;对其他 skill 行为的描述来自自己的一行摘要,可能失真,关键断言要让它先打开那个 SKILL.md。
  • 想让 implement 关票这类定制,别按它说的改 SKILL.md(更新会覆盖),写进自己的 CLAUDE.md/AGENTS.md。

原文 ↗ /skills-ask-matt

Shaping · 塑形

3 篇

动手之前把问题的形状摸清。

多会话决策地图The /wayfinder Skill

  • 面向大于一个 session、路线不清的工程:先写定 destination,再在 tracker 上建一张 wayfinder:map 主 issue 加子决策票(只决策不施工),地图含 Decisions so far、Not yet specified(雾)、Out of scope 四区块;frontier = 无阻塞未认领的票,认领即 assign 自己;票一律用名字不用 #42。v1.1 前叫 decision-mapping。
  • 决策票四型:grilling(HITL 默认)、prototype(谈不拢的观感问题)、research(AFK,charting 时自动并行起 subagent 于 research/<name> 分支)、task(纯手工解锁动作,最易被 agent 写成产品代码)。
  • 坑:"plan, don't do" 的豁免写在 agent 自己维护的 map Notes 里,读别人建的 map 先查 Notes;大地图会退化成瀑布(27 票走到 13 票已作废),应限定 destination 并大量 prototype;三段式提问过长致决策疲劳,可降 reasoning effort;地图清空后仍须 /to-spec #<map_issue> 收敛,不能直接进 implement。

原文 ↗ /skills-wayfinder

一次性原型The /prototype Skill

  • 用即弃代码回答一个具体设计问题:问题先行,无测试、无错误处理、无抽象;model-invoked,grilling 谈不拢的问题就该停下来做原型。wayfinder 地图上的 prototype 票就是由它解决。
  • 两个分支:逻辑/状态问题产出单文件可分享 HTML(状态面板、自由试玩、分 scenario 的引导 walkthrough),底层是可搬进真实代码的纯逻辑模块;外观问题产出同一路由下结构迥异的多个 UI 变体(?variant= 切换),只换配色不算原型。
  • 原型不再删除:答案(结论+所答问题)落进 commit/ADR/issue,代码留在 main 之外的 prototype/<name> 分支并在实现 issue 上留指针,永不合并。
  • 坑:名字太通用,agent 会在该 /implement 时误荐 /prototype;整 app 级 demo 是另一种产物,会以动量变成生产代码;能用嘴答清的问题别烧 token;当天答不完说明问题切太大。

原文 ↗ /skills-prototype

委托式一手调研The /research Skill

  • 只读一手来源(官方文档、源码、spec、第一方 API)回答仓库外部的事实问题,每条论断带引用,产出一份 Markdown 文件落在仓库现有笔记目录;阅读由 background agent 执行,你的会话继续干活。产出是短命事实,ADR 才是长效决策。
  • 与 grilling 的分界在答案的保质期;文件不会被后续会话自动复用,要主动喂给 spec/grilling/ticket;社区共识是研究文件不进 git,过期反会毒化上下文。
  • 坑:嵌套 bug(issue #530)——后台 agent 会再开后台 agent,有报告单任务烧 450k tokens,调用后盯后台任务列表并手动停多余项;来源可信度由模型自判,无白名单无校验,抽两三条引用验证是否真落到一手来源;无停止判据,问题要问窄(一个 API、一个行为),别问"研究 X"。

原文 ↗ /skills-research

Upkeep · 维护

5 篇

仓库日常:重构、排障、冲突、积压、引导。

架构加深扫描The /improve-codebase-architecture Skill

  • 扫描代码库找"加深机会"(浅模块可变深之处),产出自包含 HTML 报告到系统临时目录 architecture-review-<timestamp>.html;全程不改代码,选定候选后进入 grilling,产出的是决策不是 diff,再走 to-spec→to-tickets→implement。
  • 两个防泛化过滤器:候选必须过 deletion test(删掉该模块是集中复杂度还是散给调用方);默认先读近期提交、偏向活跃变更路径。卡片分 Strong/Worth exploring/Speculative 三档,全 Speculative 即"没找到东西"。
  • 周期性维护工具,不在主链上;最有效用法是对着即将开工的 spec 问 "how can we make this change easy?"。
  • 坑:弱模型会跳过报告直接拷问你一个想法(可说 "don't grill me, just show the report");报告从 CDN 加载 Tailwind/Mermaid,离线或 SRI 拦截时静默变裸 HTML,需改用内联 CSS 与手绘 SVG;一候选一会话;失控的八年老库上效果有限,可先 grill-with-docs 建词汇。

原文 ↗ /skills-improve-codebase-architecture

疑难 bug 诊断The /diagnosing-bugs Skill

  • 六阶段诊断硬 bug 与性能回归:建复现→最小化→3-5 条可证伪假设排序(唯一人工检查点)→插桩(日志统一 [DEBUG-xxxx] 标签便于一键清除)→先写回归测试再修→清理,验证过的假设写进 commit message。
  • 核心闸门:没有一条"红→绿"的紧反馈循环(快、确定、精确命中症状、agent 可无人跑)就不许提任何理论;loop 阶梯从失败测试到 HITL bash 脚本(scripts/hitl-loop.template.sh);flaky bug 的目标是提高复现率而非干净复现;实在建不出要明说并停下,不许硬猜。
  • model-invoked,最被抱怨对小问题过度触发(#578,GPT 系尤甚),说 "just answer this" 或关掉自动触发;只诊断已知症状,不做性能普查;与 triage 的验证步骤重叠但更深,两边文档互不引用。
  • 坑:插桩与修复之间无人工确认门(#124);复现输出与 HAR/日志不做脱敏,凭据可能进 issue/PR(#674),脱敏是你自己的事;自带 .sh 会触发 Snyk 误报;找不到正确 seam 时会明说并转介 improve-codebase-architecture。

原文 ↗ /skills-diagnosing-bugs

逐块解决合并冲突The /resolving-merge-conflicts Skill

  • 接手进行中的 merge/rebase,逐 hunk 解决后运行仓库自己的检查并完成提交;把冲突当意图冲突而非文本冲突:先回溯每边的 primary source(commit/PR/issue),能兼容则两边都保,真冲突才按合并目标取舍并明说代价,绝不发明新行为糊弄。
  • 明确禁止 --ours/--theirs 式开关,也没有 --abort 选项(abort 只会把同一冲突原样还给你);提交前必须找到并跑绿 typecheck/tests/format。
  • model-invoked;适用面窄:git 已停在冲突上才用;合并干净完成后的行为异常归 diagnosing-bugs,规划如何少撞分支则没有对应 skill。
  • 社区共识:不必为避免冲突给并行 agent 划文件分区,但大重构要先落地;worktree 并行时,合并回最好由写了该改动的那个 session 执行,因为只有它记得意图——把所有冲突攒给最后一个 agent 等于丢掉本 skill 要重建的上下文。

原文 ↗ /skills-resolving-merge-conflicts

外来 issue 分诊The /triage Skill

  • 只处理"别人提的"原始 issue 与外部 PR;你自己经 to-tickets 生成的票已 agent-ready,再跑 triage 是浪费。每条目归一个 category(bug/enhancement)+一个 state(needs-triage/needs-info/ready-for-agent/ready-for-human/wontfix),推荐并等待,不自动打标。
  • 出 brief 前先验证:按报告者步骤复现 bug,或 checkout PR 跑相关测试;同轮做 redundancy(按领域概念而非措辞查重)与 prior rejection;被拒的 enhancement 在 .out-of-scope/ 留概念文档,同类请求再来会翻出旧决定反问你。
  • 核心产物是 agent brief:写类型、签名、行为契约,永不写文件路径与行号,耐得住躺几周;所有评论以 "This was generated by AI during triage." 开头。
  • 坑:setup 不创建标签,gh 会报 label 不存在(#616),先自己 gh label create 五态两类;五态不够用(blocked/deferred/implemented 缺位,#139/#297);批量跑整条 backlog 时 agent 会偷懒只读 issue 正文不读评论,要明说逐条读评论;支持 Linear/GitLab/本地 markdown。

原文 ↗ /skills-triage

人工流程向导脚本The /wizard Skill

  • 生成一个交互式 bash 脚本,由人在自己机器上执行第三方服务配置、一次性迁移等手工流程:自动开 URL、提示点哪抄哪、密钥盲输、幂等写入 .env 与 gh secret/variable,收尾汇报跳过项;agent 只写脚本绝不运行,靠 bash -n、shellcheck 与"set_secret 名与 CI 引用对齐"做静态校验,第一次真跑就是测试。
  • model-invoked:构建途中撞上"必须人来点"的步骤会自动造向导,取代往聊天里倒六条步骤;先读 .env*、docker-compose、CI 里的 secrets.*/vars.* 引用圈定缺失值,确认 stage 清单后才映射具体点击路径,不清楚的 UI 会查文档或问你而非编造。
  • 模板在 STAGES 标记之上是固定库,不可手改,保证进度、确认门、跨平台开 URL(含 WSL)等 UX 一致。
  • 坑:不能回退改错值,只能 Ctrl-C 重跑(已存值作默认回填);ask 输入框方向键失效只插 ^[[D(#741),用退格删;不检查第三方服务侧已有什么;scoping 时别把密钥贴进聊天,否则照样进 context。

原文 ↗ /skills-wizard

Productivity · 效率

6 篇

不碰代码的日常杂务:对齐、交接、问卷、学习、复述、写作。

无状态想法拷问The /grill-me Skill

  • 最便携的 grilling 入口:不进 repo、不写任何文件,把一个松散想法(功能、方向、商业决策、写作皆可)访谈到可承诺;本体只是一行"跑 /grilling",必须同装 grilling;fresh session 开场,plan mode 要关(它会催着出计划)。
  • 按轮提问,每轮是整个 frontier(前置已落定的全部问题),典型四轮 46 问;frontier 清空即结束。
  • 成败在你不被动:连续附议 46 次会得到 agent 写的、你点头的伪计划;该说"我不知道"就说,谈不拢的问题转 /prototype 做出来再看;session 太长会滑入 dumb zone,问题质量下降,规模太大就先拆再各自 grill。
  • 收尾把同一会话直接交 /to-spec,别 clear;想一问一答,往全局 CLAUDE.md 加 "When grilling, ask one question at a time.";grilling 靠模型对系统如何崩坏的直觉,值得用最好的模型。

原文 ↗ /skills-grill-me

会话交接文档The /handoff Skill

  • 把当前会话压缩成一份 handoff markdown,写到 OS 临时目录,供新 harness、新目录、同事或并行分叉接续;买的是可移植性而非压缩——没有东西要"移动"时就该用 /compact;phase 边界五选项(continue/clear/handoff/subagent/compact)里它是第三顺位。
  • 文档只带活线程(在做什么、为什么、下一步)加 suggested skills 段;spec/ADR/issue/diff 一律以路径或 URL 引用绝不复制,写前脱敏密钥;已写下来的东西不重复搬运。
  • 最被忽略的用法是分叉:自己留在原会话,把上下文副本交给并行 agent(典型是和 /prototype 的两次往返)。
  • 坑:文件在临时目录,路径长且各 OS 不同,Codex 等环境会话间清空,/private/tmp 重启即失——下一会话不会马上开始就自己拷到持久处;交给新 agent 时给文件路径,别把摘要塞进 shell 命令(反引号与 $(...) 会被静默截断);常见批评是"记 what 丢 why",调用时说明下一会话目的,交接前通读并把未验证断言降级。

原文 ↗ /skills-handoff

异步问题清单The /to-questionnaire Skill

  • 把"卡在别人脑子里"的决策变成一份 Markdown 问卷(to-questionnaire-<slug>.md,写在当前目录),交给客户、领域专家、异团队同事异步填或会上同过;只生成不发送,投递自己来(贴 ticket、Slack、邮件均可)。
  • 只访谈"发送"不访谈"主题":两问定案——给谁(定语气与需携带的背景量)、要拿回什么(逐条对应成检查清单);正文按重要性排序、主题分组、一题一问、附答案占位与 why-this-matters,明确允许"我不知道"。
  • 不是分支问卷,也不支持多收件人:答案散在三人手里就跑三次;无 ingest 阶段,想接住 grilling 会话必须在同一会话里调用。
  • 与 /grill-me 的分界是答案在谁脑子里:挖自己用 grill-me,挖别人用它;回收的答案是原材料,喂给新一轮 grilling、grill-with-docs 或 to-spec。

原文 ↗ /skills-to-questionnaire

跨会话教学工作区The /teach Skill

  • 把所在目录变成固定教学工作区,跨多个 session 学一个主题,产出短小的自包含 HTML 课程:MISSION.md(为什么学,缺了先访谈补上)、RESOURCES.md(先找高信来源再教,不信模型参数记忆)、lessons/*.html、reference/*.html(真正会反复查的速查/算法/词表)、learning-records/*.md(ADR 式学习记录,决定教什么)、assets/(共享组件);推荐放独立 repo。
  • 理念是 storage strength 而非流畅感:检索练习+间隔+交错,quiz 是真门槛;按 mission 与学习记录挑"最近发展区"内的下一课;需要现实判断的问题会指向社区让你去验证。
  • 坑:路径解析 bug(#377)会把课程写进 ~/.claude/skills,开工前确认第一课落点并显式指定目录;测验正确答案总在 A 位(#335,33/33),可在自己的 assets/ 加洗牌组件修;无入学评估(#725),首条消息要自报水平并出声纠偏;不安排间隔复习、不知何时该停(要复习需明说);有编造魔方解法的实例,引用必须自己核。

原文 ↗ /skills-teach

没听懂就喊停The /wait-what Skill

  • 全库最短的 skill(三行,刻意如此——对抗啰嗦的 skill 靠变长永远赢不了):在你跟不上时输入 /wait-what,agent 用平实英语重讲刚才的内容,补上缺失的前提,并复用 CONTEXT.md 里的项目词表。
  • 设计关键在引导词 wait:它指向你的状态(理解在此失败),而 "be concise"、/tldr 一类只约束输出,只会得到更短更糊的电报体;wait 同时要来更少的话和缺掉的上下文。
  • 只有你自己知道何时掉队,所以 agent 不会自动触发;它修的是当前会话这一条消息,根治黑话要靠 grill-with-docs 提前建立共享语言。
  • 没有 CONTEXT.md 也能用,只是少了领域词汇那一半;合格标志:重讲更短且更清楚而非更短且更冲,补的是前提而不只是删词,连用两次不退化。

原文 ↗ /skills-wait-what

面向 agent 的写作参考The /writing-for-agents Skill

  • 写 agent 要读的任何文档(skill、AGENTS.md/CLAUDE.md、spec、运行时 prompt、README)都适用的参考规范;v1.1 前叫 writing-great-skills,skill 专属机制(frontmatter、model/user-invoked、router skill)拆到链接的 SKILL-MECHANICS.md。
  • 核心是两种预算:context load(每轮常驻上下文的成本)与 cognitive load(你记住有哪些文档的成本);默认动作是删除而非解释——复述模型已知内容的句子是 no-op,只烧 context 不改行为,逐句做 no-op 测试(删掉后行为变没变)。
  • 五个杠杆:context pointers(措辞决定 agent 是否真的去读)、信息层级与 progressive disclosure、completion criteria、leading words(如 tight、tracer bullet)、剪除 duplication/sediment/sprawl。
  • model-invoked,建改 skill 或 AGENTS.md 时自动触发;让 agent"精简"会按长度乱砍功能,要用行为不变性判断;文档变好时会短得让你吃惊,重复是最可靠的未测试信号。

原文 ↗ /skills-writing-for-agents

Reference · 参考纪律

4 篇

被其他 skill 复用的底座与纪律。

拷问式访谈原语The /grilling Skill

  • grilling 家族的 primitive:把主题建模成 design tree,每轮问整个 frontier(前置已全部落定的决策),13 问约 3 轮而非 13 轮;问题编号带标题、推荐答案独占 ➡️ 行,可按号作答;全家唯一 model-invoked 的成员,通常由别的 skill 代跑,直接敲 /grilling 得到纯访谈。
  • 事实与决策分离:环境能答的派 sub-agent 去查,决策必须等你;frontier 清空后还需你确认"理解已共享"才收工,弱模型会提前开建(往 CLAUDE.md/AGENTS.md 加一句不经允许不得实现)。
  • 已吸收 batch-grill-me;想要一问一答,CLAUDE.md 写 "When grilling, ask one question at a time."(读慢者、二语者常用,是受支持的退出);frontier 是模型判断而非计算图,同轮问题仍可能事后互相牵连,告知后下一轮重开受影响分支。
  • 坑:推荐行有时在反对问题原措辞,认同推荐等于答 no;grill-with-docs 可能没把它载进来(症状:一次性倾倒全部问题且无推荐),直接问 agent 载了哪些 skill 通常能恢复。

原文 ↗ /skills-grilling

领域建模与统一语言The /domain-modeling Skill

  • 主动纪律:设计过程中维护 ubiquitous language——挑战与词表冲突的术语、把含混用词逼成精确词、用具体场景压测关系;术语当场写入 CONTEXT.md(含 _Avoid_ 弃用同义词),决策同时过三关(难逆转、缺上下文会意外、真实权衡)才 offer 一份 ADR 到 docs/adr/;两处皆惰性创建。
  • model-invoked 但自动加载是全 skill 最弱一环:grill-with-docs/wayfinder 点名时模型常只载 grilling,发现访谈跑完 CONTEXT.md 没动,就手动点名调用。
  • 会拿你的话对照代码:你说支持部分取消而代码只整单取消,会当场停下要你裁决;但只查代码与已提交的 CONTEXT.md/ADR,不搜 issue tracker,几个月前争论过的命名会当新问题重提(可写进 docs/agents/domain.md 缓解)。
  • 坑:CONTEXT.md 被当垃圾场长成三千行 spec 是最高频投诉,用 /grill-with-docs 明令"more concise, remove implementation details";ADR 格式不可替换,与团队既有规范冲突只能本地改;一天的活别上词表;未经审阅的 agent 词表会变成后来会话信以为真的伪知识。

原文 ↗ /skills-domain-modeling

深模块设计词汇表The /codebase-design Skill

  • 纯参考、无流程、无产物:精确定义 module/interface/depth/seam/adapter/leverage/locality,禁用 component/service/boundary 等含混词,附四原则(deletion test、接口即测试面、两个 adapter 才算真 seam 等);depth 刻意不用 Ousterhout 的行数比定义,改用 leverage。
  • 两份按需加载的支撑文件:DEEPENING.md(依赖四分类决定怎么测)与 DESIGN-IT-TWICE.md(并行 sub-agents 产出 3+ 个迥异接口再比 depth/locality/seam);与 domain-modeling 并列为词汇层,一个管模块形状、一个管领域用词,常一起用。
  • 正确用法是待在 driver skill(grill-with-docs、improve-codebase-architecture、tdd)下面被引用,而不是直接对着它开工。
  • 坑:被当流程驱动时会自己编排、重探代码、烧 100k tokens(#449,未修);TypeScript 如何强制深层模块没有 shipped 答案,Matt 的答案是 Effect 或 dependency-cruiser(#458);DESIGN-IT-TWICE 写死了 Claude Code 的 Agent tool,跨 harness 可移植性差(#564);glossary 刻意保持小,connascence 等增补提案均未合并。

原文 ↗ /skills-codebase-design

测试先行循环规则The /tdd Skill

  • 参考型 skill(自己不驱动会话,由你或 implement 驱动):红-绿循环规则——一个失败测试,刚好通过的实现,再下一个行为;refactor 阶段 2026 年 6 月被删(agent 基本不做,重构归 code-review),但触发语 "red-green-refactor" 仍有效,错位记录在 #589。
  • 绝对规则:未经你确认的 seam 不写任何测试,先列出候选公共边界等你拍板;单独调用时直接问你,候选只给名字不给取舍是最高频摩擦(#607),先让它讲各 seam 的利弊与代价。
  • 防三种反模式:implementation-coupled(改内部函数名就红)、tautological(期望值按实现同款算法重算,应来自已知字面量或 spec)、horizontal slicing(先铺一批测试再写代码);mock 只许在系统边界(外部 API、时间、随机),不 mock 自己的模块;首周期是打通全路径的 tracer bullet。
  • 坑:无判断"该不该上循环"的能力(#746),配置/接线类改动跑它会得到复述实现的自证测试;对兄弟 ticket 无感知(#129),传 spec 有帮助;偶尔仍先写实现再补测试,严格执行靠人盯;浏览器 E2E 慢,宜在 CLAUDE.md 声明行为可用后再写。

原文 ↗ /skills-tdd

版本沿革(changelog,5 篇,未展开):v1(token 省 63%)→ v1.1(wayfinder/to-spec/to-tickets)→ v1.2(/wait-what、Claude Code 插件)→ ubiquitous language 改名 grill-with-docs → handoff/prototype/review。见 /skills/ 目录。

§2 · DICTIONARY

AI 编码词典(69 条 × 7 组)

给 agentic coding 一套精确词汇,每条都是「工程师能用的平实英语」定义。目录页:/ai-coding-dictionary,源仓库 mattpocock/dictionary-of-ai-coding。以下为全量条目的中文速览(释义为编译,链接指向原文)。

The Model · 模型本身 16 条

AI一个移动的标签,不是具体技术——永远指向「计算机新学会的、令人惊艳的事」,当下=大语言模型。
Model参数本身。无状态,只做下一 token 预测,自己无法做任何 agentic 的事。
Parameters模型内部的数字(常以十亿计),训练时调定;模型知道的一切都在里面,又称 weights。
Training用海量文本调整参数、提升下一 token 预测的过程。
Inference运行训练好的模型生成输出;每次 provider 请求都在发生,参数保持固定。
Effort模型回答前「思考多少」的旋钮:更努力=花更多输出 token,换难题上更高的成功率。
Token模型读写的原子单位,约词大小;上下文窗口、成本、延迟都按 token 计。
Next-token prediction模型唯一的工作方式:从上下文采样一个下一 token、追加、再跑一遍。
Non-determinism相同输入可能不同输出;来自文本生成方式与 provider 的服务方式。
Model provider提供推理服务的一方:通常远程(Anthropic / OpenAI / Google),也可以本地(Ollama、llama.cpp)。
Harness把模型变成 agent 的一切外围:工具、系统提示、上下文窗口管理、权限、hooks。
Model provider requestharness 与 provider 之间的一次往返:送去上下文,带回一个响应。
Input tokens每次请求 harness 发去的 token,费率低于输出。
Output tokens模型生成的 token,生产成本更高,计费也更高。
Prefix cacheprovider 侧缓存:连续请求跳过共享前缀的重复处理,这部分按更低费率计。
Cache tokens命中前缀缓存的输入 token,费率低得多。

Sessions, Context Windows & Turns · 会话与上下文 8 条

Stateless不向前携带信息:模型跨请求无状态,agent 默认跨会话也无状态。
Contextagent 当下能获取的、与任务相关的信息。
Context window每次请求模型能看到的一切:有限、因模型而异、是模型感知世界的唯一表面。
Stateful向前携带信息:会话跨 turn 有状态;配记忆系统可跨会话有状态。
Agent套上 harness(工具+系统提示+上下文窗口)、与用户轮流对话的模型——「运动中的模型」。
System promptharness 在每次请求前加上的指令——agent 的常备简报,一个会话内通常稳定。
Session一段有界的交互:从空开始、不断累积,清空/关闭/压缩成新会话时结束。
Turn一条用户消息 + agent 响应它所做的一切(含一次或多次 provider 请求),直到交还用户。

Tools & Environment · 工具与环境 10 条

Environmentagent 作用的世界:harness 之外、经工具结果感知、经工具调用改变的一切。
Filesystem文件与目录树——编码 agent 的默认环境。
Toolharness 暴露给 agent 调用的函数(Read / Write / Bash / Search)——agent 感知与作用于环境的途径。
Tool call模型输出里「点名某工具 + 参数」——只是结构化文本,必须由 harness 读取执行。
Tool resultharness 执行后送回的内容——文件内容、输出或错误;agent 看环境的唯一视图。
MCP把外部工具服务器插进 harness 的协议——agent 获得自带工具之外的工具的方式。
Permission request执行未预批准的工具调用前给用户看的确认——把人放进环里的机制。
Permission modeagent mode 中管权限的部分:哪些调用触发确认、哪些自动执行。
Agent mode预设包 = 权限模式 + 注入系统提示的行为指令;可会话中途切换。
Sandboxagent 运行其中的隔离环境(容器 / VM / 受限 shell),限制动作的爆炸半径。

Failure Modes · 失败模式 9 条

Sycophancy自信的附和——训练偏好「人类喜欢的回答」(包括附和)的产物。
Hallucination自信的错误输出,两种:事实性(编造事实)与忠实性(漂离已加载的上下文)。
Parametric knowledge训练时存进参数的知识,训练完即冻结;与上下文知识相对。
Knowledge cutoff参数知识的截止日期;之后的库和 API 若不加载文档就是编造陷阱。
Contextual knowledgeagent 此刻能从上下文直接读到的事实。
Attention relationship两个 token 之间的配对——有意义的配对相互影响更强;N 个 token 约 N² 对。
Attention budget每个 token 可分配给其余上下文的影响力,固定不随上下文变长而增长。
Attention degradation会话变长,注意力预算摊到更多竞争者,有效信号被稀释。
Smart zone会话早期 agent 又快又准;变长后滑进 dumb zone——马虎、健忘、易错。

Handoffs · 交接 9 条

Clearing结束当前会话开新的:下一条消息从空会话、空上下文开始。
Handoff把 agent 上下文从一个会话转移到另一个,无回路;载体可以是工件、压缩等。
Primary source本体:代码、转录、原始数据——完整权威,但加载进上下文很贵。
Secondary source对本体的一步转述:摘要、文档、压缩摘要——便宜,但天然有损。
Handoff artifact作为交接载体的文档——一个会话写给另一个会话读。
Spec描述多会话工作的交接工件:写「建什么」而非每个会话怎么干;由 ticket 组成。
Ticket界定一个会话工作量的交接工件:可独立、可挂在 spec 下;兄弟 ticket 间可互相阻塞。
Compaction在内存里完成的交接:旧会话历史被摘要后作为新会话的种子——细节换空间,有损。
Autocompact上下文窗口将满时由 harness 自动触发的 compaction。

Memory and Steering · 记忆与转向 6 条

Memory system让 agent 跨会话有状态的尝试:持久化到环境、会话开始时重载。
AGENTS.md环境中的文件,harness 在会话开始时装进上下文——项目给 agent 的常备简报。
Progressive disclosure只加载 agent 此刻需要的上下文,其余用指针指路——借自 UI 设计。
Context pointer文档中指向另一文档的提及,任务需要时才拉进上下文。
Skill打包成单位的可教能力——平时不占上下文,被指针按需拉入。
Subagentagent 经工具调用派生的 agent:独立会话运行、只回报一个工具结果,不能再派生。

Patterns of Work · 工作模式 11 条

Human-in-the-loop人与 agent 会话内配对:审查、纠偏、实时协作。
AFK用户启动会话后离开(away from keyboard),agent 无人值守运行。
Automated check环境中运行的确定性验证:测试、类型、lint、build、pre-commit 钩子——只判 pass/fail。
Automated reviewagent 审另一个 agent 的活(常用不同模型或系统提示)——非确定性,会形成判断。
Human review用户读 agent 产的代码并形成判断——读 diff 算,读摘要不算。
Vibe coding不做人工审查、把 diff 当黑盒接受的工作模式。
Design concept用户与 agent 共有的「在建之物」共识,独立于任何资产之外。
Grilling发展 design concept 的技术:agent 苏格拉底式面试用户,一次敲定一个决策。
Prototyping对话保真度不够时,让 agent 造个快速粗糙的版本,供大家对着实物讨论。
DX开发者体验:代码库与工具链让人类多容易把活干好——文档、反馈速度、报错质量。
AXAgent 体验:环境为 agent 干好活准备得如何——检查、架构、白拿的上下文。

§3 · COURSES

课程与系列(逐课展开)

The AI Engineer Roadmap · AI 工程师路线图

7 课

做 AI 应用前的概念地基,官方推荐顺序(课程目录)。

什么是 AI EngineerWhat Is An AI Engineer?

  • AI Engineer 是用 AI 能力构建应用的软件工程师,源自 Latent Space 的《The Rise of the AI Engineer》;不需要线代、不需要从零训模型、不需要读过 Attention 论文
  • 与 ML Engineer 的分界在 API:AI Engineer 通过 API 用模型做应用,ML Engineer 造这些 API;前者用 Python+TypeScript,后者只用 Python
  • 远不止 prompt engineering:还要建评测框架、反馈闭环、多模型架构、安全合规与成本优化
  • 区别于 AI-assisted Developer(用 Cursor/Copilot 提效的开发者);Web 开发者凭借 UX 与交付直觉可平滑转型,TypeScript 生态成长很快

原文 ↗ /what-is-an-ai-engineer

LLM 能用来做什么What Can You Use LLM's For?

  • 适合的场景:非结构化数据转结构化数据(如 19 世纪观鹰日志转表格)、标注与分类(改一个 prompt 即可变身分类器,无需训练数据)、问答、agent
  • 好用例分两类:雇人太贵的任务(数据转换、分类)与确定性系统搞不定的任务(问答、文本生成、agent)
  • 不适合:naive chatbot——guardrail 覆盖面有限,一个执着的用户就能越狱,一条不当回复就损害品牌(如 Gemini 让用户去死事件)
  • 经验法则:能确定性构建的就确定性构建;LLM 是概率系统,天然有 hallucination 与 sycophancy 两种失败模式

原文 ↗ /what-are-llms-used-for

什么是 LLMWhat Is An LLM?

  • LLM 本质是一个巨大的压缩文件(约 1TB 的 zip),内容是 16-bit float 参数;参数越多越聪明但越慢,70B 比 7B 慢约 10 倍
  • 推理(inference)是把文本送进模型取回响应,远比预训练便宜,笔记本就能跑;采样策略有 Greedy、Top-K、Top-P、Temperature,工程师通常只能调 temperature
  • 训练两阶段:pre-training 把海量文本压缩成参数(量级参考:10TB 数据、6000 GPU、12 天、约 200 万美元,产出约 140GB 文件),post-training 塑造行为与性格
  • Anthropic 可解释性研究:模型跨语言共享概念、写作时提前规划、有时会编造听起来合理的推理而非展示真实思考过程

原文 ↗ /what-is-an-llm

选 LLM 前要问的 5 个问题5 Questions To Ask Before Choosing An LLM

  • 五个决策维度:Open 还是 Closed、成本、latency、性能、context window;这不是一次性的选择,要随模型迭代反复做
  • 三类获取方式:模型供应商(OpenAI/Anthropic 等闭源)、API 供应商(Hugging Face/Groq 托管开源模型)、自托管(最灵活最贵,数据可控);建议先从第三方 API 起步
  • 成本按 token 计(输入+输出),token 单价正打价格战;latency 看 TTFT 与 TPOT 两个指标
  • benchmark 有 overfit 风险,只能当早期参考;reasoning 模型(如 o1)擅长规划类任务但更贵更慢;context window 同时计入输入与输出 token
  • 真正可靠的评估只能在你的应用里跑自建 evals

原文 ↗ /how-to-choose-an-llm

AI Engineer 的思维方式The AI Engineer Mindset

  • LLM 应用是概率系统:demo 容易、production 化难;起点是"Vibes-Only Trough"——真实用户的用法远超预期,暴露预想不到的失败模式
  • 出路是爬"Data-Driven Slope":建评测框架、收集数据、按数据决策;实验期质量剧烈波动是常态,别慌,系统追踪每次迭代
  • 成功标准必须具体可测:如准确率 92%、95% 的分类在 500ms 内完成、高置信预测 90% 符合人类判断;拒绝"表现好"这类模糊目标
  • 数据是最有价值的资产:每次用户交互都能用于改进 prompt、微调模型、追踪成功率、发现 edge case;从点赞/点踩按钮起步
  • 直白结论:第一版注定不好,靠真实用户数据驱动的持续改进文化取胜

原文 ↗ /the-ai-engineer-mindset

你的应用只和它的 Evals 一样好Your App Is Only As Good As Its Evals

  • evals 是 AI 工程师的 unit tests:从概率系统里榨取可预测性,是 AI 应用生产化不可缺的一环
  • 传统测试依赖确定性输入输出,LLM 系统"没有小改动"(大小写都可能改变输出),只靠 manual QA 是致命的
  • 三类 evals:确定性断言(pass/fail)、人工评估(早期唯一选择,贵而慢)、LLM-as-a-judge(用另一个 LLM 打分,成本高,建议本地小集合+每日大集合分批跑)
  • eval 的结构:data(测试 prompts)+ task(生成函数)+ scorers,输出 0-100% 分数
  • 数据飞轮:用户点踩→转成新 eval→改进系统到通过→重新部署;evals 应居于反馈循环的中心

原文 ↗ /what-are-evals

改进 LLM 应用的 17 种技术17 Techniques For Improving Your LLM-Powered App

  • 心态:先试简单便宜的手段,沿"复杂度地狱阶梯"从上往下,穷举简单方案再升级
  • 廉价层:写清晰的 prompt、role-based prompting、XML 标签分隔输入/约束输出、structured outputs(generateObject)、chain-of-thought、multishot 示例、temperature 调节(精确任务 0.0-0.3,头脑风暴 0.8-1.2)、tool calling
  • 中阶:LLM call chaining(拆专用步骤)、RAG(复杂度高,别当第一选择)、chunking(BM25/embeddings/hybrid/LLM rerank 检索)、agentic loops(开放任务更强但更慢)、并行调用、evaluator-optimizer、LLM router(突破单模型约 30 个工具的上限)
  • 最贵是 fine-tuning:适合已验证场景后的优化,警惕过拟合到特定模型版本;任何新技术都要用自家 evals 验证

原文 ↗ /how-to-improve-your-llm-powered-app

LLM Fundamentals · 视频课对应的文字篇

5 篇

免费视频课讲「AI 很强但很怪」;这五篇文字版把怪癖与约束讲透:token、上下文窗口、工具、agent、消息与系统提示。

什么是 TokensWhat Are Tokens?

  • token 是 LLM "思考"文本所用的数字;text→token 是 encoding,数字→文本是 decoding
  • 完整流程:tokenizer 编码输入(会话历史、system prompt、tool 定义都算 input)→ LLM 处理 → 产出 output tokens → 解码为文本
  • 输入与输出 token 都计费且单价不同;省钱手段之一是让 prompt 产生更少的输出 token
  • tokenizer 用大语料训练:先拆单字符,再合并高频字符组,组合的组合也成 token;词表越大(1000→50000→200000),同一段文本切的 token 越少、处理越高效
  • 生僻词(如 Lewis Carroll 造的 Frabjous)会被切成异常多的 token;可用 tiktokenizer 直观体验

原文 ↗ /what-are-tokens

什么是 Context WindowWhat Is The Context Window?

  • context window = input tokens(system prompt、用户消息等)与 output tokens 的总和,会随对话变长持续增长
  • 每个模型有硬编码上限:超限 API 报错,甚至可能在生成中途撞上限被截断;模型自己不够聪明,无法绕开这个限制
  • "lost in the middle" 问题:开头与结尾的消息对输出影响大,中间内容被较少关注,且 context window 越大该现象越明显
  • 结论:评估模型别只看"窗口有多大",即便支持超大窗口,用更少的 token 也总能得到更好的结果

原文 ↗ /what-is-the-context-window

什么是 ToolsWhat Are Tools?

  • 工具通过 system prompt 注入:每个工具给出名称、描述、JSON Schema 参数定义——没有魔法,就是 prompt 里的定义
  • LLM 返回带 id 与参数的 tool call 消息,这只是"指令",什么都没发生;真正的执行发生在你的机器上
  • 代码库里每个工具要有对应函数;执行结果以相同 id 的 user 消息回传,LLM 看到完整历史后做总结
  • 错误处理很关键:工具执行失败必须把错误信息回给 LLM,让它调整行为
  • 完整循环:定义工具→LLM 自选工具→本机执行→回传结果→LLM 汇总;这个简单循环就能构建非常强大的应用

原文 ↗ /what-are-tools

什么是 AgentWhat Is An Agent?

  • workflow:开发者把多步 LLM 调用与停止条件预定义在代码里,每一步调哪个 LLM、何时结束都由代码决定
  • agent:给 LLM 一组 tools,由 LLM 自己决定调用哪个工具、根据结果决定下一步、何时停止——即兴发挥,更强大但更不可预测
  • 关键区别是"谁决定何时停止";两者都涉及多次 LLM 调用,单次调用两者都不算
  • 任务明确时 workflow 往往效果更好且被低估(如并行摘要:分块→各自总结→再汇总);agent 适合步骤不明、需要即兴探索的问题

原文 ↗ /what-is-an-agent

消息、System Prompt 与 Reasoning TokensMessages, System Prompts and Reasoning Tokens

  • 与 LLM 的对话由 user 消息和 assistant 消息构成;system prompt 位于历史最前,对 LLM 可见、通常对用户不可见
  • system prompt 优先级高于用户消息(如要求用摩斯电码回复,用户叫停也仍继续),但并非绝对,存在越狱案例
  • reasoning tokens 是 assistant 消息的一部分:模型先"思考"再作答;一条消息可含多个 parts,文件(如 PDF)也借此传入传出
  • tools 流程:LLM 发出带 id 的 tool call → 应用执行 → 以相同 id 回传 tool result(通常是字符串)→ LLM 总结结果;Claude Code 与 Cursor 即基于此机制操作系统

原文 ↗ /messages-system-prompts-and-reasoning-tokens

Vercel AI SDK Tutorial · TypeScript 建 LLM 应用

16 课 + 延伸 3

前 16 篇按官方课序(课程目录),最后 3 篇为延伸。

什么是 Vercel AI SDKWhat Is Vercel's AI SDK?

  • 系列开篇:AI SDK 提供统一 API,屏蔽 OpenAI/Anthropic 等各家 LLM provider 的差异,免去换模型就重写胶水代码的痛点。
  • 由 Vercel 维护但免费开源,不需要部署到 Vercel 也不需要付费。
  • 三大组成:AI SDK Core(Node/Deno/Bun 后端)、AI SDK UI(前端 hooks 与组件)、AI SDK RSC。
  • 安装 ai 包即得 generateText/streamText/generateObject/streamObject,各 provider 另装如 @ai-sdk/openai。
  • 适用场景:流式文本、结构化输出、工具调用、agent 流程,本教程聚焦 Core 部分。

原文 ↗ /what-is-the-ai-sdk

用 AI SDK 生成文本Generate Text With Vercel's AI SDK

  • 最简用法:从 ai 导入 generateText,传入 model 与 prompt,从返回对象中解构 text。
  • 示例用 @ai-sdk/anthropic 的 claude-3.5-haiku,换成 claude-3.5-sonnet 只需改模型一行。
  • 演示封装 answerMyQuestion(prompt) 函数向 Claude 提问并拿回答案。
  • 返回对象还包含许多其他属性(后续课程展开),本课只取 text。

原文 ↗ /generate-text-with-vercel-ai-sdk

用 AI SDK 流式输出文本Streaming Text With Vercel's AI SDK

  • generateText 最后一次性吐出全部文本,体验差;改用 streamText 即可逐 token 流式返回。
  • streamText 接收的参数(model + prompt)与 generateText 完全相同,但返回 textStream 异步可迭代对象。
  • 用 for await 循环把每个 chunk 写到 stdout,也很容易接到网络请求流式推给 UI。
  • 结果还带一个 text promise,不需要流式时直接 await 即可拿完整文本。

原文 ↗ /streaming-text-with-vercel-ai-sdk

在 AI SDK 中使用系统提示词Adding System Prompts With Vercel's AI SDK

  • 想让 LLM 无论收到什么 prompt 都扮演固定角色(示例:文本摘要器),用 system prompt 预设角色与指令。
  • AI SDK 中只需给 generateText/streamText 等传一个 system 属性即可。
  • 底层等价于在消息前插入 role 为 "system" 的消息,也可以手动传 messages 数组实现同样效果。
  • 适用于所有会接触 LLM 的 API,是控制模型行为的关键手段。

原文 ↗ /system-prompts-with-vercel-ai-sdk

用 AI SDK 热切换模型Hot-Swap AI Models With Vercel's AI SDK

  • 定义 ask(prompt, model) 函数,model 参数类型用 AI SDK 导出的 LanguageModel。
  • 同一函数可传入 Anthropic、OpenAI 等任意 provider 的模型实例直接运行。
  • LanguageModel 类型天然支持依赖注入,业务函数与具体模型完全解耦。
  • 作者视之为 AI SDK 的核心卖点:换模型一行代码,应用不被单一厂商绑死。

原文 ↗ /swap-ai-models-with-vercel-ai-sdk

用 AI SDK 管理消息历史Working With Message Histories In Vercel's AI SDK

  • 核心是 CoreMessage 类型:每条消息含 role(user/system/assistant/tool)与 content,对话史就是消息数组,随对话增长。
  • 用 Hono 搭 /api/get-completions 路由,接收整个 messages 数组并原样传给 generateText。
  • 服务端保持无状态:LLM 回复取自 result.response.messages 并以 JSON 返回,由客户端负责追加与保存历史。
  • 客户端 fetch 发送历史、合并返回的 assistant 消息,数组可继续追加实现多轮追问。

原文 ↗ /vercel-ai-sdk-messages-array

在 AI SDK 中使用本地模型Use Local Models With Vercel's AI SDK

  • 用 @ai-sdk/openai-compatible 的 createOpenAICompatible 可连接任何 OpenAI 兼容 API,不限本地。
  • 示例接 LM Studio(localhost:1234)创建 provider;取模型时传空字符串即默认用 LM Studio 里已加载的模型。
  • 拿到的模型直接传进 generateText,用法与云端模型完全一致。
  • 本地模型建议设 maxRetries: 0,连不上立即失败(SDK 默认重试 3 次以应对网络问题)。

原文 ↗ /use-local-models-with-vercel-ai-sdk

用 AI SDK 获取结构化输出Structured Outputs with Vercel's AI SDK

  • 想让 LLM 返回对象而非纯文本(示例:菜谱的名称、配料数组、步骤数组),用结构化输出最有效率。
  • 先写 Zod schema 描述数据形状,直接传给 generateObject,结果的 object 拥有完整 TypeScript 类型安全访问。
  • 用 .describe() 为每个字段补充语义说明,帮模型理解要取什么,字段名不够直观时尤其有用。
  • 还可传 schemaName 并配 system prompt 约束输出风格,示例成功生成 Baba Ganoush 菜谱。

原文 ↗ /structured-outputs-with-vercel-ai-sdk

用 AI SDK 流式输出对象Streaming Objects With Vercel's AI SDK

  • 把上一课的 generateObject 换成 streamObject,即可边生成边拿到结构化数据。
  • 调用立即返回 result;partialObjectStream 是异步可迭代,用 for await 逐次读取对象的部分更新。
  • 最终完整对象需 await result.object(result 在首个 chunk 到达时就返回,所以要单独等最终值)。
  • 实际应用中把 chunk 推送到前端,让用户实时看到对象逐步成形,比干等一次吐出体验好得多。

原文 ↗ /streaming-objects-with-vercel-ai-sdk

用 AI SDK 生成枚举(分类)Generate Enums With Vercel's AI SDK

  • 经典分类场景:把用户评论判定为 positive/negative/neutral,LLM 只需返回一个枚举字符串。
  • 仍用 generateObject,但传 output: "enum" 加 enum 数组列出所有候选值。
  • 返回的 object 即枚举结果,配 system prompt 说明分类任务;示例对三种语句分别得到 neutral/negative/positive。
  • 几行代码实现情感分析,可推广到一切取值受限的分类需求。

原文 ↗ /generate-enums-with-vercel-ai-sdk

用 AI SDK 生成对象数组Generate Arrays With Vercel's AI SDK

  • 要一次返回多个对象(示例:批量生成假用户数据)时,用 generateObject 加 output: "array"。
  • Zod schema 只需描述单个元素的形状(name/age/email),字段同样建议用 .describe() 补充说明。
  • 用 system prompt 种入约束(如"用户来自英国"),返回的 object 即类型安全的对象数组。
  • 同样支持 streamObject,数组元素可以边生成边流式展示。

原文 ↗ /generate-arrays-with-vercel-ai-sdk

用 AI SDK 构建图片描述(alt text)生成器Build an Alt Text Generator With Vercel's AI SDK

  • 教你把图片传给多模态 LLM 生成 alt text(前提是模型本身支持视觉输入)。
  • 本地文件:readFileSync 读成 Uint8Array,通过 messages 数组以 content 部件 type: "image" 传入 generateText。
  • 网络图片有捷径:把 new URL(imageUrl) 直接放进 image 属性,由 LLM 侧下载查看。
  • system prompt 约束输出风格:简洁、必要时才用形容词、不超过 160 字符、用简单语言。

原文 ↗ /describe-images-with-vercel-ai-sdk

用 AI SDK 从 PDF 提取结构化数据Extract Structured Data From PDF's With Vercel's AI SDK

  • 场景:把非结构化的 PDF 发票转成可入库、可查询、可搜索的结构化数据。
  • 用 Zod schema 定义字段(总额、币种、发票号、开票方与收票方信息等),每个字段都写 .describe() 给模型最大胜率。
  • messages 数组中 content 部件改用 type: "file",readFileSync 读原始二进制并附上 MIME 类型传给 generateObject。
  • 本课组合了前两课技能:向 SDK 传任意文件 + 结构化输出。

原文 ↗ /structured-data-from-pdfs-with-vercel-ai-sdk

用 AI SDK 创建嵌入向量Create Embeddings With Vercel's AI SDK

  • 用 embedMany(批量)与 embed(单个)生成向量,模型如 openai.embedding("text-embedding-3-small")。
  • 向量是数据在高维空间的位置表示,用于度量相似性,是搜索与分类的基础原语。
  • 演示手搓最小向量数据库:数组保存 value + embedding;生产环境可用 Postgres 加 pgvector 扩展。
  • 用 SDK 的 cosineSimilarity 计算余弦相似度并排序,"Canine" 与 "Dog" 最相似(约 0.89),全程无需再调 LLM。

原文 ↗ /create-embeddings-with-vercel-ai-sdk

用 AI SDK 实现工具调用Tool Calling With Vercel's AI SDK

  • 用 tool() 创建工具:parameters 用 Zod schema 描述参数(配 .describe()),execute 执行任意异步逻辑(调 API、写库等),description 告诉 LLM 工具用途。
  • 把工具放入 generateText 的 tools 对象,并用 system prompt 引导模型调用。
  • 调试方法:解构结果的 steps,查看 steps[0].toolCalls(工具名与入参)与 toolResults(执行结果)。
  • toolResults 可以回喂给 LLM,为后续多步 agent 行为打基础。

原文 ↗ /tool-calls-with-vercel-ai-sdk

用 AI SDK 构建第一个 AgentBuild Your First Agent With Vercel's AI SDK

  • Agent 本质是反馈循环:LLM 调用工具后,根据工具返回的真实信息继续行动,从而"立足现实"。
  • 默认只走一步就停:示例中 getWeather 工具已返回结果但模型不再作答,需给 streamText 传 maxSteps 才会继续。
  • 循环两种结束方式:模型自行停止(finishReason 为 'stop')或达到 maxSteps 上限。
  • 调试仍靠 steps 查看 toolCalls/toolResults;不建议把 maxSteps 设为 Infinity,因为模型有时不会自停。

原文 ↗ /agents-with-vercel-ai-sdk

Vercel AI SDK 让 AI 技术栈面向未来Vercel's AI SDK Future-proofs Your AI Stack

  • 短文论证为何首选 AI SDK:各 provider API 表面相似实则 quirks 众多,直连易陷入 vendor lock-in 流沙。
  • 对比原生 OpenAI/Anthropic SDK 需要的 if-else 封装代码,AI SDK 只需 generateText + LanguageModel 一套代码通吃所有模型。
  • 流式差异更甚:OpenAI 与 Anthropic 的 chunk 结构完全不同,而 AI SDK 的 streamText 对所有 provider 返回统一的 textStream。
  • 附录给出支持的 provider 清单(OpenAI、Anthropic、Mistral、Google、Vertex、xAI Grok、Groq 等),学一次 API 到处复用。

原文 ↗ /vercel-ai-sdk

用 AI SDK 流式生成"下一个问题"建议Streaming In 'Next Question Suggestions' With Vercel's AI SDK

  • 常见产品模式:聊天界面实时流式给出建议的追问,帮助不熟悉对话界面的用户快速上手。
  • 用 createUIMessageStream 组合两条子流:writer.merge 并入初始 streamText 回复,再用 streamObject(Zod schema 约定 suggestions: string[])生成建议。
  • 建议作为自定义 data part(data-suggestions)以固定 id 写入流,保证前端只保留最新一份。
  • 前端用 useChat<MyMessage> 泛型获得类型安全,从最新消息的 parts 中取出建议渲染成可点击按钮。

原文 ↗ /streaming-in-next-question-suggestions-with-the-ai-sdk

用护栏(Guardrails)保护 AI 应用Securing your AI App with Guardrails

  • 模式:请求先过一道超快模型的安检,判定安全后才交给主模型(gemini-2.0-flash)正常流式回答。
  • checkIsRequestSafe 用 generateText 调 gemini-2.0-flash-lite,system prompt 要求只回一个 token:'1' 安全、'0' 拦截,因此极快。
  • 被拦截时手动向 UIMessageStreamWriter 写 text-start/text-delta/text-end 三段输出提示信息。
  • 同一"极快 LLM 判定"思路还可做请求路由:简单请求走便宜快速的模型,复杂请求才升级到大模型,省钱又保质量。

原文 ↗ /securing-your-ai-app-with-guardrails

Model Context Protocol Tutorial · MCP 实战

6 课 + 延伸 3

MCP 是「AI 的 USB-C」。前 6 篇按官方课序(课程目录),最后 3 篇为延伸。

把 GitHub MCP Server 接入 Claude CodeConnect Claude Code To A GitHub MCP Server

  • 在进入 MCP 抽象概念前,先看一个开发者实战:把 GitHub MCP server 接入终端工具 Claude Code,让 LLM 直接修改代码库
  • 用 claude mcp add 添加名为 github-server 的 MCP server,scope 选项目级
  • command 用 npx,args 用 -y @modelcontextprotocol/server-github@latest
  • env 里传 GITHUB_PERSONAL_ACCESS_TOKEN=<你的 GitHub API Key>,配置完成即可使用

原文 ↗ /connect-claude-code-to-github

用单个 TypeScript 文件搭 MCP ServerServing MCP Servers Over stdout

  • 最简 MCP server:一个 main.ts,用 @modelcontextprotocol/sdk 的 McpServer + StdioServerTransport,无需 build step
  • 用 server.tool() 定义工具:名称、Zod 描述参数、回调返回 content 数组,回调里才真正调外部 API
  • Claude Code 目前只支持 stdio transport,用 claude mcp add "weather-example" npx tsx /path/to/file.ts 一条命令接入
  • 价值:任意 TypeScript 函数都能挂到 Claude Code、Cursor、Windsurf 等 MCP host 上扩展能力

原文 ↗ /mcp-server-from-a-single-typescript-file

使用 MCP PromptsUsing MCP Prompts

  • MCP server 不止能提供 tools,还能用 server.prompt() 提供 prompt 模板,把 MCP 当作"prompt 目录"
  • 语法与 tool 类似:名称、描述、Zod 参数,回调返回 role 为 user 的 messages 数组
  • 接入 Claude Code 后,模板变成 slash command(如 /cleanTranscription),带 autocomplete,再按提示填参数
  • 作者示例:清洗口述转录稿的 prompt——不改措辞、只修格式与错字、长数字转短格式、代码加反引号、保护专有名词

原文 ↗ /using-mcp-prompts

日志:MCP 的大坑Logging: A Huge MCP Footgun

  • stdio transport 下 console.log 不可用:client 监听 stdout 收 MCP 消息,普通日志会污染协议流,轻则被吞、重则让 client 崩溃
  • sse transport 不走 stdio,可以放心用 stdout 打日志,本地也完全可用
  • 作者推荐方案:自建 logger,用 appendFileSync 同步写入 mcp-server.log 文件
  • 备选:MCP notifications(能否用于日志取决于 client 实现)或 stderr(console.error 不被 client 读取)
  • 结论:要么换不占用 stdout 的 transport,要么写日志文件

原文 ↗ /logging-a-huge-mcp-footgun

MCP 的问题:有状态服务器The Problem With MCP: Stateful Servers

  • 把 SSE transport 存在单个变量里,server 一次只能服务一个 client,第二个连上会把第一个踢掉
  • 即使按 id 存 transport,内存态仍使 server 有状态;Vercel/AWS Lambda 等请求间丢弃内存,根本没法部署,只能上长期运行的 VPS
  • 解法:把 transport 状态存进 Redis 等 key-value 数据库,server 变 stateless,即可部署到 serverless 环境
  • 参考 mcp-on-vercel 仓库,可适配任意 serverless 平台;作者推荐这是生产部署方案,但也质疑协议设计:为何不让 client 存状态?

原文 ↗ /the-problem-with-mcp-stateful-server

把你的 MCP Server 发布到 NPMPublish Your MCP Server To NPM

  • 发布到 npm 后,任何装了 Node 的用户都能用 npx -y <包名>@latest 直接运行你的 MCP server,更新自动送达
  • 入口 main.ts 顶部加 #!/usr/bin/env node shebang;package.json 的 bin 字段指向 dist/main.js(单一 bin 条目即会被 npx 执行)
  • tsconfig 编译输出到 dist;npm publish --access public 发布,需先 npm login,包名不能重复
  • 注意安全:运行来源不明的 npx 包有风险,应先审查源码

原文 ↗ /publish-your-mcp-server-to-npm

Model Context Protocol 是如何工作的How Does The Model Context Protocol Work?

  • 架构:host(Claude Desktop、Cursor 等)运行多个 client,每个 client 对接一个 MCP server;host 与 server 可用不同语言、本地或远程部署
  • 两种 transport:stdio(本地终端)与 HTTP + server-sent events(远程)
  • 协议基于 JSON-RPC 2.0:Request 带 method+params,Response 返回 result 或 error,靠 id 配对
  • 流程示例:tools/list 返回工具名、描述与 JSON Schema 输入定义;tools/call 返回 content 数组(text/image/resource)并带 isError 标志表示失败

原文 ↗ /how-does-the-model-context-protocol-work

用 TypeScript 实现 Anthropic 的 "think" 工具Implementing Anthropic's "think" Tool In TypeScript

  • Anthropic 研究提出 "think" tool:给 LLM 一个不获取新信息、不改变状态的思考工具,把想法追加进上下文日志
  • 理念呼应 ReAct 与 Reflexion:让模型在决策前有结构地反思,把重要信息存进 context 供后续使用
  • 实现:Vercel AI SDK 的 streamText + Claude 3.7,maxSteps 设 10;定义 think 工具(thought 参数),execute 只原样返回 thought 使其留存在 context 中
  • 适用于"需要遵守 policy、长链工具调用推理"的复杂任务,几行代码即可带来明显提升

原文 ↗ /implementing-anthropics-think-tool-in-typescript

两分钟了解 Anthropic 的新 Model Context ProtocolAnthropic's new Model Context Protocol In 2 Minutes

  • Anthropic 发布开放标准 MCP,用于连接"AI 助手与数据所在的系统"
  • 它是基于 JSON-RPC 的协议,让 LLM(如 Claude)与一个 long-running server 通信
  • 流程:Claude 先请求 server 列出可用 tools,再逐个调用它们
  • 官方提供 TypeScript 与 Python SDK,可自建 MCP server 接入自己的数据源或执行自定义操作

原文 ↗ /anthropics-new-model-context-protocol-in-2-minutes~hc0tx

§4 · IN THE TRENCHES

Claude Code 实战(按主题分组)

配置、钩子与状态栏

5 篇

Claude Code 本体的调教:hooks 拦截、statusline、系统提示瘦身。

如何用 Claude Code hooks 强制使用正确的 CLIHow To Use Claude Code Hooks To Enforce The Right CLI

  • 在 CLAUDE.md 写"用 pnpm 别用 npm"有两个问题:浪费全局 instruction budget(LLM 约只能可靠遵循 ~500 条指令),且非确定性、不保证生效。
  • 确定性方案是 PreToolUse hook:在 .claude/settings.json 配置 matcher 为 "Bash",脚本从 stdin 读 JSON 取 .tool_input.command,匹配错误命令则 exit 2,stderr 提示会回喂给 Claude 让它自动改用正确命令;exit 0 放行。
  • 文章附可直接粘贴的 prompt:让 Claude 把 CLAUDE.md 中可确定性化的指令(指定 CLI、禁用某些命令)转成 .claude/hooks/ 下的脚本,先与用户确认、再实现、重启 Claude Code 验证。

原文 ↗ /how-to-use-claude-code-hooks-to-enforce-the-right-cli

这个 hook 阻止 Claude Code 运行危险的 git 命令This Hook Stops Claude Code Running Dangerous Git Commands

  • Docker Sandbox 只隔离运行位置不限制命令,git 历史就在沙箱目录里,一条 git reset --hard 或 git push --force 可毁掉数周工作;该 skill 用硬性 guardrail 填补这个缺口。
  • 安装:npx skills add mattpocock/skills/skills/misc/git-guardrails-claude-code,可选项目级或全局,拦截清单可自定义。
  • 默认拦截:git push(含 --force 全部变体)、git reset --hard、git clean -f/-fd、git branch -D、git checkout . / git restore .;定位是 safe by default 而非永久禁止,可按需放行。
  • 实现:PreToolUse hook 读 stdin JSON 的 .tool_input.command,grep -E 命中危险模式即 exit 2,Claude 看到 BLOCKED 消息会理解约束并调整。

原文 ↗ /this-hook-stops-claude-code-running-dangerous-git-commands

打造完美的 Claude Code status lineCreating The Perfect Claude Code Status Line

  • status line 应显示四类信息:相对 ~/repos/ 的仓库路径、当前分支、staged/unstaged/untracked 文件数,以及最关键的 context window 使用百分比——作者约 60% 就考虑 compact 或换新会话。
  • 方案组合:npm i -g ccstatusline 提供 context-percentage(配置 "rawValue": true 只输出纯百分比),自写 shell 脚本用 git --no-optional-locks(跳过可选锁提升性能)统计 git 状态。
  • wrapper 脚本拼接两路输出,在 ~/.claude/settings.json 里把 statusLine 设为 command 类型指向它,重启生效;仓库不在 ~/repos/ 下需改脚本中的路径。

原文 ↗ /creating-the-perfect-claude-code-status-line

如何消除 Claude Code system prompt 的膨胀How To Kill The Bloat In Claude Code's System Prompt

  • 每条请求都携带隐形负载(工具定义、skills 目录、系统指令)且每轮计费;先用 /context 看分类占比,再用 logging proxy(node proxy.mjs,ANTHROPIC_BASE_URL=http://localhost:8787)把每请求落盘为 Markdown 并按体积排序工具。
  • 整功能用 disable* 旗标关:disableBundledSkills 移除全部内置 skills(slash 命令仍可输)、disableWorkflows 移除占位最大的 Workflow 工具。
  • 单个工具用 permissions.deny 写裸工具名才会把定义移出负载;"Bash(rm *)" 这类作用域规则只拦调用、定义仍在。要逐个关内置 skill 用 skillOverrides 设 "off" 或 "user-invocable-only"。
  • 注意 task tools/Workflow/worktree 等后台任务与多 agent 依赖的工具别删;重启后再跑 /context 对比,作者每轮省下数万 token。

原文 ↗ /how-to-kill-the-bloat-in-claude-codes-system-prompt

永远不要运行 Claude /initNever Run Claude /init

  • /init 生成的 CLAUDE.md 烧 token、分散注意力、迅速过时;system prompt 启动即硬编码,CLAUDE.md 每一条都在挤占真正干活的上下文。
  • LLM 有 instruction budget:一次约能遵循 300-400 条指令(大模型约 500);且 CLAUDE.md 是全局的,每条规则对每个 session 生效,成本复利放大。
  • init 生成的四类内容(package.json 脚本清单、架构描述、文件/服务引用、实现模式)要么可从源码随时发现,要么很快腐烂、主动误导 agent。
  • 解法:相信 explore 阶段按需建上下文,引导类规则放 skills 按需拉取,CLAUDE.md 几乎留空——作者全文只有 "you are on WSL on Windows",收录标准是"不可自行发现且全局相关"。

原文 ↗ /never-run-claude-init

AGENTS.md 专篇

2 篇

怎么写好「项目给 agent 的常备简报」。

AGENTS.md 完全指南A Complete Guide To AGENTS.md

  • AGENTS.md 是入 Git 的仓库级 agent 配置,位于 system prompt 之下的对话历史顶部;Claude Code 只认 CLAUDE.md,可用 ln -s AGENTS.md CLAUDE.md 软链打通。
  • 膨胀根因是"agent 犯错就加规则"的恶性循环与自动生成;指令预算有限(前沿模型约 150-200 条),文件里每个 token 每次请求都加载;过时的路径类文档会主动毒化上下文,应描述能力而非目录结构。
  • 必留的只有:一句话项目描述、非默认包管理器(或用 corepack)、非标准 build/typecheck 命令;其余用 progressive disclosure 拆进 docs/ 独立文件并互相引用,按需加载。
  • monorepo 支持子目录 AGENTS.md 与根级合并,各层只写本层内容;文末附重构损坏 AGENTS.md 的现成 prompt(找矛盾、留必需、分组拆文件、标记可删项)。

原文 ↗ /a-complete-guide-to-agents-md

我的 AGENTS.md:写出你真正会读的计划My AGENTS.md file for building plans you actually read

  • 核心是 planning loop 四步循环:先与 AI 共同 plan 对齐方案,再让它按计划写代码,然后一起测试(单测/类型检查/手动 QA),commit 后进入下一轮。
  • 跳过 plan 步骤等于让 AI 猜你要什么,会陷入幻觉与误解;planning 强迫清晰,让 AI 任务更简单、代码更好。
  • 给出的 Plan Mode 规则只有两条,可追加进 ~/.claude/CLAUDE.md:计划必须极简("Sacrifice grammar for the sake of concision"),且每个 plan 末尾列出未解决问题清单。

原文 ↗ /my-agents-md-file-for-building-plans-you-actually-read

工作流与方法论

9 篇

从阶段划分到反馈环:把工程纪律装进 AI 开发。

AI 开发七阶段方法论My 7 Phases Of AI Development

  • 七阶段:Idea(用 /grill-me 追问打磨点子)→ 可选 Research(外部依赖信息缓存进 research.md,供新 context 的 agent 免重复探索,且只在本 sprint 内有效)→ Prototyping(用一次性 route 出多个变体定设计)→ PRD(只写终态用户可见行为,不写实现)→ Kanban 票板(/prd-to-issues 拆票并标 blocking 关系)→ Execution → QA。
  • 执行阶段顺序跑票即可,票板无阻塞关系的票可并行多 agent;前置资产(research/prototype/PRD/验收标准)齐全时可 AFK 运行。
  • QA 由 agent 出 QA 计划、人做审查测试,发现的 bug 转成新票再跑 5-7 轮,迭代到生产质量;人要重点看逻辑错误、安全、性能与模式一致性。

原文 ↗ /my-7-phases-of-ai-development

Claude Code 真实特性构建全流程Real-world feature build with Claude Code: every step explained

  • 用自己 1200+ commits、637 个已关 issue 的课程视频管理应用做真实演示:/grill-me 头脑风暴 → PRD → 拆 GitHub issues → Ralph loop 自主实现 → QA 循环修问题。
  • 改造"ghost lesson"(只在数据库)与"real lesson"(有磁盘文件)的创建/删除流程,并顺手支持 ghost courses。
  • 强调这是未剪辑的实况:展示杂乱部分、QA 往返和现场决策,不是打磨过的教程。

原文 ↗ /real-world-feature-build-with-claude-code

Plan Mode 入门An Introduction To Plan Mode

  • Plan mode(--permission-mode plan 或 /plan)下 agent 只能读文件/探索/分析,不能改文件、跑命令;产出分步计划,满意后退出再执行。
  • 关键机制:计划与执行通常不清空 context,探索阶段已把相关文件装进上下文——plan mode 有效不只是因为计划文档,更是给 agent 预热 context。
  • 写作建议进 AGENTS.md:计划要极简(牺牲语法换简洁)、计划末尾列未决问题主动追问边界情况、最后放编号步骤列表(终端只看末尾)。
  • 务必用语音输入,乱语也无妨;即使自己写更快也用,因为它降低脑力疲劳、积累与 AI 协作的直觉。

原文 ↗ /plan-mode-introduction

曳光弹:控制 AI SlopTracer Bullets: Keeping AI Slop Under Control

  • 问题:AI 讨好倾向使它一次 leap 造出整层代码(全套 CRUD、中间件、鉴权),最后才连数据库,发现连接串/列类型全错——"outrunning your headlights",留下巨大 review 负担。
  • 解法(源自《程序员修炼之道》):先做一个贯穿所有层的细小垂直切片,立即测试、拿反馈,再在全新 context 里做下一片。
  • 必须 explicit 写进 prompt/Ralph loop,否则 AI 默认横切大层;给出可复用 prompt 段落。
  • 案例:Issue #161 四个 UI 入口,先只做后端 endpoint + 一个入口的端到端切片验证核心可用。

原文 ↗ /tracer-bullets

我每天用的 5 个 Agent Skills5 Agent Skills I Use Every Day

  • agent 是无记忆的工程师,需要严格流程约束;/grill-me 仅三句话却最强:沿 design tree 逐分支追问直到共识,能靠读代码回答的问题去读代码,单次可问 16~50 个问题。
  • /to-spec(原 /to-prd)不再采访,只综合已有对话成 spec(核心是 user stories),先探仓库、勾出测试接缝;/to-tickets(原 /to-issues)把 spec 拆成垂直切片票并建 blocking 关系以便并行。
  • /tdd 强制 red-green-refactor,是提升 agent 代码质量最稳定的手段;/improve-codebase-architecture 找浅模块合并成深模块的机会,建议每周跑一次。

原文 ↗ /5-agent-skills-i-use-every-day

TypeScript 项目的 AI 编码反馈环Essential AI Coding Feedback Loops For TypeScript Projects

  • TypeScript 是给 AI 的免费反馈:package.json 加 "typecheck": "tsc",能抓住浏览器里测不出的错误。
  • Vitest 单测抓逻辑错误;Husky pre-commit 依次跑 npx lint-staged、npm run typecheck、npm run test,任一失败即阻断提交并给 AI 报错。
  • lint-staged + Prettier 自动格式化暂存文件并重新 stage,保证 AI 产出的代码风格统一。
  • 为什么对 AI 特别有效:agent 不会因重复而烦躁,失败就重试,反馈环越即时决策越好,AFK(Ralph Wiggum)场景尤其关键。

原文 ↗ /essential-ai-coding-feedback-loops-for-type-script-projects

让 AI Agent 爱上你的代码库How To Make Codebases AI Agents Love

  • AI 不是超强开发者,而是每天spawn 20+ 个无记忆新人;对产出影响最大的是代码库本身,而非 prompt 或 AGENTS.md。
  • 差代码库的三种代价:反馈环慢、难以导航、人肉兜底导致认知倦怠;AI 眼里只有互相 import 的散落文件,看不到你的心智分组。
  • 解法是深模块(A Philosophy of Software Design):简单接口包大量实现;再做成 grey box——你拥有接口、AI 拥有实现,测试锁行为即可不看内部。
  • 好处:AI 靠读接口类型即可导航、你只需记住 7~8 个模块;TS 可用 Effect 简化模块化。对人好的设计对 AI 更好。

原文 ↗ /how-to-make-codebases-ai-agents-love

让 Claude Code 擅长 TDD 的 SkillMy Skill Makes Claude Code GREAT At TDD

  • LLM 写测试的通病是横切:先写完整功能再批量补测试,导致测试验证的是想象行为、mock 内部协作者、context 不足时直接改测试凑绿。
  • 解法是垂直切片的 red-green-refactor:一次只写一个失败测试 → 写最小实现变绿 → 全绿后再重构;先红后红约束让 LLM 无法造假。
  • 好测试走公共接口验证可观察行为(如"user can checkout with valid cart"),重构内部也不挂;坏测试 mock 内部、直查数据库、改名就红。
  • 实现前有规划阶段:确认接口变更、按关键路径排行为优先级、设计深模块与可测性(依赖注入、返回结果而非副作用)。

原文 ↗ /skill-test-driven-development-claude-code

AI 编码重塑我思维的 9 个方式9 Ways AI Coding Has Rewired My Brain

  • 更重视集成测试:为 Git 依赖的 CLI 建临时 Git 环境跑端到端用例;pre-commit/CI/强类型这类"摩擦"反而是 desirable 的即时反馈。
  • AI 对 UI 和软件架构都没品味:UI 要在一次性 route 上激进出 5 个原型再定;架构上要坚持深模块 + grey box(你管接口,AI 管实现,测试守边界)。
  • TS 后端推荐 Effect.ts 做依赖注入(service 即天然深模块);大量元编程:把 triage、backlog 清理等流程本身也交给 agent。
  • 警惕 doc rot:仓库里堆的 markdown 会过期误导 LLM,不如让 AI 探索时即时生成文档;追踪变化的认知负荷更高,靠信任测试来减负。

原文 ↗ /ways-ai-coding-has-rewired-my-brain

AFK / Ralph · 无人值守自主循环

5 篇

让 agent 挂机干活:入口、建议、可观测性、以及为什么别用官方插件。

Ralph 入门Getting Started With Ralph

  • Ralph = 用 bash 循环反复跑同一段 prompt:agent 自己从 PRD 挑任务、实现、跑测试、commit、更新 progress.txt,完成后输出 <promise>COMPLETE</promise>。
  • 用 Docker Desktop(4.50+)的 docker sandbox run claude 做隔离沙箱:目录同路径挂载、git 配置自动注入、每 workspace 状态持久。
  • 先 HITL 再 AFK:ralph-once.sh 单次运行观察并打磨 prompt;afk-ralph.sh 用 -p 非交互模式包循环,务必设迭代上限防失控。
  • 关键文件:PRD.md 定义终态(格式不限,任务可拆即可)、progress.txt 记进度;任务源可换 GitHub Issues/Linear/beads,输出可改为开分支提 PR,还能做覆盖率/lint/重复代码/熵减等专用循环。

原文 ↗ /getting-started-with-ralph

Ralph Wiggum AI 编码 11 条心法11 Tips For AI Coding With Ralph Wiggum

  • Ralph 的本质改进是"由 agent 选任务";先 HITL 打磨 prompt 再 AFK,迭代上限小任务 5-10、大任务 30-50。
  • 定义范围要防抄近路:用 Anthropic 式 JSON PRD(含 passes 字段兼做进度),显式列出覆盖文件、停止条件与边界情况——作者曾让 Ralph 补测试,它自作主张跳过"internal"命令。
  • progress.txt + 每任务一 commit 让后续迭代免于重新探索仓库;反馈环(类型/测试/lint/pre-commit)不绿不提交;小步提交对抗 context rot。
  • 高风险任务(架构、集成点、未知未知)用 HITL 先做;明确告诉 agent 仓库质量档位——指令会与代码库竞争,"the repo wins",脏库会被放大。
  • AFK 必用 Docker sandbox 防失控;成本上 HITL 也优于多阶段计划,还有覆盖率、jscpd 去重、lint、熵减等变体循环。

原文 ↗ /tips-for-ai-coding-with-ralph-wiggum

用 AFK Ralph 实时流式查看 Claude CodeHere's How To Stream Claude Code With AFK Ralph

  • 痛点:--print 模式零流式输出,AFK 跑 Ralph 时终端一片空白,无法判断 Claude 在工作还是卡死。
  • 解法:--output-format stream-json 输出全部消息,再用 jq 过滤——select(.type == "assistant") 取助手消息、抽取 text 内容、gsub 把 \n 换成 \r\n 修光标回行首的 bug。
  • 管道结构:grep --line-buffered '^{' 滤出 JSON 行 → tee 写入临时文件(供事后判定结果)→ jq --unbuffered 实时打印正文。
  • 循环末尾用 jq 从临时文件提取 .result 检查 <promise>COMPLETE</promise> 标记来终止;OpenCode 原生支持流式,此招专为 Claude Code 的现状而设。

原文 ↗ /heres-how-to-stream-claude-code-with-afk-ralph

为什么 Anthropic 官方 Ralph 插件不行Why the Anthropic Ralph plugin sucks (use a bash loop instead)

  • 官方 /ralph-loop 插件用 stop-hook 把循环困在同一个 session 内,每次迭代都在累积历史:约 3-4 轮后 context 进入"dumb zone"(约 40% 之后),性能必然劣化。
  • 原理:token 间关系随长度二次方增长,LLM 有 smart zone(前 40% context)与 dumb zone 之分,人人都认边界存在。
  • bash 循环每轮都是全新 context,PRD 与 progress 进来、git 历史补上下文,AI 始终待在 smart zone——这正是 Ralph 有效的原因。
  • 结论:别用插件自动化,保持 Ralph 的极简 bash 循环。

原文 ↗ /why-the-anthropic-ralph-plugin-sucks

AI 时代的个人软件疯狂好用Personal software is INSANE in the age of AI

  • 作者自建课程视频管理器(105 视频/41 课):录制后自动取 transcript 与本地文件,选 LLM(Haiku 4.5)与输出格式,一键产出 README 或复制到剪贴板,整条工作流在一个应用里。
  • 核心原则:AI 只做苦力活(转写、生成文本、格式转换),绝不把思考外包给 LLM;对自己产出用户可见内容的部分逐一审查。
  • 通用 AI 工具 demo 惊艳但日常拉胯,因为不了解你的文件结构、内容格式与仓库;未来属于深度贴合个人工作流的 bespoke 应用。

原文 ↗ /personal-software-is-insane-in-the-age-of-ai-u2hx2

Skills 深读(博客版)

5 篇

围绕自家 skill 写的实战长文。

grill-with-docs:构建前先对齐grill-with-docs: Align Before You Build

  • 与 /grill-me 同款追问面试,但是有状态的:术语敲定即写入 CONTEXT.md 词汇表,难逆转、意外、真权衡的决策过三道门后落为 docs/adr/ 的 ADR,其余只留在对话里(应接着喂给 /to-spec)。
  • 依赖 grilling + domain-modeling 两个 skill(SKILL.md 只有一行委托);加载不全时表现为一次性甩出无推荐答案的问题、或只面试不落盘——最常见故障。
  • 适用单 session 可完成的对齐;多 session 大工程用 /wayfinder。已知坑:被 spec-driven 等编排层包着跑时写文件会静默失败,输出前先查工作目录。
  • 成功标志:CONTEXT.md 随讨论逐条变化、词汇表不含实现细节、能查代码的不问你、几乎不出 ADR 也在正常工作。

原文 ↗ /grill-with-docs

/grill-me 与 /grill-with-docs 的 9 个常见错误9 Things People Get Wrong With /grill-me and /grill-with-docs

  • 区分低保真问题("这个路由 URL 是什么")与高保真问题("这个 UI 手感如何"):后者不可 grill,应 handoff 到原型 session,形成 grill → prototype → grill 的模式。
  • 范围过大有两个坑:藏进高保真问题、以及 context 撑到约 120k token 的"dumb zone"导致决策劣化;先让 agent 把大范围拆成多个可 grill 的小块分别进行。
  • 要主动掌舵而非被动答题,否则会被 540 个低保真问题轰炸撑爆范围;但也别过度规划不写代码。
  • grilling 产出的是装满设计决策的黄金 context:要么留在同 session 直接实现,要么用 /2PRD 做 handoff,绝不要清空 context 重来;grilling 依赖参数化知识,必须用大模型,实现阶段才换小模型;熟练后可并行跑两个 session 提吞吐。

原文 ↗ /things-people-get-wrong-with-grill-me-and-grill-with-docs

用 Triage Skill 清算积压 backlogtriage: Turn Backlog Mess Into Agent-Ready Work

  • /triage 只处理"别人提交的"外来 issue(bug 报告、功能请求、外来 PR);自己经 /to-tickets 产出的票已是 agent-ready,再 triage 是浪费。
  • 状态机:每条 issue 恰好一个类别(bug/enhancement)+ 一个状态(needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix);它只给推荐与理由并等你指令,不自动改标签。
  • 先验证再写 brief:按报告步骤复现 bug、checkout PR 跑测试;同时查重复实现与 .out-of-scope/(按概念匹配的历史拒绝记录,命中会先问你是否改主意)。
  • agent brief 是契约:写类型、签名与行为约定,不写文件路径和行号(要耐放,代码会在票下继续移动)。
  • 已知坑:setup 不会自动创建七个标签(要 gh label create);批量跑时必须明说"逐条读 comments",否则会漏看"已修复请关闭"的评论。

原文 ↗ /burn-through-your-backlog-with-my-triage-skill

用 /teach Skill 学任何东西Learn Anything With My /teach Skill

  • /teach 把 Claude 变成私人老师:先问清学习动机、当前水平、成功标准与学习偏好,答案越具体课程越个性化。
  • 生成一组文件:MISSION.md(目标)、RESOURCES.md(筛选过的资源)、reference/glossary.html(速查表)、lessons/(带音频按钮与即时反馈测验的交互式 HTML 课程)、learning-records/(进度档案)。
  • 安装要点:npx skills@latest add mattpocock/skills 选 /teach + Claude Code + 项目级 symlink 安装;若生成的是 .agents 目录需 ln -s .agents .claude。
  • 迭代方式像和真老师复盘:描述上节课哪里懂了哪里困惑,agent 据此生成下一课并更新学习记录。

原文 ↗ /learn-anything-with-my-teach-skill

走红的 Grill Me SkillMy 'Grill Me' Skill Went Viral

  • Skill 正文只有几行:就计划无情追问直到达成共识,沿 design tree 逐分支解开决策依赖;能靠探索代码库回答的问题就不问用户。
  • 新增的一行"每个问题附推荐答案"显著提速:答案显然时你只需说 yes。
  • 用途远超编码:早期需求发现(即 AI 时代的 rubber ducking)、选下一个课程方向等非编码场景也可用(删掉代码库那行即可)。
  • 单次 session 常 45 分钟,结束时得到一段富含上下文与真实想法的对话,起点可以是完整构想,也可以只是模糊的几句话。

原文 ↗ /my-grill-me-skill-has-gone-viral

§5 · EVALS

评测与改进

评测

3 篇

评测入门(what-are-evals)与 17 种改进技法已收在 §3 路线图课程里;这里是他专门的评测文章与工具 Evalite。

三种 EvalsThe Three Types Of Evals

  • 确定性 evals:返回 pass/fail 的断言,从概率系统中提取确定性;Ian Webster 认为这是最有用的一类,应快速、面向开发者;范例:Discord 的 Clyde 机器人被要求回复必须以小写字母开头以模仿 Gen-Z
  • LLM-as-a-judge:用 LLM 评估输出,如 autoevals 的 Humor(判有趣)、Battle(比较两个回答优劣)、配合 ground truth 查事实性;其失败往往意味着需要人工介入,更像 smoke test
  • 人工反馈:长文本生成与某些事实性评估只能由人判断;任何 LLM 应用都需要人工监督兜底

原文 ↗ /three-types-of-evals

Evalite 早期预览Evalite - an Early Preview

  • 痛点:当时没有 TypeScript-native、local-first 的 LLM 应用测试工具
  • Evalite 基于 Vitest 构建,定位是简单的 eval 运行器:watch 模式跑 evals、提供 UI 查看 traces/scores/inputs/outputs
  • 不需要注册或申请 API key,本地优先,无云平台绑定
  • 这是对当时 eval 工具生态(云服务为主)的一个轻量补充

原文 ↗ /evalite-an-early-preview

Evalite v1 预览:更快的 Evals 与内置 ScorersEvalite v1 Preview: Fast Evals, Built-in Scorers

  • v1(beta)内置 10 个生产级 scorer:string 类(exactMatch/contains/levenshtein,levenshtein 适合 SQL/代码等格式差异不判失败的场景)、RAG 类(faithfulness 查幻觉、answerSimilarity/answerCorrectness/answerRelevancy/contextRecall)、进阶类(toolCallAccuracy 测 agent 工具调用、noiseSensitivity 测鲁棒性)
  • scorer 可自由组合,各自返回 0-1 分,Evalite 聚合成总分
  • 架构大改:默认内存存储,npx evalite 开箱即用,需要持久化再切 SQLite,省掉设置 SQLite 的门槛
  • 深度集成 Vercel AI SDK:wrapAISDKModel() 带来自动 tracing 与缓存,watch 模式下改 scorer/阈值不重跑昂贵的 LLM 调用,生产环境零开销(no-op)
  • DX 改进:自动加载 .env、暗色模式、对象渲染为表格、watch 模式 rerun 按钮

原文 ↗ /evalite-v1-preview

§6 · PAPER GUIDES

论文与资源导读

论文与资源导读

4 篇

值得读一遍的外部经典,附他的解读。

Anthropic 认为应该这样构建 AgentAnthropic thinks you should build agents like this

  • Agent 与 Workflow 的区别在自主程度:Workflow 走预定义代码路径,Agent 动态引导自己的流程。
  • 默认别用框架(LangGraph、Bedrock Agents 等):抽象层会遮蔽底层 prompt 与响应,应直接用 LLM API 起步,理解底层代码后再考虑框架。
  • 文章重点其实是五种 workflow 模式:prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer。
  • 真正 agentic 的模式只有一种:LLM 基于环境反馈在循环中调用工具,每步从环境获取 ground truth,直到完成或触发停止条件(如最大迭代数)。

原文 ↗ /building-effective-agents

Google 的 Agent 入门白皮书很棒Google's Introduction To Agents Is GREAT

  • 白皮书定义 agent 为"通过观察世界并使用工具作用于世界来达成目标的应用",并区分 agent 与 model:model 受限于训练数据,agent 能访问外部系统、靠对话历史累积上下文。
  • orchestration layer 负责信息摄取、内部推理、决定下一步行动,本质是反馈循环。
  • 工具分两类:extension 由 agent 自行调用执行;function 只教 LLM 用法,执行逻辑留在客户端,适用于无权限、需 human-in-the-loop 或复用既有 API 的场景。
  • 作者认为 function/extension 命名与开发者既有概念冲突,适合教学但未必沿用。

原文 ↗ /google-agents-whitepaper-review

2024 年最佳 prompt 工程资源Here's 2024's best resource on prompt engineering

  • The Prompt Report 是对 prompt 工程全部文献的元分析,被 Latent Space 列为年度必读。
  • 核心价值是细致的术语分类树:Zero-Shot(Emotion/Role/Style Prompting、Self-Ask)、Few-Shot(exemplar 生成/排序/选择)、Thought Generation(Zero-Shot 与 Few-Shot CoT、Auto-CoT 等变体)、Ensembling、Self-Criticism、Decomposition。
  • 还覆盖多模态、多语言与 prompt 安全,每节附论文链接,是深入该领域的最佳起点索引。

原文 ↗ /the-prompt-report

STORM:基于真实研究生成高质量文章STORM: Generate High-Quality Articles Based On Real Research

  • 介绍 STORM 论文(arXiv 2402.14207),要解决"从零写出高质量文章"的难题,文章基于真实研究生成。
  • 作者把它当作复杂 AI workflow 的范例:即使不关心文章生成领域,想构建更好的 AI workflow 也值得研究。
  • 注意:该页正文仅为视频导语加论文链接,workflow 具体细节在视频/原论文中。

原文 ↗ /storm-generate-high-quality-articles-based-on-real-research

§7 · TAKES

观点与思维

观点与思维

1 篇

其余观点文已分插在 §4(rewired-brain、personal-software、grill-me 走红记)。

2025:用 GenAI 构建变得无聊2025: The Year Building With GenAI's Gets Boring

  • 核心主张:GenAI 走过炒作周期后会变成"无聊的日常工具",对应用开发者如同数据库、缓存一样平常。
  • 用户可见的 LLM 功能风险高(泄露 IP、让公司尴尬、惹恼用户),chatbot 是雷区;放在后端幕后则简单得多。
  • 幕后用例:从 PDF/图片/音频抽取结构化数据、OCR 与格式转换(对存量文档企业价值极大)、摘要(SEO/标题/TL;DR)、即时翻译(正式出版仍靠人)、用 embeddings API 构建语义搜索与推荐并可重排序。
  • 好的 GenAI 应用藏在幕后:没有 sparkle emoji,域名里没有 ".ai",用户无感知。

原文 ↗ /2025-the-year-building-with-gen-ais-gets-boring~d53hd

§+ · EXCLUDED & NOTES

排除清单与整理说明

按你的要求排除的营销/售卖内容:AI Coding Crash Course 与 AI SDK v6 Crash Course 两个付费 workshop、Claude Code cohort 试听页、newsletter 订阅页、/skills/subscribe 七天邮件课(邮箱换取)。学习价值已由本图的免费内容覆盖。
  • ›站点的小彩蛋它给 agent 畇了专门的机器可读入口:llms.txt、sitemap.md、skills.md——本身就是「AX 友好」的示范。
  • ›重复页what-are-tokens 在 sitemap 中出现两次(同一页);本图已去重。
  • ›统计口径sitemap 共 189 个 URL;词典 69 条以官方首页分组计数为准,skills 25 个以官方目录顺序为准。
← 学习站索引