AI-Native 软件工程(6):为什么起点是 Intent,而不是代码

上一篇画了完整的工程结构图：Intent → Plan → Execute → Verify → Delivery。

今天展开第一层：Intent。

这一层看起来最简单，实际上最难。难到什么程度？我见过的大多数 AI 编程失败案例，根本原因都不在 AI 不够强，而在 Intent 没定义清楚。

---

先说一个我自己的经历。

前段时间我让 AI 帮我重构一个模块。我的 Prompt 是这样的："重构 ArticleService，把里面太重的逻辑拆出来。"

AI 很听话，给我拆了。把一个 600 行的文件变成了 8 个文件，每个文件不到 100 行。看起来很工整。

但我 review 的时候发现问题了：它把"拆"理解成了按方法拆分。原来一个 Service 里的 8 个方法，变成了 8 个独立 Service。每个 Service 只有一个方法，相互之间通过参数传递数据。调用链从原来的 1 层变成了 3 层。代码行数少了，复杂度反而高了。

问题出在哪？

不在 AI。在我。

"把太重的逻辑拆出来"——这不是 Intent，这是一个模糊的愿望。什么叫太重？拆到哪里？拆完之后的结构应该是什么样？拆分的原则是按职责还是按调用频率？这些我都没说。

AI 没有办法补全这些缺失的信息。它只能基于训练数据里最常见的"拆分"模式去猜。而最常见的模式，不一定是你要的模式。

---

这引出了一个关键认知：

在 AI 时代，代码不再稀缺。Intent 才稀缺。

过去的软件工程里，瓶颈是实现。想清楚要做什么不难，难的是写出来、调通、上线。所以工程师的价值主要体现在编码能力上——你能不能写出高性能的查询、能不能处理好并发、能不能把内存控制在合理范围内。

现在这些事情 AI 都能做。不一定做得完美，但做得够快。一个中级工程师花 4 小时写的 CRUD 接口，AI 15 分钟就能生成。

但 AI 生成什么，完全取决于你告诉它什么。

如果你说"写一个用户注册接口"，你会得到一个最基础的注册接口——可能用最常见的框架、最常见的字段、最常见的校验逻辑。它不知道你的系统里手机号是唯一标识还是邮箱是唯一标识。它不知道你需要支持第三方 OAuth 还是只做密码注册。它不知道你的安全规范要求密码必须 bcrypt 加盐还是 argon2。

它会给你一个"像"的东西。但"像"不等于"对"。

---

所以 Intent 到底是什么？

我的定义是三个词：

Intent = 目标 + 约束 + 上下文

目标是你要解决什么问题。不是"写一个注册接口"，而是"让新用户可以通过手机号完成注册，支持短信验证码，注册后自动创建默认工作空间"。

约束是什么不能做、什么必须满足。比如："密码使用 argon2 加密，验证码 5 分钟过期，同一手机号 60 秒内只能发一次，单日上限 10 次。"

上下文是系统的现有状态。比如："当前用户模型在 packages/core/src/models/User.ts，已有 email 注册逻辑在 AuthService 里，数据库用的 PostgreSQL + Drizzle ORM，认证用的 JWT，项目用 monorepo 结构。"

三者缺一不可。

没有目标，AI 不知道往哪走。没有约束，AI 会做出你不想要的决定。没有上下文，AI 会假设一个不存在的系统环境。

---

这里有一个反直觉的事实：

错误的代码可以修。错误的 Intent 会导致整个系统方向错误。

代码层面的 bug——函数逻辑错了、参数漏了、边界没处理——这些都是局部问题，修起来成本有限。

但如果 Intent 本身就是错的呢？

比如你定义的目标是"优化用户注册流程"，但真实问题是用户注册了不激活。你让 AI 花三天优化了注册页面的性能、简化了表单、加了各种引导——全做完了，激活率还是没变。因为问题不在注册流程，在激活流程。

AI 不会告诉你"你的 Intent 可能搞错了"。它只会忠实地执行你给的 Intent。

这就是为什么我说 Intent 是最被低估的一层。大多数人花了大量时间在调 Prompt、选模型、搭 Agent 上，却很少花时间在定义 Intent 上。但 Intent 的质量，直接决定了后面所有环节的上限。

---

那怎么写好 Intent？

我自己的实践里，有几个原则。

第一，Intent 不是一句话，是一个结构化描述。"帮我写个 XX 功能"不是 Intent。一个合格的 Intent 至少包含：要解决的问题、预期的行为、技术约束、系统上下文。

第二，Intent 应该描述"要什么"，而不是"怎么做"。"用 Redis 做缓存来优化查询"——这不是 Intent，这是实现方案。Intent 应该是："文章列表接口响应时间从 800ms 降到 200ms 以内，在不增加额外基础设施成本的前提下"。至于用 Redis 还是用内存缓存还是优化 SQL，这是 Plan 层要做的事。

第三，好的 Intent 是可以验证的。如果你定义完 Intent，发现没有办法判断它是否被满足了——那它不是一个好的 Intent。"优化性能"不可验证。"响应时间 < 200ms，P99 < 500ms"可验证。"提升用户体验"不可验证。"注册流程步骤从 5 步减到 2 步，转化率提升 15%"可验证。

---

写到这里，你可能会觉得：这不就是写好需求吗？传统软件工程也强调需求要清晰啊。

确实。但区别在于，传统流程里需求模糊了，人可以兜底。开发和产品可以反复沟通，工程师可以边写边理解，code review 的时候可以纠偏。

AI 时代这些兜底机制弱了很多。AI 不会主动找你沟通，不会在写代码的时候发现需求矛盾，不会在 review 的时候说"我觉得这个需求可能理解错了"。

Intent 的质量，在传统工程里是"最好高"。在 AI-Native 工程里，是"必须高"。

因为 Intent 是 AI 理解你要什么的唯一入口。如果这个入口的信号是模糊的、矛盾的、不完整的，后面的 Plan、Execute、Verify 再强也没用——它们只会在错误的方向上越跑越远。

---

下一篇写 Plan。

当 Intent 定义清楚之后，AI 为什么不能直接开始干？为什么必须有一个 Planner 层来拆解任务？没有 Planner 会发生什么？

如果说 Intent 是方向盘，那 Planner 就是导航。方向盘决定你要去哪，导航决定你走哪条路。两个都不能少。