我的英语阅读还能凑合。软件开发行业的很多单词，我都认得；不太复杂的内容，也能自己看懂。但书写表达较弱，口语和听力更弱，平时和同事、AI 沟通，仍然需要一些翻译帮助。
遇到一段看起来很复杂的英文，或者手头工作比较急，我的习惯是直接让 AI 翻译。问题很快解决了，自己读英语的机会也少了一次。
我每天工作、使用 Coding Agent 的时间很长。既然已经有这么多真实的交流，能不能让 AI 把英语写得更容易读，让我多看一点、多写一点，把练习融入正在做的事情？
我已经给 Codex 的用户级指令加上了这项偏好：默认使用简单英语，保留准确的技术术语；我需要时，再提供中文帮助。
这是一项刚开始的尝试，还没有长期效果数据。我对它有信心，因为它利用了我每天都会发生的工作。如果你也能读懂简单英文，却经常依赖翻译，可以从同样的小调整开始。
我想先解决的，是长句带来的阻力
对我来说，cache、request、timeout 往往不是最大的障碍。更费力的是一句话里同时出现条件、原因、例外和多个指代。我认得单词，却需要来回读，才能确认谁在做什么。
以一个假设的客户端行为为例。下面是为了说明写法而构造的例句，不是实际运行记录：
If the cached token has expired, the client requests a new token before retrying the original request, unless token refresh fails.
把同一个逻辑展开，可以写成：
If the cached token has expired, the client requests a new token.
If token refresh succeeds, the client retries the original request.
If token refresh fails, the client does not retry the request.
条件、先后顺序和失败分支都保留了。每句话要处理的信息少一些，我更容易顺着读下去。
这也是我给 AI 的要求：减少句子结构的复杂度，保留解释的完整性。不能为了写短句，把“只有在刷新成功时才重试”这样的关键条件删掉。
为什么我选 Google 写作指南，再加个人规则
整理英语简化规范时，很容易遇到一串名字：技术写作指南、Plain English、Basic English、Globish，以及受控自然语言。它们的目标和限制并不相同，也不构成一套统一的软件行业标准。
我主要比较了 Google Developer Documentation Style Guide 和 ACE，也就是 Attempto Controlled English。
Google 的指南强调简单用词、较短的句子、主动语态、术语一致，以及避免俚语和文化背景依赖。这些建议很贴近我阅读开发文档、方案解释和代码注释的需求。[1]
但它没有承诺“按这个指南写，基础英语读者就一定看得懂”。它是一套技术写作指南，不能直接充当个人难度设置。
ACE 则通过限制语法和解释规则，帮助表达精确的规格，并支持机器处理与形式化转换。[2] 这很适合某些需要明确逻辑的场景。我当前主要需要读懂排障解释、讨论实现方案、提出修改要求，没有必要把日常交流都限制在 ACE 的语法里。
所以，我采用的组合是：Google 的清晰写作原则，加上自己的可读性规则。我在这里说的“受控英文”，就是让 Agent 按约定控制句长、用词和句式；它不等于严格符合某套受控自然语言标准，也没有经过语法验证器检查。
我的几条核心要求是：
使用常见日常词，保留准确的开发术语。
一句话表达一个主要意思，优先使用主动语态。
尽量减少嵌套从句；指代不清时，重复名词。
同一个概念使用同一个名称，不为了变化而换同义词。
尽量写成 8–15 个词的句子，但以表达完整为先。
其中，8–15 个词是我个人设置的目标，不是 Google 官方规定。有些句子需要更长，有些很短也能讲清楚。我希望 AI 写自然、准确的英语，不要求它机械数词。
把规则放进 Agent 的长期上下文
如果每次都要先说“请使用简单英语”，很容易在忙起来时忘掉。我把偏好写进了 Codex 的用户级 ~/.codex/AGENTS.md。
按 Codex 的官方说明，它会从 Codex 用户目录读取全局指令，再结合项目指令。这个目录默认为 ~/.codex；如果设置了 CODEX_HOME，就要使用对应目录。该目录中存在非空的 AGENTS.override.md 时，会优先使用该文件；具体项目的规则也可能覆盖较早的全局要求。[3]
下面这段可以复制到你的用户级指令文件中。已有内容时，追加即可。其他 Coding Agent 可以放进各自支持的长期指令位置，具体加载方式以工具说明为准。
## Simple English for work and learning
I know many software development terms.
I can read simple English, but complex sentences are difficult.
I want to improve my English through normal technical work.
Use simple English for replies, progress updates,
documentation, and code comments.
Reply in English by default, even when I ask in Chinese.
Honor explicit language requests and project requirements.
Keep the requested language of deliverables, such as Chinese articles.
Follow the Google Developer Documentation Style Guide
where relevant, with these additional rules:
- Use common everyday words and accurate technical terms.
- Aim for 8–15 words per sentence when practical.
This is a target, not a strict limit.
- Express one main idea per sentence.
- Prefer active voice and clear subjects.
- Avoid nested clauses, idioms, slang, and figurative language.
- Use the same term for the same concept.
- Repeat a noun when a pronoun would be unclear.
- Briefly explain unfamiliar terms when needed.
- State the main point first, then explain reasons or steps.
- Preserve conditions, exceptions, and technical accuracy.
- Keep identifiers, commands, API names, and quotes unchanged.
- Do not rewrite unrelated content to enforce these rules.
Accept Chinese, English, and mixed-language requests.
Provide Chinese support when I request it.
If I say the English is too difficult, simplify it.
Add Chinese support as needed.
When I write in English, answer my question first.
Then, when useful, suggest one concise, natural rewrite.
Do not correct every minor error or turn work into a lesson.保存后，开启新的 Codex 会话，让它概括当前的英语偏好，检查是否读到了这些要求。[3] 再用一个实际任务试读，比只看配置文件更有用。
文档和代码注释要遵守项目的语言要求。团队需要中文的地方照常写中文；已有文件也不用为了个人练习全部改写。这项偏好首先服务于我和 Agent 的交流。
看不懂时，先请求更简单的英文
我准备改变的一个习惯是：看到英文后，先自己读一遍，再决定需要什么帮助。
能理解结论、理由和下一步，就继续工作。某句话卡住了，可以先让 AI 保留技术细节、换成更简单的英文：
Please rewrite this explanation in simpler English.
Keep all technical details and conditions.简化后仍然看不懂，或者任务很急，就请求中文解释。理解之后，有余力再回看关键英文句子，看看刚才卡在了哪个词或哪种结构。
下面的示意图中，沿蓝色主线读懂后就继续工作；右侧的橙色路径提供逐级帮助，再沿回路重新阅读。意思确认后，才进入绿色的“继续工作”。
先尝试阅读；卡住时简化或翻译，再回看英文，读懂后继续工作。
遇到删除数据、权限调整、生产环境操作等需要精确理解的内容，我会直接确认含义，必要时使用中文。练习不应该让关键决策变成猜测。
我仍然会使用翻译。变化在于，把能够自己读的部分留下来，把帮助集中在真正卡住的地方。
书写从一句真实需求开始
我也希望借和 AI 沟通练习表达。但如果每个请求都要先查语法、改到满意，工作很容易被打断。
更容易开始的方式是：用自己会的英语提出需求，卡住的部分允许夹中文。让 AI 先处理任务，再给一句自然改写。
例如，我可以这样写。这同样是演示例句：
Please check this function. 我担心并发问题。AI 可以在处理问题之后，补一句：
Please check this function for concurrency issues.下次遇到类似任务，我就有了一句可以直接使用的表达。不需要一次学完关于并发的所有英语，也不需要对每个冠词错误都停下来纠正。
几类常见工作请求尤其适合先自己写：
Please explain why this test fails.
What happens if the request times out?
Please compare these two options.
Please keep the existing behavior.还可以用一句自己的话复述 Agent 的解释，请它检查我有没有理解错：
My understanding: the client retries only after token refresh succeeds.
Is that correct?这里除了练表达，也是在检查阅读理解。如果我说错了条件，AI 应该先指出意思上的问题，再处理语言上的问题。
想提高阅读速度，就观察真实工作的变化
我已经能看懂不太复杂的内容。接下来希望突破的，是阅读时的熟练程度和速度。我愿意让日常工作中出现更多自己能够读下去的英文。
对这个尝试，我最看重的条件有三个：任务是真实的，内容是我关心的，难度可以调整。相同的表达会在不同工作中再次出现，我也有机会把刚看到的句子用在下一次请求里。这是我愿意持续尝试的理由，还不能作为“必然快速进步”的证明。
开始时，可以只选一个入口：先自己读 Agent 的任务总结，或者每天用英语提出一个修改请求。适应以后，再扩展到方案解释、文档和注释。
一段时间后，我想观察的也不是 Agent 输出了多少英文，而是：
同类任务中，我是否更少需要整段翻译？
我能否更快找到结论、条件和下一步？
我能否用自己的话复述，而不只是觉得“看着懂了”？
我是否开始主动使用以前需要 AI 改写的表达？
这些是个人观察项，不是标准化英语测评。同一段材料反复读得更快，也不能直接证明我能更快读懂新材料。可以偶尔换一段同类、没读过的解释，看看自己是否也能顺利理解。
等简单英语读起来比较顺畅，再逐步减少额外简化，接触较自然的英文解释和原始文档。对陌生且复杂的内容，仍然保留帮助。阅读与书写的练习，也不能代替听力、口语需要的训练。
我想先做到一件很具体的事：明天与 Coding Agent 工作时，多自己读一段英文，多亲手写一句请求。遇到困难，按需要请求帮助，再继续完成工作。
如果你也每天大量使用 Coding Agent，已经能读懂简单英文，却习惯一遇到长句就翻译，可以试着给它加上这组规则。先从一个你熟悉的工作任务开始，看看这样的英文，你是否愿意多读一点。
参考资料
Google Developer Documentation Style Guide：Write for a global audience——简单用词、短句、主动语态及术语一致性的官方建议。
Attempto Controlled English Language Manual，Version 3.0——ACE 的规格表达目标、语法限制与形式化用途。
OpenAI 官方文档：Custom instructions with AGENTS.md——Codex 全局与项目指令的发现、优先级及会话加载方式。