Plan：把原始想法固化为 intent.md

计划阶段的目标不是立刻选择技术，而是避免原始需求在多次转述中失真。提出问题的人先与 Claude 澄清影响对象、期望结果、边界和未知项，再由产品负责人纠正并接受一份可版本化的 intent.md。这个文件是“为什么要改变”的记录，不是伪装成需求的实现方案。

学习目标

• 能把模糊诉求整理成不预设实现的意图工件。
• 能设计产品负责人审查、接受或关闭意图的流程。
• 能用提交历史衡量意图形成速度和后续返工。

核心概念

官方手册允许意图从人的想法、工单或生产事件进入，但都经过相同步骤：来源描述问题，Claude 通过提问帮助具体化，来源人纠正误解，产品负责人作出接受决定，然后将工件提交到共享、版本化的位置。非工程人员不必直接操作 Git，也可以通过受控连接器完成提交。

好的意图包含问题、期望结果、受影响的用户与系统、约束和开放问题。它应当让设计者理解目标，同时保留方案空间。诸如“改成 Redis”“新增三个微服务”属于候选实现，除非它本身是不可变约束，否则不应混进问题定义。

重复的提问与格式可以编码成 Skill，让不同来源得到一致引导；但模板不能代替来源人的纠错和产品负责人的接受。领先指标可观察首次讨论到意图提交的时间，滞后指标可观察意图接受率以及构建开始后的意图修订。

实践步骤

1. 让提出者用自己的话描述“今天做不到什么、谁受影响、改善后会怎样”。
2. 追问范围、明确不做什么、数据或合规约束、可观察成功证据和仍未知事项。
3. 生成草稿后逐条让提出者确认，不允许把模型推断当事实。
4. 由产品负责人决定接受、退回补充或关闭，并在评审/合并记录中留下理由。
5. 将接受的意图与后续 spec.md 使用同一变更 ID 关联。

以下内容是 AIKnow 自行创作的 illustrative template（示意模板），不是 Anthropic 原文或官方标准。团队应按自身领域、审计要求和工具链调整：

# Intent: FIN-042 报销单据缺失提醒

状态：草稿
提出者：财务运营值班
负责人：费用产品负责人

## 问题
月末关账时，约有一成已提交报销缺少合规单据；员工直到人工退回才知道。

## 期望结果
员工在提交前看到缺失项，财务人员仍保留最终合规判断权。

## 受影响对象与系统
员工、费用审核员；费用 Web、单据服务、通知服务。

## 约束
- 不把单据图像内容写入日志。
- 提醒不能替代财务审批。
- 本期不改变移动端流程。

## 成功证据
上线四周后，因缺单退回的比例下降 30%，误拦截率低于 1%。

## 开放问题
- 海外实体的单据规则是否需要分开配置？
- 历史草稿是否补做检查？

常见误区

• 把意图写成用户故事集合。 如果看不到真实问题、约束和成功证据，故事再多也无法校验方向。
• 让 Claude 补齐未知事实。 未知项应明确留下并分派负责人。
• 把来源人排除在审查外。 这会重新制造转述损耗。
• 提交后永不修改。 新证据可以促使修订，但必须保留历史并同步影响到规范与计划。

动手练习

选一个只有一句话的待办，例如“搜索要更快”。使用上面的示意模板写出问题、受影响对象、三条约束、两个可量化证据和三个开放问题。检查全文：如果删掉任何技术名词，意图是否仍然成立？请另一位同事扮演产品负责人，只根据文档决定接受还是退回。

要点回顾

intent.md 把原始问题变成第一份人机共读工件。它不替代产品判断，而是让判断发生在信息最接近来源、修改成本最低的时刻。来源纠错、产品接受、版本记录和明确成功证据共同构成可追溯的计划入口。

参考来源

• Anthropic / Claude 官方文章：The AI-Native SDLC playbook，重点参见 “Stage 1 — Plan” 与 “Capture as intent.md”，核验日期：2026-08-26。
• Claude 官方文档：Extend Claude with skills，用于核验可复用流程如何封装为 Skill，核验日期：2026-08-26。