いつも使っているテクニックというわけでなく、開発チームの平和に貢献できればと、（もちろん自戒も込めて）今思いついたことです。
やさしさあふれるコメントでのご提案を歓迎します。
■間違っているのは私かもしれない系
勘違いだったらすみません
実際勘違いのことも（私は）多い。
私もあまり自信はないのですが
信頼性の高いサイトの記載を引いてこうありました、とか続く。
細かく追ってはいないので問題なかったらすみません
コードレビューにかけられる時間は限られている。
全レビューアが細かい仕様まで把握するのは現実的ではない。
Diff だけでレビューすることもあるでしょう。
■一理を認める系
どちらがいいと一概に言えませんが
前置きしたうえで、代替案のメリットはしっかり伝えた方がいいと思う。
～という観点からは、確かにこの方法がいいですね
～という観点からは～という方法がいいと思いましたが。
検討していただく。
■私も仲間系
私もよく間違えます
レビューイからリスペクトを得られていないと逆にいらだたせてしまうので注意。
これ紛らわしいですよね
軽く言語仕様やコンポーネントのせいにしてしまう。（ごめんなさい）
悩ましいですね
一緒に考える。
■質問でワンクッション系
こういう案もあるかと思いましたが、いかがでしょう
指摘でなく提案。
どれだけ立場、技術力の差があっても、プログラマは自分の書いたコードに関して主導権を奪われたくはない。
このように実装された意図を教えていただいてもよろしいでしょうか
何か汲み取れなかった意図があるかもしれない。
指摘の精度を高めるためにも。
■プログラマの職人性を刺激系
これ実現できたらすごいですよね
燃える。
ここだけ直ればなお素晴らしいです
一般的には、先輩が後輩に。
どちらも解決できる、そんなうまい話はないですかね…
燃える。
■細かい指摘でいらだたせない系
[重要度：低]
実際に低くて受け入れられなくても大勢に影響はない場合。
重要なのに嘘をつく必要はない。
細かいところでたいへん恐縮ですが
本当に恐縮なことも多い。
あえて言うなら
基本的にはOK。
少し上からなので関係性に注意。
これくらいしか見つかりませんでした
ほかは完璧です！
ほかは問題ありませんでした
指摘を終えて最後に。