🛠️ Intent Engineering 实践指南

SKILL 验收清单升级 + Project Rules Intent Hooks + 与元层 FDD 交叉对齐——五层意图架构的完整落地路径。

📋 SKILL 创建验收清单升级（Intent Engineering 版）

原清单（Context Engineering 版）→ 新清单（Intent Engineering 版）： Frontmatter 层新增：

• intent: 声明此 SKILL 服务的业务意图——不是「做什么」，是「为什么做这个比做别的更重要」。例如：intent: "优先保证代码安全性，即使这意味着更长的生成时间"。
• validation: 此 SKILL 成功的可测量条件。不是自然语言描述——是 Agent 可以在执行后自检的条件。例如：validation: "exit code = 0 AND no new eslint errors AND all existing tests pass"。

正文结构层新增：

• Intent Constraints 段：此 SKILL 在何种条件下必须停止并请求人类介入。对应 Intent Guard 的概念。
• Calibration Log 参考：建议 Agent 在执行后记录「意图偏离」的情况——以便在意图校准层中分析。

📏 Project Rules 升级：Intent Hooks

原有的约束三段式（DO NOT / Why / Alternative）保留，新增 Intent Hook： Intent Hook 是一个附加在每条约束上的「意图声明」，回答：这条约束服务于什么意图？

• 示例——约束：DO NOT execute git push。Intent Hook: 「保护代码库的版本安全 > 任何单次任务的便利性」。
• 当 AI 面临「推代码就能完成任务」和「遵守约束不推代码」的冲突时，Intent Hook 提供优先级判断依据——不是「因为规则说不可以」，是「因为规则背后的意图不允许」。

🔗 和元层 FDD 的交叉对齐

实践层和元层之间不是独立的——它们共享认知资产。以下对齐表是三层知识栈的完整性检查：

• 元层 Spec(What) ↔ 实践层 意图定义 + 意图编码 = 从「AI 应该生成什么」到「为什么生成这个」的完整链路。
• 元层 Test(Actually Works) ↔ 实践层 意图守卫 + 意图校准 = 从「验证是否正确」到「验证是否偏离意图」的升级。
• 元层 MCP(Tool Layer) ↔ 实践层 意图执行 = 从「用什么执行」到「执行是否服务于意图」的闭环。
• 方法层 Agent 生产就绪清单 ↔ 实践层 Intent Hook = Agent 基础设施的约束体系和意图守卫共享同一套优先级编码。

🌫️ 开放问题

1. 意图编码的标准化：Context Engineering 用 MCP 标准化了工具调用。Intent Engineering 用什么标准化意图？目前没有类似 MCP 的标准——意图仍然在自然语言中。
2. Intent Schema 的粒度：一条意图对应一个 SKILL？一个项目？一个组织？粒度越粗，Agent 越难执行；粒度越细，Schema 越难维护。最佳粒度是什么？
3. 意图冲突解决：两个意图互斥时——「快」vs「对」——谁裁决？是预先写定的优先级，还是运行时的人类判断？
4. 如果 Claude 5 能直接从组织中推断意图（不需要显式编码），五层意图架构是否还需要？

_{实践层 · 第四篇 | application complete | cross-ref: 元层 FDD 框架 + 方法层 Agent 生产就绪清单}