アリババエンジニア、AI コーディングの環境・検証駆動への転換を提言

吴佐衍 2026 年 7 月 31 日 18:18 浙江

关于如何利用 AI 提升代码研发效率，本文或许能提供一些经验与思考。

这是 2026 年的第 46 篇文章。

（本文阅读时间：约 15 分钟）

最近我观察到一种现象：许多人在着手利用 AI 提升研发效率时，第一反应是将现有的研发流程进行“工作流化”，试图让 AI 在每个环节都发挥作用。这条路径确实具有现实意义，但我认为它并非 AI Coding 的终极形态。撰写本文旨在分享我对 AI Coding 的理解与判断，欢迎批评指正。

01

编码正在被逐步解决

过去一年多里，SOTA（State-of-the-Art）模型在各类代码评测基准上接连刷新纪录。无论是 HumanEval、LiveCodeBench，还是 SWE-bench Verified，均已被攻克；即便是难度更高的 SWE-bench Pro 和 Terminal-Bench 2.1，得分也已逼近 80%。

主流模型的代码能力评测成绩（2026 年 7 月快照，数据来源口径不一，仅供参考）：

55.4%

—

67.9%

公式版性能上限；Max 为推理档位

无论是查阅官方技术报告还是独立测试结果，头部厂商的得分均已进入高分段，分数差距已小于评测口径的差异。Claude Code 的作者 Boris 曾断言“编码问题已被解决”，单看基准测试数据，这句话基本成立。我们内部的数据也在印证同一趋势：团队中 AI 生成的代码占比正在快速提升。

02

为何效率未能同步跃升

既然模型的编程能力突飞猛进，我们的研发效率是否也跟上来了？至少从目前来看，答案是否定的。以我个人的经历为例：一个针对 C 端用户动线的改造需求，仅涉及终端改码和本地验证，1 小时即可完成；但要让它在线上生效，则需关联多个内部平台进行发布，恰逢 618 大促封网——这个需求从编码完成到真正上线，实际耗时达 3 周。

据我们团队内部的粗略统计，代码生成在整个研发链路中仅占 20%~30%，甚至可能更少。阿姆达尔定律（Amdahl's Law）告诉我们：将一个占比三成的环节压缩至接近零，整条链路的性能提升上限也仅为三成。随着编码问题被解决得越彻底，非编码部分便成为新的瓶颈。

阿姆达尔定律是计算机科学中用于评估系统优化或并行计算效果的核心法则。它指出：系统整体的性能提升受限于程序中无法被优化的串行部分。即使将某一部分的执行速度提升至无限快，整体性能的提升依然存在上限。

此外还有两个常被提及的原因：一是大模型基于公开语料训练，天然缺乏我们的业务领域知识；二是基准测试分数高，并不等同于在生产环境下能直接高质量完成任务。这两点固然成立，但请注意——它们与上述案例指向同一个方向：瓶颈不在编码本身，而在编码之外的其他环节。

03

诊断：可验证的反馈——AI 的能力边界

为何偏偏是“编码”最先被解决？表面的答案在于它拥有海量公开代码、公开 Issue 和公开评测；更深层的规律则是：AI 总是优先攻克那些反馈公开、验证可规模化的问题。编程和数学之所以率先取得突破，并非因为它们简单，而是因为它们是少数几个“对错机器自己能判定”的领域：编译是否通过、测试是否通过，跑一下便知。而在企业级生产环境中，答案往往藏在内部各个研发系统里，既无公开反馈，单次验证的成本也极高。

这一规律揭示了一个关键结论：既然 AI 的能力边界由“可验证的反馈”所决定，我们的应对策略应是主动将内部研发工作流改造成“有反馈、可验证”的环境。

1992 年，Jack Reeves 在《Code as Design》一文中提出过一个判断：源代码才是软件真正的设计，文档仅是设计过程中的摘要，天然会丢失信息。这一判断在 AI 时代有了新解：生成代码的速度将快到近乎免费，但真正的挑战在于如何将模糊的业务意图转化为完整、精确且可运行的表达，并验证其是否真的符合预期。

编码问题正在被解决，这恰恰意味着“让 AI 更擅长写代码”已不再是我们的主战场。我们的主战场在于验证与环境。

04

历史的快照：电力取代蒸汽机

技術革命の歴史を振り返れば、電気化時代にはまず各工場が蒸気機関から発電機へと切り替えることから始まりました。しかし、伝動軸の配置はそのまま維持されました。このアプローチはプロジェクト立项が容易で即効性があり、チームが電力と協働する感覚を蓄積させるのに役立ちました。

19 世紀末の工場は蒸気機関や水車を中心に設計されていました。大型動力機が建屋全体に伸びる伝動軸を回し、そこからベルトや滑車を介して各機械へ動力が伝えられていたのです。機械は伝動軸に沿って並べられ、生産システムの空間配置、作業順序、管理手法すべてが「どのように動力を伝えるか」という点によって決定されていました。

電動機が登場しても、多くの工場は建て替えを行わず、蒸気機関を大型の電動機に置き換えるだけで済ませました。既存の伝動軸やベルトを引き続き使用し、動力源として機能させたのです。この手法は「電力軸伝動」や「グループドライブ」と呼ばれています。エネルギー源は変わりましたが、工場レイアウト、機械の配置、生産プロセスは基本的に不変でした。旧システムに存在したエネルギー損失、設備全体の連動性、一部故障が広範囲の停止を招くといった問題は解消されず、電力は単により便利な動力源となったに過ぎず、まだ生産システムを再構築する基盤にはなり得ていませんでした。

企業が直ちに改造を行わなかったのは、電気の潜在力を認識していなかったからではありません。既存資本への制約が壁となっていました。工場や設備、伝動軸、生産ラインは依然として使用可能であり、廃棄すれば巨額の資産損失を意味します。配線の変更、小型モーターの導入、機械の移設、生産組織の見直しには新たな投資と停止コストが必要でした。さらに当時の電力網のカバレッジは限定的で、電気料金や供給の安定性、小型モーターの性能、技術基準もまだ整備途上でした。そのため、1899 年から 1919 年にかけて、米国の製造業における機械動力に占める電気の割合は約 5% から 50% へと上昇しましたが、この普及にはおよそ 20 年を要しました。

真の変革は、企業が「ユニットドライブ（個別駆動）」を採用し始めた後に起こりました。各機械に独立したモーターを備え、伝動軸を中心に並べる必要がなくなったため、原材料の投入から加工、組立、完成品出力までの流れに合わせてレイアウトを再設計できるようになりました。工場は多層で狭く、荷重を支える伝動軸に依存していた建築から、より開放的な単層空間へと変化しました。これにより、コンベアベルトによる連続生産、クレーン設備、そして柔軟な資材搬送が可能となりました。電力がもたらした最大の恩恵は、蒸気機関と電動機の効率差そのものではなく、生産プロセス、工場構造、設備配置、管理制度の全体再構築にあります。米国製造業における生産性の顕著な向上も、これらの相補的な改造が普及し始めた 1920 年代に主に現れました。

では、AI をどう活用して開発ワークフローを再構築すべきでしょうか？

現在主流となっているのは、人間が設計した固定されたプロセスに AI を組み込むというアプローチです。PRD（製品要件定義）→ 要件の明確化 → 技術設計 → タスク分解 → コード生成 → テストという各段階で、AI を活用して局所的な効率向上を図ります。ただし、各工程間の品質検証や引き継ぎは依然として従来のフローに従っています。SDD や各種エージェントスキル、スーパーパワーといったプラグインも、本質的には同じ路線に属するものです。

このアプローチには構造的な天井があります。それは「人が AI をどう使うか」の最適化に過ぎず、「AI が環境をどう利用するか」は考慮されていません。各工程で人の承認を待ち、人間が描いたパイプラインに沿って流れる仕組みでは、AI は実際には枠組みの中に閉じ込められています。この方式は人間同士の協業と分工のために生まれたもので、それを Agent が守るべき実行順序として固定化しています。これは本質的に AI 時代におけるウォーターフォールモデルの再導入であり、「要件定義が完了すれば正しく」「設計レビューを通過すれば実現可能」「実装フェーズでは忠実に実行するだけ」という前提に立っています。

しかし実際の開発現場では、テスト失敗の原因は実装ミス、環境問題、データの不整合、アーキテクチャの誤った仮定、あるいは要件理解のズレなど、どの層でも発生し得ます。もし失敗が起きるたびに設計に戻ってコードを再生成すれば、すでに正しいと判断された部分まですべて無効にしてしまうことになります。さらに Jack Reeves の「コードこそが設計である」という考え方に従えば、技術的な設計書そのものがコードと等価であるとは限りません。

もう一つの道筋は Agentic（自律型）アプローチです。Agentic の本質は「AI が意思決定を主導すること」ではなく、「AI が検証信号を自主的に取得できるか」という点にあります。各ステップで人間が正誤を判断する必要はありません。この路線ではワークフローが消えるわけではありません。むしろ、本来あるべき位置に退きます：スケジューリング、権限管理、状態保存、監査、そして高リスクチェックのための仕組みです。

電気化における真の飛躍は、発電機を交換することではありません。重要なのは「ユニット駆動」への転換です。各作業場が中央伝動軸から解放され、独立して稼働する能力を得ること。私たちが目指すべきは、コーディングという工程をまず独立して回し始めることです。

06

モデルの能力溢れによる恩恵をどう受け取るか——私たちは何を賭けているのか

どちらのアプローチを選ぶかは、日常業務における投資判断に帰着します。AI 関連へのあらゆる投入について、一つの問いで考えられます。

「次世代の SOTA モデルが発表された時、私が今取り組んでいることは、恩恵を受けるものになるか、それとも無意味なものになるか？」

この基準に基づけば、投資は二つのカテゴリに分類できます。

価値減衰領域：「生成能力」に焦点を当てた投入。モデルのファインチューニングによるコード生成品質の向上、プロンプトテクニックの蓄積、生成プロセスの細やかな調整などです。過去一年で繰り返されたのは、「昨日までの足場が、今日にはモデルの標準機能として組み込まれてしまう」というシナリオでした。この路線への投資は、モデルベンダーとの軍拡競争に賭けるようなものです。

価値増幅領域：「環境と検証」に焦点を当てた投入。企業内のビルド、デプロイ、テスト、データ管理、API、ログ、モニタリング、リリースパイプラインなどを、AI が呼び出せるツールとして整備することです。この作業を他社が代行することはなく、むしろモデルが強力になるほど、これらの資産の価値は高まります。同じ環境でも、より強力なモデルであれば、より深く、より長い自律的なループを実現できるからです。

価値減衰と価値増幅の境界線は、「プロセス調整」か「環境整備」という言葉の違いにあるのではなく、モデル能力との関係性にかかっています。

モデルの推論能力を代替または補完するもの——ステップの分解、プロンプト設計、プロセスの調整など——は、モデルベンダーが次世代モデルを訓練する際にも同様の領域で学習しているため、次のバージョンアップですぐに吸収されてしまいます。

一方、モデル自身では生成できない情報を提供するもの——内部システムの実際の状態、ビルド結果、ログ、テストフィードバックなど——は継続的に価値を増し続けます。なぜなら、世界に関する情報は世界からしか得られず、重み（パラメータ）の中から生まれるものではないからです。

なぜ環境への投資は価値を増し続けるのに、生成モデルへの投入だけでは不十分なのか。これを理解する簡単な関係式があります。

企業が AI から得られる恩恵は、「モデルの能力」と「環境の成熟度」の積（掛け算）で表されます。足し算ではありません。モデルは外部から借りてくる要素であり、ベンダーのペースに合わせて自動的に向上します。一方、環境は自社が構築する固有の要素です。これは自前で作り上げるしかなく、一度築けば価値は下がることなく積み上がっていきます。

この「掛け算」には2つの重要な意味があります。第一に、どちらかの値がゼロなら結果もゼロになることです。どんなに強力なモデルでも、自社の環境に組み込まれなければ生産性はゼロです。第二に、モデルが世代ごとに強化されるたびに、既存の環境の価値が何倍にも拡大される点です。

ワークフロー化による効果は線形的です。既存のプロセスに一定の効率化を足し算するだけだからです。しかし、環境への投資は複利効果をもたらします。なぜなら、それが掛け算の式の中で「乗数」として機能しているからです。

したがって私の主張はこうです。「AI がコードを生成する能力をいかに高めるか」という軍拡競争には参加せず、自社の内部環境を整備しツール化することに注力すべきです。これはモデル関連の業務をすべて放棄せよという意味ではありません。モデルの選定、評価、コンテキストの接続などは当然行うべきですが、その判断基準は上記の関係式にあります。

07 環境とツールこそが Agent の核心インフラ

業務ドメイン知識の構築

業務領域固有のスキル（SKILL）や、オントロジーベースのナレッジベースの構築などです。

再現可能で呼び出し可能な開発環境

Agent がプロジェクトを独立して構築し、サービスを起動し、データを準備し、API を呼び出し、ブラウザやアプリを操作し、ログやトレースチェーンを確認し、監視メトリクスを読み取れるようにすることです。本質的には、「人間にしか操作できない内部システム」を「AI が呼び出せるツール」へと翻訳する作業です。

階層化された検証体系

秒単位でフィードバックが得られるもの（コンパイル、型チェック、単体テスト）は、高頻度な自律的な反復に適しています。分単位でフィードバックが得られるもの（結合テスト、契約テスト、ブラウザ自動化）は、より現実的な動作をカバーします。そして、機械が信頼性を持って判断できない部分——ビジネス上の価値、ユーザー体験、倫理的な境界線——のみを人の判断に委ねます。

エンドツーエンドの開発システム連携

開発プロセスには一連のシステムが関与しています。これらを AI フレンドリーなモードへと改造する必要があります。具体的には、リリースプラットフォームや実験プラットフォーム、監視プラットフォームなどが該当します。

仕様と技術設計書の新しい書き方

「制約」と「仮説」を明確に区別します。「データはドメイン外に出さない」「API は後方互換性を保つ必要がある」「遅延は閾値を超えてはならない」といったものは制約です。これらは長期保存し、可能な限り自動でチェックすべきものです。一方、「マイクロサービスかモノリスか」「どのキャッシュ戦略を採用するか」などは検証が必要な仮説です。AI には、実装や運用中のフィードバックに基づいて自ら調整する余地を与えます。

仕様は「何が正解か」という境界線を定めるものであり、実現方法まで規定するものではありません。

最後に、自社の事例という「スズメ」を解剖してみましょう。コーディングに要する時間が1時間しかない場合、クロスプラットフォームへの影響分析、連携環境の構築、リリースオーケストレーション、グレーディング検証、封鎖期間中のコンプライアンスチェックといった工程のツール化こそが、コーディングプロセスをさらに圧縮するよりもはるかに大きな価値をもたらします。

注：本記事は著者の個人的な技術的考察と経験の共有であり、所属企業の公式見解や立場を代表するものではありません。文中の一部の議論には技術動向や発展方向に関する先見的な判断が含まれていますが、これらは執筆時点での著者の認識と経験に基づいたものです。すべての内容は交流と参考のためのものであり、読者は自らの状況に合わせて独立して評価を行う必要があります。

コメント欄で一緒に議論しましょう。

WeChat で開くにはこちらへ