feedback-application

审查反馈实施

系统地处理并根据代码审查反馈实施更改。

适用场景

• 提供审阅者的评论或反馈
• 粘贴 PR 审查备注
• 提到要实施审查建议
• 表示“处理这些评论”或“实施反馈”
• 分享审阅者要求的更改列表

系统化工作流

1. 解析审阅者备注

识别各项反馈：

• 拆分编号列表（1.、2. 等）
• 处理项目符号或未编号的反馈
• 提取不同的更改请求
• 开始前澄清含糊的事项

2. 创建待办事项列表

使用 TodoWrite 工具创建可执行的任务：

• 每项反馈对应一个或多个待办事项
• 将复杂反馈拆分为更小的任务
• 确保任务具体且可衡量
• 开始前将第一项任务标记为 in_progress

示例：

- Add type hints to extract function
- Fix duplicate tag detection logic
- Update docstring in chain.py
- Add unit test for edge case

3. 系统地实施更改

对于每项待办事项：

定位相关代码：

• 使用 Grep 搜索函数/类
• 使用 Glob 按模式查找文件
• 阅读当前实现

进行更改：

• 使用 Edit 工具进行修改
• 遵循项目约定（CLAUDE.md）
• 除非要改变行为，否则保留现有功能

验证更改：

• 检查语法是否正确
• 视情况运行相关测试
• 确保更改符合审阅者的意图

更新状态：

• 完成后立即将待办事项标记为 completed
• 继续处理下一项待办事项（同一时间只能有一项处于 in_progress 状态）

4. 处理不同类型的反馈

代码更改：

• 使用 Edit 工具修改现有代码
• 遵循类型提示约定（PEP 604/585）
• 保持风格一致

新功能：

• 必要时使用 Write 工具创建新文件
• 添加相应的测试
• 更新文档

文档：

• 按照项目风格更新文档字符串
• 按需修改 Markdown 文件
• 保持说明简洁

测试：

• 将测试编写为函数，而不是类
• 使用描述性名称
• 遵循 pytest 约定

重构：

• 保留功能
• 改进代码结构
• 运行测试以确认没有回归

5. 验证

实施更改后：

• 运行受影响的测试
• 检查 lint 错误：uv run ruff check
• 确认更改不会破坏现有功能

6. 沟通

及时告知用户进展：

• 实时更新待办事项列表
• 针对含糊的反馈请求澄清
• 报告阻碍因素或挑战
• 完成后总结更改

边缘情况

反馈相互冲突：

• 向用户寻求指导
• 清楚说明冲突

需要进行破坏性更改：

• 实施前通知用户
• 讨论影响和替代方案

更改后测试失败：

• 修复测试后再将待办事项标记为完成
• 确保所有相关测试均通过

引用的代码不存在：

• 请求用户澄清
• 继续之前确认理解无误

重要指南

• 始终使用 TodoWrite 跟踪进度
• 每项完成后立即标记待办事项为完成
• 同一时间只能有一项待办事项处于 in_progress 状态
• 不要批量标记完成——实时更新状态
• 反馈不明确时提出问题
• 如果更改影响到已测试的代码，则运行测试
• 所有代码更改均遵循 CLAUDE.md 约定
• 之后创建提交时使用约定式提交