这是笔者在公司内，为同组的数据分析师，撰写的一篇有关如何使用AI来提效的文档，文章已隐去业务细节。
引言：AI 协作是一套项目管理方法
最近我接了一个项目：对「xx产品」的投放用户做 LTV180 预估。如果你做过类似的预估工程，大概率会对它的“耗时”和“复杂”很熟悉：取数、数据清洗与口径对齐、特征工程、训练与调参、评估对比、再到线上化落地，每一步都不难，但链路很长，细节很多，整体推进成本很高。
这次我换了个做法：把它当成一次“人机协作”的项目来推进。多数时间我在和 AI 对齐思路、口径和验收标准；数据准备好之后，让它按既定管线自己跑训练、做预估、产出评估对比。我只在关键节点介入：做判断、收敛方向、最后验收。最终交付的精度还不错，自动化程度也明显更高。
但我想说的不是“AI 很好用，大家都来用 AI，就能立刻提效”。相反，如果你真的开始把一大堆工作交给 AI，你会很快遇到一系列现实问题：它会笨、会偷懒、会跑题，也会自信地给出错误结论。AI 能创造业务价值没错，但“用好 AI”本身有门槛。
更关键的是视角问题：AI 与其被当作工具，不如把它当作需要被管理的执行者——像一个潜力很大、但需要明确指引的实习生。这篇文章就从“AI 的管理者”这个角度，拆解几个让 AI 顺滑工作的关键环节和管理原则。某种意义上，这是一次工作岗位的晋升：你用“带人”的方法去拆解、派活、验收，很多原本看上去是模型能力问题的地方，反而会变得好处理。
Part 1 任务拆解与 AI招聘
1.1 任务拆解与分工
站在管理者视角，接到上级任务后的第一件事，不是马上开干，而是先把任务“翻译”成团队能交付的结果形态。第一步先抓两件事就够：拆解任务、明确分工。 引入 AI 之后，这套思路并没有变。变的是团队的“成员结构”：除了同事，还多了一批各司其职的 AI。分配原则也更清晰了——AI 做它擅长、可自动化的部分；人做需要判断、需要承担责任的部分。
- AI 适合处理高频重复、快速迭代、结构化整理、批量执行；
- 人更擅长定目标、做取舍、控风险、立标准、最后拍板
拿这次项目举例：一个完整的 LTV180 预估，大致分三段——训练前（规划与澄清）、训练中（建模与迭代）、训练后（交付与落地）。每一段都应该由“合适的员工”负责：比如项目澄清需要频繁和业务方对齐口径、确认边界，这更适合人来做；训练和调参可以流程化、自动化，就让 AI 写代码、跑实验、产出记录。
没有 AI 的时候我们也会做拆解，但有了 AI 之后，拆解的目的不只是分配人力，而是把 AI 当成可用的产能纳入团队：用「人 + AI」的方式，把不少工作流重新做一遍。
1.2 招聘：为每个模块选对 AI 工具
拆解完任务，下一步是为每项工作找到合适的 AI。“选对人”本来就是管理者的基本功。能力结构不匹配，再强的 manager 也很难稳定交付。AI 也是一样：不同模型长板不同，把任务分给合适的模型，往往比提示词技巧更重要。 这件事没什么捷径，主要靠多用、多对比、多复盘，每个人的感受也各不相同。我个人当前的偏好如下：
- 深度调研：Gemini Deep Research、ChatGPT Deep Research
- PRD/技术决策/辅助思考：Gemini 3.0-Pro
- 写代码，短平快：Cursor Composer 1、AIStudio build、GPT-5 Codex
- 写代码，复杂工程：Claude Code（Opus 4.5）
- 写文档：画图（nano banana pro）；文字润色（ChatGPT、Claude） 
Part 2 清晰化：把需求说清楚
2.1 写一份完整的项目PRD
想象一个很常见的场景：周一早上，业务方找你说：“帮我分析一下 XXX 功能上线后的效果吧。”你追问细节，他支吾半天，只丢下一句“老板要的”就走了。你心里大概已经开始骂人了。
然后，再把这个场景切换到你和 AI 的工作中，此时你变成了那个业务方，你告诉 AI：“给我做个分析，关于XXX的”，你觉得AI的心里在想什么呢？当然，AI不会说“我干不了，你去告状吧”，AI高低肯定能给你干了，但你敢用这个结果吗？
所以，不论对同事还是对 AI，第一重要的就是把话说清楚。最有效的方式，是把要做的事情写成一份可执行的 PRD。更省力的做法也很直接：PRD 不必从零手写，而是通过和 AI 反复讨论把它“打磨”出来。我通常这么做：
- 先把项目完整讲给它听，尽可能提供你已有的业务知识、约束条件、历史经验与隐性偏好；
- 在讨论过程中，持续追问“这块你觉得有什么问题吗”，让它复述你的需求，并主动提出你可能遗漏的点；
- 当对话推进到某些环节被问住（就像需求评审时，突然发现自己被问住了），就暂停执行，和它一起把这个问题讨论出结论，再继续往下；
- 直到讨论不再产生新的增量信息，让它把所有结论与约束收敛成一份结构完整的 PRD 输出给你。 以本次LTV180预估为例，我和gemini进行了如下的对话（仅供参考，真实的回合数会更多）：
| 回合一：开始问题 | 回合二：提供背景 | 回合三：追问 | 回合四：继续追问 | 回合五：整理成PRD |
|---|---|---|---|---|
 |  |  |  |  |
最后推荐两个非常实用的小习惯：
- 习惯一：用“口喷”输入提高信息密度。思考时直接对着电脑讲，哪怕语音很乱，但信息更全、更贴近真实思维，把这份原始材料交给 AI 处理，效果通常比手打更好。此处强烈推荐用 Typeless 做语音转文字，它拥有我见过最好的识别准确率，以及极强的结构化文本的整理能力，乱说一堆也能给你整理的很好，用过一次就离不开了。
- 习惯二：保留AI的“面包屑”。把和AI对话的链接保存下来，放到文档的附录里，后续回看背景与细节会非常省时间，也方便你持续迭代同一个 PRD。
2.2 Curse of Knowledge
接下来有一个很容易被忽视、但对“人机协作”影响极大的概念：Curse of Knowledge（知识的诅咒）。举个生活化的例子：我女朋友让我收拾行李，顺便把衣服叠好。我听到后，直觉就是“叠起来塞进行李箱就行”。但在她的标准里，这样的叠法不够靠谱。原因很简单：
- 有些衣服叠得不对，会产生明显褶皱；
- 随意叠放会很占空间，整体装箱效率很差。
这就是典型的“知识的诅咒”：她脑子里有一套“科学叠衣服”的方法和标准，我没有。任务交给了我，但隐形标准没说清楚，我就算认真做，也很难做到她心里的“正确”。问题不在态度，而在信息差——关键的操作方法和判断标准没有被显性化。
很多管理者布置任务时也一样：因为自己太熟，默认关键细节“大家都懂”。结果任务一旦交给下属，产出就很容易偏。看上去像是能力问题，实质是对方根本不知道你脑子里那套标准。
放到 AI 协作里也是同一件事。AI 看起来聪明，但它不会自动读懂你的默认前提、隐含口径和验收标准。你越专业，越容易把最关键的部分省略掉。遇到回复不及预期时，先别急着下结论说“它不行”。更有效的是回到管理者视角：是不是我给的信息不够完整。很多时候问题不在“智能不足”，而在“信息传递不完整”。
一个很实用的 Prompt 技巧，是把“补信息”这件事交给 AI 来反问你。你可以直接问它两句：“你觉得我还有哪些信息没有交代清楚？”“为了做出更好的判断，你还需要知道哪些信息？”
Part 3 开始干活，像带组员一样控过程
3.1 入职培训
先讲 AI 的“入职培训”。AI 极度依赖当前对话窗口的上下文。对它来说，信息不在上下文里，就等同于不存在。也因此，入职培训不是做一次就够了；只要你换了新对话，关键背景和标准就得重新交代。 核心就一句：把 AI 当新员工带，关键是管好上下文，尤其在复杂项目里。我通常从几个角度补齐背景：
- 用提示词交代高频规则：语言、格式、禁用写法等。反复出现的规则再沉淀成文档，用 @文档 减少重复输入。
- 不只说“做什么”，还要说“为什么”：重要决策的原因写进文档，让它读一遍，后续代码质量会好很多。
- 把关键架构写在 README.md里：很多“大项目写不好”，本质是缺少架构层的入职培训。本质是缺架构层的入职培训。给它一份高层概览：核心模块、关键流程、必读文件、边界条件。必要时先让 AI 通读代码库，产出工程概述当起点。
- 问题记录：每一次遇到并解决了重大 Bug，都要记录下来，在后续迭代时可以快速回查历史决策与踩坑记录，避免反复犯同类错误。
- 把常见交付方式也标准化进文档（尤其是验收与看数方式）：以 LTV 预估为例，需要一套固化的看数逻辑：用哪些指标、和哪个 baseline 比、图表格式如何统一。一旦这套规则确定，就写进文档；此后每次训练新模型，结论必须基于同一套看数方式输出。这样可以保证评估标准一致、对比图表格式统一，显著减少重复沟通成本。 这套“培训”是可以累积的：把高频规则、关键决策、踩坑经验和验收规范沉淀成知识资产，会产生复利，越早开始越划算。
3.2 过程指导
在项目执行阶段，我们往往需要对 AI 做过程指导。但“指导”不等于盯着它写每一行代码。更像管理日常：你给方向、边界、标准，让执行者自己把细节跑出来。实践里最省时间的方式通常是“高层指导”：
- 给大方向：你希望它朝哪个目标推进
- 划清边界：哪些不能做、哪些必须做
- 设定标准：什么算完成、什么算不合格
- 让它自检：先自我检查，再提交给你验收 举个例子，在预估过程中，遇到需要迭代的部分，我给的指导是：
- 首先，让他自己去检查当前模型的效果，分析还可以做哪些特征工程来提高模型的准确率（给大方向）；
- 接着，让他根据刚刚分析的方向，再尝试一版模型，但是不要改动之前的结果，也不要乱删文档（划清边界）；
- 最后，让他判断新的模型是否真的更好，从而决定采用哪一个（划定标准+自检）； 这里比较有用的一个小技巧，是在每一步的提示词中加上“做完后，自己检查一下结果，判断合不合理”，往往能省掉很多debug的时间，
3.3 工程验收
第三步是“工程验收”。AI 做完作业之后，管理者仍然要花精力验收——短期内这部分很难被替代。原因很简单：“什么算好”往往是一类高度复杂的隐性知识：它来自经验、业务语境、风险偏好和取舍标准，模型很难做到这一点。但即便如此，我们依然可以用一些方法，把验收做得更快、更稳、更可复用。 第一类方法：借助可视化，把“指标”变成“直觉”。 以 LTV 预估为例，MAPE、MSE 这些数字本身不够直观：误差集中在哪？长尾有没有崩？某些渠道/人群是不是明显偏？这时最有效的验收手段就是画图。让 AI 产出误差分布、分桶表现、分人群/分渠道对比曲线、预测值 vs 真实值散点图等。图出来之后，很多“数字上看不出的问题”会直接暴露。 更重要的是，好的验收流程通常不是一次性设计出来的，而是在多轮迭代中逐步找到最有效的观测方式，然后固化下来：每次训练新模型都按同一套图表与指标模板输出，对比才有意义，沟通成本才会下降。 第二类方法：交叉验证与赛马，让 AI 监督 AI。 当你对某个结论不够放心，可以拉一个“第二意见”来复核：例如在 Claude Code 里开多个窗口，用不同提示词或不同推理路径做对照；或者用另一个模型复查关键代码与结论，看看是否存在明显分歧。本质上，这是用工程里的“对照与复现”来降低不确定性，而不是让同一个 AI 在原地重复试错。 归结起来，验收必须前置：在开始让 AI 干活之前，就先想清楚“我准备怎么验收、用什么标准评价、什么结果才算可交付”。当评价标准明确，AI 的执行会更容易收敛，管理成本也会显著下降。
Part 4 「人机协同」的心态升级
最后，在持续使用 AI、并与它一起交付了几个完整项目之后，我明显感觉自己的工作方式在变化：过去很多靠经验形成的习惯——怎么拆解、怎么推进、怎么评价产出——正在被更适配 AI 时代的方法替代。我把这种变化总结成两点。
4.1 从“代码复用”到写“一次性代码”
以前判断 LTV 预估是否合理，我大概率只算个大概值，或者盯几个核心数字看趋势。我很少为了验收去写一堆可视化脚本，把误差分布、分桶表现、分人群/分渠道差异全都画出来——不是因为不重要，而是因为太耗时，不划算。 现在这件事变得可行了。哪怕这些脚本只用一次，写完就丢，也没关系：在 AI 的辅助下，“把想法变成代码”的边际成本被压得很低。成本一旦足够低，很多过去被卡死的动作——更细的验证、更全面的对比、更快速的探索——就能变成常态。 改变的不只是效率，而是你能做到的上限。
4.2 从“低分辨率”的黑盒到“高分辨率”的白盒
第二个变化，是从过去那种“低分辨率”的黑盒观察，转向现在“高分辨率”的白盒观察。
这个表述听起来非常抽象，让我们回忆一个现象：为什么很多DA团队在有了 LLM之后，最经常被提及的项目之一就是“AI打标”（打标 Agent－可标 K-label）？因为标签代表着对每一个实例的观察，这是一种高分辨率的数据分析。
在传统工作流里，打标签很耗时，成本极高。为了对用户做一些分析，专门标注大量样本，往往投入产出不划算，就发展出一套妥协策略：我们认为所有的用户，都可以按照一些特定的 维度 聚合成“数据桶”，我们再观察这些桶的 指标 变化就可以了。
显然，这种情况下我们看到的不是“单个用户”，而是聚合到某个恰好不粗不细的维度下的“数据桶”。这实际上，就是一种低分辨率的黑盒分析，而非高分辨率的白盒分析。
而这种在“看不见的情况下”，去做黑盒分析的能力，就成了一种重要的技能（技术去debug，DA去做分析，PM去做策略）。换句话说，在信息获取成本过高的时代，我们把技能点大量点在“推理黑盒”上，而不是“直接观察系统内部”。
但有了 AI 之后，局面变了：
1）观察能力大幅增强：AI 在打标签、归类、抽取结构化信息方面极强，可以把每一个具体 case 直接摊开来观察；
2）信息成本被打穿：过去因为太贵、太耗时而无法处理的信息——比如全量评论内容、细粒度属性日志、客服对话、日常行为轨迹——现在几乎可以低成本甚至近乎实时地被整理出来。
这些信息过去一直存在，只是我们拿不到、用不起；而现在它们变得触手可及。因此，心态的转变在于：我们正在从一种“依赖直觉、对系统做外部推测”的决策模式，转向一种“基于全量观察、对系统内部做直接洞察”的决策模式。你不再需要靠猜测补全世界，而是可以用更高分辨率的现实信息，把黑盒拆开看清楚再做判断。
结尾 七天快速练习
- 挑战 A：用 AI 完成一个小项目（选你工作里最常见的一类）
- 挑战 B：把困惑完整讲给 AI（建议语音），让它追问并结构化成一份完整的文档
- 挑战 C：把自己的某个routine的任务做拆解，找到可以让AI协同的部分
附录
写文档期间用到的一些参考资料，Computing Life博客里的几篇文章（强烈推荐）：