面试题库
共 328 题,当前筛选 2 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#prompt-basics2#cost14#evaluation14#reliability12#agent-skills11#architecture11#observability10#error-handling9#security9#api-design6#coding-agent6#debugging5
还有 235 个标签收起标签
#idempotency5#streaming5#structured-output5#chunking4#deployment4#distributed-systems4#rag4#system-prompt4#tool-calling4#client3#embeddings3#failure-modes3#ingestion3#mcp3#message-bus3#operations3#progressive-disclosure3#ranking3#timeline3#agent-loop2#agentic-rag2#agents-sdk2#caching2#citations2#code-review2#communication2#concurrency2#consistency2#context2#context-engineering2#context-rot2#cost-control2#data-modeling2#grounding2#hybrid-search2#langgraph2#latency2#model-migration2#model-routing2#multi-agent2#ordering2#pipeline-design2#prompt-engineering2#protocol2#rate-limiting2#react2#redis-streams2#responses-api2#retrieval2#retrieval-quality2#routing2#runtime2#sse2#state-management2#statelessness2#subagents2#system-design2#tool-design2#tooling2#tracing2#trade-offs2#transport2#vector-database2#versioning2#workflow2#abstention1#access-control1#agent-design1#agent-quality1#altitude1#approvals1#async1#async-task1#atomicity1#attention-budget1#auth1#av-sync1#behavioral1#bm251#candidate-selection1#capacity-planning1#chain-of-thought1#checkpointing1#ci1#citation-verification1#claude-code1#cli-design1#cloud1#compaction1#compression1#content-hash1#context-compression1#context-window1#contextual-retrieval1#cost-optimization1#cross-model1#dag1#data-quality1#database1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#distribution1#docker1#documentation1#engineering-judgement1#engineering-tradeoffs1#eval1#event-driven1#fallback1#fan-out1#ffmpeg1#forking1#four-elements1#framework-design1#framework-selection1#golden-set1#hallucination1#handoffs1#headless1#hnsw1#hybrid1#hyde1#image-generation1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#intent-routing1#interrupt-merge1#interview-prep1#invalidation1#isolation1#ivfflat1#just-in-time1#knowledge-organization1#lease1#llm-as-judge1#llm-output-quality1#long-context1#loop-guard1#media-pipeline1#metadata1#metrics1#mobile1#model-selection1#multi-tenancy1#multimodal1#nodejs1#orchestration1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#prioritization1#production-readiness1#prompt-assembly1#prompt-caching1#prompt-injection1#prompt-limits1#prompt-techniques1#prompt-template1#prompt-versioning1#provider-abstraction1#quality-check1#quantization1#query-transformation1#quiet-hours1#rank-fusion1#reasoning1#recall1#redis1#reflection1#refusal1#reporting1#reproducibility1#rerank1#retrieval-failure1#retrieval-metrics1#retry1#retry-semantics1#retry-strategy1#review1#rollback1#rrf1#sandbox1#sandboxing1#scalability1#scheduling1#schema-design1#scoping1#scripts1#secrets-management1#self-assessment1#self-presentation1#self-reflection1#service-architecture1#session-management1#sessions1#sharding1#skill-authoring1#skill-description1#skills1#spec1#state-machine1#stateless1#stopping-criteria1#subtitles1#task-graph1#team-governance1#testing1#tool-budget1#tool-execution1#tool-naming1#tools1#tts1#tuning1#ux1#validation1#vector-index1#verification1#workflow-engine1#xml-tags1
5 天提示词工程零基础
D1 提示词是什么、不是什么:模型如何读指令;角色 / 任务 / 格式 / 约束四要素
角色、任务、格式、约束四要素各解决什么问题?如果只能保留三个,你会砍掉哪个,为什么?What problem does each of the four prompt elements — role, task, format, constraints — solve? If you could keep only three, which would you drop and why?
国内高频海外高频进阶#prompt-basics#four-elements分析过程 · 先想清楚再作答
- 前半句是送分,后半句才有区分度:它在考你是否知道每个要素对应模型的哪一种「猜」,以及哪种猜错的代价最小。
- 拆法:把每个要素映射到一个「模型会猜错的地方」——角色对应视角与关注点,任务对应终点在哪,格式对应输出能否被程序消费,约束对应改动范围与不可碰的边界。
- 判断哪个可砍:看缺了之后是「结果不稳定」还是「结果不可用」。缺角色多半是关注点偏了但仍可用;缺任务的完成标准会让模型不知何时停;缺格式会让下游解析失败;缺约束会让改动面失控。
- 结论:多数工程场景下角色最可砍,因为任务与格式写得足够具体时视角已经被隐含;但要说明前提是任务里已经写清了关注点。
- 追问几乎必然是「那为什么大家还都写角色」——答案是它便宜且能一句话压缩大量隐性偏好,在任务没法写得很细的对话场景里性价比最高。
How to reason about it · think before answering
- The first half is a warm-up; the second half tests whether you can map each element to a specific way the model would otherwise guess, and rank the cost of each wrong guess.
- Map them: role fixes perspective and focus, task fixes the finish line, format decides whether downstream code can consume the output, constraints bound the change surface.
- To pick the one to drop, ask whether its absence makes results unstable or unusable. Missing role skews focus but stays usable; missing done-criteria means the model never knows when to stop; missing format breaks parsers; missing constraints lets edits sprawl.
- Conclusion: in most engineering settings role is the most droppable, because a specific task plus a strict format already imply the perspective — provided the task states what to care about.
- Expect the follow-up 'then why does everyone write a role?' Because it is cheap and compresses many implicit preferences into one line, which pays off in chat-style use where the task cannot be fully specified.
答题要点
- 角色定视角与关注点;任务定做什么与完成标准;格式定输出形状是否可机械核对;约束定不可碰的边界与理由
- 每个要素对应模型的一种「猜」,缺哪个就多一种不稳定
- 可砍的是角色:任务与格式足够具体时视角已隐含,但前提是任务里写清了关注点
- 任务的完成标准与格式的可核对性最不能省,因为它们直接决定输出能不能被程序消费
Key points
- Role sets perspective; task sets the goal and done-criteria; format makes output mechanically checkable; constraints bound scope with reasons
- Each element removes one kind of guess the model would otherwise make
- Role is the most droppable once task and format are specific enough to imply the perspective
- Done-criteria and checkable format are the least negotiable because downstream code depends on them
为什么规则要放系统提示而不是用户消息?请从遵从度、管控和成本三个角度说明,并指出系统提示做不到什么。Why do rules belong in the system prompt rather than the user message? Cover adherence, control, and cost, and name what the system prompt cannot guarantee.
国内高频海外高频进阶#system-prompt#prompt-basics分析过程 · 先想清楚再作答
- 题眼在「三个角度」和「做不到什么」。只答「系统提示权重高」是背概念,面试官要看的是你有没有在生产里拼过系统提示。
- 拆法:遵从度看多轮稀释——用户消息会被后续对话淹没,系统提示全程生效;管控看谁能改——系统提示由后端统一拼装、用户碰不到,规则放这里才能对所有用户一致;成本看缓存——提示缓存按前缀命中,系统提示是最稳定的前缀。
- 「做不到什么」是区分度所在:系统提示遵从度高不等于绝对,提示注入可以让模型跑偏,所以安全边界不能只靠系统提示,要在模型外用代码兜底。
- 结论:规则进系统提示是为了稳定、一致、省钱;但它是「强建议」不是「硬约束」,硬约束必须在代码层实现。
- 追问方向:系统提示可以放在对话末尾吗?可以但不推荐——多数模型对靠前指令更敏感,且会破坏缓存前缀;另一个追问是「哪些内容不该进系统提示」,答案是每次都变的任务细节,放进去会让缓存失效且难以复用。
How to reason about it · think before answering
- The tell is whether you cover all three angles and name a limitation. 'System prompts carry more weight' alone reads as memorized.
- Adherence: user turns get diluted as the conversation grows, the system prompt stays in force. Control: the backend assembles the system prompt and users cannot touch it, so rules apply uniformly. Cost: prompt caching matches on prefixes, and the system prompt is the most stable prefix.
- The limitation is the differentiator: higher adherence is not a guarantee, prompt injection can still steer the model, so security boundaries need code-level enforcement outside the model.
- Conclusion: rules go in the system prompt for stability, consistency and cost, but it is a strong suggestion, not a hard constraint.
- Follow-ups: can the system prompt go last? Possible but unwise — models weight early instructions more and it breaks the cache prefix. What should stay out? Per-request task details, which would bust the cache and hurt reuse.
答题要点
- 遵从度:用户消息会被多轮对话稀释,系统提示全程生效
- 管控:系统提示由后端统一拼装,用户碰不到,规则才能对所有人一致
- 成本:提示缓存按前缀命中,系统提示是最稳定的前缀,不变的内容集中在这里最省钱
- 做不到的:它不是安全边界,提示注入可以绕过,硬约束必须在代码层兜底
Key points
- Adherence: user turns get diluted over a long conversation, the system prompt stays in force
- Control: the backend assembles it and users cannot edit it, so rules apply to everyone
- Cost: prompt caching matches prefixes, so stable content in the system prompt maximizes cache hits
- Limit: it is not a security boundary; prompt injection can bypass it, so enforce hard rules in code