开启Harness Engineering探索之旅¶
Ch05.081 开启Harness Engineering探索之旅¶
📊 Level ⭐⭐ | 7.6KB |
entities/harness-engineering-exploration-journey-tencent.md原文归档：原文归档
腾讯技术工程团队的Harness Engineering探索实践，分享如何在生产环境中系统化地应用AI编码技术，提升工程团队的代码质量和开发效率。
一句话¶
腾讯技术工程团队的Harness Engineering实践探索，从理论到生产落地的完整路径。
核心内容¶
Harness Engineering理解¶
Harness Engineering是一套用于规范和优化AI代码生成过程的工程方法论，核心目标是让AI在生产环境中更可靠、更可控。
实践要点¶
- 规范设计：明确什么场景适合AI编码，什么场景需要人工干预
- 过程控制：建立从需求理解到代码验证的完整流程
- 质量保障：设置多层次的代码评审和测试机制
- 持续迭代：基于反馈不断优化Harness规则
生产落地¶
文章分享了腾讯内部多个团队应用Harness Engineering的实际案例，包括：
- 前后端开发场景的Harness实践
- 测试和运维阶段的AI协助
- 团队协作中的规范落地
深度分析¶
1. "出码率与提效之间的裂缝"——Harness Engineering 的根本动机¶
团队的数据揭示了一个反直觉的现象：AI 产出代码占比持续走高，但版本节奏的提升远不如数字好看。分析根因有三：研发从来不是"写代码"这一个环节（Brooks 的本质复杂度一分没少）、局部加速只会让瓶颈转移（从"写"移到"审/测/维"）、AI 看不见工程体系中的隐性约束。这一洞察将 Harness Engineering 的价值从"提升出码率"重新定义为"打通从出码到提效之间的被卡住的环节"——瓶颈不在编码，而在理解、对齐、追溯、沉淀、验证这些非编码工作。
2. 2 轨道 + 1 记忆的整体架构设计¶
Tencent 的 Harness 实践采用了清晰的两轨架构：轨道 1（研发端到端交付） 覆盖 P1 需求 → P6 归档的标准化 6+1 阶段管线；轨道 2（线上运营） 覆盖告警触发 → 归档的 7 步闭环。两条轨道共用同一套知识库（项目级 specs/ + 变更级 knowledge-spec/），构成 AI 的长期记忆。两轨共享知识库、同一套 trace-id 检索 SOP、同一套评分门槛，是 Harness 在"主动驱动"和"被动驱动"两种输入入口上的对偶设计。
3. P1-P6 管线：从协议到纪律的完整工程化¶
管线层的核心创新在于三层设计：协议层规定 AI 每步输入输出必须满足的结构化格式（需求 → GIVEN-WHEN-THEN、设计 → 契约 + Mermaid 图、改动点 → D-x 列表）；管线层标准化 6+1 阶段工序（P0 brainstorming → P1 需求 → P2 设计 → P3 实现 → P4 测试 → P5 部署 → P6 归档），每阶段有明确输入输出和阶段间接力机制；纪律层将五道防线（TDD / Debugging / Verification / Review / Evaluate）硬编码为管线门禁，评分 ≥ 95 才允许进入下一阶段。其中 P6 归档的 delta-spec 机制（四类标记增量合并）是知识复利的关键，确保每个变更的知识不流失、不膨胀。
4. 可监测性三层：可追踪、可回溯、可度量¶
团队将可监测性拆为三个维度对应三个信任问题：可追踪让 AI 的每一步留下机器可读的证据（.phase-metrics.jsonl + evaluation.md + Report API）；可回溯让失败能从结果自动收敛到根因（按 UI 偏差/API 测试失败/跨阶段重试等类型配不同 SOP）；可度量让效果和成本被量化（Token/成本、耗时、重试/失败率、代码改动量四类指标）。核心纪律是：SOP 写死，不让 Agent 自由发挥——把人工排查的隐性经验显式化为 Agent 的检索路径。
5. 典型问题的工程方法论提炼¶
团队将反复踩到的问题归纳为 4 个典型模式并形成标准化应对：AI 指令遵循（TODO 文件驱动 + SubAgent 拆解 + 渐进式披露）、需求歧义（多轮澄清 + GIVEN-WHEN-THEN 结构化）、设计稿还原（插入中间结构层 A → C → B）、产物可靠性（自验证循环 + UTDD + 审查 Agent）。每条都给出了问题→原因→解决方案→工程判断的完整逻辑链，其中最核心的工程判断是：AI Coding 的工程化，本质是对"不确定性"的系统治理——模型概率性、注意力衰减、上下文压缩是 LLM 的物理常数，无法消除，只能在周围搭一套确定性的骨架兜住。
实践启示¶
-
不要在"写"这一格追求极致，瓶颈不在这里：当 AI 把编码成本压到接近零，真正的瓶颈显形在理解、对齐、追溯、沉淀、验证。Harness 的投入分配应该反映这一点——80% 的工程精力放在"非编码环节"，而非继续优化代码生成速度。
-
协议层先行——没有契约就没有评估基准：AI 每一步的输入输出都必须有结构化格式约束。需求用 GIVEN-WHEN-THEN，设计用 Mermaid + 表格契约，改动点用 D-x 列表。格式确定的产出物才是可评估、可回溯的。
-
纪律层必须硬编码，不能靠 AI 自觉：AI 会跳过测试、猜想修复、谎称完成、给自己打高分——这些不是偶发行为，是天然倾向。五道防线的每一道都必须硬编码为门禁（评分 < 95 打回），不允许"建议遵守"。
-
SubAgent 上下文是独立计费的：这是一个反直觉的成本陷阱——把负担甩给 SubAgent 看似节省了主上下文，实际另起了一份成本。所有 SubAgent 应优先读 git diff + 关键片段，避免读全文件。token 双层结算是上线前必须做的核算。
-
知识库的"进出通道"必须同时设计：P6 归档用 delta-spec 四类标记做增量合并，解决了"怎么进"；但"怎么出"（知识老化淘汰）目前还没有成熟机制。早期建设时就应规划这两条通道，避免知识库膨胀成新债务。