回复审查意见
通过在源代码的适当位置插入说明性注释来解决代码审查意见，记录设计原因，使未来的审查者不会再提出相同的疑问。
输入
根据对话上下文推断两个输入。仅在含义不明确时提问。
输入1 — 审查意见。
审查者的发现：通常是一个包含位置（文件:行号）和问题描述的表行。
该表格通常来自 dakubo-display-pr-remarks 或 dakubo-review-commit-range 技能。如果对话中没有表格，且上述技能可用，则使用该技能生成表格。否则，请用户提供审查意见。
输入2 — 解释。 开发者的回应：说明代码为何正确、其背后的设计决策、接受的权衡，或审查者忽略的全局背景。该解释无需直接反驳意见，只需转变审查者的视角。
流程
- 读取输入1中指定位置的文件。
- 确定审查意见所针对的具体代码结构（方法、代码块、字段、行）。
- 起草一条注释：
- 概括输入2的核心内容（原因/决策/上下文）。
- 简洁明了——最多1到4行。
- 不要提及审查者、PR或意见编号（注释的生命周期超过审查周期）。
- 不要重复代码已明确表达的内容——只添加阅读代码时无法直接看出的原因。
- 如果有助于解释更清晰，可选地针对意见的关注点进行说明。
- 将注释放在目标代码结构正上方，如果行内注释更自然，则放在行尾。
- 应用编辑。
输出
确认添加注释的文件和行号。一句话即可。
禁止事项
- 除非用户明确要求，否则不要重写代码。
- 不要编写仅复述代码功能的注释。
- 不要在注释中引用“审查者说……”或“PR #N”。
- 不要添加超过约4行的注释；如果需要更多解释，应将其放入设计文档或提交信息中，而非行内注释。