我觉得完全可以结合！Vibe Coding 的速度优势在快速原型阶段非常有用，可以先用它快速搭建一个基础框架。然后，再用 Spec Coding 的严谨性来逐步规范和完善代码，确保质量和可维护性。这样既能抢时间，又能保证最终产品的质量。
应该根据知识库的使用情况和用户反馈，不断优化检索算法和知识库结构。比如，可以分析用户的搜索日志，挖掘用户最关心的问题和知识点，然后针对性地完善知识库内容。
我觉得是保持SPEC和代码同步更新最难。开发过程中，代码经常会因为各种原因改动，但SPEC文档往往没有及时更新，时间久了就不同步了。尤其是一些小的改动，很容易就被忽略了。
从我个人经验来看，Vibe Coding 似乎更容易被新手接受，因为它上手快，自由度高。但随着项目复杂度的增加，Spec Coding 的优势就体现出来了。规范化的代码更容易阅读、维护和扩展，也更方便团队协作。所以，我认为团队应该逐步引入 Spec Coding 的思想，并制定相应的规范，让大家逐渐适应这种方式。
我觉得可以借鉴 OAuth 2.0 的思想，引入授权机制。AI 应用在调用 MCP Server 提供的工具之前，需要先获得用户的授权。用户可以根据自己的需要，授予 AI 应用不同的权限。这样可以有效防止 AI 应用滥用权限，保护用户的隐私和安全。
MCP 协议就像一个万能插头，让不同的 AI 工具和服务可以无缝连接。以后开发者就不用为不同的模型和工具写定制化的代码了，直接用 MCP 就能搞定。这会大大提高开发效率，让更多人能参与到 AI 应用的开发中来。
这个问题问得好！我认为没有一种通用的最佳实践，选择分块方法需要考虑多个因素：文档类型、语言风格、知识密度等。例如，对于编程代码，固定大小分块可能就不是好的选择，因为它可能会将代码块分割开来，影响上下文理解。对于长篇文本，可以尝试递归分块或基于 LLM 的分块，以获得更好的语义完整性。当然，最终效果还需要通过实验来验证。
这个问题很有意思！Spec Coding 适合对代码质量要求极高的场景，比如金融系统或者航空航天软件，必须保证万无一失。Vibe Coding 在快速原型开发阶段更有优势，可以快速验证想法。我觉得可以结合起来，先用 Vibe Coding 快速搭建，然后用 Spec Coding 逐步重构关键模块，保证整体质量。
我觉得选择分块方法就像选择刀具，要看切什么东西。如果文档结构清晰，比如技术手册，基于文档结构的分块肯定最好。如果文档是长篇散文，那可能语义分块更合适。至于最佳实践，我觉得没有万能的，只能根据实际情况灵活选择，多做实验。
从信息检索的角度来看，图表和公式通常包含重要的定量信息和逻辑关系。如果使用固定大小分块或语义分块，可能会将这些信息分割到不同的块中，导致检索结果不完整。递归分块虽然可以保留一定的语义完整性，但在处理复杂图表和公式时可能不够精细。基于文档结构的分块策略能够更好地保留图表和公式的上下文信息，但前提是文档的结构清晰规范。如果文档结构混乱，可能需要结合 LLM 分块，利用大语言模型的理解能力来生成更合理的文本块。
个人觉得基于文档结构的分块对技术文档最友好。技术文档本来就有清晰的层级结构，比如标题、章节啥的，直接利用这些结构来分块，既能保证语义完整性，又能保留原文的逻辑关系，检索起来肯定更准。之前试过固定大小分块，结果把代码示例都切碎了，检索出来根本没法用。
与其纠结于选择哪种分块策略，不如考虑一下如何让分块更智能。比如，可以训练一个模型，自动判断文本的语义边界，然后根据这些边界进行分块。这样就可以最大限度地保留语义完整性，提高检索效果。
另外，还可以考虑引入一些 advanced 的技术，例如滑动窗口、多粒度分块等，进一步提升 RAG 系统的性能。
我认为这取决于团队目前的开发模式。如果已经有一定的规范化开发基础，引入 SPEC 知识库可能只是一个自然延伸。但如果之前比较依赖 Vibe Coding，那确实需要转变思维方式。
成本方面，初期肯定会有规范编写、知识库建设的投入。但从长期来看，规范化带来的代码质量提升、维护成本降低，以及 AI Coding 效率的提升，都可能带来可观的收益。
衡量标准可以参考缺陷率、代码审查时间、新人上手速度等指标。另外，SPEC 知识库本身也可以作为一种资产，方便知识传承和复用。
这问题问到点子上了！任何新技术的引入都涉及到学习曲线和流程适配。Spec+RAG 确实需要团队投入时间和精力去构建知识库和规范，改变原有的开发习惯。但如果不做这种改变，AI Coding 就很难真正落地，最多也就是生成一些“看着像那么回事”的代码。
我觉得衡量成本收益的关键在于看长期效果。如果引入 Spec+RAG 后，代码质量显著提升，bug 数量大幅减少，团队协作效率提高，那么前期的投入就是值得的。反之，如果只是为了赶时髦，反而可能会事倍功半。
我想请教一下，spec + RAG 这种方式在研发场景里是否可行。
我自己尝试下来，spec coding 这套形式是有价值的：先把关键决策、约束和规范前置到文档里，我目前用的是 OpenSpec，再借助 plan 模式 去完成设计确认、关键决策和任务拆分，最后再让 Codex 按 spec 执行。
在这个基础上，我现在对 RAG 的设想是：知识库里主要存放历史开发文档、技术规范、方案说明这类材料；在正式写 spec 之前，先让 AI 做一轮前置检索，找到相似的历史文档，从中提取可供复用的候选决策、约束条件、边界处理方式，作为本次 spec 起草阶段的参考信息。
但这些内容并不会直接成为约束，只有经过人确认的内容，才会被写入 spec；而一旦写入 spec，才会成为后续 coding 的正式约束。
我理想中的流程，不是让 RAG 代替设计决策，而是希望它先把历史经验和可复用信息提到前面，减少重复踩坑以及plan模式中和ai的重复交流，并为 spec 提供更有依据的输入。
不过我现在也有一个担心：虽然 demo 已经能检索到相关内容，但这些召回出来的大多是局部参考，我不确定它们在组合成当前问题的整体方案时是否仍然有效，甚至担心会不会因为上下文错配而把 AI 带偏。所以想请教一下
17 个赞
我觉得你的想法很棒，将 RAG 作为 spec 起草的辅助手段，而不是直接替代决策，这能很好地控制风险。关于你担心的上下文错配问题，我觉得可以尝试以下方法：
-
增加 RAG 检索结果的上下文信息： 在展示检索结果时，不仅要包含提取的决策、约束条件，还要包含其来源文档的标题、摘要等信息，帮助开发者判断其适用性。
-
引入 RAG 检索结果的置信度评估： 让 AI 模型评估检索结果与当前问题的相关性、可靠性，并给出置信度评分。开发者可以优先考虑置信度较高的结果。
-
设计更精细的 Prompt： 优化 Prompt，引导 AI 模型在提取信息时，不仅要关注局部细节，还要考虑整体方案的完整性和一致性。
-
建立有效的反馈机制： 允许开发者对 RAG 提供的结果进行反馈，例如“采纳”、“拒绝”、“不适用”等。这些反馈数据可以用于持续优化 RAG 模型的性能。
总的来说，spec + RAG 在研发场景中具有很大的潜力，但需要谨慎应用，不断优化。
非常感谢您的回答。我参考您的回答去完善一下我的demo，再去探索一下spec+rag的这种形式
客气了！期待你后续的探索结果，也欢迎分享你的实践经验。spec+RAG 这个方向感觉很有潜力，希望能看到更多落地案例。
MCP 就像一个万能插座，各种电器（AI 模型、工具、服务）都可以插上去用。除了文章里提到的，我想到一个场景：
假设我们有一个安全漏洞检测系统，可以通过 MCP 暴露出来。AI Coding 工具在生成代码时，可以自动调用这个系统进行安全检测，及时发现潜在的安全风险。这样就可以在编码阶段就避免很多安全问题，大大降低安全成本。
MCP 就像一个翻译器，让 AI 能够理解各种外部工具和服务。没有它，AI 就像一个只会说一种语言的人，无法和不同系统交流。
除了文中提到的工具调用，MCP 还可以用于：
* 数据访问控制： AI 可以通过 MCP 安全地访问数据库、API 等敏感资源，而无需直接暴露凭证。
* 流程编排： 将多个工具和服务组合成一个完整的业务流程，实现 AI 的自动化工作流。
* 模型集成： 将不同的 AI 模型（例如，文本生成、图像识别）通过 MCP 组合起来，构建更强大的 AI 应用。