design-function

design-function

使用时机

• 仅被 design skill 显式调用

功能定义

• 功能是支撑场景达成目标所需的业务能力，应从外部可观测行为的视角描述系统“能够提供什么能力”。
• 功能必须可落地: 能够映射为「输入/输出 + 触发条件/前置条件 + 主要步骤 + 失败处理与补偿策略」。在后续设计阶段再明确由哪些组件/模块分别承担职责。
• 不得将“实现细节/代码结构”当作功能；不得将“接口清单”当作功能本身。

注意事项:

1. 将场景中的关键验收点映射到功能的外部可观测行为，确保每条功能都能回答:

• 触发条件/前置条件是什么
• 输入/输出是什么
• 主路径步骤是什么
• 关键失败处理与补偿策略是什么

1. 对识别出的功能集合做一致性校验，避免后续重复建设或边界漂移:

• 去重与合并: 不同场景下语义等价的功能应复用同一条功能（必要时通过“适用范围/约束条件”表达差异），避免同义重复。
• 粒度校准: 避免抽象过度（难以验证、无法落到可测试行为）或细节过度（陷入实现层设计/代码结构）；必要时对功能进行拆分或收敛，但保持其对外可观测性。
• 命名与术语对齐: 功能名称与描述使用 context.md 中已对齐的术语，避免同一概念多种叫法。

指令

步骤1: 明确输入与上下文

• 场景: 读取 FEATURE_DIR/spec.md 中的「场景」章节，明确本次需要支撑的业务目标与验收标准。
• 上下文文件: 优先读取 FEATURE_DIR/context.md，参考其中的:
  • 「相关功能文档」章节，作为既有功能的主要参考来源
  • 架构分析、可复用模式、术语对齐、约束和假设
  • 若 context_mode = evidence_first，优先消费 on_demand.scope、on_demand.traceability、on_demand.risks、on_demand.evidence_gaps

步骤2: 分析既有功能的变更

基于步骤1输入与上下文，按「功能定义」识别并产出本次变更涉及的全部功能条目（含INSERT/MODIFY/DELETE/REFER），作为后续步骤的范围基线。

动作类型定义:

• MODIFY: 业务意图要求对既有功能的输入/输出、约束条件、步骤、失败处理、适用范围等进行调整或细化。
• INSERT:
  • 理解既有功能，业务意图无法合理归属到任何既有功能条目，或现有功能的职责边界无法承载新增能力且保持可验证性。
  • 不存在既有功能时，则新增所需功能。
• DELETE: 业务意图明确要求移除既有功能，且删除具有明确业务必要性、风险可控（必须给出充分、可追溯的理由与影响说明）。
• REFER: 既有功能已充分覆盖当前业务意图，无需修改内容，但需建立引用关系以支持后续影响分析与可追溯性。

on-demand 功能消费规则（仅 evidence_first 模式）：

• 先从 on_demand.scope.direct_functions 和 on_demand.scope.indirect_functions 建立功能基线（白名单）。
• 通过 on_demand.traceability 将需求/场景映射到功能条目，优先判定 MODIFY/REFER，减少无依据 INSERT。
• 对每个功能条目，优先引用 ${DOC_DIR}/on-demand/functions/*.md 中可定位证据（入口、主流程、波及点、风险）。
• 未进入 scope 且无证据链支撑的功能，不得纳入主设计范围（避免 scope creep）。
• on_demand.risks / on_demand.evidence_gaps 要体现在功能的失败处理、补偿策略或假设说明中。

兼容规则（default 模式）：

• 若 context_mode = default 或 on_demand 字段缺失，沿用原有逻辑，不阻塞功能设计。

步骤3: 按照以下模板生成「功能」章节内容

## 功能

### [INSERT/MODIFY/DELETE/REFER] - [功能ID] - [功能名称]

**来源场景**: [场景ID] - [场景名称]

变更原因: [分析业务意图对存量功能的影响；REFER 填写为无变更]

**功能描述**: [从对应场景的验收场景中提取，描述该功能需要实现的具体能力]

[功能具体内容]

[按照上述格式继续描述其他功能...]