工具与软件开发
已有项目代码审查与 Bug 修复
先复现问题，再诊断或修复限定范围的代码缺陷。
- 适合
- 需要定位/修复已有项目某个问题时选择；新增功能选 现有项目的限定功能开发。
- 工作范围单位
- 一个可定位/复现的问题及目标环境
- 可能的交付形式
- 仅诊断：报告与复现／受阻证据；获准修复后：客户仓库 Patch／PR 与回归记录
你提供 · 你会收到
需要你提供
- 最小复现步骤、预期与实际
- 指定 repo/代码包及合法访问授权
- 本地运行/测试依赖、目标分支、CI 约束
可以先说明你已有的材料，缺少的信息可在确认范围时补充。正式执行前，会根据具体任务确认必要的材料、使用权限及执行条件。
分两步进行
第一步 · 诊断
诊断订单先交付报告：复现步骤和结果或受阻证据、已观察到的发现与待验证假设、修复可行性、建议范围，以及可选的修复报价。无法复现时明确保留不确定性。
可能交付什么
- 复现／受阻证据、发现与假设、修复可行性和建议范围报告，可附修复报价
诊断本身可以是一份完整订单。
你决定是否继续
第二步 · 获准后实施
在客户有限授权的仓库／环境中确认复现和修复范围后，只有客户批准修复才交付限定 Patch／PR、实际回归记录与剩余风险；合并由客户控制，不默认发布生产。
可能交付什么
- 客户控制仓库中的限定 Patch／PR、实际测试命令与回归结果
另行确定范围与报价。
两步都适用诊断／修复均说明未测部分、剩余不确定性及适用的访问移交／回收记录
第三方费用付费依赖、测试／云资源、第三方 API 与模型运行费用不包含在诊断或修复交付费内，使用前另行确认。
重点核查仅诊断以报告、复现／受阻证据、发现与假设、可行性及建议范围验收；只有另行批准的修复才要求 Patch／PR 与实际回归记录，合并由客户控制。
可核查的验收 · 3
- 第一步 · 诊断客户收到报告，能分清实际观察、待验证根因和修复可行性；无法复现时有阻塞证据与下一步条件
- 第一步 · 诊断仅诊断的验收不要求代码修改；修复范围和报价由客户另行确认
- 第二步 · 获准后实施交付限定 Patch／PR，按原复现场景及约定回归用例复测，说明剩余风险；合并由客户控制
假设 Brief 与输出结构
示例 · 假设
说明性假设示例，非已完成的客户订单
示例请求
表单在填写特定字段后提交报错，请先复现并判断能否修复。
示例成果文件
diagnosis.md复现／受阻证据、发现与假设、可行性和建议范围fix.patch / PR仅在另行批准修复后交付test-log.md诊断复现记录；获准修复后补充实际回归证据
文件名仅为示意
其他同类需求示例
- 现有报表导出有时会得到空文件，请先找出可复现的输入条件，再判断是否能修复。
输出结构/测试路径
诊断：给定输入 → 尝试复现 → 记录错误或阻塞 → 说明发现／推测与可行性；获准修复后重复原用例并记录回归。
重要边界
私有 Repo 需有限授权；先诊断复现再报价修复，未经许可不得公开或部署。
默认不包含
- 无复现承诺包修
- 未经批准合并主分支/上线
- 私有代码公开、代客户支付生产资源
影响报价的因素
先约定诊断报告的范围与价格；客户确认后才另行报价并实施修复。诊断不保证可修复，也不等于完整代码质量保证。
真实项目参考
Roleward ↗
AI 产品（自有项目）
验证工作流/产品实践；不代表市场成功或客户交付记录。
自有项目与公开作品证明相关实践，不代表付费客户交付记录，也不保证本次任务结果。
