成长 人人都是产品经理 · AI Second · 6小时前 · AI 生成
用 AI 干掉一个真实业务痛点：从 Excel 排期到自动试算工具 文章记录了一位游戏研发 PM 如何利用 AI 工具（CodeBuddy）将排期准备中的重复劳动（Excel 手动排期、甘特图生成、节假日计算等）转化为规则、再到自动化工具的全过程。作者强调：规则明确、输入输出清晰、验证简单的场景最适合 AI 改造；PM 的关键能力是精准定义边界、拒绝功能蔓延。适合正在探索 AI 工具落地或面临排期效率问题的产品经理/项目经理阅读。
核心观点
▍ 排期准备中最磨人的不是最终结果，而是在 Excel 中重复手动试排、调整甘特图的过程，且这一过程规则明确、可被 AI 自动化取代。 ▍ PM 使用 AI 工具的关键不在于写 prompt，而在于清晰地定义问题的边界：规则拆解、核心功能取舍、结果验证——否则 AI 会做出越来越臃肿的东西。 01 作者拆解排期流程为三部分：有标校（排期基准、甘特图规则）→ 按标校试排（耗时长、易出错） → 需要甘特图和表格输出。 02 使用 CodeBuddy 识别标校截图后，AI 自动梳理出流程环节、关键规则（工期、特殊要求）并补充提问，一次会话输出初版原型。 03 之前每次需求试排需 30-40 分钟；工具原型完成后，2 分钟可完成两遍排期操作，效率提升约 20 倍。 04 工具定位为个人计算器：数据存本地，不做账号登录、多人协作，仅小范围迭代使用，避免过度复杂化。 05 顺排、倒排、节假日、单双休等组合计算均通过结果验证，与 Excel 历史排期结果一致。 06 作者尝试过流程图手动拖动建立依赖关系，但因页面空间与操作手感问题最终回滚旧版。 反方 / 局限
— 甘特图导出 Excel 时格子为二色占位符而非填充颜色，需搜索后手动修改，增加了回退到 Excel 操作的风险。 — 风险识别（如压缩验收时间导致的质量风险）高度依赖业务经验，规则不明确，当前工具无法覆盖；TAPD 同步涉及系统对接，复杂度高暂时不做。 — 流程图建立依赖关系的交互优化尝试了多版均不理想，最终放弃，可能影响复杂依赖关系的可操作性。
11 分钟 · 5 卡片 · 10 资料
读原文 →
概念锚点 CodeBuddy 的 Craft 模式
作者用 CodeBuddy 的核心是它的 Craft 智能体——不同于 ChatGPT 的对话式问答，Craft 能读取截图里的表格结构、识别节假日规则、自动计算工期并生成甘特图 HTML 代码。它本质上是把 PM 手动在 Excel 里「拖-算-对-调」的四步操作，翻译成了「解析输入规则→执行算法→渲染输出」的一条工程链。腾讯内部数据显示，Craft 模式在处理「多文件、多依赖」的工程任务时，编码时间平均缩短 40% 以上，AI 生成代码占比超四成。
▸ 2 条关联资料
▼
前置背景 游戏行业的「标校」从哪来
作者反复提到「标校」——这是游戏研发圈特有的排期基准，沉淀了历史项目里每个环节(策划→原画→模型→程序→测试)的标准工期和依赖关系。它不是随便拍脑袋定的，一般由主策和主程拿过去 3-5 个相似规模需求的真实耗时做中位数测算，再预留 15%-20% 的缓冲应对版本迭代和提测 bug。大型工作室每年会做两次复盘调整标校，小团队则靠 PM 手工维护。理解标校生成的「经验+数据」混合逻辑，才能看懂为什么排期工具适合用 AI 做——因为规则是已经收敛的已知量，不是还在迭代中的开放问题。
▸ 2 条关联资料
▼
平行视角 CodeBuddy 并非唯一的路径
作者选 CodeBuddy 是因为它理解截图能力强、快速跑通原型。但多数 PM 面临两种替代方案:一是 Cursor/Claude Code 的 Agent 模式，能自动拆任务、生成工程结构，适合从零搭建小工具；二是 Trae/通义灵码 IDE，集成 Figma 设计转代码和可视化调优，更适合需要对接 UI 和后台的中重度原型。三种工具在「规则读取准确度」「多文件工程能力」「交互调试方便性」上各有侧重，选型取决于 PM 自己对代码质量的掌控——CodeBuddy 更像一对一笔译，Cursor 更像全栈学徒，Trae 则像低代码画板与 IDE 的混合体。
▸ 2 条关联资料
▼
未来推演 AI排期工具的下一个边界在哪
作者明确把「风险识别」和「TAPD 同步」放在待办外，理由是前者依赖业务经验后者涉及系统对接。但 2026 年已有产品能做部分自动化——禅道和飞书项目通过 API 和低代码规则引擎，允许 PM 配置风险触发条件(如测试周期压缩超 20% 自动标记高风险)。真正的拐点不在工具能不能做，而在「风险规则能否像排期规则一样被显式表达」。当下能观察到的信号:钉钉宜搭和飞书多维表格已开放甘特图 AI 插件市场，一批独立开发者正把类似排期计算器做成轻量 SaaS。接下来 1-2 年，工具会从「算结果」进化到「推方案」——但完全替代 PM 的人工判断还需要更长的时间。
▸ 2 条关联资料
▼
延伸追问 PM 的边界感从哪来
文章强调「精准定义边界、拒绝功能蔓延」是 AI 工具落地的关键，但没展开说这对 PM 意味着什么。功能蔓延的根因不是开发者贪多，而是 PM 没想清楚「哪个场景最痛、哪个不做好像也行」。真正值得追问的不是「怎么拒绝需求」，而是「凭什么判断这个功能该砍」——这依赖对业务规则透明度的深入理解:排期计算能拆是因为规则明确，但风险识别要凭经验，边界就划在这里。如果未来 AI 能逐步学会「经验型规则」，PM 的决策护城河会移到哪一层？
▸ 2 条关联资料
▼