附录A 术语表
本附录收录全书反复使用、承担跨章节论证功能的核心术语，并按照术语首次得到系统阐述的部分编排，而不是按照字母顺序排列。读者既可以将其作为速查工具，也可以借此把握全书的概念体系和论证脉络。
每个词条包括术语、英文原词（如适用）、简要释义和首次系统展开的章节。同一概念在全书中原则上采用统一译法；如果其他资料使用了不同译名，应以本书正文和本表的表述为准。
本附录并未穷尽全书出现的所有词汇，而是集中收录承担跨章节论证功能、值得反复查阅的核心概念。附录B至附录D提供更加具体的操作层面速查内容，与本表相互补充。
第一部分 基础概念
| 术语 | 释义 | 出处 |
|---|---|---|
| 智能体（Agent） | 能够读取或感知环境状态，围绕既定目标选择行动、调用工具，并根据执行反馈继续推进任务的软件系统；其自主程度取决于所获得的上下文、工具、权限和控制机制。 | 第1章 |
| Agentic Coding | 由编码智能体在一定授权范围内理解任务、规划步骤、操作代码库、调用工具并验证结果的开发方式；人仍然负责确定目标、划定边界、审查证据并承担最终责任。 | 第1、2章 |
| ReAct | 让模型在推理、行动和观察行动结果之间循环，并利用新获得的信息调整后续判断的经典智能体范式。 | 第2章 |
| 模式预测（Pattern Prediction） | 大语言模型依据训练中学习到的统计规律和当前上下文预测后续词元的基本生成机制，也是理解其能力与局限的重要起点。 | 第3.2节 |
| 四个悖论 | 冒进、上下文、局部视野和学习四类在AI协作者身上反复出现的结构性矛盾，是全书识别和分析失效模式的通用框架。 | 第4章 |
| 冒进悖论（Eagerness Paradox） | 智能体越急于产生可见成果，越可能在尚未充分理解需求时开始行动，并迅速把错误理解扩展成大量看似完整的产出。 | 第4.2节 |
| 上下文悖论（Context Paradox） | 上下文并非越多越好；当信息超过智能体能够有效筛选和组织的范围后，新增内容可能稀释关键信号、制造冲突并降低结果可靠性。 | 第4.3、7章 |
| 局部视野悖论（Tunnel Vision Paradox） | 智能体可能在局部任务上得到高质量结果，却因为忽视系统级约束、接口关系和长期影响而造成全局失调。 | 第4.4节 |
| 学习悖论（Learning Paradox） | 单次任务中获得的经验不会自动转化为可跨会话复用的长期知识，除非借助专门机制将其提炼、保存并在后续任务中重新加载。 | 第4.5、7章 |
第二部分 智能体编码的工作循环
| 术语 | 释义 | 出处 |
|---|---|---|
| 信任工程（Trust Engineering） | 围绕智能体的可信委托，把委托、安全、问责和合规四个方面组织成统一控制体系的工程框架，用于判断可以信任什么、信任到何种程度以及如何验证这种信任。 | 第5.1、18.4节 |
| 委托工程（Delegation Engineering） | 信任工程的组成部分，关注事前如何定义目标、权限、自主范围和升级条件，回答应当把多大的决策权交给智能体。 | 第5.1、18.4节 |
| 安全工程（Safety Engineering） | 信任工程的组成部分，关注智能体发生错误、越权或者遭受攻击时，如何限制影响范围并保持系统可恢复。 | 第5.1、18.4节 |
| 问责工程（Accountability Engineering） | 信任工程的组成部分，关注能否根据日志、证据和决策记录还原智能体做了什么、为何这样做以及责任应当由谁承担。 | 第5.1、18.4节 |
| 合规工程（Compliance Engineering） | 信任工程的组成部分，关注既定策略、审批流程和控制要求是否得到实际执行，并能否通过独立证据加以证明。 | 第5.1、18.4节 |
| 提示注入（Prompt Injection） | 攻击者将恶意或者误导性指令嵌入智能体可能读取的外部内容，诱使其偏离原始任务、泄露信息或者执行非预期操作的一类攻击。 | 第5.2节 |
| 自信的错误（Confident Wrongness） | 智能体以流畅、确定的方式给出错误结论或实现，使问题比显式报错更难被发现的一类失效模式。 | 第5.3节 |
| 问责鸿沟（Accountability Gap） | 智能体能够执行工作，却不能承担组织、职业或者法律责任，由此形成的责任归属缺口；最终责任仍须由授权、审查和接受其产出的人及组织承担。 | 第5.4节 |
| 意图工程（Intent Engineering） | 将模糊目标逐步转化为明确范围、约束、验收标准和决策边界的系统方法，是提高任务委托质量的第一道工程关卡。 | 第6章 |
| 任务简报（Mission Brief） | 集中说明任务目标、验收标准、必要背景、范围和约束的结构化任务说明，用于建立委托双方共同遵守的任务契约。 | 第6.2节 |
| 自主性边界（Autonomy Envelope） | 将智能体的决策范围划分为可以自主决定、必须升级请示和绝对禁止三类，从而明确自主行动边界的控制机制。 | 第6.3节 |
| AGENTS.md | 记录代码库或者目录级项目约定的指令文件；支持该机制的编码智能体会按照作用域加载其中的构建、测试、风格和协作要求。 | 第6.5节 |
| CLAUDE.md | Claude Code使用的项目指令文件，用于保存可跨会话复用的代码库约定、工作流程和操作限制。 | 第6.5节 |
| Planning Mode | 让智能体先以只读方式探查代码库并提出实施计划，在计划得到审阅和确认后再进入修改阶段的工作模式；不同工具对只读约束的实现强度可能不同。 | 第6.6节 |
| 上下文工程（Context Engineering） | 围绕任务目标选择、组织、压缩、更新和传递上下文的系统方法，核心是让有限的上下文窗口承载最有助于当前判断的信息。 | 第7章 |
| 注意力预算（Attention Budget） | 将模型有限的上下文容量和有效注意力视为需要主动分配的资源，优先保留目标、约束、关键证据和当前决策所必需的信息。 | 第7.2节 |
| Skill Engineering | 将专家知识、操作流程和适用条件组织成可复用的指令与工具包，使智能体能够在相关任务中按需加载和执行的工程方法。 | 第7.6节 |
| Continuity Pack | 跨会话传递当前状态、既有决策、已排除路径、未解决问题和后续步骤的结构化上下文制品，用于降低任务交接时的信息损失。 | 第7.7节 |
| MCP（Model Context Protocol） | 为AI应用连接外部数据、资源、提示和工具提供标准化接口的开放协议，主要解决智能体与外部能力之间的集成问题。 | 第8.2节 |
| 沙箱（Sandbox） | 在运行环境层面限制进程可以访问的文件、网络、命令和其他资源的隔离机制，其约束不依赖智能体是否主动遵守提示。 | 第8.4、8.5节 |
| Hooks | 在智能体执行流程的预设事件节点自动触发检查、命令或者拦截动作的确定性机制，可用于执行验证、阻止违规操作和记录审计信息。 | 第8.6节 |
| 最小权限原则（Principle of Least Privilege） | 只向用户、进程或者智能体授予完成当前任务所必需的最小权限，并在任务结束后及时收回。 | 第8.7节 |
| 证据驱动监督（Evidence-Driven Oversight） | 根据可检查的代码差异、测试结果、执行记录和风险证据作出监督判断，而不是依赖智能体对任务完成情况的自我描述。 | 第9.3节 |
| 独立验证原则（Independent Verification Principle） | 对结果的核验应由与产出过程充分独立的人、工具、测试或者证据完成，不能仅以产出者自身的声明作为通过依据。 | 第9.4节 |
| 分层验证（Layered Verification） | 按风险叠加行为一致性、类型与结构健全性、独立复核与惯用法、安全与供应链、性能与真实负载五个验证层，避免把单一测试结果当作充分证据。 | 第9.5节 |
| 混沌工程（Chaos Engineering） | 通过受控实验主动向系统注入故障或异常条件，检验系统能否维持预期行为，并在真实事故发生前暴露薄弱环节的方法。 | 第9.8节 |
| 决策点而非执行点 | 将人工监督集中设置在目标选择、风险接受、不可逆操作和权限扩大等需要判断力的节点，而不是要求人逐一确认所有例行步骤。 | 第10.1节 |
| Delta-first Review | 评审时优先呈现自上次检查以来发生的变化及其影响，需要时再追溯完整上下文，以降低重复阅读和信任判断的成本。 | 第10.3节 |
| 结构化决策请求（Structured Decision Request） | 智能体超出自主性边界时提交的结构化决策材料，通常包括待决策事项、必要背景、备选方案、权衡、证据和影响范围。 | 第10.5节 |
| 决议记录（Resolution Record） | 保存一次决策的结果、理由、适用条件、约束和证据指针的持久化记录，使该决定可以被追溯并在类似任务中复用。 | 第10.5节 |
第三部分 编码活动实践
| 术语 | 释义 | 出处 |
|---|---|---|
| 五类核心工作流 | 本书归纳的五类典型编码任务，即功能骨架搭建（Feature Scaffolding）、Bug修复、测试补全、重构和迁移；不同工作流需要采用不同的上下文、验证和监督方式。 | 第11.1节 |
| 规范驱动生成（Spec-Driven Generation） | 先建立机器可读、可核验的接口或行为规范，再据此生成代码、测试和文档的方法，用于减少自然语言需求中的歧义向实现阶段扩散。 | 第12.1节 |
| 失败测试作为完整问题规范 | 当一条测试能够稳定复现缺陷并准确表达预期行为时，它可以同时充当Bug修复任务的问题定义、验收标准和回归验证手段。 | 第13.1节 |
| 有界重试（Bounded Retry） | 为自动化尝试设置明确的次数、时间或者成本上限，达到边界后停止重复执行并转入重新诊断或者升级请示。 | 第13.4.1节 |
| 规格漂移（Specification Drift） | 长时间、多轮执行过程中，智能体的判断和产出逐渐偏离原始目标、约束或者系统结构的现象，常由上下文累积、局部反馈和反复修改共同造成。 | 第13.4.3节 |
| 批判-反思模式（Critique-Reflection Pattern） | 将初始方案生成与批判性评审分配给相互独立的角色，再依据评审意见修订方案的两阶段评审机制。 | 第15.1节 |
| 评审分级（P0-P3） | 本书采用的评审问题分级约定：P0表示必须在提交或合入前解决的阻断性问题，P1表示原则上应在当前迭代处理、是否阻断由项目规则和风险决定的重要问题，P2表示记录进入技术债务清单的问题，P3表示不影响当前功能、作为建议处理的问题。 | 第15.3节 |
| 受限子集 | 从一门语言或者一组可选写法中划定并强制执行较窄的允许范围，以减少歧义、限制危险行为并提高产出的可验证性。 | 第20.4节 |
第四部分 多智能体编码
| 术语 | 释义 | 出处 |
|---|---|---|
| 真独立与假独立任务 | 判断任务能否安全并行时，不仅要检查代码修改范围是否独立，还要检查端口、数据库、缓存目录和测试环境等运行时资源是否相互隔离。 | 第16.3节 |
| Git Worktree | 让同一个Git仓库关联多个独立工作目录的机制，各工作目录可以检出不同分支或者提交，同时共享底层对象库，适合隔离并行开发任务。 | 第16.4节 |
| A2A（Agent2Agent Protocol） | 为独立智能体之间的发现、通信、任务协作和状态交换提供共同交互模型的开放标准，与主要连接工具和资源的MCP形成互补。 | 第16.5节 |
| 流水线撰写（Pipeline Authoring） | 由人预先定义任务阶段、依赖关系、验证关卡、交接要求和失败处理方式，再让工作流在这些边界内持续运行的委托方式。 | 第17.1节 |
| 交接契约（Handoff Contract） | 规定阶段之间必须传递哪些状态、工作产物、证据、上下文和任务信息的结构化约定；具体交接记录应按照该契约生成并接受校验。 | 第17.3节 |
| 多版本并行探索（N-Version Exploration） | 针对同一决策生成多个相互独立的候选方案，在统一约束和评估标准下取得可比较证据，再据此收敛并记录最终选择的方法。 | 第17.4节 |
| Mentorship-as-Code | 将团队成员的隐性经验、判断规则和工作惯例整理成智能体能够稳定加载的分层指南，使指导能力可以跨人员和任务复用。 | 第18.2节 |
| 机制与意图匹配 | 根据知识所承担的作用选择承载方式：行为偏好采用概率性指导，强制流程采用确定性机制，复杂认知策略则保留必要的人类判断空间。 | 第18.3节 |
第五部分 代码库、语言与交付
| 术语 | 释义 | 出处 |
|---|---|---|
| 爆炸半径（Blast Radius） | 一次错误、故障或者改动可能波及的系统、数据和用户范围，是划分模块边界、权限范围和发布批次的重要依据。 | 第19.3节 |
| 适中区间 | 组件粒度介于过度碎片化与过度集中之间的合适范围；具体边界取决于职责、耦合度、语言特性和验证成本，不能仅由固定行数决定。 | 第19.3节 |
| 知识缓存反模式（Knowledge Cache Anti-pattern） | 将本可从代码或工具实时获得的事实重复写入静态说明，导致信息冗余并随代码演化而过期的知识管理反模式。 | 第19.5节 |
| 两种模块性 | 面向人的模块性重视理解、局部推理和低歧义，面向智能体的模块性还需要支持上下文隔离、并行执行和自动验证；系统设计应兼顾二者。 | 第20.1节 |
| 信任边界 | 用于区分哪些输入、操作和结果可以直接接受，哪些必须经过隔离、授权或者额外验证的系统分界；编程语言及其受限子集也可以构成这种边界。 | 第20.2节 |
| 代码成为新的二进制 | 一种长期趋势判断：当更高层规范能够可靠生成并验证实现时，人类评审的重心可能从逐句检查代码转向审查语义、约束和证据，但这并不意味着现阶段可以忽视代码。 | 第20.5节 |
| 隔离配置 | 在持续集成环境中屏蔽个人配置、历史状态和无关环境变量，为每次运行提供明确、可重复配置的做法。 | 第21.3.1节 |
| 灰度发布（Canary Deployment） | 先让受控的小比例用户或流量使用新版本，根据错误率、性能和业务指标决定继续扩大范围还是回滚的渐进式发布方式。 | 第21.4节 |
| 影子模式（Shadow Mode） | 将真实生产输入复制给新版本进行旁路处理，但不让其结果影响生产决策或产生外部副作用，用于比较新旧实现行为的验证方式。 | 第21.4节 |
| 架构决策记录（Architecture Decision Record，ADR） | 记录重要架构或流程决策的状态、背景、最终选择、后果和备选方案的轻量级文档，用于保留决定背后的理由。 | 第21.6.1节 |
| harness | 承载模型运行并将其组织成智能体的软件层，负责上下文组装、工具连接、权限控制、执行循环和多智能体协作；智能体的实际表现由模型与harness共同决定。 | 第3.4、22.1节 |
第六部分 走向未来
| 术语 | 释义 | 出处 |
|---|---|---|
| 信任负债（Trust Debt） | 当组织生成和交付变更的速度超过理解、解释和审计这些变更的能力时逐渐累积的风险，最终可能表现为系统不可解释、责任不清和审计困难。 | 第23.1节 |
| 证据思维（Evidence Mindset） | 围绕提出主张、留存证据、独立核验和沉淀复用建立的思维习惯，使判断不依赖智能体的自我陈述或者某一种短期有效的提示技巧。 | 第23.3节 |
| 时间视野（Task-Completion Time Horizon） | 在给定任务分布和成功率阈值下，以人类专业人员完成同类任务所需的时间衡量智能体能够自主完成的任务长度；本书主要讨论50%成功率对应的时间视野。 | 第24.1节 |
| SICA（Self-Improving Coding Agent，自我改进编码智能体） | 能够修改自身智能体脚手架代码，并通过基准评估、版本归档和迭代选择提高任务表现的实验性自我改进系统。 | 第24.3.1节 |
| AlphaEvolve | 将大语言模型生成、自动评估器和进化搜索结合起来，用于发现和优化可由程序表达、能够通过客观指标评估的算法方案的进化式编码智能体。 | 第24.3.2节 |