vibe‑coding 九阳神功之喂：把链接喂成“本地知识”，AI 才能稳定干活（API / 设计 / 报道 / 截图）

vibe‑coding 九阳神功之喂：把链接喂成"本地知识"，AI 才能稳定干活（API / 设计 / 报道 / 截图）

系列顺序：夯（Git） → 抄 → 学 → 喂

这一篇只讲一件事：别让 AI 去"猜"，你要学会"喂"------把资料变成它能直接执行的知识底座。

AI 编程现在最大的坑不是"不会写"，而是：

• 写得太快
• 改得太多
• 炸了没后路
• 炸完你甚至不知道它到底改了哪些文件

所以我准备写一套 vibe‑coding 九阳神功：核心不是提示词，而是把 AI 变成"可控交付的队友"。

这套"九阳神功"我先定了九个字诀：

• 夯：Git 生存技能（刹车 / 保险 / 录像）
• 抄：拆解 yfge/orion、ai-shifu/ai-shifu 的优秀骨架，搭底盘
• 学：学习行业黑话，会组合技术栈、不懂原理也能不翻车
• 喂：把 API 文档 / 资料结构化成可执行知识
• 规：让 AI 出计划 + tasks.md，按清单推进
• 验：多模型交叉验证，专治幻觉
• 测：Chrome MCP 自动测试，交付有证据
• 扩：扩展认知边界，但必须可验证
• 收：上线交付、监控回滚、复盘闭环

一句话：不是教你"让 AI 写代码"，是教你"带着 AI 把东西交付上线"。

这篇咱们讲第四式喂：喂什么、怎么喂、喂到什么程度算够用。

前一式"学"教你说黑话，这一式"喂"教你给 AI 喂资料------会说还得会喂，AI 才能稳定产出。

为什么必须"喂"？

你跟 AI 合作时，99% 的翻车不是模型不够聪明，而是：

你给了它一句话需求，它就开始"脑补"，然后用它的默认世界观给你写一套"也许能跑"的东西。

链接不是知识，链接只是"可能有知识的入口"。

而 vibe‑coding 想要稳定交付，必须把入口变成可被反复引用、可审计、可版本化 的东西------也就是：本地文件。

你把资料喂到本地的那一刻，变化非常明显：

• 你和 AI 讨论的是同一份 source of truth（不会出现"你说的 A 文档，它看的 B 版本"）
• 你能用 Git 追踪资料变更（谁更新了 docs、哪段被改了）
• 你能逼 AI 输出更"工程化"的交付物（文件清单/接口清单/验收清单）

喂 = 把不确定性砍掉。

小白只看这里：喂什么？（五大类，一网打尽）

我把"喂"分成 5 类。你不需要一次全会，你只要把它当成 checklist，用到哪项就喂哪项：

1. API 文档：决定代码能不能正确对接
1. 设计文档：决定页面长得对不对
1. 报道稿/资料：决定系统规则准不准
1. 截图：决定 BUG 能不能快速定位
1. 现场证据：日志/配置/样本数据/录屏

下面逐个讲：

1）喂 API 文档：给链接，让 AI 整理成本地速查表

这是最值得喂的一类，因为它直接决定 AI 写出来的代码"对不对接口"。

小白只需要 2 步：

第 1 步：把链接直接给 AI

go 复制代码

请读这个 API 文档：https://pay.weixin.qq.com/wiki/doc/apiv3/

第 2 步：让 AI 把文档整理成速查表，保存到本地

go 复制代码

请帮我整理成速查表，保存到 docs/_feed/api/wechat-pay.quickref.md，包含：

1) 接口清单（接口名称、URL、请求方式、用途）
2) 鉴权方式（怎么拿 token、怎么签名）
3) 常见错误码（至少列 5 个）
4) 给我 3 条可复制的测试命令（下单、查询、退款）

为什么要存本地？

• AI 今天读的版本和明天读的可能不一样（文档会更新）
• 有了本地速查表，你和 AI 讨论时是"同一份资料"
• 用 Git 可以追踪你什么时候喂了什么

目录建议：

go 复制代码

docs/_feed/api/
  wechat-pay.quickref.md   # AI 整理的速查表（这个最重要）
  wechat-pay.examples.sh   # AI 给的测试命令
  wechat-pay.openapi.json  # 如果官方提供（可选）

进阶：如果官方有 OpenAPI/Swagger 文件

这种文件是 API 的"标准化描述"，AI 最爱读这个。如果你看到官方提供了 openapi.json 或 swagger.yaml，直接下载放到 docs/_feed/api/ 里，然后：

go 复制代码

@docs/_feed/api/wechat-pay.openapi.json

请根据这个 OpenAPI 文件，生成完整的接口速查表

2）喂设计文档：喂网址/图片，把"长什么样"变成可执行约束

很多人做需求沟通只给一句话："做个类似 XX 的页面"。

AI 的第一反应就是：自由发挥 + 随机 UI + 你看着不对但又说不清哪不对。

喂什么：

• 设计稿链接（Figma/蓝湖/截图都行）
• 关键页面截图（首页/详情/下单/支付这种主路径）
• 交互说明（点击什么出现什么、loading/error/empty 状态）

怎么喂：

把图片/链接落地到本地，最好按页面组织：

go 复制代码

docs/_feed/design/
  01-home.png
  02-detail.png
  03-create-flow.png
  notes.md            # 你补充的交互说明

你应该让 AI 先做的 2 件事：

1. "像产品经理一样"把页面拆成组件与状态：header/list/card/modal/loading/empty/error
1. "像前端 TL 一样"把它变成路由与文件清单（Next.js/React/Vue 都行）

投喂模板（直接复制）：

go 复制代码

我把设计稿截图放在 docs/_feed/design/。

请输出：
1) 页面信息架构：有哪些页面/路由/主流程
2) 组件拆解：每页组件清单 + 状态清单（loading/empty/error）
3) 前端落地清单：按文件路径列出需要新增/修改的文件
4) 验收标准：我打开哪些 URL、看到什么算对

3）喂报道稿/资料：先存 PDF，让 AI 读完再改系统里的提示词

我在做 ai-video-studio 的时候，经常会遇到"创作类需求"：短剧、分镜、人物设定、叙事节奏......这些东西不是写几行代码能解决的，它更像"你要先把行业资料吃透"。

这时候最有效的投喂是：报道/论文/行业分析 → PDF 落地 → AI 先解读 → 反哺提示词/规则库。

喂什么：

• 报道稿/行业分析（PDF）
• 你自己写的"创作约束"（比如平台审核红线、时长、节奏、镜头语言）
• 你现有系统里的 prompt（让它知道你现在怎么写的）

目录建议：

go 复制代码

docs/_feed/research/
  2026-02-xx-short-drama-xxx.pdf
  2026-02-xx-notes.md
docs/prompts/
  storyboard.md
  character.md

你投喂后不要让 AI "总结就完事"，你要让它回写到系统里：

go 复制代码

请阅读 docs/_feed/research/2026-02-xx-short-drama-xxx.pdf。

1) 用 10 条要点总结"短剧爆款规律"（必须可操作）
2) 把要点映射成 prompts 改动建议：分别修改 docs/prompts/storyboard.md 与 docs/prompts/character.md
3) 给我一个 A/B 对比的验收方法：同一题材，旧 prompt 和新 prompt 分别生成一次，看哪条更贴近资料规律

这一步的本质：你不是在"让 AI 读论文"，你是在用资料给你的系统"上规则"。

4）喂截图：直接截图扔它，让它修 BUG（但你要补齐"证据链"）

截图是 vibe‑coding 最爽的一种投喂方式：

你不用描述半天，"它看一眼就知道你哪里不对劲"。

但我建议你别只喂一张 UI 截图 ------ 你最好同时喂三样：

• 现象截图：页面长啥样/报错在哪
• 控制台截图：Console 报错、Network 失败请求
• 复现步骤：1-2-3（越短越好）

你可以这样要求 AI 输出（让它别瞎猜）：

go 复制代码

这是 BUG 截图 + 控制台报错 + 复现步骤。

请输出：
1) 最可能的 3 个根因（按概率排序）
2) 每个根因对应要检查的文件/配置/接口（按路径列清单）
3) 给出最小修复方案：只改必要代码
4) 给我一个验收步骤：怎么证明修好了、不会回归

5）喂现场证据：日志/配置/样本数据（把问题变成可审计的材料）

最后这条是"总纲"：你只要能把问题变成"可被审计的材料"，就都可以喂。

常见但被忽略的高价值投喂物：

• .env.example / 配置文件（很多 bug 都藏在环境变量里）
• 关键日志（后端日志/浏览器 console/worker 日志）
• 真实样本数据（脱敏后的一条订单/一条对话/一条任务记录）
• 数据库 schema（migration/DDL）
• 一段失败的 curl / 一段失败的 SQL
• 录屏（某些交互 bug 截图不够）

你甚至可以把"事故现场"整理成一个包：

go 复制代码

docs/_feed/bugcase/bug-2026-02-xx/
  repro.md
  ui.png
  console.png
  network.har
  logs.txt
  env.example

然后丢给 AI：你别给我一堆推理，你给我"改哪几个文件、怎么验收"。

喂的心法：三层结构，把"资料"变成"可执行知识"

很多人喂完资料，AI 总结两段话，就结束了。

我建议你把"喂"固定成三层结构，形成闭环：

1. 原件层（Raw）：网址/截图/PDF，先落地到本地（可追踪）
1. 结构层（Digest）：速查表/术语表/边界说明（可检索）
1. 执行层（Action）：文件清单 + 改动方案 + 验收步骤（可交付）

一句话：喂不是给 AI 增加信息量，是给它增加确定性。

练习：从一个真实场景开始喂

场景：你要接入微信支付 API

任务：

1. 找到微信支付官方文档，保存到 docs/_feed/api/wechat-pay.md
1. 让 AI 抽取"接口速查表"（至少包含：下单、查询、退款、回调）
1. 让 AI 输出"最小验收脚本"（3条 curl）
1. 用 Git 提交这些"喂料"：git add docs/_feed/ && git commit -m "feat: 添加微信支付API喂料"

验收：

• docs/_feed/api/ 目录下有 3 个文件（原始文档 + 速查表 + 验收脚本）
• 用 AI 生成的接口代码能通过速查表验证（字段不遗漏、错误码有处理）

总结：喂得好，AI 才像"你自己的团队"

你可以把 vibe‑coding 理解成"带实习生写代码"：

• 你只说一句"做个系统"，它就按它理解做一坨
• 你把文档/设计/资料/现场证据喂给它，它就能像人一样按规矩干活

下一式我们讲规：把 AI 的产出固定成计划与清单（tasks.md），让它从"会写"升级成"会计划"。