欲善其事先利其器，AI友好架构优于AI本身

大模型编程如火如荼，目前所有人都觉得大模型编程会大幅提效，还有很多人觉得有了AI程序员就面临失业了。    其实，大模型在编程方面的提效是一个体系化的工程，不光是大模型强或agent牛就能搞定的，就像火器替代冷兵器一样，要想把火器威力发挥到极限， 除了火器的精准度、威力的持续演进外，还必须配合相应战法、后勤重塑无缝配合才能适应新的武器威力的突破。    大模型编程也一样，如果软件架构不是面向模型的，更多是遗留代码甚至腐化严重，比如过大类过长函数、发散式变化、散弹式修改比比皆是，大模型维护起来也是心有余而力不足。    他山之石可以攻玉，我们引用chroma的一个发现：

    Chroma 官方研究发现：在超长上下文中，模型倾向于过度关注开头和结尾，而「遗忘」中间部分——这被称为「Lost in the Middle」效应。

1.研究摘要

• 报告标题：Context Rot: How Increasing Input Tokens Impacts LLM Performance
• 发布机构：Chroma（向量数据库公司）
• 发布时间：2025 年 7 月
• 核心测试：覆盖18 个主流 LLM（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3 等）
• 官方链接：
  • 报告原文：https://research.trychroma.com/context-rot
  • 开源复现代码：https://github.com/chroma-core/context-rot
• 核心结论：模型性能随输入长度非均匀、断崖式下降；过度关注首尾、忽略中间（叠加 Lost in the Middle 效应）；干扰项、语义相似性、上下文结构会显著放大性能衰减。

2. 通用长度阈值（所有模型共性）

• 5k token 以内：性能稳定，召回率 >90%
• 5k–20k token：开始明显衰减，召回率从 92% 降至 58%（Llama2-70B）
• 20k–50k token：断崖式下降，关键指令准确率下降 43%，逻辑断裂概率达 73%
• >50k token：性能接近随机，幻觉、拒绝生成、无关输出频发

3. 不同模型的 “翻车” 长度（差异极大）

4. 关键发现：

• 长度是最重要的因素

• 干扰项放大衰减：加 1 个干扰项即降性能，加 4 个则衰减翻倍
• 语义相似度越低，衰减越快：非字面匹配任务（真实场景）比 “大海捞针” 衰减更剧烈
• 位置效应叠加：中间信息在长上下文里被双重忽略（Context Rot + Lost in the Middle）

5.小结：

    要想获得较好的推理性能，单次提示词需要提升以下方面：

• 控制提示词长度
• 重要信息放在首位
• 排除干扰项

    解决方案是AI友好架构。

    AI友好架构的关键点

举措：

i.架构按上下分层、左右分模块拆分；

ii.模块功能足够内聚，拆分足够小每

iii.个模块提炼一份模块说明文档

    摘要说明模块的功能、目录结构、对外接口、测试用例等。

应对提示词优化的三个方面。

a、上下分层：

b、层内分竖横

竖：业务模块，实现一个个内聚独立的功能单元。

      ai code模块自包含的知识单元，检查AC模块，一个AC模块 = 功能源码+ AC文档 

横：业务流程，编排、调用模块完成业务功能。

AC文档 ：

– 模块概要

– 模块目录结构

– 对外API使用示例

– 内部核心组件/类描述以及mermaid关系图 

– 模块依赖关系（是否依赖其他模块）

– 测试和验证方法（特别重要）c、横竖依赖规则

d、功能维护

i、修改业务模块

ii、修改业务流程

iii、同时修改i、ii

    模块内容足够内聚，业务流程又足够薄，并且优先使用每个模块的ac.md文件来获取模块核心信息，修改上述i、ii、iii的prompt都可以浓缩在很小范围，这样每次功能维护（修改bug或新增功能）都可以做到prompt始终不超过大模型最大提示词的最小有效比例，始终可以获取较好的大模型编程效果；同时，也实现了提示词的内聚，由于使用ac.md也可以保证重要信息放在首位，避免了 lost in the middle。

    同时模块变化时，也可以使用大模型自动维护ac.md，从而实现系统的闭环。

    另外，经过我们实践，实现了AI友好架构的团队，在AI零手工代码的实践模式中也表现非常优异。

    综上，要想获得高效的大模型编程效果，需要做到AI友好的代码架构，从而更有利于控制单次交互提示词token数量，获得最大效用的大模型生成内容，从而实现大模型编程事半功倍的效果。