本文提供一份完整填写的项目周会会议记录示例，逐项说明基本信息、讨论要点、决议、行动项和待决问题的写法依据，并总结可迁移到评审会、复盘会的调整规律。示例为虚构情景，用于演示字段填写方法，不代表真实客户案例或实际成效。
要点总览（TL;DR）
- 一份可用的会议记录应包含会议基本信息、议题与讨论要点、决议、行动项和待决问题五类内容，示例中的行动项还带有负责人、截止时间、验收标准和状态。
- 行动项写成可验收的动宾结构，负责人写到具体角色或姓名，截止时间写到日期与时间点，能减少会后“谁做什么、做到什么程度”的反复确认。
- 决议与讨论要点分开记录，待决问题标注决策人与期限，记录才能同时支撑回溯讨论和跟进行动。
- 迁移到评审会时侧重评审结论与遗留问题，迁移到复盘会时侧重原因分析与改进项，通用字段保留、专项字段按会议目的增减。
- 示例为虚构情景，涉密会议、合规留档会议和跨组织会议需另行确认记录范围、权限与对外口径；记录本身需进入跟进机制才能闭环。
示例目标：这份会议记录要解决什么问题
这份示例假设一个六人产品研发小组召开项目周会，参会角色包括项目经理（主持）、产品负责人、前端负责人、后端负责人、测试负责人和设计负责人，其中后端负责人因出差缺席。会议时长设定为一小时，讨论一个版本迭代的进度、风险与下周安排。情景为虚构，角色与议题均为演示服务。
记录要支撑三件事。第一是回溯讨论：会后有人问“当时为什么决定延后这个功能”，记录能还原讨论中的依据和分歧，而不只是结论。第二是确认决议：会上达成的结论以条目形式固定下来，避免不同参会者对同一结论有不同理解。第三是跟进行动项：每项待办有负责人、截止时间和验收标准，会后可以直接进入跟进流程，不需要再开一次会确认谁做什么。
这三个目标决定了记录的详略取舍。讨论要点记录到能支撑决议的程度即可，不必逐字还原发言；决议和行动项则要写到可以独立阅读、不依赖会议现场语境的程度。读者在参照本示例时，应先确认自己的会议是否同样以“形成决议并分配行动”为主要目的，再决定字段的增减。
完整示例：一次项目周会的会议记录全文
以下为示例会议记录的完整填写结果，各字段前后自洽，可直接作为填写参照。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | 订单模块 2.3 版本迭代周会 |
| 会议时间 | 2025年3月11日（周二）10:00–11:00 |
| 会议地点 | 线上会议 |
| 主持人 | 项目经理 林某 |
| 参会人 | 产品负责人 周某、前端负责人 吴某、测试负责人 郑某、设计负责人 何某 |
| 缺席人 | 后端负责人 陈某（出差，会后由项目经理同步记录） |
| 记录人 | 项目经理 林某 |
议题与讨论要点
议题一：订单列表页改版进度。前端已完成列表页主体开发，筛选条件区域尚在联调。设计负责人提出筛选条件的交互与原设计稿有出入，前端说明是为适配移动端做了折叠处理。讨论后认为折叠方案可用，但需补充一版交互说明供测试对照。
议题二：批量导出功能的排期。产品负责人希望本版本上线批量导出，后端评估当前排期无法在版本截止日前完成接口开发。讨论中出现分歧：一方主张缩减导出字段范围以赶上版本，另一方主张整体顺延到下一版本。最终倾向于顺延，但需产品负责人与业务方确认后再定。
议题三：测试环境稳定性。测试负责人反馈近一周测试环境出现两次中断，影响回归进度。后端缺席，会上未能定位原因，记为待决问题。
决议
- 订单列表页筛选条件采用移动端折叠方案，设计负责人于3月12日前补充交互说明文档，测试按该文档编写用例。
- 批量导出功能整体顺延至 2.4 版本，由产品负责人于3月13日前与业务方沟通确认，确认结果同步至项目群。
- 本周五的例行进度同步会取消，改为在项目文档中更新进度，由各负责人于3月14日18:00前完成更新。
行动项
| 序号 | 行动项 | 负责人 | 截止时间 | 验收标准 | 状态 |
|---|---|---|---|---|---|
| 1 | 补充筛选条件移动端交互说明文档 | 设计负责人 何某 | 3月12日 18:00 | 文档含折叠与展开两种状态的交互描述，测试负责人确认可据此编写用例 | 进行中 |
| 2 | 与业务方沟通批量导出顺延方案并反馈结果 | 产品负责人 周某 | 3月13日 18:00 | 业务方书面或群内确认顺延，结论记录在本记录待决问题下方 | 未开始 |
| 3 | 排查测试环境两次中断的原因 | 后端负责人 陈某 | 3月13日 12:00 | 给出中断原因说明及至少一项预防措施 | 未开始 |
| 4 | 更新本周进度至项目文档 | 各模块负责人 | 3月14日 18:00 | 文档中进度状态与实际开发状态一致 | 未开始 |
待决问题与下次会议
- 待决问题：批量导出顺延是否影响已承诺的业务方交付时间，决策人为产品负责人，期限为3月13日。
- 待决问题：测试环境中断原因待后端负责人排查后确认，决策人为项目经理，期限为3月13日。
- 下次会议：3月18日（周二）10:00，同一线上会议室，议程为 2.3 版本发布前检查。
逐项解释：每个字段为什么这样写
示例中的字段并非越多越好，每个字段的存在都对应一个会后会被追问的问题。下面按字段说明写法依据，并给出模糊与清晰写法的对照。
行动项写成可验收的动宾结构
行动项以动词开头、以可检查的产物结尾，读者不看会议现场也能判断是否完成。“补充筛选条件移动端交互说明文档”明确了动作和产物；“跟进一下设计问题”则无法判断做到什么程度算完成。验收标准进一步把“完成”具体化，例如写明文档需覆盖哪两种状态、需谁确认。
负责人写具体角色或姓名
写“设计部”“后端组”这类部门名称，会后容易出现多人以为对方在做的情况。示例中统一写“角色 + 姓名”，既方便识别，也便于在人员变动时追溯。若团队习惯只写姓名，应保证姓名在团队内唯一可识别。
截止时间写到日期与时间点
“本周内”“尽快”在跨人协作中含义不稳定。示例统一写到“3月12日 18:00”这样的日期加时间点，与团队的工作节奏对齐。对于依赖他人输入的行动项，截止时间应留出交接余量，例如沟通类事项安排在确认方有空的时间之前。
决议与讨论要点分开记录
讨论要点保留分歧和依据，决议只写最终确定的事项。两者混在一起，会后回溯时难以区分“讨论过的想法”和“已经定下的事”。示例中议题二的顺延在讨论部分记录了两种意见，在决议部分只写最终倾向和确认动作，读者能看清结论是如何形成的。
待决问题标注决策人与期限
待决问题如果没有决策人和期限，会长期停留在“待定”状态。示例中每条待决问题都写明由谁决策、何时给出结论，并在下次会议安排中留出复查位置。这样待决问题与行动项形成互补：行动项是已确定要做的事，待决问题是尚未确定、需要有人拍板的事。
| 字段 | 模糊写法 | 清晰写法 |
|---|---|---|
| 行动项 | 跟进导出功能 | 与业务方沟通批量导出顺延方案并反馈结果 |
| 负责人 | 后端组 | 后端负责人 陈某 |
| 截止时间 | 本周内 | 3月13日 18:00 |
| 决议 | 讨论了导出排期，大家觉得可以延后 | 批量导出功能整体顺延至 2.4 版本，由产品负责人确认后同步 |
| 待决问题 | 测试环境问题待查 | 测试环境中断原因待排查，决策人项目经理，期限3月13日 |
可迁移规律：换到评审会、复盘会怎么填
示例中的字段可以分成两类：一类是几乎所有工作会议都需要的通用字段，包括会议基本信息、议题、决议、行动项和待决问题；另一类随会议类型增减。迁移时先保留通用字段，再按会议目的补充专项字段。
评审会侧重结论与遗留问题
评审会的核心产出是“通过、有条件通过或不通过”的明确结论，以及未解决的问题清单。填写时在决议部分写清评审对象、评审结论和通过条件；行动项围绕修改意见展开，每条意见对应负责人和复查时间；遗留问题单独列出，注明是否阻塞下一阶段。讨论过程可以简写，评审依据（如对照的规范或需求文档版本）要写清楚。
复盘会侧重原因与改进项
复盘会的记录重点从“做了什么决定”转向“为什么发生、下次怎么改”。可在通用字段外增加事实时间线、原因分析和改进项三块。原因分析区分直接原因与流程原因，改进项写成可执行的行动项，并注明验证方式，例如“在下个迭代的发布检查中验证”。复盘会容易产生大量感受性描述，记录时应把可验证的事实与主观判断分开。
行动项从记录到跟进的状态流转
会议记录写完只是起点，行动项需要进入跟进机制才能闭环。示例中的状态列从“未开始”到“进行中”再到“已完成”，每次状态变化应有依据，例如验收标准被确认满足。团队可以把行动项录入任务管理工具，与会议记录文档相互关联，让记录中的结论和工具中的任务保持同一份事实。ONES Wiki 支持文档关联项目任务，文档中可嵌入任务进度，会议记录沉淀在页面树中便于按项目归档；使用模板库可以按会议类型创建结构一致的记录文档，减少每次从零搭建字段的工作。对于需要多人协作维护的记录，还可以按角色配置读写权限并保留页面版本，便于回溯修改。
迁移时的调整清单可以这样用：先确认会议目的属于“形成决议”“形成评审结论”还是“形成改进项”，据此决定专项字段；再检查每条行动项是否具备负责人、截止时间和验收标准三要素；最后确认待决问题都有决策人和期限。三项检查通过，记录基本可以支撑会后跟进。
适用边界：示例不能直接照搬的情况
本示例为演示用途，会议主题、人员、时间和进度均为虚构，不包含真实数据，也不代表任何团队采用后的量化效果。照搬前需要确认以下几类情况。
涉密会议与合规留档会议有额外要求。这类会议通常对记录范围、存储位置、访问权限和保存期限有明确规定，部分内容可能不允许写入普通协作文档。示例中的字段结构可以参考，但权限配置、留存方式和脱敏处理需按组织制度另行确认。
跨组织会议的记录口径存在差异。与外部合作方共同召开的会议，各方对“决议是否生效”“行动项是否对外承诺”的理解可能不同，记录中应明确哪些内容经各方确认、哪些仅为单方内部记录，避免会后对外引用时产生歧义。
记录本身不等于任务管理。示例中的行动项表格适合承载会议产出，但状态更新、逾期提醒和跨会议汇总需要进入团队的跟进机制，例如任务管理工具或固定的周度检查。若团队没有跟进机制，再完整的记录也会停留在文档里。行动项字段如何与工具中的任务字段对应，需结合团队实际工具链确定，本文不作为统一要求。
此外，示例假设会议有明确主持人和记录人。在站立会、临时讨论等轻量场景中，可以只保留决议和行动项，省略部分基本信息字段；在决策链条较长的会议中，则可能需要补充决策依据和审批记录。字段的增减应以“会后能否独立读懂并执行”为判断标准。
常见问题
会议记录里的行动项和待决问题有什么区别，需要分开写吗？
建议分开写。行动项是会上已经确定要做的事，具备负责人、截止时间和验收标准，会后直接进入执行；待决问题是尚未形成结论、需要有人拍板的事，应标注决策人和给出结论的期限。两者混在一起，跟进时容易把“还没定的事”当成“已经在做的事”。示例中批量导出是否顺延属于待决问题，与业务方沟通确认则是围绕它产生的行动项。
会议没有专职记录人时，怎么保证记录质量？
可以由主持人兼任记录人，但要在会前明确记录范围：讨论要点记到能支撑决议即可，决议和行动项写到可独立阅读的程度。会后把记录发到参会人处做一次简短确认，重点核对行动项的负责人、截止时间和验收标准。若会议节奏快、议题多，也可以安排轮值记录，并沿用同一份字段结构，减少每次重新约定格式的成本。
行动项录入任务管理工具后，会议记录还需要维护吗？
需要，但维护重点不同。会议记录保留讨论依据、决议原文和待决问题的来龙去脉，任务工具承载状态更新、逾期提醒和跨会议汇总。两者可以通过关联保持同一份事实，例如在记录中标注对应任务，任务完成后回写结论。ONES Wiki 支持文档关联项目任务，文档中可嵌入任务进度，会议记录按项目归档在页面树中，便于回溯时同时看到当时的讨论和后续执行情况。
站立会、临时讨论这类短会也要按完整字段填写吗？
可以精简。短会通常只需保留决议和行动项，会议基本信息写到主题、日期和参会人即可，讨论要点可以省略或只记一句背景。判断标准是会后能否独立读懂并执行：如果行动项本身已经写清负责人、截止时间和验收标准，省略讨论过程不影响执行。反之，涉及多方协调或决策依据较多的短会，仍应补上关键分歧和待决问题。
跨部门或与外部合作方开会，记录口径要注意什么？
要区分各方共同确认的内容和单方内部记录。会上达成的结论应写明经哪些方确认，行动项是否构成对外承诺要单独标注；内部讨论中的保留意见和备选方案，若不适宜对外披露，应放在内部记录中并控制访问范围。会后对外引用前，建议由各方对接人核对一遍表述，避免同一份记录在不同组织中被理解成不同承诺。
