关于 AI 编码未来的思考
关于AI编码未来的思考
AI 编码的未来，也许不是让模型理解整个项目。未来 AI 编码可靠性的提升，可能不只来自更强的模型和更大的 Context Window，更来自软件架构本身的改变：通过稳定底座、强契约、局部上下文和自动验证，把一个复杂软件系统拆解成 AI 可以独立完成并确定性验证的小问题。
从 Android Framework 得到的启发：我们真正需要的，可能是一个让 AI 永远只解决局部问题的软件世界。
AI辅助编码的演进
我曾经在智能电动汽车主机厂工作。套用一下关于智能驾驶分级的概念：
- L0 应急辅助：例如自动紧急制动（AEB）、车道偏离预警。
- L1 部分驾驶辅助：例如自适应巡航（ACC，只控制纵向）或车道居中（LCC，只控制横向）。
- L2 组合驾驶辅助：例如同时控制方向与速度的领航辅助（NOP）。
- L3 有条件自动驾驶：例如高速拥堵时系统可自行驾驶，但您需随时准备接管。
- L4 高度自动驾驶：例如限定区域内的无人出租车（Robotaxi），无需您接管。
- L5 完全自动驾驶：任何道路、天气下都无需人类干预（目前尚未实现）。
AI编码的演进，可能也是从辅助到完全自主的过程。
我认为你这个方向是成立的，而且它可以被提炼成一个比“AI 编码应该减少上下文”更有力度的观点：
AI 时代的软件架构，优化目标可能会从“让人更容易理解整个系统”，进一步转向“让 AI 完成一次变更时，只需要理解最小必要上下文”。
这和你作为 Android 开发者的直觉非常契合。
不过你初版里有几个地方需要调整，否则文章容易变成“因为 Transformer 不可靠，所以未来系统应该简单”这样略显跳跃的论证。
1. 先修正第一个前提：问题不只是 Transformer 的“不确定性”
你现在的表述是：
因为 Transformer 架构的特性，输出代码具有不确定性，上下文太长容易引入噪声，丢失注意力。
后半句基本成立。长上下文并不意味着模型能够同等有效地利用所有信息，“Lost in the Middle”早就观察到了随着相关信息位置变化，模型表现会明显下降。到了 Agent 场景，Anthropic 也明确把 context 视为一种有限资源，认为随着上下文不断膨胀，模型会出现注意力和信息利用效率下降的问题。(arXiv)
但前半句最好改成：
LLM 本质上是一种概率生成系统。即使模型越来越强，软件需求本身的歧义、上下文选择、推理路径以及生成过程，都会让同一个任务存在多个可能实现。
因为我们其实不需要追求：
同一个需求
↓
AI 每次生成完全相同的代码真正应该追求的是：
┌→ 实现 A ─┐
需求 → AI生成 ─┼→ 实现 B ─┼→ Contract / Test / Rule → PASS
└→ 实现 C ─┘代码可以不确定，结果必须确定。
我觉得这句话甚至可以成为你整篇博客的一个核心观点：
未来 AI 编码要解决的，并不是“生成的确定性”，而是“验证的确定性”。
这是一个非常重要的思想转变。
2. 你 Android 的类比其实非常好
你提到：
Android 应用程序员开发 App 时，不会想着修改系统源码，而是遵循已经实现的系统特性，在应用层做适配。
这个类比可以继续往下推。
今天一个 Android 工程师写：
context.getSystemService(...)不会去理解：
Binder
AMS
PMS
SurfaceFlinger
Linux Scheduler
Binder Driver
Kernel为什么？
不是因为这些东西不复杂。
恰恰相反。
是因为底层已经把复杂度封装掉了。
对于 App 开发者而言：
巨大复杂系统
↓
稳定 API / Contract
↓
有限问题空间
↓
App Feature所以这里有一个非常关键的概念：
未来的软件并不是整体变简单，而是复杂性向下沉淀。
系统底层仍然可能极其复杂。
但 AI 不应该每次修改一个按钮，都重新理解整个系统。
3. 这可能是今天 AI Coding 最大的问题之一
现在 Codex、Claude Code、Cursor 这类工具，本质上仍然是在适配为人类设计的软件工程体系。
一个典型任务：
给设置页面增加一个 AI 开关。
Agent 开始：
搜索 Settings
↓
找到 SettingsActivity
↓
发现 Compose
↓
搜索 ViewModel
↓
找到 Repository
↓
寻找数据库
↓
寻找 DI
↓
查看 DataStore
↓
查看已有类似实现
↓
阅读 navigation
↓
阅读 build.gradle
↓
发现项目特殊规范
↓
阅读 AGENTS.md
↓
开始修改这里有个有趣的问题：
真正新增的业务逻辑可能只有几十行。
但是为了安全修改这几十行代码，AI 可能需要阅读数千甚至数万行代码。
这其实是一个非常低效的比例：
Task Complexity ≪ Context Complexity
现在很多所谓 Context Engineering，本质上就是在解决：
怎么从巨大 repository 中，把当前任务真正需要的信息挑出来？
Anthropic 对 Context Engineering 的定义本身就是不断选择和维护模型当前真正应该看到的信息，而不是简单把越来越多 token 塞进去。(Anthropic)
4. 所以你的思想可以进一步升级
不要仅仅说：
未来 AI 应该只实现小功能。
因为别人很容易反驳：
那复杂需求怎么办？
真正应该说的是：
未来的软件系统应该具备一种能力：无论整个产品多复杂，都能把一次变更压缩成局部问题。
也就是：
全局复杂，局部简单。
这是软件工程几十年来一直追求的东西。
模块化、接口、SOLID、微服务、插件系统、Clean Architecture，本质上都在做类似事情。
但 AI 会让这个原则的重要性突然放大。
以前模块化主要是为了：
减少人类工程师的认知负担。
以后可能增加一个目的：
减少一次模型推理所需要加载的上下文。
这甚至可以形成一个新的架构指标：
Context Locality（上下文局部性）
例如：
修改 Feature A 时：
需要理解 100% repository是一个 AI 极不友好的架构。
而：
Feature A
│
├── contract
├── state
├── ui
├── tests
└── capabilitiesAI 只加载这里：
整个 repo：1,000,000 LOC
↓
任务 Context：2,000 LOC可能才是真正的 Agent-friendly Architecture。
5. 事实上现在前沿 Coding Agent 已经在向你的方向收敛
这是你的文章可以加入的一些现实证据。
OpenAI 今年公开的 Harness Engineering 实践非常有意思。
他们描述一个几乎完全由 Codex 写代码的项目时发现，工程师真正需要做的已经不只是“告诉 AI 写代码”，而是：
设计环境、抽象、约束和反馈循环，让 Agent 能够可靠完成任务。
而当 Agent 做不好时，他们并不是简单地“换一个更强 Prompt”，而是思考：
系统缺少什么能力？怎样让这个能力对 Agent 可见并且可以被强制执行？(OpenAI)
这其实跟你的想法高度一致。
Anthropic 在长时间 Coding Agent 实验里也发现，如果直接：
给一个巨大目标
→ Agent 一口气实现Agent 很容易试图一次完成太多事情。
更有效的方式反而是：
初始化环境
↓
Feature 1
↓
验证
↓
留下结构化状态
↓
Feature 2
↓
验证
↓
Feature 3也就是Incremental Progress。(Anthropic)
甚至最新的软件工程 Agent benchmark 也暴露了类似问题。
2026 年 SWE-EVO 专门测试“长期演进大型项目”，任务平均涉及大约 21 个文件。实验中，Agent 在孤立问题上的能力远高于这种长期、多文件的软件演进任务。(arXiv)
所以你的观察并不是单纯的个人感觉。
目前整个 Agent Engineering 领域实际上已经逐渐发现：
让模型变得更强是一条路线，让问题本身变得更容易被模型解决，是另一条同样重要的路线。
6. 但是我会修改你“新的操作系统”这个概念
你现在说：
未来新的操作系统形式，需要是有利于 AI 编码的。
这里我认为“操作系统”可能稍微太底层了。
更准确的概念可能是：
AI-native Application Platform
或者：
Agent-native Software Runtime
它完全可以继续运行在：
Linux
Windows
macOS
Android之上。
真正变化的可能是：
┌────────────────────────────┐
│ AI Generated App │
│ │
│ Feature A Feature B │
│ Feature C Feature D │
├────────────────────────────┤
│ AI Native Runtime │
│ │
│ UI / State / Storage │
│ Network / Auth / Media │
│ Navigation / Permission │
├────────────────────────────┤
│ Android / macOS / Windows │
├────────────────────────────┤
│ Kernel / Hardware │
└────────────────────────────┘AI 真正频繁修改的：
AI Generated App而 Runtime 是高度稳定的。
就像 Android 开发者不会修改 ActivityManagerService 一样：
未来 AI 写 App，也不应该每次去修改基础设施。
7. 更激进一点：未来 AI 甚至不应该写今天这种“应用代码”
这是我觉得你的思想继续推演之后最有意思的地方。
今天：
产品需求
↓
AI
↓
Kotlin / TypeScript / Swift
↓
Framework
↓
OS未来可能变成：
产品需求
↓
AI
↓
Feature Specification
↓
AI Runtime
↓
OS例如一个功能：
用户可以收藏文章，收藏数据需要持久化，并且登录用户可以跨设备同步。
AI 不一定生成：
Repository
Room DAO
Coroutine
ViewModel
UseCase
Retrofit
DTO
Mapper
Database Migration它可能生成类似：
Feature: FavoriteArticle
State:
favorite: Boolean
Storage:
persistent
Sync:
cloud
scope: user
Actions:
favorite(article)
unfavorite(article)
UI:
FavoriteButton然后系统 Runtime 自己解决：
数据库
并发
同步
生命周期
网络
缓存
权限
线程
序列化此时 AI 真正需要思考的，只剩：
业务意图。
这其实才是你所谓“系统规则简单”的真正含义。
不是底层真的简单。
而是：
暴露给生成式 AI 的状态空间足够小。
8. 这里甚至可以定义一个非常重要的原则
我建议你文章里提出一个自己的概念。
例如：
Minimum Coding Context Principle
最小编码上下文原则
一个软件系统越成熟，完成一个局部业务需求所需要理解的系统信息应该越少，而不是越多。
传统项目经常恰恰相反。
五年前：
加一个按钮 → 改 2 个文件五年后：
加一个按钮
↓
Design System
Navigation
AB Test
Analytics
Feature Flag
ViewModel
DI
Repository
Domain
Database
Remote Config
Permission最后 AI 得读半个 repository。
这可以叫：
Context Entropy / 上下文熵。
软件演进越久：
历史约束 ↑
隐式知识 ↑
模块耦合 ↑
特殊逻辑 ↑最终：
完成局部任务所需 Context ↑↑↑AI Coding 的可靠性就下降。
9. 所以未来 AI-friendly 软件架构可能有六个非常明显的特征
我会预测是：
AI Feature
│
▼
┌────────────────────┐
│ 1. Local Context │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ 2. Typed Contract │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ 3. Capability API │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ 4. Sandbox │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ 5. Verification │
└─────────┬──────────┘
│
▼
Accept也就是：
小上下文。 AI 不需要理解整个 repository。
强边界。 不允许 Feature 随便访问整个系统。
Capability 化。 数据库、网络、UI、权限等通过稳定接口调用。
声明式。 尽量描述 What，而不是 How。
Sandbox。 AI 修改范围天然受限制。
Executable Constraint。 最关键，架构规则不是写在 Wiki 里的：
“请不要跨层调用。”
而是系统直接：
跨层调用
→ compile failed这其实就是从：
告诉 AI 应该怎么做
变成：
让错误的做法根本无法成立。
10. 我觉得这是你这篇文章真正有意思的地方
文章最后甚至可以提出这样一个判断：
过去我们一直在问：
怎样让 AI 理解越来越大的代码仓库？
于是：
32K Context
→ 128K
→ 1M
→ Repository RAG
→ Semantic Search
→ Memory
→ Sub-Agent但可能还有另外一个方向：
为什么我们需要让 AI 理解整个代码仓库？
也许未来真正优秀的软件系统，是这样的：
Human
│
Intent
│
▼
┌────────────────┐
│ Coding Agent │
└───────┬────────┘
│
Minimal Context
│
▼
┌────────────────┐
│ Feature Capsule│
└───────┬────────┘
│
Contract
│
▼
┌────────────────┐
│ Stable Runtime │
└───────┬────────┘
│
▼
OSAI 的职责不是：
理解并维护整个世界。
而是：
在一个被精心设计过的小世界里完成任务。
我会把你这篇文章的中心论点改成一句话
你现在的中心思想大概是：
为了提高 AI 编码可靠性，未来操作系统应该更加简单，让 AI 专注于局部功能。
我建议提升成：
未来 AI 编码可靠性的提升，可能不只来自更强的模型和更大的 Context Window，更来自软件架构本身的改变：通过稳定底座、强契约、局部上下文和自动验证，把一个复杂软件系统拆解成 AI 可以独立完成并确定性验证的小问题。
再激进一点，可以作为文章标题：
《AI 编码的未来，也许不是让模型理解整个项目》
副标题：
从 Android Framework 得到的启发：我们真正需要的，可能是一个让 AI 永远只解决局部问题的软件世界。
我觉得接下来我们最值得继续讨论的是一个更深的问题：**如果真的按照这个思路设计一套“AI Native Application Platform”，它究竟应该长什么样，以及 Kotlin/Compose/Android 现有架构为什么还不够 AI-friendly。**这个问题一旦推演清楚，你这篇文章就会从“AI 编程感想”上升成一篇真正有架构观点的文章。