プロジェクト概要#

これは、curosr が商品詳細フロントエンドアプリケーションの理解に基づいて描画した SVG 形式の画像です（curosr は描画をサポートしていないため）。

全体としては、プロジェクトの状況、プロジェクト構造、技術選定、およびいくつかのサブパッケージの役割を大まかに記述しています。しかし、画像全体には詳細において多くの問題があり、テキストのはみ出し、重なり、配置の問題など、AI に何度も修正を要求しても改善されませんでした。これが、合理的な費用対効果の範囲内で AI が生成できる最良の結果であり、まあまあといったところです。

cursor エディタ自体の実践#

具体的なモデルの指定#

auto モードは使用せず、オフにして claude-4 を指定してください。現在のテストでは効果が良いです。デフォルトの auto モデルを使用すると、回答の品質が非常に不安定になります。

curosr rule の実践#

10のフレーズでcursorのプログラミングスキルを10倍に向上させる（冗談）

基本的な回答品質の向上#

これは以前どこかの記事で見た cursor rule riper-5 で、実践してみて良かったのでずっと使っています。

全体のガイドフローは以下の通りです。

実際に使用してみると、AI はこの指示の順方向のプロセスに非常によく従いますが、逸脱や問題が見つかった場合に前のステップに戻るような逆方向のプロセスについては、実際に使用した限りでは一度もそのステップに進んだことがありませんでした。AI は毎回非常に自信満々で、最終的なレビューは完璧、素晴らしいといった自己肯定的なフィードバックばかりでした。たとえ非常に愚かな問題であっても、AI 自身が自分の問題を発見することは一度もなく、人為的な介入が不可欠でした。
- 例えばこの例では、AI の回答は非常に高品質に見え、図とテキストが豊富で、まるでプロフェッショナルのようですが、実際には AI 自身が描いた画像に含まれる機能、例えば totalPrice の計算や quantity の計算などの関連ロジックはすべて欠落しています。したがって、表面的なものに騙されてはいけません。

しかし、全体的に実践してみると、日常的な機能開発において回答の品質を大幅に向上させることができ、時にはコードを書いてくれなくても、思考プロセスや複数の参考案は参考にできます。

ただし、あまりにもシンプルな要件に対しては、回答プロセスが冗長すぎる場合があり、最初から最適な答えが出せるような状況でも遠回りをしてしまうことがあります。

コードリファクタリングレビュー#

コードリファクタリングレビューのルール

技術リファクタリングコードレビューガイド（Git Diff）

私はフロントエンド開発者です。Git
Diff のレビューをお願いします。以下の技術チェックリストに従って、詳細な分析レポートを提供してください。

チェックリスト

一、コードの構成と構造の調整

コードの構成、アーキテクチャ、命名レベルの調整のみであるかを判断してください。具体的には以下を含みますが、これらに限定されません。

関数、メソッド、または変数の名前の調整
ファイルまたはディレクトリ構造の変更（例：ファイルの分割または結合）
ロジックが異なる関数やファイルに分割または結合されたが、入力、出力、プロセスは変更なし
コメントの追加または改善、ロジックの変更なし
廃止されたコードの削除、既存のプロセスに影響なし

二、ビジネスロジックの潜在的な変更

変更がビジネスロジックまたは機能に影響を与えるかどうかを詳細に確認してください。以下を含みますが、これらに限定されません。

入力パラメータの型、数、デフォルト値が変更されたか
関数またはメソッドの戻り値の型または構造が変更されたか
制御フロー（条件分岐、ループ構造など）に論理的な変更があったか
データ処理、計算方法、または主要なアルゴリズムに調整があったか
非同期呼び出し、APIリクエスト、または外部サービスへの依存ロジックに変更があったか
状態管理、キャッシュ、またはデータストレージロジックに変更があったか
ビジネス上重要な関数、メソッド、インターフェース、または外部依存が追加または削除されたか

出力フォーマット要件

以下のフォーマットでレビューレポートを出力してください。

概要結論

今回の変更全体が既存のビジネスロジックに影響を与える可能性があるかどうかを明確に記述してください。

組織、アーキテクチャのみの変更

構造的、組織的な調整のみであると確認されたものをすべてリストアップしてください。

ビジネスロジックに影響を与える可能性のある変更

コード変更箇所（ファイル名、行数、関数名または変数名）を明確に指摘してください。
変更の性質（例：パラメータ、戻り値、ロジックの変更）を詳細に記述してください。
考えられる影響とリスクを評価してください。

推奨事項とリスク管理策

ビジネスへの影響が疑われる場合は、ビジネスの安定性を確保するための推奨される対策（例：単体テスト、結合テスト、コードレビューなどの追加）を提供してください。

技術リファクタリングの安全性を確保するため、必ず詳細かつ項目ごとに確認し、判断の根拠となる十分な理由またはコードスニペットを提供してください。

比較的大きな変更があった後には、AIに何が変更されたのか、どの変更が既存のビジネスロジックに影響を与え、どれが与えないのかを要約させ、同時に全体的な評価を与え、回帰テストが必要かどうかなどを教えてもらいます。

実際の体験としては、大きなリファクタリングがあるたびに、私のコード変更に対して AI にこのプロンプトに基づいて異なるモデルで回答させます。そして、それが純粋なコードリファクタリングなのか、ビジネスロジックの変更の可能性があるのかをレビューします。実際に試したところ、かなり信頼性が高いです。異なる AI に回答させるのは、AI がでたらめを言って私を騙すのを避けるためのクロス検証です。

cursor mcp の実践#

現在使用している mcp は以下の通りです。

1 つは同僚が書いた Yuque mcp で、cursor に Yuque ドキュメントを読み取る機能を提供します。
もう 1 つはオープンソースの npm パッケージバージョン管理 mcp で、ページ全体の依存関係を管理するために使用します。

AI のために最適化された商品詳細フロントエンドアプリケーション#

cursor 自体の機能強化に加えて、商品詳細のフロントエンドアプリケーションに対しても、cursor 専用、あるいはより AI フレンドリーな改修を行いました。

Monorepo：各モジュールが完全に独立し、固定された API のみを公開することで、コード間の結合度を大幅に低減し、AI が一般的なフロントエンドアプリケーションよりもリポジトリ全体を理解しやすくする#

まず、Monorepo の機能を通じて、商品詳細のすべての依存プロジェクトを 1 つのアプリケーションにまとめ、孤立したアプリケーションの存在を回避しました。これにより、AI がプロジェクト全体を理解するための基盤が提供され、依存関係以外に AI が知らないコードは存在しません。

同時に、商品詳細のフロントエンドは複数回の改修を経ており、技術スタックはコミュニティ標準とほぼ完全に一致しており、Alibaba 内部のプライベートソリューションはほとんどありません。つまり、技術的には、すべての技術フレームワーク、コンポーネントライブラリ、およびソリューションは最新の AI モデルの固有の知識であり、AI が知らない Alibaba プライベート領域の知識は存在しません。

1 つのアプリケーションのすべての依存関係を 1 つのリポジトリに置くと、依存関係の混乱や過度な結合の問題が発生する可能性があります。そのため、最終的には Monorepo を通じて各サブパッケージ、サブアプリケーションを隔離し、統一された規範に従って相互作用させることで、AI がリポジトリ全体の動作メカニズムを理解するための基盤を築きました。

アトミック CSS を使用して CSS の複雑なスコープの問題を回避する#

tailwind css ソリューションを使用することで、技術的にすべてのスタイルが独立しており、互いに干渉しないスタイルであることを保証します。これにより、AI がスタイルコードを生成する際に、プロジェクト全体の複雑な CSS グローバルを理解する必要がなく、現在の部分の内容のみを考慮すればよくなります。

プロジェクトレベルの cursor rule#

商品詳細の特定のプロジェクト状況に合わせて、プロジェクト全体の devGuid を作成する#

参考ドキュメント：https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/project-rule.mdc

プロジェクトの構造、開発理念、および注意すべき内容を核として紹介します。

PC と WAP の異なる特性に合わせて異なる curosr rule を作成する#

大規模モデルのコンテキストが限られているため、プロジェクトレベルでは主要なルールのみを記述し、PC および WAP 開発時の異なるルールについては、globs: apps/wap/**/. alwaysApply: false の条件参照を通じて、特定のファイル変更にのみプロンプトが適用されるようにしています。

各独立したサブパッケージに README を作成し、AI が理解できるようにする#

特定の作業に合わせて特定の rule を作成する#

私は最近、M サイトのユーザー体験統一プロジェクトに取り組んでおり、古い WAP 詳細コードの移行とリファクタリングが含まれています。

その大部分の作業は商品詳細のモジュールの移行であり、App のスタイルと PC のデータに基づいて WAP のモジュールを移行し、同時に私たちのプロジェクト規範を厳守する必要があります。そのため、これ専用の rule を作成しました。https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/apps/wap/src/modules/wap_module_devGuide.mdc

内容の核は、私たちのモジュール開発規範と、プロジェクト内の既存のツールやメソッドを使用して作業を完了する方法を強調し、勝手に書き散らさないようにすることです。

eslint を通じて AI がアイソモルフィズムを破壊する問題を解決する#

アイソモルフィズムの問題：cursor rule と eslint を組み合わせることで、AI が生成するコードが可能な限りアイソモルフィズムを破壊しないようにします。

cursor rule による制約はありますが、AI が一直線に進むため、完全に保証することはできません。
eslint による制約は、AI の挙動を制約することができます。

swagger を通じてフロントエンドとバックエンドのフィールドプロトコルタイプを生成し、AI のでたらめな記述を制約する#

重要な内容：detail.backend.d.ts は、バックエンドインターフェースに基づいてフロントエンドが必要とする ts 型定義を生成します。また、私たちはバックエンドと商品詳細において swagger をフロントエンドとバックエンドのデータ連携ドキュメントとして導入しました。同時に、swagger で生成された openApi.json に基づいて、フロントエンドプロジェクトが必要とする ts 型定義ファイルを生成します。

これにより、AI がフロントエンドとバックエンドのデータ連携モデルを理解できない問題を解決し、AI がフロントエンドコードからデータモデル全体を理解する可能性を与えました。実際に試したところ、AI への貢献は非常に大きく、フィールド名からフィールドの意味を理解し、正しい場所で使用できるようになりました。もしバックエンドの同僚が swagger の仕様に従ってフィールドに詳細なドキュメントを記述できれば、さらに効果が向上する可能性があります。

swagger に基づくフロントエンドとバックエンドのインターフェース規約

単体テストを通じて AI が変更したコードにある程度の保証を与える#

商品詳細のビジネス特性上、フロントエンドには非常に複雑なデータ処理と計算が多く存在します。元々、AI を使用しない状況では経験豊富なフロントエンドの同僚が関与していたため、すべてのビジネスロジックと UI ロジックはプロジェクトの store に混在していました。ロジックを個別に抽出することは良い最適化ポイントですが、煩雑なビジネス要件の下ではその優先順位は上がりませんでした。

しかし、AI 支援によるフルスタック開発が必要になったため、フロントエンド経験のないバックエンドの同僚もフロントエンドアプリケーションの開発に参加することになりました。その結果、元々複雑で様々なロジックが混在していた store は、バックエンドの同僚にとって理解が難しく、AI がこの部分のコードを変更することに対しても不安がありました。そこで、WAP への改修時に、純粋なバックエンドのデータ処理ロジックや特定のビジネスロジックを独立したメソッドとして抽出し、store では単にそれらを呼び出すだけにしました。これにより、ほとんどの場合、これらのコードを変更する必要がなくなり、store の複雑さを劇的に下げることができ、バックエンドの同僚の参加も比較的容易になりました。

したがって、私たちの改修の方向性は、これらの比較的固定されたビジネスロジック処理関数を可能な限り分離し、独立したパッケージに集約することでした。抽出されたものはすべて純粋な関数であるため、単体テストを補完するのも比較的容易です。

このように改修した後、コアビジネスロジックは基本的に独立した biz-core パッケージに抽出され、上位の WAP & PC（改修中）の store は biz-core を呼び出すだけであり、通常はそれらの具体的なロジックを意識しません。

これにより、AI によるコード変更に制御不能な部分があったとしても、変更後のコードが単体テストをパスする限り、ビジネスロジックのリスクは基本的に制御可能となります。

store の複雑さを大幅に削減#

以下の図は、私たちのページの store の改修前後の比較です。一目でわかるように、それらの複雑さは大幅に簡素化されています。もちろん、WAP 側にはサンプルや物流モジュールがないため、ビジネスの複雑さが低いという理由も一部ありますが、通常品自体の複雑さも大幅に簡素化されました。これは AI がページ全体の状態を理解するのにも役立ちます。

以前：

以後：

実際の体験#

フロントエンドの AI 体験#

これは、約 3 週間の開発プロセスにおける、私が有意義だと感じた記録であり、参考としてのみ提供します。その中で、最も役立った 2 回は以下の通りです。

[mock データのモジュールを使用してタグ付け]：機能だけが必要で、実装には全く関心がなく、その後のメンテナンスにも全く関心がなく、頭を働かせたくもありませんでした。そのため、このような問題は AI に任せるのが非常に適しており、最終的に AI は私が望む内容を非常にうまく実現してくれました。
[店舗パフォーマンスのための画面録画最適化のためにバックエンドサポートが必要な要件]：店舗自体のレンダリングについて十分な理解があり、バックエンドの指示も加わり、AI の助けを借りて迅速に私が望むものを完成させることができました。非常に役立ち、1.5 日節約できました。

フルスタックの AI 体験#

AI 改修を終えた後、フルスタックの同僚が要件開発に参加するようになりましたが、実際に運用してみるとやはり役立っています。私たちのバックエンドの同僚は、AI の助けを借りて、簡単な要件を迅速に完了でき、少し複雑な要件でも時間をかければ最終的に完了できます。これにより、ゼロからイチを生み出す問題が解決され、状況によってはフロントエンドとバックエンドの同僚が迅速に役割を補完しビジネスをサポートできるようになりました。

しかし、依然としていくつかの問題が存在します。一部のスタイルの改修やコンポーネントの使用については、フロントエンドエンジニアリングへの理解度が比較的浅いため、cursor は様々な rule の制約下でも自由に振る舞い、コンポーネントを使うべきところで使わず、既存のメソッドがあるのにわざわざ自分で書くことがあります。しかし、フルスタックの同僚はこれらの問題をすぐには見抜けないため、ブラウザでこの部分の改修表示が OK かどうかを確認するしかなく、最終的に一部手戻りが発生します。

しかし、全体的に見れば、ある程度は人員の補完が可能です。

小結#

私の cursor 使用統計データでは、コード採用率は 40%〜60%程度と推定されますが、実際の効率向上は 15%〜25%の間であるはずです。このギャップの理由は以下の通りです。

統計上のコード採用率は、実際に最終的にメインブランチにマージされるコードよりもはるかに高くなります。なぜなら、AI が生成したコードを毎回詳細に確認する時間がなく、ほとんどの場合、コードにざっと目を通し、問題がなければそのまま accept して、期待通りの効果が得られるかを確認するからです。コードを採用するたびに、今回のガチャの成功可否をテストするようなもので、期待通りの結果が得られて初めて、そのコードを最終的にマージするか、修正してからマージします。実際のほとんどの状況では、同じ問題に対して 3 回から 5 回、あるいはそれ以上 accept した後、かろうじて使えるバージョンを提供し、それを修正してからマージするため、実際のコード採用率は 20%程度であるはずです。

まとめ#

フルスタック（関連する技術的背景がない場合）：他の技術スタックに迅速に切り替えて要件開発を行うことができますが、非常にシンプルな要件に限定されます。少し複雑な要件では、より長い時間をかけて基礎を固め、関連する技術スタックの基礎知識を学ぶことで初めて対応可能になります。しかし、特定の状況では効率を大幅に向上させることができます。
フロントエンド開発者自身：cursor が効率を向上させるという目的を持たずに使用する場合、効率向上の割合は約 10%〜20%の間です。cursor が必ずこれだけ効率を向上させると期待して使用する場合、全体的な効率向上は限定的です。
1. cursor 自体の AiTab 機能は非常に使いやすく、日常の開発において、いかなる環境サポートも必要とせずに約 5%〜10%の効率向上が可能です。
2. 一般的な UI 要件で、使い捨て（日次または月次）のコードであれば、直接 AI に任せることでリスクは制御可能であり、効率向上は良好です。
3. 最終的にリリースされない機能、例えば開発中に一時的なタグ付けスタイル機能など、最終的にリリースされない機能であれば、AI に全面的に任せることができます。最終的に私たちの本番コードを変更しない限り、複数回の対話の後には望む効果が得られ、効率向上は顕著です。
AI 利用におけるいくつかの落とし穴：複雑な問題に対して、直接 AI に書かせると、N 回の対話の後には確かに動作するコードが提供されるかもしれませんが、これ自体が落とし穴であり、以下の 2 つの側面があります。
1. 自分で直接書いた場合、AI に書かせた場合よりも時間がかからないかもしれません。しかし、AI と対話を続け、修正を繰り返す過程で、あなたの頭は働いているようで、完全に働いていない状態になります。最終的に動作するコードも、ブラックボックステストと目視による大まかなホワイトボックステストの結果に過ぎず、動作すると判断してリリースしようとします。なぜなら、開発時間はすでに費やされているからです。これは時間的な落とし穴であり、AI がコードを生成したように見えても、短期的には効率向上にはつながりません。
2. AI が生成した複雑な問題を解決するこのコードが、非常に独立したモジュールでない限り、このコードは純粋な負債となります。なぜなら、このコードを開発したあなた自身が、そのロジックを完全に理解していないからです。これは非常に恐ろしい状況です。このコードを生成する過程であなたは常に参加していましたが、あなたの頭は常に参加していたわけではないかもしれません。最終的にコードは動作するものの、なぜ動作するのかについては漠然とした概念しか持っていません。本当に問題が発生したり、機能を追加する必要がある場合、あなたはコード自体を完全に把握していません。この時、あなたは 2 つの選択肢に直面します。
  1. 以前 AI が生成したコードを完全に理解し、そのコードに基づいて機能を追加する。以前節約したとされる時間は再び費やされることになり、効率の面では、全体的に効率向上ではなく、低下することになります。
  2. 引き続き機能を AI に任せ、そのコードを基に修正させる。しかし、機能のイテレーションが進むにつれて、AI はこの状況を制御できなくなる可能性が高く、場当たり的な対応や、一つの問題を解決すると別の問題が発生するといった状況が始まり始めます。

結局のところ、最初は AI があなたの脳の負担を軽減したように見えても、実際には全体的に効率とプロジェクトの把握の両方において低下し、マイナスになります。したがって、複雑で多依存の機能については、AI による実装は推奨しません。強化すべき個人の能力は、モデルの限界を感知できることです。適切な場所で使い、不適切な場所では使わないことで、AI による向上は非常に大きくなります。そうでなければ、多くの場合マイナスになる可能性があります。

その他#

ATA の記事で言及されていた内容で、非常に役立つと感じたもの：

当写代码不再那么重要，程序员的能力要求必然发生变化。

**我们需要快速适应变化的能力** ：AI 技术发展日新月异，从开始写提示词调用大模型，再到模型微调和搭建工作流和智能体，到现在开始搞 MCP 等，从 DeepSeek-R1 、V3 到 DeepSeek-R1 0528 ，从 Claude 3.5 到 3.7 和 4 模型也在飞速发展。从 AI 只能写纯前端的“玩具”代码，到现在使用 Cursor 可以实现企业级的 AI Coding，也不过几个月甚至一两年的光景。

**我们需要更强的提出问题的能力** ：只有懂 AI ，又懂业务，才能发现问题，提出问题，进而解决问题。

**我们需要更强的任务拆解能力** ：能够感知模型边界，将任务拆解为大模型可以 Hold 住的粒度，才能更好地发挥出模型的效果。

**我们需要更强的架构设计的能力** ：代码不是资产，真正的资产是代码所实现的业务能力。每一行代码都需要维护、安全保障、调试和淘汰，本质上是负债。AI Coding 带来了提效，同时也带来了很多风险，技术债的积累，程序员编码能力退化等。新的 AI Coding 工具让程序员从基础的编码中解放出来，可以更专注于系统架构的设计。代码易得的时代，设计出复杂且连贯系统架构的人，比单纯会写代码的人更有价值。详情参见：[https://www.linkedin.com/posts/vbadhwar_sysadmins-devops-ai-activity-7333228313433227268-WNW4](https://www.linkedin.com/posts/vbadhwar_sysadmins-devops-ai-activity-7333228313433227268-WNW4?spm=ata.21736010.0.0.50de4238i2BGMr) （linkedin 帖子，需要开加速才能看）

**我们需要更强的需求理解能力** ： 快速理解需求，使用 AI 工具快速实现。

**我们需要更强的沟通表达能力** ：现在很多 AI Coding 团队反馈用户不懂如何提问。现在这个时代很多人说“提示词工程不重要了”，然而，很多特别好用的提示词依然需要精心设计。很多人并不能很好地表达需求，缺少输入，缺少明确的输出要求，任务粒度太粗，上下文不足等等问题非常突出。沟通表达能力不是人与人的沟通，还应该包括人与 AI 的沟通。随着 AI 能力的不断增强，我们的工作方式开始更多地和 AI 沟通，因此提示词工程，沟通表达能力非常重要。

**我们需要更强的批判性思维能力** ：AI 很容易出现幻觉，我们需要有能力评判出 AI 产出的内容是否正确。

**我们需要终身学习的能力** ：技术发展远比想象得更快，上面有一张图提到 60 岁程序“终身学习” 快速掌握新一代 AI Coding 工具，可以超越自己的能力限制，轻松编写代码。终身学习让人能够跟上时代发展的步伐，享受到时代发展的红利。值得庆幸的是， AI 的时代，学习成本进一步降低，可以创建各种有意思的智能体快速帮助我们学习和理解知识，已经是现在进行时。