Ajiang Feature

---
name: ajiang-feature
description: 开发新功能或改进已有功能：围绕用户要完成的操作实现，并从实际入口验证结果。
license: MIT
---

# 开发新功能

## 明确要做什么

把需求落成“什么人在什么条件下做什么动作，应观察到什么结果”。有现成失败、截图或参考实现时读取它；明确目标项目与参考材料的身份，防止把参考仓库改了。

读取项目规范、README 和相关脚本，确认修改范围，再从实际入口找现有链路和可复用模块；复用前检查其真实契约，不凭命名推断。需求不明确时先推进不依赖该信息的调查，再询问影响结果的关键差异。无须为每次小改写一份规格。

## 实现一条完整流程

优先打通一条完整用户路径：输入 → 状态/业务执行 → 实际输出，而非铺满所有抽象层再做演示。沿用现有栈和结构。记录必要行为与本次不涵盖的需求，不擅自扩展成平台重建。

对比可获得的参考实现时给出设计前提、值得复用的部分与应保留的现有能力；没有源码就只对可观察行为做判断。参考代码是证据，不意味着自动迁移其技术栈。

修改涉及配置、事件、provider、存储或进程边界时，从实际生产者跟到消费者，检查来源、优先级、缺失状态、错误传播和恢复行为，并用对应负向场景验证。触及支持语言、主题或平台时覆盖相应变化；项目不支持的能力不因本流程变成新需求。

## 验证用户结果

从项目真实入口执行最小用户任务，检查实际输出或持久化状态。按改动加入关键失败或边界场景，运行现有相关检查。开始时已失败的检查记录为基线，不能把它们静默忽略或归因于本次代码。

本次改动涉及外部服务时，验证请求、返回和实际消费者之间的行为。无法访问服务时完成内部检查，并注明尚未验证的外部行为。检查不会抓住错误实现时，改进断言。

本次新增问题必须处理，无关旧问题记录后续。复杂/高影响变化或用户要求独立 review 时，给独立审查者任务、验收、目标版本和原始事实，不附预设结论；每条发现必须有触发条件与实际后果，逐条核验后再修复。普通小修改可直接交付。

## 完成与连续迭代

功能合入目标分支后，按同一用户路径复测，确认最终集成状态仍满足验收。

下一轮或另一会话接手时保留：用户结果、当前版本、有效配置、已验证内容、已排除假设的适用条件、剩余问题及允许的下一步。

需要多轮迭代或交接时，可按 [功能开发记录](assets/task-record.md) 保存目标、实现路径、验收和下一步。