AI Coding 已经不是什么新鲜事了。
现在，借助 Cursor、Claude Code、Codex 等工具，开发者可以让 AI 理解代码、生成接口、编写测试，甚至独立完成一部分开发任务。
但在真实的软件研发项目中，一个很现实的问题逐渐暴露出来：
AI 能把代码写出来，不代表它能把需求正确实现，更不代表这段代码可以直接交付。
一个企业级项目可能有几十个业务模块、复杂的调用关系、历史遗留代码、安全规范和团队约定。AI 如果不了解这些信息，即使生成的代码语法正确，也可能违反项目规范，破坏原有业务逻辑，甚至引入新的 Bug。
开发者不得不反复给 AI 补充项目背景、解释业务规则、检查代码修改、补充测试用例。
个人使用 AI Coding，可能已经很高效了。但当一个团队几十个人、上百个人同时使用 AI 时，如何保证 AI 的工作方式、代码质量和交付标准相对一致？
最近，滴滴金融技术团队开源了一个项目：HelixHarness。
它关注的正是 AI Coding 从个人效率工具走向团队工程化交付时遇到的问题。
项目地址：https://github.com/didi/helixharness
一、AI Coding 最大的问题，已经不只是代码生成
我们先看一个实际场景。
假设现在有一个电商系统，需要新增一个订单退款功能。
开发人员把需求交给 Coding Agent，AI 很快就能生成退款接口、业务逻辑和相关代码。
但真正进入企业项目后，事情没有这么简单。
AI 可能不知道：
当前项目采用什么技术架构，退款逻辑应该放在哪个业务模块？
订单、支付、退款之间有哪些历史业务约束？
团队对异常处理、日志、事务和接口规范有什么要求？
退款金额是否允许超过原支付金额？
重复提交退款请求应该如何处理？
相关接口需要覆盖哪些异常测试场景？
这些信息如果没有提前提供给 AI，它就只能根据当前上下文和代码推测。
最终可能出现一种情况：代码生成得很快，开发人员却花了大量时间检查、修改和返工。
这也是 AI Coding 在企业研发中需要解决的几个问题：
- 工程上下文不足
AI 不了解项目完整的业务知识、技术架构和研发规范，每次执行任务都需要开发者补充背景。
- 研发过程缺少统一管理
不同开发者使用 AI 的方式不同，有人让 AI 直接写代码，有人先做方案设计，有人会让 AI 自动执行测试。团队很难形成统一的研发流程。
- 开发过程缺乏可观测性
AI 调用了哪些工具、修改了哪些文件、经历了几次返工、为什么执行失败，这些过程数据如果没有记录，就很难分析研发效率和问题根因。
- AI 能力升级缺乏评测
修改一条规则、增加一个 Skill，究竟有没有让 AI 的表现变好？会不会在其他场景中引入问题？如果没有统一的评测机制，就很难判断。
这些问题共同指向一个方向：
AI Coding 需要从单纯的代码生成，进一步走向工程化管理。
二、HelixHarness 是什么？为什么需要 Harness？
先解释一个概念：Harness。
在 AI Agent 工程中，Harness 可以理解为围绕 Agent 构建的一套运行和管理机制。
大模型负责理解和推理，Coding Agent 负责组织任务、调用工具和执行操作，而 Harness 则为 Agent 提供必要的工程上下文、执行规则、工作流程和质量约束。
可以简单理解为：
LLM： 提供理解、推理和代码生成能力。
Coding Agent： 负责理解任务、规划步骤、调用工具。
Harness： 负责提供项目知识、执行规范、流程约束和验证机制。
三者不是相互替代的关系，而是不同层次的能力组合。
滴滴开源的 HelixHarness，正是在现有 Coding Agent 的基础上，进一步构建面向团队的 AI Coding 工程化基础设施。
它最初来自滴滴金融技术团队内部的 OpenHarness 项目。
根据项目介绍，该框架已经在滴滴内部推广至 10 余个部门和团队，累计应用于上百个业务模块。
它的核心目标不是重新开发一个 Coding Agent，而是让现有 Coding Agent 更好地理解企业项目，并按照团队的工程规范完成研发任务。
三、HelixHarness 的核心设计：四层工程上下文
这是整个项目比较值得关注的设计。
在实际研发中，项目知识往往分散在代码仓库、技术文档、接口定义、历史设计方案和开发人员经验中。
如果每次使用 AI 都需要重新解释这些内容，效率很难真正提升。
HelixHarness 将工程上下文拆分为四个部分：
Knowledge、Harness、Specs、Hooks 四层工程上下文
- Knowledge：项目知识
主要用于沉淀项目相关的知识，包括业务逻辑、系统架构、模块职责和技术文档等。
让 AI 在执行任务之前，能够获取必要的项目背景，而不是只根据当前对话猜测业务逻辑。
- Harness：工程约束
用于组织工程规范和相关索引，让 AI 在代码开发过程中遵循团队约定。
例如代码规范、架构约束、开发约定等。
- Specs：需求与交付契约
用于管理需求规格、任务信息以及验证相关的交付工件。
它的价值在于让 AI 不只是接收一句自然语言需求，而是围绕明确的任务目标开展工作。
- Hooks：自动化检查规则
用于组织检查规则，在研发执行过程中对相关行为和结果进行约束与检查。
这部分和软件测试人员的工作也有直接联系。
例如代码规范检查、特定规则校验以及自动化验证等，都可以通过工程化检查机制融入研发流程。
四层上下文不是简单地把文档放进项目目录，而是希望让知识、规则、需求和检查机制真正参与 AI Coding 的执行过程。
四、从需求到交付：HelixHarness 如何组织研发工作流？
如果只有项目知识，AI 仍然可能出现执行过程混乱的问题。
例如开发人员给 AI 一个需求，它可能直接开始修改代码，中间没有充分分析影响范围，也没有明确的实施方案。
HelixHarness 将日常研发过程抽象为标准化命令和工作流。
整体可以理解为四个主要阶段：
初始化、方案设计、执行开发和归档沉淀
第一阶段：项目初始化
建立项目上下文，让 Coding Agent 获取必要的工程知识和研发约束。
第二阶段：方案设计
先理解需求，分析涉及的业务模块、技术方案和潜在影响，形成相应的需求规格与任务信息。
第三阶段：执行开发
按照既定方案执行代码修改，在工程规范和检查规则的约束下完成开发任务。
第四阶段：验证与归档
对研发结果进行验证，将相关任务信息、需求规格和交付工件沉淀下来，为后续维护和知识复用提供基础。
这套流程的意义在于：把原本依赖开发者个人经验的 AI 使用方式，逐渐转变成团队可以复用的工程化工作流程。
对于测试开发人员而言，这里面有一个值得关注的变化：
测试验证不应该只发生在开发完成之后，而应该成为 AI Coding 工作流中的一部分。
例如新增一个订单退款功能，除了生成业务代码，还应该考虑：
正常退款流程是否正确？
重复退款是否会产生数据问题？
退款金额边界是否经过验证？
支付服务异常时如何处理？
数据库事务失败后是否能够正确回滚？
原有订单查询、支付和退款功能是否受到影响？
如果这些验证要求能够提前沉淀到项目知识、需求规格和自动化检查机制中，AI 就有机会在研发过程中更早地发现问题。
当然，具体测试能力仍然取决于团队配置的测试工具、检查规则和验证流程，并不是接入 Harness 就自动拥有完整的测试体系。
五、可观测、可评测：让 Harness 自己也能持续进化
这是 HelixHarness 另一个值得关注的设计方向。
很多团队在使用 AI Coding 时，都会持续调整提示词、Rules、Skills 和工作流。
例如：
增加一条代码规范，减少 AI 生成不符合团队要求的代码。
增加一个 Skill，让 AI 更好地完成某类开发任务。
调整工作流，让 AI 在修改代码之前先分析影响范围。
但有一个问题：
修改之后，效果真的变好了吗？
例如新增了一条 Rule，虽然减少了某类代码问题，却可能让 AI 执行任务的步骤变多，导致整体效率下降。
新增一个 Skill，可能在某个项目中效果很好，换到另一个项目却未必适用。
如果只凭开发人员的主观感受，很难准确判断这些调整是否有效。
HelixHarness 提出的思路是建立一套持续评测和优化机制：
整体过程可以概括为：
可观测： 记录研发执行过程中的相关数据，分析工具调用、代码修改和返工情况。
形成假设： 根据执行数据和实际问题，判断当前规则、知识或工作流存在哪些不足。
候选修改： 调整 Rules、Skills、Knowledge 或 Workflow。
统一评测： 使用相对统一的任务和评测标准，对修改前后的表现进行比较。
受控采纳： 验证有效后再将调整纳入正式框架。
持续迭代： 根据新的研发数据继续优化。
这套思路和软件测试中的回归测试有一定相似之处。
我们修改了一个功能，不能只验证新功能是否正常，还需要确认原有功能有没有受到影响。
同样，Harness 发生变化，也需要通过评测验证它是否真正提升了 AI 的工程表现。
AI 自己可以参与优化，但优化结果不能只由 AI 自己说了算。
需要有相对客观的评测任务、验证标准和结果数据。
六、HelixHarness 对软件测试意味着什么？
过去，我们更多关注 AI 能不能生成测试用例、能不能生成自动化脚本、能不能帮助定位 Bug。
现在，企业开始进一步关注：
AI 是否理解真实业务和项目架构？
AI 生成的代码是否符合工程规范？
AI 修改代码后能否自动执行相关测试？
AI 的执行过程是否可追溯？
AI 的能力升级是否有客观评测依据？
不同研发团队能否复用一套工程化能力？
这些问题已经不只是代码生成问题，而是研发质量保障问题。
对测试开发工程师而言，我认为未来有几个方向值得提前关注。
第一，测试人员需要参与 AI Coding 的质量约束设计。
测试不应该只在开发完成后接收代码、执行用例。需求分析阶段就可以参与定义验收条件、异常场景、边界条件和质量标准。
第二，自动化测试需要进一步融入 Agent 工作流。
测试用例、自动化执行、失败诊断、回归验证，都有机会成为 Coding Agent 工作流中的组成部分。
第三，AI 测评会成为新的技术能力。
不仅要测试软件产品，也要评估 AI Agent 本身的表现。
例如任务完成率、代码正确性、测试通过率、工具调用效率、异常恢复能力，以及不同规则调整前后的效果。
这些都可能成为 AI 研发体系中的重要评估指标。
七、写在最后
从代码补全，到 AI Coding，再到 Harness 工程化，AI 参与软件研发的方式正在发生变化。
过去，我们关注的是 AI 能不能帮助开发者更快地写代码。
现在，企业更加关心的是：AI 能不能理解项目、遵循规范、完成验证，并且持续稳定地交付。
滴滴开源 HelixHarness，提供了一种面向团队的工程化实践思路。
它不是一个新的大模型，也不是用来替代 Cursor、Claude Code 或 Codex 的编程工具，而是在现有 Coding Agent 之上，组织工程知识、研发规范、任务工作流和评测机制。
当然，Harness 也不是解决 AI Coding 所有问题的万能方案。工程知识是否完整、规则是否合理、测试体系是否健全，都会影响最终效果。
但有一点已经越来越明确：
AI Coding 的竞争，正在从模型和代码生成能力，延伸到工程体系、质量保障和持续交付能力。
对于软件测试从业者而言，这同样意味着新的技术机会。
未来不仅要懂自动化测试，还需要理解 Agent、Harness、Skills、MCP、RAG 和 AI 评测体系，逐步参与 AI 研发流程中的质量保障工作。
项目地址：https://github.com/didi/helixharness
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
