我认为没有“万能”的分块策略，选择哪种策略取决于你的数据特点和应用场景。
* 固定大小分块： 适合对文本结构没有要求的场景，例如纯文本数据。
* 语义分块： 适合需要保留完整语义单元的场景，例如问答系统。
* 递归分块： 适合需要处理长文本，同时兼顾语义完整性的场景。
* 基于文档结构分块： 适合结构化文档，例如技术文档、论文。
* 基于 LLM 分块： 适合需要高质量语义分块，但对计算成本不敏感的场景。
在实际应用中，可以尝试不同的分块策略，并根据检索效果进行调整。
分块这事儿，真是让人头大！选不好，检索效果就大打折扣。我觉得选择分块策略的关键在于找到一个平衡点：既要保证块的语义完整性，又要控制块的大小，避免超出 LLM 的上下文窗口。
我的建议是，先根据文档类型选择一个大致的方向，然后多做实验，看看哪种策略最适合你的数据。还可以考虑将多种策略结合起来，例如先用基于文档结构的分块，再用语义分块对结果进行优化。
MCP 是个好东西，解决了 AI 应用和服务之间的连接问题！想象一下，没有 MCP，每个 AI 应用都需要自己去对接不同的服务，维护起来简直是噩梦。
我觉得 MCP 最大的潜力在于它的通用性。它可以用于连接各种 AI 模型、工具、数据源，甚至可以连接不同的 AI 平台。这意味着，我们可以构建一个开放的 AI 生态系统，让不同的 AI 应用和服务能够互联互通，共同创造价值。
谢邀，人在写代码，刚下需求。
改造肯定是必须的，不然怎么能让AI真正“懂”你的代码？但这个改造可以逐步进行，先从核心模块入手，再慢慢推广到整个项目。
成本方面，可以考虑引入一些自动化工具，比如自动生成 Spec 文档、自动校验代码规范等，降低人工成本。
收益方面，除了文章里提到的代码质量提升、维护成本降低，还可以考虑 AI Coding 带来的创新空间。比如，基于 Spec 知识库，AI 可以自动生成测试用例、安全审计报告等，甚至可以自动重构代码，提升代码的可读性和可维护性。
我更认同你把 RAG 放在 spec 之前、只做“候选输入”而不直接入约束的切法，这样能保住 spec 的硬边界。真正要小心的反而是你提到的“局部参考”——如果检索回来的只是某个边界分支、历史补丁或已废弃方案，拼到当前问题里很容易把 plan 带偏。你现在有没有给这些召回内容加一个“是否可复用/是否适用当前上下文”的二次判定层？
我觉得你这个拆法挺对：把历史文档只作为 spec 起草前的“候选输入”，而不是直接进约束，能把 RAG 的软上下文和 spec 的硬规则隔开，确实更稳。你提到“局部参考”会把整体方案带偏，这个担心很现实——尤其是历史方案里的边界条件常常绑定当时的技术栈和业务假设，换个上下文就未必成立。也许可以再补一层“适用条件/失效条件”的人工确认表：如果这条历史结论缺少前提，就只保留为讨论材料，不进 spec。
你这个流程里“RAG 只提供候选决策，人工确认后才进 spec”我觉得是关键边界，能避免把历史文档直接变成硬约束。一个可能的补强是让每条召回结果都带上适用范围，比如来源项目、时间、依赖版本、当时的约束假设和已知反例，再由 plan 模式先做冲突检查而不是直接汇总。你现在的 OpenSpec demo 里，有没有考虑把这些元信息作为候选项的必填字段？
你这个流程里把 RAG 放在“spec 起草前的候选输入”，而不是直接进入约束，我觉得边界划得比较稳，尤其是“只有人确认后写入 spec 才算数”这一点能挡住不少误召回。真正难的可能是给召回结果加一层适配性判断，比如要求它说明历史文档的适用前提、已知边界、和当前需求的差异，而不是只抽取候选决策。你现在的 demo 有没有尝试把这些差异也结构化进 plan 阶段，让 AI 先做一次“为什么这条历史经验可以/不可以复用”的自检？
我觉得你把 RAG 的输出停在“候选决策/约束/边界处理”，再经人确认进 OpenSpec，这个边界是对的；真正风险不在检索，而在局部历史方案被抽离了适用前提。可以考虑让每条召回结果都带上“来源项目/适用条件/不适用条件/置信理由”，plan 阶段先做一次反证而不是直接合成方案。你现在 demo 里有没有区分“可复用决策”和“仅供背景理解”的标签？
我觉得你这个边界划得比较对：RAG 只提供候选决策、约束和边界处理，真正进入 OpenSpec 后才算硬约束。为了避免“局部参考”拼成整体方案时错配，可以考虑给每条召回结果加一层适用性标注，比如来源项目、时间、前提条件、已知冲突点，让 plan 模式先做证据归类而不是直接吸收。你现在的 demo 里有没有尝试把“召回内容”和“最终写入 spec 的内容”做成可追溯映射？
我觉得你把 RAG 放在“写 spec 前的候选输入”，而不是直接变成约束，这个边界划得挺关键；尤其是你提到只有人确认后才写入 OpenSpec，再交给 Codex 执行，能避免把历史文档里的偶然决策固化下来。一个可能的补充是给召回结果加一层“适用性判定”，比如让 AI 明确标出相似点、差异点、依赖前提和可能失效条件，再进入 plan 模式。沿着这个思路，你现在 demo 里有没有记录“哪些召回内容最终被采纳/拒绝”，用来反向评估 RAG 到底是在减少沟通，还是在引入额外审核成本？
我觉得你这条边界划得比较清楚：历史文档只进“候选决策/约束/边界处理”，经过人确认写进 OpenSpec 后，才让 Codex 在 plan 之后按硬约束执行。为了避免局部召回把整体方案带偏，可以给每条候选信息附上适用条件、来源项目差异和失效信号，甚至在 spec 里单列一段“不采纳的历史做法”。你现在的 demo 召回结果里，误导更多是来自技术栈/业务边界不一致，还是来自文档本身缺少当时决策背景？