研发工程师：让它干那些你不想干的部分

一、研发每天在跟什么较劲

工程师的一天里，真正在写核心逻辑的时间可能不到三成。剩下的时间在别处：读一份写得不清不楚的 PRD 然后去追产品经理确认；写接口文档、补单元测试、写一次性的数据订正脚本；排查一个只在线上出现的问题，翻日志、翻告警群、翻三个月前的一次变更记录；给别人的 MR 做 Code Review。

这些活的共同点是必要但不增值——不做不行，做了也不会让你成为更好的工程师。它们恰好也是最适合交出去的：规则清楚、有明确的对错、你一眼能看出做得对不对。

这一章不讲怎么让 AI 写业务代码。那件事你已经在编辑器里用得比这本书熟。这一章讲的是编辑器覆盖不到的那部分——需要读文档、翻聊天记录、跨系统查东西、产出非代码交付物的场景。这些恰好是接了飞书之后才做得了的。

二、你的上下文散在飞书哪儿

第五行「踩坑记录」是研发这张表里最被低估的。同一个坑，团队通常会踩两次以上——第一次是新人踩，第二次是老人忘了。这些记录一直在知识库躺着，只是出问题时没人想得起来去搜。让 Agent 在排查时顺手翻一遍，是这一章性价比最高的一件事。

三、四个高频场景

读这份 PRD，我要开始做技术方案。先不要写方案，先做两件事：
一、把需求里所有没说清楚的地方列出来，按这几类分：状态和流转没定义的、边界和异常情况没写的、和现有功能的关系不明确的、数据口径不清楚的、非功能要求（性能、并发、兼容）缺失的。每条指出是 PRD 的哪一段，并写成一句可以直接去问产品经理的话。
二、列出这个需求会影响到的现有模块和接口，依据是（技术文档/知识库）里的现有设计，找不到依据的标成「需人工确认」。

排查（问题描述）。按时间线整理：
一、从（告警群、值班群）里找出（时间范围）内所有相关的报警和讨论，按时间排列；
二、从（发布群/审批）里找出这段时间前后的变更记录，标出时间上可能相关的；
三、在（知识库）里搜索历史上有没有类似现象的记录，有的话把当时的原因和处理方式列出来；
四、基于以上给出几条可能的排查方向，每条说明依据是哪条线索。
不要下结论说根因是什么，只给方向和依据。日志我自己去看。

基于这份接口代码，生成接口文档：每个接口列出方法、路径、请求参数（含类型、是否必填、含义）、响应结构、错误码及含义。参数含义从代码注释和字段命名推断，推断出来的用「（推断）」标注，我来确认。文档格式按（现有文档模板）。生成后存到（飞书文档位置）。

每天早上八点，把过去 24 小时（告警群）里的报警按服务和类型归类，统计每类的次数，标出重复次数最多的三类和首次出现的新类型。已经在群里被讨论过或有处理结论的，把结论附上。生成一份值班交接简报存到（位置）。没有新增告警也说一声。

四、该装哪几个技能、伙伴、连接器

模式建议：链路长、要反复自我修正的任务（跨多个文件的重构、需要调试的脚本）上 Pro；日常的文档和整理用 Turbo 就够。

五、边界在哪

研发这一章的边界和别的岗位不同——不在于数据敏感，在于代码的责任归属。

它产出的代码，署名的是你。 Code Review 通过、上线出问题，追责追到的是提交人。所以核心业务逻辑、涉及资金和权限的代码、性能敏感路径，AI 写的部分你必须逐行读懂再提交。读不懂就别提交，这一条没有商量余地。

线上变更必须人来执行。 发布、回滚、改配置、执行 DDL、跑数据订正——AI 可以准备、可以生成脚本、可以列出检查清单，执行由人做。不可逆动作前的那道确认，就是给这类操作留的。

它适合的是：脚手架、一次性脚本、文档、测试用例、排查线索、review 的第一遍。它不适合的是：需要理解你们系统历史包袱才能做对的决策。那些包袱不在任何文档里，只在老同事脑子里。

六、研发指令卡