第 12 章 三类角色的高频实战脚本
针对程序员、产品经理与事务型办公人员三类角色，提供 AI 工具的高频实战脚本、最佳实践、典型工作流指南和可直接复用的执行模板。
同一个工具，不同角色的最佳切入点不同。培训应围绕真实输入、真实产物与真实验收，而不是所有人看同一场功能演示。
12.1 程序员路径：从“写代码”升级到“管闭环”
| 任务 | 推荐入口 | 输入 | 交付 |
|---|---|---|---|
| 理解代码库 | Codex / Claude Code 只读 Plan | 仓库、关注模块、规则 | 架构、入口、数据流、命令、风险 |
| 修 Bug | CLI / IDE；必要时 Browser | 复现、错误、日志、最近改动 | 原因、最小修复、测试、回滚 |
| 加功能 | Spec + worktree | 目标、非目标、验收、参考模式 | 计划、代码、测试、PR 描述 |
| 重构 | 长目标 + 分里程碑 | 痛点、不变量、性能/兼容要求 | 迁移路径、小 Diff、回归证据 |
| 代码审查 | 独立 reviewer Agent | Diff、Spec、关注点 | 严重度、证据、修复和回归 |
| 批量维护 | Cloud / Scheduled / Routine | 任务列表、范围、预算、停止条件 | 独立 PR、运行日志、失败队列 |
程序员高频提示
-
“先只读分析订单导出链路，从入口到文件下载列出真实文件和调用关系。”
-
“先复现这个 Bug，不要猜原因；每个假设写明如何证伪。”
-
“基于 SPEC.md 实现；不新增依赖；每个里程碑都运行对应验证。”
-
“读取当前 Diff，优先审查权限、错误处理、并发、数据一致性和测试缺口。”
-
“把这次踩坑转成一条最小规则、一个测试或一个 Hook，避免重复。”
12.2 产品经理路径：从模糊想法到可交付规格
| 任务 | 推荐入口 | 起手动作 | 交付 |
|---|---|---|---|
| 需求澄清 | Chat / Work + spec Skill | 先采访，区分事实/假设/待决策 | 需求 Brief、Spec、验收 |
| 竞品研究 | Work + Browser | 限定时间、用户、证据与决策 | 证据表、矩阵、机会与反证 |
| MVP 原型 | Work 形成 Spec；Codex/Claude 实现 | 给参考、流程、风格、数据与非目标 | 可运行原型、走查证据 |
| 评审准备 | Chat / Work | 先写必须做出的决策 | 议程、备选、权衡、建议 |
| 发布验收 | Browser / Computer Use + checklist | 围绕核心场景和异常路径 | 验收报告、问题优先级 |
| 复盘 | Work | 收集指标、反馈、事故与销售异议 | 事实、原因、行动、下版优先级 |
产品经理高频提示
-
“先采访我，把这个想法变成可执行 Spec；先不要给解决方案。”
-
“列出 5 个必须澄清的问题、5 个最大风险和 3 个可能不值得做的理由。”
-
“研究最近 12 个月的 3 个竞品，所有事实注明来源与日期，最终支持是否进入 MVP。”
-
“把研究收敛成最小闭环：保留核心价值，明确不做清单和两周验证方案。”
-
“根据 Spec 生成可走查验收 checklist，覆盖正常、空、错误、权限与数据一致性。”
12.3 事务型办公人员路径：从重复劳动到可控流程
| 场景 | 推荐入口 | 输入 | 输出 |
|---|---|---|---|
| 会议纪要 | Work + Calendar / Files | 转写、agenda、参与人 | 结论、决策、待办、owner、文档草稿 |
| 日报 / 周报 | Scheduled Task / Skill | 任务、Git、会议、表格 | 完整报告、群简版、来源 |
| 资料整理 | Work / Claude Code 脚本 | CSV、Excel、文件夹、邮件 | 清洗表、异常、可复核清单 |
| 日程准备 | Chat / Work + Calendar | 会议、参与人、项目状态 | 冲突、会前资料、问题清单 |
| 流程 SOP | Work | 当前人工步骤、输入输出、权限 | 流程图、自动化候选、检查点 |
| 消息与跟进 | 插件 / Lark CLI | 模板、目标对象、条件 | 草稿、人工确认、发送记录 |
事务人员高频提示
-
“把这段转写整理成：结论 / 决策 / 待办 / owner / 截止时间；不确定项标注待确认。”
-
“读取这个表，先描述字段和质量问题，再生成异常清单；不要自动修改原文件。”
-
“根据今天日程和项目材料生成会前 Brief；每条结论给出来源。”
-
“把记录整理成周报草稿，事实、判断和建议分开；先不要发送。”
-
“梳理当前人工流程，标出输入、输出、等待、重复、错误和审批，再评估自动化。”
12.4 三类角色共同遵守的协作原则
| 原则 | 最低要求 |
|---|---|
| 先给目标与边界 | 每次任务至少明确目标、范围、成功标准、禁止事项 |
| 复杂任务先计划 | 使用 Plan 或 Spec；未决策项不得静默假设 |
| 每步都验证 | 要求命令、结果、截图、链接或数据证据 |
| 规则进入版本库 | 不把项目制度藏在个人聊天或 Auto Memory |
| 外部副作用可见 | 目标对象、内容、账号、环境和撤销路径必须明确 |
| 人类保留责任 | 架构、权限、发布、对外沟通与业务判断由责任人拍板 |
12.5 三个培训实操题
| 角色 | 实操 | 验收 |
|---|---|---|
| 程序员 | 在真实仓库修一个小 Bug，分别用 Plan、实现、独立 review 与验证会话 | 有复现、最小 Diff、测试、风险、回滚、PR 描述 |
| 产品经理 | 把一个模糊想法做成证据化研究、Spec 和可运行小原型 | 有决策问题、来源、非目标、验收与浏览器走查 |
| 事务人员 | 从会议材料生成纪要并发布到测试文档 / 测试群 | 有结构化输出、人工确认、真实链接、失败恢复 |