工作总结和职业准备可以共享一份真实成果底稿，但服务于不同读者，也有不同保密边界。周报帮助团队协调，述职解释贡献与改进，求职材料说明本人能力，不能把内部记录原封不动带到外部。本篇用虚构的展览预约系统维护岗位，拆成日常汇报、年度复盘和在职职业规划三个场景，不声称已处理真实员工资料或代作去留决定。
先建立可核对的工作账本
每项记录包含日期、目标、动作、产物、当前状态、本人贡献、协作对象、证据与下一步。将已完成、已提交待验收、进行中、受阻和取消分开。开了会议、提交代码或写了方案并不自动代表功能上线，更不说明业务指标改善。记录当时事实，避免年底仅凭记忆把计划补写成成果。
把工单、提交、发布记录、支持反馈与非代码工作对应起来。Git 历史可作为线索，提交数量不是工作价值或个人绩效分数；合并、回滚、共同作者和提交时间口径都需核对。官方 git-log 支持查看与筛选提交历史，但历史不包含全部沟通、排障与维护贡献。读取范围先限定，不把私有代码、密钥或敏感项目名发到外部模型。
原始证据与汇报副本分开保管。内部版本可含获准的工单链接，外部简历只能用可披露概述。给来源编号和资料版本，缺少结果数据就标待补，不让 Agent 自动“量化亮点”。例行检查、预防性维护和交接也能有具体产物，但不能凭没有发生事故就证明避免了某个损失金额。
场景一：周报月报写给接下来要行动的人
先确认对象需要什么：项目负责人关心里程碑与依赖，团队关心交接与风险，其他角色可能关心服务或资源。结构可用目标、已验收产物、进行中、阻碍、需决定事项与下期计划。不要为了模板齐全给没有数据的 KPI 填数字，也不要把所有工单逐条复制成流水账。
把“动作—结果—影响”分开。动作是定位预约重复提交问题，结果是修复已在测试环境通过某些用例，影响只能写已观察到的变化与适用范围；如果尚未发布，就不能写客户投诉下降。对影响未知的工作，可写它支持什么后续决定和仍需验收什么，而不是用“大幅赋能”替代证据。
月报聚合周报时按项目或目标去重，不重复累加跨周工作。指标须注明窗口、分母、数据源和是否最终值；同一个问题被关闭又重开要保留状态变化。下期计划写责任人、依赖与可接受结果，风险要指出需要谁在何时做什么，不只写“加强沟通”。
如批准的工作笔记已在 Notion，Notion Research & Documentation 可在本阶段读取获准页面并综合摘要、发现、限制与来源链接。需要可用连接、明确可读材料与可写目标，保存后核对实际页面。它不扫描 Git、不确认生产发布，也不衡量个人绩效；没有连接时输出只能标草稿。
实操：把一项维护写成诚实进展
虚构记录 W-18 是“修复预约重复提交”，有提交编号、测试记录和待发布状态。周报可写“完成请求去重修改，测试环境覆盖重复点击与超时重试；生产发布待批准，下一步核对发布后记录”。这里不给不存在的投诉改善或节省成本，读者却能知道已经完成什么、还差什么。
若复核发现测试只覆盖重复点击，就删去超时重试已通过的说法，列为待测。若另一个同事完成服务端修改，自己负责复现与验收，就准确说明分工。报告不是把每个人都写成唯一负责人，而是让团队看见真实贡献与协作关系。
给 Agent 的请求可写为：“仅使用 work-log-v1 与列明的脱敏工单摘要。按已验收、待验收、进行中和受阻分类，所有成果保留来源编号。缺数据列问题，不估造指标。输出本周摘要和下周依赖，先不发送，不发布，不修改工单。”本人核对后再通过正常渠道交付。
场景二：年度述职从工作清单走向解释
先围绕职责和期初目标归类，再挑能展示判断与持续贡献的案例。大项目、重复维护、跨团队协调和能力建设可以分别说明，不能只因为维护没有轰动成果就夸成战略转型。每个案例写背景、本人责任、关键动作、可证实结果、限制与反思，团队目标未达成也要真实记录。
对“整理台账、核对数据”这类工作，展示流程、发现的问题、交付的检查规则与后续采用情况。若有前后对比，明确基线、口径与其他变化；没有对照就不宣称完全由自己造成提升。数量要能从账本复算，避免年度总结把月度累计再加一遍。
复盘不是只列亮点。分清假设错误、执行受阻、资源依赖与外部变化，写下一次怎样发现得更早。GitHub 的 MADR 用于架构决策记录，包含背景、备选、结果、后果与确认方式，可参考其结构整理一个技术取舍案例。它是可版本化记录格式，不是绩效评价工具，也不把采用格式当作决策已正确。
述职材料可以按总结、亮点、问题风险和下一阶段计划组织，但内容不足的栏目留缺口，不由模型补齐。展示稿与详细证据附件分开，重要数据和关键限制不能只藏在备注。请同事根据材料复述本人贡献、结果范围和下一步，如果出现明显误解，先修叙事与证据，而不是增加形容词。
场景三：把在职职业准备变成个人项目
先写想改变什么与不可妥协条件：职责、成长、管理方式、地点、时间安排、家庭约束或收入稳定性。当前不满意与新机会是否更合适是两件事，不能用一次糟糕会议替代全面比较。准备、申请、面试和决定分阶段管理，保留正常履职与保密义务，不建议伪造请假理由、滥用公司设备或带走内部资料。
先从个人可拥有、可披露的成果摘要准备基础简历，内部记录只能按允许方式概述。申请与面试日程使用获准的个人资源，不把工作联系人和客户名单作为求职素材。对每个机会记录信息来源、职责、已确认条件、未知项与下一步，不自动投递或联络。职业规划是支持本人决定，不替任何人选择录用或离职。
涉及合同、保密、竞业、通知程序或保障连续性的事项，先收集本人实际文件、地区和时间，列需专业核实的问题，不让通用 Skill 判断条款一定有效、无效或保证保障不中断。不同情形规则变化很大，本篇不提供具体法律结论或缴费安排。只把缺信息与需要确认的动作记录下来，必要时向适当专业渠道核实。
Offer 比较表区分已书面确认与口头描述、固定与条件性部分、职责边界、地点时间、起始安排和未知风险。个人给权重，也测试权重变化会不会改变排序；一个高总分不保证实际适合，无法比较的条件不要硬填零。没有正式可依赖条件时，表格不能替你决定辞职时机，也不能把薪酬估计写成确定到手金额。
离职沟通与交接是独立动作
可以先起草给本人审阅的沟通提纲，说明决定、希望讨论的安排与交接范围，不承诺尚未确认的最后工作日或新雇主义务。起草并不授权发送辞职邮件。被挽留时回看原先原因、书面条件与信任预期，列需要澄清的问题，不让模型替本人即时接受或拒绝。
交接清单列项目状态、责任人、资料位置、已知风险和未完成事项，权限转移通过组织正常流程，不能交出个人密码或擅自扩大访问。保留公司材料在批准位置，不为方便求职复制到私人云。完成交接与实际离职状态分别核对，沟通要真实，不生成虚构口头承诺记录。
验收、技能选择与 FAQ
交付周报前核对日期、状态、数据和收件范围；述职前核对个人与团队贡献；求职前再过外部披露边界。文件、页面、已发送消息和实际结果是不同状态，工具只能声明有证据完成的部分。每次修改保留版本与原因，定期补齐工作账本，比临时从零包装更稳。
本篇只将已核验 Notion 综合技能关联到批准笔记汇报步骤，不为原文周报、述职和跳槽名称猜造 SkillPI 链接。后续候选要检查固定来源、许可、是否扫描私有仓库、会写哪些文件、是否联网或发送消息，再用脱敏小样本核对输出。安装与自动调用不等于结果通过，目录增加后按具体用途刷新关联。
没有大项目怎么写？如实展示维护产物、协作与问题处理，不虚构战略影响。Git 能写完周报吗？它只是材料之一，要补非代码工作与发布验收。是否十分钟就能交？取决于素材与核对范围，不作普遍时长承诺。写了离职稿就一定要走吗？不是，草稿、本人决定和实际发送分别管理。比较表能替代个人判断吗？不能，它帮助显露条件与未知，最终仍由本人结合真实情况决定。