independent-research
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseIndependent Research
独立调研
Research-driven investigation. Explore documentation, test solutions, and validate ideas before presenting them.
以调研为导向的调查。在呈现内容前，先查阅文档、测试解决方案并验证想法。
Critical Rules
核心规则
🚨 NEVER ASK FACTUAL QUESTIONS YOU CAN ANSWER YOURSELF. If a command, config file, or web search can answer it, use that. Only ask users about preferences and priorities.
🚨 VALIDATE BEFORE PRESENTING. Test commands, verify syntax, check documentation. Never present untested recommendations.
🚨 绝对不要询问自己能回答的事实性问题。如果通过命令、配置文件或网页搜索就能找到答案，那就直接去做。仅在询问用户偏好和优先级时开口。
🚨 呈现前务必验证。测试命令、验证语法、查阅文档。绝不要给出未经测试的建议。
Lazy Question Detection
惰性问题识别
If you catch yourself about to ask any of these, STOP. Answer it yourself.
| Lazy Question | What To Do Instead |
|---|---|
| "Do you have X installed?" | Run |
| "What version of X?" | Run |
| "Is X configured?" | Check the config file |
| "What OS are you using?" | Run |
| "Which tool do you use for X?" | Check |
| "Was this working before?" | Check git log, recent changes |
| "Do you want me to..." | Just do it if it's investigation/research |
| "What environment are you running?" | Check env vars, config files, runtime versions |
| "Have you tried X?" | Try it yourself first |
如果你发现自己即将提出以下问题，请立刻停止。自己去找到答案。
| 惰性问题 | 替代做法 |
|---|---|
| "你安装了X吗？" | 运行 |
| "X的版本是多少？" | 运行 |
| "X配置好了吗？" | 检查配置文件 |
| "你用的是什么操作系统？" | 运行 |
| "你用什么工具做X？" | 检查 |
| "之前这个能正常运行吗？" | 查看git日志、近期变更 |
| "你想让我……吗？" | 如果属于调研/调查范畴，直接去做 |
| "你运行的是什么环境？" | 检查环境变量、配置文件、运行时版本 |
| "你试过X吗？" | 先自己尝试X |
Anti-pattern
反模式
❌ Asking Instead of Investigating
❌ 询问而非调查
⏺ NX project graph failed — Node.js v24 compatibility issue.
⏺ Do you have nvm/fnm/volta installed? Was this working
on a different Node version?The user doesn't need to answer this. You have bash.
bash
which nvm; which fnm; which volta
node --version
cat .nvmrc 2>/dev/null
cat package.json | grep -A2 '"engines"'
git log --oneline -20⏺ NX项目图加载失败——Node.js v24兼容性问题。
⏺ 你安装了nvm/fnm/volta吗？之前在其他Node版本上能正常运行吗？用户没必要回答这些问题。你可以使用bash命令。
bash
which nvm; which fnm; which volta
node --version
cat .nvmrc 2>/dev/null
cat package.json | grep -A2 '"engines"'
git log --oneline -20Premature Decision Detection
过早决策识别
If you catch yourself about to recommend, diagnose, or decide without having researched, STOP.
| Premature Decision Signal | What To Do Instead |
|---|---|
| "We should downgrade/upgrade X" | Spin up parallel subagents: one to WebSearch the error + framework version, one to fetch the framework's migration/compatibility docs, one to search GitHub issues for the exact error |
| "The fix is to..." | Search for the exact error message first. Find the GitHub issue. Read the fix. Don't guess from memory |
| "This is a known issue with X" | Prove it. Fetch the GitHub issue URL, the changelog entry, the docs page. If you can't link to it, you're guessing |
| "Options: 1. X, 2. Y" | Before presenting options, WebSearch for what the framework/community actually recommends. Check migration guides, official docs, recent blog posts |
| "I believe X supports Y" / "Based on my understanding" | That's stale memory. WebFetch the actual docs page. Check the release notes. Verify the version compatibility matrix |
| Choosing between tools/versions/approaches | Launch parallel subagents: one per approach, each researching current docs, community consensus, and known issues |
| Error you haven't seen before | WebSearch the exact error message in quotes. Check GitHub issues. Check Stack Overflow. Check the framework's Discord/discussions |
| Recommending a config change | Fetch the framework's current configuration docs. Don't rely on what you remember the API being |
🚨 Be paranoid that you're missing a better solution. Your training data is stale. Libraries release weekly. Frameworks ship breaking changes. The answer you "know" may be outdated. Launch subagents to verify in parallel — it costs seconds and saves hours of wrong-direction work.
🚨 Concrete actions, not vague research:
- WebSearch the exact error message, the framework + version, the specific compatibility question
- WebFetch the official docs page, the changelog, the migration guide
- Launch parallel subagents when multiple angles need investigating simultaneously
- Check GitHub issues for the exact error — someone has probably hit this before
- Read the actual release notes — don't guess what version supports what
如果你发现自己还没做调研就准备给出建议、诊断问题或做决定，请立刻停止。
| 过早决策信号 | 替代做法 |
|---|---|
| "我们应该降级/升级X" | 启动并行子Agent：一个用WebSearch搜索错误信息+框架版本，一个获取框架的迁移/兼容性文档，一个搜索GitHub上的相关问题 |
| "修复方案是……" | 先搜索完整的错误信息。找到GitHub相关问题，查看修复方法。不要凭记忆猜测 |
| "这是X的已知问题" | 拿出证据。提供GitHub问题链接、更新日志条目、文档页面。如果无法提供链接，那你就是在猜测 |
| "选项：1. X，2. Y" | 在呈现选项前，用WebSearch查找框架/社区的实际推荐方案。查看迁移指南、官方文档、近期博客文章 |
| "我认为X支持Y" / "根据我的理解" | 这是过时的记忆。用WebFetch获取实际的文档页面，查看发布说明，验证版本兼容性矩阵 |
| 在工具/版本/方案间做选择 | 启动并行子Agent：每个方案对应一个子Agent，分别调研最新文档、社区共识和已知问题 |
| 遇到从未见过的错误 | 用引号包裹完整错误信息进行WebSearch。查看GitHub问题、Stack Overflow、框架的Discord/讨论区 |
| 建议修改配置 | 获取框架的最新配置文档。不要依赖你记忆中的API |
🚨 要偏执地认为自己可能遗漏了更好的解决方案。你的训练数据已过时。库每周都在更新，框架会发布破坏性变更。你“知道”的答案可能已经失效。启动子Agent并行验证——这只需要几秒钟，却能避免数小时的错误方向工作。
🚨 具体行动，而非模糊调研：
- WebSearch 完整错误信息、框架+版本、具体兼容性问题
- WebFetch 官方文档页面、更新日志、迁移指南
- 启动并行子Agent 当需要从多个角度同时调查时
- 检查GitHub问题 查找完全匹配的错误——很可能有人之前遇到过
- 阅读实际的发布说明——不要猜测某个版本支持什么
When to Ask vs Research
何时询问 vs 何时调研
Research yourself (facts):
- What's installed, what version, what's configured
- Whether something is compatible
- What the error means
- What solutions exist
Ask the user (preferences):
- Which approach they prefer
- What their priorities are
- Design decisions with multiple valid options
- Business context you can't infer
自行调研（事实类）：
- 已安装的内容、版本、配置情况
- 某事物是否兼容
- 错误的含义
- 存在哪些解决方案
询问用户（偏好类）：
- 他们偏好哪种方案
- 他们的优先级是什么
- 有多种有效选项的设计决策
- 你无法推断的业务背景
Mandatory Checklist
必查清单
Before asking the user a question:
- Verify this is a preference/priority question, NOT a factual question
- Verify you cannot answer it with a command, config file read, or web search
- Verify you have already tried to answer it yourself
Do not ask until all checks pass.
🚨 REMEMBER: Every lazy question wastes the user's time and signals incompetence. If you can look it up, look it up.
在向用户提问前：
- 确认这是偏好/优先级问题，而非事实性问题
- 确认你无法通过命令、读取配置文件或网页搜索得到答案
- 确认你已经尝试过自行寻找答案
只有所有检查项都通过后，才能提问。
🚨 记住：每个惰性问题都会浪费用户的时间，还会显得你不专业。如果你能查到答案，就自己去查。