[问与答] 想做一个播客问答网站，被实现方案卡住了怎么办？
我平时很喜欢听某个播客频道，现在想针对这个播客做一个类似于对话框问答的网站。
播客一共有 300 多期节目，我目前正在把播客音频转成文稿，已经转了 20 多期。
但是这个播客每期都是好几个人录制，导出的播客文稿很琐碎。
用 AI 基于已经导出的 20 期文稿生成的问答网站效果并不好吧，有些问题回答的不全或者干脆找不到。
昨天突然接触到谷歌的 notellm ，我尝试把这 20 多期文稿扔进去，惊讶的发现，这个 notellm 的回答质量高的吓人，信息汇总的特别全面。
研究半天，发现谷歌的 notellm 不支持对外接口。
现在卡在这里不知道要不要做下去了。
请问是我哪里的步骤出了问题吗
via V2EX (author: seafog)
我平时很喜欢听某个播客频道，现在想针对这个播客做一个类似于对话框问答的网站。
播客一共有 300 多期节目，我目前正在把播客音频转成文稿，已经转了 20 多期。
但是这个播客每期都是好几个人录制，导出的播客文稿很琐碎。
用 AI 基于已经导出的 20 期文稿生成的问答网站效果并不好吧，有些问题回答的不全或者干脆找不到。
昨天突然接触到谷歌的 notellm ，我尝试把这 20 多期文稿扔进去，惊讶的发现，这个 notellm 的回答质量高的吓人，信息汇总的特别全面。
研究半天，发现谷歌的 notellm 不支持对外接口。
现在卡在这里不知道要不要做下去了。
请问是我哪里的步骤出了问题吗
via V2EX (author: seafog)
[鸿蒙] agc-cli 现在支持 NPM 安装和 Codex Agent Skills 了
我给 agc-cli 补上了两层面向 AI 编程助手的分发能力：
● Windows 、macOS 、Linux 现在可以统一使用
● Codex 可以通过
官网同时增加 JSON-LD Schema 、
项目： https://github.com/Createitv/agc-cli
官网： https://agccli.app/
NPM： https://www.npmjs.com/package/@createitv/agc-cli
完整中文文章： https://blog.csdn.net/weixin_40065545/article/details/167804328
via V2EX (author: createitv)
我给 agc-cli 补上了两层面向 AI 编程助手的分发能力：
● Windows 、macOS 、Linux 现在可以统一使用
npm install --global @createitv/agc-cli；● Codex 可以通过
npx --yes skills add Createitv/agc-cli --global --agent codex 安装 6 个任务型 Skills 。官网同时增加 JSON-LD Schema 、
llms.txt、llms-full.txt、中英文 Agent Guide 、Skills 索引和机器可读 API 契约。目标不是让 Agent 猜命令，而是让它沿着“发现能力 → 读取文档 → 检查凭据 → dry-run → 用户授权 → 验证远程状态”的路径工作。项目： https://github.com/Createitv/agc-cli
官网： https://agccli.app/
NPM： https://www.npmjs.com/package/@createitv/agc-cli
完整中文文章： https://blog.csdn.net/weixin_40065545/article/details/167804328
via V2EX (author: createitv)
[Claude] 大型 AI 工作室主打：克劳德官 key Openai 官 key 克劳德 CCMAX20X 大厂上游渠道来对接
青春没有售价 硬座直达拉萨 大型 AI 工作室主打：克劳德官 key Openai 官 key 克劳德 CCMAX20X 大厂上游渠道来对接 泰山就在脚下 夜骑开封拿下 暗恋止于盛夏 合作永不止步！ TG 飞机联系： @maoxianwang9
via V2EX (author: yyw5332979)
青春没有售价 硬座直达拉萨 大型 AI 工作室主打：克劳德官 key Openai 官 key 克劳德 CCMAX20X 大厂上游渠道来对接 泰山就在脚下 夜骑开封拿下 暗恋止于盛夏 合作永不止步！ TG 飞机联系： @maoxianwang9
via V2EX (author: yyw5332979)
[分享创造] 分享一个监控 OpenRouter, OpenCode, NIM 等免费模型速度的网站
https://john-walks-slow.github.io/token-speed-patrol
随时检测有没有值得用的羊毛🐱
via V2EX (author: JohnnRen)
https://john-walks-slow.github.io/token-speed-patrol
随时检测有没有值得用的羊毛🐱
via V2EX (author: JohnnRen)
[分享创造] 我测试出 Jev 的一个实用方向：给 AI Agent 做事实质检，进一步用在 RAG 核查
我的结论：Jev 值得用来低成本筛查 AI 有没有把事情记错。 让它核对一个具体事实，比让它重新判断整个任务更有意思。
比如： 用户说：周五有读书会，开场时间还没公布。 AI 记成：周五 19:00 开始。
格式正确、保存成功，但时间是编的。Jev 可以对照原文，把这种“看起来合理、实际没有依据”的事实标出来。
我做了一组小规模合成实验：
● 32 条保留检查中，Jev 和 GPT-5.5 都找到了 16 条问题，对另外 16 条正常事实没有误报。
● 同轮各 80 次调用，中位耗时分别为 0.87 秒和 4.10 秒。
● 按实验记录费率估算，Jev 的核查调用成本明显更低。
之前我让 Jev 同时参与多个字段的决策，效果反而变差。缩小成“这个事实，原文到底有没有说”，才找到了值得继续试的方向。
更让我感兴趣的是：如果检查足够便宜，哪些原来只能人工抽查的工作，可以更频繁地检查？
下面这些是应用猜想，尚未实测：
1. 客服、会议纪要、CRM AI 承诺退款，政策里有依据吗？纪要里的负责人和截止日期，是大家明确同意的，还是模型补全的？“客户感兴趣”有没有被写成“客户确认购买”？ 让系统先筛出疑点，人工优先看这些记录，可能比逐条翻原文省心。
2. RAG 知识库与问答优化 将回答拆成关键事实，与检索片段逐项核对：引用是否支持结论？有没有遗漏适用条件、混用不同版本？ 疑点可以用于触发重新检索、改写或人工复核；确认的问题还能积累成回归测试。也可以先找出知识库里疑似冲突的片段，再检查它们是否在相同条件下表达了矛盾结论。
3. Ontology ／知识图谱辅助整理 先由其他模型提取候选实体、关系和类型，再核对： 原文是否支持这条关系？ 这个实体是否符合已有类型定义？
明确的结构约束用代码检查，语义疑点再交给模型。如果有效，也许能减少人工逐条审阅候选知识的成本。
潜在价值，是让“原始资料 → 知识整理 → AI 回答”每个环节都多一次低成本核查，把人的注意力集中到疑点上。
不过，本次实验中的候选事实由人工给定，也确实发现过漏检，还没验证生产环境能省多少人力。回答符合检索材料，不代表材料本身正确；检查候选关系，也不等于能自动设计合理的 ontology 。
接下来真正想测的是：每发现一个真实错误花多少钱，以及人工核查时间到底减少了多少。
完整实验、原文： https://tryjevai.com/blog/jev-ai-fact-checking
大家手上的业务里，有没有这种核对费神、出错又不容易发现的环节？尤其做 RAG 或知识图谱的朋友，觉得这种接法有没有试验价值？
via V2EX (author: Taylor77)
我的结论：Jev 值得用来低成本筛查 AI 有没有把事情记错。 让它核对一个具体事实，比让它重新判断整个任务更有意思。
比如： 用户说：周五有读书会，开场时间还没公布。 AI 记成：周五 19:00 开始。
格式正确、保存成功，但时间是编的。Jev 可以对照原文，把这种“看起来合理、实际没有依据”的事实标出来。
我做了一组小规模合成实验：
● 32 条保留检查中，Jev 和 GPT-5.5 都找到了 16 条问题，对另外 16 条正常事实没有误报。
● 同轮各 80 次调用，中位耗时分别为 0.87 秒和 4.10 秒。
● 按实验记录费率估算，Jev 的核查调用成本明显更低。
之前我让 Jev 同时参与多个字段的决策，效果反而变差。缩小成“这个事实，原文到底有没有说”，才找到了值得继续试的方向。
更让我感兴趣的是：如果检查足够便宜，哪些原来只能人工抽查的工作，可以更频繁地检查？
下面这些是应用猜想，尚未实测：
1. 客服、会议纪要、CRM AI 承诺退款，政策里有依据吗？纪要里的负责人和截止日期，是大家明确同意的，还是模型补全的？“客户感兴趣”有没有被写成“客户确认购买”？ 让系统先筛出疑点，人工优先看这些记录，可能比逐条翻原文省心。
2. RAG 知识库与问答优化 将回答拆成关键事实，与检索片段逐项核对：引用是否支持结论？有没有遗漏适用条件、混用不同版本？ 疑点可以用于触发重新检索、改写或人工复核；确认的问题还能积累成回归测试。也可以先找出知识库里疑似冲突的片段，再检查它们是否在相同条件下表达了矛盾结论。
3. Ontology ／知识图谱辅助整理 先由其他模型提取候选实体、关系和类型，再核对： 原文是否支持这条关系？ 这个实体是否符合已有类型定义？
明确的结构约束用代码检查，语义疑点再交给模型。如果有效，也许能减少人工逐条审阅候选知识的成本。
潜在价值，是让“原始资料 → 知识整理 → AI 回答”每个环节都多一次低成本核查，把人的注意力集中到疑点上。
不过，本次实验中的候选事实由人工给定，也确实发现过漏检，还没验证生产环境能省多少人力。回答符合检索材料，不代表材料本身正确；检查候选关系，也不等于能自动设计合理的 ontology 。
接下来真正想测的是：每发现一个真实错误花多少钱，以及人工核查时间到底减少了多少。
完整实验、原文： https://tryjevai.com/blog/jev-ai-fact-checking
大家手上的业务里，有没有这种核对费神、出错又不容易发现的环节？尤其做 RAG 或知识图谱的朋友，觉得这种接法有没有试验价值？
via V2EX (author: Taylor77)
[分享创造] 之前想在 mac 弄个 fnos 的虚拟机挂着，存视频在别的端用，发现 pd 虚拟机装起来太麻烦，就 VibeCoding 了一个稍微轻一点的
https://github.com/Xiaohantx/FnOS-Manager
via V2EX (author: xiaohantx)
https://github.com/Xiaohantx/FnOS-Manager
via V2EX (author: xiaohantx)