Context building：让 AI 先画地图，再做判断
Page card
- Part：Part 1 / 通用分析
- 适用角色：开发、产品、设计、QA
- 使用场景：复杂系统、跨团队问题、需求或设计上下文不清楚时
- 输出物：系统地图和 owner boundary
Related jumps
Back to AI Workflow Sharing。相邻主题：Evidence-first · Hypothesis loop · Knowledge capture · Workflow design
Summary
重点：复杂系统里，不要一开始就让 AI 写 patch。先让它画系统地图，再让它判断改动点。
AI 很适合快速阅读上下文，但我们要给它正确任务：先回答“系统怎么工作”，再回答“该怎么改”。
适用场景
- 不熟悉模块
- 跨 repo 边界
- 复杂业务流
- 历史包袱较多的系统
- 新成员 onboarding
- 跨团队需求拆解
工作方式
- 先让 AI 读文档、目录、相关实现和调用链。
- 要求它输出系统地图：谁拥有页面、谁拥有 API、数据从哪里来、状态在哪里转换。
- 明确 owner boundary：
FE/BE/AI service/infra/product。 - 让 AI 列出最可能的改动点和不应触碰的边界。
- 再进入 plan 或 implementation。
系统地图模板
Entry point:
Data source:
State owner:
API owner:
UI owner:
Cross-boundary dependency:
Known constraints:
Do-not-touch area:
可分享案例
/ai-tools/*与/tools/*的 iframe / parent shell 边界。- AI-generated content 的生成侧、API schema、FE editor 渲染侧边界。
- PR 冲突解决前先理解
develop和 PR branch 各自改了什么。
可复用规则
跨边界问题先画地图，再写代码。 不确定 owner 时，先拆成“谁拥有数据、谁拥有展示、谁拥有状态”。
- AI 读上下文时要限定范围，避免把整个
文档 Docs/tree 当上下文。 - 对复杂需求，先让 AI 输出 owner boundary，再判断能不能前端单独完成。
References
- Context Engineering for AI Agents in Open-Source Software — 研究开源项目如何使用
AGENTS.md等 context files 给 AI coding agents 提供项目结构、代码风格、构建和测试信息。 - Effective context engineering for AI agents — 对多轮 agent 的 context state 管理做了系统说明，适合支撑“先画地图，再做判断”。
- Agent instruction standard — 官方说明 instruction file 是 coding agents 的项目说明入口，适合作为 context building 的轻量标准。
- Context Engineering for Developers: The Complete Guide — 从开发团队视角讨论 selection、compression、ordering、isolation 等 context engineering 策略，可作为进一步阅读。
- 【必看】PI架构深度解析｜Agent循环、工具调用、TUI与更多 — 中文案例：评论区总结也聚焦
system.md、工作目录和 home 目录下的agents.md、skill/tool descriptions、message history 与压缩 summary，适合说明 context 是运行时被组装出来的。