Perchouli

谢谢！有用的项目。做训练的时候是调阿里的 Document Mind 接口转结构化，然后自己处理 RAG 。这个 knowhere 相当于把 RAG 也做好了，企业内部知识库这类场景节省很多工作量。

@andrewTeller 外网访问是把 URL labfile.oss-cn-hangzhou-internal.aliyuncs.com 里的 oss-cn-hangzhou-internal.aliyuncs 这段替换成 shiyanlou
纯演示项目，给没网络的读者 vcrpy 重现请求用的，在他们虚拟环境里能下载。

谢谢！同样的痛点——网上小程序广告太多，又都是中文。
看了下这个项目还支持多语言，非常贴心了。

看描述真是疑难问题了。是说 Bing 能正常抓取 sitemap.xml ？是不是可以排除连通性问题。

这个 GSC 的提交失败 Status 一直不成功，是[失败]？在 GSC 顶部的搜索栏直接输入 sitemap.xml 的地址是绿色吗

上规模就考虑多站点。

要是小一些的站，直接用子分类。父分类地区，子分类菜系。缺点是子分类也要手动建。
还要一点灵活性的话，可能注册 taxonomy 会更好。

这条推支持反对的都有，有说让 CEO 深入技术细节不如让他们专注于商业判断。也有说不用 AI 构建产品的 CEO 正在管理一家他们实无法理解的公司，“理解力”无法转交给下属。
AI 应该还没到完全颠覆企业流程的阶段，CEO 下场 vibe 没什么问题，但如果不是技术背景或者之前从来不参与，贸然干涉已有开发流程可能不是明智做法。

多人协作的目前最容易落地的应该是“中间产物”和“共享上下文”。前者就是在“意图”和“代码”之间，有一个记录，将自然语言意图编译为可读、可编辑且受版本控制的结构化中间表示，根据团队成熟度用 Spec 文件，用图（转 spec ），用自己实现的其他格式都有。“共享上下文”是项目里用 AGENTS.md 、.cursorrules 、architecture.md 控制好大的约束，然后用其他记忆管理比如 mem0 动态记录项目变化，比如一个配置文件用 TOML 写了被记录到记忆里，另一个人像用 YAML 写，在上下文里发现冲突就能拦掉。

猪队友——文明一点叫低效协作者，影响主要集中在倾向于快速接受 AI 生成的第一个“能跑”的方案。降低方式主要是人工审核了，另一个实践是引入发散性思维的显式脚手架，就是让低效协作者在接受这个方案之间，先让 AI 多给一些其他方案做选择。

如果一直都是 vibe coding ，“能跑”会累积成复杂的缺陷，传统的单测被认为会失效。有一种实践是强制要求 AI 生成一个映射表，将 Prompt 中的每一句话（业务意图）精确映射到具体的代码行（类/函数）和具体的验证点上。审查这个会比审查代码细节更能发现早期的规范缺失。我前两天还 share 了一个做法，也是一种可供参考的实践： https://v2ex.com/t/1216271

至于“最佳”估计很难说，毕竟去年刚提出来的概念，模型也还在更新。

@andrewTeller 演示项目 llmrec 那个 tar 包吗？稍等我问问他们客服，放的是内网链接。

@409164 不同的大模型是能缓解。也提出对抗独立性是结构层面，最好能有形式层面的独立。大模型训练的数据高度重合，还需要增加非 LLM 的验证机制，比如静态代码分析、形式化验证，最终的人类业务逻辑审查。