AI 已经会回答，为什么工作还没有完成

最近和几位有经验的朋友聊天，大家提到的困扰很相似：AI 明明能写、能答、能给出方案，但真正放到工作里，常常还要人从头改一遍。问题不在于它生成得少，而在于它生成得不对。

这也解释了一个现象：越是有现场经验的人，越不会把 AI 当成一个“输入一句话就能交付”的工具。他们更关心的是，在什么条件下可以让它做、做到什么程度、谁来验收。AI 已经是一项必须掌握的技能，但这项技能的核心，不是会写提示词，而是知道什么叫做对。

会生成，不等于会工作

素材里有一句话我很认同：不只是能够生成，而是能够正确地生成。生成是中间步骤，正确才是交付标准。场景、边界、责任、口径，这些判断仍然在人这一边。人的经验越强，越能看出哪里不对，也越能把 AI 的输出拉回到可用的范围。

所以，讨论 AI 时只谈“能不能生成”是不够的。一份报告、一个方案、一段代码，生成出来只是开始；它是否符合当前项目的约束，是否能被同事和客户接受，出了问题由谁负责，这些都不会因为模型变强而自动解决。真正需要训练的，是把问题说清楚、把标准定下来、把结果验一遍的能力。

Agent 把“说”变成了“做”

我自己也做过 AI Agents。早期的 Agent，更多是在网页和聊天窗口里，围绕一些不太熟悉的话题给出讨论和回复。它像一个随时在旁边的顾问，能提供信息，但事情还是要人去办。

现在的变化是，Agent 开始接到具体的动作上。通过一个网络地址，它可以联系服务、完成预约，把原本需要人点开页面、填写信息、确认时间的流程接过去。能预约的东西，原则上都能被接进这样的流程。

这一步的意义，不在于 Agent 更会聊天，而在于它开始占用“执行”这一层。哪些动作可以交出去，哪些必须留在人手里，变成了新的设计问题。也要看到边界：一部分工作已经完成，另一部分并没有过去。Agent 不是把整份工作吞下去，而是把其中可被描述、可被验证的段落接走。

人机协作，最后要落到项目结构里

在大规模开发和团队协作里，这个问题会更明显。项目需要 PM，也需要 FD 这样的角色；团队负责人之间要有分工，项目群之间要有接口。过去，每个领域会提供不同的项目，由 S.E. 或研究工程师承担；需要的时候，再把合适的人放到更专业的位置上。

和项目群合作时，需求文件、报告文件、时间节点，基本还是以往的方式。AI 并没有让项目治理消失，反而把这些东西的重要性放大了：只有把目标、约束、交付物写清楚，Agent 才有可能接得住。项目开始运行之后，还要持续考虑如何改善、如何增加复杂度、如何在途中把成果物变成可复用的模板。

所以，人机协作不是一个口号，而是一张分工表。人负责定义问题、设计流程、判断结果、承担后果；AI 负责执行其中可以被拆清楚的部分。两者之间需要有接口，也需要有验收。没有这些，AI 越强，返工可能越多。

成功、失败、改善，这三个词在项目里会反复出现。AI 可以帮忙缩短中间过程，但不能替人定义什么叫成功，也不能替人承担失败的代价。哪些事情值得继续投入，哪些地方需要停下来重做，最终还是人的判断。

能力要能被抽取、组合和复用

素材里还有一个判断：技能可以从更大的范围里抽取，知识可以沉淀在 EBase 里；具体到每个项目，再根据流程去组合和控制，可以自由设计。

这背后的变化是，组织能力不再只存在某个人的脑子里。它可以被拆成技能、知识和流程，再按项目重新组装。小型的服务器、工作流、资金，也可以被重新运转起来。素材提到，前一段时间企业成绩不错，消耗金额减少，后半期变得更好；这些说法没有给出可验证的数据，我更愿意把它理解为一个方向，而不是一个已经证实的结论。

真正能积累下来的，是成果物被当作模板继续使用。下一个项目不是从零开始，而是从上一个项目的结构开始。改善只有在被复用的时候，才不是一句口号。

技术还会变，先把方法跑起来

新的生成方式在哪里有意义，应该用什么方法生成，怎样才能使用、重复使用，直到真正直接使用——这些问题目前都没有标准答案。可以确定的是，技术还会继续改善，未来会发生什么，没有人能提前写完。

能做的，是保持探索。遇到异常状况，就随时去看；最初阶段跑出来的一个好例子，可能会带来更大的变化。以往同事也会用类似的定位测试，先看一个人实际做什么、适合什么，再制定计划。对 AI 也是一样：先看它在哪个环节真的能交付，再决定放多少进去。

AI 和人类智慧，最后要放在同一张工作图上。不是把工作全部交出去，也不是把 AI 挡在门外，而是让人的思维、经验和判断，与 AI 的执行能力各自站在合适的位置上。AI 已经会回答，接下来要回答的，是我们如何把工作重新设计一遍。