意图对齐：AI 编程时代被忽视的核心工程能力
前言：当"代码"不再等于"意图"
过去几十年的软件工程里，代码就是意图的直接体现。架构自己设计，接口自己定义，逻辑自己写，边界自己调。每一行代码都是思维的具象化。沟通偏差当然有，但主要发生在人与人之间——一旦进入编码阶段，意图就锚定在代码里了。
所以传统意义上的"意图对齐"，止步于需求理解的一致性就够了。但在 Vibe Coding 和 Harness Engineering 进入日常开发流程之后，这个等式不成立了。
代码不再是意图的载体，而是 AI 对你意图的翻译结果。
矛盾点从"人与人"转移到了"人与 AI"。要求更高，容错更低。你没法再依赖"边写边想"或"代码即文档"的默契，必须近乎 100% 精确地告诉 AI 这些事：
- 执行顺序：先做什么？后做什么？哪些步骤不可并行？
- 技术选型：用什么框架？依赖哪个版本？是否允许引入新库？
- 架构规约：模块边界在哪？哪些是禁区？数据流如何约束？
- 开发方式：普通开发，还是测试驱动开发（TDD）？
- 上下文资产：知识库存放在哪？已有接口契约是什么？
- 环境限制：运行时资源上限？网络策略？安全合规红线？
- 验证标准：怎样才算"完成"？测试覆盖哪些路径？失败语义如何定义？要不要 E2E？
缺任何一环，AI 都会基于训练数据里的"常见模式"做合理但错误的推断。早期 Vibe Coding 最被诟病的就是这个：自作主张——《AI 替你做的每个模糊决定，都可能是需求里埋的雷》。这些缺失的信息，就是意图和结果之间差距的根源。
最常犯的 4 个错误
用 Vibe Coding 的时候很容易有一种错觉：把想法"说"出来，AI 就能"懂"并"做对"。实际上，意图不等于指令，指令不等于实现，实现更不等于正确。
01 自然语言太模糊
自然语言擅长传递情绪和方向，给不了工程需要的精确性。这不能怪语言本身——它生来就是用于人与人高效沟通的，没人喜欢事无巨细地描述早餐的配料、火候和口感。
"优化一下性能""让代码更清晰""处理得健壮些"，这些话在人类协作里没问题，交给 AI 就是灾难的起点。它感知不到你的潜台词，只能按概率选"最可能"的解释。而这个解释，经常跟你的真实意图南辕北辙。
02 上下文知识匮乏
AI 对你的系统一无所知，除非你告诉它：
- 哪些服务是核心链路，哪些是边缘功能？
- 字段的意义是什么？哪些不能改？禁区在哪里？
- 这个接口的 RPC 调用路径是什么？
- 缓存失效后，降级还是返回错误？
- 缓存过期时间要不要加 20% 随机浮动，避免击穿？
这些"组织内部常识"不显式注入，AI 就用训练时的通用模式来填。结果是错误的降级策略、越权的数据访问、跟现有契约冲突的接口变更——污染架构，埋下隐患。
03 没有验证闭环
模糊的语言和匮乏的上下文都还不是最要命的。真正危险的是缺人机协同的验证闭环。现在的 AI 不会主动反馈不确定性，也不会自己去查知识库（这正是《Karpathy 的 LLM 知识库想法，我自己搭了一遍》要解决的问题），得靠开发者设计交互流程：
- 强制澄清：遇到模糊或拿不准的地方，选 A 还是选 B，必须问，不能擅自作主。
- 上下文补全：我们给的信息一定不全，AI 必须能自己去指定位置调查。
- 自我验证：信息够了之后，能不能串起来形成合理方案？这需要 AI 有自我验证的能力。
04 上下文过长，"腐化"出幻觉
上下文太少会偏，太多也会错。大模型的上下文容量和信息处理能力都有限，信息量一上来，注意力机制就开始"失焦"：早期的关键约束被稀释，后期的临时补充被过度强调。最早定的规则，到后面被"遗忘"了——这个现象很明显。而且上下文过多会迫使模型压缩信息，进一步失真。
要控制信噪比：
- 上下文精准，胜过堆砌
- 描述要结构化
- 明确当前的重点是什么
最后
先在上下文里定义一套基础规范，你甚至可以把它加进自己的 skill：
- 需求有歧义就先问，不要根据"常见做法"擅自添加用户没要求的任务。
- 用户描述存在多种理解时，先澄清，别替用户猜。
- 50 行能解决的问题，别写成 200 行。不过度封装，不过度抽象。
- 尽量只做局部修改，不要把小任务做成大手术。
- 任务复杂就分步实施，控制上下文总量，避免"腐化"。
暂无评论