Appearance
怎么让 AI 帮你找到现成的轮子？
导读
GitHub 上的现成项目不是按需求列出来的，所以先把需求切成最小可验收切片（MVS），再用接口想象力判断两个 MVS 能不能接上；然后用五步指挥 AI：定 MVS、摊开技术路线、读代码选项目、子代理复核、写成 Spec。
GitHub 的搜索对非编程人员不够友好。如果你是奔着「看看都有什么作业可以抄」的心态，正确的方式是尝试去搜项目的「描述」。好在 GitHub MCP 已经装好，这些事情都可以扔给 AI 来做。
胶水代码
既然 AI 负责去 GitHub 上找开源项目来拼装这个「PPT 生成工具」，那么问题就只剩一个：怎么判断找回来的东西能不能用。
理论上，不论你的需求有多么小众，你都会在 GitHub 上找到现成的作业抄。那么如何找合适的项目呢？
这里我们需要引入一个极其重要的切分依据：最小可验收切片（Minimum Verifiable Slice，简称 MVS）。
在中文语境里，你可以称之为：「功能」。
之所以先介绍 MVS，是因为「功能」这个概念太「泛」了。我们要把功能收敛到能被单独测试、有明确输入和输出、失败能定位、成功可验收的最小单元**。
真实的需求，往往不是单一能力的展现，而是「既能这样，又能那样」的 MVS 组合。
比如一个 PPT 自动生成工具，可以拆成：话题结构化解析、模板渲染、插图匹配、质量校验与导出多个部分。这几个 MVS 的输入和输出相连，共同组成了一个「PPT 生成工具」的项目。把一个 MVS 的输出和另外一个 MVS 的输入连接在一起，就是程序员嘴里常说的「胶水代码」。
我们要在 GitHub 中找的是 MVS，而不是具体的某个项目，项目只是实现 MVS 的「候选容器」。
接口想象力
脚手架，就是字面意思。盖楼前先搭金属脚手架。当项目搭完以后，我们通常要拆除脚手架或者隐藏脚手架。** 我们不妨搭起一个思想上的脚手架，并把它命名为「接口想象力」。
AI 能写代码，能验证兼容性，但就像搜索引擎不能替你决定搜什么关键词一样，它不能替你发起「这两个东西能不能捏在一起」这个判断动作。这个判断能力就是所谓的接口想象力——看到功能 A 的输出结构，和看到功能 B 的输入结构，在脑子里形成一个映射关系。
具体来说：
- 看 A 输出什么；
- 看 B 输入什么；
- 判断中间差什么，需不需要转换。
举个具体的例子：
| 程序员观察到 | 程序员意识到 |
|---|---|
| A 输出 JSON，B 的输入也是 JSON | 两个项目大概率可以链接 |
| A 输出视频流，B 的输入文本 | 那么，中间必须有转码、转录或识别才行 |
| A 输出的是 user_id，B 要的是 account_id | 所以，还要改一下标签 |
事实上，上述的表格是通过直觉的下意识完成的。
程序员会快速形成假设，然后验证，不会在此处做任何停留。这是非编程人员在缺乏训练的情况下无论如何也做不到的事情，原因就是非编程人员暂时还没有接口想象力。我们只能把接口想象力外化成可操作的具体步骤，建立一套在程序员眼里“这还用说？”的工作流程去推进。
不过请放心，这是一个临时的脚手架。你只要做过一个项目，就会对架构相似的其他项目建立起接口想象力。做完两三个项目以后，这套脚手架就可以彻底扔掉了。
一套临时脚手架
TIP
再次说明：这是给不会编程的人临时用的「抄作业脚手架」，不是优雅的终极方案，更不是 Vibe Coding 的万能答案。真正想让你看到的是：项目能跑起来，靠的往往是一堆不优雅的「胶水代码」，而不是照搬几个结论或效果。
你已经通过苏格拉底问答法和 JTBD 模型，把模糊的想法收敛成了清晰的项目任务。理论上，你得到的结果本身就已经是一份项目的「验收规格」，我们要尝试把这套项目的验收规格变成 MVS 的验收规格。
脚手架的核心：描述验收规格，而不是需求本身
你的提示词以及指令都要去描述验收规格，而不是需求本身。你发出的每一个指令，都在向你的验收规格靠拢。
告诉 AI 你的验收规格有两个目的：
- 防止 AI 扔给你一大堆看不懂的名词和概念，让你稀里糊涂偏离原有的前进方向。** 只要 AI 的回答中出现了你看不懂的名词和概念，都要问「和我的验收规格（而不是我的需求）有什么关系」。
- 面对选择题，有一个抉择依据。 如果多个项目都满足规格，那就选择「综合成本」最低的。跑通一个项目主要有四个判断维度：部署成本、维护成本、时间成本、技术依赖风险。
我们当然是要优先考虑部署成本和维护成本更低的方案。需要警惕的是，AI 经常会高估某些技术路线的开发便利，低估部署和维护成本，从而劝你放弃其实更省事的方案。这是因为它的训练语料和网上找到的素材，都会有「哪些技术路线更方便？哪个项目更费时间」的内容。但 Vibe Coding 本身就是 AI 去写代码，所以用什么方式实现不是我们考虑的事情。
脚手架的具体步骤（以「PPT 生成工具」为例）
第 0 步：完成 GitHub MCP 的安装
如果你还没有安装 GitHub MCP，请回到《GitHub 除了存代码还能干什么？》完成安装。安装后确认它能搜索仓库、读取文件、查看提交记录和许可证文件。
第 1 步：生成 MVS
AI 会将我们定义的「PPT 生成工具」验收规格，切分为 4 个 MVS：
| MVS 编号 | 能力切片名称 | 输入 → 输出 | 验收标准（怎么算成功） |
|---|---|---|---|
| MVS 1 | 话题结构化解析 | 纯文本话题 → JSON 大纲（含标题+3 个要点） | 输入任意话题，输出的 JSON 结构完整、字段不缺失、内容与话题相关 |
| MVS 2 | 插图匹配、生成 | JSON 大纲中的关键词 → 图片文件或占位符标记（含来源和许可证字段） | 每页都有对应插图；图片尺寸适配幻灯片；来源和许可证字段完整，供后续校验 |
| MVS 3 | 模板渲染引擎 | JSON 大纲 + 图片 + .pptx 模板 → 填充内容的 .pptx 文件 | 标题、正文正确填入对应占位符；字号配色符合规格；无排版溢出 |
| MVS 4 | 质量校验与导出 | 填充后的 .pptx 文件 → 最终 .pptx + 校验报告 | 自动检查页数、字数、对比度是否达标；不达标项在报告中高亮提示；若达标，则导出最终 .pptx |
MVS 是验收点，不是采购项。
这些 MVS 放在一起，是对项目做一次功能角度上的描述。你可以拿着这些功能去 GitHub 上找实现，但不是要去找对应的 4 个项目。
因为程序员自己的项目，不会把每个功能都单独写出来，所以你几乎不可能找到严丝合缝的现成项目。MVS 终究是一份验收 checklist。
第 2 步：基于 MVS 让 AI 阐释可选技术路线
先让 AI 帮你规划技术路线，再在技术路线下面挑选项目。
你至少要看两个维度：有没有成熟路线，哪些更具备扩展性。问法不必完美，AI 回答的格式也不重要。重要的是，让 AI 从多个维度把可能性摊开。你可以随心所欲与 AI 讨论，这件事本身比你最后选哪条路线、项目能不能做出来还重要。**
有了这一步，技术路线基本清晰。同时你可以剔除掉很多不必要的 MVS：有些 MVS 不需要去 GitHub 找现成项目，直接让 AI 写一个小模块即可。只有复杂、成熟轮子多、自己写不划算的 MVS，才去 GitHub 找候选项目。
第 3 步：看和 MVS 比较匹配的项目
不要让 AI 只读 README 就下结论。一个项目的 README 和它的代码之间没有强约束。所以你要让它去读项目里的核心代码、示例文件、依赖文件和最近提交，确认它真实的样子。
评判标准有两条：
- 不满足验收规格的，一律 Pass。
- 都满足规格时，优先选部署成本和维护成本最低的，再综合时间成本和技术依赖风险。
除此之外，再加一些加减分项：
- 加分： Star/Fork 多、最近仍在维护、Issue 有人回复、文档清楚、有测试、许可证宽松。
- 减分： 长期停更、依赖老旧、需要数据库或云服务或复杂环境、输出格式难解析、接口和你的 MVS 对不上。
这里有两个要注意的地方：许可证宽松对人类来讲不重要，但是 AI 会默认这些事情很重要；其次，Star 只是参考，不是决定因素，Fork 多才是真的质量高。
接口契合度 > 项目名气。
路线适配 > 功能大而全。
第 4 步：用子 Agent 复核
让子 Agent 在没有上下文的情况下，只拿 MVS 卡、验收规格硬约束和候选材料，独立判断「能不能解决」。
这一步是为了防止主 Agent 自证偏差。不用记复杂的提示词：
text
输入：当前 MVS 卡、验收规格硬约束、待复核的路线或项目材料
输出：能不能解决当前 MVS？输入输出怎么接？缺什么转换？卡在哪？有没有隐藏依赖、许可证、维护、技术栈问题你甚至可以直接：
text
找个子路由，复核一下你的结论是否满足原始需求。如果我照此开发，是否没有风险？第 5 步：保存调研报告 + 做成 Spec
你的提示词里一定要包含下面三个词：结构、机制、代码。你可以直接和 AI 说：从结构、机制、代码的角度，制定一份我们自己的开发计划输出 Spec。
至于 Spec 怎么写，请阅读Spec 到底该怎么写？。