ARTICLE · 990517
codex文档编写Skill使用指南
Codex 文档编写 Skill 使用指南｜规则、提示词及工作流
很多人让 Codex 写文档时，问题不在于它不会写，而在于每次都要重新解释读者、语气、结构、格式和验收标准。今天写周报，明天写 SOP，后天写公众号文章，提示词不断变长，结果却依然不稳定。
解决方法是把写作方法沉淀成一个文档编写 Skill。Skill 不是一句“请写得专业”，而是一份可调用的作业指导书：什么时候使用，读取什么资料，按什么步骤工作，输出什么格式，遇到不确定信息如何处理，交付前检查哪些内容。
这篇指南将带你从零搭建一套 Codex 文档编写 Skill，并解释规则、提示词和工作流如何配合。
一、先定义 Skill 要解决的文档问题
不要一开始就做“万能写作 Skill”。先选择一种高频、边界清楚的文档类型，例如项目周报、会议纪要、SOP、研究摘要或公众号教程。
选择时看三个条件：输入是否相对稳定，输出是否有固定结构，质量是否可以被检查。满足这三个条件，最容易形成可复用流程。
先收集三到五份真实样例，标记它们的共同点和差异：读者是谁，开头如何进入主题，章节如何组织，哪些字段必填，哪些内容必须人工确认。样例比抽象形容词更能帮助 Codex 理解你的标准。
二、设计 Skill 的基本结构
一份实用 Skill 至少包含八部分：
名称和适用场景； 触发条件； 输入字段； 上下文读取顺序； 执行步骤； 输出模板； 质量检查； 禁止事项和失败处理。
名称要让人一眼看懂，例如“公众号教程写作”或“项目 SOP 编写”。触发条件说明什么情况下调用，避免它被错误用于不适合的任务。
输入字段要具体：主题、读者、目标、资料路径、字数、语气、截止时间和发布渠道。没有提供的字段，Skill 应该要求补充或明确标记待确认，而不是自行猜测。
三、把规则写成可执行要求
规则不是“写得好一点”，而是可观察、可验证的行为。
“语言专业”可以改写为“避免夸张承诺，使用短句，首次出现的术语给出解释”。“结构清晰”可以改写为“先给结论，再给背景、步骤、注意事项和检查清单”。“适合手机阅读”可以改写为“单段不超过若干句，重要内容使用小标题和列表”。
规则建议按优先级排列：
事实和安全规则； 读者与目标规则； 结构和格式规则； 语气与风格规则； 可选的美化规则。
如果规则冲突，明确哪一条优先。例如，事实准确优先于语言流畅，人工确认优先于自动发布。
四、建立上下文读取顺序
文档写作需要资料，但不代表要把所有文件一次性塞给 Codex。规定读取顺序可以减少遗漏和噪声。
推荐顺序是：先读项目规则，再读文档模板，然后读本次输入资料，最后参考历史样例。读取后，让 Codex 先输出“已理解的目标、读者、资料范围和限制”，你确认后再开始写作。
稳定信息放在项目规则中，临时要求放在当前任务中，历史经验放在案例或交接记录中。这样更新一个规则时，不会影响所有临时任务。
五、设计一条标准文档工作流
文档 Skill 可以采用七步流程：
第一步，确认目标和读者；第二步，盘点并筛选资料；第三步，生成结构提纲；第四步，完成初稿；第五步，进行事实、结构和风格检查；第六步，根据反馈修改；第七步，输出成品和交付说明。
每一步都应有明确产物。资料盘点产出来源清单，提纲产出章节骨架，初稿产出可阅读文本，检查产出问题列表，交付产出文件路径和待确认项。
不要让 Codex 在一个回合里做完所有事情。分阶段执行能更早发现方向错误，也方便只重跑失败步骤。
六、写一条高质量提示词
提示词负责把本次任务交给 Skill。可以使用下面的顺序：
角色：你是某类文档的编辑助理。
目标：这份文档要帮助谁完成什么决定或动作。
输入：读取哪些文件，哪些文件是唯一事实来源。
要求：字数、结构、语气、格式、图片和链接要求。
流程：先计划，再写作，再检查，发现缺失信息先提问。
输出：正文、摘要、素材清单、检查结果和待确认事项。
一个具体例子是：“请调用文档编写 Skill，把资料目录中的项目规则整理成新人 SOP。读者是第一次接手项目的同事，输出背景、目标、步骤、责任、风险和检查清单。不要补写资料中没有出现的事实，先给提纲，确认后再写正文，最后报告来源文件和未解决问题。”
提示词不需要重复 Skill 中的长期规则，只补充本次任务的变量。
七、设计输出模板和文件命名
固定模板可以显著减少返工。以 SOP 为例，建议包含：适用范围、前置条件、操作步骤、异常处理、责任人、交付物和检查清单。
以公众号文章为例，可以固定为：标题、摘要、导语、正文、小结、配图清单和发布前检查。
文件命名也属于 Skill 的一部分。使用统一的日期、主题、版本和状态，例如“日期-主题-v02-待确认”。成品和草稿放在不同目录，避免 Codex 读取到过期版本。
输出时要求 Codex 同时报告绝对路径、版本和修改摘要。不要只说“已经完成”。
八、让 Skill 保留特殊内容
文档中可能有表格、代码块、嵌套列表、提示框和任务清单。Skill 应该明确“保留原有语义和结构”，而不是把它们压平成普通段落。
公众号可见内容中，任务清单使用“□”和“☑”等文本符号，避免把原始 Markdown 勾选语法直接暴露给读者。表格要检查移动端可读性，代码要保留缩进和必要说明。
如果文档使用教程卡片布局，可以通过 hero、章节导航和 section-block 强化阅读，但不能为了排版而删除正文信息。
九、建立质量检查门
检查至少分为五类：
事实检查：是否出现资料中没有的结论，数字和名称是否有来源。
结构检查：是否回答了目标问题，章节是否有顺序，是否存在重复。
读者检查：术语是否解释，步骤是否能执行，语气是否匹配读者。
格式检查：标题层级、列表、表格、图片路径和文件命名是否正确。
安全检查：是否包含密码、隐私、未公开信息或未经授权的外部动作。
要求 Codex 输出通过项、失败项和未验证项。把不确定内容单独列出，不要用一句“已检查”带过。
十、处理资料不足和规则冲突
文档任务经常遇到资料不全。Skill 应规定处理顺序：先指出缺口，再给出合理的占位结构，最后列出需要用户确认的问题。
如果资料之间冲突，保留冲突信息和来源路径，优先使用标记为最新、已确认或项目主文档的版本。无法判断时停止生成确定性结论。
规则冲突时，也要让 Codex报告冲突。例如，用户要求“不要使用列表”，但项目模板要求“步骤必须编号”，应按照更高优先级规则处理，并向用户说明。
十一、把反馈沉淀回 Skill
不要只在当前对话里纠正一句“标题不够具体”。把反馈归类为规则、模板、流程或检查项。
如果同类问题重复出现，就修改 Skill；如果只发生在某个项目，就修改项目规则；如果是本次临时偏好，就留在任务说明中。
每次更新保留版本和变更说明。新增规则先用真实样例测试，确认不会破坏原有交付。
十二、一个完整使用示例
假设你要让 Codex 编写一份客户回访 SOP。
先把访谈记录、现有流程和异常案例放入 inputs，再给出目标读者和使用场景。调用 Skill 后，Codex 先盘点资料并列出缺口，再生成 SOP 提纲。
你确认提纲后，它继续写初稿，输出适用范围、准备工作、标准步骤、异常分支、话术示例和检查清单。随后运行事实和格式检查，把不确定项放到待确认列表。
你补充两条业务规则后，Codex只重写受影响章节，保留其他内容和版本记录。最终文件进入 outputs，交接记录写入项目首页。
这个例子说明，Skill 的价值不是替你按一次按钮，而是让整个过程有顺序、有边界、有证据。
十三、常见误区
把 Skill 写成角色扮演：只写“你是专家”，没有输入、步骤和验收。
规则互相矛盾：既要求极简，又要求覆盖所有细节，却没有优先级。
上下文无限堆积：把整个项目所有历史文件都交给模型，造成噪声。
没有人工确认：让 AI 直接覆盖原文档或发布外部内容。
只看最终稿：不检查来源、差异、路径和未验证问题。
一次性做万能 Skill：职责过大，难以测试和维护。
十四、文档编写 Skill 检查清单
□ Skill 是否有明确名称和适用场景？
□ 输入字段是否具体，缺失信息如何处理？
□ 项目规则、模板和当前任务是否分层？
□ 是否规定了先计划、再写作、后检查？
□ 输出模板和文件命名是否统一？
□ 是否保留表格、代码块和任务清单等特殊内容？
□ 是否区分事实、推断和建议？
□ 是否检查来源、隐私、格式和链接？
□ 高风险操作是否设置人工确认？
□ 每次反馈是否能沉淀为规则、模板或检查项？
结语：把写作经验变成可调用能力
Codex 文档编写 Skill 的核心，不是让提示词变长，而是把你的工作方法写成一套可执行的规则和流程。
先定义文档问题，再设计输入、上下文、步骤、模板和检查；让 Codex 分阶段工作，保留来源和版本；把重复反馈沉淀回 Skill，让每一次交付都改善下一次。
当你能用同一套方法稳定产出周报、SOP、研究摘要和教程文章，Codex 就不再只是临时写手，而会成为真正懂你工作标准的文档协作伙伴。