《Agentic Engineering Patterns》术语表与翻译风格指南模板¶
本文档可直接作为 Simon Willison《Agentic Engineering Patterns》系列内容的翻译项目底稿使用。用法建议是：先锁定“项目基本设置”，再统一“术语表”，然后要求每篇译文都遵循“风格指南”和“交付前检查清单”。如果后续你把它扩展成团队协作文档，也可以直接继续补充，不需要重写。
一、项目基本设置¶
- 项目名称：
《Agentic Engineering Patterns》中文翻译项目 - 源站主页：
https://simonwillison.net/guides/agentic-engineering-patterns/ - 默认主译名：
智能体工程（Agentic Engineering） - 默认目标读者：
对 AI Agent、LLM 应用开发、代码智能体、工程工作流感兴趣的中文技术读者 - 默认发布形态：
Markdown 正文 + 术语表 + 更新日志 - 默认翻译流程：
AI 初译 + 人工精修 + 技术复核 + 一致性检查 - 默认质量目标：
技术准确、术语稳定、中文自然、可持续维护
如果你要做双语版，可在本节追加：
- 是否提供双语对照：
是 / 否 - 是否保留英文小标题：
是 / 否 - 是否为公众号单独改写：
是 / 否
二、术语使用总原则¶
- 能稳定保留英文检索价值的术语，优先保留英文或缩写，例如 LLM、RAG、MCP、Prompt、Token、Context Window。
- 能自然中文化且不会显著损失检索价值的术语，优先使用中文，并在首次出现时括注英文，例如“规划（planning）”“记忆（memory）”。
- 一个术语只能确定一个主译名，全文不要来回切换，例如“编码智能体”和“编程智能体”必须二选一。
- 标题、正文、图注、表头、译者注中的术语必须统一，不能只在正文统一。
- 对社区尚未完全定型、且带明显语境色彩的词，推荐“中文解释 + 英文原词”并用，例如“氛围编程（Vibe Coding）”。
三、核心术语表（预填版）¶
下表已经按当前项目可直接使用的默认方案预填。后续若要调整，应先修改此表，再批量修正文稿。
| 英文原词 | 推荐译法 | 可接受替代 | 是否保留英文 | 使用说明 |
|---|---|---|---|---|
| Agentic Engineering | 智能体工程 | 智能体化工程（不建议作主译） | 首次出现保留英文 | 标准写法为“智能体工程（Agentic Engineering）”；标题和目录优先用“智能体工程” |
| agentic | 智能体式的 / 智能体驱动的 | 智能体化的 | 视语境而定 | 不建议机械固定；优先按句义翻 |
| Agent | 智能体 | 代理（仅特定语境） | 一般不保留 | 默认统一为“智能体” |
| Coding Agent | 编码智能体 | 编程智能体、代码智能体 | 一般不保留 | 推荐全文统一“编码智能体”；如果改用“编程智能体”，需全文同步 |
| Subagent | 子智能体 | 从属智能体（不建议） | 首次出现可括英文 | 标准写法“子智能体（subagent）” |
| Workflow | 工作流 | 流程 | 首次出现可括英文 | 正文优先“工作流” |
| Planning | 规划 | 计划 | 首次出现可括英文 | 如果语境强调步骤制定，也可译“计划”；默认用“规划” |
| Memory | 记忆 | 记忆机制、记忆模块 | 首次出现可括英文 | 避免和计算机“内存”混淆 |
| Reasoning | 推理 | 推理过程、思考 | 首次出现可括英文 | 面向模型能力时优先“推理” |
| Reflection | 反思 | 复盘、自我反思 | 首次出现可括英文 | 指智能体回看结果并修正时优先“反思” |
| Tool Use | 工具使用 | 工具调用 | 首次出现可括英文 | 如果强调接口调用动作，可局部写“工具调用” |
| Delegation | 委托 | 分派 | 首次出现可括英文 | 多智能体任务拆分场景优先“委托” |
| Context Window | Context Window | 上下文窗口 | 建议保留英文 | 首次写法“Context Window（上下文窗口）” |
| Prompt | Prompt | 提示词 | 建议保留英文 | 首次写法“Prompt（提示词）”；提示词正文不要翻成中文替代原文 |
| Token | Token | 词元 | 建议保留英文 | 首次写法“Token（词元）”；后续直接用 Token |
| LLM | LLM | 大语言模型 | 建议保留英文 | 首次写法“LLM（大语言模型）” |
| RAG | RAG | 检索增强生成 | 建议保留英文 | 首次写法“RAG（检索增强生成）” |
| MCP | MCP | 模型上下文协议 | 建议保留英文 | 首次写法“MCP（模型上下文协议）” |
| Pattern | 模式 | 模型、范式（视语境） | 一般不保留 | 标题中通常译“模式” |
| Anti-pattern | 反模式 | 反面模式 | 一般不保留 | 默认统一为“反模式” |
| Vibe Coding | 氛围编程（Vibe Coding） | 感觉编程（不建议） | 建议保留英文 | 语感词，建议中英并用 |
| Red/green TDD | 红/绿 TDD | 红绿 TDD | 保留缩写 | 首次写法“红/绿 TDD（Red/green TDD）” |
| Test-Driven Development | 测试驱动开发 | TDD | 通常保留缩写 | 首次写法“TDD（测试驱动开发）”或“测试驱动开发（TDD）” |
| Reflog | Reflog | 引用日志 | 建议保留英文 | Git 术语，命令和正文都保留英文更稳 |
| Cherry-pick | Cherry-pick | 挑选提交 | 建议保留英文 | Git 术语，正文可首次释义，但命令必须保留原样 |
| Bisect | Bisect | 二分定位 | 建议保留英文 | Git 术语，正文可释义，命令必须保留原样 |
| Stash | Stash | 暂存 | 建议保留英文 | Git 术语，命令保留原样 |
| Repo / Repository | 仓库 | 代码仓库 | 视语境而定 | 正文可用“仓库”，命令和 URL 相关语境保留 repo/repository |
| CLI | CLI | 命令行界面 | 建议保留英文 | 首次写法“CLI（命令行界面）” |
| Sandbox | 沙箱 | 沙盒（不建议混用） | 视语境而定 | 默认用“沙箱” |
| Hallucination | 幻觉 | 模型幻觉 | 一般不保留 | 默认用“幻觉” |
| Eval / Evaluation | 评测 | 评估 | 视语境而定 | 模型或系统质量验证可用“评测” |
四、可追加术语表模板¶
当你开始翻具体页面时，把新增术语继续补在这里。
| 英文原词 | 推荐译法 | 可接受替代 | 是否保留英文 | 使用说明 | 所在页面 |
|---|---|---|---|---|---|
| Observability | 可观测性 | — | 视语境 | 首次写法「可观测性（Observability）」 | 30 概念 |
| Tracing | 追踪 | 调用追踪 | 一般不保留 | 指智能体运行路径的逐步记录 | 30 概念 |
| Logging | 日志 | — | 一般不保留 | 指运行原始记录，可观测性基础层 | 30 概念 |
| Metrics | 指标 | 度量 | 一般不保留 | 指延迟 / 成本 / 次数等代理与结果信号 | 30 概念 |
| Replay | 回放 | 重放 | 一般不保留 | 指重现历史运行以调试与改进 | 30 概念 |
| Hook | 钩子 | — | 一般不保留 | 指工作流特定点运行的小检查（pre-tool hook 等） | 30 概念 |
| Permission | 权限 | — | 一般不保留 | 指工具调用授权规则 | 30 概念 |
| Orchestration | 编排 | — | 一般不保留 | 指多智能体协同的管理层 | 30 概念 |
| Prompt Caching | Prompt 缓存 | — | 建议保留英文 | 首次写法「Prompt 缓存」 | 30 概念 |
| Context Rot | 上下文腐烂 | 上下文劣化 | 一般不保留 | 指长上下文导致模型质量下降 | 30 概念 |
| Loop Engineering | 循环工程（Loop Engineering） | — | 建议保留英文 | 本文主题，首现写法「循环工程（Loop Engineering）」 | Loop Engineering |
| Automations | Automations（保留）/ 自动化 | — | 保留英文 | 指 Codex 的 Automations 特性，首现释义「自动化（Automations）」 | Loop Engineering |
| Plugin / Connector | 插件 / 连接器 | — | 一般不保留 | 指 loop 接入真实工具的插件与连接器 | Loop Engineering |
| Eval loop | 评测循环 | 评测闭环 | 一般不保留 | 指用评测驱动循环的闭环 | Loop Engineering |
| Cognitive surrender | 认知投降 | — | 保留英文 | Addy coined，首现「认知投降（cognitive surrender）」 | Loop Engineering |
| Comprehension debt | 理解债务 | — | 保留英文 | Addy coined，首现「理解债务（comprehension debt）」 | Loop Engineering |
| Intent debt | 意图债务 | — | 保留英文 | Addy coined，首现「意图债务（intent debt）」 | Loop Engineering |
| Orchestration tax | 编排税 | — | 保留英文 | Addy coined，首现「编排税（orchestration tax）」 | Loop Engineering |
| Maker / Checker | 制造者 / 审查者 | 写代码者 / 审查者 | 一般不保留 | 指写代码与审查代码的角色分离 | Loop Engineering |
| software factory | 软件工厂 | — | 一般不保留 | 指规模化、流水线式生产软件的组织形态 | Why Software Factories Fail |
| lights-off software factory | 熄灯软件工厂 | 无人值守软件工厂 | 保留英文 lights-off | 指人类不再读/写代码、全自动交付的工厂，首现「熄灯软件工厂（lights-off software factory）」 | Why Software Factories Fail |
| front-loading alignment | 前置对齐 | — | 一般不保留 | 指把规划/架构对齐前置到写代码之前，以降低返工与评审成本 | Why Software Factories Fail |
| vertical slices | 垂直切片 | — | 一般不保留 | 指端到端打通一小条功能（对比按技术栈顺序的"水平计划"） | Why Software Factories Fail |
| tracer bullets | 示踪子弹（tracer bullets） | — | 建议保留英文 | 同 vertical slices，源自 Shape Up 的 tracer bullet 概念 | Why Software Factories Fail |
| shotgun surgery | 霰弹式修改 | — | 一般不保留 | Martin Fowler 代码异味，改动一处需在多处同步修改 | Why Software Factories Fail |
| brownfield | 棕地（brownfield） | — | 保留英文 | 指接手并长期维护已有代码库（对比绿地 greenfield） | Why Software Factories Fail |
| maintainability | 可维护性 | — | 一般不保留 | 指代码库随时间被安全改动的能力 | Why Software Factories Fail |
| RLVR | RLVR | 可验证奖励强化学习 | 保留英文 | Reinforcement Learning with Verifiable Rewards，首现「可验证奖励强化学习（RLVR）」 | Why Software Factories Fail |
| loopsmaxxing | 循环至上（loopsmaxxing） | — | 保留英文 | 指盲目堆循环/循环工程以追求速度的倾向 | Why Software Factories Fail |
| token-maxxing | 狂堆 Token（token-maxxing） | — | 保留英文 | 指盲目堆 Token 以追求效果的倾向 | Why Software Factories Fail |
| slop | 垃圾（slop） | 废话、灌水 | 建议保留英文 | 指低质量 AI 生成代码/内容，首现「垃圾（slop）」 | Why Software Factories Fail |
| Agent harness | 智能体 harness | — | 保留英文 harness | harness 不翻译 | Loop Engineering |
| Agentic Code Review | 智能体式代码审查（Agentic Code Review） | — | 建议保留英文 | 本文主题，首现写法「智能体式代码审查（Agentic Code Review）」 | Agentic Code Review |
| Blast radius | 影响半径（blast radius） | — | 保留英文 | Addy 用以衡量失败影响范围，首现中英并注 | Agentic Code Review |
| Verification bottleneck | 验证瓶颈（verification bottleneck） | — | 保留英文 | 指验证/审查成为新瓶颈 | Agentic Code Review |
| Triage | 分诊 | — | 一般不保留 | 医学借词，指按风险/优先级分流审查 | Agentic Code Review |
| Heterogeneous reviewers | 异构审查者 | 保留英文 | 指用不同模型/工具并行审查 | Agentic Code Review | |
| First-pass read | 一遍初读 | 一般不保留 | 指 AI 给出的首轮通读 | Agentic Code Review | |
| Merge decision | 合并决策 | 一般不保留 | 指是否合并 PR 的最终决定 | Agentic Code Review | |
| turn-based loop | 基于轮次的循环（turn-based loop） | 一般不保留 | 指用户每轮 Prompt 驱动、Claude 判断完成即停的循环 | Getting started with loops | |
| goal-based loop | 基于目标的循环（goal-based loop） | 一般不保留 | 对应 /goal，以目标达成或达最大轮次为停止条件 |
Getting started with loops | |
| time-based loop | 基于时间的循环（time-based loop） | 一般不保留 | 对应 /loop、/schedule，按时间间隔触发 |
Getting started with loops | |
| proactive loop | 主动式循环（proactive loop） | 一般不保留 | 由事件/计划触发、无实时人工、长期运行的循环 | Getting started with loops | |
| stop condition | 停止条件 | 一般不保留 | 循环终止的判断标准；已有「可验证停止条件」先例 | Getting started with loops | |
| evaluator model | 评估模型（evaluator model） | 首现括注 | 在 /goal 每轮结束后判断目标是否达成的独立模型 |
Getting started with loops | |
| auto mode | auto 模式 | 保留英文 auto | Claude Code 特性，运行时不暂停请求权限 | Getting started with loops | |
| dynamic workflows | 动态工作流（dynamic workflows） | 首现括注 | Claude Code 研究预览特性，编排多子智能体 | Getting started with loops | |
| research preview | 研究预览 | 一般不保留 | 标注特性成熟度，意为研究预览版 | Getting started with loops | |
| harness | 智能体 harness | — | 保留英文 harness | harness 不翻译；首现「智能体 harness（harness）」 | Harness Engineering |
| recursive self-improvement (RSI) | 递归自我改进（RSI） | — | 建议保留缩写 | 首现「递归自我改进（RSI）」 | Harness Engineering |
| context engineering | 上下文工程（Context Engineering） | — | 一般不保留 | 指构造结构化、精简上下文的一层 | Harness Engineering |
| Agentic Context Engineering (ACE) | 智能体式上下文工程（ACE） | — | 保留缩写 | 把上下文当作可进化的 playbook | Harness Engineering |
| Meta Context Engineering (MCE) | 元上下文工程（MCE） | — | 保留缩写 | 在“机制”与“内容”两层分别优化 | Harness Engineering |
| Meta-Harness | 元 harness（Meta-Harness） | — | 保留英文 Meta- | “优化 harness 的 harness” | Harness Engineering |
| persistent memory | 持久记忆 | 持久化记忆 | 一般不保留 | 以文件等形式长期保存的状态与产物 | Harness Engineering |
| self-improving harness | 自我改进 harness | — | 保留英文 harness | 指能改写自身的 harness | Harness Engineering |
| Self-Taught Optimizer (STOP) | 自学优化器（STOP） | — | 保留缩写 | 递归式脚手架改进的早期例子 | Harness Engineering |
| reward hacking | 奖励作弊（reward hacking） | 奖励黑客 | 保留英文 | 优化器钻奖励信号空子 | Harness Engineering |
| evolutionary search | 进化搜索 | 演化搜索 | 一般不保留 | 受自然选择启发的优化方法 | Harness Engineering |
| verifier | 验证器 | — | 一般不保留 | 判定任务成败的模块/程序 | Harness Engineering |
| held-in / held-out | 内部保留集 / 外部保留集 | — | 一般不保留 | 回归测试的训练内/泛化切分 | Harness Engineering |
| AlphaEvolve | AlphaEvolve | — | 保留英文 | 编码智能体式进化搜索系统 | Harness Engineering |
| AFlow | AFlow | — | 保留英文 | 把智能体工作流表示为图并做 MCTS 优化 | Harness Engineering |
| ADAS | ADAS | — | 保留英文 | 把智能体设计本身作为优化问题 | Harness Engineering |
| DGM (Darwin Gödel Machine) | 达尔文·哥德尔机（DGM） | — | 保留缩写 | 显式演化可编辑的 harness 代码库 | Harness Engineering |
| SIA | SIA | — | 保留英文 | 联合 harness 改进与模型权重更新的尝试 | Harness Engineering |
| collective operation | 集合通信（collective operation） | — | 首现括注 | 分布式训练中 GPU/TPU 协同的通信原语 | 集合通信剖析 |
| All-Gather | 全收集（All-Gather） | — | 首现括注 | N 个分片聚合为完整张量 | 集合通信剖析 |
| Reduce-Scatter | 归约散布（Reduce-Scatter） | — | 首现括注 | 先归约再散布分片，All-Gather 的对偶 | 集合通信剖析 |
| All-Reduce | 全归约（All-Reduce） | — | 首现括注 | Reduce-Scatter + All-Gather 组合 | 集合通信剖析 |
| All-to-All | 全互换（All-to-All） | — | 首现括注 | 分布式转置/令牌路由 | 集合通信剖析 |
| ring / ring algorithm | 环 / 环形算法（ring） | — | 首现括注 | 集合通信常用实现，N-1 步完成 | 集合通信剖析 |
| tree / tree algorithm | 树 / 树形算法（tree） | — | 首现括注 | log₂ N 步完成，延迟友好 | 集合通信剖析 |
| torus | 环面（torus） | — | 首现括注 | 含环绕连接的网格拓扑 | 集合通信剖析 |
| mesh | 网格（mesh） | — | 首现括注 | 无环绕的网格拓扑 | 集合通信剖析 |
| wraparound | 环绕（wraparound） | — | 一般不保留 | 环面边界回绕特性 | 集合通信剖析 |
| superpod | 超级 Pod（superpod） | — | 首现括注 | 最大 ICI 连接域（"超节点"） | 集合通信剖析 |
| slice | 切片（slice） | — | 首现括注 | TPU 的 ICI 岛 | 集合通信剖析 |
| ICI | ICI | 芯片间互联 | 保留 | inter-chip interconnect，TPU 芯片间互联 | 集合通信剖析 |
| DCN | DCN | 数据中心网络 | 保留 | data center networking，跨 Pod 通信 | 集合通信剖析 |
| NVLink / NVSwitch | NVLink / NVSwitch | — | 保留 | NVIDIA 高带宽互联技术 | 集合通信剖析 |
| SHARP | SHARP | — | 保留 | 网内归约/聚合计算单元 | 集合通信剖析 |
| fat tree | 胖树（fat tree） | — | 首现括注 | 层次化交换机拓扑，越往根越胖 | 集合通信剖析 |
| Scalable Unit (SU) | 可扩展单元（Scalable Unit，SU） | — | 保留缩写 | DGX 集群的 32 节点分组 | 集合通信剖析 |
| bisection bandwidth | 二分带宽（bisection bandwidth） | — | 首现括注 | 对半切分后的集群间可用带宽 | 集合通信剖析 |
| oversubscription | 超额订阅（oversubscription） | — | 首现括注 | 下游注入超上游承载的比例 | 集合通信剖析 |
| hierarchical collectives | 分层集合通信（hierarchical collectives） | — | 首现括注 | 跨多级拓扑（节点/SU/Spine）的通信算法 | 集合通信剖析 |
| recursive doubling / halving | 递归倍增 / 递归折半 | — | 一般不保留 | 树形 All-Gather / Reduce-Scatter 的核心技巧 | 集合通信剖析 |
| in-network reduction | 网内归约（in-network reduction） | — | 首现括注 | 由交换机直接完成归约操作 | 集合通信剖析 |
| leaf switch / spine switch | 叶子交换机 / 脊交换机 | — | 一般不保留 | 胖树的两级交换层 | 集合通信剖析 |
| scale-up / scale-out | 纵向扩展 / 横向扩展 | — | 首现括注 | NVLink 域内 vs InfiniBand 跨节点 | 集合通信剖析 |
| injection bandwidth | 注入带宽 | — | 一般不保留 | 节点向网络注入数据的带宽 | 集合通信剖析 |
| throughput-bound / latency-bound | 吞吐受限 / 延迟受限 | — | 一般不保留 | 判断通信瓶颈在带宽还是延迟 | 集合通信剖析 |
| nearest-neighbor | 近邻（nearest-neighbor） | — | 一般不保留 | TPU 环面的物理相邻芯片 | 集合通信剖析 |
| data / tensor / expert parallelism | 数据并行 / 张量并行 / 专家并行 | — | 一般不保留 | 分布式并行策略 | 集合通信剖析 |
| FSDP | FSDP | — | 保留 | Fully Sharded Data Parallelism | 集合通信剖析 |
| MoE | MoE | 混合专家 | 保留 | Mixture of Experts | 集合通信剖析 |
| general method | 通用方法（general method） | — | 首现括注 | 不针对特定领域做假设，仅依赖算力与数据的通用学习/搜索算法 | 苦涩的教训 |
| Moore's law | 摩尔定律（Moore's law） | — | 首现括注 | 单位算力成本持续指数级下降的经验规律 | 苦涩的教训 |
| brute force search | 暴力搜索（brute force search） | — | 首现括注 | 穷举式大规模搜索，不依赖人类领域知识 | 苦涩的教训 |
| deep search | 深度搜索 | — | 一般不保留 | 大规模、深层的博弈树搜索 | 苦涩的教训 |
| self play | 自我对弈（self play） | — | 首现括注 | 智能体与自身对弈以学习策略和评估函数 | 苦涩的教训 |
| value function | 价值函数（value function） | — | 首现括注 | 评估状态或动作长期累积回报的函数 | 苦涩的教训 |
| Hidden Markov Model (HMM) | 隐马尔可夫模型（Hidden Markov Model，HMM） | — | 保留缩写 | 基于统计的序列建模方法 | 苦涩的教训 |
| meta-method | 元方法（meta-method） | — | 首现括注 | 能发现并捕获任意复杂性的通用算法框架 | 苦涩的教训 |
五、文风总原则¶
5.1 中文风格定位¶
本项目译文应接近成熟中文技术文章，而不是英文句法的直译稿。整体风格建议是：清楚、克制、准确、可执行。不要故意写得过分口语，也不要把英文长句硬搬进中文。
5.2 句式原则¶
- 优先用短句或中短句，避免一个句子套太多从句。
- 有明显因果关系时直接说清，不要绕。
- 能用主动句就不用被动句。
- 英文中重复出现的代词、连接词、插入语，进入中文后应按可读性裁剪。
- 如果一段包含定义、原因、例外、示例四层信息，优先拆段，不要挤在一个长段落里。
5.3 术语首次出现规则¶
- 中文主译词 + 全角括号英文，例如：
智能体工程（Agentic Engineering） - 英文缩写 + 全角括号中文释义，例如：
LLM（大语言模型） - 同一篇文章中，同一术语首次出现时括注一次即可，后文不重复。
- 若标题中已出现术语，正文首段仍可补一次释义，便于读者快速进入语境。
5.4 标题规则¶
- 标题优先翻成自然中文，不必强行保留英文结构。
- 标题要短，优先清楚，再考虑“贴原文”。
- 如果原标题是问句，中文可保留问句形式。
- 如果原标题里有高辨识度术语，允许保留英文原词，例如：
什么是智能体工程？而不是What is agentic engineering?
可直接复用的标题处理示例：
| 原标题 | 推荐译法 |
|---|---|
| What is agentic engineering? | 什么是智能体工程？ |
| How coding agents work | 编码智能体如何工作 |
| Using Git with coding agents | 如何将 Git 用于编码智能体工作流 |
| Red/green TDD | 红/绿 TDD |
| Subagents | 子智能体 |
六、格式与内容处理规则¶
6.1 代码块¶
- 代码本体不翻。
- 代码中的命令、参数、路径、函数名、类名、配置项不翻。
- 代码注释是否翻译，要在同一篇内统一。默认建议：说明性注释可以翻，关键标识不翻。
- 代码块上下方的解释文字应翻成中文。
6.2 Shell 命令与 Git 命令¶
- 命令全文保持原样，例如
git log、git cherry-pick、git bisect、git reset --soft HEAD~1。 - 只翻命令的用途说明，不翻命令本身。
- 不要把选项名、参数名、flag 翻成中文。
6.3 Prompt 与长提示词¶
- Prompt 正文默认保留英文原文。
- 如果 Prompt 是“被讲解对象”或“可执行输入”，不要直接翻成中文版替代原文。
- 推荐做法是：保留英文 Prompt，在其后增加“中文解释”或“分段说明”。
- 若确实需要给中文版本，建议采用“原文 + 中文参考译文”双栏或上下排布，不要只留中文。
6.4 链接¶
- 第一版译文默认保留原始 URL。
- 内链尚未完成中文版映射前，不要改成不存在的中文链接。
- 锚文本可翻成中文，但链接目标先保留原文地址。
6.5 引用¶
- 直接引用时，应尽量保持原意和语气。
- 如果一句话在原文中具有高传播度或明显作者风格，允许同时给出原文短句。
- 引用后尽量给出来源链接。
6.6 文件名、路径、配置名、产品名¶
- 文件名、目录名、路径、环境变量名、配置键名全部保留原样。
- 产品名、工具名、库名默认保留原文，例如 GitHub、Claude Code、VS Code、Python。
6.7 列表、表格与强调¶
- 列表项应尽量平行，避免同一层级里有的极短、有的极长。
- 表格优先用于术语、对比、步骤差异，不要为排版而强行造表。
- 加粗只用来标记关键信息，不要整段加粗。
七、译者注规则¶
建议统一使用以下格式：
[译者注] 这里补充翻译选择、背景信息、版本差异或中文语境说明。
适合添加译者注的典型场景：
- 术语尚未定型，且当前选择需要说明。
- 原文默认读者背景较强，中文读者可能缺乏上下文。
- 原文内容依赖特定工具、时间点或版本。
- 你保留了英文原词，但需要告诉读者为什么不直译。
不建议滥用译者注。凡是可以自然写进正文的内容，优先融入正文。
八、单篇文章交付模板¶
下面这段可以直接作为每篇译文的头部模板。
# 文章标题（中文）
原文标题：
原文链接：
原文作者：Simon Willison
译文版本：v0.1
译者：
审校：
## 译文说明
本文为《Agentic Engineering Patterns》系列内容的中文翻译。术语使用遵循本项目统一术语表。代码、命令、URL、文件名默认保留原文；Prompt 如为可执行输入，一般保留英文并补充中文解释。
## 正文
（从这里开始贴正文）
九、交付前检查清单¶
9.1 术语一致性¶
- [ ] “智能体工程”是否全篇统一，没有混入“智能体化工程”“代理工程”等写法
- [ ] “编码智能体”是否全篇统一，没有与“编程智能体”混用
- [ ] LLM、RAG、MCP、Prompt、Token 是否按既定规则处理
- [ ] 规划、记忆、推理、反思、工具使用、委托等术语是否前后一致
- [ ] 新增术语是否已经回填到术语表
9.2 技术准确性¶
- [ ] 代码块没有被误翻
- [ ] Git 命令、CLI 命令、参数、路径都保持原样
- [ ] 工具名、产品名、文件名、配置项没有被中文化
- [ ] 对模型机制、工作流、测试方法的表述没有事实性误解
9.3 可读性¶
- [ ] 中文读起来像自然技术文章，而不是逐句直译
- [ ] 长句已经适当拆开
- [ ] 标题清楚，不拧巴
- [ ] 段落长度均衡，没有连续堆叠超长段
9.4 Prompt 与引用处理¶
- [ ] 可执行 Prompt 默认保留英文原文
- [ ] Prompt 下方有必要的中文解释
- [ ] 关键引用保留原意
- [ ] 链接都能正常点击，且第一版优先指向原文
9.5 元信息¶
- [ ] 记录了原文链接与访问日期
- [ ] 记录了译文版本号
- [ ] 如果做过术语改动，已记录在更新日志中
十、更新日志模板¶
十一、推荐执行方式¶
如果你准备马上开工，最稳的方式不是直接全量翻完，而是先用这份模板试翻三篇样本：What is agentic engineering?、How coding agents work、Using Git with coding agents。这三篇分别覆盖概念定义、机制说明和工程实践，足够用来检验术语、文风和处理规则是否稳定。等样本跑顺之后，再把术语表和风格指南回修一轮，最后批量推进后续页面。
十二、可直接复制的团队协作约定¶
如果是多人协作，可以直接采用下面这段：