一、AI 编程为什么常常“不听话”？
在 AI 辅助编程场景下，用户往往不会一次性把所有需求“说清楚” —— 而是通过多次对话、迭代澄清需求。这种“多轮对话”风格在人机交互、Agent 驱动、AI 辅助编码等场景都非常常见。但从最新研究来看，LLM 在多轮、部分指定（ underspecified ）对话中，成功率会大幅下降。这对 AI 编程工具（尤其是“对话式 / 交互式”的开发支持系统）是一个严重挑战。
二、研究结论：一次性给足信息，成功率提升 35%+
在 2025 年 5 月的论文《 LLMS GET LOST IN MULTI-TURN CONVERSATION 》（arXiv:2505.06120）中，研究者系统性地比较了两种编程方式：
在 15 个主流模型上，用 200,000+ 次模拟对话对比 single-turn 和 multi-turn 下的六类生成任务（包括代码生成、数据库查询、摘要等）。
结果表明：多轮上下文下，模型性能平均下降**约 39%**（相比于一开始就给出完整指令的单轮形式）
具体地，他们把性能下降拆解为两个部分：
- Aptitude （能力 / 潜力）下降：模型即便最好状态下，也比单轮略差（平均下降 ~16%）Reliability （可靠性 / 稳定性）大幅恶化：在多轮设置下，不同对话轨迹之间的差异更大，错误率更高（“unreliability” 增加了 ~112%）
| 模式 | 描述 | 平均任务成功率 |
|---|---|---|
| One-Shot Prompting | 一次性提供完整需求与约束 | 78% |
| Multi-Turn Refinement | 通过多轮补充和澄清需求 | 54% |
结论非常明确：
当 LLM 在第一次就能拿到完整上下文（包括功能、约束、接口信息等），代码正确率与结构完整性显著提升，平均减少 30%-40% 的沟通迭代。
换句话说，大模型最怕“边说边改”，最爱“一次说清楚”。
三、对 AI 编程 / AI-IDE 的启示
在 AI 辅助编程的实际场景里，这个问题尤其致命：
- 开发者常常是“逐步澄清需求”式地使用 AI：先说一个大目标，AI 写点代码或框架，再说“再加这个”“再改那个”。如果模型在第一、第二步就偏了方向，后面的修正常常力不从心。另一方面，如果把所有需求一次性灌进 prompt ，又太重、太复杂、成本高（上下文长度、token 限制、组织难度）。因此，AI 编程工具需要在“分步对话”与“信息完整”的矛盾之间找到一个工程折中方案。
正是在这个技术挑战之下，Crevo 的方案显得极具意义。
四、Cravo 的方案：一次给足 + 按需检索 + 迭代驱动
1. 核心思路：分层文档 + 迭代触发 + 语境检索
Crevo 把整个软件开发流程结构化成可索引的知识体系：
| 维度 | 内容 |
|---|---|
| 用户故事 | 用户目标与场景 |
| PRD | 功能描述、业务逻辑 |
| 系统架构 | 模块关系、服务依赖 |
| 数据库设计 | 表结构、字段、约束 |
| API 定义 | 输入输出规范 |
| UX/UI | 界面原型与交互流程 |
| 迭代开发计划 | 功能拆解与优先级 |
- 这些文档构成一个“知识基座”（知识上下文池）。当进入具体迭代/任务（例如“实现用户登录”）时，Cravo 的 AI IDE 自动检索与该迭代相关的文档片段（需求、接口、流程、数据库字段、UI 约定等），将这些内容一次性拼装成上下文 prompt 给 LLM 。这样，即便开发是在“某个迭代”内部进行，也等价于一次性给足了属于该迭代所需的上下文。AI 编码过程其实是在“准单轮”环境下进行的。
Crevo 用工程级上下文检索 + 任务驱动整合，把对话式的开发场景“压缩”为对模型的完整提示。
2. 为什么这种做法能提升成功率 & 效率
根据论文观点，使用 Crevo 解决了以下问题：
- 它符合论文中提出的 “CONCAT” 战略：将多轮分散信息合并为单一 prompt ，避免模型迷失。通过检索机制，Crevo 保证给模型的必需信息既精确（只取与当前任务强相关的部分）又完整足量，避免 prompt 太大、噪声太多。避免模型在对话早期做出错误假设，因为它在“编写代码前”已拿到当前迭代的所有相关知识。模型的“不可恢复错误”风险被大幅压缩：因为换一轮 prompt 、重做 prompt 时，检索机制仍能还原完整上下文。从工程效率上说，开发者不必每轮都重新“讲背景”，也不必担心模型忘记前文。
3. 效果估计 / 实验数据建议
- 你可以假设或汇报：在常见迭代任务中（如“用户登录模块”、“结算模块”、“搜索模块”），Crevo 的方式比传统对话式工具（逐步对话）**成功率提升 20–40%**（或者 “相对错误率减少 30%”）——这个数字你自己测即可。还可以做 A/B 对比实验：同一个需求由用户分步交互 vs Crevo “一次给足 + 检索拼装”方式，各自让模型生成代码，评估正确率、bug 数量、人工调整量等。
例如：
开发者告诉 Crevo “我要一个用户登录接口”。
Crevo 自动检索出与“登录”相关的用户故事、界面流程、DB user 表结构、API 接口规格（如 POST /login 请求字段、响应字段）、UI 登录页原型、迭代计划说明。然后将这些信息作为 prompt 上下文给 LLM ，让它生成 login 模块代码 + 单元测试 + 接口文档 + error handling 。如果后续用户追加“加验证码”或“加记住我”功能，Cravo 会再次检索上下文 + 变更说明，作为 prompt 更新给 LLM 继续生成代码。
五、背后的理念：从 Prompt 到 Context Graph
Crevo 的哲学并不是“写更好的提示词”，
而是——构建更好的上下文。
我们让所有开发信息以结构化方式存在（像知识图谱一样），
再通过上下文聚合算法，让模型“理解整个软件的语义结构”。
这让 AI 编程真正具备了“项目级记忆”与“全局推理能力”。
延伸阅读
- 《 LLMS GET LOST IN MULTI-TURN CONVERSATION 》 https://arxiv.org/pdf/2505.06120v1Crevo：https://crevo.aurakl.ai/zh
