star 数不代表能跑:可用性核查与成本边界
学完你能用三条标准判断一个陌生开源项目今天还能不能用
上一节你有了一张表。这一节讲这张表里最容易被忽略、也最值钱的那一列:可用性核查。
为什么要专门加这一列?因为开源项目会停更,而停更的项目不会在首页挂个牌子说"我不能用了"。README 还是那个 README,star 数甚至还在涨——你照着敲第一条命令,才发现根本跑不动。
学完这一节,你会有一套三步核查动作,和一条关于成本数据的硬纪律:只用你自己验证过的数字。
去一家网上评分很高的餐厅,门口挂着五星牌子,评论区几千条好评。你推门进去,里面空了,桌椅蒙着布。
评分记录的是"过去有多少人觉得它好",不是"今天还开不开门"。想知道今天开不开,你得看的是门口的营业执照日期和最近一次进货记录。
2532 个 star,零可用性
gpt-author 有 2532 个 star,是本课三个项目里 star 最高的(novel-writer 916,Long-Novel-GPT 1202)——但它恰恰是唯一完全跑不起来的那个。
这条反差值得你记一辈子:
GitHub star 数不代表可用性。
它失效的原因也不玄学,就两条可诊断的因果链:
- 写死的模型 ID——模型名字直接焊在源码里,不可配置。厂商一退役,整个项目连锁失效。gpt-author 源码里写死了
claude-2(已于 2025-07-21 退役)和claude-3-haiku-20240307(退役日 2026-04-19,早于本课核查日 2026-08-06),调用直接返回 404。类比:把钥匙焊死在门上,换锁只能砸门。 - SDK 破坏性变更——官方库升大版本时移除了老写法。
openai.ChatCompletion这个写法在 openai SDK 1.0 之后被移除,你照老教程装新版就报错。类比:老菜谱写"用煤气灶点火",你家换了电磁炉,步骤照抄点不着。
核查一个陌生项目,只看三样
- 最后推送时间——去 GitHub 仓库首页看最近一次 commit 是什么时候。
- 有没有人实测过——有没有人写下"我某年某月某日跑通了,终端输出是这样"。
- 源码里有没有写死的模型 ID / 是否依赖已停更的 SDK 写法——搜一下源码里有没有直接出现模型名字符串。
不看 star。
注意第三条才是关键:看时间是为了提醒你去查后果,不是替代查后果。一个功能稳定、不依赖外部模型 ID 的小工具,半年没更新照样能跑;gpt-author 的致命伤也不是"两年没更新"这件事本身,而是"写死的模型 ID 已经退役"这个具体后果。
成本账:只有一个数据点,而且它已经过期
关于"AI 写一本书要花多少钱",本课手上只有一个公开数字:
约 4 美元生成一本 15 章的奇幻小说
必须连着三个限定语一起记:
- 这个数字出自 gpt-author 项目 README 的作者自述,没有第三方验证;
- 它基于 2023–2024 年的模型与价格;
- 而这个项目已停更两年。
项目资料本身就写明了:这是"15 章奇幻小说的单一数据点,无不同章节数、不同模型的成本对比,不可外推"。
所以本节的动手环节,不是让你估算自己要花多少钱——那是拿一个过期数据点做算术,算出来的数字只会给你虚假的安全感。真正靠谱的成本数据,是你下一节自己跑一遍测出来的。
🔧 动手做:给成本数据加上限定语(10 分钟)
- 打开你的《工具选型报告》,在表格下面新起一段,标题写"成本数据点"。
- 写下
约 4 美元 / 15 章,并在后面用括号注明它的三个限定:作者自述、2023–24 年价格、项目已停更。 - 再起一段,回答这个问题:"为什么这个数字不能直接套用到我的项目?"
- 你的答案里至少要写出两个理由。提示方向:数据来源的性质、时间、模型与价格的变化、你的题材和篇幅与它不同。
你会看到:报告里多出两段,一段是带完整限定的数据点,一段是你自己写的不可外推理由。
为什么:引用数字时把限定语一起抄下来,是最省事的自我保护。你现在养成这个习惯,以后看到任何"某某只要几块钱"的说法都会先问一句"哪一年、哪个模型"。
诚实的做法不是回避成本,是只用你亲自验证过的成本。下一节你会跑一次零成本的实验,那个数字是一手的、可信的。
这一节给了你三样东西:一条铁律(star 数不代表可用性)、两条失效因果链(写死的模型 ID、SDK 破坏性变更)、三步核查动作(推送时间、实测记录、源码依赖)。
关于成本,本课只有一个来自项目 README 自述、基于 2023–24 年价格、且项目已停更的数据点。它只能作历史参考,不可外推。
下一节我们不再纸上谈兵——你会用一条命令、零成本、零 API key,亲手跑通一个工具,拿到属于你自己的第一手数据。
🔎 来源与核验· 4 条,点开核对
