研究笔记
AI 编程
工程方法论
2026 版

AI 编程工程方法论研究笔记

这份文档把 2025–2026 年最有代表性的 AI-native 软件工程方法，压缩成一个可操作的研究框架：从 Spec、Context、Tool、Agent Workflow、Eval 到 Harness，最后收束到 Compound Engineering 的复利系统观。

写作目标不是解释几个新名词，而是回答三个更重要的问题：AI 时代的软件工程到底在重构什么；团队应该先补哪一层；怎样把“会用模型”升级成“会构建可持续的 AI 工程系统”。

8
核心方法论类别
4
工程成熟度阶段
1
统一落地流水线
2026
研究时间边界

1. 执行摘要

1.1 核心判断

AI 编程已经从“让模型生成代码”转向“构建一个能持续产生高质量代码的系统”。这一变化在 2025–2026 年被多个来源同时推动：Martin Fowler 系列文章将 Context Engineering 与 Harness Engineering 明确命名；GitHub 将 Spec-Driven Development 工具化；Anthropic 持续强调 上下文管理、工具设计、长程 agent harness；OpenAI 则把 evals、trace grading、agent 监控与优化 放到了生产化中心。[1][2][3][4][5][6][7][8]

1.2 一句话框架

Spec 定义目标，Context 提供认知边界，Tools 提供可行动作，Agent Workflow 组织执行，Evals 负责验真，Harness 负责长期约束与纠偏，Compound Engineering 则把以上全部变成复利飞轮。

1.3 结论先行

  • Prompt Engineering 没消失，但已经降级成子问题。 现在更关键的是：模型看到了什么、能调用什么、如何被验证、错误能否被沉淀。
  • 团队差距不再只来自模型差距，而来自工程壳差距。 同一个模型，在弱 harness 团队和强 harness 团队里会产生完全不同的生产效果。
  • 未来的软件工程岗位将更偏“监督式工程工作”。 人从直接编码者，转向 specification author、context curator、workflow designer、evaluator、harness maintainer。[9][10]

2. 背景：为什么“Prompt Engineering”已经不够

早期 AI 编程的默认想象是：写一个更好的 prompt，就能获得更好的代码。这个思路在简单单轮任务中依然有效，但一旦任务进入真实软件工程环境，就会暴露出四个结构性问题：

  1. 上下文不稳定： 大仓库、长任务、跨文件、跨轮次时，模型容易丢失关键约束。
  2. 工具调用脆弱： 模型可能不会选对工具，或者选对工具但传错参数。
  3. 输出不可直接信任： 代码“看起来像对的”不代表真的可上线。
  4. 经验无法自动积累： 人工修复一次错误，不代表下次 agent 会少犯一次。

因此，AI 编程的最小问题单元已经不再是“怎么 prompt”，而变成“怎么构建一个可持续运行的工程系统”。Anthropic 对 agent 的实践总结反复强调：简单 agent 往往比复杂 orchestration 更有效，但前提是 上下文、工具、记忆、compaction、任务分解 被设计得足够好。OpenAI 的生产指南则把 准确率目标、工具、守护栏、评测与监控 视作 agent 工程的基本件。[3][4][6][7][8]

3. 方法论全景图

方法论 主要回答的问题 关注层 典型代表
Spec-Driven Development AI 应该做什么 目标定义层 GitHub Spec Kit
Context Engineering AI 应该知道什么 认知输入层 Thoughtworks / Anthropic
Tool / Interface Engineering AI 能动哪些手脚 动作接口层 Anthropic tools guidance
Agentic Engineering 人和 AI 如何协同执行 工作流层 OpenAI Agents / Anthropic coding practices
Eval-Driven Development AI 做得对不对 验证层 OpenAI Evals / trace grading
Verification-First 谁来兜底结果质量 质量门层 tests + lint + schema + graders
Harness Engineering 如何长期约束和纠偏 agent 系统治理层 Thoughtworks / Anthropic harnesses
Compound Engineering 如何形成复利飞轮 演化层 经验沉淀 + 规则回写

4. 八类方法论逐项拆解

4.1 Spec-Driven Development

定义： 先把需求、约束、验收标准结构化为规格，再让 agent 实施。GitHub 将其定位为从 “vibe coding” 走向 “predictable outcomes” 的方法，并将 Spec Kit 开源为工具链。[11][12][13]

为什么重要

  • 把“隐性期望”显式化，减少模型误解。
  • 把“产品语言”转换成“工程可执行语言”。
  • 让生成、评审、测试、验收共享同一个源规格。

最低可落地形态

  • 功能目标
  • 非功能要求
  • 边界与禁区
  • 输入输出 contract
  • 验收标准
  • 回滚条件

本质： 它不是文档主义，而是把“任务描述”升级成“可被 agent、reviewer、tester 共同消费的控制面”。

4.2 Context Engineering

定义： 不是优化一句 prompt，而是设计模型在某一时刻能看到的全部上下文：仓库结构、架构规则、近期改动、运行日志、任务笔记、长期记忆、被压缩的历史状态。Martin Fowler 2026 年文章将其明确化为 coding agent 的关键实践；Anthropic 则强调 compaction、structured note-taking、NOTES.md 等低成本高收益模式。[1][3][14]

关键问题： 不是什么都塞进去，而是决定什么必须长期保留、什么按需拉取、什么必须隔离、什么应该被摘要。

上下文类别 是否长期 典型载体 失效风险
仓库约束 高 ARCHITECTURE.md / AGENTS.md 低
任务目标 中 spec / issue / PRD 中
临时进展 低到中 todo / NOTES.md / scratchpad 高
运行状态 短期 logs / metrics / traces 极高
历史教训 高 runbooks / gotchas / guardrails 低

本质： Context Engineering 解决的是 agent 的“工作记忆设计”。弱团队把上下文当输入文本；强团队把上下文当分层缓存系统。

4.3 Tool / Interface Engineering

定义： 设计 agent 可以调用的工具、接口、参数与返回结构。Anthropic 官方指出，agent 常见失败模式包括：选错工具、传错参数、调用过少、误解工具结果；因此工具名、描述、参数边界和返回格式都直接影响 agent 成功率。[4][15]

工具设计不是附属工作，而是把模型从“纯语言推理”升级成“可操作系统”的核心桥梁。

设计要点：

  • 工具名称要贴近自然任务分割。
  • 参数要少而明确，避免隐式耦合。
  • 返回格式要稳定、可机读、可被后续工具链消费。
  • 工具描述要写明前置条件、失败模式、危险动作。

4.4 Agentic Engineering

定义： 把软件工程任务组织成 plan → act → verify → repair 的 agent 工作流，而不是把整件事一次性扔给模型。OpenAI 的 Agents 文档把 agent 定义为能完成简单到复杂开放式任务的系统，并提供 Agent Builder、Agents SDK、监控优化能力；Anthropic 则长期强调 coding agent 的 bounded tasks、逐步执行与工具使用。[6][7][8][16]

关键转变： 工程师的价值从“多快写完代码”转向“多好地拆分任务、定义守护栏、管理例外”。

4.5 Eval-Driven Development

定义： 先设计评测，再推动 agent 迭代。OpenAI 将 evals 描述为衡量模型是否符合预期的方法，并提供 datasets、graders、trace grading、workflow-level evaluation 等机制。Cookbook 进一步提出 “Eval Driven System Design”，把 eval 作为从 prototype 到 production 的主线。[5][17][18][19]

与传统测试的区别：

  • 传统测试偏确定性输入输出。
  • AI eval 同时处理开放式输出、概率性行为、工具路径、任务完成质量。
  • 评测对象不再只是结果，也包括推理路径和工作流痕迹。

4.6 Verification-First

定义： 把 lint、types、unit tests、integration tests、contract checks、security checks、schema validation、golden cases 作为 agent 输出之前的强门槛。它不是单一品牌词，但已经成为生产环境中的稳定实践。Martin Fowler 关于 AI coding 质量评估的讨论和 OpenAI 的评测实践都在往这条线收敛。[17][18][20]

本质： 模型可以生成，系统必须验证。没有验证层的 AI 编程，本质上仍然是“语义上像工程，实际上像赌博”。

4.7 Harness Engineering

定义： 为长期运行的 coding agent 构建“约束、反馈、垃圾回收、知识注入、质量控制”的工程外壳。Martin Fowler 2026 年文章将其视为 AI-enabled software development 的关键活动，并提到 OpenAI 的 harness 建设耗时数月；Anthropic 则从另一路径讨论 long-running agents 的 harness、compaction 与上下文维持问题。[2][10][21]

关键组成：

  • 规格层：任务、架构、规则、边界。
  • 质量层：lint、tests、evals、审计。
  • 记忆层：长期知识库、NOTES、历史教训。
  • 维护层：清理过期文档、发现结构漂移、压缩无效上下文。

本质： Harness 不是某一个工具，而是 agent 生产系统的“控制平面”。

4.8 Compound Engineering

定义： 把每次任务中的成功模式、失败教训、规则更新和验证工件，回写成下一次任务的可复用资产。它强调工程产出应具有复利效应，而不是单次效率。相关讨论常把它与 project memory、agents.md、规则文件、经验沉淀联系起来。[22][23]

Compound Engineering 的关键不是“这次更快写完”，而是“以后越来越少重复犯错、越来越低成本复现高质量产出”。

5. 横向对比矩阵

维度 传统软件工程 早期 AI 编程 成熟 AI-native 工程
目标定义 需求文档 + 口头同步 模糊 prompt 规格化任务 + 验收标准
知识输入 工程师脑内记忆 一次性粘贴上下文 分层 context + 检索 + compaction
执行方式 人工编码 单轮生成 agent workflow + 工具调用
质量控制 代码审查 + CI 人工目测 tests + evals + trace analysis
经验沉淀 人传人 + wiki 几乎没有 规则回写 + runbooks + memory
长期治理 工程规范 弱约束 harness + guardrails + drift cleanup

6. 团队成熟度模型

L1：提示词作坊

特点：靠个人 prompt 技巧，任务成功高度依赖高手经验。
风险：不可复现，质量不稳定。

L2：工作流拼装

特点：有基础 agent 流程和工具，但规范、验证、记忆薄弱。
风险：能跑 demo，难跑生产。

L3：规格与评测驱动

特点：spec、tests、evals、代码规则齐全。
价值：结果可预测，可持续迭代。

L4：复利式工程系统

特点：拥有完整 harness，失败会变成新规则，新规则会改变下一次 agent 行为；上下文、评测、工具、架构约束被统一治理。
价值：不是“某个人很会用 AI”，而是“整个团队具备 AI 工程能力”。

7. 推荐落地流水线

最稳健的统一流水线不是多名词堆叠，而是单条闭环：

Spec → Context Pack → Tool Access → Plan → Act → Verify → Eval → Review → Lessons Back → Harness Update

7.1 每一步对应的工件

步骤 输入 输出 责任人/责任系统
Spec 需求/问题 任务规格 PM / TL / architect
Context Pack 仓库规则、历史、依赖 最小充分上下文 context curator / harness
Tool Access 工具目录 可执行接口集 platform / agent framework
Plan & Act spec + context + tools 代码/配置/文档改动 agent
Verify 改动结果 确定性质量检查结果 CI / linters / tests
Eval 行为轨迹与结果 可比较质量评分 eval harness / graders
Review 全部工件 接受 / 退回 / 修复意见 human reviewer / reviewer agent
Lessons Back 失败与成功模式 规则、runbook、memory 更新 compound loop

8. 组织与角色重构

AI 编程工程方法论的真正冲击，不在“代码更快写了”，而在角色的重心改变了。Martin Fowler 2026 年关于 humans and agents loops 的讨论，以及有关 supervisory engineering work 的碎片文章，都指出工程师越来越多地承担指导、评估、校正与 harness 维护工作。[9][10]

8.1 新角色原型

  • Spec Author： 把模糊业务目标转成可执行规格。
  • Context Curator： 维护上下文包、知识库、压缩策略。
  • Toolsmith： 设计和治理 agent 工具接口。
  • Eval Engineer： 构造数据集、grader、回归评测。
  • Harness Maintainer： 维护 guardrails、规则、垃圾回收机制。
  • Supervisor Engineer： 人类在回路外/上层，专注验真和方向控制。

8.2 对管理层的含义

  • 不要只采购模型额度，要投资 harness。
  • 不要只追求首日效率，要追求第 90 天的稳定产能。
  • 不要只看“写了多少代码”，要看“失败是否被转化为组织资产”。

9. 常见误区与 gotchas

误区 1：把 prompt 当方法论

后果：任务靠人，不靠系统。人换了，效果断崖式下滑。

误区 2：过早多 agent 化

后果：编排复杂度暴涨，调试与评测难度反而超过收益。OpenAI 和 Anthropic 都强调：单 agent + 好工具，通常先于复杂多 agent。[6][13]

误区 3：没有 eval 就追求自治

后果：看似自动化，实则把不可见风险埋进流程深处。

误区 4：只沉迷生成，不沉淀规则

后果：每次都像第一次，永远没有复利。

9.1 典型 gotchas 清单

  • 上下文过载： 给太多信息不等于更聪明，往往更混乱。
  • 过期知识污染： 老文档进入上下文会把 agent 引向废弃实现。
  • 工具接口漂移： 工具文档未更新，agent 仍按旧 contract 调用。
  • 测试通过但行为错： 确定性测试不能覆盖开放式工作流质量。
  • runbook 不可执行： 写给人看的经验，没有转成 agent 可消费规则。
  • 只做记忆，不做垃圾回收： 长期知识库会越来越脏，最终反噬 agent。

10. 90 天落地路线图

阶段 时间 目标 交付物
阶段 1 1–2 周 选定高频、低风险任务作为试点 任务清单、基线流程、失败样本
阶段 2 3–4 周 建立最小 spec 模板与 context 包模板 spec 模板、AGENTS.md、NOTES.md
阶段 3 5–8 周 引入 tests/evals，建立可比较基线 golden cases、grader、回归报告
阶段 4 9–12 周 构建 harness 回写与规则更新流程 runbooks、gotchas 库、memory 机制

11. 结论

AI 编程工程方法论的演进方向非常清晰：从“单次生成”走向“系统性生产”，从“提示技巧”走向“控制面设计”，从“人修模型错误”走向“把错误转化成组织资产”。

真正的分水岭不是谁先接入了最强模型，而是谁先把模型嵌入了一个可验证、可约束、可积累、可进化的工程系统。

因此，最值得投入的，不是继续追逐下一个热词，而是系统地补齐这六层：Spec、Context、Tools、Workflow、Evals、Harness。补齐后，Compound Engineering 自然发生；补不齐，所有“Agent 化”最终都会退化成更昂贵的手工活。

12. 参考资料

  1. [1] Martin Fowler, Context Engineering for Coding Agents, 2026-02-05.
  2. [2] Martin Fowler, Harness Engineering, 2026-02-17.
  3. [3] Anthropic, Effective context engineering for AI agents, 2025-09-29.
  4. [4] Anthropic, Writing effective tools for agents — with agents, 2025-09-11.
  5. [5] OpenAI, Evaluation best practices.
  6. [6] OpenAI, Agents guide.
  7. [7] OpenAI, Agent evals.
  8. [8] OpenAI, Building agents learning track.
  9. [9] Martin Fowler, Fragments: March 16, 2026-03-16.
  10. [10] Martin Fowler, Humans and Agents in Software Engineering Loops, 2026-03-04.
  11. [11] GitHub, spec-kit repository.
  12. [12] GitHub Blog, Spec-driven development with AI, 2025-09-02.
  13. [13] GitHub, spec-driven.md.
  14. [14] Anthropic Engineering, Effective harnesses for long-running agents, 2025-11-26.
  15. [15] Anthropic Research, Building Effective AI Agents, 2024-12-19.
  16. [16] OpenAI, Agents SDK.
  17. [17] OpenAI Cookbook, Eval Driven System Design - From Prototype to Production, 2025-06-02.
  18. [18] OpenAI, Working with evals.
  19. [19] OpenAI Developers Blog, Testing Agent Skills Systematically with Evals, 2026-01-22.
  20. [20] Martin Fowler, Assessing internal quality while coding with an agent, 2026-01-27.
  21. [21] Anthropic Engineering index, Engineering posts archive.
  22. [22] Every, Compound engineering: how Every codes with agents.
  23. [23] Stormy AI, Mastering agents.md & AI coding memory.