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 Engineering3.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_iterations3): 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 研发基础设施的下一个阶段。