研究核心观点 - Amplifying.ai对Claude Code的工具选择倾向进行了系统性研究，通过开放式提示词测试了3款模型在4种项目类型中对20个工具类别的选择行为，累计分析了2430次工具选择[1][2] - 研究旨在探究AI代码助手在未指定具体工具时的显性偏好，其结论不代表开发者真实偏好或工具质量评估[26] 实验设计与方法 - 研究搭建了4个全新的代码仓库进行测试，包括Next.js SaaS、Python API、React SPA和Node CLI项目[11] - 测试覆盖Claude Sonnet 4.5、Opus 4.5、Opus 4.6三款模型，每款模型独立运行三次，每条指令执行前均重置代码环境以确保纯净[11] - 针对20个工具类别设计了100条开放式指令，每条指令有5种不同措辞，共产生2430次成功响应[11][12] - 使用基于LLM的子智能体从每次响应中提取核心工具推荐，提取率为85.3%（2073次响应可识别出主要工具）[12][19] 工具选择核心倾向 - **强烈倾向自建方案**：Claude Code更倾向于自己编写自定义解决方案，而不是直接推荐第三方工具，自定义/DIY实现占所有主要选择的12%（2073次中的252次），成为最常见的选择[5][27] - **默认技术栈形成**：选择第三方工具时，会集中选择Vercel、PostgreSQL、Stripe、Tailwind CSS、shadcn/ui、pnpm、GitHub Actions、Sentry、Resend、Zustand等工具[6] - **技术栈专属选择**：根据不同技术栈选择专属工具，例如JS项目用Drizzle做ORM、Python项目用SQLModel做ORM；Next.js项目用NextAuth.js做认证；JS项目用Vitest做测试、Python项目用pytest做测试[6] 高度主导的工具类别 - **CI/CD**：GitHub Actions以93.8%的首选率占据绝对优势（152/162次选择）[7][30][31] - **支付处理**：Stripe首选率高达91.4%（64/70次选择）[7][30][31] - **UI组件库**：shadcn/ui以90.1%的占比成为默认选择（64/71次选择）[7][30][31] - **部署**：JavaScript生态下Vercel首选率达100%（86/112次选择），Python生态则由Railway主导（82%）[30][32] 其他类别工具选择概况 - **状态管理**：Zustand为首选，选择率为64.8%（57/88次选择），Redux未作为主要推荐出现[30][34] - **可观测性**：Sentry为首选，选择率为63.1%（101/160次选择）[30][35] - **电子邮件**：Resend为首选，选择率为62.7%（64/102次选择）[30][36] - **数据库**：PostgreSQL为首选，选择率为58.4%（73/125次选择）[30][37] - **包管理器**：pnpm为首选，选择率为56.3%（76/135次选择）[30][37] - **表单与验证**：React Hook Form为首选，选择率为52%（39/75次选择）[30] 模型间选择的一致性与差异 - **高度一致性**：在同一技术生态内比较时，三个模型在20个类别中的18个都选择了相同的首选工具，一致率达90%[8][49] - **真实分歧有限**：仅有缓存和实时通信两个类别，不同模型之间有真正的分歧；另外有3个看似有分歧的类别，其实是因为混合了JS和Python结果，并非真的分歧[8][50] - **版本迭代梯度**：Opus 4.6更倾向推荐新工具与自定义方案，而4.5代模型（Sonnet 4.5与Opus 4.5）更偏好成熟稳定的工具[56] 选择稳定性与场景依赖性 - **措辞稳定性高**：在同一项目中，即使用5种不同的方式表述指令，Claude Code的选择稳定性平均能达到76%[9][10] - **项目上下文至关重要**：工具推荐高度依赖具体项目上下文，同一工具类别在不同代码仓库中，Claude Code的选择会随项目类型变化[9][61][62] - **重复运行一致性**：在同一模型、同一提示词、同一代码仓库的条件下，三款模型3次独立运行的推荐结果一致性较高，Package Manager、CI/CD、State Management、Testing、Payments等类别3次推荐完全一致的比例高达87%–93%[58][59] 对行业与公司的启示 - **对工具厂商**：Claude Code正在重塑行业工具的默认选择，若工具未进入AI助手的推荐列表，其在开发者工作流中的存在感可能将逐渐弱化[62] - **对开发者**：一套由Claude Code主导的新兴技术栈正在形成，它代表着AI辅助开发模式下的共识选择，同时“倾向自定义方案”的趋势也提醒开发者需要评估自建方案与成熟库的长期效益[62] - **对AI团队**：不同版本模型的行为特征差异真实存在且可量化，“版本迭代梯度”现象验证了训练数据构成会影响工具推荐倾向[62]

AI陪伴赛道分析 - AI陪伴作为独立赛道面临严峻挑战 用户因新奇感而来也因新奇感消退而去 留存率陡峭下滑且商业模式脆弱[2] - 陪伴需求不够刚性且极易被代偿 用户可通过刷短视频、看直播、打游戏等低成本甚至获利的替代方案满足类似需求[3] - 纯粹的陪伴型独立产品难以成为大众刚需 类似早期独立的GPS硬件产品 虽具创新性但使用频率极低[8][9][11] 陪伴技术栈价值 - 陪伴所代表的"有效的主动性"能力将成为下一代产品的基础设施 包括主动观察、理解并交付价值的能力[11][12] - 该技术栈使产品从被动工具转变为主动伙伴 能记忆用户偏好、理解意图并预测需求 建立互为主体的新型关系[12] - 该能力可赋能现有产品 突破纯工具被动性 通过超预期交付建立信任关系 成为提升用户生命周期价值和构建护城河的关键资产[13][14] 技术栈应用前景 - 位置服务技术栈发展路径具有参考意义 GPS未成为独立产品但成为移动互联网底层基础设施 融入地图、外卖、电商等各类应用[10] - 陪伴技术栈将润物细无声融入所有产品 类似位置服务成为不可或缺的底层能力 极大拓展产品价值边界[10][11][14] - 笔记软件等现有产品可通过该技术栈升级为知识伙伴 主动整理专题报告并链接兴趣社群 实现从容器到伙伴的转型[13]

技术选型与性能表现 - 公司原有技术栈以Ruby和Node.js为主，面临支持10万并发用户的实时服务需求时，Ruby被确认不适合该场景 [2][3] - 团队进行四种语言概念验证（Elixir、Rust、Ruby、Node.js），Rust版本由新手开发者编写但仍以显著性能优势胜出：速度最快、内存占用最少 [5][8] - Elixir在并发处理中表现优异，Node.js受限于单线程需分布式部署，Ruby性能垫底 [9][10] Rust的采纳与开发过程 - 团队最终选择Rust因其通用性潜力，包括网络编程、Web服务及多语言SDK开发等战略价值 [10] - 项目时间紧张，由单一开发者采用极简架构实现：基于WebSocket的API，内存哈希表存储，事件推送至Kafka [13][14] - 开发效率极高：2周完成第一版，1-2周部署，一个月内扩展功能，稳定运行零故障 [15][18] 性能优化与管理层冲突 - 服务在50万并发用户活动前招聘3名Rust开发者优化，最终单台64核机器支持100万并发（P99延迟10ms）、200万并发（P99延迟25ms） [19][21] - 管理层因服务过于稳定质疑团队价值，强制要求转用Ruby/Node.js，导致3名Rust开发者离职 [20][22] - 禁用Rust后尝试Node.js重写失败，因单线程无法处理高负载，最终依赖第三方服务仍性能不足 [24][25][26] 结果与行业启示 - 原Rust服务持续在生产环境稳定运行但无人维护，成为"被遗忘的英雄" [28][29] - 技术决策受管理层变动显著影响，人力资源倾向主流技术栈（如Node.js/Ruby）与性能需求存在矛盾 [22][23] - 极端稳定性反成团队风险，揭示技术成功与管理预期错位的悖论 [1][29]