k2f-policy-document

K2F Policy Document — AI 原生美学设计

目的

指导 Agent 在排版前为政策文档制定蓝图：构建易于浏览的规则架构、面向员工的通俗语言层级和正式的层次结构，同时不得擅自编造用户或 HR／法务未提供的福利、法律义务、管辖范围或审批流程。

基于 K2F 构建

此技能将政策文档生成为 .K2F 包。按照 k2f 技能进行创作：解包或初始化工作区、编辑语义树、运行 pack／verify，然后导出。K2F 让 Agent 专注于含义（章节、强调、表格），而非像素坐标；布局、排版和主题则由引擎编译，生成一致且可供导出的成品。

开始构建前，请安装核心技能：npx skills add suzheng/k2f --skill k2f。

适用场景

• 新建或更新单项政策页面（带薪休假、远程办公、费用、行为规范、差旅、安全、各类假期）。
• 员工手册中的章节：须与既定风格保持一致，同时便于读者快速查找。
• 将草稿或粘贴的政策内容重新整理为适合 HR 或法务审阅并发布的结构。
• 不适用于仅在聊天中进行政策问答、AgentRC 评分政策或律师级合同（请使用 k2f-contract）。

工作流

步骤 1. 生成 content_and_design.md

将信息架构与设计意图结合成一份蓝图。标注内容块，以便 k2f 技能之后将其映射为章节、提示框和强调内容。

子步骤

1. 文档框架——政策标题、用户提供的文档 ID、生效日期、版本、政策负责人（团队／角色）以及适用范围（实体、地点、雇佣类型）。说明这是新政策、修订还是取代先前文本；仅在用户提供的信息中包含先前版本链接时才添加。

2. 目的与范围——分成两个简短部分：说明政策制定原因（最多一段）以及适用对象／时间。删去重复标题的叙述；如果适用范围涉及用户未指定的地区，则标注 HR VERIFY。

3. 一览层——快速摘要（3–5 条要点或一段简短文字）：说明员工阅读详细内容前必须了解的信息。这是浏览时的锚点，不是所有规则的另一份副本。

4. 定义——仅收录会改变本政策合规含义的术语；省略词典式术语表。

5. 政策声明——编号列出规则：明确主体、情态动词（must／may not／requires approval）和结果。每条要点只包含一项义务；不要在同一条要点中混写“政策 + 操作指南”。

6. 流程——分开列出编号流程：如何申请、报告、升级处理或记录合规情况（表单、系统、时限仅采用用户提供的信息）。流程引用规则，不要用文字重述规则。

7. 角色与职责——使用简洁的矩阵或要点说明：员工、经理、HR、IT、财务、法务分别在各步骤中负责什么。

8. 例外与审批——说明谁可以批准例外、需要哪些文件，以及记录存放在哪里。如果未知，标注 APPROVAL PATH — USER TO CONFIRM。

9. 相关政策与参考资料——仅添加用户指定的交叉链接和外部法规；不得编造引用。

10. 执行与问题——仅在用户提供相关信息时列出后果或渐进式纪律处分；否则标注 LEGAL/HR TO CONFIRM。说明边缘情况的联系人，并提供唯一的问题反馈渠道。

11. 修订历史——使用表格或列表，列出版本、日期、变更摘要和审批人；待用户填写的占位内容标记为 TBD。

12. 设计意图 — 清晰优先于装饰：

    • 语气：摘要采用中性、权威、通俗易懂的语言；编号规则措辞严谨准确；不使用营销或道歉语气。
    • 层级：优先呈现标题和适用范围；一目了然和政策声明最醒目；程序和角色次之；修订历史居后。
    • 信息密度：适中——段落简短；规则和程序使用项目符号；用户提供数字时，用表格呈现角色或阈值；避免大段文字。
    • 配色：采用克制的中性色，正文对比度高；仅在必须/不得、截止日期和审批流程处使用少量强调色；符合 WCAG AA；不使用会分散规则注意力的图库图片。

规则与约束

• 来源把关：强制性或特定司法管辖区的措辞必须逐字保留用户提供的内容；所有其他草稿均标注 FOR HR/LEGAL REVIEW。
• 诚实把关：不得编造 PTO 天数、金额限额、法律引文、系统或审批人姓名。
• 区分把关：规则放在政策声明中；步骤放在程序中；不得将规则藏在程序段落里。
• 适用范围把关：每项义务都须明确说明适用于谁；地理范围不明确时应标记，不得默认假定适用于美国。
• 单一主题把关：每份蓝图只涵盖一个政策主题；除非用户明确要求合并为包含明确命名部分的员工手册章节，否则应拆分无关主题（例如差旅与费用）。

常见失败模式

• 引言冗长，却没有一目了然的内容 → 员工找不到规则。
• 规则埋在 FAQ 叙述中 → 将祈使性要求提取为编号的政策声明。
• 先讲程序再讲规则 → 调整顺序，先说“是什么”，再说“怎么做”。
• 快速摘要和完整章节重复 → 摘要保持简短；详细内容放在下文。
• 使用通用的 AI 员工手册语气 → 替换为用户提供的术语、系统和审批人；否则标注 TBD。
• 缺少联系对象 → 边界情况会流入非正式渠道。
• 修订历史中修改内容未注明变更内容 → 合规跟踪会失效。
• 将面向员工的通俗文本与特权法律分析混在一起 → 仅保留对外语气。

质量检查清单

• 框架包含适用范围、生效日期，以及新增/修订/取代状态。
• 一目了然的内容可独立阅读；政策声明已编号并采用祈使句。
• 程序单独列出；已提供角色和例外处理流程，或标记为 TBD。
• 用户要求的文本逐字保留；未编造限额、引文或联系人信息。
• 仅列出用户输入中提及的相关政策。
• 设计意图明确说明规则与程序的语气、层级、信息密度和强调方式。

步骤 2：使用 content_and_design.md 和 k2f 技能生成 K2F 文件，并导出为合适的文件格式。

按照 k2f 根据蓝图编写政策、应用设计意图角色、进行验证，并导出供 HR/法务审核的文件（通常为 PDF 或 DOCX）。