面试题库
共 328 题,当前筛选 1 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#cost-accounting1#pipeline-design7#consistency4#cost4#error-handling4#image-generation3#observability3#timeline3#workflow-engine3#architecture2#async-task2#caching2
还有 59 个标签收起标签
#ffmpeg2#idempotency2#media-pipeline2#provider-abstraction2#rate-limiting2#reproducibility2#retry2#scheduling2#tts2#agent-loop1#analytics1#architecture-review1#av-sync1#backoff1#budget-control1#build-vs-buy1#candidate-selection1#circuit-breaker1#compliance1#concurrency1#content-safety1#copyright1#cost-analysis1#cost-control1#dag1#data-modeling1#debugging1#degradation1#encoding1#evaluation1#fairness1#feedback-loop1#human-in-the-loop1#incremental-recompute1#integration1#labeling1#llm-output-quality1#moderation1#multimodal1#offline-testing1#pipeline-reliability1#priority-queue1#project-storytelling1#prompt-assembly1#prompt-injection1#quality-check1#resume1#retry-strategy1#rollback1#schema-validation1#state-management1#state-persistence1#structured-output1#subtitles1#system-design1#task-graph1#test-strategy1#trade-offs1#versioning1
14 天用 Agent 搭一条 AI 短剧生产线
D7 一集杀青:把六个环节串成端到端流水线并算清第一笔账
怎么度量一条生成流水线的成本?除了钱还要量什么?How do you measure the cost of a generation pipeline, and what besides money should you measure?
国内高频海外高频基础#observability#cost-accounting#pipeline-design分析过程 · 先想清楚再作答
- 这题看着是送分题,题眼其实在「除了钱」。只报一个总金额的人,做不出任何优化决策,因为总金额不告诉你该动哪里。
- 第一步是确定度量的粒度:**按环节摊开**。一个总数没有信息量,一张按环节分列的表能立刻告诉你钱花在哪、时间花在哪。本课量过一集:五张图一毛二五、配音不到两分、三个镜头的视频十块五,视频占了九成八——这个结论只有摊开才看得见。
- 第二步是把「钱」之外的三样一起量:耗时决定一天能出几集;调用次数决定会不会撞上厂商的速率限制;产物数是最朴素的完整性校验,四个镜头就该有四个视频,少一个说明某处静默失败了。
- 第三步是把估算和真实分开。离线或压测时拿不到真实金额,可以按公开单价折算,但**必须标明它是折算值**,而且折算逻辑和真实金额不能混在一条路径上算,否则账永远对不上。
- 还要提醒一句常被忽略的:离线模式下的耗时排名往往是假的。接口被打了桩,本地的编码步骤反而成了大头,照着这张图做优化会优化错地方。
- 可预期的追问是「量完之后先优化哪一项」。答:先优化能被数字证明收益的那一项。这个场景里是失败重跑造成的浪费,因为它直接等于账单上的金额;并发排第二,因为在产出还不稳定时并发只会让你更快地烧钱。
How to reason about it · think before answering
- This looks like a giveaway, but the real question is 'besides money'. Anyone who reports a single total cannot make an optimization decision, because a total does not say where to act.
- First decide the granularity: break it down per stage. One number carries no information; a per-stage table immediately shows where the money and the time went. Measured on one episode here: five images cost 0.125 yuan, voice under two cents, three video shots 10.5 yuan — video is 98 percent. You only see that broken down.
- Second, measure three things besides money: elapsed time decides how many episodes per day, call count decides whether you hit provider rate limits, and artifact count is the crudest completeness check — four shots should yield four clips, and a missing one means something failed silently.
- Third, separate estimates from real spend. Offline or in load tests you have no real amounts, so derive them from published unit prices — but label them as estimates, and never mix the two on one code path or the books will never reconcile.
- Also worth flagging: offline timing rankings are usually fake. With the APIs stubbed, local encoding becomes the biggest slice, and optimizing against that chart targets the wrong thing.
- Expect the follow-up 'what do you optimize first'. Answer: whatever has a number attached. Here it is waste from failed reruns, because it equals money on the bill. Concurrency comes second — before output is stable, concurrency only burns money faster.
答题要点
- 按环节摊开,不要只给一个总数,否则无法定位该优化哪里。
- 除了金额还要量耗时、调用次数、产物数,各自对应吞吐、限流、完整性。
- 估算与真实金额分开计算,估算必须标明是折算值。
- 注意离线模式下耗时排名不可信,别照着假图做优化。
- 优化顺序按「收益能不能被数字证明」排,不按直觉排。
Key points
- Break the cost down per stage; a single total cannot tell you where to act.
- Besides money, measure elapsed time, call count and artifact count — throughput, rate limits and completeness.
- Keep estimated and real spend on separate paths, and always label estimates as estimates.
- Offline timing rankings are unreliable; do not optimize against a stubbed profile.
- Prioritize by which improvement has a number attached, not by intuition.