大代码库组件范围界定

Guillermo 的判断很直接：AI 目前处理超大代码库的能力仍然有限，本质原因是长上下文推理能力仍是短板——代码库越大，LLM 需要在越长的上下文里保持连贯推理，出错概率越高。

但他指出一个可利用的结构性红利：如果产品是按 React 组件/文件这种小颗粒度拆分的，AI 工具在这个维度上表现明显更好。原因可以追溯到 React 本身的设计哲学——"组件作为可复用单元"最初是 Facebook 为了让大量工程师能在巨大代码库上协作而发明的抽象，这个抽象恰好也是 LLM 擅长处理的粒度。Next.js 的文件路由约定（建一个文件即自动成为一个路由，类似 PHP 的心智模型）进一步强化了这一点——LLM 处理"文件"这个单位天然得心应手。

由此得到一条可执行的使用建议：代码库/项目变大时，主动把任务范围收窄到具体的组件或具体的文件，而不是让 AI 在整个项目范围内自由发挥。缩小任务颗粒度直接降低了"LLM 无法在超长上下文里可靠推理"这个失败模式命中的概率。