- 只算起草时间的“快一倍”，多半不成立，因为省下的时间挪到了后面的返工上。
- 要从接到工作开始计时，一直算到客户拿到成果，返工也要算作成本。
- 管用的做法是分两轮做：第一轮找思路，第二轮核对准确性。别急着把初稿交出去。
按业务的标准定义“快一倍”
如果员工写草稿从 60 分钟缩短到 15 分钟，却因为数据有误还要再改三轮，这项工作其实一点也没有变快。该计时的是从接到工作到客户拿到成果的整段时间，坐下来打字只是其中一小段。
很多团队觉得 AI 非常快，因为它几秒钟就能生成一段文字。可接下来，可能还要花时间核对事实、调整语气、找对的文件，或者走好几轮审批。如果只计算起草时间，公司看到的就是一场并不存在的胜利。应该衡量交付周期（Lead Time）：从收到请求开始，到接收方认可成果为止，等待时间、返工和退回重做的工作都要算进去。
先把工作单位定义清楚，比如“已审批的报价单”“主管能据此做决定的报告”或“能够结案的客户回复”。然后收集至少 20–30 件工作作为基线，按简单、中等、困难分开，因为 AI 通常擅长标准案例，处理例外情况的时间却不会按同样的比例缩短。
找出消失的时间
写给开发团队 · 技术细节
画出一项工作的时间线，拆成 Touch Time（人动手处理的时间）、Machine Time（系统处理的时间）、Wait Time（等数据或等审批的时间）和 Rework Time（回头返工的时间）。AI 适合减少 Touch Time，如果能打通相关系统，也能帮助减少 Wait Time；但如果没有任务简报（Brief）和质量关卡（Quality Gate），Rework Time 反而会增加。
设计五段式工作流水线：Frame、Gather、Create、Check、Act
把一件工作看成一条传送带：从理解需求、收集信息、动手做、检查，一直到交付。AI 在有些环节帮助很大，在另一些环节完全帮不上忙。知道哪些环节能交给 AI、哪些不能，速度才会真正提上来。
Frame（定题）：把问题收窄，写明接收人、目标、范围和完成标准（Definition of Done）。Gather（收集信息）：从可信的来源调取数据。Create（动手做）：让 AI 总结、提出备选方案或起草。Check（检查）：对照规则和证据检查，并由有权限的人把关。Act（交付）：发送、更新系统，或开启下一项工作。分成五段之后，问题出在哪一段就很清楚，不用再笼统地说一句“AI 答得不好”。
| 阶段 | AI 能帮什么 | 仍需由人负责的部分 |
|---|---|---|
| Frame | 提问，帮忙补全简报 | 确定真实的意图和限制条件 |
| Gather | 搜索、调取和整理数据 | 选择数据来源和权限 |
| Create | 起草、总结、比较 | 选定方案，做出取舍 |
| Check | 检查内容是否齐全、格式是否正确 | 核实事实、数字和政策 |
| Act | 创建任务或更新系统 | 审批影响重大的操作 |
能减少返工的简报
简报要回答七个问题：要什么结果，谁来用，对方已经知道什么，输入从哪里来，有哪些禁止事项，交付成什么格式，合格标准是什么。再附上一份合格的示例和一份不合格的示例。把这些写清楚，比在提示词（Prompt）里堆一大串形容词有用得多。
重要信息不要让 AI 去猜。来源不全时，写明“停下来，索要数据”；数字必须准确时，用公式或模型之外的计算系统；需要引用政策时，附上版本号和日期。把这些限制写进工作流，安全就不必依赖每个用户的记性。
四道质量关卡
- Fact（事实）：每个重要论断都有出处或确认人
- Number（数字）：数字可以按规则重新算一遍核对
- Policy（政策）：内容符合政策和权限
- Audience（受众）：接收人看得懂，也知道下一步该做什么
提速又不把负担推给下游的例子
销售部门：从会议到方案书（Meeting-to-Proposal）
写给开发团队 · 技术细节
开会前，系统把客户数据、往来记录和相关新闻汇总成简报，并把事实和假设分开标注。会后，AI 把会议记录整理成客户的问题点（Pain Point）、决策标准（Decision Criteria）和下一步行动（Next Step）。销售人员选定报价和条件，系统再用已审批的模板起草文件。发送前，质量关卡核对价格、范围和承诺。要追求的是第一轮就能通过的方案书（Proposal），起草了多少份并不说明问题。
运营部门：从工单到解决（Ticket-to-Resolution）
AI 读取工单，完成分类，调出历史记录，并从知识库里推荐排查步骤。如果置信度（Confidence）低，或者出现有风险的措辞，系统立即转给资深人员。标准案例回复得更快，专家只需要看附带了上下文的例外情况。团队因此多了产能，安全性也没有降低。要衡量的是结案时间、首次联系解决率（First-contact Resolution）和重新打开的工单数。
经理：从数据到决策（Data-to-Decision）
不必让 AI 从零开始写报告。让系统调取口径固定的 KPI，标出变化，并提出问题；经理到现场核实原因，做出决定，并记下所依据的假设。下一轮，系统把实际结果和当初的预期作比较。这样能少花时间排版，多留时间思考，决策权也不会交给模型。
试行时，在同一时期内随机分配用 AI 的工作和按原方式做的工作，以排除季节、工作量或个人能力差异的影响。一般工作看中位数（Median），慢的案例看 P90，因为客户对长尾的感受往往比对平均值更强烈。
把个人的成功变成团队的标准
写给开发团队 · 技术细节
能干的员工常有自己私藏的 Prompt，别人不知道它为什么好用。人一离职，效率也跟着走了。把验证过的做法整理成 Workflow Card，写明 Trigger、Input、Prompt 或 Template、检查步骤、Owner、Version，以及通过和不通过的示例。集中存放，并在数据、政策或工具变化时重新审视。
不自欺欺人的仪表盘
| 指标 | 应该怎样改善 | 预警信号 |
|---|---|---|
| End-to-end Lead Time | 整件工作的时间确实缩短 | 只有起草变快 |
| Right-first-time | 首轮通过的比例提高 | 返工轮次增加 |
| Cost per Accepted Output | 算上审核成本后仍然下降 | API 费用低，审核人力却很高 |
| Exception Rate | 持平或下降 | 系统只接简单的工作 |
| Customer/Receiver Outcome | 回复更快，满意度更高 | 产出很多，却没人用 |
事先定好停止规则（Stop Rule）。比如错误率连续两周超标，就退回只起草的模式；审核花的时间比省下的还多，就修改简报，或者停掉这个应用场景；团队不用，就查清问题出在用户体验、信任、工作不对路，还是 KPI 互相冲突。别什么问题都靠加培训来解决。
快一倍不一定全靠 AI。有时候砍掉没人看的报告、减少审批人，或者把公共数据理顺，效果比 AI 还大。获益最多的公司，把 AI 放进整套工作的重新设计里，没有只在旧流程上再贴一层。
TECHNIQUE · 快而不草率
两轮法（Two-pass）：第一轮求广，第二轮求准
别指望 AI 一次就写出最终答案。第一轮让它拆解问题、指出缺少的信息，并提出 3 种思路；人选定方向、补上事实。第二轮再按模板生成成品，并附上检查清单。看起来多了一步，却能大幅减少后期返工，方案书、报告和需要多个部门过目的内容尤其如此。
20–60–20 法则
20% 的时间用来写简报，60% 由 AI 和人一起产出，剩下 20% 用来检查，并按接收人的需要调整。如果检查环节连续超过 20%，说明输入、模板或工作范围还有问题。别靠催审核人加快速度来解决。
提示：模板按产出命名，比如“Proposal-SME-v3”，别起“最新超好用 Prompt”这种名字。不合格的示例也要留着，错误示例比长篇说明更能划清边界。
从知识到真正能解决问题的系统
问题的根源
提速要改整条路径。只催起草这一步、把检查留给下一个人，是行不通的。
分步解决方案
- 用至少 20 个真实案例，测出 Touch、Wait 和 Rework 时间
- 按 Frame、Gather、Create、Check、Act 设计工作流，并设置质量关卡
- 先在小范围试行，衡量合格产出（Accepted Output）、P90、错误率和单件成本
把高手的诀窍变成全队都能用的工作流
团队说用了 AI 之后变快了，我们会接着问：快在哪里？下一个环节是谁多扛了活？所以 DNA Maker 会先跟着真实的工作走一遍，从接到需求一直到接收方认可，把动手时间、等待时间和返工时间分开。然后和工作负责人坐下来，一起定好简报、质量关卡和例外情况。判断工作是否“够好”的知识仍然来自客户自己的团队，我们负责把这些知识整理成看得见、量得出的流程，私藏的 Prompt 不会因此流失，错误也不会推给最后的审核人。
需求明确之后，DNA Maker 可以把 AI 工作助手（AI Work Assistant）设计成 Web 应用或移动应用：接收简报、从现有系统调取数据、起草、按规则检查、送审批，并保留审计日志（Audit Log），全部在一条流程里完成。AI 智能体（AI Agent）可以帮忙收集背景信息或执行多步骤的工作，关键节点的决定权仍在人手里。从产品设计、系统集成、开发、评测和监控，到在工程师审核下用 AI 自主开发（AI Autonomous Development）加快构建和测试，我们都能全程参与。如果您的团队有某一类工作天天重复，可以带着真实的流程来和我们聊聊。我们会帮您分清哪些部分该砍掉，哪些该自动化，哪些该留给人。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| API | 让系统之间交换数据的标准通道 | 从 CRM 调取客户数据放进简报 | 有哪些系统可以对接？在权限或数据量上有没有限制？ |
| Quality Gate | 工作进入下一步之前必须通过的检查点 | 方案书发出前，核对价格和引用来源 | 合格标准靠规则判断还是靠专家判断？证据怎么记录？ |
| Human-in-the-loop | 在关键节点由人检查或做决定 | AI 起草，但由负责该客户的人亲自点击发送 | 每个案例都要人看，还是只看有风险的？ |
| Automation | 让系统按设定条件执行重复步骤 | 会后自动创建任务，不用重复录入 | 系统出错时，怎么停下、怎么回滚、通知谁？ |
| Audit Log | 记录哪个人或哪个系统在什么时候做了什么 | 回查方案书用的是哪个版本的数据 | 需要能回查多久以前的记录？ |