Vibe Coding 心得，AI 像一门更高级的编程语言
AI 把写代码抬到了更高的抽象层。从需求、开发、测试到运维和宣发，准确的专业语言仍然决定产品质量。
以前用高级语言开发，我们很少关心一条 Java 语句最后变成了哪些机器指令。编译器接走了这部分工作，人开始把精力放在类型、对象、接口和业务模型上。
现在用 AI 写代码，我有一种相似的感觉。人给出目标和约束，agent 读项目、改文件、跑测试，再把结果交回来。我们操作的对象又往上抬了一层，从代码语句变成了意图、领域规则和验收条件。
所以我愿意把 AI 看成一门更高级的编程语言。
这只是一个工程上的类比。Java、Go 这类语言有确定的语法和语义，同一份代码交给同一个编译器，结果大体可预期。自然语言容许省略和歧义，模型还会根据上下文猜测。它有时猜得很准，有时会给出一份结构完整、方向却偏了的实现。传统编译器会在语法错误时停下来，agent 更可能沿着一个合理猜测继续干活。
抽象层升高以后，软件工程没有退出。需求、设计、测试和交付仍在，只是更多工作发生在写代码之前和生成代码之后。
先分清 Vibe Coding 和 AI Coding
Section titled “先分清 Vibe Coding 和 AI Coding”Vibe Coding 现在经常被用来泛指 AI 写代码，它最初的意思更窄。
Simon Willison 沿用 Andrej Karpathy 的定义，把 Vibe Coding 解释为不再阅读模型生成的代码，只看运行效果，把报错继续交给模型处理。这种方式很适合一次性脚本、周末原型和低风险试验。生产代码需要另一套要求。开发者要读变更、跑测试，还要能向别人解释系统怎样工作。
Martin Fowler 把后一种工作方式称为 agentic programming。人可能不再逐行敲代码，仍然要对软件的行为和实现负责。Kent Beck 在用 AI 编写 B+ Tree 时也保留了 TDD、复杂度控制和设计判断。他的前两次尝试积累了太多复杂度，agent 最后无法继续。后续尝试缩小了目标范围，他也更早介入设计，不再让 agent 一直往前写。
标题沿用大家熟悉的 Vibe Coding。涉及需要长期维护的项目时，本文说的是认真交付软件的 AI Coding。
AI 接走了编码，意图需要有人说清楚
Section titled “AI 接走了编码，意图需要有人说清楚”高级语言把机器指令藏到了编译器后面，开发者仍要准确表达程序。AI 又藏掉了一部分代码细节，表达准确反而更重要了。
一句“给订单加个退款功能”足够让 agent 开始工作，也足够让它走错方向。它不知道退款由谁发起，不知道支付渠道能否部分退款，也不知道重复回调会不会重复记账。项目里的旧接口、状态机和审计要求，都可能被一句过于宽松的需求漏掉。
一份能工作的任务说明至少要回答下面这些问题。
| 部分 | 要说清楚的内容 |
|---|---|
| 目标 | 哪个用户在什么情况下需要完成什么事 |
| 现状 | 相关代码、数据和既有流程在哪里 |
| 约束 | 哪些接口不能改，性能、安全和兼容边界是什么 |
| 领域规则 | 哪些状态允许转换，哪些条件始终成立 |
| 验收 | 用什么测试、页面行为、日志或指标判断完成 |
| 变更范围 | 允许修改哪些模块，哪些内容明确留到以后 |
任务说明不靠长度取胜。好的任务说明会减少猜测，差的长 prompt 只是把模糊的话重复几遍。关键约束应该能被代码、测试或运行结果验证。
OpenAI 介绍 Codex 工程实践时提到，团队的主要工作逐渐变成设计环境、描述意图和建立反馈循环。早期进展慢，原因在于环境没有说清，agent 缺少工具、抽象和项目结构。后来他们把设计、实现、审查和测试拆成可执行的环节，agent 才能承担更完整的任务。
这条经验和传统软件工程很接近。需求要能落到验收条件，设计给实现划出边界。代码进入项目以后，测试指出偏差，版本控制留下变化过程。AI 提高了生成速度，这些约束也要跟上。
专业术语是压缩过的工程知识
Section titled “专业术语是压缩过的工程知识”和 agent 沟通时，掌握专业术语很有用。一个准确术语可以同时带出定义、边界和一组成熟方案。
比如“重复消息不能重复扣款”已经说明了业务目标。再补上 at-least-once delivery、幂等键和事务边界，agent 才知道重复从哪里来，应该在哪一层消除，哪些写入需要一起成功。只说“做一下防重”，它可能在内存里放一个布尔值，也可能随手加一把分布式锁，两种实现看起来都像完成了需求。
术语也会被用错。“最终一致性”不能替代可接受延迟、失败补偿和用户看到的中间状态。“微服务”也不能说明服务该怎样拆。开发者需要知道一个词解决什么问题，有哪些前提，会增加什么成本。懂到这个程度，术语才会帮 agent 缩小解空间。
领域里的专业术语更重要。同一个项目里，“客户”“账户”“订单”“任务”分别指什么，必须保持稳定。领域驱动设计把这叫作通用语言。人和 agent 共用同一套词，数据库字段、类名、接口和文档才不容易各说各话。
软件工程理论会变得更显眼
Section titled “软件工程理论会变得更显眼”AI 很擅长补齐样板代码，熟悉主流框架，也能快速尝试几个方案。它不替团队决定需求优先级，不承担线上事故的后果，也不知道一个看似多余的兼容分支为什么已经保留了三年。
软件工程原来处理的就是这些问题。需求工程和领域建模把目标、概念说清，架构设计控制变化范围。实现进入代码库以后，测试和可观测性提供反馈，发布工程再把风险限制在可恢复的范围里。AI 能生成其中许多产物，仍需要有人判断它们是否服务于同一个目标。
Addy Osmani 在总结自己的 AI Coding 工作流时，仍然坚持设计、测试、版本控制和代码审查。他发现模型看到测试失败或 lint 结果后，会主动修正实现。Kent Beck 也把循环、擅自增加功能、删除测试当作 agent 偏航的信号。两人的工具和项目不同，依赖的反馈都很朴素。
描述给出方向，术语减少歧义。测试提供硬反馈，让错误尽早暴露。缺少这些条件，agent 很可能快速产出一大批需要返工的代码。
代码之外还有一整条交付链
Section titled “代码之外还有一整条交付链”代码写完只是交付过程的中段。前面有人判断问题值不值得解决，把想法收成明确范围。后面还有测试、部署和运行，产品上线以后还要让目标用户看见、理解并愿意尝试。
小团队和独立开发者尤其容易漏掉这些环节。agent 可以生成页面、接口、测试、部署脚本和宣传文案，却不知道产品面对谁，也不会替人决定一个版本什么时候值得发布。每个环节都有一套长期形成的专业语言。听懂这些词，才能知道该向 agent 交代什么，哪些结果需要自己判断。
三个容易混用的词可以先分开。验收标准描述需求完成后能观察到什么，测试用例记录怎样操作和检查，完成定义约束一个工作项达到什么状态才可以结束。部署表示把代码放进某个环境，发布表示让某项能力对用户可用，正式上线还会连着公告、渠道和运营动作。词用准以后，任务边界会清楚很多。
已有的 Vibe Coding 提示词实践 讲任务怎样写得更具体，Matt Pocock Skills 拆解 讲怎样把术语、规格、TDD 和诊断流程固化成可执行的 Skills。这篇只补一个认识。我们少写了很多语法，仍然要理解自己正在建什么。
附录 从需求到宣发的专业术语索引
Section titled “附录 从需求到宣发的专业术语索引”下面按一项产品工作通常经过的环节排列。它不追求教科书式定义，只记录一个词能帮我们说清什么。团队之间的叫法会有差异，使用前还要结合项目里的具体约定。
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 目标用户 Target User | 产品优先服务的具体人群 | 判断功能为谁解决问题，哪些人暂时不在范围内 |
| 问题陈述 Problem Statement | 用户处境、现有阻碍和期望变化 | 在讨论功能以前确认问题是否真实 |
| 待办任务 Jobs to Be Done | 用户在某个情境下想完成的进展 | 避免把需求只写成页面和按钮 |
| 用户故事 User Story | 某类用户为了某个目的需要一种能力 | 把需求放回用户、目标和价值中表达 |
| 用例 Use Case | 角色与系统完成目标的交互过程 | 展开主流程、异常流程和边界条件 |
| 产品需求文档 PRD | 记录目标、范围、规则和验收约定 | 让产品、设计、开发和测试依据同一份需求工作 |
| 功能需求 Functional Requirement | 系统需要提供的具体行为 | 描述用户能做什么，系统应该怎样响应 |
| 非功能需求 Non-functional Requirement | 性能、安全、可靠性和兼容性要求 | 防止功能可用却无法在真实环境交付 |
| 范围 Scope | 当前版本明确包含和排除的内容 | 控制任务膨胀，给 agent 划出允许修改的边界 |
| 约束 Constraint | 方案必须遵守的技术或业务限制 | 保留兼容接口、合规规则、预算和时间边界 |
| 验收标准 Acceptance Criteria | 判断需求完成的可观察条件 | 把“做好了”改成页面行为、接口结果或指标 |
| 最小可行产品 MVP | 用最小范围验证核心假设的版本 | 在大量投入前验证用户是否真的需要 |
| 需求池 Backlog | 尚未完成并持续排序的工作集合 | 管理后续需求、缺陷和技术改进 |
| 就绪定义 Definition of Ready | 工作项进入开发前应具备的条件 | 检查目标、依赖、范围和验收是否足够清楚 |
| 完成定义 Definition of Done | 工作项结束前必须满足的统一质量条件 | 约束代码、测试、文档和发布准备是否齐全 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 通用语言 Ubiquitous Language | 团队在代码和交流中共同使用的领域语言 | 统一业务名词、数据字段和代码命名 |
| 领域模型 Domain Model | 业务概念、关系、行为和规则的表达 | 把真实业务翻译成可以设计和实现的结构 |
| 限界上下文 Bounded Context | 一套领域模型保持明确含义的边界 | 处理同名概念在不同业务中的差异 |
| 不变量 Invariant | 系统运行中始终要成立的规则 | 定义金额、状态和权限不能破坏的条件 |
| 状态机 State Machine | 状态、事件和允许转换的集合 | 设计订单、审批、任务和设备生命周期 |
| 契约 Contract | 调用双方对输入、输出、错误和兼容性的约定 | 设计 API、事件和模块接口 |
| 架构决策记录 ADR | 一项关键设计选择及其背景和取舍 | 保存以后难以从代码里还原的决策原因 |
| 耦合 Coupling | 模块之间相互依赖的程度 | 判断一次修改会影响多少地方 |
| 内聚 Cohesion | 一个模块内部职责相关的程度 | 判断代码是否围绕同一件事组织 |
| 事务边界 Transaction Boundary | 需要一起提交或一起回滚的一组操作 | 划定数据一致性的范围 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 概念验证 Proof of Concept | 一条关键技术路线是否可行 | 在正式设计前验证最不确定的技术点 |
| 技术探针 Spike | 有时间限制的调查或试验任务 | 估算未知成本，比较候选方案 |
| 征求意见稿 RFC | 可讨论的方案、接口和取舍说明 | 在大改动开始前收集团队反馈 |
| 任务拆分 Task Breakdown | 把目标拆成可独立验证的小任务 | 控制 agent 单次改动范围并安排依赖顺序 |
| 分支 Branch | 与主线隔离的一组代码变化 | 并行开发功能、修复和实验 |
| 提交 Commit | 带有说明的最小版本变化记录 | 保存可审查、可回退的工作节点 |
| 合并请求 Pull Request | 请求把一组变更合入目标分支 | 集中展示差异、测试结果和讨论 |
| 代码审查 Code Review | 检查实现、风险和可维护性的过程 | 在合并前发现设计偏差和隐蔽错误 |
| 重构 Refactoring | 在保持外部行为的前提下改进代码结构 | 降低后续修改成本，清理重复和混乱职责 |
| 技术债 Technical Debt | 为短期速度留下的未来维护成本 | 决定哪些妥协需要记录和偿还 |
| 语义化版本 Semantic Versioning | 用主版本、次版本和修订号表达兼容变化 | 发布库、API 和可复用组件 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 用户界面 UI | 用户直接看到和操作的页面元素 | 讨论布局、组件、视觉层级和交互状态 |
| 用户体验 UX | 用户完成目标时经历的完整过程 | 评估流程是否清楚、顺畅且可恢复 |
| 信息架构 Information Architecture | 内容、页面和导航之间的组织关系 | 设计栏目、菜单、层级和查找路径 |
| 设计系统 Design System | 可复用的视觉规则、组件和使用约定 | 保持多个页面与产品的一致性 |
| 设计令牌 Design Token | 颜色、字号、间距等基础设计值 | 让设计规则能在代码中统一复用 |
| 组件 Component | 封装界面结构、行为和样式的单元 | 复用按钮、表单、卡片和业务模块 |
| 状态管理 State Management | 界面状态的来源、更新和共享方式 | 处理跨组件数据、异步请求和复杂交互 |
| 客户端渲染 CSR | 页面主要在浏览器中生成 | 构建交互密集的单页应用 |
| 服务端渲染 SSR | 服务器在请求时生成页面 HTML | 改善首屏、动态内容和搜索收录 |
| 静态生成 SSG | 构建阶段提前生成页面 HTML | 发布博客、文档和变化较少的内容 |
| 水合 Hydration | 给服务端生成的 HTML 接上客户端交互 | 排查页面可见却暂时不能操作的问题 |
| 响应式设计 Responsive Design | 页面适配不同屏幕和输入方式 | 处理手机、平板和桌面布局 |
| 可访问性 Accessibility | 残障用户也能感知和操作界面的能力 | 检查键盘、读屏、对比度和语义结构 |
| 核心网页指标 Core Web Vitals | 衡量加载、响应和视觉稳定性的指标 | 发现真实用户感受到的前端性能问题 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 应用接口 API | 软件之间交换能力和数据的边界 | 连接前端、后端和外部服务 |
| REST | 以资源和 HTTP 语义组织接口的风格 | 设计常规 Web API |
| RPC | 像调用函数一样请求远程服务执行操作 | 处理内部服务间的明确命令调用 |
| Webhook | 事件发生后由服务主动回调外部地址 | 接收支付、仓库和第三方平台通知 |
| 中间件 Middleware | 在请求主逻辑前后执行的通用处理 | 统一认证、日志、限流和错误处理 |
| 认证 Authentication | 确认请求者是谁 | 登录、令牌校验和设备身份识别 |
| 授权 Authorization | 判断请求者可以做什么 | 角色权限、资源归属和数据隔离 |
| 数据迁移 Schema Migration | 受版本管理的数据结构变更 | 新增字段、修改索引和升级生产数据库 |
| 索引 Index | 用额外数据结构加速查询 | 优化数据库检索、排序和关联 |
| 缓存 Cache | 保存可复用结果以减少重复计算或访问 | 降低延迟和数据库压力 |
| 消息队列 Message Queue | 暂存并异步传递待处理消息 | 削峰、重试和解耦耗时任务 |
| 发布订阅 Pub/Sub | 发布方把事件分发给多个订阅方 | 驱动跨模块事件和异步协作 |
| 幂等 Idempotency | 同一业务请求重复执行不产生额外结果 | 处理重试、重复回调和消息重复消费 |
| 最终一致性 Eventual Consistency | 允许短暂不一致，并按规则收敛 | 设计异步流程和跨服务协作 |
| 背压 Backpressure | 下游处理不过来时限制上游输入 | 保护队列、流式任务和推理服务 |
| 限流 Rate Limiting | 限制单位时间内的请求数量 | 防止突发流量耗尽服务资源 |
| 超时与重试 Timeout and Retry | 限定等待时间并处理暂时性失败 | 调用网络服务和不稳定依赖 |
| 熔断 Circuit Breaker | 依赖持续失败时暂时停止调用 | 防止故障在服务之间扩大 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 测试用例 Test Case | 输入、步骤、预期结果和前置条件 | 把验收标准展开成可以重复执行的检查 |
| 单元测试 Unit Test | 隔离验证一个较小逻辑单元 | 快速检查分支和边界条件 |
| 集成测试 Integration Test | 验证多个真实组件能否正确协作 | 检查数据库、消息队列和外部服务接入 |
| 契约测试 Contract Test | 验证接口双方仍遵守同一约定 | 防止 API 或事件升级后互不兼容 |
| 端到端测试 End-to-End Test | 从用户入口走完一条完整业务流程 | 验证关键流程能够交付 |
| 验收测试 Acceptance Test | 从业务或用户角度判断需求是否满足 | 在交付前确认验收标准已经成立 |
| 回归测试 Regression Test | 检查已有功能是否被新改动破坏 | 发布前复查高风险旧流程 |
| 冒烟测试 Smoke Test | 快速检查版本最基本的能力是否可用 | 部署后判断能否继续深入测试 |
| 测试替身 Test Double | 用可控对象代替真实依赖 | 隔离数据库、网络和外部服务 |
| 测试覆盖率 Test Coverage | 测试执行到的代码或分支比例 | 发现明显缺口，不能单独证明质量 |
| 不稳定测试 Flaky Test | 相同代码下结果偶尔成功、偶尔失败的测试 | 排查并发、时间、环境和共享状态问题 |
| 基于性质的测试 Property-Based Test | 生成大量输入，检查始终成立的性质 | 验证解析器、状态机和复杂数据规则 |
| 负载测试 Load Test | 在预期并发和数据量下测量系统表现 | 验证容量、延迟和资源使用 |
| 压力测试 Stress Test | 超过预期负载以寻找系统极限 | 观察过载后的退化和恢复能力 |
| 安全测试 Security Test | 检查漏洞、越权和数据暴露风险 | 上线前验证认证、授权和输入处理 |
运维、发布与稳定性
Section titled “运维、发布与稳定性”| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 构建 Build | 把源码转换成可运行或可分发结果 | 编译、打包和生成静态资源 |
| 制品 Artifact | 一次构建产生并可追踪的文件或镜像 | 在不同环境部署同一版本 |
| 持续集成 CI | 每次变更自动执行构建和检查 | 尽早发现合并冲突、测试和质量问题 |
| 持续交付 CD | 自动把通过检查的版本送到可发布状态 | 缩短从合并到部署的时间 |
| 环境 Environment | 开发、测试、预发布和生产等运行空间 | 隔离配置、数据和发布风险 |
| 配置 Configuration | 随环境变化但不写死在代码里的参数 | 调整地址、开关和运行策略 |
| 密钥 Secret | 需要受控保存的密码、令牌和证书 | 连接数据库、云服务和第三方 API |
| 容器 Container | 把应用和运行依赖封装成可移植单元 | 保持本地、测试和生产环境一致 |
| 基础设施即代码 IaC | 用版本化文件声明基础设施 | 创建云资源、网络和权限配置 |
| 部署 Deployment | 把一个版本安装到目标环境 | 更新服务器、容器或静态站点 |
| 发布 Release | 让已部署的能力对用户可用 | 配合版本、开关和发布说明开放功能 |
| 正式上线 Launch | 把产品或重要版本正式推向目标用户 | 协调发布、公告、渠道和支持准备 |
| 功能开关 Feature Flag | 用运行时开关控制功能是否生效 | 分离代码部署和功能开放 |
| 金丝雀发布 Canary Release | 先让少量实例或流量使用新版本 | 控制风险并观察真实指标 |
| 蓝绿发布 Blue-Green Deployment | 在两套环境间切换新旧版本 | 快速切换和回退完整版本 |
| 回滚 Rollback | 让代码、配置或数据回到可工作状态 | 处理发布失败和严重回归 |
| 可观测性 Observability | 通过日志、指标和追踪判断系统状态 | 排查线上问题和验证运行结果 |
| SLI、SLO 与 SLA | 指标、内部目标和对外承诺三个层次 | 定义可用性、延迟和错误率要求 |
| 事故 Incident | 已经影响或可能影响服务的异常事件 | 启动响应、沟通和恢复流程 |
| 运行手册 Runbook | 处理常见操作和故障的可执行步骤 | 值班、发布和应急处置 |
| 复盘 Postmortem | 事故后的事实、原因和改进行动记录 | 修复系统问题并跟踪后续任务 |
| RTO 与 RPO | 恢复所需时间和可接受的数据丢失范围 | 设计备份、容灾和恢复方案 |
这里的宣发指产品怎样被目标用户看见、理解和尝试，以及发布后怎样判断用户是否留下。它和产品规划、内容运营会有交叉，重点仍是把传播目标和结果说清楚。
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 产品定位 Positioning | 产品为哪类用户解决什么问题，和替代方案有何差异 | 决定首页、介绍文案和渠道选择 |
| 理想客户画像 ICP | 最可能获得价值并愿意采用产品的客户特征 | 聚焦早期用户和销售线索 |
| 价值主张 Value Proposition | 用户选择产品能够得到的明确价值 | 写产品介绍、落地页和发布文案 |
| 信息表达 Messaging | 面向不同受众稳定使用的一组说法 | 统一官网、社交媒体和销售材料 |
| 市场进入策略 Go-to-Market | 产品进入市场的受众、渠道、定价和节奏 | 规划新产品或重要版本的推出方式 |
| 落地页 Landing Page | 承接某次传播并引导用户采取行动的页面 | 发布产品、投放内容和收集注册 |
| 行动按钮 CTA | 明确希望用户下一步采取的动作 | 引导注册、试用、订阅和下载 |
| 获客渠道 Acquisition Channel | 用户第一次接触产品的来源 | 比较搜索、社区、内容和广告效果 |
| 内容营销 Content Marketing | 用持续内容帮助用户理解问题和产品 | 写博客、案例、教程和行业解释 |
| 搜索优化 SEO 与 ASO | 改善网页或应用在搜索结果中的发现能力 | 获取长期自然流量 |
| 发布说明 Release Notes | 面向用户解释本次版本变化 | 告知新增能力、修复和使用影响 |
| 变更记录 Changelog | 按版本持续记录产品变化 | 给用户和开发者提供可追踪历史 |
| 转化漏斗 Funnel | 用户从看见产品到完成目标的一组阶段 | 定位流失发生在哪一步 |
| 转化率 Conversion Rate | 完成目标动作的用户比例 | 衡量注册、试用、购买和订阅效果 |
| 激活 Activation | 新用户第一次获得核心价值的时刻 | 设计新手流程和首个成功体验 |
| 留存 Retention | 用户在一段时间后继续使用产品的情况 | 判断产品是否形成持续价值 |
| A/B 测试 | 随机比较两个版本对目标指标的影响 | 验证页面、文案和流程改动 |
| 归因 Attribution | 判断一次转化应归到哪个来源或触点 | 评估渠道和活动投入 |
| 获客成本 CAC 与用户价值 LTV | 获得一个客户的成本和客户长期贡献 | 判断增长方式是否能持续 |
AI Coding
Section titled “AI Coding”这组术语以 Codex、Claude Code 这类可以读写代码库并调用工具的 coding agent 为语境。不同产品对 System Prompt、Skill 和 Harness 的文件结构与优先级定义并不相同，表里只保留它们共同的工程含义。
| 术语 | 它约束什么 | 常见使用场景 |
|---|---|---|
| 上下文窗口 Context Window | 模型一次处理能够容纳的上下文范围 | 决定放入哪些代码、文档和历史信息 |
| 系统提示 System Prompt | 应用在会话中提供的高优先级行为约束 | 放项目规则、角色边界和输出要求 |
| 工具调用 Tool Calling | 模型按结构化参数请求外部工具执行动作 | 让 agent 读文件、查数据和调用服务 |
| Agent 循环 Agent Loop | 模型读取结果、决定下一步并继续调用工具的循环 | 理解 agent 怎样完成多步任务 |
| MCP | 连接 AI 应用与外部工具、数据源的开放协议 | 接入数据库、浏览器和业务系统 |
| Skill | coding agent 中可复用的任务说明、参考材料和执行资源 | 固化团队反复使用的工作方法 |
| Harness | 包围模型的上下文、工具、权限和反馈系统 | 提高 agent 执行复杂任务的稳定性 |
| 护栏 Guardrail | 在输入、工具或输出层强制执行的限制 | 阻止越权操作和不合规结果 |
| 沙箱 Sandbox | 隔离代码执行范围和权限的环境 | 运行未知代码或低信任任务 |
| 评测 Eval | 用固定任务和判定标准反复测量 agent 表现 | 比较模型、提示词和工具链变化 |
| 检查点 Checkpoint | 保存可恢复、可审查的中间状态 | 支持长任务续跑、回退和人工确认 |
这份索引适合在不确定一个词时回查，不适合一次塞进 prompt。先判断当前工作处在哪个环节，再挑能缩小范围、明确方案或约束验收的词。术语用得多，不代表任务写得更专业。
通用术语也替代不了项目自己的领域语言。每个业务词写一句定义，补上不能混用的近义词，再链接到对应代码或业务文档。这个文件可以叫 CONTEXT.md、GLOSSARY.md，也可以放进现有项目说明。文件名不重要，agent 能找到并持续使用才有价值。