Harness 基建：把可交付性从 40~60 分提到 80 分
2026/6/25大约 6 分钟
为什么 AI 项目总是 40~60 分？
为什么很难做到 80 分？
如何系统化提升 AI 项目的可交付性？
Harness 基建的答案：
上下文工程 + 架构约束 + 团队知识 Memory + 技术债梳理。
问题：AI 项目的可交付性陷阱
当前 AI 项目的一个残酷现实：
大多数项目的可交付性只有 40~60 分，很难突破到 80 分。
┌─────────────────────────────────────────────────────────┐
│ AI 项目可交付性分布 │
├─────────────────────────────────────────────────────────┤
│ │
│ 可交付性分数分布： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 0─────20─────40─────60─────80─────100 │ │
│ │ ████ ████████████ │ │
│ │ 10-30分 40-60分 80-100分 │ │
│ │ (失败) (常见) (罕见) │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 现状： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 40-60 分：大多数 AI 项目在这里 │ │
│ │ · 80 分以上：凤毛麟角 │ │
│ │ · 能用，但不稳定 │ │
│ │ · 能交付，但维护困难 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘为什么是 40~60 分？
40~60 分的特征
40~60 分的 AI 项目通常有这样的特征：
- 功能层面（60 分）：核心功能能用，基本场景能跑通，但边缘情况处理不好，异常处理缺失
- 质量层面（50 分）：基本功能正确，但代码质量参差不齐，测试覆盖不足，文档缺失
- 维护层面（40 分）：代码难以理解，修改容易引入 bug，依赖关系混乱，技术债累积
- 交付层面（50 分）：能勉强交付，但交付后问题频发，客户满意度低，维护成本高
为什么很难突破 60 分？
大多数 AI 项目卡在 40~60 分的原因：
- 缺乏系统性基建 — 没有系统的上下文管理、架构约束、知识沉淀、技术债管理"
- 过度依赖"人肉" — 靠开发者的记忆和经验、靠口口相传的知识、靠临场发挥的决策
- AI 的不确定性 — AI 输出不稳定，代码质量参差不齐，需要大量人工干预
- 技术债累积 — 为了赶进度牺牲质量，没有时间重构，技术债越来越多
解决方案：Harness 基建
Harness 基建的核心思想：
通过系统性基建，把 AI 项目的可交付性从 40~60 分提升到 80 分。
┌─────────────────────────────────────────────────────────┐
│ Harness 基建的四大支柱 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 上下文工程 │ │ 架构约束 │ │ │
│ │ │ │ │ │ │ │
│ │ │ · 需求理解 │ │ · 代码规范 │ │ │
│ │ │ · 任务分解 │ │ · 架构模式 │ │ │
│ │ │ · 状态管理 │ │ · 安全标准 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 团队知识 │ │ 技术债梳理 │ │ │
│ │ │ Memory │ │ │ │ │
│ │ │ │ │ · 债务识别 │ │ │
│ │ │ · 最佳实践 │ │ · 优先级排序│ │ │
│ │ │ · 经验沉淀 │ │ · 还款计划 │ │ │
│ │ │ · 知识共享 │ │ · 持续优化 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 目标：40~60 分 → 80 分 │
│ │
└─────────────────────────────────────────────────────────┘支柱一：上下文工程
上下文工程是对 AI 输入的系统性管理。
核心内容
- 需求理解 — 用户需求是什么？业务目标是什么？成功标准是什么？
- 任务分解 — 大任务拆分成小任务，每个任务的目标是什么？任务之间的依赖关系？
- 状态管理 — 当前进行到哪一步？已经完成了什么？下一步要做什么？
- 上下文传递 — 如何在任务之间传递信息？如何保持上下文的一致性？如何避免信息丢失？
价值
- 提高需求理解准确度 — 详细的上下文让 AI 生成符合预期的内容
- 提高任务执行效率 — 大任务分解成小任务，逐个完成，每个小任务都有明确的上下文
- 提高协作效率 — 上下文信息自动传递，减少重复沟通
支柱二：架构约束
架构约束是对 AI 输出的系统性规范。
核心内容
- 代码规范 — 命名规范、文件结构、注释规范、格式标准
- 架构模式 — 分层架构、模块化设计、依赖注入、单一职责
- 安全标准 — 输入验证、权限控制、敏感数据处理、依赖安全
- 性能标准 — 响应时间、并发处理、资源使用、缓存策略
价值
- 保证代码质量 — AI 生成的代码符合规范，可以直接使用
- 保证安全性 — AI 必须遵守安全标准，减少安全风险
- 保证可维护性 — 代码结构清晰，易于理解和维护
支柱三：团队知识 Memory
团队知识 Memory 是对团队经验和知识的系统性沉淀。
核心内容
- 最佳实践 — 什么做法效果好？什么做法效果不好？为什么效果好？
- 经验沉淀 — 遇到过什么问题？如何解决的？有什么教训？
- 知识共享 — 技术文档、解决方案、代码示例
- 持续学习 — 新技术学习、新方法实践、持续改进
价值
- 避免重复踩坑 — 记录了已知的坑和解决方案，避免重复踩坑
- 加速新成员上手 — 新成员可以快速查阅文档和经验
- 持续改进 — 经验持续积累和沉淀
支柱四：技术债梳理
技术债梳理是对项目技术债的系统性管理。
核心内容
- 债务识别 — 哪些地方有技术债？技术债的严重程度？技术债的影响范围？
- 优先级排序 — 哪些技术债需要优先处理？哪些可以暂时搁置？处理的顺序是什么？
- 还款计划 — 如何处理技术债？需要多少时间？需要多少资源？
- 持续优化 — 如何避免新的技术债？如何持续改进代码质量？如何建立预防机制？
价值
- 提高代码质量 — 定期处理技术债，保持代码质量
- 提高开发效率 — 减少技术债的影响，提高开发效率
- 降低风险 — 及时处理高风险技术债，降低项目风险
从 40~60 分到 80 分
Harness 基建的四大支柱如何协同工作，提升可交付性？
提升路径
起点：40-60 分
- 核心功能能用
- 基本场景能跑通
- 代码质量参差不齐
- 维护困难
第一步：引入上下文工程（+10 分）
- 需求理解准确度提升
- 任务执行效率提升
- 协作效率提升
第二步：引入架构约束（+10 分）
- 代码质量提升
- 安全性提升
- 可维护性提升
第三步：引入团队知识 Memory（+10 分）
- 避免重复踩坑
- 新成员上手加速
- 持续改进
第四步：引入技术债梳理（+10 分）
- 代码质量持续保持
- 开发效率持续提升
- 项目风险持续降低
最终：80 分
- 功能完善
- 质量优秀
- 易于维护
- 交付顺利
收尾金句
- 为什么 AI 项目总是 40~60 分？因为缺乏系统性基建
- Harness 基建：把可交付性从 40~60 分提到 80 分
- 四大支柱：上下文工程 + 架构约束 + 团队知识 Memory + 技术债梳理
- 上下文工程：提高需求理解准确度、任务执行效率、协作效率
- 架构约束：保证代码质量、安全性、可维护性
- 团队知识 Memory：避免重复踩坑、加速新成员上手、持续改进
- 技术债梳理：提高代码质量、开发效率、降低风险
- 从 40~60 分到 80 分，系统性基建是关键
- 不要只关注 AI 能做什么，要关注如何让 AI 持续产生高质量输出
Harness 基建：把可交付性从 40~60 分提到 80 分
系统性基建，让 AI 项目持续产生高质量输出