很多人以为与 AI 沟通就是把问题描述清楚，然后等答案。但当 AI 从聊天机器人变成 Agent 之后，这套玩法就不够了。真正高效的沟通不是"说得更多"，而是定义好五件事：事实 → 目标 → 约束 → 完成 → 证据。

序言

AI 做错事之后，我的第一反应曾经是：是不是 Prompt 写得不够详细？于是不断往里加东西——"你要注意这个……另外还要考虑那个……还有一个特殊情况……"，最后变成一篇几千字的 Prompt。

问题是：信息多，不等于信息结构好。

后来想明白了：传统 Prompt Engineering 问的是"如何写一个更好的 Prompt"，而 Agent 时代真正要回答的问题是——如何设计一个让 AI 不容易犯错的工作环境。一个优秀 Prompt 只能解决一次任务，一个好的工作环境可以持续约束 Agent。

这套方法其实不新，里面的概念几乎全来自传统软件工程：Source of Truth、Definition of Done、Quality Gate……只不过在 AI Coding 时代被重新组合了一遍。下面按"事实 → 目标 → 约束 → 完成 → 证据"这条链展开。

一、先告诉 AI：什么是真实的

AI 最怕的不是问题难，而是不知道应该相信什么。过时文档、代码、聊天记录、自己的推理——信息一多就开始自行猜测。

解法很直接：给它一个 Single Source of Truth（SSOT）。开发一个项目时，可以明确告诉 AI：

Source of Truth 清单
══════════════════════════════════════════
项目规范      → AGENTS.md
API 定义      → OpenAPI
数据库结构    → Migration
当前行为      → 自动化测试结果
需求          → Specification

SSOT 解决的是一个非常基本的问题：多个信息互相冲突时，AI 应该相信谁？ 一个好的 AI 工作环境，首先要说清楚什么是事实、什么只是参考。

顺带一提，SSOT 不是 Scrum 专属概念，它广泛存在于软件工程、数据工程、DevOps、企业架构里——回答的都是"系统里存在多个版本的信息时，哪个才是权威版本"。

二、再告诉 AI：要达到什么状态

不要只说"帮我优化这个函数"，而要说：

"这个函数目前处理 100 万条数据需要 15 秒，希望降低到 5 秒以内，同时不能改变输出结果。"

区别在于：前者给的是一个任务，后者给的是一个目标状态。目标可以拆成四块——当前状态、目标状态、衡量指标、优先级，也就是 Current State → Target State。这样 AI 才知道自己是在"修改代码"，还是在"解决性能问题"。

三、约束：什么不能做

很多 AI 输出不符合预期，并不是它不知道怎么做，而是自由度太高。所以需要明确 Constraints：

• 不允许修改数据库结构
• 不允许增加第三方依赖
• 必须兼容 Go 1.24
• 不能改变 API，必须保持向后兼容
• 不能修改已有测试

这比单纯说"帮我重构"有效得多。一句话概括：

目标决定 AI 往哪里走，约束决定 AI 不能往哪里走。

这也是 Harness Engineering 的核心思想：不是让模型拥有无限自由，而是通过工程约束控制模型的行为空间。

四、提前定义：什么叫"完成"

这是最容易被忽略的一点。Definition of Done（DoD）不是 AI 时代的新概念，它来自 Scrum / Agile，用来明确什么条件满足时，工作才真正算完成。

拿一个接口优化任务举例：

• 单元测试全部通过，API 行为保持不变
• P95 延迟低于 100ms，Benchmark 达到目标
• 没有新增 lint error，没有数据一致性问题

DoD 的价值是把模糊的"做好它"，变成"满足这些条件才算做好"。对 Agent 来说尤其关键，因为 Agent 最大的问题之一是：它很容易自己决定什么时候停止。没有明确的 DoD，Agent 可能改了几行代码就告诉你"任务已完成"，而真正的工程问题根本没解决。

顺便区分几个经常混用的词，关注点其实不一样：

概念                    回答的问题                          例子
════════════════════════════════════════════════════════════════
Acceptance Criteria     这个需求必须满足什么？              密码错误返回 401
Definition of Done      工作做到什么程度才算完成？          测试通过、文档更新
Quality Gate            达到什么门槛才能继续往下走？        覆盖率不低于阈值
Evidence                凭什么证明前面的条件真的满足？      go test 通过、4.8s

串起来就是：Acceptance Criteria → DoD → Quality Gate → Evidence。这比一句"把这个需求做好"精确得多。

五、不要相信"我完成了"，要证据

Agent 时代尤其重要的一点：AI 说"已经修复了"，这句话本身没有多少价值。真正有价值的是：

"已修复。go test ./... 通过，新增测试 8 个，Benchmark 从 15.2s 降到 4.8s。"

所以我会要求 AI 输出：修改了什么、为什么修改、执行了什么验证、验证结果是什么、哪些没验证、有没有遗留风险。也就是从"我认为完成了"变成 "这是完成的证据"——Claim → Evidence。

这些概念都不是 AI 发明的

把上面的东西摆在一起会发现一件有意思的事：今天我们在 AI Agent 里讨论的这批概念，几乎全是从老工程思想里搬过来的。

┌─────────────────────┬─────────────────────────────────────────┐
│  AI Agent 中的概念 │   传统工程思想来源                      │
├─────────────────────┼─────────────────────────────────────────┤
│  Source of Truth    │  Software Eng / Knowledge Management    │
│  Specification      │  Requirements Engineering               │
│  Acceptance Criteria│  Agile / User Stories                   │
│  Definition of Done │  Scrum                                  │
│  Constraints        │  Software Arch / Systems Engineering    │
│  Quality Gate       │  DevOps / CI/CD                         │
│  Verification       │  Testing / Formal Methods               │
│  Evidence           │  Testing / Verification                 │
│  Feedback Loop      │  Agile / DevOps / Control Systems       │
└─────────────────────┴─────────────────────────────────────────┘

传统软件工程解决的是"如何让人和软件系统可靠地协作"，AI Agent 面对的是"如何让人和一个具有自主执行能力的软件系统可靠地协作"。所以 AI Agent Engineering 并不是从零建立一套工程学，很大程度上是在重新组合已有的软件工程思想，使其适用于具有自主性的 AI 系统。

想系统理解 DoD 的话，几本经典：Ken Schwaber《Agile Project Management with Scrum》、Mike Cohn《User Stories Applied》、Jeff Sutherland《Scrum: The Art of Doing Twice the Work in Half the Time》。

一份可以直接抄的沟通模板

给 AI 复杂任务时，我现在基本都按这个结构来：

## Context
当前系统使用 Go 1.24，数据库为 MySQL 8.0。

## Source of Truth
API 定义以 OpenAPI 为准。数据库结构以 Migration 为准。

## Goal
将接口 P95 延迟降低到 100ms 以下。

## Constraints
不能修改 API。不能修改数据库结构。不能增加第三方依赖。

## Definition of Done
测试全部通过。Benchmark P95 < 100ms。无新增 lint error。

## Verification
执行 go test ./... / benchmark / golangci-lint。

## Evidence
报告实际执行结果，不要只报告"已完成"。

这比"帮我把这个接口优化一下，注意不要影响原来的功能"可靠得多。这套模板的核心不是让 Prompt 变长，而是让 AI 没有必要猜测。

人与 AI 的分工

分工也因此变了：

过去:  人负责思考，机器负责执行
现在:  人负责定义问题空间，AI 负责探索解决方案

人应该越来越擅长                AI 负责
────────────────────           ────────────────────
定义目标 / 判断优先级            搜索 / 分析 / 编码
提供事实 / 设计约束              调试 / 执行工具
定义验收标准 / 判断风险          生成方案 / 验证结果
审查证据

未来优秀的 AI 使用者，不一定是最会写 Prompt 的人，而是最会定义上下文、约束和验证体系的人。

总结

面对任何 AI 任务，先问自己五个问题就够了：

1. What is true?          什么是事实？      → Source of Truth
2. What do we want?       我们到底要什么？  → Goal / Specification
3. What must not happen?  什么不能发生？    → Constraints
4. What counts as done?   什么才算完成？    → Acceptance Criteria / DoD
5. How do we know?        凭什么知道完成了？→ Verification / Evidence

与 AI 高效沟通的本质，不是"如何把话说得更漂亮"，而是**"如何把问题定义得足够清晰，让 AI 能够可靠地执行"**。

如果只把 AI 当聊天机器人，你会不断优化 Prompt；如果把 AI 当 Agent，你就必须开始考虑：事实从哪里来？目标是什么？边界在哪里？什么叫完成？如何验证？

AI 越强，人越不应该只负责"提问"。人真正应该负责的是：定义事实、目标、规则、边界和判断标准。而这，正是从 Prompt Engineering 走向 Harness Engineering 的关键一步。