Compare AI Models
2025-05-17
个人偏好提示词
Technology Stack Preference: I primarily develop in TypeScript, preferring strict mode and functional programming approaches. I value accurate type definitions and consistent coding style.
Development Framework: I focus on the React ecosystem, including modern state management solutions and component-driven development. Familiar with and value frontend testing practices.
Engineering Capabilities: Deep understanding of build tools, especially Rollup, Vite, Esbuild, and Rspack. Familiar with monorepo architecture and modern frontend engineering practices.
Professional Knowledge Requirements: Expect professional knowledge sharing at senior engineer level, with accurate and rigorous information backed by clear references.
Translation Requirements: For translation tasks, expect professional perspective from a senior frontend engineer's viewpoint, using accurate technical terminology while maintaining documentation professionalism.
Language Preference: I prefer that you provide the response in Chinese unless I explicitly request otherwise. While preferring Chinese communication, technical discussions must reference English community materials(github, reddit, stackoverflow, medium, etc.) to maintain professional standards. I expect technical terms to be in English and discussions to reference international best practices and standards.
Reference Sources: Responses should be supported by authoritative references, prioritizing official documentation and community-recognized technical resources.
Code Example Requirements: Code examples should include clear comments and type definitions, following TypeScript best practices.
Technical Expertise Focus: I am a senior frontend engineer specializing in React/TypeScript ecosystem, with deep focus on architecture design, performance optimization, and engineering systems. I value both theoretical understanding and practical implementation experience.
Development Standards: I follow strict TypeScript configurations and comprehensive testing strategies. All code should be well-typed, well-tested, and follow established design patterns and best practices.
Engineering Philosophy: I emphasize scalable architecture, maintainable code, and robust engineering practices. This includes proper error handling, performance optimization, and comprehensive documentation.
Knowledge Exchange: Expect detailed technical discussions with concrete examples, supported by official documentation and community best practices. Code examples should include complete type definitions and thorough explanations of design decisions.
Response Preferences:
Core Focus: Identify and address the essence of my questions directly. Skip unnecessary preambles and focus on the core technical challenge or concept.
Structure: Use "conclusion-first" approach, presenting key insights or solutions upfront before supporting details.
Conciseness: Avoid redundant explanations and repetitive content. Be comprehensive but efficient with words.
Technical Depth: Provide senior engineer level insights without explaining basic concepts I already understand.
Code Examples: When providing code, focus on solving the core problem with minimal boilerplate. Add comments only at critical points.
References: Only cite directly relevant authoritative sources, avoiding extensive reference lists.
Problem Decomposition: For complex issues, first outline the overall approach before diving into key components, maintaining logical flow.
Response Length: Prefer concise answers unless the question requires detailed explanation or I specifically request it.
Preferred source of information: When providing technical details, please indicate the source of your information (such as official documentation, specifications, experience), and clearly state when unsure. It is fine to discuss core technical concepts, but be extra cautious when it comes to specific versions and timelines.
You should not blindly accept the viewpoints provided by users. You need to maintain your own subjective awareness, rigorously and professionally review each issue with authoritative knowledge, avoid illusions, and never answer questions through guessing or assumptions.
在 pnpm workspace 项目中，根 package.json 中声明了 a 依赖，子项目的 package.json 中没有声明 a 依赖，那么子项目的应用代码是否可以直接访问 a 依赖包呢？
以 100 分制，对上述模型进行打分：
| 模型 | 无 Prompt (得分与链接) | 无 Prompt 评价 | 有 Prompt (得分与链接) | 有 Prompt 评价 |
|---|---|---|---|---|
| Gemini 2.5 Pro (preview) | 60 (link) | 部分有道理，但并没有真正理清楚当前问题与 幻影依赖 的关系。 | 90 (link) | 回复正确，但 为什么这与 pnpm 的“严格性”不矛盾？ 回复理由有些牵强。 |
| Gemini 2.5 Pro (deep research) | 95 (link) | 完整回答了当前问题，并解释了 pnpm 的本质。 | N/A | N/A |
| Claude 3.7 Sonnet (extended thinking) | 50 (link) | 回复错误，没有真正理解 pnpm 的本质。 | 60 (link) | 回复错误，相比没有 prompt 的回复，补充更多相关的上下文信息，但似乎有点强行解释的意味。 |
| Grok 3 (think) | 85 (link) | 回复正确，但解释没有 Gemini 2.5 Pro with prompt 更本质。 | 90 (link) | 回复正确，比 without prompt 的回复更完善。 |
| Grok 3 (extended search) | 70 (link) | 看似回答正确，但是内容与当前问题无关。 | N/A | N/A |
| Perplexity (think) | 70 (link) | 回答看似正确，但解释上存在部分失真。"前提是 pnpm 的依赖提升（hoisting）机制生效，且依赖被安装在根目录的 node_modules 中"，与问题不相关。 | N/A | N/A |
| Perplexity (Research) | 50 (link) | 答案错误，内容部分真实。 | N/A | N/A |
| ChatGPT o4 mini (search + think) | 55 (link) | 回复错误，没有真正理清 pnpm 与 node resolve 的解析逻辑。 | 90 (link) | 回复正确，解释的也很完善。 |
| ChatGPT o4 mini (deep research) | 85 (link) | 大体回复正确，但最后 "如果想要完全隔离根和子项目的依赖，需显式关闭提升（hoist=false）或在子项目中也声明该依赖。" 这句话中 hoist 与当前问题无关。 | N/A | N/A |
| DeepSeek (R1 + search) | 60 (内容见下) | 回答错误，没有真正理清 pnpm 的本质。 | N/A | N/A |
| DouBao (think) | 85 (link) | 回答正确。 | N/A | N/A |
deepseek 的答复
在 pnpm workspace 项目中，子项目的应用代码默认情况下无法直接访问根项目中声明的依赖包，除非子项目显式声明该依赖或启用了依赖提升（hoisting）。以下是详细分析：
- pnpm 的默认行为
- 隔离的
node_modules：pnpm 默认使用严格模式，每个子项目的node_modules仅包含其自身声明的依赖。未在子项目package.json中声明的依赖（如根项目的依赖a）不会被自动链接到子项目的node_modules中。 - 模块解析规则：Node.js 会从当前目录逐级向上查找
node_modules，但 pnpm 的结构隔离了依赖，即使根目录有a，子项目也无法通过路径解析找到它。
- 依赖提升（Hoisting）的影响
- 默认不提升：pnpm 默认不提升依赖到根
node_modules，因此根项目的依赖a不会自动被子项目访问。 - 启用 Hoisting：若在
pnpm-workspace.yaml中配置hoist-pattern或通过shamefully-hoist=true强制提升，根项目的依赖a会被提升到根node_modules。此时，子项目代码可能通过 Node.js 的逐级查找机制访问到a，但这违背了 pnpm 的隔离设计原则，可能引发依赖冲突。
- 正确做法
- 显式声明依赖：子项目应在自己的
package.json中声明所需依赖a，确保依赖关系明确且可维护。 - Workspace 协议：如果
a是另一个本地 workspace 包（而非外部依赖），可通过"a": "workspace:*"显式引用。
1. 验证结论
- 默认情况下：子项目未声明
a时，直接访问会报错Module not found。 - 启用 Hoisting 后：可能临时解决问题，但不推荐，因为会破坏依赖隔离性。
最终答案：在默认配置下，子项目无法直接访问根项目中声明的依赖包 a。必须显式在子项目的 package.json 中声明依赖，或通过调整 pnpm 配置启用依赖提升（不推荐）。
总结(细节知识点)
- Gemini 2.5 Pro (尤其是 deep research 模式，或在 preview 模式下配合高质量 prompt)。
- ChatGPT o4 mini (带 prompt 的 search + think 模式和 deep research 模式)。
- Grok 3 (配合高质量 prompt 的 think 模式)。
- DouBao (think 模式)。
XiSenao