夜雨聆风
你的文档需要一套AI使用策略
好文翻译，原文链接
https://passo.uno/ai-docs-policy-contributions/
AI参与撰写的文档贡献浪潮，或许即将全面到来。这股趋势在代码领域早已显现，相关讨论甚至在思考该如何审核由AI生成、包含九千行新代码的拉取请求（pull request）。在汤姆·约翰逊所说的技术加速（acceleration）阶段，采用文档即代码（docs-as-code）模式的写作者们，都在思考如何遏制这股看似无法阻挡的浪潮，避免大量低质AI内容淹没待处理任务。而解决方案，或许就是明确立场——为文档制定专属的AI使用政策。
即便如部分科技行业预测者所言，所有主流AI公司未来某天都会倒闭，它们研发的产品也会留存下来，成为计算生态（computing landscape）的一部分。AI模型的训练与部署会高度大众化，甚至能免费搭建专属模型，并在手机上运行。当人人都能使用这款强大的文本生成（text generation）工具时，用户在文档即代码场景中用AI参与文档创作，只是时间问题。
技术写作者（tech writers）不能指望AI消失，也无法回避它对日常工作的影响。遗憾的是，即便出于伦理与职业考量反对AI用于文档撰写，若想保住这份工作，这种抵触并不现实。更糟糕的是对身边的变化漠不关心、随波逐流——这会慢慢消磨掉技术写作者赖以适应环境的学习能力与沟通协调能力。
技术写作若想作为一门职业存续下去，就必须应对新一轮技术变革，主动参与并融入其中。
想要捍卫技术写作，就要主导并制定游戏规则
二十年前，我接触过合气道（Aikido），这是一种既能自卫、又能避免伤害攻击者的武术。合气道的核心不是格挡攻击，而是引导对方的力量为己所用。看待AI与文档的关系，道理相通：与其完全禁止AI或回避问题，不如制定指导规范与工具，通过AI辅助生成文档。而一套完善的政策，就是我们的合气道反击技法（ude gaeshi）。
尽管“政策”听起来偏官僚化，但它本质只是一份立场声明，是通过原则与规则明确的工作态度。政策能为新工具、新工作方法定下基调与框架，明确工作预期，界定可接受与不可接受的产出成果。你完全可以为文档制定AI使用政策，就像你制定过的风格指南（style guide）、问题模板或文档内容策略（content strategy）一样，这份工作的主导权本就属于你。
但在制定政策前，你需要明确希望大语言模型（LLMs，Large Language Models，能理解和生成人类语言的AI模型）如何融入你的工作。下面我会分享一些思路，为你制定政策提供参考。
先明确文档与AI结合的核心原则
指导规范的开篇，应明确生成式AI（generative AI）或大语言模型应用于面向用户文档的核心原则，后续政策都要围绕这些原则展开。比如，要将人类对AI产出负责作为核心原则：作为AI工作的发起者与监督者，你必须对最终内容负责。同时，也要明确内容质量的最终决策者（通常是你自己）。
如果所在公司已有现成的生成式AI相关政策与规范，你可以以此为基础，将文档AI政策作为延伸，在核心原则上补充更具体的指导建议。比如公司大概率已列出许可使用的生成式AI工具与模型清单。若公司暂无相关政策，你自主制定的文档政策，还能为工程团队提供参考范例。
明确需要人类专业能力的场景
贡献者可能会困惑，究竟何时、何种场景下，能将大语言模型用于文档相关工作。你可以列出适合用AI辅助提升效率、补充能力的使用场景，帮他们理清思路。同时，也可以排除或明确禁止部分场景使用AI，比如架构设计工作、从零撰写整套全新文档等。当下我们正处于AI探索阶段，不妨牢记合气道的思路：多明确可以做什么，而非一味禁止。
比如，你可以规定生成式AI可作为传统查找替换功能的替代方案，或是比正则表达式（regular expressions）更高效的批量编辑工具。也可以明确，只要用户完成内容校验，大语言模型自动补全等用法始终允许。结合自身工作经验，划定你期望的AI贡献边界即可。
把AI贡献和其他贡献一视同仁地审核
开源容器项目（opencontainers）目前正在讨论AI政策的落地，争议焦点之一就是：在开源（open source）场景中，AI生成的贡献是否应与人工贡献同等对待。这个问题同样适用于文档领域。有评论者认为，贡献的来源不应区别对待。我个人的观点，可以用用户alexchantavy的评论总结：
作为开源项目维护者，我不反感AI，我反感的是低质垃圾内容——无论它来自机器还是人类。
作为文档负责人，你有权设定文档的质量标准。使用大语言模型生成、或有大量AI参与的文档，都要和人工文档走完全相同的审核流程。不过，你仍需要知晓内容是否有AI参与，以便排查AI幻觉（hallucinations，指AI编造虚假信息、不存在的内容）等问题。明确拉取请求是否借助AI完成，会让审核更高效，这也引出了下一条建议。
要求披露AI使用情况，即便无法被检测
当贡献者记录下AI的使用细节（使用的工具、提示词（prompts）、效果优劣），整个团队都会受益。久而久之就能总结出规律：某类文档适配AI生成，某类文档需要投入的人工成本远高于AI价值。如今我们已无法精准识别AI生成的文本，因此披露AI使用，更多是职业诚信问题，而非强制要求。
有价值的披露信息包括：贡献者使用的工具或模型、初始提示词、后续人工修改量、AI出错的地方，以及是否会再次用AI处理同类工作。这能帮助团队优化AI辅助工作流，也能逐步完善政策。但不必过于严苛，AI使用披露本就复杂，尤其在存在“AI歧视”的氛围中。若怀疑内容用到AI，温和提醒贡献者披露即可。
依靠确定性安全机制与测试工具
传统且可靠的确定性测试（deterministic testing，即规则固定、结果可预测的自动化测试），是批量管控大语言模型这类“智能机器人”的最佳方式。AI不会在自动化检测中享受特殊待遇，所有内容都要通过现有质量把关流程：代码检查工具（linters）、链接检测、拼写检查、构建测试。持续集成工作流（CI workflows）不会在意内容由谁撰写，这能让人工审核者专注于核心工作：风格、结构、实用性、价值等。
如果现有工具无法检测AI产生的错误，比如虚构的指令、不存在的应用程序编程接口（API）方法、看似正确实则错误的语法，或许正是扩充测试体系的好时机。就像曼尼·席尔瓦主张的“文档即测试”（docs as tests）理念，要用对待代码的严谨程度对待文档。正如我在《文档即代码的真正含义》中所写：
你绝不会在未经充分审核与测试的情况下将代码上线，也别仓促发布文档——因为文档本身就是基础设施（infrastructure）的一部分。
继续做技术适应的掌控者
几十年来，技术写作者历经多次技术变革都屹立不倒，AI的到来也不会例外。如果说这是一种现实政治（Realpolitik）思维，其实并不为过：大语言模型生成的内容贡献已成事实，无法逆转。制定文档AI使用政策，意味着全程主导工作流程，提醒所有人：文档创作需要专业能力与高标准质量要求。这种战略思维，才是让我们立足的核心。
当下对技术写作而言，最危险的做法是袖手旁观，等待他人制定规则。我们不能指望问题自行解决，不如立刻着手起草政策、明确立场，并在实践中持续优化。你的政策也能彰显你为团队创造的价值，退一步说，它还能引发团队内部被忽视的深度讨论，而我们恰恰需要这种深度思考。