AI-Native 软件工程(6):为什么起点是 Intent,而不是代码上一篇画了完整的工程结构图：Intent → Plan → Execute → Verify → Delivery。这一层看起来最简单，实际上最难。难到什么程度？我见过的大多数 AI 编程失败案例，根本原因都不在 AI 不够强，而在 Intent 没定义清楚。前段时间我让 AI 帮我重构一个模块。我的 Prompt 是这样的："重构 ArticleService，把里面太重的逻辑拆出来。"AI 很听话，给我拆了。把一个 600 行的文件变成了 8 个文件，每个文件不到 100 行。看起来很工整。但我 review 的时候发现问题了：它把"拆"理解成了按方法拆分。原来一个 Service 里的 8 个方法，变成了 8 个独立 Service。每个 Service 只有一个方法，相互之间通过参数传递数据。调用链从原来的 1 层变成了 3 层。代码行数少了，复杂度反而高了。"把太重的逻辑拆出来"——这不是 Intent，这是一个模糊的愿望。什么叫太重？拆到哪里？拆完之后的结构应该是什么样？拆分的原则是按职责还是按调用频率？这些我都没说。AI 没有办法补全这些缺失的信息。它只能基于训练数据里最常见的"拆分"模式去猜。而最常见的模式，不一定是你要的模式。在 AI 时代，代码不再稀缺。Intent 才稀缺。过去的软件工程里，瓶颈是实现。想清楚要做什么不难，难的是写出来、调通、上线。所以工程师的价值主要体现在编码能力上——你能不能写出高性能的查询、能不能处理好并发、能不能把内存控制在合理范围内。现在这些事情 AI 都能做。不一定做得完美，但做得够快。一个中级工程师花 4 小时写的 CRUD 接口，AI 15 分钟就能生成。如果你说"写一个用户注册接口"，你会得到一个最基础的注册接口——可能用最常见的框架、最常见的字段、最常见的校验逻辑。它不知道你的系统里手机号是唯一标识还是邮箱是唯一标识。它不知道你需要支持第三方 OAuth 还是只做密码注册。它不知道你的安全规范要求密码必须 bcrypt 加盐还是 argon2。目标是你要解决什么问题。不是"写一个注册接口"，而是"让新用户可以通过手机号完成注册，支持短信验证码，注册后自动创建默认工作空间"。约束是什么不能做、什么必须满足。比如："密码使用 argon2 加密，验证码 5 分钟过期，同一手机号 60 秒内只能发一次，单日上限 10 次。"上下文是系统的现有状态。比如："当前用户模型在 packages/core/src/models/User.ts，已有 email 注册逻辑在 AuthService 里，数据库用的 PostgreSQL + Drizzle ORM，认证用的 JWT，项目用 monorepo 结构。"没有目标，AI 不知道往哪走。没有约束，AI 会做出你不想要的决定。没有上下文，AI 会假设一个不存在的系统环境。错误的代码可以修。错误的 Intent 会导致整个系统方向错误。代码层面的 bug——函数逻辑错了、参数漏了、边界没处理——这些都是局部问题，修起来成本有限。比如你定义的目标是"优化用户注册流程"，但真实问题是用户注册了不激活。你让 AI 花三天优化了注册页面的性能、简化了表单、加了各种引导——全做完了，激活率还是没变。因为问题不在注册流程，在激活流程。AI 不会告诉你"你的 Intent 可能搞错了"。它只会忠实地执行你给的 Intent。这就是为什么我说 Intent 是最被低估的一层。大多数人花了大量时间在调 Prompt、选模型、搭 Agent 上，却很少花时间在定义 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 再强也没用——它们只会在错误的方向上越跑越远。当 Intent 定义清楚之后，AI 为什么不能直接开始干？为什么必须有一个 Planner 层来拆解任务？没有 Planner 会发生什么？如果说 Intent 是方向盘，那 Planner 就是导航。方向盘决定你要去哪，导航决定你走哪条路。两个都不能少。
夜雨聆风