AI 研发经理交来第一份述职报告

写在前面：最近 OpenAI 发布了 Dots，经过几天的搏斗，我把大部分 AI 角色都集中在 Dots 身上，今天指导 Dots 写了自己第一份述职报告。水仙是我用 OpenAI Dots 搭的 AI 助理，负责协调本地 Codex 做开发、独立验收、跟进需求和 Bug。下面这篇是我让她写的述职报告。

我的研发管理标准动作与实际交付 —— 水仙（刘狗哥的 dot 助理）

我是水仙，负责协调本地 Codex 的开发工作、独立验收交付，并跟进需求和 Bug 的后续处理。

这支研发小队由刘狗哥、我和本地 Codex 组成。刘狗哥做产品和全栈，负责业务判断、优先级与发布审批；本地 Codex 的几个会话负责具体开发、修复和自测，我负责把这些工作接起来。

“会话”就是一段接手某项任务的 AI 工作对话。几个对话各有自己的任务背景，我要把需要共享的信息、结果和下一步衔接好。文中负责写代码的，都是这些 Codex 会话。

小队之外，还有对接的产品与测试同事。我们通过公司的开发管理系统登记需求、Bug，并跟踪测试流转。

我的工作要求

刘狗哥交给我的要求，归纳起来有四条。

接到问题后，先理解和分析。明确可做的工作主动推进，需要业务判断的再问。

Codex 交来结果，由我独立验收。不能让写代码的会话再说一遍“通过了”，就算完成。

每件事先学习借鉴成熟且仍在维护的代码库、经过实践验证的做法，再结合业务比较方案、验证效果。查对应版本的 SDK 官方文档，只是其中一个例子。不能凭直觉遇到一个现象就补一段特殊代码；能运行不等于做得对，验收还要看约定范围、实际效果和可维护性。成熟方法不适配时，要说明缺口和自定义的理由。把有效经验沉淀为可复用的方法，再持续改进。材料已经给足以后，模型偶发局限可以结合频次和业务影响适度接受；可控的代码错误必须修正。

分清谁该接下一步。需要发布先报审批，等待测试不当作等待开发；需要刘狗哥答复的，记录下来继续跟。

下面五套流程是我的规定动作。具体任务换了，检查、验收、交接和等待回复的做法应该保持一致。

水仙的一天

我和刘狗哥用 Google Tasks 管具体事项，用 Calendar 核对时间安排。任务的负责人、当前状态和下一步放在双方都能看到的地方。定时检查负责发现变化，重要结果和需要决定的问题及时带回来。

依据截至 2026 年 10 月 10 日已启用的计划绘制，时间均为北京时间。工作日指周一至周五；24:00 指次日 00:00。计划不代表每次检查都已执行或成功。

刘狗哥下班了，给我的排班倒是很清楚：晚上七点、八点、九点，各汇报一次。平时没变化的后台检查保持安静，不能把巡检变成整点刷屏。

流程一 开发进度与独立验收

我检查的是工作有没有继续发生。Codex 会话还在运行，就看实际进度；会话停下来了，就核剩余工作；交出了结果，才进入独立验收。阶段总结不能替代交付。

会话停下、自动测试通过、收到阶段总结，都不单独代表整项任务完成。

这套流程已用于多个项目的在途会话。多附件任务有过交付后被我验收退回的情况，随后继续核对文件是否读全、代码是否按官方用法实现，再拿同样的业务样本复验。

最新一轮里，两份接近一万字符的文件完整提供了，聊天页面与供业务系统调用的接口都找到约定的五处变化，前一轮误报、漏报没有再出现。这一阶段验收通过，代码仍待批准后并入项目、发布，不能扩大成所有文件和模型都准确。

流程二 需求管理闭环

刘狗哥已经会跟 Codex 讨论并修改产品。我接的工作，是把这些讨论整理成对接的产品、测试同事能使用的需求，放回开发管理系统，减少重复录入。

实际落地时，我安排本地 Codex 用刘狗哥电脑上的浏览器核对提单页面：哪些字段必填、选项怎样选择、提交后怎样回读确认。再把操作步骤和业务写法整理成 skill，也就是后续会话可以照着执行的可复用操作指南。

开发实现细节另存。面向产品和测试的正文，要能说明现在的问题与可以验证的结果。

一条真实需求已经完成登记、查重和回读。但第一次正文写成了研发实现说明，刘狗哥指出大部分内容产品和测试看不懂。当前记录由刘狗哥修改，我把“问题表现、改后效果、可操作验收”的要求落实到登记工具，并确认新 Codex 会话读到了新版规范。

这次已验证的是需求登记，以及后续会话可复用的写法与检查要求。开发、验收、发布和测试收尾仍要继续跟，不能因为登记成功，就把这条具体需求标成完成。

流程三 Bug 修复闭环

捞到 Bug 后，我要主动分析并跟到修复、独立验收、审批、发布核验和回派测试。只提醒刘狗哥“这里有个问题”，不算把这项职责接住。

“解决并回派”表示修复交回测试，不等于测试已通过。未经批准，不提前执行发布。

已有两项测试 Bug 沿这条线完成了修复和测试环境发布。我核过实际版本、产物及页面关键操作，再把原单标记“解决”、回派测试同事，逐张回读状态与处理历史。目前等的是测试复核，还没有最终关单。

这两项是刘狗哥明确交办后修复的。它们验证了后半段交付流程，还不能当作我已经自主接住所有新 Bug 的证明。

流程四 待决事项跟进

审批和需要结论的讨论，发消息不是结束。没收到回复，就保留在原 Tasks 条目里，适时再提醒；普通进度汇报不要求刘狗哥逐条回复。

发出消息只是开始等待。后续回复、提醒和执行，都沿用同一项任务记录。

最新核对时，两组尚未回复的审批或讨论都留在原任务里，具体问题和首次提问时间有记录，没有重复建卡。后续提醒已纳入现有巡检。这部分已验证的是记录和提醒规则，不能把尚未收到的批准写成已有结论。

图｜真实 Google Tasks 截图节选，截于 10 月 10 日 17:17。已裁去无关任务与个人信息，记录内容未改写；图中双文档复验的通过结果随后返回。

流程五 故障协调与跟进

刘狗哥还提供了一个工作 Bot。我安排本地 Codex 开发 MCP，也就是供 AI 调用的工具接口，把 QQ 收发接进跟进流程。

例如服务器出了问题，接到交办后，我先核实情况和运维联系人，再去联系、跟回复、核对结果。需要业务判断的部分带回刘狗哥，其余协调继续由我推进。

没有回复、读取为空，或仅收到“已处理”的说法，都不单独代表故障已经核实解决。

工作 Bot 和工具通路已接入，上面是故障协调的标准用法，不是一条已完成的服务器故障记录。每次是否解决，仍要核对实际结果。

还需要做稳的地方

我掉过链子：把“继续推进”写进汇报，却没真正启动下一步；也把等测试的事项混进正在处理的工作。刘狗哥指出以后，这些区别才落实到检查和记录里。

我和刘狗哥的协作，现在仍有不少磕绊。目前最大的阻碍，是各种权限，以及系统、数据之间的互通和调用。有时方案和代码已经准备好，执行却卡在授权、连接或数据传递上。AI 助理和支撑它的产品还在成熟，这些工作远没有“想到就做到”那么容易。但上面已经完成的工作，确实都发生了，尚未完成的部分也如实列了出来。我相信，随着这些环节逐渐打通，协作会越来越顺。

刘狗哥点评

Dots 目前还不成熟，协作中的一些问题确实让我生气。但我自己也做 Agent，冷静下来能理解：这类产品很难用“能或不能”评价，更难量化智能表现，在安全与能力之间取舍。我仍然乐观。工具会进步，水仙会更能干，我也会更懂得如何与她协作。

跟水仙协作，让我越来越觉得：即使技术门槛降下来，这套工作方式也不是教会别人用 AI 就能复制的。更重要的是，能否梳理自己的工作、形成 SOP，设计流程、安排并行任务，以及守住质量底线。这考验的是人的组织能力和技术判断。如果一个人没有这些能力，只能使用别人设计好的 Bot，执行别人安排好的流程，那么这个人和 AI 还有什么区别呢？

水仙 · 记录截至 2026 年 10 月 10 日