Interview Bank

How to reason about it · think before answering

1. First decide whether this asks for definitions or engineering consequences; a definition-only answer reads as inexperienced.
2. Follow the causal chain: tokens are the unit of billing and length, the window caps that unit, models are stateless so history is resent every turn, cost grows with turns, hence context engineering.
3. The differentiator is why agents suffer more: a loop calls the model repeatedly and appends tool results back into history.
4. Close with concrete tactics: sliding window, summarization, externalized long-term memory, and the cost of each.
5. Expect the follow-up: why compress before the window is full? Long contexts dilute attention and raise latency and cost.

分析过程 · 先想清楚再作答

1. 先判断这题问的是「概念」还是「工程后果」。只答定义会被认为没做过工程，必须落到设计影响上。
2. 从一条因果链推：token 是计费与长度的计量单位 → 窗口是这个单位的上限 → 模型无状态、历史每轮重发 → 成本随轮数增长 → 所以必须做上下文工程。
3. 关键要点出在「Agent 比聊天更严重」：Agent 在循环里反复调模型，还要把工具返回结果也塞回历史，增长速度快得多。
4. 结论给出具体手段：滑动窗口、摘要压缩、长期记忆外置到检索系统，并说明各自代价。
5. 可以预期的追问：窗口没满为什么也要压缩？答案是长上下文会稀释注意力、抬高延迟与成本，不是塞满了才处理。

How to reason about it · think before answering

1. This tests context-cost awareness. 'CLAUDE.md holds rules, skills hold procedures' is the conclusion; derive it from how each is loaded.
2. Start from load timing: CLAUDE.md enters context in full every session — a fixed cost; a skill keeps only its one-line description resident and loads its body on invocation — a variable cost. Hence short facts that always apply go in CLAUDE.md, occasional multi-step procedures go in skills.
3. Give the table: commands, non-default style, repo etiquette, environment quirks, and the definition of done belong in CLAUDE.md; deployment runbooks, issue-fixing steps, document generators belong in skills. Multi-step procedures in CLAUDE.md or always-on rules inside a skill are both misplacements.
4. At 500 lines the failure is dilution, not capacity: important rules drown, adherence drops, and every turn pays for the bloat. Fixes: prune ruthlessly (would removing this cause a mistake?), move occasional content to skills, split path-scoped rules into .claude/rules/ so they load only when matching files are touched.
5. Follow-ups: a rule that keeps being ignored — prune, then disambiguate, then emphasize; anything that must run every time should be a hook, not a sentence.

分析过程 · 先想清楚再作答

1. 这题考的是「上下文成本意识」。答成「CLAUDE.md 放规则、skill 放流程」只是结论，面试官想听你从加载方式推出这个结论。
2. 拆法从加载时机入手：CLAUDE.md 每次会话整份进入上下文，是固定成本；skill 只有描述那一行常驻，正文在被触发（模型判断相关或用户输入 /name）时才加载，是按需成本。所以「每次都成立的短事实」放 CLAUDE.md，「偶尔才用、一用就是多步」的流程放 skill。
3. 给判据表：命令、风格差异、仓库礼仪、环境怪癖、完成的判据进 CLAUDE.md；部署流程、修 issue 的固定步骤、某类文档的生成方法进 skill。反过来，CLAUDE.md 里出现了多步流程，或 skill 里放了「每次都要遵守」的规则，都是放错了。
4. 500 行的问题不是「太长跑不动」，而是稀释：重要规则被淹没，模型的遵守度反而下降，还白白吃掉每轮的窗口。对策是「删到不能再删」（删掉会不会让它犯错？不会就删）、把偶尔用的挪进 skill、按路径拆进 .claude/rules/ 只在碰到匹配文件时加载。
5. 可预期的追问：「规则它老是不听怎么办」——先删再改再强调；「必须每次执行」的动作根本不该靠 CLAUDE.md，要改成 hook。

How to reason about it · think before answering

1. This probes whether you treat context as a scarce resource, not whether you know the file format; answering with a project overview signals inexperience.
2. Use one test: can the agent discover this by opening files? If yes, leave it out (directory layout, framework); if no, write it down (conventions, no-go areas, environment facts, test commands).
3. Add the lookup rules: a global file in the home directory, then project files concatenated from the repo root down to the current directory, so closer files override earlier ones.
4. The size cap (32 KiB by default in Codex) forces prioritization: a long manual crowds out the task and dilutes adherence to every rule.
5. Expect the follow-up: will the model always obey the file? No, it is prompt text and fades over long sessions; hard limits belong to the sandbox and approvals.

分析过程 · 先想清楚再作答

1. 这题考的不是文件格式，而是你对「上下文是有限资源」有没有工程直觉。把它答成「写项目介绍」会被判为没真用过。
2. 拆法是一个判断句：这条信息 agent 打开文件自己能不能发现？能发现的不写（目录结构、用了什么框架），发现不了的才写（约定、禁区、环境事实、测试命令）。
3. 再补一层查找规则：全局层在用户目录，项目层从根目录到当前目录依次拼接，越靠近当前目录越靠后、越优先，所以子目录可以覆盖根规则。
4. 大小上限（Codex 默认 32 KiB）的意义是逼你做取舍：手册太长会挤占任务本身的上下文，还会让模型对每一条规则的遵守度下降。
5. 可预期的追问：写在说明文件里的规则模型一定会遵守吗？不一定，它是提示词的一部分，会被长对话稀释；硬约束要靠沙箱与审批，不是靠文字。