第三章：意图的分层

1 为什么需要分层

意图从来都不是一个单一维度的简单指令，而是一个分层的语义体系。让我们通过一个具体的场景来理解这一点：当一位高管在项目启动会上说"我们要开发一个会员系统"时，在场的不同角色实际上接收到了完全不同的信息——

CEO脑海中浮现的是财务报表上的数字：这套系统能否提升用户留存率？能否带来可观的收入增长？它如何支撑公司的长期竞争壁垒？

产品经理则在思考功能蓝图：会员应该划分几个等级？每个等级的权益如何设计？定价策略应该采用怎样的梯度？如何与现有的积分体系打通？

技术负责人的关注点已经下沉到技术层面：这个系统应该如何保障性能？数据安全如何确保？高并发场景下如何稳定运行？

同一个"会员系统"的概念，在不同角色的认知中呈现出截然不同的面貌。这种认知差异不是沟通的失误，而是软件系统固有复杂性的体现——它同时涉及商业价值、产品功能和技术约束等多个层面。

意图分层的核心目的，正是在这种复杂性中建立秩序。它将模糊的"开发一个系统"分解为清晰的三个层次：业务意图指明价值方向，产品意图定义具体功能，技术意图划定实现边界。其中，产品意图和技术意图是IOSE变革的核心操作界面。

2 意图的三层模型

在面向意图软件工程的实践中，我们将意图划分为三个层次，形成清晰的价值传递链条：

flowchart TB
    A["业务意图 Business"]
    A_desc["回答为什么做——价值方向"]
    B["产品意图 Product"]
    B_desc["回答做什么——功能定义"]
    C["技术意图 Technical"]
    C_desc["回答怎么做才对——约束边界"]

    A --> A_desc
    A --> B
    B --> B_desc
    B --> C
    C --> C_desc

    style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style B fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style A_desc fill:#fafafa,stroke:#bdbdbd
    style B_desc fill:#fafafa,stroke:#bdbdbd
    style C_desc fill:#fafafa,stroke:#bdbdbd

这三个层次分工明确、逐层递进。其中，产品意图和技术意图是IOSE变革的核心战场——产品人员通过定义产品意图直接驱动开发，技术人员通过定义技术意图保障AI生成质量。

业务意图（Business Intent）

业务意图聚焦于宏观的商业目标，回答"为什么要做"的问题。它通常来自高层管理者，为整个组织指明方向。

业务意图的核心要素：

业务意图相对稳定，更多作为背景存在。在IOSE变革中，它不需要被频繁操作，但需要被清晰理解和传达。

业务意图示例：

我们要做什么：
提升年费会员的续费率

业务目标：
- 将年度会员续费率从目前的75%提升至85%，即每月减少约2000名被动流失用户
- 通过主动服务手段，让更多即将到期的会员及时完成续费
- 预计带来的年收入增长约为500万元

价值主张：
对公司的价值：
减少用户流失意味着更高的客户生命周期价值，每位保留的年费会员平均可带来
额外3年的订阅收入。相比获取新客的高昂成本，留住老用户的ROI更高。

对用户的价值：
帮助用户避免因遗忘或疏忽导致的权益中断，确保他们能持续享受会员特权，
提升用户对平台的忠诚度和满意度。

战略背景：
- 市场竞争加剧：过去两年，同行业的获客成本上涨了40%，单纯依靠拉新驱动
  的增长模式已经难以为继

- 公司战略转型：今年公司明确提出从"流量导向"向"用户价值导向"转型，
  存量用户运营成为核心战略

- 数据发现的问题：用户调研显示，超过60%的流失会员表示"忘记续费"是主要原因，
  而非对服务不满意，这意味着存在巨大的挽回空间

产品意图（Product Intent）

产品意图是连接业务与技术的桥梁，它将抽象的业务目标转化为具体的产品功能方案，回答"做什么"的问题。

产品意图的核心要素：

• 功能目标：具体要实现什么功能，解决什么问题
• 目标用户：这个功能服务的对象群体是谁，他们有什么特征
• 使用场景：功能在什么情况下被使用，触发条件是什么
• 用户体验：用户如何感知这个功能，操作路径是怎样的
• 验收标准：如何衡量功能是否成功，有哪些可量化的指标

产品意图是IOSE变革的核心操作对象之一。在IOSE范式下，产品经理的工作重心从写PRD、画原型，转向定义结构化的产品意图。这种结构化的产品意图可以直接驱动AI生成可运行的软件，产品人员由此获得了直接创造数字产品的能力。

产品意图的表达有两种主要形式：文本描述用于表达功能逻辑和业务流程，Figma设计稿用于精确表达用户界面。

文本表达：描述功能与流程

文本形式适合描述不涉及复杂界面的功能逻辑、业务流程、算法规则等。它用自然语言清晰阐述"做什么"、“给谁用”、“在什么场景下使用"以及"如何衡量成功”。

文本型产品意图示例：

功能目标：
为年费会员开发一套权益过期提醒功能，在用户会员即将到期时，通过App推送
和邮件多渠道触达，提醒用户及时续费，从而减少因遗忘导致的被动流失。

目标用户：
年费会员，特别是距离到期还有30天内的用户群体。根据数据分析，这部分
用户的续费意愿较高，但容易因忘记而导致权益中断。

使用场景：
当会员的年费权益即将在30天内过期时，系统需要主动发起提醒：
- 到期前30天：首次友好提醒，告知权益即将到期
- 到期前7天：二次提醒，强调权益价值和续费优惠
- 到期前1天：最后提醒，制造紧迫感
提醒渠道包括App推送通知和邮件两种方式。

用户体验：
- 提醒内容清晰明了：明确告知过期时间、剩余权益价值，以及不续费将失去什么
- 操作路径极简：提供一键续费的快捷入口，用户无需多次跳转即可完成支付
- 尊重用户选择：提供"7天后再提醒"和"不再提醒"的选项，避免过度打扰

验收标准：
功能准确性：
- 提醒触发时机准确，分别在到期前30天、7天、1天触发
- 提醒对象筛选正确，不包含已续费或已关闭自动续费的用户

业务效果：
- 提醒打开率 > 60%（即收到提醒的用户中，超过60%会点击查看）
- 续费转化率 > 15%（即点击查看的用户中，超过15%会完成续费）
- 用户投诉率 < 1%（因过度打扰或提醒不准确导致的投诉）

Figma表达：精确描述用户界面

当产品意图涉及用户界面时，纯文本描述往往难以精确传达视觉细节——按钮的具体位置、颜色色值、文字字号、元素间距等信息用文字描述既冗长又容易歧义。此时，Figma设计稿是表达界面意图的最佳工具。

Figma的本质优势在于它将设计定义成了数据：

• 传统设计工具输出的是像素（图片），大模型需要"理解"视觉元素、推理其结构和样式，这个过程不仅消耗大量算力，还容易丢失细节（比如精确的间距、色值、字体参数）。
• Figma的每一个界面元素——从按钮的位置坐标、颜色值到文字的字体、间距参数——都是结构化的数据。Figma的文件格式本质上就是一种"伪代码"，可以被精确读取和程序化操作。

因此，当产品意图包含界面时，优先提供Figma设计稿的链接或导出的结构化数据，而非截图或纯文字描述。这让AI能够精准还原设计意图，而不是在模糊的视觉信息中猜测。

界面型产品意图示例：

功能目标：
设计会员续费提醒的推送通知卡片和邮件页面，提升用户点击率和续费转化率。

界面交付物：
- Figma设计稿链接：https://figma.com/file/xxx/member-renewal
- 或导出的结构化数据文件（如 figma-to-code 插件生成的 JSON）

关键界面说明：
1. App推送通知卡片
   - 展示位置：手机锁屏和通知中心
   - 内容要素：会员等级图标、权益过期倒计时、续费按钮
   - 交互：左滑关闭，点击进入续费页面

2. 邮件提醒页面
   - 顶部：品牌Logo和会员专属标识
   - 主体：权益清单（已使用/未使用）、过期时间、续费优惠
   - 底部：一键续费按钮、客服联系方式、退订链接

设计规范：
- 遵循iOS/Android官方推送设计规范
- 邮件宽度限制在600px以内，确保各客户端兼容
- 按钮颜色使用品牌主色#FF6B35，确保视觉层级清晰

验收标准：
- 设计稿完整覆盖推送卡片和邮件两种形式
- 所有视觉元素标注明确的尺寸、颜色、字体参数
- 提供移动端和桌面端的适配方案

技术意图（Technical Intent）

技术意图的核心使命是将产品意图转化为编码Agent能够理解和执行的具体方案，同时确保实现过程符合质量边界。它回答两个关键问题：“如何让AI理解需求"以及"怎么做才对”。

技术意图包含两大组成部分：

第一部分：实现规格（How to Implement）

这部分聚焦于将产品功能拆解为Agent可执行的技术方案，是技术意图最具变革意义的内容。

第二部分：质量约束（Constraints）

这部分定义实现过程必须遵守的边界条件。

关于架构质量约束的特别说明：

架构质量约束是IOSE范式中确保软件长期可维护性的关键机制。当AI Agent持续生成和修改代码时，如果没有清晰的架构边界约束，系统很容易陷入"混乱增长”——模块职责模糊、依赖关系错综复杂、代码复杂度失控。这不仅影响人类理解，更会大幅降低AI Agent后续工作的效率。

核心架构约束要素：

• 分层方向约束：严格定义分层架构中各层的依赖方向（如经典的三层架构：Controller → Service → Repository），禁止反向依赖或跨层调用。这确保AI在生成新代码时不会破坏架构的清晰边界。

• 圈复杂度控制：要求每个函数/方法的圈复杂度不超过10（或团队约定的阈值）。高复杂度的代码不仅难以维护，也会让AI在后续修改时难以把握逻辑边界，容易产生bug。

• 模块规模约束：限制单个文件、单个类、单个函数的代码行数（如单个文件不超过500行，单个函数不超过50行）。适当的粒度让AI能够更精准地定位修改范围，降低变更的影响面，提升生成效率。

通过这些约束，我们确保AI Agent在持续工作中始终面对的是一个结构清晰、边界明确的代码库，从而保持高效率的代码生成和修改能力。

技术意图是IOSE变革的核心操作对象。开发者从"亲自编写每一行代码"转向"定义实现规格并审查AI的执行"。高质量的技术意图应当足够清晰，使得Cursor、Claude Code等Agent工具能够基于它自主完成开发任务。

技术意图的实践参考

在实际工作中，技术意图的撰写可以参考以下工具和理念：

参考Cursor的Agent模式：Cursor的Composer功能展示了如何将需求描述转化为多文件代码修改。在技术意图中，我们需要提供类似的"上下文地图"——说明每个模块的职责、与其他模块的交互方式、以及关键文件的组织结构。

参考Claude Code的Spec驱动：Claude Code在处理复杂任务时，会先与用户确认"Implementation Plan"（实现计划）。技术意图中的"任务拆分"部分正是类似的实现计划，它需要明确每个子任务的输入、输出和验收标准。

参考Kiro的规格驱动开发：Kiro强调"Specs as Code"，即规格文档本身就是可执行的约束。技术意图中的"验收规格"应当足够精确，可以被自动化工具验证——例如通过单元测试断言、API契约测试、或者静态代码分析来确保实现符合规格。

3 三层之间的互动关系

业务意图、产品意图和技术意图不是相互独立的三个孤岛，而是一个有机整体。理解它们之间的互动关系，对于有效运用意图分层至关重要。

自上而下的转化过程

在实际的软件规划过程中，高层的业务意图需要逐层转化为可执行的技术方案：

flowchart TD
    A["业务意图: 提升会员续费率10%"]
    B["产品意图: 权益过期提醒功能"]
    C["技术意图A: 提醒生成服务"]
    D["技术意图B: 推送通知服务"]
    E["技术意图C: 续费页面优化"]

    A --> B
    B --> C
    B --> D
    B --> E

    style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style B fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style D fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style E fill:#fff3e0,stroke:#f57c00,stroke-width:2px

业务意图回答"为什么要做"，为产品意图提供方向指引；产品意图回答"做什么"，将业务目标转化为具体的功能方案；技术意图回答"怎么做才对"，为产品实现划定质量边界。

自下而上的支撑关系

反过来，每一层意图都为上一层提供实现支撑：

• 技术意图支撑产品意图：如果没有性能约束，提醒服务可能在高峰期崩溃，产品功能就无法正常运行；如果没有安全约束，用户数据泄露，产品价值将荡然无存。
• 产品意图支撑业务意图：如果产品功能设计不合理，用户不愿使用，业务目标就无法达成；如果验收标准设定不当，无法衡量实际效果，业务价值就无从验证。

产品意图和技术意图是IOSE变革的核心操作界面。产品人员通过定义清晰的产品意图，直接驱动AI理解"做什么"；技术人员通过定义完备的技术意图，确保AI知道"怎么做才对"。两者共同构成了人类与AI协作的主要通道。

各层的关注主体

4 意图表达的精确性原则

意图表达的质量直接决定了AI Agent能否准确理解和执行。以下是两个关键原则：

避免歧义：从模糊到精确

自然语言本身具有天然的歧义性，但意图文档要求尽可能消除这种歧义。以下是一些常见的对比示例：

可验证性：确保意图可被检验

每一个意图都应该能够被客观地验证。如果一个意图无法验证，那么它就无法作为AI Agent的执行目标和验收标准。

不够好的意图示例：“系统应该稳定运行”

问题：“稳定"是一个主观概念，不同人可能有不同理解

改进后的意图：“系统可用性 > 99.9%，故障恢复时间 < 30分钟，每月计划外停机时间 < 43分钟”

优势：指标明确、可测量、可验证

5 本章小结

意图分层是面向意图软件工程的理论基石和实践指南。通过本章的学习，我们应该掌握以下核心要点：

1. 业务意图回答"为什么做”——它指明价值方向，为产品意图提供背景；
2. 产品意图回答"做什么"——它将业务目标转化为具体功能方案，是IOSE变革的核心操作对象；
3. 技术意图回答"如何让AI理解并实现"——它包含实现规格（需求拆解、技术设计、任务拆分）和质量约束，是IOSE变革的技术核心；
4. 精确表达原则消除了自然语言的歧义，确保意图能够被AI准确理解和验证。

这种三层结构带来的好处是多方面的：

• 业务人员可以专注于价值方向，无需陷入功能细节；
• 产品人员可以专注于功能定义，通过结构化意图直接驱动开发；
• 技术人员从编码执行者转变为规格定义者，通过技术意图指导AI完成实现；
• AI Agent获得了清晰、结构化、可执行的输入，能够自主完成从设计到编码的全流程。

核心洞察：在IOSE范式下，技术人员的价值不再体现在"写代码的速度"，而体现在"定义清晰规格的能力"。一个优秀的技术意图应当足够完整，使得Cursor、Claude Code等Agent能够基于此自主完成开发任务，而人类只需审查和验收。

在下一章中，我们将进一步对比新旧软件工程范式的核心差异，深入理解这场变革的深远影响和意义。

实操练习

为了帮助你更好地掌握意图分层，建议完成以下实践练习：

练习任务：选择一个你当前正在负责或熟悉的具体功能，尝试按照本章介绍的模板编写：

1. 一份业务意图文档（简要说明业务背景和目标）
2. 一份产品意图文档（参考3.2.2节的模板，详细描述功能定义）
3. 一份技术意图文档（参考3.2.3节的模板，明确技术约束）

完成后的自检清单：

• 三个层次的意图是否形成清晰的价值链条？
• 产品意图是否将业务目标转化为具体可执行的功能方案？
• 技术意图是否包含完整的实现规格（需求拆解、技术设计、任务拆分）？
• 任务拆分是否足够细致，Agent能够理解每个任务的输入输出？
• 验收规格是否可量化、可自动化验证？
• 如果将这些文档交给Cursor或Claude Code，它是否能够据此自主完成开发？