TL;DR

本文核心观点：

  1. 范式转移 — 详细设计不会完全消失，但会”消失一半”——80% 的常规需求将被 Intent + Constraints + Examples 直接替代，只有 20% 的复杂系统仍需传统详细设计。
  2. 信息密度提升百倍 — intent + constraints + examples 三要素直接驱动 AI 生成代码，比长篇详细设计文档的信息密度高出两个数量级。
  3. 核心能力转向 — 工程师从”如何实现”转向”想要什么”，从”写代码”转向”定义问题和边界”，从”详细设计文档”转向”高质量示例”。
  4. 三层分层选择 — Layer 1（Intent-Driven，80%）、Layer 2（Structured Design，15%）、Layer 3（Detailed Design，5%），按需选择而非一刀切。

详细设计会消失吗？Intent-Driven 开发的未来

前面三篇讲了 AI-Native 详细设计的变革、最小实践、增量工作流。

现在问一个更激进的问题：

详细设计会消失吗？

答案是：会消失一半。

💡 Key Insight

消失的不是设计本身，而是设计的表达方式——从”规定如何实现”变成”规定要达成什么”。

详细设计分层模型

正在发生的范式转移

AI-Native SDLC 正在出现一种新范式：

核心思想：

很多”详细设计”会被 intent + constraints + examples 直接替代。

不是设计变少了，而是设计的表达方式彻底变了。

💡 Key Insight

AI 不需要你教它”怎么写循环”——它需要的是”这个功能要达成什么目标”。一份 5000 字详细设计文档，对人类是充分信息，对 AI 可能是噪声。

传统 vs Intent-Driven

传统 vs Intent-Driven

传统详细设计

传统详细设计是软件工程中最经典的产出物：一篇 10-30 页的 Word 文档，规定”系统应该怎么做”——类图、时序图、数据库 Schema、接口签名、异常处理策略，应有尽有。它的核心假设是：写清楚”如何实现”，代码就能正确执行。

这套模式在过去二十年运转良好，原因有三个。第一，代码由人类编写，人类需要详细的指令。第二，设计文档和代码一样是”交付物”，有同等效力。第三，评审靠人肉完成，文档的可读性直接影响评审质量。

但 AI 出现后，这套假设开始崩塌。AI 不需要你教它”怎么写循环”——它需要的是”这个功能要达成什么目标”。一份 5000 字详细设计文档，对人类来说是充分信息，对 AI 来说可能是噪声——因为人类在写作时会不自觉地补充大量”显而易见”的上下文，这些对 AI 反而造成干扰。

💡 Key Insight: 传统详细设计靠长篇文字描述系统行为，信息密度低且容易产生语义歧义。人类阅读成本高，AI 更难从中提取确定性约束。

Intent-Driven

Intent-Driven 的本质是从”规定如何实现”转向”规定要达成什么”。它只要求你回答三个问题：为什么要做这个功能？怎么算成功了？有什么边界条件？

最关键的变化是Examples（示例）的引入。传统详细设计用文字描述期望行为；Intent-Driven 用 3-5 个具体例子。举个例子，”用户登录失败后应该显示错误信息”是一句模糊的描述；”尝试用错误密码登录，第三次时系统返回 401 Unauthorized 并显示’密码错误，还剩 2 次尝试机会’“就是一个 AI 可以直接执行的 Example。

Examples 之所以比规格说明更有效，因为 LLM 的本质是模式匹配。给它看正确的模式，它就能复现；给它抽象规则，它就要做推理。推理有不确定性，模式匹配几乎没有。

💡 Key Insight: Intent-Driven 用 intent + constraints + examples 三要素直接驱动 AI 生成代码。信息密度提升百倍，AI 理解成本大幅下降。

信息密度提升了 100 倍。

💡 Key Insight

同样是”说清楚期望”，Examples 比文字描述的信息密度高出两个数量级——而且 AI 执行的不确定性更低。

Intent-Driven 的核心结构

只需要三个要素：

1. Intent（意图）

关键： 说清楚”为什么要做”和”怎么算成功”。

2. Constraints（约束）

关键： 划定边界，告诉 AI 什么不能做。

3. Examples（示例）

关键： 用具体例子说明期望行为，比抽象描述更有效。

为什么 Examples 比 Spec 更有效？

LLM 的本质是模式匹配。

给它看 3-5 个高质量例子，比 20 页抽象规格更容易理解。

方式 AI 理解难度 人类编写成本
抽象规格 高 高
具体例子 低 低

这就是 Few-Shot Prompting 在软件工程中的应用。

Intent-Driven 的工作流程

设计文档不是写出来的，是”示例驱动”生成的。

具体分五步循环：

第一步：写清楚 Intent。 用一两句话说明为什么要做这个功能，以及”怎么算成功了”。这里的关键词是”结果”而非”过程”——不是说”我们要做一个用户登录模块”，而是说”用户可以通过密码或 SSO 登录，登录成功后获得 24 小时有效的会话 token，失效后需要重新认证”。

第二步：列举 3-5 个高质量 Examples。 包括正向案例（正确行为是什么样）和负向案例（错误行为应该被拒绝）。Examples 越多越好，但质量比数量重要——一个能覆盖多个边界条件的负向例，比三个重复的正向例有用得多。

第三步：明确 Constraints（约束）。 这是最容易被忽略的一步。Constraints 不是功能需求，而是”边界条件和禁忌”：不能用什么技术方案？哪些 corner case 必须处理？什么行为是绝对不允许的？把”不要做什么”说清楚，和”要做什么”同样重要。

第四步：交给 AI 生成初始实现。 把 Intent + Examples + Constraints 一起给到 AI，让它生成第一版代码。这时不要给实现提示——如果发现自己在补充”这里用循环而不是递归”，说明你的 Intent 或 Examples 写得还不够清楚。

第五步：用反馈迭代 Examples 和 Constraints。 AI 第一次输出几乎肯定不会完全符合预期——这时不要直接修改代码，而是把 AI 的错误输出补充到 Examples 里（”这个 Case 应该返回 X，而不是 Y”），然后重新生成。这个循环通常需要 2-3 轮，直到 AI 的输出稳定可用。

💡 Key Insight

Intent-Driven 工作流是一个循环，不是一次性活动——前几轮的目的是把 Examples 和 Constraints 补充完整，而不是一步到位写出完美代码。

什么场景适合 Intent-Driven？

什么场景适合 Intent-Driven？

场景 适合度 原因
CRUD 操作 ⭐⭐⭐⭐⭐ 模式固定，例子足够
标准业务流程 ⭐⭐⭐⭐⭐ 有明确规则，可示例化
复杂算法 ⭐⭐⭐ 可能需要补充数学描述
创新性功能 ⭐⭐ 缺乏先例，需要更多设计
安全关键系统 ⭐ 需要严格验证，不能仅靠例子

结论： 80% 的业务开发适合 Intent-Driven，20% 的复杂系统仍需传统设计。

💡 Key Insight

选 Layer 1 还是 Layer 3，不是功能大小的问题，而是”AI 对这类问题的置信度”够不够——置信度够用 Intent-Driven，置信度不够就加约束或退回到详细设计。

详细设计会完全消失吗？

不会。但会分层：

分层的关键不是”功能大小”，而是AI 对该类问题的置信度。当 AI 对一个任务有足够多的参考例子，它的输出就稳定可靠——这种情况用 Intent-Driven。当 AI 输出不稳定、需要多轮才能收敛——这种情况用 Structured Design。当任务涉及人类判断、安全攸关、或业界没有先例——这种情况用 Detailed Design。

Layer 1: Intent-Driven（80% 的需求）

触发条件： 任务有明确模式可循，Examples 容易获取。

典型场景：CRUD 接口（增删改查用户、商品、订单）、标准业务流程（电商下单流程、审批流）、数据转换任务（CSV 解析、格式互转）。这些场景的共同特点是：正确的输出有明确标准，且人类可以轻松给出 3-5 个正负例。

操作方式：写清楚 Intent（目标是什么）、提供 3-5 个 Examples（正向和负向案例）、明确 Constraints（边界条件和禁忌）。AI 拿到这三样东西，通常能一次性给出可用代码，不需要多轮迭代。

Layer 2: Structured Design（15% 的需求）

触发条件： AI 单次输出置信度不足，或需要跨模块协调。

典型场景：涉及多个服务的分布式事务、带有状态机逻辑的业务流程（订单状态流转、库存锁定逻辑）、性能敏感路径（缓存策略选择、数据库索引设计）。这些场景的特点是：正确性边界不清晰，需要人类帮助 AI 建立约束体系。

操作方式：在 Intent-Driven 基础上，增加结构化约束文档——接口契约、数据 Schema、状态机定义、异常处理规范。可以理解为”给 AI 看一份更结构化的示例集”，而不是”给它一份实现指令”。

Layer 3: Detailed Design（5% 的需求）

保留场景： 核心支付逻辑、安全认证模块、涉及合规要求的系统、业界没有先例的创新功能。

这类场景之所以还需要 Detailed Design，不是 AI 能力不够，而是容错成本太高。一次支付漏洞可能造成数百万损失，一次安全认证绕过可能带来合规风险。在这些地方花时间写详细设计，是值得的。

操作方式：用传统详细设计的全套产出（类图、时序图、接口契约、异常处理策略），但写作目标从”给人类阅读”转向”给 AI 执行”——每一条设计决策都要附上对应的 Example，让 AI 能直接验证而非需要推理。

三层之间没有硬边界，实际选择是按需渐进的过程：先用 Intent-Driven 快速启动，AI 输出不稳定时就往 Layer 2 移动，发现涉及安全关键或核心算法时升级到 Layer 3。

工程师角色的变化

传统工程师

传统工程师的核心能力建立在一条清晰的推导链上：需求 → 详细设计 → 代码实现。他们擅长把模糊的业务目标翻译成精确的技术方案——画出完整的类图、写清楚状态机转换、预估各种 corner case。这种”如何实现”的推导能力，是多年在代码和文档之间反复往返积累下来的。

在 AI-Native 时代，这些能力没有完全消失，只是权重在转移。Layer 3（Detailed Design）仍然需要人来写，核心算法的正确性仍然需要人来保证。问题是：当 80% 的需求都不再需要详细设计时，单靠”如何实现”的推导能力，够不够支撑一个工程师的价值？

答案是否定的。不是因为这项能力没用，而是因为它只覆盖 5% 的场景。

AI-Native 工程师

AI-Native 工程师的核心工作，从”如何实现”转向了“想要什么”——定义清晰的 Intent、划定明确的 Constraints、提供高质量的 Examples。

这不是一个简单的能力切换，而是一次认知模式的转变。传统工程师的时间主要花在”实现路径”上：选什么架构、用什么算法、怎么组织代码结构。AI-Native 工程师的时间主要花在”问题定义”上：这个功能解决什么问题？成功的样子是什么？边界在哪里？有哪些错误行为需要特别排除？

从”写代码”到”定义问题和边界”，意味着工程师从”执行者”变成了”判断者”——不再亲手把代码敲出来，而是判断 AI 生成的代码是否真正解决了问题。

💡 Key Insight: AI-Native 工程师的核心工作是”想要什么”——定义清晰的 Intent、划定 Constraints、提供高质量 Examples。价值体现在对问题空间的理解深度。

核心能力转移：

  • 从”如何实现” → “想要什么”
  • 从”写代码” → “定义问题和边界”
  • 从”详细设计” → “高质量示例”

💡 Key Insight

这三个转移的共同本质是：工程师从”执行者”变成”判断者”——不再亲手敲代码，而是判断 AI 的输出是否真正解决了问题。

未来的终极形态

想象这样一个工作流：

详细设计在哪里？

在对话里，在例子中，在 AI 生成的代码里。

不再需要单独的”设计文档”。

💡 Key Insight

详细设计从”人写给人看”变成”人写给 AI 执行”，最终变成”人和 AI 共同探索问题空间”——设计文档消失了，但设计思维没有消失。

给实践者的建议

如果你今天开始

  1. 从 Intent-Driven 入手
    • 写清楚意图
    • 给 3-5 个高质量例子
    • 明确约束
  2. 逐步引入结构化设计
    • 当 AI 输出不稳定时
    • 当需要多人协作时
    • 当涉及复杂边界时
  3. 保留详细设计用于关键系统
    • 核心支付逻辑
    • 安全认证模块
    • 性能关键路径

关键心法

三条实战中最有用的心法：

1. 用 Examples 而非规格说明来传达期望。 当你发现自己在写”系统应该优雅地处理错误”，停下来——这句话对 AI 和对人类一样模糊。换一种说法：”当用户连续 3 次输入错误密码时，系统锁定账户 30 分钟，并返回特定错误码 ACCOUNT_LOCKED。第四次尝试在锁定期间内发生时，返回 RETRY_AFTER。”后者可以直接执行，前者只能靠推理。

2. 约束要清晰，但不要过度规定实现。 “不能用递归”是约束，”用循环实现阶乘”就不是约束——那是实现方案。Intent-Driven 的约束只说”什么不能做”，不说”怎么做”。给 AI 留出实现空间，它往往能给出比你想的更好的解法。

3. AI 不理解”显而易见”。 所有你认为是”常识”的假设，都必须写成 Examples 或 Constraints。人类工程师看到”登录后跳转到首页”，会自己补全”未登录用户访问需要认证的页面时，先跳转登录页，登录成功后跳转原页面”——对 AI，这些全部是未知假设。

💡 Key Insight: AI-Native 开发的终极心法是”用例子思考，而非用文档思考”。当你发现自己在写长篇描述时，问自己：这个描述能否用 3-5 个具体例子替代？

总结

详细设计不会完全消失，但会形态转移：

时代 核心产出 形式
传统 设计文档 长篇描述
AI-Native 过渡 结构化 Artifacts Markdown + YAML
Intent-Driven 意图 + 示例 极简文本

最终趋势：

详细设计从”人写给人看”变成”人写给 AI 执行”，最终变成”人和 AI 共同探索问题空间”。

这是软件工程的下一次革命。

你准备好了吗？

深度阅读时间：约 13 分钟

系列完结。四篇文章覆盖了 AI-Native 详细设计的变革逻辑、最小实践、增量工作流和未来趋势。希望对你有启发。