穿透性上下文驱动的 AI 编程工程实践
🟡 2026-04-26，基于一场软件部&技术委深度技术讨论，炜然总系统阐述了他对 AI 编程的底层思考。 本文将其整理为可复用的方法论框架，并补充了”AI Native Design Pattern”的视角。
一、问题的起点：大模型编程范式的结构性缺陷
当行业还在讨论 Vibe Coding 与 Spec Coding 的优劣时，真正需要正视的是当前 AI 编程工具存在的三个结构性缺陷——任何方法论都必须先解决它们：
❗ 缺陷一：上下文陷阱 AI 会深度陷入当前问题单的上下文，缺乏对整个软件系统的全局视角。上下文窗口的限制从根本上约束了它的智慧上限。 缺陷二：补丁螺旋 当设计本身存在问题时，持续向 AI 提交 bug，它只会在补丁上继续打补丁，无法从根本上审视和修正设计。 缺陷三：视角锁定 AI 无法跳出当前修改点，以更高维度的视角去思考——应该改算法、改策略，还是改架构。它只会在当前修改点上做局部优化。 关键洞察： 这三个缺陷并非 prompt 编写不当所致，而是大模型注意力机制决定的——它以当前用户关注为优先，天然缺乏系统观。因此，人的世界观和系统级理解变得越发重要。
二、AI 编程三阶段：从 Spec 到 Taste 到反哺
AI 编程可分为三个演进阶段。当前行业普遍停留在第一阶段，而真正的生产力释放来自第二和第三阶段。
第一阶段：Spec 编程（初级）
人定义 spec，AI 按 spec 执行。这是当前行业主流，也是基础——没有结构化的 spec，AI 就是在盲目猜测。核心要求：先做到 spec 化，把静态知识结构化输出。
第二阶段：品味驱动（中级）
人不只定义”做什么”，而是将软件工程的审美和判断注入 AI 的工作流程中：
- 代码的可维护性——不允许腐坏
- 后向兼容——符合架构承诺
- 运行环境约束——例如运行在手机端
- 长期维护方案——避免代码过度膨胀
人的核心任务是为 AI 提供项目上下文以外的认知——这些是大模型自身无法理解的。
第三阶段：反哺大模型（高级）
AI 不只是被引导，而是从人的引导中学习，形成更好的软件工程判断力。这是一个人机互相成就的循环，也是必然的演进方向。
实践路径映射：
- 第一步（静态）：Spec 化 = 把已知知识结构化 → 对应第一阶段
- 第二步（动态）：牵引 AI 管好上下文、往正确方向走 → 对应第二阶段
- 第三步（反哺）：让 AI 自主管理这部分工作 → 对应第三阶段
三、核心概念：穿透性上下文（Penetrating Context）
面对 AI 的三个结构性缺陷，核心解法是穿透性上下文。
关键区分：
- 上下文堆砌（Context Stuffing）：给 AI 更多文件、更多日志、更多信息 → 信息过载，AI 反而更差
- 穿透性上下文（Penetrating Context）：人提供系统级判断和方向性引导 → AI 获得更高维度的视角
在这个过程中，人对软件系统的认知理解和引导越发重要。这种新的视角由人赋予，即穿透性上下文。
操作含义： 当 AI 陷入补丁螺旋时，不要给它更多信息，而是换一个维度提问——“是否应该改算法而不是改参数？""这个设计本身是否存在问题？“——将 AI 从局部修补拉到系统级思考。
四、工程实践体系
4.1 六份文档铁律
整个项目必须包含以下六份文档，用于 AI 理解项目全貌：
| 序号 | 文档 | 作用 | 负责人 |
|---|---|---|---|
| 1 | 产品需求文档（PRD） | 定义”做什么” | 产品 |
| 2 | 架构设计文档 | 定义”怎么组织” | 架构师 |
| 3 | 算法与策略/模型调用设计 | 定义”核心逻辑” | 算法 |
| 4 | 测试系统设计 | 定义”怎么验证” | 测试 |
| 5 | 回测系统设计 | 定义”怎么审计” | 测试 |
| 6 | 代码修改历史记录 | 定义”改了什么” | 全员 |
关键要求：
- 每次代码修改必须同步更新对应子文档
- 子文档在指定文件夹下生成，周期性整合
- 每次整合保留前次记录版本号
- 文档的核心目的是让 AI 理解项目全貌，而非仅供人阅读
4.2 七步闭环工作流
- 提交模块需求（人的判断）
- 要求生成架构文档 + 给出对现有代码的影响分析
- 要求更新测试文档
- 要求对齐三份文档的一致性，确保无矛盾
- 生成代码，启动测试
- 解决问题
- 启动回测系统，给出影响分析报告
核心原则： 整个过程中，人需要根据实际输出不断梳理要求并提交给 AI。人在回路中不是审批者，而是引导者。
4.3 模板化问题清单
在项目开始时，预先梳理出所有需要向 AI 提出的模板化问题。在任何变化、任何修改发生时，将这些模板化问题一次性提交给 AI。
示例问题模板：
- 这个代码修改点是否符合之前的架构承诺？
- 是否具备后向兼容？
- 是否会导致代码过度膨胀？
- 多次修改和需求变更后，是否仍具备可维护性？
本质： 不是每次临时想问题，而是把软件工程的判断标准模板化，变成 AI 每次修改前必须回答的 checklist。
五、两个独创机制
5.1 多方案融合
不是让 AI 从零生成一个方案，而是人跑多轮实验后，让 AI 融合多方案的优缺点。
流程：
- 人自己先跑用例，摸清问题本质
- 让 AI 帮助优化用例
- 更新回测系统
- 让 AI 生成架构优化方案
- 经过 2-3 次方案尝试后，把修改点和测试报告提交给 AI
- 明确告知 AI：要方案一的优势 + 避免方案三的问题 → 让它融合生成新方案
核心思路： AI 本质上是一个极其聪明但不懂业务的大脑。人的任务是在与它不断交流的过程中，获取针对具体业务的最优方案。
5.2 回测审计系统
回测系统用于每次代码提交后的审计，输出增量代码的影响分析。
要求：
- 所有代码合入必须跑完测试，自动下载更新跑 trace 并提交分析
- trace 交由低成本模型（如 MiMo）分析，无需人工逐条查看
- 无法自动验证的部分由人工验证，输出验证信息到指定目录
- 文件名格式：时间_模块_trace
- 利用历史验证的 trace 信息和 Jira 单审核，记录所有信息
本质： 代码合入的质量门禁。在 AI Agent 开发中，模型行为的非确定性使得回测比传统单元测试更为关键。
六、四大难题与质量悖论
6.1 记忆、上下文、提示词、意图
这是 AI 编程中最具挑战性的四个维度：
- 记忆：在海量的长期记忆中提取与当前上下文相关的内容，极其困难
- 上下文：提示词和上下文为了命中率，会保持恒定部分，在此基础上增加变量
- 提示词：被严重低估的要素。实践验证表明，删除部分提示词后系统反而表现更好
- 意图：人的真实意图如何准确传达给 AI
6.2 AI 时代的软件质量悖论
由于代码生产效率极高、片面解决问题的效率极高，整个软件质量的控制反而变得越来越困难。AI 对人的数量要求降低了，但对人的质量要求显著提高了。
核心洞察： AI 不是让软件工程变简单了，而是让人与人之间的差距被放大了。优秀的工程师借助 AI 更加高效，而能力不足者产出的代码质量可能差距达到 10 倍。AI 是能力放大器，而非能力替代品。
七、行业对标
| 方法论 | 与本方法论的关系 |
|---|---|
| Spec-Driven Development | 基础层。本方法论在此之上增加了回测审计和多方案融合 |
| TDD / Superpowers | 部分重叠。TDD 聚焦单任务粒度，本方法论偏系统级 |
| Eval-Driven Development | 部分重叠。Eval 用于 prompt 优化，本方法论用于整个 Agent 架构迭代 |
| ADR/RFC 流程 | 形式相似。传统 ADR 面向人，本方法论的文档面向 AI |
| Karpathy auto-research | 互补。Karpathy 研究让 AI 更自主，本方法论研究让人更好地引导 AI |
| Harrison Chase Harness | 概念相通。六份文档 = 认知层面的 harness |
| Factory.ai Software Factory | 结构相似。本方法论多了回测审计和多方案融合两个环节 |
框架视角： 类比传统软件工程从口口相传到总结出 Design Pattern 的过程，AI Native 时代也应有其 Design Pattern。本方法论本质上就是第一批 AI Native Design Pattern——它回答的不是”怎么写代码”，而是”怎么与 AI 协作写代码”。
八、实操清单
✅ Do（应该做）
- 文档先行：项目启动时先建立 6 份文档框架，即使内容不完整也要有骨架
- 先跑实验再提需求：自己先跑用例摸清问题本质，再让 AI 介入
- 多方案融合：经过 2-3 次方案尝试后，让 AI 融合优缺点生成新方案
- 穿透性引导：给 AI 系统级方向，而非让它在局部修补
- 模板化 checklist：项目开始前梳理所有需要问 AI 的模板化问题，每次修改一次性提交
- 先仿真再提交：要求 AI 每次有了思路先仿真、再跑回测、再提交
- 文档同步更新：每次代码修改必须同步更新对应子文档
- 回测审计：代码合入前必须跑回测，输出增量影响报告
- trace 外包分析：将 trace 交由低成本模型分析，无需人工逐条查看
- 引导 AI 换视角：当 AI 陷入补丁螺旋时，主动将其拉到更高维度思考
❌ Don’t（不应该做）
- 不要让 AI 直接改代码：先要求它输出架构文档和影响分析，再执行修改
- 不要只提交问题单：不加引导地提交 bug 给 AI，它只会打补丁
- 不要信息过载：不要把所有文件都丢给 AI，要给穿透性判断
- 不要跳过一致性检查：需求、架构、测试三份文档必须对齐后才生成代码
- 不要让 AI 从零生成方案：给它实验数据让它融合，而非让它凭空设计
- 不要跳过回测：没有回测的代码合入等同于盲人过马路
- 不要让人自己看 trace：这是对人力的浪费，应交由低成本模型处理
- 不要追求局部最优：单个模块的最优可能导致全局问题
- 不要忽视文档版本管理：子文档必须有版本号，可追溯
- 不要用 Vibe Coding 方式做系统级开发：闲聊式交互只适合小脚本，不适合 Agent 架构
九、总结
AI 不缺智商，缺的是世界观。人的任务不是替代 AI 写代码，而是赋予 AI 一个穿透局部视野的全局视角。通过文档固化认知、通过实验驱动方案演化、通过回测闭环保证质量——这就是穿透性上下文驱动的 AI 编程工程实践。
核心理念可以归结为：多实践、多尝试，在实践中才能真正理解这套方法论的价值。而从行业视角来看，类似于多年前人类总结出 Design Pattern，在 AI Native 时代，也应当有属于这个时代的 Design Pattern。