上下文工程：AI-Native时代的软件研发新范式

这两年，大家都在说「用 AI 写代码」。

但我越来越确定一件事：

真正有价值的，不是 AI 写了多少行代码，而是——你是不是在做 AI-Native 的软件工程。

换句话说，不是“让 AI 帮忙写点函数”，

而是：把 AI 当成一个 24 小时在线的 Pair Programmer，参与整个工程流程——

需求、用例、API、TDD、实现、文档，一个环节都不落。

工程方法论本身不变，只是每一步后面，都悄悄多了一个 AI 通道。

一、工程步骤一个都不省，只是每步都有 AI

先说底线：我不相信「无文档开发」「无测试开发」「AI 一把梭」。

我的流程还是那一套很“科班”的：

需求确认 → 用例分析 → API / CRD 设计 → 模块拆分 → TDD → 实现 → Code Review → 文档

区别只是：

• 需求分析不能省 → 用 AI 帮我梳理输入边界、找歧义
• 测试不能省 → 用 AI 帮我先写测试骨架
• 文档不能省 → 用 AI 把文档变成开发过程的副产物

AI 时代的编程，本质上是一场「代码通胀」与「价值通缩」的博弈。

人类负责守住价值的底线。

二、人类做决策：最小必须原则（The Principle of Minimum Necessity）

我给自己画过一张粗暴的分工表。

人类负责的：

• 做减法（熵减）：

  最小必须原则——如无必要，勿增实体。 哪怕 AI 一秒能给我堆出一套“看起来很高级”的微服务架构，如果一个单体能解决，我就只让它写单体。

• 需求优先级、取舍

• 架构方案选择

• 边界用例补充

• 代码逻辑审核 & 最终质量把关

AI 负责的：

• 方案草稿生成（接口、CRD、方案对比）
• 常规用例生成
• 代码骨架、样板逻辑
• 文档初稿、接入指南、测试指南

一句话：

人定边界，AI 填细节。

AI 天生有“堆东西”的倾向，

人要做的是不断挥舞奥卡姆剃刀：

删掉不必要的复杂度，让系统熵减。

三、基于上下文工程的 Vibe Coding

Andrej Karpathy 在今年年初提出了一个概念：Vibe Coding

以前我们也算是“Pair Programming”，

只不过另一个伙伴叫 Google / Stack Overflow，而且是个哑巴。

现在这个伙伴终于长了嘴，虽然话有点多，但好在真的能干活。

Vibe Coding 的核心不是“边听歌边写代码”，而是：

• 人类尽量待在 Flow 状态里：
• 想业务、抽象、模型、trade-off，而不是某个库的 API 写法
• AI 负责所有会打断 Flow 的机械活：
• 查文档、改样板、迁一堆重复 if/else、补注释、写初版文档

我的实际习惯是：

1. 用自然语言把需求 / 设计 /约束丢给 AI
2. 让它帮我：

• 生成用例矩阵
• 提几版 API / CRD 设计
• 写一版测试骨架 / 代码骨架

• 我只做那 20% 必须自己负责的部分：选择、取舍、删减、收口。

失败成本变得极低：

想法 → 测试 → 骨架 → 跑起来 → 砍掉重来，

一整套闭环可以在很短时间里反复跑。

---

四、上下文工程：Context is the new Source Code

慢慢地，我发现一件很有意思的变化：

以前我主要维护的是代码仓库（Git Repo），

现在我同样认真地在维护上下文（Context）。

所谓 AI-Native 开发，本质上其实是：上下文工程（Context Engineering）。

我不仅要告诉 AI“要做什么”，

更重要的是：我要像管理内存一样管理它的上下文窗口：

• 哪些历史决策是必须保留的？
• 这就像给上下文做 Snapshot：关键设计、边界约束、命名约定，这些要一直在。
• 哪些中间过程产生的噪音必须清除？
• 这就是 GC：试错过程、无效方案、已经推翻的假设，如果不清掉，AI 会反复捡起来当真理用。
• 如何把 PRD / wiki 这种“非结构化数据”，清洗成 AI 能理解的“结构化 Prompt”？
• 比如先抽出：角色、目标、约束、输入输出、边界条件，再喂给 AI，而不是甩一大坨原文档。

在这个视角下：

代码只是“上下文流过 AI 之后，沉淀下来的结晶”。 **上下文脏了，结晶一定有杂质。垃圾进，垃圾出（GIGO）。在 AI 时代，上下文污染就是新的‘内存泄漏’。

所以对我来说：

上下文就是新的源码（Context is the new Source Code）。

Git 管的是 history，Context 管的是现在这一次调用 AI 时的“认知状态”。

---

五、一个真实项目：IAM-Operator 怎么落地这套方法

说点实战的。

项目背景：

我做过一个 Kubernetes 的 IAM-Operator，

核心目标是：在集群里自动注入访问凭证，替代手工配置和脚本拼接。

项目周期：1 个月，从 0 到生产上线。

开发搭子：Claude Code + TDD。

1. 需求 & 上下文：先把「说不清」翻出来

我把 PRD 和 Helm 的 values.yaml 丢给 AI，让它做上下文清洗：

• 把所有输入参数 & 可能取值边界列出来
• 生成一个「需求歧义 checklist」：
• 哪些场景没定义？
• 冲突策略是什么？
• 多集群 / 多租户怎么处理？

这一步本质上就是：用 AI 帮我整理“干净的上下文快照”。

我带着这份 checklist 去跟产品 & 运维对齐，

那些以后一定会踩坑的地方，基本都提前被翻出来了。

2. CRD & 技术选型：AI 拉草稿，人拍板 + 最小必须

CRD 设计阶段，我让 AI 先生成一版 IAMCredential 的 CRD Schema 草稿。

我做的事只有三件：

• 用“最小必须原则”砍字段和层级
• 保证抽象和平台里其他资源保持一致
• 明确哪些字段 immutable，哪些可以演进

技术选型也是类似流程：

• AI 拉出 Python Operator vs Go + Kubebuilder 的对比表
• 我基于团队技能栈、长期维护成本、性能约束做决定
• 最终选择 Go + Kubebuilder ——不是因为“看起来更高级”，而是因为在“最小必须”前提下它更稳。

3. TDD + 实现：先锁定“什么算对”，再让 AI 写

TDD 这块，我会刻意给 AI 一个角色：

• 让 AI 根据需求 + CRD，先写出单测 & 表驱动测试的骨架
• 我再补：
• 极端场景
• 租户 / 配额 / 网络抖动等边界
• 确认「什么算对」之后，再去写实现代码

实现阶段，很多样板分支、client 调用、错误处理，都可以交给 AI，

我主要盯核心逻辑、性能、可维护性。

4. Code Review：顺便做一次“含 AI 量检测”

在 Code Review 上，我会多看一个维度：含 AI 量。

• 有一些一眼就能看出来是 AI 写的代码：
• 命名很好看，注释很工整，逻辑也没错
• 但你一试，发现“删掉也不影响业务”
• 对这种“正确的废话代码”，我的态度是：删。

AI 很擅长给你多加两层抽象、加几个没必要的 helper。

这个时候“最小必须原则”又要出来挡刀：

架构要长在真实复杂度上，而不是长在 AI 的想象力上。

5. 文档：从「项目结束补作业」变成「一路长出来」

以前写文档是项目最后的痛苦补作业。

现在我基本改成：

• 每有一次比较大的设计决策 / 接口变更
• 顺手把上下文丢给 AI，让它生成：
• 技术方案章节
• 接入指南的一小节
• 运维手册里的一个场景

项目结束时，自然就有了：

• 技术方案
• 接入指南
• 运维手册
• 测试说明 / 回归 checklist

这些东西不是事后硬编，而是在上下文工程做好之后，自然流出来的产物。

---

六、幻觉对抗：你是船长，它只是舵手

当然，这一切有一个前提：

你得有能力识别“一本正经胡说八道”。

上下文工程的一大核心，就是随时警惕 AI 在上下文里“偷偷下毒”：

• 引用了不存在的库
• 捏造了从没定义过的参数
• 把已经被推翻的老方案重新捡起来当默认

我给自己的原则是：

你是船长，它只是舵手。 它力气大、方向感也不错，但一旦你发现它眼花了，你要有能力把方向盘抢回来。

---

七、为什么我要坚持这套 AI-Native 方法论？

总结一下，我现在做新项目，基本都按这套方式来：

1. 工程方法论不变，AI 只是全流程加速器

   确保项目是能跑到生产的系统，而不是 AI 玩具。

2. 上下文工程 + 最小必须原则

   上下文干净，代码才干净；

   架构做减法，系统才不会被 AI 堆成一座技术债金字塔。

3. 开发者体验变好了

   需求更清晰、测试更完整、文档一路长出来，

   而且——写代码这件事，重新变得好玩了。

如果你已经在用 AI 帮你查 bug、补函数，不妨往前再走一步：

从「写代码」， 升级成「做上下文工程」。

当你真正把 AI 纳入整个软件工程流程，你会发现：

不是你在用 AI 写项目，而是你和 AI 一起在“养”一个系统。