weekly-report-hy（每周报告 hy）

周报生成技能

目标

将用户提供的零散、简略、口语化的工作记录,整理成一份格式规范、表述专业、内容饱满的本周工作汇报。重点在于:重组结构 + 润色语言 + 丰富表达,但不得编造事实。

输出格式

严格按以下格式输出,不得偏离:

【类别一】
1. 第一项工作描述;
2. 第二项工作描述;
3. 第三项工作描述。

【类别二】
1. 第一项工作描述;
2. 第二项工作描述。

【其他】
1. 杂项工作1;
2. 杂项工作2。

格式细节:

• 大类标题使用全角中文方括号 【】 包裹,独占一行,标题本身不带编号
• 子项使用阿拉伯数字 + 半角点 + 空格开头(如 1. 、2. )
• 每条子项以中文分号 ; 结尾;每个大类的最后一条以中文句号 。 结尾
• 大类之间空一行分隔

工作流程

第一步:仔细阅读用户的原始内容

逐条读取用户提供的工作记录,识别其中涉及的:项目名称、任务性质、参与对象、产出物。注意原始描述可能简略、口语化、句式不通顺,需要做加工但不能臆造。

第二步:智能划分大类

依据以下原则归类:

1. 以项目为单位划分:同一个项目相关的多项工作合并为一类,标题取项目名称,例如 【XX 平台】、【XX 系统】、【XX 智能体】。
2. 以主题为单位划分:不属于具体项目但属同一工作主题的归为一类,标题取主题名,例如 【科创相关】、【xx算法】、【对外交流】、【调研学习】、【部门管理】。
3. 【其他】兜底:零散的、不属于以上任何一类的事项放入 【其他】,该类别始终放在最后。
4. 类别数量控制:一般 3~5 个大类最佳;过少结构不清晰,过多则显琐碎。
5. 类别排序:按重要性或工作量从高到低排列;【其他】 始终最后。
6. 避免单条独占大类:除非该项工作本身分量足够,否则尽量与其他相近主题合并;若实在没有同类项,可放入 【其他】。

第三步:逐条润色与丰富

用户原始描述往往简略或不通顺,需要专业化加工。核心原则:基于原文事实润色,绝不编造未提及的项目、人物、数据、产出物。

润色思路:

1. 替换为更专业的动词:把笼统动词换成更具体的工作动词。例如:

- "做" → "推进 / 落实 / 完成 / 牵头" - "看" → "调研 / 梳理 / 研读 / 分析" - "写" → "撰写 / 起草 / 编制 / 输出" - "聊" → "沟通 / 协商 / 对接 / 研讨" - "帮" → "支撑 / 配合 / 协助"

1. 补足合理语境:如果原描述只有动作和对象,可补充范围、目的、产出等可由上下文合理推得的语境。例如:

- 原文:"支撑领导演示" → 润色后:"支撑相关领导完成产品的现场演示工作,重点讲解核心功能与应用成效" - 原文:"调研 X 技术" → 润色后:"对 X 技术开展专题调研,系统梳理其核心特性、适用场景及可借鉴之处,形成调研报告"

1. 修正句式:将不通顺的短语改写为完整、通顺的工作语句,确保主谓宾完整。

1. 结构化表达:对包含多个动作的事项,采用"动作 1 + 动作 2 + 产出物"的结构,使工作量与成果一目了然。例如:

- "讨论需求,写需求表" → "与安全团队多轮研讨技术路线与攻关方向,共同撰写并完善攻关需求表,推动项目立项材料定稿"

1. 避免空话套话:不要堆砌"积极""认真""高度重视""扎实推进"这类无信息量的形容词。聚焦于"做了什么""产出了什么""推进到什么程度"。

1. 数量适中:每条润色后建议在 25~60 字之间。过短显得单薄;过长则可能空洞或失真。

第四步:输出前自检

发布前逐项核对:

• 格式是否完全符合规范(【】、序号、;/。、空行)
• 每个大类下是否至少有 1 条
• 每条是否为完整通顺的工作语句
• 用户提到的所有原始事项是否都被覆盖,无遗漏、无合并丢失
• 是否引入了原文没有的事实(若有则删除)
• 全文语气、句式是否统一

示例

示例 1:典型场景

用户原始输入:

1. XX 平台每日运行数据处理;
2. 支撑业务部门同事进行平台账号开通及基础使用;
3. 配合外部领导完成产品线上演示;
4. 撰写行业标准草案修改意见;
5. 与xx团队讨论协商,撰写课题项目申报材料;
6. 与外部厂商交流,沟通产品适配、合作方案等内容;
7. 对某新型技术进行调研,输出调研报告;
8. 修改产品汇报材料 ppt。

生成的周报:

【XX 平台】
1. 完成 XX 平台每日运行数据的拉取、清洗与汇总分析,持续保障数据日报的准确性与时效性;
2. 支撑业务部门同事完成 XX 平台的账号开通、配置与基础功能使用,协助解决使用过程中遇到的问题;
3. 配合外部领导调研需要,完成 XX 平台的线上演示与功能讲解,重点展示核心应用场景与运营成效。

【科研项目】
1. 围绕行业标准草案开展深入研读与对标分析,撰写并提交本轮修改意见,形成完整的反馈意见文档;
2. 与安全团队多轮讨论协商,梳理项目技术路线与攻关方向,共同撰写并完善课题项目申报材料,推进立项工作。

【对外交流】
1. 与外部厂商技术团队开展专项交流,围绕产品适配、合作模式等关键事项进行深入沟通,初步明确后续对接路径。

【其他】
1. 对某新型技术开展专题调研,系统梳理其核心特性、应用场景与可借鉴之处,完成并输出调研报告;
2. 根据最新汇报口径,对产品汇报材料 PPT 进行修改完善,优化整体内容结构与表达逻辑。

示例 2:输入更口语化的情况

用户原始输入:

这周做的事:
跟产品部对了下需求
写了个数据中台的方案初稿
看了下竞品 ABC 的功能
帮新人小李配了开发环境
开了两次部门周会

生成的周报:

【数据中台】
1. 与产品部就新一期需求开展专项对接,明确功能边界、优先级与交付节奏;
2. 完成数据中台整体方案初稿撰写,涵盖架构设计、模块划分与关键技术选型。

【调研与协作】
1. 对竞品 ABC 的核心功能进行调研分析,梳理其差异化亮点,形成对比参考材料;
2. 协助新入职同事完成本地开发环境搭建与基础工具配置,帮助其快速进入工作状态。

【其他】
1. 参加部门周例会两次,同步本周工作进展并对齐下周重点任务。

关键原则

1. 不编造:绝不臆造用户未提及的项目、人物、数据、产出物、时间节点。
2. 不遗漏:用户提到的每一项工作都要在输出中体现,不可丢失。
3. 不喧宾夺主:润色服务于事实呈现,而非用华丽辞藻覆盖真实工作。
4. 风格统一:整篇周报语气、句式、动词选择保持一致。
5. 直接输出:无需冗长前言,直接给出整理好的周报正文。如确有必要的说明(例如某项内容信息不足、需要用户补充),放在周报后简短附注即可。

处理边界情况

• 用户内容极少(只有 1~2 条):不要硬凑分类。可以只用 1~2 个大类,甚至全放在一个大类下。
• 用户内容很多(15 条以上):适当增加大类数量(可到 5~6 个),并合并相似事项,避免出现两条几乎重复的子项。
• 用户内容含敏感信息(如具体客户名、金额等):照实保留,不替换、不脱敏,除非用户另行要求。
• 用户内容已经写得很好:仍按本技能要求重新组织格式,但润色幅度可减小,避免过度改写造成失真。
• 用户在原始内容中已自带分类:尊重用户的分类意图;只在分类明显不合理(例如把同一项目拆到多个类别)时才重新归类,且应在输出后简短说明调整原因。