研发黑话 Cheatsheet
AI 导读
研发黑话 Cheatsheet 给产品、研发、AI 应用、Agent、平台架构场景用的高频术语速查表。目标不是背词,而是知道每个词在团队里通常暗示什么。 研发流程 AI / Agent 架构与平台 数据与评估 工程效率 上线运维 01 基础研发黑话 02 AI / Agent 黑话 03 数据 / 检索 / RAG 04 架构 / 平台 / 系统 05 质量 / 测试 / 稳定性 06 项目管理...
研发黑话 Cheatsheet
给产品、研发、AI 应用、Agent、平台架构场景用的高频术语速查表。目标不是背词,而是知道每个词在团队里通常暗示什么。
01 基础研发黑话
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| PRD Product Requirement Document | 需求文档 | 不是“写个需求”这么简单,而是产品边界、场景、流程、规则、验收口径的统一依据。 |
| MVP Minimum Viable Product | 最小可行产品 | 不是简陋版,而是只保留验证核心假设所需的最小闭环。 |
| POC Proof of Concept | 概念验证 | 验证“技术上能不能做”,不负责商业闭环和可运营性。 |
| Spike | 技术试刺 | 短平快试验,先打穿未知点,不做长期工程承诺。 |
| RFC Request for Comments | 设计提案文档 | 大型改动上线前先公开方案,收评论,降低拍脑袋决策。 |
| Schema | 数据结构约束 | 定义“数据长什么样”,字段、类型、关系、约束都在里面。 |
| Primitive / 原语 | 基础能力单元 | 能被反复组合的最小稳定构件,不是一个具体业务功能。 |
| Abstraction | 抽象层 | 把共性提炼成接口;抽象做对,复用和扩展才会快。 |
| Boilerplate | 样板代码 | 重复、基础、必要,但没有业务差异化价值。 |
| Glue Code | 胶水代码 | 负责把多个模块粘起来,常被低估,但在 AI 工作流里很关键。 |
| Monorepo | 单体代码仓 | 多个项目共用一个仓库;统一依赖、统一规范、统一 CI/CD。 |
| Polyrepo | 多仓模式 | 服务分仓管理,团队边界更清晰,但跨仓协作更碎。 |
02 AI / Agent 黑话
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| Context | 模型当前可见的信息 | 不只是窗口长度,还包括系统提示、历史消息、工具返回、检索结果。 |
| Prompt Engineering | 提示词设计 | 给模型施加结构化约束、角色、目标和格式,不等于“会说话”。 |
| Harness | 实验 / 运行框架 | 把输入、任务、评估、环境封装起来,让试验可批量、可重复、可回归。 |
| Agent | 会规划和行动的系统 | 不是普通对话机器人,而是能观察、决策、调用工具、执行任务的闭环体。 |
| Tool Use | 工具调用 | 模型不只“说”,还会查、写、调 API、读文件、执行命令。 |
| Planner | 规划器 | 负责拆任务、定步骤;强规划不等于强执行。 |
| Executor | 执行器 | 按计划调工具、做动作;很多 Agent 失败不是不会想,而是执行落不下去。 |
| Reflection | 反思 | 模型对自己结果做二次检查;用于降低粗糙输出和错误路径。 |
| Memory | 记忆机制 | 短期记忆存会话状态,长期记忆存偏好、事实、经验,不等于简单聊天记录。 |
| Router | 路由器 | 决定任务交给哪个模型、工具、工作流或子 Agent。 |
| Subagent | 子智能体 | 把复杂任务拆给多个角色化执行单元,并行或分层协作。 |
| Eval | 评估体系 | 验证改动到底变好还是变差。没有 eval,Agent 研发基本靠感觉。 |
| LLM-as-a-Judge | 模型当裁判 | 用模型给模型打分,适合主观质量评估,但必须防偏差和提示污染。 |
| Grounding | 让输出有依据 | 把模型回答绑定到外部知识、文档、检索或工具结果,降低胡编。 |
| Hallucination | 幻觉 | 模型说得像真的,但依据并不存在;不是“答错”这么简单,而是伪确定性。 |
| Compaction | 上下文压缩 | 把长对话或历史轨迹压成更短摘要,控制 token 成本与注意力衰减。 |
03 数据 / 检索 / RAG
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| RAG Retrieval-Augmented Generation | 检索增强生成 | 先找资料,再让模型生成答案,核心是“找得对”和“用得好”。 |
| Chunking | 切块 | 把长文档切成可检索小段;切法决定召回质量上限。 |
| Embedding | 向量表示 | 把文本映射到语义空间,便于相似检索;不是“压缩成数组”这么浅。 |
| Recall | 召回 | 相关内容有没有被找回来;RAG 第一关。 |
| Precision | 精准率 | 找回来的内容是不是足够相关;召回太宽会污染上下文。 |
| Rerank | 重排 | 对初步召回结果二次排序,把更相关的片段顶上来。 |
| Top-K | 取前 K 条 | 检索返回多少条候选;K 太小漏信息,太大加噪声。 |
| Hybrid Search | 混合检索 | 关键词检索 + 向量检索,一般比单一路径更稳。 |
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| Vector DB | 向量数据库 | 存 embedding 和索引,用于相似检索,但它本身不等于“知识库”。 |
| Knowledge Graph | 知识图谱 | 用实体、关系、属性表达结构化知识,适合推理与约束,不只是画图。 |
| Ontology | 本体 | 定义“世界里有哪些类、关系、约束”,是图谱和语义系统的规则层。 |
| Metadata | 元数据 | 描述数据的数据,如作者、时间、来源、标签;过滤和追溯很依赖它。 |
| Ground Truth | 标准真值 | 评估时作为对照答案的权威标注。 |
| Data Drift | 数据漂移 | 线上数据分布变了,原来的效果不再成立。 |
| Freshness | 新鲜度 | 知识是否及时更新;新闻、政策、价格场景尤其致命。 |
| Coverage | 覆盖度 | 知识库有没有覆盖真实用户会问的问题域。 |
04 架构 / 平台 / 系统
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| API-first | 接口优先 | 先定义接口契约,再做实现,方便平台化和外部集成。 |
| Contract | 接口契约 | 前后端、服务与服务之间对输入输出的明确约定。 |
| Backward Compatibility | 向后兼容 | 升级后不把老调用方搞挂。 |
| Idempotency | 幂等 | 重复调用多次,结果等价;支付、任务重试、消息消费里很关键。 |
| Stateless | 无状态 | 单次请求不依赖本机历史状态,便于扩容和容灾。 |
| Stateful | 有状态 | 状态要被保存和管理,复杂度更高,但某些业务不可避免。 |
| Orchestration | 编排 | 控制多个服务或步骤按顺序协同工作。 |
| Choreography | 协同自治 | 各服务按事件自行响应,没有单一总控者。 |
| Event-driven | 事件驱动 | 由状态变化触发后续动作,适合异步流程与解耦。 |
| Queue | 消息队列 | 削峰填谷、异步处理、解耦服务的常见基础设施。 |
| Circuit Breaker | 熔断 | 下游挂了时主动断开,防止全链路雪崩。 |
| Rate Limit | 限流 | 限制调用频率,防止系统或三方接口被打穿。 |
| Feature Flag | 特性开关 | 不用重新发版也能控制功能开放范围,是灰度和回滚的基础。 |
| Multitenancy | 多租户 | 同一套系统服务多个客户,隔离、权限、配额是难点。 |
| Observability | 可观测性 | 通过日志、指标、链路追踪看清系统发生了什么。 |
05 质量 / 测试 / 稳定性
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| QA | 质量保障 | 不是只测 bug,而是保证需求、实现、验收都可控。 |
| Test Case | 测试用例 | 把业务规则转成可验证条件,AI 场景里也会扩展成评测集。 |
| Regression | 回归问题 | 新改动把旧能力搞坏了。 |
| Smoke Test | 冒烟测试 | 先看主流程是不是活着,不追求全面。 |
| Golden Set | 黄金样本集 | 一组高质量代表性样本,常用于核心回归验证。 |
| SLA Service Level Agreement | 服务等级承诺 | 对外承诺可用性、响应时间、修复时效。 |
| SLO Service Level Objective | 服务目标 | 内部目标值,如 99.9% 可用性。 |
| SLI Service Level Indicator | 服务指标 | 用来衡量是否达成 SLO 的具体指标。 |
| Error Budget | 错误预算 | 允许系统在一定范围内不完美,用来平衡创新和稳定。 |
| Canary | 金丝雀发布 | 先给极小流量试运行,没炸再放大。 |
| Gray Release | 灰度发布 | 分人群、分流量逐步上线,便于观察和回退。 |
| Rollback | 回滚 | 出问题后快速恢复旧版本,不是补丁修修就算。 |
| MTTR Mean Time To Recovery | 平均恢复时间 | 系统出故障后恢复到正常所需平均时长。 |
06 项目管理 / 协作
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| Roadmap | 路线图 | 说明未来一段时间做什么,不是任务清单,而是方向和优先级表达。 |
| Milestone | 里程碑 | 关键阶段节点,常绑定可交付成果和决策点。 |
| Scope | 范围 | 项目到底做哪些、不做哪些;范围失控是常见死因。 |
| Dependency | 依赖项 | 你能不能推进,取决于谁先完成什么。 |
| Blocker | 阻塞项 | 不解决就没法继续推进的硬障碍。 |
| Alignment | 对齐 | 不是互相知道,而是目标、口径、优先级、责任边界一致。 |
| Owner | 负责人 | 不是参与者,而是对结果负责的人。 |
| DOD Definition of Done | 完成定义 | 做到什么程度才算完成,避免“我以为做完了”。 |
| Acceptance Criteria | 验收标准 | 需求交付时怎么判断达标。 |
| Tech Debt | 技术债 | 为了速度牺牲长期健康留下的后患。 |
| Trade-off | 权衡取舍 | 性能、成本、时效、稳定性、体验之间不能全要。 |
| Escalation | 升级处理 | 跨层级拉人解决问题,常意味着常规路径已经卡住。 |
07 业务化 / 产品化
| 术语 | 直白解释 | 团队里真实含义 |
|---|---|---|
| Productization | 产品化 | 把一个能力做成可售卖、可交付、可运维、可复制的产品。 |
| Scale | 规模化 | 不是用户多了而已,而是系统、组织、成本模型还能撑住。 |
| PMF Product-Market Fit | 产品市场匹配 | 产品真的打中了需求,不靠补贴和意志强推。 |
| Activation | 激活 | 用户第一次真正体验到价值的关键行为。 |
| Retention | 留存 | 用户会不会持续回来;AI 产品尤其容易首日惊艳、后续流失。 |
| Funnel | 漏斗 | 从触达到转化的分阶段流失路径。 |
| North Star Metric | 北极星指标 | 最能代表长期价值创造的核心指标。 |
| Unit Economics | 单元经济模型 | 每个客户、每次调用、每笔订单是不是赚钱。 |
| Paywall | 付费墙 | 免费和付费能力的边界设计,不只是“哪里收费”。 |
| ROI | 投入产出比 | 企业客户最关心:省了多少人、多少时间、多少钱。 |
08 最容易装懂的词
| 词 | 很多人嘴上怎么说 | 真正应该问什么 |
|---|---|---|
| 平台化 | “做个平台统一起来” | 统一的是能力、流程、权限、数据,还是只是 UI 壳子? |
| 智能化 | “接个模型就智能了” | 智能体现在哪个决策环节,成功率提升多少,成本增加多少? |
| 闭环 | “我们已经形成闭环” | 输入、处理、输出、反馈、优化五段是否真的打通? |
| 自动化 | “已经自动跑了” | 异常谁兜底,失败怎么恢复,人工介入点在哪里? |
| 高可用 | “我们做了容灾” | 可用性指标是多少,切换策略是什么,故障演练做过没有? |
| 可扩展 | “后面很好扩” | 扩的是场景、用户量、模型数、租户数,还是组织协作? |
| 企业级 | “我们是企业级方案” | 权限、审计、配额、隔离、可观测、合规、SLA 哪些做了? |
| SOTA | “我们用最先进方案” | 是 benchmark 上最强,还是你这个业务里综合性价比最优? |
极简记忆法
| 维度 | 抓手 | 例子 |
|---|---|---|
| 目标词 | 它想解决什么问题 | MVP 解决“先验证价值,不先做完整” |
| 机制词 | 它靠什么机制起作用 | RAG 靠“检索 + 生成”起作用 |
| 约束词 | 它的代价和边界是什么 | 多租户提升复用,但增加隔离和配置复杂度 |
| 质量词 | 如何判断它做好了 | Eval 看成功率、回归、成本、延迟 |
| 组织词 | 它会改变谁的协作方式 | 平台化会重塑研发、产品、运维边界 |
深度加工(NotebookLM 生成)
基于本文内容生成的 PPT 大纲、博客摘要、短视频脚本与 Deep Dive 播客,用于多场景复用
PPT 大纲(5-8 张幻灯片) 点击展开
研发黑话 Cheatsheet — ppt
这是一份基于您提供的《研发黑话 Cheatsheet》为您提取并整理的 8 张 PPT 大纲,采用 Markdown 格式输出:
研发黑话 Cheatsheet:高效沟通指南
- 核心目标:梳理高频术语,目的不是背诵名词,而是理解每个词在团队沟通中真实暗示的边界、场景与规则 [1]。
- 适用人群:产品、研发、AI 应用、Agent 开发以及平台架构场景的团队成员 [1]。
- 沟通本质:真正的沟通能力不是会说黑话,而是能将黑话还原为具体的问题、约束、机制、指标与代价 [2, 3]。
- 核心应用:可作为团队日常速查、新人培训、统一口径以及评审前扫盲的工具 [3]。
基础研发与系统架构
- 需求与验证:PRD 负责统一产品边界和验收口径,MVP 用于验证最小核心闭环,POC 仅验证技术可行性而不负责商业闭环 [1]。
- 代码与抽象:Schema 定义数据结构与约束,Abstraction 提炼共性以提升复用率,Monorepo/Polyrepo 则决定了代码仓的统分管理模式 [1]。
- 架构设计理念:API-first 强调先定义接口契约,无状态(Stateless)设计便于扩容,而事件驱动(Event-driven)适合异步流程与解耦 [4]。
- 稳定性基建:需关注 Idempotency(幂等性)以防重复调用出错,并利用 Circuit Breaker(熔断)和 Rate Limit(限流)防止全链路雪崩 [4]。
AI 与 Agent 核心术语
- 模型交互基础:Context 包含窗口长度、系统提示及检索结果,Prompt Engineering 则是给模型施加结构化约束与角色 [1]。
- Agent 闭环能力:Agent 不是普通聊天机器人,而是具备观察、决策、工具调用(Tool Use)和执行任务能力的闭环系统 [5]。
- 核心组件分工:Planner 负责拆解任务,Executor 负责落地执行,Memory 区分长短期以存储状态和经验,Router 则决定任务的分发路径 [5]。
- 评估与保障:没有 Eval(评估体系)的研发只能靠感觉,常借助 LLM-as-a-Judge(模型当裁判)评估主观质量,并通过 Grounding 降低模型幻觉(Hallucination) [5]。
数据检索与 RAG 机制
- RAG 系统核心:检索增强生成(RAG)的核心是“找得对”和“用得好”,难点在于切块、召回、重排、评估等全链路闭环 [4, 5]。
- 数据处理与映射:Chunking(切块)方式直接决定召回质量的上限,Embedding 则负责将文本映射到语义空间以供检索 [5]。
- 检索质量控制:Recall 决定是否找回相关内容,Precision 衡量内容相关度,通过 Top-K 控制数量,并常采用混合检索(Hybrid Search)提升稳定性 [4, 5]。
- 知识底座:Vector DB(向量数据库)仅用于存索引而非完整的知识库,Knowledge Graph(知识图谱)适合结构化知识推理,Data Drift 则需警惕线上数据分布改变导致的效果衰减 [4]。
质量控制与稳定性保障
- 测试与回归:QA 需保证从需求到验收全盘可控,通过 Smoke Test(冒烟测试)看主流程,用 Golden Set(黄金样本集)验证核心功能是否发生退化(Regression) [6]。
- 发布与控制:Feature Flag(特性开关)是灰度和回滚的基础,发布时可采用 Canary(金丝雀)极小流量试水或 Gray Release(灰度发布)逐步放量 [4, 6]。
- 可用性承诺:对外提供 SLA(服务等级承诺),内部盯紧 SLO/SLI 目标,并利用 Error Budget(错误预算)平衡创新速度与系统稳定性 [6]。
- 成熟团队标志:不在于系统从不出错,而在于 MTTR(平均恢复时间)短,即发现快、定位准、恢复快、复盘狠 [6]。
项目协作与交付管理
- 目标与职责对齐:通过 Roadmap 明确未来方向与优先级,确保团队 Alignment(目标、口径、边界一致),并由 Owner 对最终结果负责 [2, 6]。
- 交付标准管控:明确 DOD(完成定义)避免“以为做完了”,依托 Acceptance Criteria 作为需求达标的验收依据,并严格控制项目 Scope(范围)防止失控 [2, 6]。
- 技术与速度权衡:研发过程需要 Trade-off(权衡取舍),为追求速度可能留下 Tech Debt(技术债),遇到阻塞项(Blocker)需及时拉起 Escalation(升级处理) [2, 6]。
业务视角与产品化思维
- 从能力到产品:Productization 要求将技术能力转化为可售卖、可交付的产品,并在 Scale(规模化)时确保系统与成本模型不崩溃 [2]。
- 市场与用户验证:追求 PMF(产品市场匹配)而非强推,关注用户 Activation(首次体验价值)和 Retention(留存),警惕 AI 产品首日惊艳后续流失的陷阱 [2]。
- 商业价值衡量:盯紧 North Star Metric(北极星核心指标),通过 Funnel(漏斗)分析转化,最终看 ROI(投入产出比)和 Unit Economics(单元经济模型)是否赚钱 [2]。
避坑指南:最容易“装懂”的词汇
- “平台化”与“智能化”:需追问“平台化”统一的是能力流程还是仅有 UI 壳子;“智能化”体现在哪个环节、提升了多少成功率及成本 [2]。
- “闭环”与“自动化”:需确认输入、处理、输出到反馈五段是否真打通;自动化失败时谁来兜底以及人工介入点在哪 [2]。
- “高可用”与“企业级”:要量化可用性指标和切换策略,明确是否做好了权限、审计、隔离等企业级合规与 SLA 保障 [2]。
- 极简还原法:遇到黑话时,按“目标词(解决什么)”、“机制词(靠什么起作用)”、“约束词(代价边界)”、“质量词(如何评判)”进行拆解还原 [3]。
博客摘要 + 核心看点 点击展开
研发黑话 Cheatsheet — summary
SEO 友好博客摘要:
这份《研发黑话 Cheatsheet》是一份专为产品、研发及 AI 应用团队打造的高频术语速查指南[1]。文章全面解析了从基础研发、AI/Agent 架构、数据与 RAG 技术,到系统稳定性、项目管理及产品商业化等核心场景的真实语境[1-5]。它不仅帮助互联网从业者告别“背词”,更能深度理解 MVP、Prompt、RAG 等高频词汇背后的业务问题、技术代价与协作边界[1-3, 6]。无论是新人扫盲还是跨部门对齐沟通,本文都能助你快速识破“伪理解”,提升团队协作与项目交付效率,是互联网人必读的实战指南[1, 4, 6]。
核心看点:
- 全场景术语解析:涵盖 AI/Agent、RAG、架构等8大核心领域,直击团队真实语境[1, 2]。
- 洞悉底层逻辑:拒绝死记硬背,深度剖析术语背后的业务问题、技术代价与协作边界[1, 6]。
- 跨部门协作利器:提供极简记忆法,助力团队统一口径、高效对齐,扫清沟通障碍[4, 6]。
60 秒短视频脚本 点击展开
研发黑话 Cheatsheet — video
这是一段为您定制的 60 秒短视频脚本,严格按照您的字数与结构要求编写:
【钩子开场】
研发黑话太绕?一招带你看透!
【核心解说】
- 基础认知:MVP绝非做个简陋版,而是只保留验证核心假设的最小闭环[1]。
- AI 语境:Agent不是普通机器人,而是能观察决策、调用工具的闭环体[2]。
- 沟通本质:懂黑话不是会背词,而是能将其还原为问题、代价与边界[1, 3]。
【一句收束】
拒绝盲目装懂,直击业务背后的真实诉求!
课后巩固
与本文内容匹配的闪卡与测验,帮助巩固所学知识
延伸阅读
根据本文主题,为你推荐相关的学习资料