AI Coding提速后，软件工程瓶颈与Harness Engineering实践-平芜编程栈

AI Coding 的速度上限被拉高之后，软件工程的下一个瓶颈在哪里？这个问题比“哪个模型生成代码更强”更值得讨论。

最近一两年的实际体验是：用 AI 完成一个功能模块的编码，已经从“半天”缩短到“几十分钟”，甚至更短。但团队的整体交付节奏并没有按同样的比例提速。需求评审、接口约定、测试回归、代码审查、上线排期，这些环节依然按天甚至按周计算。于是出现了一个很反常的现象：写代码的人越来越快，软件工程却没有变快。

这篇不是某个模型或工具的安装教程，而是围绕“AI Coding 提速之后，Engineering 怎样同步迭代”的方法论拆解。我会先拆清楚 coding 和 engineering 的边界，再列出工程链路里真正的瓶颈，最后给出一套可以落到团队流程里的实践路径，包括 Spec 定义、Coding Plan、验证闭环和落地度量。如果你正在带团队摸索 AI 研发流程，或者想搞清楚 vibe coding 之后下一步往哪走，这篇可以直接收藏。

1. AI Coding 提速的本质：编码环节被大幅压缩

1.1 Coding 与 Engineering 并不是一回事

先做一层概念切分。

Coding 是把设计翻译成代码的动作，输入是明确的需求、接口定义和约束条件，输出是可运行的代码片段。Engineering 则是从问题定义到交付上线的完整链路，包含需求分析、系统设计、任务拆解、编码实现、测试验证、代码评审、部署发布、线上观测和后续迭代。

AI Coding 的提速，本质上是把“编码”这个单点动作的性价比拉到了极致。模型可以快速生成样板代码、补全函数、写单元测试、做小范围重构，甚至在一段对话里完成一个文件的初稿。常用 Copilot、Cursor、Claude Code 或各类 Coding Agent 的开发者，应该都能感受到这种变化：以前需要半小时完成的 CRUD 接口，现在只需要把表的字段列清楚，让 Agent 生成，再手动改掉边界情况。

但工程交付的耗时并没有等比例下降。原因是：工程链路中真正占用时间的环节，从“写代码”转移到了“把问题定义清楚、把上下文组织好、把验证跑起来、把风险控制住”。

1.2 AI 真正解决的是“从代码到功能”的翻译问题

当前 AI Coding 工具的核心能力，可以归纳为几类：

代码生成：根据自然语言或上下文生成函数、类、接口实现。
代码补全：在编辑器内根据前文预测后续代码。
代码理解和解释：对已有代码库做结构说明、定位逻辑、生成文档。
测试生成：自动生成单元测试、接口测试用例。
重构与修改：基于指令修改遗留代码，或完成小范围迁移。
多文件 Agent 任务：读取多个文件、跨模块修改、批量处理重复代码。
Coding Plan：把一个大任务拆解成多步计划，由 Agent 按步骤执行并自检。

这些能力解决的核心问题是“从想法到代码的翻译成本”，但翻译之前的问题定义，和翻译之后的验证交付，仍然需要人去完成。

1.3 编码时间占比越来越低，瓶颈已经转移

传统软件工程里，编码可能占开发周期的 30% 到 40%。当 AI 把这个比例压缩到 10% 甚至更低时，其他环节的比重就会被迫放大。

举一个常见场景：一个后端服务需要新增一个数据导出功能。以前开发人员要写查询逻辑、组装数据、写导出工具、补单元测试，可能要花大半天。现在用 AI Agent，可能十几分钟就生成了初版。但真正要上线，还需要确认：

导出字段和过滤条件是否和产品预期一致；
数据量很大时的内存和超时控制；
是否有权限校验和审计日志；
是否需要异步任务和进度提示；
测试数据和回归用例是否覆盖边界条件；
数据库查询索引是否合理。

这些问题是 AI 无法单方面替你回答的。它们依赖业务背景、系统现状和团队约定。所以更准确的判断是：AI Coding 让“快速产出代码”变成了现实，但“快速做出正确的软件”仍然是工程问题。

2. 工程没有变快的真实瓶颈

2.1 需求与规格定义是新的时间黑洞

很多团队在 AI 辅助开发后遇到的第一个问题，不是代码写不出来，而是“需求本身不够清楚”。

传统流程里，需求不明确时，开发人员会在写代码的过程中补问、确认、调整，编码时间本身有“消化不确定性”的作用。AI 出现后，这个缓冲被压缩了。你把一段含糊的需求丢给 Agent，它很可能直接生成一段“看起来合理但方向错误”的代码，反而增加了返工成本。

于是，Spec-Driven 的开发方式重新被重视。Spec 在这里不是传统意义上的几百页需求文档，而是一份足够精确、足够机器可读的任务描述，包含背景、输入输出、约束条件、验收标准和异常处理策略。

从实践看，规格定义的时间投入可以显著降低 AI 生成代码的返工率。这个环节省不得。

2.2 上下文工程：Agent 不知道的事情，就无法正确完成

AI Coding 和传统编程最大的差异在于：传统程序员可以通过浏览项目结构、阅读调用链来建立上下文；而 Agent 的上下文窗口有限，它看到的只是你喂给它的文件、文档和对话历史。

于是出现了大量“看起来在认真写代码，实际上在无中生有”的现象。例如：

Agent 假设某个接口存在，直接调用，但项目里根本没有这个接口；
Agent 沿用旧的配置项，没有注意到配置中心已经迁移；
Agent 只修改了调用方，没有改底层实现，导致类型不匹配；
Agent 对某个业务规则的理解和现有系统不一致。

这些问题的根源不是模型能力，而是上下文供给不足。2019 年之后出现的 Context Engineering（上下文工程）概念，就是专门解决这个问题：如何把项目结构、关键代码、技术约束、任务目标，以最优的方式组织给 Agent。

解决上下文问题有几个常用的手段：

在项目里维护一份权威的 AGENTS.md 或项目说明，写清楚目录结构、技术栈、编码规范、常用命令；
任务下发时，把关键入口文件、数据模型、接口定义一起作为附件喂给 Agent；
用检索方式从代码库中抽取相关片段，而不是让 Agent 自行猜测；
对复杂的多文件修改任务，先让 Agent 输出计划，确认后再执行。

2.3 架构决策与系统设计无法自动生成

AI 可以写出高质量的函数，但很难替团队做出“这个模块应该放在哪个服务”“这次是同步调用还是异步事件”“数据一致性用哪种方案”这类架构决策。

原因很简单：架构决策依赖大量隐性约束，包括团队维护能力、基础设施现状、历史包袱、业务发展预期。这些约束很难完整写进提示词，更不可能每次都从零描述给模型。

工程化 AI 的正确做法，是让 AI 在架构边界内发挥效率，而不是让 AI 来决定架构。先有约束，再让 Agent 在约束内生成代码，输出质量会稳定得多。

2.4 测试验证与质量闭环仍然依赖人

代码可以自动生成，但测试设计很难完全自动化。因为测试的本质是“明确预期行为”，而预期行为来自业务需求和系统设计。如果预期本身不清楚，AI 生成的测试也只能是“基于代码现状的自我确认”，看起来覆盖率高，实际没有捕捉到真正的问题。

工程链路里应该建立的闭环是：

从 Spec 推导出验收标准；
让 AI 根据验收标准生成测试用例；
运行测试，收集失败结果；
把失败信息反馈给 AI，让它修正代码；
人工复核修正逻辑是否合理。

这个闭环已经被很多团队验证为有效，但它需要工程纪律来保障。没有质量闭环的 AI Coding，速度越快，风险积累越深。

2.5 审查、协作与交付链路拖慢了整体速度

代码生成之后，还需要人工审查、合入、构建、部署。传统流程里很多环节是串行的：写代码 → 提交 → 评审 → 修改 → 测试 → 上线。AI 把第一个环节缩短后，后续环节没有同步自动化，整体流程仍然卡在队列里。

这也是“AI Coding 变快了，Engineering 没变快”最直观的原因：你只是加速了流水线上的一个工位，其他工位的产能没有变。

要真正提升工程整体效率，需要把 AI 能力嵌入到更多环节里，包括：

自动生成代码评审意见；
自动补充单元测试和集成测试；
自动生成变更说明和发布说明；
自动分析失败用例并定位可疑代码；
自动把人工评审意见总结成修改指令，让 Agent 迭代。

这些都属于 AI Engineering 的范畴，而不是单纯的 AI Coding。

2.6 部署、运维与反馈回路依然需要稳定体系

上线只是开始，真正的工程成本消耗在运行阶段：日志排查、监控告警、性能优化、故障恢复。AI 可以辅助分析日志、推荐修复方案，但可观测性的数据采集和指标设计，仍然需要团队提前做好。

工程提速的另一个关键在于缩短反馈回路。AI 生成的代码能不能尽早跑到真实环境里，用真实数据验证，直接决定 AI 的效率能不能转化为交付效率。如果反馈回路是小时级别的，AI 的速度优势就会被抵消殆尽。

3. 从 Vibe Coding 走向 Harness Engineering

3.1 Vibe Coding 为什么火，又为什么不够

Vibe Coding 是最近出现频率很高的词，描述的是“把需求用自然语言描述给 AI，让 AI 生成代码，再做少量修改”的开发方式。它之所以流行，是因为门槛极低：不需要完整理解底层实现，也能快速做出原型。很多个人开发者用这种方式做小工具、小站点，效率确实很高。

但 Vibe Coding 的问题也很明显：缺少可验证性。当代码由 AI 生成、人不完全理解时，bug 会藏在细节里。随着代码量增长，AI 对系统整体结构的理解会越来越弱，修改一个地方可能引入另一个问题，最终变成“无法维护的 AI 代码堆”。

如果只做一次性原型，这没有问题。但做生产系统，不能只靠 vibe。

3.2 Harness Engineering：给 AI 套上工程缰绳

Harness Engineering 是更工程化的应对方式。harness 的本意是“挽具、控制器”，在这类语境里可以理解为“为 AI 建立可控的执行框架”。

它的核心思想是：AI 仍然是代码生成的主力，但它的行为必须被约束在一个可验证、可回滚、可观测的框架内。具体包括：

明确的输入输出协议；
可执行的任务计划；
分阶段的验证门禁；
失败后的自动反馈回路；
人工确认的关键决策点；
完整的日志与追踪能力。

换句话说，Vibe Coding 是“让 AI 自由发挥”，Harness Engineering 是“给 AI 铺轨道，让它跑得快且不脱轨”。

3.3 AI Engineering 的整体框架

AI Engineering 比单纯的 AI Coding 范围更大，它关注的是如何把大模型、Agent、外部工具和工程流程组合成一个可靠的生产系统。几个重要方向：

Prompt Engineering：设计高质量的指令，让模型稳定输出；
Spec Coding：从清晰规格出发编码，减少歧义和返工；
Context Engineering：组织上下文，保证 Agent 拥有完成任务所需的信息；
Graph Engineering：用图结构管理代码依赖、任务依赖和 Agent 协作关系；
Loop Engineering：设计包含执行、验证、反馈、修正的闭环流程；
Evaluation Engineering：用评测集验证模型或 Agent 的输出质量。

这些方向正在取代“把提示词写长一点”的朴素操作，成为团队落地 AI 研发基础设施的底座。

4. 几个正在被验证的工程化方向

4.1 Spec-Driven Coding：先写规格，再造代码

Spec-Driven Coding 的思路是：把需求文档、接口定义、数据模型、验收标准写成一个结构化规格，再让 AI 按规格生成代码。这个规格既是给 AI 的任务输入，也是给人工评审的验收依据。

一份实用的 Spec 模板可以这样组织：

# 功能名称：用户导出 Excel ## 背景 运营后台需要支持按筛选条件导出用户列表，数据量最大 10 万条。 ## 输入 - auth_token：登录凭证 - filters：筛选条件对象 - status: 用户状态 - created_after: 注册起始时间 - created_before: 注册结束时间 ## 输出 - 生成 Excel 文件地址，支持异步下载 - 文件包含字段：id, nickname, phone, status, created_at ## 约束 - 导出任务使用异步队列，防止请求超时 - 手机号需要脱敏 - 单次导出最大 10 万条，超出则分页读取 ## 验收标准 1. 筛选条件正确映射到 SQL WHERE 2. 10 万条数据导出不超过 2 分钟 3. 手机号导出后为脱敏格式 4. 导出完成生成下载链接，链接有效期 30 分钟 ## 异常处理 - 文件生成失败：记录日志并返回失败状态 - 数据源超时：重试 2 次，仍失败则结束任务

把这样的文档交给 AI Agent，比直接说“帮我写一个用户导出功能”要可靠得多。关键区别在于：验收标准变成了可执行的检查项，AI 生成代码后，可以对照标准逐项验证。

4.2 Coding Plan：让 Agent 按计划工作

Coding Plan 是任务拆解的工程化实现。复杂任务直接交给 Agent 容易失控，先让 Agent 生成一份分步计划，再按步骤执行，每一步都校验结果，是更稳妥的方式。

可以要求 Agent 在动手前先输出 JSON 格式的任务计划：

{ "task": "实现用户导出 Excel 功能", "steps": [ { "name": "定义导出任务数据模型", "files": ["src/export/models.py"], "output": "导出任务表结构定义" }, { "name": "实现 Excel 生成服务", "files": ["src/export/service.py"], "output": "可复用的导出服务类" }, { "name": "实现异步任务队列", "files": ["src/export/tasks.py"], "output": "Celery 异步任务" }, { "name": "编写接口和权限校验", "files": ["src/export/api.py"], "output": "REST 接口" }, { "name": "补充单元测试", "files": ["tests/test_export.py"], "output": "测试用例覆盖验收标准" } ] }

以“先计划、后编码、再验证”的方式工作，Agent 出现方向性错误的概率会明显下降，工程负责人也更容易在计划阶段介入纠正。

4.3 Loop Engineering：用反馈循环收敛质量

Loop Engineering 关注的是让 Agent 在“执行 → 验证 → 失败反馈 → 修正”的循环里工作。传统的单次生成是 open loop，一旦结果不合格，人工要重新写提示词，效率很低。做得好的团队会把闭环做成系统能力：

# 伪代码：Agent 验证闭环示例 def run_agent_loop(spec, max_iterations=3): plan = agent.plan(spec) for iteration in range(max_iterations): code = agent.implement(plan) test_results = run_tests(code) if test_results.is_pass(): return code feedback = summarize_failures(test_results) plan = agent.revise(plan, feedback) raise LoopExceededError("max iterations exceeded")

这里的关键是验证步骤必须可靠。如果测试覆盖不足，Loop 再多次也是在原地打转。所以 Loop Engineering 先要建设好的测试基线和静态检查工具链。

4.4 Context Engineering：把项目知识变成 Agent 的输入

为 Agent 提供上下文的方式，很大程度上决定了输出质量。较成熟的实践是：在仓库根目录维护一份 AI 指引文件，内容包含项目结构、技术栈、命令、约定和常见陷阱。

一个大纲示例：

# 项目项目 AI 操作指引 ## 技术栈 - Python 3.11 + FastAPI - PostgreSQL 15 + SQLAlchemy 2.0 - Redis + Celery 异步任务 ## 目录结构 - src/api 接口层 - src/services 业务服务层 - src/models ORM模型 - src/tasks 异步任务 - tests 单元测试与集成测试 ## 常用命令 - 启动测试：pytest tests/ -x - 启动服务：uvicorn src.main:app --reload - 代码检查：ruff check src/ ## 约定 - 所有数据库操作必须在 service 层完成 - API 入参校验使用 Pydantic - 手机号等敏感字段输出前必须脱敏 - 新增依赖需要先经过评审 ## 常见陷阱 - 不要在 API 层直接操作数据库 - 批量更新必须使用事务 - 连接 Redis 必须显式关闭连接

Agent 在开始任务前读取这份文件，比每次从零描述上下文要高效得多，也更容易在团队内统一规范。

5. 把 AI Engineering 落到团队流程

5.1 先做最小可行实验

团队引入 AI 辅助研发，不建议一上来就让所有 Agent 全权接管所有任务。更稳妥的路线是选择一条垂直业务链路做试点，比如“从需求到接口实现”这条线。

推荐试点条件：

业务边界清晰，不需要太多跨团队沟通；
已有可运行的测试基线；
团队成员具备 AI 工具使用经验；
产研双方能在规格阶段达成一致。

试点目标不是“AI 替代人”，而是验证“人负责定义和评审，AI 负责生成和迭代”的协作模式是否可行。试点期间重点关注缺陷率、返工率、交付周期和团队体验。

5.2 建立人机协作的评审流程

AI 生成的代码必须进入人工评审，但评审方式要随之改变。传统评审是“逐行读代码”，在 AI 场景下更有效的方式是：

先评审 Spec 和任务拆解，确认目标正确；
再评审关键文件的核心逻辑，不需要逐行检查样板代码；
依赖自动化测试、静态检查、类型检查等门禁来兜底；
对 AI 不确定的代码位置做重点排查，例如数据一致性、事务边界、外部调用。

评审不再追求“看清每一行”，而是“确认错误不会漏到生产”。

5.3 提示词资产与规范沉淀

团队积累的提示词、Spec 模板、Agent 配置，都是重要的工程资产。建议建立统一存放目录，例如prompts/、specs/、agent_configs/，并纳入版本管理。

沉淀的内容包括：

常用的任务模板，如“新增接口”“修复 Bug”“补充测试”；
按团队技术栈优化的上下文指引；
处理典型问题的最佳提示词，如“分析测试失败原因并给出修复方案”；
各类任务的验收标准模板。

提示词资产越沉淀，后续新成员的上手成本越低，团队输出的一致性也越强。

5.4 用度量验证 AI 是否真的提效

没有度量就没有改进。建议团队试点前记录基线数据，试点后再对比指标。

关注的核心指标：

指标	说明	观察方式
需求到上线的周期	从需求确认到功能上线的总时长	对比试点前后周期
编码时间占比	纯编码时间占开发总时长的比例	试点后应明显下降
返工率	因需求理解错误导致的返工比例	应下降
测试覆盖率	新增代码的覆盖率变化	不能因为 AI 生成而下降
线上缺陷密度	每千行代码的缺陷数	需要环比观察
人工评审耗时	评审一次变更加载	可能先升后降

数字不一定要做得很重，但需要让团队看到哪些环节真正提速，哪些环节反而变慢了。

6. 常见误区与踩坑排查

问题现象	可能原因	排查方式	解决思路
AI 生成代码和现有系统风格不一致	上下文缺少编码规范	检查 AGENTS.md 是否覆盖	补充项目约定到上下文
Agent 改 A 文件导致 B 文件报错	多文件依赖判断不足	查看 Agent 计划是否覆盖全部调用链	拆解任务时显式列出影响范围
测试总是失败但人工看不出问题	测试生成是基于现有代码，不是基于 Spec	检查测试断言是否覆盖验收标准	从 Spec 推导测试用例，而不是让 AI 自写自测
任务执行后期 Agent 开始产生幻觉	上下文窗口被无关内容占满	检查对话历史长度	及时清理历史，重新打包关键上下文
提示词微调后结果差异很大	模型温度或版本变化	对比多次输出	固定模型参数，建立评测样例
工程团队效率没有提升	只有编码环节提速，其他环节未自动化	分析各环节耗时占比	扩展 AI 到变更文档、测试生成、评审辅助
全局扩散：Agent 改了很多不该改的文件	缺少变更范围约束	检查 Agent 的 diff	明确文件白名单和黑名单
线上出现 AI 代码导致的隐蔽 Bug	验证链路不完整	回顾测试覆盖和评审记录	增加集成测试和边界用例

7. 做好 AI 软件工程的关键原则

7.1 先定义可验证的规格，再让 AI 动手

AI 生成代码的能力越强，规格定义的重要性越高。不要把模糊的需求直接扔给 Agent。花时间写清楚输入、输出、约束和验收标准，收益会体现在返工次数上。

7.2 让验证成为闭环的一部分

AI 生成的代码，必须经过可靠验证才能合入。这个验证包括：类型检查、静态分析、单元测试、集成测试、人工评审。验证越自动化，AI 的速度优势越能在安全边界内发挥。

7.3 人仍然承担最终责任

AI 可以生成代码、分析日志、提出修复方案，但最终对系统负责的是人。关键决策点，比如架构选型、数据迁移、权限模型、对外协议，必须保留人工确认。这里的核心不是“信不信任 AI”，而是“谁能对后果负责”。

7.4 以图形化方式管理复杂依赖

当 Agent 多文件、多任务协同工作，Graph Engineering 的价值会显现：把代码文件、模块依赖、任务依赖建模成图结构，在任务执行前做影响范围分析，能明显减少“改了一处，坏了一片”的问题。

7.5 保持可观测性和可回滚性

任何 AI 自动生成和自动修改的能力，都建议套上“可观测、可回滚”的壳。Agent 每次修改生成完整 diff，记录执行日志，支持一键回滚到修改前版本，可以减少试错成本。

8. 总结与下一步

AI Coding 提速之后，工程团队的注意力应该从“谁能更快生成代码”转向“怎样让整条交付链路同步提速”。从当前实践看，最值得先做三件事：

第一，建立 Spec 驱动的需求拆解习惯。把模糊想法变成结构化任务描述，这比优化提示词带来的收益更大。第二，建设自动化验证闭环，包括测试、静态检查、类型检查，形成对 AI 输出的质量门禁。第三，在团队内沉淀提示词资产和 Agent 配置，让上下文管理从个人技巧变成团队规范。

最容易踩的坑是：看到 AI 生成代码变快了，就放开 Agent 权限，跳过规格和验证，结果代码量快速膨胀、缺陷率同步上升。更稳妥的节奏是：先选一条业务链路试点，小步验证“AI 生成 + 人工评审 + 自动验证”的协作模型，跑通后再逐步扩大范围。

后续可以继续关注的方向包括：多 Agent 协同的图结构编排、面向 Agent 的评测集建设、以及上下文工程在大型代码库里的规模化应用。工具会持续迭代，但“由人定义目标、由 AI 提速执行、由验证保障质量”的工程框架，大概率会稳定下来。现在开始搭这套框架，正好赶上 AI 研发基础设施的下一个阶段。

AI Coding提速后，软件工程瓶颈与Harness Engineering实践