deep-research

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deep Research

深度调研

Comprehensive research and discovery before building something new. Instead of jumping straight into code from training data, this skill goes wide and deep — local exploration, web research, competitor analysis, ecosystem signals, future-casting — and produces a research brief that makes the actual build 10x more productive.

在开发新事物前开展全面的调研与探索。不同于直接基于训练数据开始编码，该技能会进行全方位深度调研——本地项目探索、网络调研、竞品分析、生态信号挖掘、未来趋势预判——并生成一份研究简报，让实际开发效率提升10倍。

Depth Levels

调研深度层级

The difference is scope of ambition, not just time.

Depth	Purpose	Scope
focused	Answer a specific question	One decision: "CodeMirror vs ProseMirror?" — targeted search, local scan, 1-2 comparisons. Produces a 1-page recommendation.
wide	Understand the space	Landscape for a new product or feature. Competitors, ecosystem, user needs, architecture options. Enough to write a spec.
deep	Plan a major build	Leave no stone unturned. Everything in wide PLUS library/component research, plugin ecosystems, GitHub issues mining, community sentiment, future-casting, technical deep-dives on every decision. Enough to drive weeks of coding.

Default: wide

差异在于目标范围，而非仅仅是耗时。

深度	目标	范围
聚焦型	解答特定问题	单一决策："CodeMirror vs ProseMirror?" —— 定向搜索、本地扫描、1-2项对比。生成1页的推荐报告。
广泛型	了解整体领域格局	新产品或功能的全景分析。包括竞品、生态、用户需求、架构方案。内容足以支撑撰写规格说明书。
深度型	规划大型开发项目	全面调研无遗漏。包含广泛型的所有内容，再加上库/组件调研、插件生态挖掘、GitHub问题分析、社区舆情、未来趋势预判、每个决策的技术深度剖析。内容足以指导数周的开发工作。

默认：广泛型

Workflow

工作流程

1. Understand the Intent

1. 理解用户意图

Ask the user:

What are you building? (one sentence)
Why? What problem does it solve? Who's it for?
Constraints? Stack preferences, budget, timeline, must-haves?
Existing work? Any projects to build on? Repos to look at?

If the user gives a brief prompt ("obsidian replacement on cloudflare"), that's enough — fill in the gaps through research.

询问用户：

你要开发什么？（一句话描述）
为什么开发？ 解决什么问题？面向哪些用户？
约束条件？ 技术栈偏好、预算、时间线、必备功能？
已有工作？ 有没有可基于开发的项目？需要查看的代码仓库？

如果用户给出简短提示（比如"基于Cloudflare的Obsidian替代方案"），这已足够——通过调研填补信息空白。

2. Local Exploration

2. 本地项目探索

Scan the user's machine for relevant prior work:

bash

undefined

扫描用户设备上的相关过往工作：

bash

undefined

Find related projects by name/keyword

按名称/关键词查找相关项目

ls ~/Documents/ | grep -i "KEYWORD"

Read CLAUDE.md of related projects for architecture context

读取相关项目的CLAUDE.md文件以了解架构背景

find ~/Documents -maxdepth 2 -name "CLAUDE.md" -exec grep -l "KEYWORD" {} ;

find ~/Documents -maxdepth 2 -name "CLAUDE.md" -exec grep -l "KEYWORD" {} \;

Check for reusable patterns, schemas, components

查找可复用的模式、 schema、组件

find ~/Documents -maxdepth 3 -name "schema.ts" -o -name "ARCHITECTURE.md" | head -20


For each related project found:
- Read CLAUDE.md (stack, architecture, gotchas)
- Check for reusable code (schemas, components, utilities, configs)
- Note what worked well and what didn't (from git history, TODO comments)

Also check:
- Basalt Cortex (`~/Documents/basalt-cortex/`) for related clients, contacts, knowledge facts
- `grep -rl "KEYWORD" ~/Documents/basalt-cortex/ --include="*.md"`

find ~/Documents -maxdepth 3 -name "schema.ts" -o -name "ARCHITECTURE.md" | head -20


对于每个找到的相关项目：
- 读取CLAUDE.md（技术栈、架构、注意事项）
- 查找可复用代码（schema、组件、工具函数、配置）
- 记录哪些部分表现良好、哪些存在问题（从git历史、TODO注释中提取）

同时还要检查：
- Basalt Cortex（`~/Documents/basalt-cortex/`）中的相关客户、联系人、知识信息
- `grep -rl "KEYWORD" ~/Documents/basalt-cortex/ --include="*.md"`

3. Web Research

3. 网络调研

Search broadly to understand the space:

Product category: "markdown note app", "knowledge management tool for teams"
Competitors: find top 5-10 by searching "best X", "X alternatives", "X vs Y"
Open source: search GitHub for open-source alternatives, check star counts
Architecture: "how to build X", "X tech stack", "building X with [framework]"
Technology docs: check llms.txt, official docs for key technologies
Platform examples: "built with Cloudflare Workers", "D1 full-text search example"
Tutorials and case studies: "building a Y from scratch", "lessons learned building Z"

广泛搜索以了解领域格局：

产品类别："markdown笔记应用"、"团队知识管理工具"
竞品：通过搜索"最佳X"、"X替代方案"、"X vs Y"找到Top 5-10竞品
开源项目：在GitHub上搜索开源替代方案，查看星标数量
架构："如何开发X"、"X技术栈"、"基于[框架]开发X"
技术文档：查看llms.txt、关键技术的官方文档
平台示例："基于Cloudflare Workers构建"、"D1全文搜索示例"
教程与案例研究："从零构建Y"、"开发Z的经验教训"

4. Ecosystem and Community Research (wide + deep)

4. 生态与社区调研（广泛型+深度型）

Go beyond the core product — the ecosystem reveals what users actually need:

Plugins and add-ons:

What plugins exist for major competitors? The most popular ones reveal what the core product lacks.
e.g. Obsidian has 1800+ plugins — the top 20 tell you what Obsidian doesn't do well natively.
Search: "top [product] plugins", "[product] plugin directory"

GitHub issues and feature requests:

Check top competitors' GitHub repos for most-upvoted issues
Sort by thumbs-up reactions — this is direct user demand signal
Check closed issues for how features were implemented

Forum discussions:

Reddit: r/[product], r/selfhosted, r/webdev, relevant niche subreddits
Hacker News: search for the product category
Discord/Discourse: product-specific communities
What do users love? What do they complain about? What do they wish existed?

App store and review sites:

1-star reviews = unmet needs (the product fails at this)
5-star reviews = what to preserve (users love this, don't break it)
3-star reviews = the interesting middle (it's okay but...)
Search: ProductHunt, G2, Capterra, App Store reviews

Integration requests:

What systems do users want to connect to? (Zapier integrations, API requests)
These reveal real workflows — users duct-tape tools together

超越核心产品本身——生态系统能揭示用户的真实需求：

插件与附加功能：

主流竞品有哪些插件？最受欢迎的插件反映了核心产品的缺失功能。
例如：Obsidian有1800+插件——Top 20的插件能告诉你Obsidian原生支持不足的功能。
搜索关键词："热门[产品]插件"、"[产品]插件目录"

GitHub问题与功能请求：

查看头部竞品GitHub仓库中获赞最多的问题
按点赞数排序——这是最直接的用户需求信号
查看已关闭的问题，了解功能的实现方式

论坛讨论：

Reddit：r/[产品]、r/selfhosted、r/webdev及相关细分社区
Hacker News：搜索产品类别
Discord/Discourse：产品专属社区
用户喜欢什么？抱怨什么？期望什么功能？

应用商店与评测网站：

1星评价 = 未被满足的需求（产品在这方面表现糟糕）
5星评价 = 需要保留的优势（用户喜爱这些功能，不要破坏）
3星评价 = 值得关注的中间地带（功能尚可但仍有不足）
搜索平台：ProductHunt、G2、Capterra、应用商店评价

集成请求：

用户希望连接哪些系统？（Zapier集成、API请求）
这些反映了真实的工作流——用户正在手动整合不同工具

5. Competitor Deep-Dive (wide + deep)

5. 竞品深度剖析（广泛型+深度型）

For each major competitor (3-5 for wide, 5-10 for deep):

Question	How to research
Features	Landing page, docs, changelog
Pricing	Pricing page, comparison sites
User complaints	Reddit, HN, app store reviews
Tech stack	Wappalyzer, view-source, job postings, blog posts
What they do well	5-star reviews, product demos
What they do poorly	1-star reviews, forum complaints, migration guides FROM the product

针对每个主要竞品（广泛型3-5个，深度型5-10个）：

问题	调研方式
功能特性	官网首页、文档、更新日志
定价策略	定价页面、对比网站
用户抱怨点	Reddit、Hacker News、应用商店评价
技术栈	Wappalyzer、查看页面源码、招聘信息、博客文章
竞品优势	5星评价、产品演示
竞品劣势	1星评价、论坛抱怨、从该产品迁移的指南

6. Library and Component Research (deep mode)

6. 库与组件调研（深度型）

Research the building blocks — what already exists that you can use or learn from:

React / UI libraries:

Search npm for category-specific packages ("react markdown editor", "react kanban", "react data table")
Check weekly downloads, last publish date, GitHub stars, open issues count
Read the README and examples — what patterns do they use?
Check bundle size (bundlephobia.com) — does it fit the project constraints?
Look at the source code of the best ones — their architecture is proven by real usage

Headless / unstyled libraries:

Headless UI, Radix, React Aria, Downshift — what primitives exist for the features you need?
These are often better than full component libraries because you control the styling
Check if shadcn/ui already wraps what you need

Hooks and utilities:

TanStack (Query, Table, Virtual, Router) — what's relevant?
React Hook Form, Zod, date-fns, Zustand — proven solutions for common problems
Search "awesome-react" lists and curated collections

Platform-specific libraries:

For Cloudflare: what works on Workers? (No Node.js APIs, no native modules)
Check Cloudflare's own examples and starter templates
Search for "cloudflare workers" + the feature you need

What to capture for each library:

Question	Why it matters
Does it solve our problem?	Feature match
Bundle size	Performance budget
Last publish date	Is it maintained?
Open issues / PRs	Community health
Works on our platform?	Cloudflare Workers has restrictions
What patterns does it use?	Even if we don't use the library, its patterns are valuable

The insight: Even if you decide to build something custom, researching existing libraries shows you the patterns that survived contact with real users. A library with 10K stars has had its API refined by thousands of developers — steal their design decisions.

调研可复用的构建模块——哪些已有组件可以直接使用或借鉴：

React / UI库：

在npm上搜索类别相关的包（"react markdown editor"、"react kanban"、"react data table"）
查看周下载量、最后发布日期、GitHub星标数、开放问题数
阅读README和示例——它们采用了哪些设计模式？
检查包体积（bundlephobia.com）——是否符合项目性能预算？
查看优质库的源码——它们的架构经过了真实场景的验证

无样式/Headless库：

Headless UI、Radix、React Aria、Downshift——有没有你需要的基础组件？
这些通常比完整组件库更优，因为你可以完全控制样式
检查shadcn/ui是否已经封装了你需要的组件

Hooks与工具库：

TanStack（Query、Table、Virtual、Router）——哪些与项目相关？
React Hook Form、Zod、date-fns、Zustand——这些都是解决常见问题的成熟方案
搜索"awesome-react"列表和精选集合

平台专属库：

针对Cloudflare：哪些库能在Workers上运行？（不支持Node.js API、不支持原生模块）
查看Cloudflare官方示例和启动模板
搜索"cloudflare workers" + 你需要的功能

每个库需要记录的信息：

问题	重要性原因
是否能解决我们的问题？	功能匹配度
包体积	性能预算限制
最后发布日期	库是否仍在维护？
开放问题/PR数量	社区活跃度与健康度
是否兼容我们的平台？	Cloudflare Workers有诸多限制
采用了哪些设计模式？	即使我们不使用该库，其设计模式也有借鉴价值

关键洞察：即使你决定自定义开发，调研现有库也能让你了解经过用户验证的设计模式。一个拥有10K星标的库，其API已经过数千开发者的打磨——直接借鉴它们的设计决策即可。

7. Platform Capability Deep-Dive (wide + deep)

7. 平台能力深度调研（广泛型+深度型）

This is critical. Claude's training data is always behind on platform features. Cloudflare, Vercel, Firebase, Supabase — they all ship new capabilities constantly. A feature you assume doesn't exist might have launched last month. The Basalt Cortex project exists because of capabilities (Workers AI toMarkdown, Vectorize metadata filtering, D1 FTS5) that weren't obvious without actively looking.

Do NOT rely on training data for platform capabilities. Go read the actual current docs.

这一点至关重要。Claude的训练数据在平台功能方面总是滞后的。Cloudflare、Vercel、Firebase、Supabase——这些平台都在持续发布新功能。你以为不存在的功能，可能上个月已经上线了。Basalt Cortex项目的诞生，正是得益于Workers AI toMarkdown、Vectorize元数据过滤、D1 FTS5等不主动调研就不会发现的平台能力。

不要依赖训练数据了解平台能力。直接查看最新的官方文档。

How to Research the Platform

平台调研方法

Fetch the platform's changelog/blog:

Cloudflare:

https://blog.cloudflare.com/

https://developers.cloudflare.com/changelog/

Vercel:
```
https://vercel.com/changelog
```

Firebase:

https://firebase.google.com/support/releases

Supabase:
```
https://supabase.com/changelog
```

Read the full product catalogue — not just the services you already use:
- Cloudflare: Workers, D1, R2, KV, Vectorize, Queues, Durable Objects, Workers AI, AI Gateway, Workflows, Containers, Browser Rendering, Tunnel, Email Routing, Images, Stream, Hyperdrive, Pipelines, Sandbox
- Vercel: Functions, Edge Middleware, KV, Postgres, Blob, AI SDK, Cron, Firewall
- Firebase: Firestore, Auth, Storage, Functions, Hosting, Extensions, Genkit, App Check
For each service, ask: could this solve a problem in the product we're building?
Look for recently shipped features that expand what's possible:
- New AI models available at the edge?
- New storage primitives?
- New networking capabilities?
- New auth/identity features?
- New build/deploy options?

获取平台的更新日志/博客：

Cloudflare：

https://blog.cloudflare.com/

https://developers.cloudflare.com/changelog/

Vercel：
```
https://vercel.com/changelog
```

Firebase：

https://firebase.google.com/support/releases

Supabase：
```
https://supabase.com/changelog
```

通读完整的产品目录——不要只看你已经在使用的服务：
- Cloudflare：Workers、D1、R2、KV、Vectorize、Queues、Durable Objects、Workers AI、AI Gateway、Workflows、Containers、Browser Rendering、Tunnel、Email Routing、Images、Stream、Hyperdrive、Pipelines、Sandbox
- Vercel：Functions、Edge Middleware、KV、Postgres、Blob、AI SDK、Cron、Firewall
- Firebase：Firestore、Auth、Storage、Functions、Hosting、Extensions、Genkit、App Check
针对每个服务，思考：这能解决我们产品中的什么问题？
寻找近期发布的新功能——这些功能能拓展产品的可能性：
- 边缘节点新增了哪些AI模型？
- 新增了哪些存储原语？
- 新增了哪些网络能力？
- 新增了哪些身份验证/身份管理功能？
- 新增了哪些构建/部署选项？

Cloudflare Capability Checklist (Expand for Other Platforms)

Cloudflare能力检查清单（可扩展到其他平台）

Go through each and ask "would this be useful for what we're building?":

Category	Services to investigate
Compute	Workers, Cron Triggers, Queues consumers, Workflows (multi-step), Containers, Durable Objects (stateful), Tail Workers
Storage	D1 (SQL + FTS5), R2 (objects), KV (key-value), Durable Object storage (strongly consistent)
AI	Workers AI models (text, image, embedding, speech, translation, toMarkdown), Vectorize (semantic search), AI Gateway (caching/routing)
Networking	Custom domains, Tunnel, Spectrum (TCP/UDP), WebSockets, Hyperdrive (database proxy)
Security	WAF, Turnstile (CAPTCHA), Bot Management, API Shield, DDoS
Media	Images (resize/optimise on-the-fly), Stream (video), Browser Rendering (screenshots, PDF generation)
Email	Email Routing (rules), Email Workers (programmable inbound email processing)
Observability	Workers Logs, Analytics Engine, GraphQL analytics

逐一检查并思考"这对我们要开发的产品有用吗？"：

类别	需要调研的服务
计算	Workers、Cron Triggers、Queues消费者、Workflows（多步骤）、Containers、Durable Objects（有状态）、Tail Workers
存储	D1（SQL + FTS5）、R2（对象存储）、KV（键值存储）、Durable Object存储（强一致性）
AI	Workers AI模型（文本、图像、嵌入、语音、翻译、toMarkdown）、Vectorize（语义搜索）、AI Gateway（缓存/路由）
网络	自定义域名、Tunnel、Spectrum（TCP/UDP）、WebSockets、Hyperdrive（数据库代理）
安全	WAF、Turnstile（验证码）、Bot Management、API Shield、DDoS防护
媒体	Images（即时缩放/优化）、Stream（视频）、Browser Rendering（截图、PDF生成）
邮件	Email Routing（规则）、Email Workers（可编程的入站邮件处理）
可观测性	Workers日志、Analytics Engine、GraphQL分析工具

What to Capture

需要记录的信息

For each relevant capability, note:

What it does (one sentence)
How it could be used in this product
Any limitations or pricing considerations
Example: "Workers AI
```
toMarkdown()
```
converts any uploaded PDF/DOCX to markdown at the edge — we could use this for document import without any external service"

对于每个相关的平台能力，记录：

功能描述（一句话）
如何在本产品中使用
任何限制或定价考量
示例："Workers AI
```
toMarkdown()
```
可以在边缘节点将上传的PDF/DOCX转换为markdown——我们可以用它实现文档导入，无需依赖外部服务"

Why This Matters

为什么这很重要

The difference between "build a note app" and "build a note app that converts any file to markdown, searches semantically across all notes, generates summaries with AI, syncs via background Workflows, and renders PDFs with Browser Rendering" is knowing what the platform offers. Most developers only use 20% of their platform because they never looked at the other 80%.

"开发一款笔记应用"和"开发一款能将任意文件转换为markdown、支持所有笔记语义搜索、AI生成摘要、通过后台Workflows同步、用Browser Rendering渲染PDF的笔记应用"的区别，就在于你是否了解平台提供的能力。大多数开发者只使用了平台20%的功能，因为他们从未关注过另外80%。

8. Future-Casting (deep mode)

8. 未来趋势预判（深度型）

Think beyond what exists today:

Platform roadmap: Based on the changelog and blog research above, what direction is the platform heading? What's in beta? What was announced but not yet GA?

AI integration: Not "add a chatbot" — think deeper. What's possible when the tool can read, reason about, and act on the user's data? What if every note could be searched semantically? What if the app could write its own documentation? What if uploads auto-converted to markdown?

Device and input evolution: Mobile-first, voice input, wearables, spatial computing. How might users interact with this in 2-5 years?

Data sources: What new inputs could feed in? Sensors, APIs, real-time data, cross-app context?

Adjacent opportunities: What problems sit next to this one? e.g. building a note app — adjacent: task management, project tracking, team communication. What are users duct-taping together today?

Convergence trends: What separate tools are being unified? (Email + chat + tasks = Slack. Notes + databases + wikis = Notion. What's next?)

超越当前已有的功能，思考未来的可能性：

平台路线图：基于上述更新日志和博客调研，平台的发展方向是什么？哪些功能处于测试阶段？哪些已发布但尚未全面可用？

AI集成：不是简单的"添加聊天机器人"——要深入思考。工具能够读取、推理并响应用户数据时，能实现什么功能？如果所有笔记都能语义搜索会怎样？如果应用能自动生成文档会怎样？如果上传的文件能自动转换为markdown会怎样？

设备与输入方式演进：移动优先、语音输入、可穿戴设备、空间计算。未来2-5年用户会如何与产品交互？

数据源拓展：未来可能接入哪些新的输入源？传感器、API、实时数据、跨应用上下文？

相邻机会：与当前问题相关的其他问题是什么？例如：开发笔记应用——相邻领域包括任务管理、项目跟踪、团队沟通。用户现在正在手动整合哪些工具？

融合趋势：哪些独立工具正在被整合？（邮件+聊天+任务=Slack；笔记+数据库+维基=Notion；下一个会是什么？）

7. Technical Research (deep mode)

7. 技术调研（深度型）

For each major architectural decision:

Decision area	Questions to answer
Editor / UI framework	Options, tradeoffs, community size, our experience
Database	SQL vs NoSQL vs file, managed vs self-hosted, our stack support
Auth	Better-auth, Clerk, Auth.js, custom — what fits?
Hosting / deployment	Cloudflare, Vercel, Railway — constraints and capabilities
Search	FTS5, Elasticsearch, Meilisearch, Vectorize — what scale?
Real-time	WebSockets, SSE, Durable Objects — do we need it?
File storage	R2, S3, local — access patterns?
API design	REST, tRPC, GraphQL — what does the use case need?

针对每个关键架构决策：

决策领域	需要解答的问题
编辑器/UI框架	可选方案、权衡、社区规模、团队经验
数据库	SQL vs NoSQL vs 文件存储、托管 vs 自托管、技术栈兼容性
身份验证	Better-auth、Clerk、Auth.js、自定义实现——哪个更适合？
托管/部署	Cloudflare、Vercel、Railway——限制与能力
搜索功能	FTS5、Elasticsearch、Meilisearch、Vectorize——支持的规模？
实时功能	WebSockets、SSE、Durable Objects——是否需要？
文件存储	R2、S3、本地存储——访问模式？
API设计	REST、tRPC、GraphQL——用例需求是什么？

8. Synthesis

8. 调研成果整合

Produce a research brief saved to

.jez/artifacts/research-brief-{topic}.md

markdown

undefined

生成一份研究简报并保存到

.jez/artifacts/research-brief-{topic}.md

：

markdown

undefined

Research Brief: [Topic]

研究简报：[主题]

Depth: [focused|wide|deep] Date: YYYY-MM-DD Research time: [duration]

调研深度：[聚焦型|广泛型|深度型] 日期：YYYY-MM-DD 调研时长：[时长]

Executive Summary

执行摘要

[2-3 sentences: what to build, why, key insight from research]

[2-3句话：要开发什么、为什么开发、调研的核心洞察]

Competitive Landscape

竞品格局

| 产品 | 优势 | 劣势 | 定价 | 用户群体 |

Key Insights

核心洞察

[What winners do well, what gaps exist in the market]

[头部产品的成功经验、市场中的空白]

Ecosystem Signals

生态信号

最受欢迎的插件/附加功能

[Top plugins for competitors — reveals unmet needs]

[竞品的热门插件——反映了核心产品的缺失功能]

Most Requested Features

呼声最高的功能请求

[From GitHub issues, forums, reviews — sorted by demand]

[来自GitHub问题、论坛、评价的需求——按需求热度排序]

Integration Patterns

集成模式

[What systems users connect to — reveals real workflows]

[用户希望连接的系统——反映真实工作流]

User Needs

用户需求

[What real users want, from reviews/forums/complaints]

[从评价/论坛/抱怨中提炼的真实用户需求]

Technical Landscape

技术格局

| 决策 | 可选方案 | 推荐方案 | 理由 |

Libraries and Components

库与组件评估

| 需求 | 库名称 | 星标数 | 包体积 | 兼容平台？ | 备注 | [每个核心功能对应的候选库评估]

Platform Capabilities

平台能力适配

| Service | Could use for | Impact | [Every platform service evaluated against the product's needs] [Flag recently shipped features the team may not know about]

| 服务 | 可应用场景 | 影响 | [每个相关平台能力的评估] [标记团队可能不了解的近期发布功能]

Reusable From Existing Projects

可复用的现有项目资源

| Project | What to reuse | Location |

| 项目 | 可复用内容 | 位置 |

Future Possibilities

未来可能性

Platform roadmap

平台路线图

AI opportunities

AI应用机会

Adjacent problems

相邻问题

2-5 year horizon

2-5年发展展望

Proposed Architecture

建议架构

[Stack, data model sketch, key flows]

[技术栈、数据模型草图、核心流程]

Risks and Open Questions

风险与待解答问题

[Things research couldn't answer]

[调研无法解答的问题]

Suggested Phases

建议开发阶段

[Build order based on research findings]

[基于调研结果的开发优先级]

Sources

参考来源

[Links to everything read]

undefined

[所有参考资料的链接]

undefined

Tips

小贴士

Start the brief early and add to it as you research — the artifact is the deliverable
For deep mode, use sub-agents to parallelise web research and local exploration
The "Reusable From Existing Projects" section often saves weeks of work
Ecosystem signals (plugins, issues, reviews) are often more valuable than competitor feature lists
Save the brief to
```
.jez/artifacts/
```
— it's useful for future sessions and for the actual build phase
The brief is a living document — update it as you learn more during the build

尽早开始撰写简报，边调研边补充——最终的简报就是交付成果
深度调研模式下，可使用子Agent并行处理网络调研和本地探索
"可复用的现有项目资源"部分通常能节省数周的开发时间
生态信号（插件、问题、评价）往往比竞品功能列表更有价值
将简报保存到
```
.jez/artifacts/
```
——对未来的会话和实际开发阶段都有用
简报是活文档——开发过程中了解到新信息时要及时更新",