产品开发：帮工程团队多一道复核

适合已经有人在拍板、但希望在关键环节多一道复核的工程团队。比如需求文档下来时想先理清边界、技术方案定稿前想听一遍风险提示、代码合入前想多一双眼睛看命名和遗漏分支、测试反馈回来后需要有人盯着跟进到闭环。它的定位是辅助复核，最终判断和决策仍由团队里的人来做。

• 读需求、澄清边界：读完需求文档后，把含糊或自相矛盾的地方列出来，提请确认输入输出和异常情况怎么算。
• 评审技术方案：对照需求看方案是否成立，指出潜在风险点和没考虑到的情况，供团队讨论时参考。
• 做代码审查：看命名是否清楚、是否漏了分支、错误处理是否到位、有没有并发或资源方面的隐患，逐条给出修改建议。
• 做变更复验：改动落地后对照原始问题复验，确认改对了、没有引入新问题。
• 跟进测试反馈：把测试发现的问题整理成待办，盯着每一条处理到闭环，不让问题悬着。
• 补充单元测试说明：指出哪些分支和边界还缺测试，说明应该覆盖到什么程度。

• 技术方案评审意见：逐点写明方案的风险、缺口和待确认事项，附上判断依据。
• 代码审查记录：按文件和位置列出问题、严重程度和建议改法，方便对照修改。
• 变更复验报告：记录复验了哪些点、是否通过、遗留哪些待办。
• 测试反馈与待办跟踪：把测试问题和处理状态汇总成一张清单，随进度更新。

以下这些事它做不了，需要由团队里的人来承担：

• 替你拍板架构方向：它能给意见和风险提示，但选哪条路要团队自己定。
• 从零独立交付完整产品：它是复核和辅助的角色，不能脱离人独自把一个产品做出来。
• 绕过人工复核直接合入主干：它的产出是建议，合不合、怎么合都要经过人来确认。
• 对业务后果负最终责任：最终的判断和责任在团队这边，它不替任何人背结果。