《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 | 评测 | 评估 | 视语境而定 | 模型或系统质量验证可用“评测” |
四、可追加术语表模板¶
当你开始翻具体页面时，把新增术语继续补在这里。
| 英文原词 | 推荐译法 | 可接受替代 | 是否保留英文 | 使用说明 | 所在页面 |
|---|---|---|---|---|---|
| 待补充 | 待补充 | 待补充 | 待补充 | 待补充 | 待补充 |
| 待补充 | 待补充 | 待补充 | 待补充 | 待补充 | 待补充 |
五、文风总原则¶
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
访问日期：YYYY-MM-DD
译文版本：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。这三篇分别覆盖概念定义、机制说明和工程实践，足够用来检验术语、文风和处理规则是否稳定。等样本跑顺之后，再把术语表和风格指南回修一轮，最后批量推进后续页面。
十二、可直接复制的团队协作约定¶
如果是多人协作，可以直接采用下面这段：