第 7 章 员工工作方法：人机协作的日常实践
前面六章建立了框架：认知校准、工作流设计、数据地基、最小闭环。但一个真实的问题始终没有被直接回答：
每天早上打开电脑，具体怎么和 AI 一起工作？
这一章回答的是微观层面的日常协作问题，不讲提示词技巧，不讲模型原理，只讲一个普通员工在正常工作日里，如何把 AI 稳定地嵌入自己的工作节奏，既不过度依赖，也不浪费能力。
先看绿灯：你可以在哪些地方安心尝试
这本手册的护栏不用于限制每一种探索方式，而是保护不可逆、不可审或超出职责的动作。只要使用的是已批准工具，以及公开、合成、脱敏或已明确允许的有限材料；输出只作为个人草稿或本地比较；不对外发送、不写入系统、不替代最终判断，你可以在自己的高频工作中主动尝试更好的整理、表达、检查和协作方式。 这属于探索轨，不需要先把团队治理材料全部填完。
若不确定资料是否允许、输出是否会影响他人、是否需要写入/发送，或任务已超出当前职责，请不要把“探索”当作继续的理由：按本章后文的话术暂停、转人工并请有决定权的人澄清。
一个约 15 分钟的最小创造动作
从一项你反复做、且处于上述安全边界内的小任务开始。先写下你希望改善的一个点，例如“让待办更完整”或“让日报结构更清楚”；再写 3 条你认为合格的标准；保存 2 个较好的例子和 2 个不符合预期的例子；最后只改变一个变量，比较两种提示、输入整理或检查顺序。记录“哪种做法更好、在什么条件下失效、下一次想试什么”。
这不是为了证明效率、替代人工判断或建立正式 Skill，而是让个人把模糊经验变成可讨论的工作假设。一次顺利输出只说明值得继续学习，不说明已经形成业务效果、团队能力或扩大依据。
一、首先明确：哪些子任务该交给 AI，哪些自己做
最常见的误区有两种：把所有任务都扔给 AI，或者把 AI 只用来做最简单的格式转换。两种极端都浪费了 AI 的价值，也都会带来问题。
一个更实用的判断框架是任务性质四象限：
| 规则明确 | 规则模糊 | |
|---|---|---|
| 信息充分 | 最适合 AI：格式转换、模板填充、分类打标、结构化摘要 | 可用 AI 起草，人工判断收尾：方案初稿、报告骨架 |
| 信息不足 | 先补齐经批准的来源或受控查询结果，再由 AI 协助整理、分析或起草 | 不能在信息和授权缺失时直接委托：需补齐内部知识、利益判断、关系背景和责任边界；高影响判断仍由人负责 |
操作建议： 在开始一个任务前，花 30 秒判断它属于哪个象限。右下角先补齐信息、来源和授权；右侧一列由人工保留关键判断；左上角可在已批准的工具、数据和行动范围内交由 AI 或受控 Agent 执行。
具体的“该/不该交给 AI”清单
适合交给 AI 的子任务：
- 把会议录音/笔记整理成结构化摘要
- 将已有信息填充进固定模板（周报、汇报格式等）
- 检查一段文本的格式、拼写、语气一致性
- 将一篇长文档压缩为要点列表
- 生成几个方向的初稿供选择
- 对已有内容做语言润色（保留原意，改善表达）
- 将数据转化为文字描述
- 对一组选项按指定标准进行分类
不适合直接交给 AI 的子任务：
- 涉及内部信息、利益权衡或关系判断的建议（即使提供部分背景，也不应把模型输出当作完整组织语境或正式判断）
- 没有已批准实时来源、受控检索或业务系统查询支撑的“当前状态”分析（基础模型内置知识并不等于当前业务事实）
- 最终的对外正式文件（需人工完整审核）
- 涉及个人情感判断的沟通（如处理团队冲突）
- 需要对结果负责的决策（AI 的输出不能作为责任依据）
二、多轮交互的工作节奏
很多人用 AI 的方式是“一次性写一个超长提示词，等待完美输出”，结果往往失望。更有效的方式是分阶段迭代：
标准的三段式工作节奏
第一段：定锚（1–2 轮）
目标是让 AI 理解任务的基本框架，不求完美，只求方向对。
示例流程：
- 给出任务的核心要求和关键约束
- 看 AI 的第一版输出，判断方向是否正确
- 如果方向偏了，直接纠正方向（不要在细节上修改）
常见错误：一开始就给出所有细节要求，导致 AI 陷入细节而失去整体结构。
第二段：收紧（2–3 轮）
方向确认后，逐步补充具体要求和细节约束。
示例流程：
- 告诉 AI“结构不错，但第二部分需要更具体，加上数据/案例”
- 对关键段落给出具体的改写方向
- 要求 AI 按特定格式或风格调整
常见错误：同时要求改很多地方，导致 AI 顾此失彼。每轮聚焦 1–2 个改进点。
第三段：收尾（1 轮 + 人工检查）
AI 做最后的格式整理、措辞润色，然后人工完成最终审核。
重要原则： 第三段的输出不能直接使用，必须经过人工对照验证清单检查。
知道什么时候停
多轮迭代中最容易犯的错误是迭代过度。以下信号提示你该停止了：
- 已经修改了 5 轮以上，但每次改动越来越小
- 修改的主要是语气和措辞，而不是实质内容
- 你已经花在改 AI 输出上的时间，超过了自己直接写的时间
- 输出已经“够用”，但你还在追求“完美”
停止标准： 输出满足任务的核心要求，通过验证清单，就可以进入下一步。不需要追求完美。
三、“够用”而非“完美”：如何判断输出可以使用
这是一线员工最难掌握的技能之一。判断标准：
三个必须满足的条件：
- 事实准确：涉及的具体数据、日期、名称、规则等可以核实，且无明显错误
- 结构完整：任务要求的关键部分都有覆盖，没有明显遗漏
- 符合格式：输出格式符合使用场景的要求（报告格式、措辞风格等）
三个“不影响使用”的不完美：
- 部分措辞不是你最理想的风格（可接受，自行微调）
- 某些论述不够深入（可接受，你自行补充背景）
- 结构比你预想的稍有不同（可接受，只要逻辑清晰）
判断方法： 想象你把这份输出发给一个严格但公平的审核，他会打回来吗？如果不会，就是“够用”。
四、AI 辅助与纯手工之间的切换策略
不是所有任务都应该用 AI。在以下场景，先用 AI 会反而效率更低：
切换回手工的信号：
- 你已经用 AI 生成了三版，但每次都需要大改（说明这个任务的核心信息 AI 不具备）
- 任务涉及高度内部化的判断（如特定业务背景下的策略决策）
- 对方是需要“感受到你的思考”的重要关系（有些沟通不适合 AI 语气）
- 任务体量很小，用 AI 的来回协调时间超过直接做的时间
切换到 AI 的信号：
- 你在重复做之前做过的事（可以用上次的提示词模板）
- 你面对空白文档不知从哪里开始（AI 给初稿，你来判断和补充）
- 你需要快速了解一个不熟悉的领域（先用 AI 搭框架）
- 你有明确的内容，但需要帮助整理成特定格式
原则： AI 可以在受控范围内起草、整理、检索、分析、调用工具或执行已批准步骤；它不是业务判断、正式授权或责任承担的替代者。
五、保持独立判断力的日常习惯
长期使用 AI 最大的隐性风险，是判断能力的悄悄让渡。以下是防止这种情况的具体习惯：
习惯 1：在看 AI 输出之前，先写下你自己的判断
对于重要任务，在把任务交给 AI 之前，先用 1–2 句话写下你自己对这个问题的判断或预期答案。然后再看 AI 的输出。这会帮你：
- 发现 AI 的输出和你的判断有什么差异
- 保持独立思考的习惯，而不是直接被 AI 的输出锚定
习惯 2：不接受无来源的数字和事实
AI 输出中的具体数字、引用、统计数据，不要不加核实地使用。养成习惯：只要输出中出现数字或事实陈述，就标注“待核实”，在最终使用前验证来源。
习惯 3：问“如果 AI 不存在，我会怎么做这件事”
每隔一段时间，对某类任务用纯手工方式做一次，保持自己的基础能力不退化。这不是否定 AI 的价值，而是确保你对 AI 的依赖是“可以选择的依赖”而非“不得不依赖”。
习惯 4：区分“AI 建议”和“我的决定”
在向他人传达时，明确区分：哪些是 AI 辅助生成的内容，哪些是你的判断和决定。不要把 AI 的输出当成你自己的分析原封不动呈现，需要你自己的判断为其背书。
习惯 5：记录 AI 的失误
每当 AI 给出错误输出，记录下来：什么任务、什么类型的错误、你是怎么发现的。这个习惯会快速帮你建立起对 AI 能力边界的准确认知，比读任何文档都有效。
把个人技巧变成团队可评估的候选
个人探索得到的好做法，不必一开始就包装成正式 Skill 或要求全员照做。若同一方法在相近任务中多次有帮助，可先向经理或 Skill/流程 Owner 提交一份简短候选说明：它改善的是哪类任务；当前允许的输入与不适用条件；你比较过的两种做法和少量好/坏例子；仍需人工保留的判断；以及已经观察到的失败或疑问。
这份候选说明的作用是让团队决定“是否值得进入 L0 三项设计”，而不是把个人经验直接发布为正式流程。只有业务 Owner、知识/流程 Owner 与相关审核人确认任务边界、来源、质量和回退后，个人技巧才可进入团队的受控测试、Skill 或工作流；不满足条件时，保留为个人探索笔记、继续学习或停止复用。
六、个人层面的质量自检
在把 AI 输出用于正式场合之前，完成以下自检清单：
事实层
- [ ] 所有具体数字、日期、名称已核实
- [ ] 引用的政策、规则是当前有效版本
- [ ] 没有包含我不确定但看起来合理的内容（即“听起来对但没验证”）
逻辑层
- [ ] 结论和论据之间有合理的支撑关系
- [ ] 没有出现内部矛盾（前后说法不一致）
- [ ] 对结论的确定性程度表达是准确的（“可能”不写成“确定”）
场景层
- [ ] 内容符合这次使用场合的正式程度要求
- [ ] 对受众来说语言是合适的
- [ ] 如果传播出去，我愿意对内容负责
通过这三层自检后，输出才可以进入正式使用环节。
使用 Agent 时的额外检查
Agent 不只是“多轮聊天”。它可能会检索知识、读取系统、保存记忆、调用工具或提出下一步行动。员工不需要理解底层实现，但必须能判断它的任务边界、可见信息和拟执行动作是否仍在授权范围内。
| 时点 | 员工必须确认的事项 | 发现异常时 |
|---|---|---|
| 发起前 | 是否使用已批准的 Agent/Skill；任务、对象和范围是否清楚；是否可使用当前数据；是否理解该 Agent 不会做什么 | 缩小任务、改用固定 Skill 或转人工；不要用个人工具绕过正式边界 |
| 运行中 | Agent 依据的来源、版本和工具结果是否与任务相关；是否出现超范围检索、敏感信息、未知来源、异常工具结果或未预期动作 | 停止或拒绝当前步骤；保留必要记录；按问题升级路径联系知识、技术或业务 Owner |
| 审批前 | 是否能看懂其计划、关键依据、未确认项和拟执行动作；是否仍需人类判断或正式授权 | 修改、拒绝、转人工或终止；不得因“看起来合理”而机械批准 |
| 完成后 | 最终内容、行动记录、来源和版本是否可追溯；是否需要更新失误记录、知识反馈或试点证据 | 记录问题、更新反馈；对有影响的错误按 Runbook 升级 |
员工应把“Agent 提出计划”与“我批准执行”视为两个不同动作。只要依据不清、信息过期、权限不确定或影响超出自己的职责，就应停止并转人工。第 5 章说明如何识别最小上下文包；第 9 章和附录 A 第 48–51 节提供运行合约、上下文、记忆、工具和评测资产。
七、不同工作场景的具体协作模式
场景 1：写作类任务（报告、邮件、文案）
推荐流程：
1. 自己先列出核心要点（3–5 个）
2. 交给 AI 生成结构化初稿
3. 人工对照要点检查覆盖完整性
4. 修改关键判断和措辞
5. 对照自检清单做最终确认注意： 给 AI 的信息越具体，初稿质量越高。“写一份季度总结”的效果远不如“写一份 500 字的 Q3 运营总结，重点是用户增长从 5% 提升到 12% 的原因分析”。
场景 2：分析类任务（数据解读、方案评估）
推荐流程：
1. 把原始数据/材料整理好，提供给 AI
2. 让 AI 先做结构化整理（不要直接要结论）
3. 人工审核整理结果是否准确
4. 再让 AI 基于整理结果做初步分析
5. 人工补充内部背景知识，修正分析偏差
6. 形成最终判断（判断必须由人给出）注意： 分析类任务中，AI 负责信息整理和框架搭建，人工负责背景补充和最终判断。两者的分工不能倒置。
场景 3：沟通类任务（对外邮件、客户回复）
推荐流程：
1. 人工先确定沟通立场和核心信息
2. 交给 AI 起草具体措辞
3. 人工检查是否准确传达了立场
4. 调整语气使其符合关系性质
5. 发出前再读一遍，确认代表你自己注意： 沟通类任务的核心是立场和关系，这部分必须由人决定，不能交给 AI。
场景 4：研究类任务（了解新领域、竞品调研）
推荐流程：
1. 用 AI 快速搭建领域框架（主要概念、关键问题）
2. 将 AI 的框架作为问题清单，自行查阅可靠来源
3. 用 AI 辅助整理和归类收集到的信息
4. 人工提炼结论和判断注意： 研究类任务中，AI 输出只是起点，不是终点。AI 给你的知识框架可能是准确的，也可能包含过时或错误的内容，必须用可靠来源核实。
八、按岗位的 AI 协作实践卡片
同样的原则在不同岗位上有不同的落点。下面五张卡片给出高频任务、适合交给 AI 的部分、必须人工保留的部分和验证要点；请按你的真实业务场景替换任务名称，不要直接照搬。
客服/支持岗
| 项目 | 内容 |
|---|---|
| 适合交给 AI | 标准咨询回复草拟、问题分类、摘要提取、话术润色 |
| 人工保留 | 例外承诺、投诉升级、情绪判断、最终发送 |
| 验证要点 | 使用正确问题类型的最新要点；无额外承诺；语气符合规范 |
| 关键资产 | 知识 Owner 维护的标准答复要点（带版本与生效日期） |
运营岗
| 项目 | 内容 |
|---|---|
| 适合交给 AI | 周报/日报初稿、数据描述、异常标记、汇总整理 |
| 人工保留 | 异常原因判断、数据口径确认、对外发布 |
| 验证要点 | 数据与原始表格一致；被规则命中的异常均有说明；无编造原因 |
| 关键资产 | 固定输入模板、可解释的异常规则、数据一致性检查 |
市场/内容岗
| 项目 | 内容 |
|---|---|
| 适合交给 AI | 初稿生成、结构规划、多版本标题、排版与润色 |
| 人工保留 | 品牌立场、事实与数据核实、合规审核、最终定稿 |
| 验证要点 | 事实和引用可核实；无虚假宣传或越界承诺；符合品牌规范 |
| 关键资产 | 品牌规范、过往已发布稿件作为示例、内容审核清单 |
研发/工程岗
| 项目 | 内容 |
|---|---|
| 适合交给 AI | 代码片段与测试生成、重构建议、文档初稿、问题排查思路 |
| 人工保留 | 架构决策、安全敏感代码、生产部署、最终审查 |
| 验证要点 | 代码通过测试与审查；无未理解就合入的代码；安全与性能责任不转移 |
| 关键资产 | 代码库上下文、测试套件、评审与发布流程 |
HR/职能岗
| 项目 | 内容 |
|---|---|
| 适合交给 AI | 内部通知草稿、制度文档整理、培训材料初稿、FAQ 生成 |
| 人工保留 | 人事决策、绩效与敏感信息处理、制度口径确认 |
| 验证要点 | 数据边界（不输入未批准的个人信息）；制度口径与现行版本一致 |
| 关键资产 | 脱敏流程、数据分级确认、制度文档版本 |
使用方式：把本岗位卡片里的任务换成你的真实高频任务，对照“适合交给 AI / 人工保留 / 验证要点”三列，形成你自己的岗位工作方式，并提交给经理确认边界。
九、新员工 AI 协作入门（第一周）
新员工不应该通过“听一场通用培训”学会 AI 协作，而应该通过真实任务建立边界感。建议入职第一周按以下节奏安排：
第 1 天：边界教育（30 分钟）
- 哪些数据可以输入 AI、哪些不可以（按第 15 章数据分级确认）；
- 哪些工具/平台是批准的，个人账号不能用于公司工作；
- 什么场景必须转人工、什么动作必须审批。
员工应同时知道自己的边界：可以报告缺口、请求澄清、暂停使用和转人工；但不应代替业务 Owner 决定风险是否可接受，代替知识 Owner 判定规则版本，代替技术/安全 Owner 批准数据、权限或工具，也不应自行作出对外、写入或生产变更决定。
第 2–3 天：受控试跑
- 用 1 个低风险真实任务，在导师陪同下完成“输入 → AI 生成 → 对照清单检查 → 人工修改 → 记录问题”全流程；
- 完成第 4 章的四象限判断练习：这个任务哪部分适合 AI，哪部分必须自己做。
第 4–5 天：独立运行与反馈
- 独立完成一次受控任务，并对照三层自检清单（事实层、逻辑层、场景层）检查；
- 建立个人“AI 失误记录”，提交第一份反馈（问题、类型、如何发现）；
- 与经理确认：你所在岗位的“适合交给 AI / 人工保留”边界（可参考上一节岗位卡片）。
第一周结束的标志：新员工能说清“哪些任务我用 AI、哪些我绝不交给 AI、出错时找谁”，并至少留下一次可复核的受控运行记录。
十、从个人习惯到团队能力：培训与变革如何运行
前面的内容主要解决“个人如何稳定协作”。但组织采纳不是个人习惯的简单相加：使用者需要知道如何安全完成任务，知识 Owner 需要维护规则，经理人需要选择场景与保护试点时间，Skill/流程 Owner 需要把经验封装为资产，技术 Owner 需要保障权限与运行控制。把所有人放进同一场通用培训，往往只能带来短暂热度。
1. 按角色学习，而不是按工具学习
建议按角色分配学习目标和实践任务。全员使用者重点练习任务判断、数据边界、人工核验和问题上报；业务 Owner 重点练习场景选择、基线、价值与暂停决策；知识 Owner 重点练习时效、冲突和变更回归；Skill/流程 Owner 重点练习封装、评测和第二人复现；技术 Owner 重点练习权限、日志、熔断与接管；管理者重点练习资源、风险和组合决策。
完整的分角色能力地图和实践认证记录见附录 A 第 22 节。认证不以听课时长、登录次数或 Token 消耗为依据，而以真实或脱敏任务中的可复核证据为依据：是否遵守边界，是否完成角色关键动作，是否能解释何时停止、转人工或升级。
2. 经理人的核心任务是改变工作方式
团队经理不应把“使用 AI 次数”当作绩效指标，也不应要求所有成员使用同一工具。正确的做法是选择一个低风险、高频、可验证的任务；让成员在真实样本上共同练习；把 Skill、验证与人工确认嵌入 SOP；再根据质量、采用、耗时、失败和知识更新情况，决定扩大、改进或暂停。
特别重要的是，经理人应明确传递一条规则：及时上报失败、知识过期、异常输出和控制缺口是有价值的改进行为；在不确定时转人工、暂停或拒绝发送，是被支持的专业判断。 隐瞒失败、绕过验证或用未经批准的工具处理敏感工作，则应进入相应的风险处理流程。附录 A 第 23 节提供 30 天启动节奏与经理人每周检查问题。
经理人还应与业务 Owner 说清一件容易被忽略的事：AI 辅助不是把“省下来的时间”自动换成更高的个人产出配额。开始团队试跑前，至少共同确认哪项重复动作会减少或改变；新增的审核、例外处理、知识维护和反馈由谁在什么时间承担；以及释放出的容量优先用于降低积压、改善服务、学习/改进还是其他已同意的业务目标。若这些问题尚无答案，就不应把使用频率、节省分钟数或个人是否愿意尝试直接写入绩效压力；应先用受控观察了解工作负担是否只是被转移。第 12 章说明团队如何把这类约定放进阶段复盘与资源决定。
员工可直接使用的暂停、拒绝与上报话术
以下话术的目的不是把责任推走，而是让不确定性在造成不可逆后果前进入正确的判断路径。团队应把本地的联系人、工单入口或升级时限补入方括号中。
| 情形 | 可直接使用的话术 | 随后要记录/转给谁 |
|---|---|---|
| 输入来源、版本或数据边界不清 | “我无法确认这份资料是否允许用于当前任务，也无法确认它是否仍然有效。我会先停止使用它，并请【知识/数据 Owner】确认来源、版本和适用范围。” | 记录资料标识、发现时间、当前任务；转知识或数据相关 Owner。 |
| 输出涉及发送、写入、承诺或关键决定 | “这一步会产生【对外发送/系统写入/业务决定】。我可以准备草稿或证据，但不会自行执行；请【业务 Owner/审批人】确认后继续。” | 记录拟执行动作、审批请求和未执行状态；转有相应决定权的人。 |
| 无法按清单判断输出是否合格 | “我无法依据现有规则判断这份输出能否使用。为避免把不确定内容带入流程，我将按原人工流程处理，并请【业务 Owner/审核人】澄清判断标准。” | 记录未通过的检查项、已用依据和人工回退动作。 |
| 发现异常、敏感信息、工具越权或安全担忧 | “我发现【异常/敏感信息/越权请求】。我已停止后续操作并保留必要记录，请按【风险/安全升级路径】处理。” | 记录最小必要事实，不扩散敏感内容；转技术、安全或风险联系人。 |
| 任务本身已超出批准范围 | “这项请求超出当前用例的已批准范围。我不会通过更换 Prompt 或工具继续推进；请【业务 Owner】决定是缩小范围、补充审批，还是不做。” | 记录原请求、当前范围与缺失条件；转业务 Owner。 |
员工的专业责任是识别、记录并升级不确定性，而不是独自接受风险。任何人都可以暂停或转人工；只有被授权的角色才能接受例外、扩大范围或恢复运行。
3. 让反馈产生可见的改进
员工只有在反馈被处理、处理结果被回告时，才会持续采用正式流程。团队应提供低门槛入口，允许成员报告输出错误、知识过期、工具限制、培训困惑、数据担忧或“这个场景根本不适合 AI”的判断。反馈应被分流到知识更新、Skill/流程改进、技术/权限处理、培训、风险升级或用例组合决策，而不是停留在群聊里。
附录 A 第 24 节提供采纳反馈与问题上报模板。每月汇总反馈类型和处理时效，可以帮助团队识别真正的培训盲区、知识缺口和流程障碍。
十一、本章行动清单
立刻可以做的（本周）：
- [ ] 在批准工具与允许材料的边界内，对一个高频小任务完成一次“3 条合格标准 + 2 个好例子 + 2 个坏例子 + 一次单变量比较”的探索；不对外发送、不写入系统，也不把结果宣称为业务效果
- [ ] 对你最常做的 3 类工作任务，用四象限框架判断哪部分适合 AI
- [ ] 选其中一类，设计一个三段式工作节奏，试跑一次
- [ ] 建立一个“AI 失误记录”文档，开始记录你遇到的输出问题
- [ ] 为本岗位保存一份“暂停、拒绝、上报”话术；遇到不确定的来源、对外/写入动作或无法验证的输出时，先停止并按路径升级
- [ ] 如团队正在试用 Agent，选择一个低风险任务，按“发起前—运行中—审批前—完成后”四个时点记录一次受控使用过程
建立习惯（一个月内稳定）：
- [ ] 对重要任务，在看 AI 输出前先写下自己的判断
- [ ] 所有正式输出在使用前完成三层自检清单；涉及 Agent 时额外完成来源、工具、审批和行动检查
- [ ] 每月至少用纯手工方式做一次你常用 AI 辅助的任务
团队层面（如果你是团队 Leader）：
- [ ] 组织一次“工作方法分享”：让用 AI 效果好的成员分享具体的任务拆分和协作节奏
- [ ] 把本章的“适合/不适合交给 AI 的子任务清单”根据你们的业务场景具体化
- [ ] 建立团队共享的“AI 失误案例库”，定期回顾
- [ ] 为使用者、业务 Owner、知识 Owner、上下文/工具 Owner 和 Skill/流程 Owner 分别选择一项真实实践任务，而不是只安排通用培训
- [ ] 建立一个可追踪的反馈入口，并在下次周度复盘中回告至少一项处理结果
- [ ] 用附录 A 第 23 节的 30 天节奏，决定一个试点场景是扩大、改进还是暂停
- [ ] 对一项已在个人探索中重复出现的有效做法，提交“个人技巧候选说明”；由相应 Owner 决定是否进入 L0，而不是直接要求团队照做
本章小结
稳定的人机协作不依赖天赋，依赖习惯。
关键是在任务开始前花 30 秒判断任务性质，在使用过程中保持三段式节奏，在输出完成后用清单检查，以及在长期使用中保持独立判断力的练习。
这些习惯单独看都很简单，但坚持执行是让个人 AI 使用从“偶尔有用”变成“持续稳定”的核心路径。