17C.07起草不能只根据编号直接套模板，因为“17C.07”可能是条款号、内部文件编码、表单项目号或技术文件章节号。正式动笔前，应先确认文件名称、发布或使用单位、适用范围、版本状态和最终交付形式，再决定写成条款、制度、说明还是表格内容。

如果暂时无法取得完整依据，最稳妥的做法是先制作“编号定位表”，把来源、目的、对象、关联文件和待确认问题列清楚。信息没有核实以前，只能形成结构稿，不能把推测内容写成正式要求。

17C.07起草前，先把编号定位到具体文件

17C.07起草的第一步是确认编号的完整语境，而不是先写正文。单独的“17C.07”无法说明它究竟属于哪份文件，也无法判断其中的“17”是章节号、项目号、年份标记还是内部分类号。

编号定位表至少应记录原始出处、当前版本、上位依据、关联章节、使用场景和联系人。若编号来自截图或口头通知，还应补充截图所在页面、前后标题和上下文，避免只凭一个孤立代码起草。

先判断17C.07属于哪一种文本

17C.07的文本类型决定写作重点，条款、管理制度和表单项目不能使用同一种表达方式。判断时可以观察编号前后的标题、同级项目的写法以及文件中是否出现“应、不得、可、宜”等规范用语。

• 如果属于规范条款。重点写清适用条件、行为要求、例外情形和验证方式。条款应能回答谁在什么情况下必须做什么，以及做到什么程度才算符合。
• 如果属于管理制度。重点写清职责分工、办理流程、时限要求、审批权限、记录保存和异常处理。制度文本不能只写原则口号，否则执行人员无法据此办理。
• 如果属于技术要求。重点写清对象、参数、单位、允许范围、测试方法和判定规则。数值没有单位、条件没有边界时，技术要求通常无法检验。
• 如果属于表单或系统字段。重点写清字段名称、填写主体、数据格式、必填条件、校验规则和示例。字段说明与正文条款必须保持一致。

文本类型无法确认时，应先提交一页结构确认稿，而不是直接提交长篇正式稿。结构确认稿只列出标题、层级、主要责任对象、关键动作和待补资料，可以让需求方尽早纠正方向。

条款型内容应按“条件—动作—标准”展开

条款型17C.07起草应把一个完整要求拆成条件、动作和结果标准。这样的结构能够减少主语缺失、责任不明和执行尺度不一致的问题。

1. 先写适用条件。说明该要求在什么业务、对象、阶段或风险状态下适用。没有条件时，读者可能把局部要求误解为所有场景都适用。
2. 再写责任对象。明确由哪个部门、岗位、项目负责人或操作人员完成，避免使用“有关人员”“相关部门”等无法追责的泛称。
3. 接着写具体动作。使用“提交、审核、记录、检测、隔离、复核、批准”等可观察动词，少用“加强、做好、及时、妥善”等无法直接验证的词语。
4. 最后写完成标准。明确时间、数量、范围、格式、质量要求或判定条件。需要留出判断空间时，应说明判断依据和审批权限。

规范用语应保持层级稳定。“应”适合表达必须履行的要求，“不得”适合表达禁止行为，“可”适合表达允许选择，“宜”适合表达推荐做法。起草人员不能把“应当完成”和“原则上完成”混在同一强制层级中。

一个条款尽量只承担一个主要义务。若同一句同时规定资料提交、审核责任、保存期限和例外处理，应拆成分款或分项，使后续修改、检查和责任认定更加清楚。

内部制度型文本要补齐执行闭环

内部制度型17C.07起草必须形成“发起—办理—审核—留痕—异常处理”的闭环。只有目标和原则，没有流程节点与记录要求的文本，通常不能直接指导工作。

• 发起环节：写明什么情况可以启动、由谁提出、需要提交哪些材料，以及材料不完整时如何退回。
• 办理环节：写明承办部门、办理顺序、时间要求和跨部门配合方式，避免把多个职责全部压给一个笼统主体。
• 审核环节：写明审核重点、审批权限和不同风险等级下的处理差异。金额、风险或影响范围存在分级时，应设置相应的升级路径。
• 留痕环节：写明需要保存的表单、日志、检测记录、审批意见和版本信息，并注明保存责任。
• 异常环节：写明逾期、资料缺失、结果不合格、系统故障或责任人无法履职时的替代处理方式。

制度中出现“及时处理”时，应进一步说明处理时限；出现“必要时上报”时，应说明什么情形属于必要；出现“按规定执行”时，应列出具体规定名称或关联条款。无法补充依据的地方应保留待核标记，不宜用模糊表述掩盖缺口。

起草说明和正文要分别解决不同问题

起草说明用于解释为什么这样写，正文用于规定实际应该怎么做，两者不能互相替代。审查人员看起草说明时关注必要性、依据、主要变化和争议问题，执行人员看正文时关注责任、步骤、条件和结果。

起草说明通常可以安排以下内容：

1. 说明文件或条款的制定背景，以及现有流程中需要解决的具体问题。
2. 列出主要依据，并注明依据名称、版本或对应条款，避免只写“根据有关规定”。
3. 解释适用范围、责任主体、关键术语和主要制度安排。
4. 说明与现有文件的衔接关系，包括新增、修改、删除或保持不变的内容。
5. 列出仍需确认的事项，例如数据口径、部门职责、时限、表单名称和系统字段。

正式正文不宜大量重复背景论证。正文应集中表达可执行要求，解释性内容放入定义、注释或起草说明中，避免把建议、理由和强制条款混写在同一段。

用反例和审查清单检查可执行性

17C.07起草完成后，应使用真实业务场景进行反向验证，而不是只检查错别字。至少选择一个正常场景、一个边界场景和一个异常场景，按照文本逐步操作，记录无法判断的位置。

• 责任对象是否能够唯一确定，是否存在两个部门都以为对方负责的环节。
• 启动条件是否可识别，是否需要某个日期、材料、数据或审批状态才能触发。
• 动词是否能够被观察和检查，是否存在“适当、及时、合理、必要”等未定义词语。
• 时间要求是否明确起算点，工作日、自然日和截止时点是否混用。
• 数量、比例、金额、尺寸和单位是否统一，正文与表单是否采用同一口径。
• 例外情况是否说明批准人、替代流程和补充记录要求。
• 与上位文件、同级文件和现行流程是否存在冲突，旧版本是否需要废止或同步修改。
• 编号、标题、交叉引用、附件名称和表格字段是否前后一致。

审查意见应区分“必须修改”“需要确认”和“文字优化”三类。必须修改涉及依据冲突、责任错误、程序缺失和无法执行；需要确认涉及业务口径或权限边界；文字优化只处理表达顺序和格式。分类后，修改记录更容易追踪，也能避免把重要问题埋在一般性文字意见中。

可直接套用的最小起草框架

最小起草框架适合在资料不完整、需要先交结构稿时使用。框架不代表最终内容，括号中的信息必须根据真实来源补齐。

完成17C.07起草时，最重要的不是把文字写得复杂，而是让来源可追溯、责任可定位、动作可执行、结果可验证。若编号来源、文件类型或适用范围仍不明确，应先补齐这三项信息，再进入正式定稿。