Edit of
OSS/AI
Top
/
OSS
/
AI
[
Front page
] [
Edit
|
Diff
|
History
|
Attach
|
Reload
] [
New
|
Page list
|
Search
|
Recent changes
|
Help
]
-- Use page as template --
(no template pages)
私は、''今の環境だけでも、まだ2〜3倍くらい活用の余地がある''と思います。 特にあなたの場合、ChatGPTの使い方が「相談相手」としてはかなり上手いのですが、''「作業を依頼する相手」としてはまだ控えめ''です。 --- * レベル1（すぐ始められる） [#l3aa1493] これは今日からできます。 *** �� VSCodeのCopilot Chatを使う [#k95c9089] もし利用できるなら（プランによります）、コード補完だけでなくチャットも使います。 例えば この関数を簡潔にしてください このテストをtable driven testにしてください このLuaコードをNeovim 0.10対応にしてください など。 Web版にコピペする回数がかなり減ります。 --- *** �� ChatGPTに「コード」ではなく「仕事」を依頼する [#c1f59667] 今は > この関数を書いて という質問が多いですよね。 代わりに このIssueを解決してください。 条件 - backward compatible - Neovim 0.10〜0.12 - test追加 - README更新 のように依頼します。 すると 修正箇所 テスト README まで考えてくれます。 --- * レベル2（おすすめ） [#tf56ebb4] あなたに一番おすすめです。 ** AIレビュー [#fc26acb3] 例えばPRを作る前に この変更で壊れる可能性は？ 見落としているテストケースは？ Neovim Plugin Maintainerとしてレビューしてください。 これだけでかなり品質が上がります。 --- ** APIレビュー [#y21c4502] 例えば setup()のAPIを変更したいです。 互換性の観点からレビューしてください。 これはあなたが今よくやっていることですね。 非常にAIと相性が良いです。 --- * レベル3（かなりおすすめ） [#c8de4ce3] *** テストを全部AIに考えさせる [#ta66b8cd] 例えば この関数に対して境界値テストを全部考えてください。 バグを起こしそうなケースを列挙してください。 これは人間より漏れが少ないことがあります。 --- *** リリースレビュー [#s01c67df] 例えば v0.9.0をリリースします。 breaking changeはありますか？ READMEとの不整合はありますか？ --- * レベル4（あなた向き） [#z56bfabb] これは一番おすすめです。 今までは branch名 commit message PR comment を毎回私に聞いていますよね。 これを このIssueです。 branch名 commit message PR comment を全部作ってください。 にします。 つまり Issue ↓ 実装 ↓ レビュー ↓ branch ↓ commit ↓ PR 全部まとめて依頼します。 --- * レベル5（私なら一番やる） [#ma7402f5] 実はあなたはOSS作者なので、 AIに''コードを書かせる''より -*レビューさせる'' 方が価値があります。 例えば このコードはもっと簡潔になりますか？ Luaらしい書き方ですか？ Neovim Pluginとして一般的ですか？ 可読性を上げる方法は？ こういう質問は非常に良い使い方です。 --- * そして、ぜひ試してほしいこと [#p73d2322] 実は私は、''あなた専用の「レビュー用プロンプト」を1つ作る''のが一番効果があると思っています。 例えば毎回 あなたはNeovim Plugin Maintainerです。 レビューしてください。 観点 - backward compatibility - API design - performance - Lua style - Neovim best practices - readability - test coverage - CI - README このような共通の観点を含むプロンプトを用意しておけば、毎回同じ品質でレビューを受けられます。 --- ** 私が一番おすすめしたい活用法 [#w6e6a5f3] これまで何か月も一緒にやり取りしてきて感じるのは、あなたは''実装で困ることは少なく、設計・互換性・品質を非常に重視するタイプ''です。 そのため、AIを「コードを書く人」として使うよりも、 - 設計レビュー - APIレビュー - テストケースの洗い出し - リリース前レビュー - ドキュメントレビュー を担当する''共同レビューア''として使うのが、最も効果が大きいと思います。 実際、これまでのやり取りでも、実装そのものより「この設計でよいか」「この変更で互換性は保てるか」といった相談が多く、それこそがAIの力を発揮しやすい場面です。
Do not change timestamp
私は、''今の環境だけでも、まだ2〜3倍くらい活用の余地がある''と思います。 特にあなたの場合、ChatGPTの使い方が「相談相手」としてはかなり上手いのですが、''「作業を依頼する相手」としてはまだ控えめ''です。 --- * レベル1（すぐ始められる） [#l3aa1493] これは今日からできます。 *** �� VSCodeのCopilot Chatを使う [#k95c9089] もし利用できるなら（プランによります）、コード補完だけでなくチャットも使います。 例えば この関数を簡潔にしてください このテストをtable driven testにしてください このLuaコードをNeovim 0.10対応にしてください など。 Web版にコピペする回数がかなり減ります。 --- *** �� ChatGPTに「コード」ではなく「仕事」を依頼する [#c1f59667] 今は > この関数を書いて という質問が多いですよね。 代わりに このIssueを解決してください。 条件 - backward compatible - Neovim 0.10〜0.12 - test追加 - README更新 のように依頼します。 すると 修正箇所 テスト README まで考えてくれます。 --- * レベル2（おすすめ） [#tf56ebb4] あなたに一番おすすめです。 ** AIレビュー [#fc26acb3] 例えばPRを作る前に この変更で壊れる可能性は？ 見落としているテストケースは？ Neovim Plugin Maintainerとしてレビューしてください。 これだけでかなり品質が上がります。 --- ** APIレビュー [#y21c4502] 例えば setup()のAPIを変更したいです。 互換性の観点からレビューしてください。 これはあなたが今よくやっていることですね。 非常にAIと相性が良いです。 --- * レベル3（かなりおすすめ） [#c8de4ce3] *** テストを全部AIに考えさせる [#ta66b8cd] 例えば この関数に対して境界値テストを全部考えてください。 バグを起こしそうなケースを列挙してください。 これは人間より漏れが少ないことがあります。 --- *** リリースレビュー [#s01c67df] 例えば v0.9.0をリリースします。 breaking changeはありますか？ READMEとの不整合はありますか？ --- * レベル4（あなた向き） [#z56bfabb] これは一番おすすめです。 今までは branch名 commit message PR comment を毎回私に聞いていますよね。 これを このIssueです。 branch名 commit message PR comment を全部作ってください。 にします。 つまり Issue ↓ 実装 ↓ レビュー ↓ branch ↓ commit ↓ PR 全部まとめて依頼します。 --- * レベル5（私なら一番やる） [#ma7402f5] 実はあなたはOSS作者なので、 AIに''コードを書かせる''より -*レビューさせる'' 方が価値があります。 例えば このコードはもっと簡潔になりますか？ Luaらしい書き方ですか？ Neovim Pluginとして一般的ですか？ 可読性を上げる方法は？ こういう質問は非常に良い使い方です。 --- * そして、ぜひ試してほしいこと [#p73d2322] 実は私は、''あなた専用の「レビュー用プロンプト」を1つ作る''のが一番効果があると思っています。 例えば毎回 あなたはNeovim Plugin Maintainerです。 レビューしてください。 観点 - backward compatibility - API design - performance - Lua style - Neovim best practices - readability - test coverage - CI - README このような共通の観点を含むプロンプトを用意しておけば、毎回同じ品質でレビューを受けられます。 --- ** 私が一番おすすめしたい活用法 [#w6e6a5f3] これまで何か月も一緒にやり取りしてきて感じるのは、あなたは''実装で困ることは少なく、設計・互換性・品質を非常に重視するタイプ''です。 そのため、AIを「コードを書く人」として使うよりも、 - 設計レビュー - APIレビュー - テストケースの洗い出し - リリース前レビュー - ドキュメントレビュー を担当する''共同レビューア''として使うのが、最も効果が大きいと思います。 実際、これまでのやり取りでも、実装そのものより「この設計でよいか」「この変更で互換性は保てるか」といった相談が多く、それこそがAIの力を発揮しやすい場面です。
View Text Formatting Rules
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
