← → 翻页 · B 静态 · ESC 索引
VOL.01OPENING
HARNESS ENGINEERING
45 MIN TALK

从 Prompt
到 Harness

AI Coding 如何放大研发交付能力

商品理解 1600万用户理解 3亿+2.3万行代码
Harness Engineering
Harness Engineering01 / 18
VOL.01BACKGROUND
HARNESS ENGINEERING
BACKGROUND

两条生产级链路，两个核心变化

商品理解

商品素材(标题/图片/OCR/CPV) → 结构化属性 → 准出评测

支撑 1600 万商品刷数，准召 93%+ / 85%+

用户理解

多源行为 → 兴趣画像推理 → SPU 圈选

覆盖 3亿+ 低U用户，实验结果正向

变化一：研发链路被缩短

从需求理解到文档沉淀的完整过程加速，周期减少 2-3 倍

变化二：能力边界被拓宽

个人拉通模型/数据/工程/评测，团队经验沉淀为可复用资产

Harness Engineering02 / 18
VOL.01DATA
HARNESS ENGINEERING

三周实战数据

AI 对话
5585轮

65 个对话

原始 Token
14.67亿

消耗量

计费 Token
2.8亿

实际计费

代码产出
2.3万行

生成与修改

工具成本
4万元

总投入

2 天

出汇报 Demo

2 周

迭代两版 + 60 万爆品刷数

3 周

1000万+ 动销品刷数，交付下游使用

Harness Engineering03 / 18
VOL.01CONCEPT
HARNESS ENGINEERING
PART 01 - CONCEPT

AI Coding 的三个阶段

01
Prompt
怎么问
02
Context
看什么
03
Harness
如何稳定交付

Prompt 让 AI 回答更好，Context 让 AI 理解更准，Harness 让 AI 交付更稳。

从 Prompt 到 Context 再到 Harness
Harness Engineering04 / 18
VOL.01DEFINITION
HARNESS ENGINEERING

Harness Engineering 的定义

让 AI 在一个有上下文入口、有阶段约束、有验证门禁、有经验回写的工程现场里工作。
01
上下文入口

先知道系统是什么

02
阶段约束

按节奏推进

03
验证门禁

产出能被验收

04
经验回写

沉淀回事实源

Harness 的四个组件
Harness Engineering05 / 18
VOL.01PROBLEM
HARNESS ENGINEERING
PART 02 - WHY HARNESS

裸用 AI 的四种失控

一步到位

一轮改太多，隐含约束被破坏

提前宣布完成

没跑脚本没贴日志就说"已修复"

语法对，语义错

代码干净但工程后果不对

不理解生产风险

删表清队列不能靠"请谨慎"

裸用 AI 的四种失控
Harness Engineering06 / 18
VOL.01PROBLEM
HARNESS ENGINEERING
失败模式与 Harness 解法

每种失控都有对应约束

一步到位 → 结构化执行：分阶段推进
提前完成 → 质量门禁：证据而非口头
语义错误 → 上下文 + Skill：理解为什么不能这么写
风险盲区 → 门禁 + dry-run：权限和人工确认
Harness Engineering07 / 18
VOL.01METHOD
HARNESS ENGINEERING
PART 03 - METHOD

个体使用 AI 最关注三件事

01 - CONTEXT
上下文入口

先让 AI 知道系统是什么。不需要读完仓库，但必须知道核心链路、常见入口、历史约束。

价值不是让 AI 少读，而是从正确的地方开始读。

02 - EXECUTION
结构化执行

先理解再规划再执行。复杂项目最怕的不是写得慢，而是方向错了还写得很快。

不是把流程做重，而是加停顿点。

03 - QUALITY GATE
质量门禁

自然语言约束容易失效。可靠做法：命令是什么，预期输出是什么，失败率阈值是多少。

不能验证的约束，都是口头建议。

Harness Engineering08 / 18
VOL.01METHOD
HARNESS ENGINEERING

检查是工程能力

AI 可以执行检查，但检查思路要由人设计。

弱检查

"帮我看看有没有问题" → AI: 整体没问题。

强检查

带着假设验证：字段缺失？分布异常？边界样本？

多视角质量检查
Harness Engineering09 / 18
VOL.01TEAM
HARNESS ENGINEERING
PART 04 - TEAM ENVIRONMENT

共用开发机 + Repo as Truth

很多团队用 AI 不稳定，不是模型不行，而是研发现场太碎。

共用开发机：依赖/样本/命令/日志全部稳定可追踪
Repo as Truth：承载需求/方案/脚本/报告/badcase/Skill
经验回写：每次犯错追问根因，回写到 repo
碎片化协作与统一研发现场
Harness Engineering10 / 18
VOL.01TEAM
HARNESS ENGINEERING
Repo as Truth

不在环境里的知识，对 AI 等于不存在

需求在聊天记录里 → AI 看不到

测试命令在某人脑子里 → AI 不知道

评测结论在群聊截图里 → AI 无法复用

冷启动次数多了，提效就被消耗掉

Harness Engineering11 / 18
VOL.01TEAM
HARNESS ENGINEERING

研发闭环：每一步留下可追踪产物

01
需求分析
边界、不确定问题
02
技术方案
路径、风险、最小 spec
03
代码实现
代码、脚本、配置
04
测试执行
命令、日志、样本
05
结果反馈
指标、报告、badcase
06
持续优化
回写 Skill / 检查清单
好的 Harness 不是一次设计出来的，而是在每次失败后长出来的。每次 AI 犯错时追问：是上下文缺失？文档没写清楚？该写进 Skill？
Harness Engineering12 / 18
VOL.01PRACTICE
HARNESS ENGINEERING
PART 05 - PRACTICE

商品理解：从模型调用到数据生产链路

01
源数据
标题/图片/OCR/CPV
02
Prompt 构造
证据组织，控制噪声
03
批量推理
并发/QPM/TPM限流
04
结果落盘
JSON修复/续跑/Hive
05
准出评测
rule + LLM-as-judge

多源素材带噪声

长 RT 需并发限流

状态结果要对账

1600万放大小概率问题

Harness Engineering13 / 18
VOL.01PRACTICE
HARNESS ENGINEERING

用户理解：从多源行为到兴趣画像

01
多源行为
电商/搜索/内容/广告
02
统计加工
分桶转为行为证据
03
LLM 推理
兴趣画像与偏好
04
Embedding
匹配站内类目/SPU
05
圈选应用
人货匹配与策略

推荐特征是统计意义，不是 LLM 容易理解的语义 — 需先做证据组织

3亿+ 低U不能逐个推理 — 必须分桶分簇群体推理

复用商品理解沉淀的批处理、限流、评测思路

Harness Engineering14 / 18
VOL.01PRACTICE
HARNESS ENGINEERING

复利：第二个项目变值钱

PROJECT 1
花时间补齐工具链、把坑踩一遍

沉淀文档、脚本、Skill、检查清单

PROJECT 2+
复用的不是代码，是工程模式

任务拆解、错误处理、评测口径、对账思路、文档结构

Harness 的复利曲线
Harness Engineering15 / 18
VOL.01RESULT
HARNESS ENGINEERING
PART 06 - RESULT

研发提效 + 能力扩展

全链路效率提升

需求理解更快 → 方案拆解更快 → 工具链补齐更快 → 验证闭环更快 → 经验复用更快

能力边界拓宽

从单模块交付走向端到端 Pipeline，同时关注系统可靠性和质量准出

关键判断仍要人做

方案是否破坏幂等？指标能否证明问题解决？结果能否被业务信任？

AI 没有省掉研发流程，而是让研发流程更快被执行、更快被验证。

Harness Engineering16 / 18
VOL.01CLOSING
HARNESS ENGINEERING
CLOSING

把 AI 当成
可被约束的协作者

它可以读材料、拆任务、补脚本、跑检查、整理报告。
但它需要上下文、执行现场、质量门禁，也需要人做最终判断。

上下文执行现场质量门禁人做判断
Harness Engineering
Harness Engineering17 / 18
VOL.01TAKEAWAY
HARNESS ENGINEERING
TAKEAWAY

Prompt 让 AI 能回答问题
Context 让 AI 能理解项目
Harness 才是让 AI 进入生产工程的关键

Q&ADISCUSSIONREPO AS TRUTH
Harness Engineering18 / 18